(57)【要約】  ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードは、レシーバ(NIC405)およびレシーバ(NIC405)に動作可能に結合されるプロセッサ(CPU421)を含む。レシーバは、命令を受け取り、パケットを受け取る。プロセッサは、受け取った命令にしたがってSDPネットワークノードの構成をアップデートし、受け取ったパケットを処理する。
2017505578.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードであって、
命令を受け取り、パケットを受け取るように構成されるレシーバと、
前記レシーバに動作可能に結合されるプロセッサであって、受け取った前記命令にしたがって、前記SDPネットワークノードの構成をアップデートし、受け取った前記パケットを処理するように構成されるプロセッサと
を備える、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノード。
【請求項２】
前記命令がプロトコルのソフトウェア記述を含み、前記プロセッサが前記プロトコルを前記受け取ったパケットに適用するように構成される、請求項1に記載のSDPネットワークノード。
【請求項３】
前記レシーバが、前記命令をソフトウェア・デザインド・ネットワーキング(SDN)コントローラから受け取るように構成される、請求項1に記載のSDPネットワークノード。
【請求項４】
前記命令がプロトコルのソフトウェア記述を含み、前記プロセッサが前記ソフトウェア記述を検証し、前記ソフトウェア記述を記憶するように構成される、請求項1に記載のSDPネットワークノード。
【請求項５】
前記プロセッサが前記受け取ったパケットを発信するように構成される、請求項1に記載のSDPネットワークノード。
【請求項６】
前記プロセッサが前記受け取ったパケットを水平方向の方式と垂直方向の方式のうちの少なくとも1つで発信するように構成される、請求項5に記載のSDPネットワークノード。
【請求項７】
ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードを動作させるための方法であって、
前記SDPネットワークノードによって、処理命令を受け取るステップと、
前記SDPネットワークノードによって、第1のパケットを受け取るステップと、
前記SDPネットワークノードによって、前記第1のパケット内の情報を識別することにしたがい前記第1のパケットを分類するステップと、
前記SDPネットワークノードによって、前記処理命令にしたがい前記第1のパケットを処理するステップと
を含む、方法。
【請求項８】
前記処理命令がワークフローシーケンス記述を含む、請求項7に記載の方法。
【請求項９】
前記処理命令がソフトウェア・デザインド・ネットワーキング(SDN)コントローラから受け取られる、請求項7に記載の方法。
【請求項１０】
前処理記命令がプロトコルのソフトウェア記述を含む、請求項7に記載の方法。
【請求項１１】
前記処理命令がパケットフロー識別子およびプロトコルを含み、前記パケットフロー識別子が前記プロトコルに関連する、請求項7に記載の方法。
【請求項１２】
前記第1のパケットを分類するステップが、
前記第1のパケットのフロー識別子を構文解析するステップと、
前記第1のパケットが前記SDPネットワークノードによって処理されるべきであると決定することに応じて、前記第1のパケットをメモリに転送するステップと
を含む、請求項7に記載の方法。
【請求項１３】
前記第1のパケットを分類するステップが、
前記第1のパケットが前記SDPネットワークノードによって処理されるべきでないと決定することに応じて、前記第1のパケットを前記第1のパケットの宛先に送付するステップ
をさらに含む、請求項12に記載の方法。
【請求項１４】
前記分類されたパケットを処理するステップが、
前記第1のパケットをネットワーク要素に転送するステップと、
前記第1のパケットを処理するためにプロトコルスタックを識別するステップと、
前記第1のパケットに対し、前記プロトコルスタックに関連するプロトコルを適用するステップであって、そのことにより処理済みパケットを生成する、ステップと、
前記処理済みパケットを、前記処理済みパケットの宛先に送付するステップと
を含む、請求項7に記載の方法。
【請求項１５】
前記ネットワーク要素が、仮想ネットワーク要素を含む、請求項14に記載の方法。
【請求項１６】
前記プロトコルを適用するステップが、
プロトコル状態をアップデートするステップ
を含む、請求項14に記載の方法。
【請求項１７】
前記プロトコルを適用するステップが、前記第1のパケットに第1のプロトコルヘッダを付加するステップと前記第1のパケットに第2のプロトコルヘッダを削除するステップのうちの1つを含む、請求項14に記載の方法。
【請求項１８】
前記プロトコルを適用するステップが、第2のパケットを生成するステップを含む、請求項14に記載の方法。
【請求項１９】
ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードであって、
処理命令を受け取り、パケットを受け取るように構成されるレシーバと、
前記レシーバに動作可能に結合されるプロセッサであって、前記パケット内の情報を識別することにしたがい前記パケットを分類し、前記処理命令にしたがい前記パケットを処理するように構成されるプロセッサと
を備える、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノード。
【請求項２０】
前記プロセッサが、前記パケットのフロー識別子を構文解析し、前記パケットが前記SDPネットワークノードにより処理されるべきであると決定することに応じて、前記パケットをメモリに転送するように構成される、請求項19に記載のSDPネットワークノード。
【請求項２１】
前記プロセッサが、前記パケットが前記SDPネットワークノードにより処理されるべきでないと決定することに応じて、前記パケットの宛先に前記パケットを送付するように構成され、前記SDPネットワークノードが、前記プロセッサに動作可能に結合される送信器をさらに備え、前記送信器が、前記宛先に前記パケットを送信するように構成される、請求項20に記載のSDPネットワークノード。
【請求項２２】
前記プロセッサが、仮想ネットワーク要素に前記パケットを転送し、前記パケットを処理するためにプロトコルスタックを識別し、前記パケットに対して前記プロトコルスタックに関連するプロトコルを適用し、そのことによって処理済みパケットを生成し、前記処理済みパケットの宛先に前記処理済みパケットを送付するように構成される、請求項19に記載のSDPネットワークノード。
【請求項２３】
前記プロセッサが仮想機械である、請求項19に記載のSDPネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、「System and Method for a Software Defined Protocol Network Node」と題する、2014年1月21日に出願された米国非仮特許出願第14/160,146号の利益を主張するものであり、本出願は参照により本明細書中に組み込まれる。
【０００２】
本開示は、一般的にデジタル通信に関し、より詳細には、ソフトウェア・デザインド・ネットワーキング(SDN)ネットワークノードのためのシステムおよび方法に関する。
【背景技術】
【０００３】
現在のネットワークデータプレーンプロトコルは、エンドツーエンド7層プロトコルスタックに基づく。各層内には独立したプロセスがあり、独立した層の間の相互作用は、層間のプリミティブを介している。エンドツーエンドデータプレーンプロセスの機能の多くは、ネットワーク中のリンクデータプロセス機能ごとに、より低い層と共存する。現在のプロトコルスタックは、セッションにわたって固定され予め構成されており、ネットワーク状態の変化に適合できない。現在のプロトコルスタック設計は、アプリケーション体感品質(QoE)ごとの、プロトコルスタックが密に一致したプロビジョニングを行うことを妨げている、限られた数のオプションを提供する。現在のプロトコルスタック設計は、ソフトウェアデザインネットワーキング(SDN)概念を考慮に入れず、このことによって、プロトコルスタックが、SDNの利点を完全に活用することを妨げている。現在のプロトコルスタックは、全てのエンドツーエンドホストを同じに取り扱うが、例えばマシンツーマシン(M2M)通信といった、多くの新しいおよび/または未来のサービスおよび/またはアプリケーションは特注のプロトコルスタックを必要とする場合がある。
【発明の概要】
【課題を解決するための手段】
【０００４】
ソフトウェア・デザインド・ネットワーキング(SDN)ネットワークノードのためのシステムおよび方法を提供する、本開示の例示的な実施形態。
【０００５】
本開示の例示的な実施形態によれば、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードが提供される。SDPネットワークノードは、レシーバおよびレシーバに動作可能に結合されるプロセッサを含む。レシーバは、命令を受け取り、パケットを受け取る。プロセッサは、受け取った命令にしたがってSDPネットワークノードの構成をアップデートし、受け取ったパケットを処理する。
【０００６】
本開示の別の例示的な実施形態によれば、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードを動作させるための方法が提供される。方法は、SDPネットワークノードによって、処理命令を受け取るステップと、SDPネットワークノードによって、第1のパケットを受け取るステップとを含む。方法は、SDPネットワークノードによって、第1のパケット内の情報を識別することにしたがい第1のパケットを分類するステップと、SDPネットワークノードによって、処理命令にしたがい第1のパケットを処理するステップとをやはり含む。
【０００７】
本開示の別の例示的な実施形態によれば、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードが提供される。SDPネットワークノードは、レシーバおよびレシーバに動作可能に結合されるプロセッサを含む。レシーバは、処理命令を受け取り、パケットを受け取る。プロセッサは、パケット内の情報を識別することにしたがいパケットを分類し、処理命令にしたがいパケットを処理する。
【０００８】
実施形態の1つの利点は、データプレーンにおけるフレキシビリティが改善されること、例えば、装置のインストール後にプロトコルを付加および/または変更することができ、より細かいプロトコルの特徴が可能であることなどである。
【０００９】
実施形態のさらなる利点は、データプレーンにおける効率が改善されること、例えば、不要な機能性を除去できることなどである。
【００１０】
本開示およびその利点のより完全な理解のために、ここで、添付図面に関連して行われる以下の記載に参照がなされる。
【図面の簡単な説明】
【００１１】
【図１】本明細書に記載される例示的な実施形態にしたがう、データプレーンプロセス機能が分解された、例示的なSDPおよびSDN相互作用を図示する図である。
【図２】本明細書に記載される例示的な実施形態にしたがう、例示的な通信システムを図示する図である。
【図３ａ】本明細書に記載される例示的な実施形態にしたがう、第1の例示的なキャリアメタプロトコルパケットフォーマットを図示する図である。
【図３ｂ】本明細書に記載される例示的な実施形態にしたがう、第2の例示的なキャリアメタプロトコルパケットフォーマットを図示する図である。
【図４】本明細書に記載される例示的な実施形態にしたがう、例示的なSDPネットワークノードのアーキテクチャを図示する図である。
【図５】本明細書に記載される例示的な実施形態にしたがう、第1の例示的なソフトウェアプロトコルエンジンのアーキテクチャを図示する図である。
【図６】本明細書に記載される例示的な実施形態にしたがう、第2の例示的なソフトウェアプロトコルエンジンのアーキテクチャを図示する図である。
【図７】本明細書に記載される例示的な実施形態にしたがう、ソフトウェアプロトコルエンジンがパケットを処理するときの、ソフトウェアプロトコルエンジンにおいて生じる例示的な動作を図示する流れ図である。
【図８ａ】本明細書に記載される例示的な実施形態にしたがう、モノリシック処理を利用してパケットフローの優先順位付けを提供する、ソフトウェアプロトコルエンジンにおいて生じる例示的な動作を図示する流れ図である。
【図８ｂ】本明細書に記載される例示的な実施形態にしたがう、階層型処理を利用してパケットフローの優先順位付けを提供する、ソフトウェアプロトコルエンジンにおいて生じる例示的な動作を図示する流れ図である。
【図９】本明細書に記載される例示的な実施形態にしたがう、例示的なVNNのアーキテクチャを図示する図である。
【図１０】本明細書に記載される例示的な実施形態にしたがう、VNNマネージャにおいて生じる例示的な動作を図示する流れ図である。
【図１１】本明細書に記載される例示的な実施形態にしたがう、SDPネットワークノードがソフトウェアをアップグレードおよび/またはインストールするときに、SDPネットワークノードにおいて生じる例示的な動作を図示する流れ図である。
【発明を実施するための形態】
【００１２】
現在の例示的な実施形態の動作およびその構造が、下で詳細に議論される。しかし、多種多様な特定の状況において具現化できる多くの適用可能な発明性のある概念を、本開示が提供することを諒解されたい。議論される特定の実施形態は、本開示の特定の構造および本開示を動作するための方法の単なる実例であり、本開示の範囲を限定しない。
【００１３】
本開示の一実施形態は、SDNネットワークノードに関する。例えば、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードが命令を受け取り、パケットを受け取る。SDPネットワークノードは、受け取った命令にしたがって、SDPネットワークノードの構成をやはりアップデートして、受け取ったパケットを処理する。
【００１４】
本開示は、特定の状況、すなわちソフトウェア・デファインド・ネットワークにおける例示的な実施形態に関して記載されることになる。本開示は、標準に準拠するSDNおよび非標準に準拠するSDNに適用できる。
【００１５】
将来のネットワークは一般に、トラフィックスを複数のタイプのサービスまたは(例えば、ビデオトラフィックおよびM2Mトラフィックといった)性質にさえ組み合わせることになる。ネットワーク性能を最適化し、様々な共存するサービス品質(QoS)クラスにサービスを提供するため、将来のネットワークは、それらのQoS目標の全てを達成するために、ソフトウェア・デファインド・ネットワーキング(SDN)技法での集中型管理を必要とする可能性があろう。しかし、SDNを用いてさえ、ネットワークの性能は、それらの基礎をなすプロトコルによって依然として制限される。
【００１６】
図1は、データプレーンプロセス機能を分解した、例示的なソフトウェア・デファインド・プロトコル(SDP)およびSDN相互作用100を図示する。データ処理機能性の異なる能力を備える複数のタイプのノードがある。集中型SDPマネージャが、データソースからデータシンクへ、ネットワークエッジ間などの、エンドツーエンドデータプレーンプロセスを制御する。SDNとSDPの間には、密な相互作用がある。
【００１７】
図2は、例示的な通信システム200を図示する。通信システム200は、SDN通信システムであってよい。通信システム200は、SDNマネージャ205、SDPマネージャ207、およびSDPネットワークノード209〜215などの複数のSDPネットワークノードを含む。SDNマネージャ205は、経路(すなわち、ソースから宛先へのトラフィックフローのための、一連のSDPネットワークノード)を決定し、トラフィックフローの経路中のSDPネットワークノード内の仮想ネットワークノードにパケットを送付するために使用される、送付情報ベース(FIB)を構成するための情報を提供することができる。FIBは、FIB217中など、SDPネットワークノード中に記憶することができる。
【００１８】
SDPマネージャ207は、トラフィックフローのためのプロトコルを決定し、プロトコルを実装するため、経路に沿ったSDPネットワークノードをセットアップすることができる。SDPネットワークノードのうちの1つがトラフィックフローのためのプロトコルを事前にサポートしていない場合、SDPマネージャ207は、SDPネットワークノードに対し、プロトコルを実装するためのソフトウェア記述、ワークフローシーケンス記述、パケットフロー識別子およびプロトコルなどを含む処理命令を提供することができる。SDPマネージャ207は、経路中のSDPネットワークノードの各々に対し処理命令を提供することができる。
【００１９】
SDPネットワークノード209などのSDPネットワークノードは、VNN219などの、1つまたは複数の仮想ネットワークノード(VNN)を実装することができる。VNNは、SDPネットワークノードの仮想化であってよく、プロトコル情報ベース(PIB)221およびプロトコル223などの1つまたは複数のプロトコルを含むことができる。各VNNは、1つの仮想プライベートネットワーク(VPN)により必要とされるプロトコルを実装することができる。例として、VNNが2つのプロトコルをサポートする場合、SDPネットワークノードは、少なくとも2つのVNNを含むことができる。図2に示されるように、SDPネットワークノード209は、3つのプロトコルをサポートし、VNN219を含む、3つのVNNを含む。SDPネットワークノードは、SDPマネージャにより提供されるような、プロトコルのソフトウェア記述を実装することもできる。SDPネットワークノードは、パケットを受け取るため、プロトコルのソフトウェア記述を適用することができる。SDPネットワークノードは、パケットフロー識別子および/またはプロトコルを受け取ることもでき、ここで、パケットフロー識別子は、プロトコルと関連付けることができる。
【００２０】
ソース225は、通信システム200の中にパケット229を投入することができる。パケット229は、とりわけデータを含むことができる。パケット229は、SDPネットワークノード209において受け取られて、VNN219によって処理され、PIB221にしたがって、プロトコルスタック実装部223によって処理される。プロトコルスタック実装部223により処理するステップが、例えば、パケット229にヘッダP1およびP2(集合的にヘッダ231と示される)を付加する。パケット229は、SDPネットワークノード209により変更されると、SDPネットワークノード211において受け取られる。SDPネットワークノード211中のVNNによって処理するステップが、例えば、パケット229にヘッダP3233を付加する。パケット229は、SDPネットワークノード211により変更されると、SDPネットワークノード213において受け取られる。SDPネットワークノード213中のVNNによって処理するステップが、例えば、パケット229からヘッダP3を除去し、ヘッダP1およびP2(集合的にヘッダ231と示される)を残す。パケット229は、SDPネットワークノード213により変更されると、SDPネットワークノード215において受け取られる。SDPネットワークノード215中のVNNによって処理するステップが、パケット229からヘッダP1およびP2を除去して、とりわけデータを残す。例えば、パケット229は宛先227に提供される。
【００２１】
例示的な実施形態によれば、SDPマネージャ207などのSDPマネージャは、SDPネットワークノード能力および状態情報のデータベースを維持することができる。SDPネットワークノードの能力のデータベースは、処理速度、プロセッサの数、プロトコルソフトウェアをアップデートする能力、サポートされるプロトコル動作のタイプ(例えば、システムのオペレーションシステム、ハードウェアバージョンなど)などの情報を含むことができる。SDPネットワークノードの状態情報のデータは、測定された処理速度、負荷、プロトコル状態情報(例えば、ウィンドウサイズ、バッファサイズ、レイテンシー、エラーレートなど)を含むことができる。SDPマネージャは、仮想ネットワーク中のSDPネットワークノードを管理することができ、またはSDPネットワークノードは、移動性および/または電力状態に依存して出入りすることができる。
【００２２】
データベース中に記憶される情報は、通信システムのオペレータが入力することができるが、数が多いので、実行不可能な場合がある。通信システムを動的に変えることをサポートするために、動的発見メカニズムを使用することができる。説明に役立つ例として、SDPマネージャは、SDPネットワークノードに、それらの能力および/または状態について問い合わせるプローブメッセージを送信することができる。代替の説明に役立つ例として、SDPネットワークノードは、能力および/または状態についての情報を周期的に(または、能力および/または状態における変化などの事象の発生の際に、)送信することができる。
【００２３】
例示的な実施形態によれば、SDPマネージャは、パケット処理のため、ソフトウェアSDPネットワークノードを提供することができる。SDPマネージャは、(SDPネットワークノードがハードウェアの能力を有するが、ソフトウェアの能力を有さない、または一般的なアップデートの場合、)SDPネットワークノードに、プロトコルソフトウェアアップデートを送信することができる。SDPマネージャは、プロトコルのソフトウェアバージョンが経路の中の全てのSDPネットワークノード上で一致することを確実にすることができる。SDPマネージャは、どのSDPネットワークノードが、どのエンドツーエンドフローのために、どのソフトウェアプロトコルスタックを実装するべきかを判断することができる。SDPマネージャは、ソフトウェアデファインドプロトコルスタックにフロー識別子をマッピングするため、送付テーブルをセットアップすることができる。SDPマネージャは、アトミックプロトコル層、層の順序、プロトコルのパラメータ(最大ウィンドウサイズ、最小ウィンドウサイズなど)を含むプロトコルスタック構成のための命令を送信することにより、プロトコルスタックをセットアップすることができる。
【００２４】
例示的な実施形態によれば、SDPマネージャは、様々なフォーマットでメッセージを送信することができる。メッセージは、2進数フォーマット、プレーンテキストフォーマット、拡張マークアップ言語(XML)フォーマットなどであってよい。説明に役立つ例として、ソフトウェアアップグレードおよび/またはインストールのために使用されるSDPマネージャからのメッセージは、ソフトウェアアップデート中のプロトコルのリスト、SDPマネージャの検証で使用するためのSDPマネージャのデジタル署名、ソフトウェアアップデートの検証で使用するための暗号化ハッシュ、および2進数フォーマット、バイトコードフォーマット、テキストスクリプトなどのソフトウェアを含むことができる。別の説明に役立つ例として、新しいパケットフローをセットアップするために使用されるSDPマネージャからのメッセージは、パケットフロー識別子、パケットフロー優先順位、順にパケットフローに適用するためのプロトコルのリスト(すなわち、作業フロー)、プロトコルのサブタグを読むための命令などを含むことができる。さらに別の説明に役立つ例として、パケットフローをティアダウンするために使用されるSDPマネージャからのメッセージは、パケットフロー識別子などを含むことができる。
【００２５】
例示的な実施形態によれば、SDPネットワークノード209などのSDPネットワークノードは、SDPマネージャからメッセージを受け取り、メッセージ中に命令されたようにデータプレーンを実装することができる。データプレーンプロトコルは、メタキャリアプロトコルを利用することができる。説明に役立つ例として、SDPネットワークノードによるプロトコル処理は、順次型または階層型のプロトコル処理を使用する、複数のプロトコルのための大量の並列処理をサポートするハードウェアアーキテクチャを使用することができる。いくつかのパケットフローを順次型(サイロ)処理に、いくつかのパケットフローを並列および/または階層型処理にスケジュールすることによって、混合処理を可能とすることもできる。別の説明に役立つ例として、共有プロトコルデータベースを使用するメカニズムを介して、層間情報交換および層間プロトコル処理をサポートすることができる。接続特性の共有データベースは、各層がアクセスすることができる。さらに別の説明に役立つ例として、いくつかのプロトコル層実装は、アトミック動作(順序正しい送達、信頼性が高い送達、輻輳制御、圧縮、暗号化などを含む)、複雑な動作(順序正しく信頼性が高い送達、輻輳制御を行った順序正しく信頼性が高い送達などを含む)、ネットワークサービス(ファイアウォール、フローアグリゲーションなど)、コンテンツ処理(ビデオストリーム圧縮など)などを含むSDPネットワークノード上にインストールすることができる。プロトコル優先順位付けは、待ち行列スケジューリングおよびSDPネットワークノード上へのリソース割当てでサポートすることができる。
【００２６】
例示的な実施形態によれば、キャリアメタプロトコルは、SDPネットワークノード中のパケットの処理のための情報を含有することができる。例として、プロトコル中の情報が使用されて、パケットフローおよびそれらのプロトコル処理ワークフローを識別する。図3aおよび図3bは、第1の例示のキャリアメタプロトコルパケットフォーマット300および第2の例示のキャリアメタプロトコルパケットフォーマット350を図示する。仮想ネットワーク識別子(VN ID)フィールド305および355は、仮想ネットワークを識別するために使用される識別子(VN ID)を含有することができる。VN IDは、フローIDフィールド307および357に含有されるフロー識別子(フローID)から独立した別個の値である場合があり、またはVN IDは、推定するもしくはフローID中に埋め込むことができ、このことによって、VN IDフィールド305および355を省略することを可能にすることができる。フローIDフィールド307および357を使用して、エンドツーエンド接続および/またはサービスを識別することができる。SDNマネージャは、第1のパケットが受け取られる前に、フローIDを使用して、仮想回路をセットアップすることができる。フローIDとして使用できる識別子の例としては、インターネットプロトコルベースの5タプル、アプリケーションおよび/またはサービス識別子、仮想LAN(VLAN)ネットワークタグ、マルチプロトコルラベルスイッチング(MPLS)タグ、プライベート仮想ネットワークタグ(8ビット、16ビット、32ビットなど)、マグネティックリンク(整数値にハッシュされたユニバーサルリソースロケータ(URL))、暗号化および/または圧縮および/またはハッシュされたそれらの値の任意の組合せのグループなどが挙げられる。パケットは、プロトコル処理をバイパスするため、ヘッダを検査することなく送付することができることが留意される。
【００２７】
キャリアメタプロトコルパケットフォーマット300は、パケットフローのプロトコルワークフロー中のプロトコルについての組み合わされた情報を搬送する、キャリアプロトコルヘッダフィールド309をやはり含む場合がある。キャリアメタプロトコルパケットフォーマット300は、例えば、パッセンジャプロトコルヘッダおよびデータフィールド311中に記憶される、キャリアのプロトコルスタックの状態についての情報をやはり含む場合がある。キャリアメタプロトコルパケットフォーマット350は、パケットフローのプロトコルワークフロー中のプロトコルについての組み合わされた情報を搬送する、キャリアプロトコルヘッダフィールド359をやはり含む場合がある。キャリアメタプロトコルパケットフォーマット350は、例えば、サブプロトコルIDフィールド361、サブプロトコルヘッダフィールド363、サブプロトコルIDフィールド365、およびサブプロトコルヘッダフィールド367といった、拡張階層化能力のための異なるサブプロトコルの別個のヘッダを含むこともできる。典型的には、サブプロトコルIDは、パケットフローに適用するためのアトミックサブプロトコルの識別子を含有し、サブプロトコルヘッダは、サブプロトコルIDで識別されたプロトコルについての情報を含有する。パッセンジャプロトコルヘッダおよびデータフィールド369は、パケットフローのためのプロトコルワークフローについての付加情報を搬送することができる。サブプロトコルIDおよびサブプロトコルヘッダは、各ホップにおいて、パケットとの間で、プッシュ(付加)またはポップ(削除)することができる。サブプロトコルヘッダが、スタック中のプロトコルを識別することができ、またはタグが、スタック中のプロトコルを識別することができる。
【００２８】
図4は、例示的なSDPネットワークノード400のアーキテクチャを図示する。SDPネットワークノード400は、パケットを送受信する、NIC405などの複数のネットワークインターフェイス(NIC)を含む。NICは、例えば、パケット送付および処理について、SDPマネージャが命令することができる。例として、いくつかのパケットを、さらなるプロトコル処理のために送ることができ、一方他のパケットを別のNICに送付することができる。一般的に、単一のSDPネットワークノード上のNICは、イーサネット(登録商標)、IEEE 802.3、IEEE 802.11、IEEE 802.16、第3世代パートナーシップ(3GPP)ロングタームエボリューション(LTE)、3GPP LTE-Advancedなどといった、複数の有線またはワイヤレスプロトコルタイプをサポートすることができる。NIC405などのNICは、通信システムへの接続性を可能にするネットワークポート407、処理能力を提供する中央処理装置(CPU)409、および受け取ったパケットを記憶する速いデータメモリ411を含むことができる。NICは、パケットに関連するFIBがNICにそうするように命令する場合、いくつかのパケットをプロトコル処理のためにメモリ413に転送することができる。全てのパケットがプロトコル処理のためにメモリ413に転送されるように、FIBなしでいくつかのSDPネットワークノードを有することが可能であってよい。
【００２９】
ランダムアクセスメモリ(RAM)を使用して実装できるメモリ413は、パケット、ならびに、プロトコル状態415、パケット処理ソフトウェアおよび/またはスクラッチメモリ417、ソフトウェア419などを記憶することができる。SDPネットワークノード400は、メモリ413を利用してパケットを処理する処理能力を提供する、汎用CPU421などの、複数の汎用CPUを含むこともできる。汎用CPUは、グローバル処理ユニット(GPU)にグループ化することができる。あるいは、別個のメモリおよび/または汎用CPUへの高速リンクもしくはバスを使用することが可能であってよい。並列処理は、クロスフロー(すなわち、垂直方向の並列性)、層間(すなわち、水平方向の並列性)またはそれらの組合せを利用して、SDPネットワークノード400によってサポートすることができる。専用ASIC423などの、専用特定用途向け集積回路(ASIC)が、専用処理のための処理能力を提供することができる。例として、3値コンテンツアドレス可能メモリ(TCAM)は、速いアドレス索引を提供することができ、またはデジタル信号プロセッサ(DSP)コアは、信号処理を無線送信することができる。
【００３０】
図5は、第1の例示的なソフトウェアプロトコルエンジン500のアーキテクチャを図示する。ソフトウェアプロトコルエンジン500は、モノリシック処理を特徴とする。ソフトウェアプロトコルエンジン500は、仮想機械であってよく、または複数のパケットフロー間で共有することができる。ソフトウェアプロトコルエンジン500は、複数のVNNまたは複数のVNNのパケットフロー間で共有することができる。ソフトウェアプロトコルエンジン500は、プロトコル処理のためいくつかの受け取ったパケットを転送する方法を決定し、他のSDPネットワークノードにいくつかの受け取ったパケットを送信するために使用することができるPIB505を含む。プロトコル処理のために転送される受け取ったパケットは、着信パケット待ち行列507の中に記憶することができ、そこで、パケットは、プロトコル処理を待つ。プロトコルライブラリ509は、ソフトウェアプロトコルエンジン500によりサポートされるプロトコルを含むが、サポートされるプロトコル全てがアクティブとなることができるわけではない。プロトコルスタック511は、アクティブプロトコルのためのスタックを含む。ディスパッチャ513は、プロトコルスタック511のプロトコルサイロ中のプロトコル処理のため、着信パケット待ち行列507の中に記憶されたパケットをそれらの対応するプロトコルへと発信することができる。プロトコル処理の結果は、プロトコル状態データベース517の中に記憶することができ、それらの宛先へと進むことになるパケットを、発信パケット待ち行列519の中に配置して、他のSDPネットワークノードへの後続の送信を待つことができる。プロトコルプロビジョニングデータベース521は、ソフトウェアプロトコルエンジン500によりサポートされるプロトコルについての、ソフトウェア、命令、パラメータなどを記憶することができる。プロトコルプロビジョニングデータベース521は、ソフトウェアプロトコルエンジン500の中に、まだ実装されていないプロトコルについての、ソフトウェア、アップデート、アップグレードなどを記憶することもできる。ソフトウェアプロトコルエンジン500は、SDPノード管理ユニット523も含む。SDPノード管理ユニット523は、SDPマネージャから命令を受け取り、SDPマネージャからの命令にした
がってソフトウェアプロトコルエンジン500を構成するなどができ、命令のうちの一部は、パケットフローの、プロトコルスタックとの関連性を潜在的に参照し、他の命令は、ディスパッチャ513および/またはプロトコル自体の中のフローの優先順位付けを潜在的に参照する。SDPノード管理ユニット523は、PIB505、プロトコルプロビジョニングデータベース521、およびディスパッチャ513に動作可能に結合することができる。
【００３１】
例示的な実施形態によれば、SDPネットワークノードが新しいパケットフローを通知されると、プロトコルサイロを動的に構築することができる。プロトコルサイロは、プロトコルスタック511中の各プロトコルを実装する、機能の順位リストを含有することができる。プロトコルマッピングに対するパケットフローを、PIB505の中に記憶することができる。プロトコルは、それらの状態を監視するために、プロトコル状態データベース517を使用し、そのことが、層間の共有を可能にすることができる。プロトコル状態データベース517の中に記憶される情報の例としては、パケットシーケンス数、利用可能なパケットクレジット、セキュリティキー、待ち行列長、ウィンドウサイズ、行頭(HOL)遅延、待機パケットタイプなどが挙げられる。
【００３２】
例示的な実施形態によれば、ディスパッチャ513がリソースを管理および調整する。例として、ディスパッチャ513は、選択されたパケットにサービスするため、どのパケットがCPUおよび/またはASICを処理ならびに選択するのかを選択することができる。ディスパッチャ513は、選択されたパケットについて、割り当てられたプロトコルサイロを起動することができる。ディスパッチャ513は、(アクティブな動作として示されるように)着信パケット待ち行列507からCPUに、およびCPUから発信パケット待ち行列519にパケットをハンドオーバすることができる。ディスパッチャ513は、着信パケット待ち行列507および発信パケット待ち行列519の中のパケットをスケジュールすることにより、フロー優先順位を適用することができ、ディスパッチャ513は、プロトコル優先順位を区別するため、プロセッサ(CPUおよび/またはASIC)を割り当てることもできる。ソフトウェアプロトコルエンジン500が共有される場合、ディスパッチャ513は、仮想機械ハイパーバイザを含むことができる。ディスパッチャ513は、ディスパッチャ513が共有される方式で動作している場合、スケジュールするために、仮想ネットワーク識別子を考慮することができる。
【００３３】
図6は、第2の例示的なソフトウェアプロトコルエンジン600のアーキテクチャを図示する。ソフトウェアプロトコルエンジン600は、階層型処理を特徴とする。ソフトウェアプロトコルエンジン600は、プロトコル処理のためいくつかの受け取ったパケットを転送する方法を決定し、他のSDPネットワークノードにいくつかの受け取ったパケットを送信するために使用することができるPIB605を含む。プロトコル処理のために転送される受け取ったパケットは、着信パケット待ち行列607の中に記憶することができ、そこで、パケットは、プロトコル処理を待つ。プロトコルライブラリ609は、ソフトウェアプロトコルエンジン600によりサポートされるプロトコルを含むが、サポートされるプロトコル全てがアクティブとなることができるわけではない。作業待ち行列611は、アクティブプロトコルのための待ち行列を含む。ディスパッチャ613は、作業待ち行列611の作業待ち行列中のプロトコル処理のため、着信パケット待ち行列607の中に記憶されたパケットをそれらの対応するプロトコルへと発信することができる。パケットは、層ごとに処理することができる。各層について、ディスパッチャ613は、(例えば、アクティブな動作615などの、アクティブな動作として示される)利用可能なCPUを選択することができる。プロトコル処理の結果は、プロトコル状態データベース617の中に記憶することができ、それらの宛先へと進むべきパケットを、発信パケット待ち行列619の中に配置して、他のSDPネットワークノードへの後続の送信を待つことができる。プロトコルプロビジョニングデータベース621は、ソフトウェアプロトコルエンジン600によりサポートされるプロトコルについての、ソフトウェア、命令、パラメータなどを記憶することができる。プロトコルプロビジョニングデータベース621は、ソフトウェアプロトコルエンジン600の中にまだ実装されていないプロトコルについての、ソフトウェア、アップデート、アップグレードなどを記憶することもできる。
【００３４】
ディスパッチャ613は、処理されている現在の層が完了した後、処理する次の層を動的に決定するために、プロトコルプロビジョニングデータベース621を使用することができる。一般的に、ディスパッチャ613がリソースを管理および調整する。例として、ディスパッチャ613が、パケットを選択するためフロー優先順位を使用してどのパケットを処理するのかを選択することができ、ディスパッチャ613が、作業待ち行列を選択するためパケットの優先順位を使用してパケットをどの作業待ち行列に配置するのかを選択することができ、ディスパッチャ613が、プロトコルヘッダを使用すること、またはPIB605を参照することのいずれかによって、パケット上で割り当てられたプロトコルを起動することができる。別の例として、ディスパッチャ613は、各パケットについて、パケットフローごと、プロトコル層ごとに1つの処理スレッドで、CPU上の処理をスケジュールすることができる。さらに別の例として、ディスパッチャ613は、パケットを、作業待ち行列611からCPUに、また作業待ち行列611に戻してハンドオーバすること、ならびに、パケットを、CPUから発信パケット待ち行列619にハンドオーバすることができる。ソフトウェアプロトコルエンジン600は、SDPノード管理ユニット623も含む。SDPノード管理ユニット623は、SDPマネージャから命令を受け取り、SDPマネージャからの命令にしたがってソフトウェアプロトコルエンジン600を構成するなどができ、命令のうちの一部は、パケットフローの、プロトコルスタックとの関連性を潜在的に参照し、他の命令は、ディスパッチャ613および/またはプロトコル自体の中のフローの優先順位付けを潜在的に参照する。SDPノード管理ユニット623は、PIB605、プロトコルプロビジョニングデータベース621、およびディスパッチャ613に動作可能に結合することができる。
【００３５】
例示的な実施形態によれば、水平方向の並列性は、より多くのCPUに重い負荷層を、より少ないCPUに軽い負荷層を割り当てることにより、より良好な負荷バランスの達成を可能にすることができる。ディスパッチャ613は、着信パケット待ち行列607および発信パケット待ち行列619をスケジュールすることにより、フロー優先順位を適用することができる。ディスパッチャ613は、プロトコル優先順位を区別するために、CPUを割り当てることもできる。ディスパッチャ613は、仮想機械ハイパーバイザを含むこともできる。
【００３６】
図7は、ソフトウェアプロトコルエンジンがパケットを処理するときの、ソフトウェアプロトコルエンジンにおいて生じる例示的な動作700の流れ図を図示する。動作700は、ソフトウェアプロトコルエンジンがパケットを処理するとき、SDPネットワークノードの、ソフトウェアプロトコルエンジン500またはソフトウェアプロトコルエンジン600などのソフトウェアプロトコルエンジンにおいて生じる動作を示すことができる。
【００３７】
動作700は、ソフトウェアプロトコルエンジンがパケット処理命令を受け取ること(ブロック705)で開始することができる。ソフトウェアプロトコルエンジン(またはその中のSDPノード管理ユニット)は、SDPマネージャからパケット処理命令を受け取ることができる。ソフトウェアプロトコルエンジンは、パケットフローごとに1度、パケット処理命令を受け取ることができる。ソフトウェアプロトコルエンジンは、パケットが、SDPネットワークノードのNIC上に到達するのを待つこと(ブロック707)ができる。ソフトウェアプロトコルエンジンは、NICがパケットを受け取る(ブロック709)のを待つことができる。
【００３８】
ソフトウェアプロトコルエンジンは、パケットのフロー識別子(フローID)を読み取ること(ブロック711)ができる。一般的に、ソフトウェアプロトコルエンジンは、パケットのヘッダの少なくとも一部を構文解析して、パケットがプロトコル処理を受けるべきかどうかを決定し、また、フロー識別子を読み取るステップは、パケットがプロトコル処理を受けるべきかどうかを決定するためにソフトウェアプロトコルエンジンが使用できる例示的な技法である。ソフトウェアプロトコルエンジンは、パケットがSDPネットワークノードにより処理されるべきかどうか、すなわち、パケットがプロトコル処理を受けるべきかどうかを決定するための検査を実施すること(ブロック713)ができる。集合的に、ブロック711および713は、フロー分類と呼ぶこと(ブロック715)ができる。
【００３９】
パケットがSDPネットワークノードによって処理されるべきである場合、ソフトウェアプロトコルエンジンは、パケットを例えばRAMといったメモリに転送すること(ブロック717)ができる。ソフトウェアプロトコルエンジンは、パケットがメモリに転送されるとき、パケットに優先順位付けを適用することができる。ブロック717は、フロー優先順位付けと呼ぶこと(ブロック719)もできる。
【００４０】
ソフトウェアプロトコルエンジンは、パケットのためのVNNを決定、例えば選択して、パケットをVNNに転送すること(ブロック721)ができる。ソフトウェアプロトコルエンジンは、パケットに適用するためのプロトコルスタックを決定、例えば選択すること(ブロック723)ができる。各プロトコルについて(ブロック725)、ソフトウェアプロトコルエンジンは、プロトコルをパケットに適用してプロトコル状態をアップデートすること(ブロック727)、およびパケット内のプロトコルヘッダをアップデートすること(ブロック729)ができる。ソフトウェアプロトコルエンジンは、生成する新しいプロトコルパケットがあるかどうかを決定するための検査をすること(ブロック731)ができる。新しいプロトコルパケットを生成するべきである場合、ソフトウェアプロトコルエンジンは、さらなるプロトコル処理のためにブロック725に戻ることができる。集合的に、ブロック721〜731は、プロトコル処理と呼ぶこと(ブロック733)ができる。
【００４１】
新しいプロトコルパケットの生成が必要でない場合、ソフトウェアプロトコルエンジンは、各処理または生成されたパケットについて(ブロック735)、パケットの宛先を決定すること(ブロック737)、送付NICを検索すること(ブロック739)、パケットを送付NICに送信すること(ブロック741)ができる。
【００４２】
パケットがSDPネットワークノードによって処理されるべきでない場合(ブロック713)、ソフトウェアプロトコルエンジンは、パケットの宛先(ブロック737)、送付NICを検索すること(ブロック739)、パケットを送付NICに送信すること(ブロック741)ができる。
【００４３】
以前に議論したように、モノリシック処理は、単一のスレッドを使用してパケットフローのための全てのプロトコルを処理することができる。モノリシック処理を用いると、プロトコル間に依存性がない場合、プロトコル処理を複数のCPUに分配することを可能にすることができる。階層型のプロトコル処理を用いると、プロトコルは、連続的に処理され、このことによって、プロトコルシーケンスの割込が可能になる。単一の待ち行列をパケットごとに使用することができ、または単一の待ち行列をプロトコルフローごとに使用することができ、このことにより、フロー優先順位付けまたはプロトコル優先順位付けを簡単にすることができる。
【００４４】
フローパケット優先順位付けは、パケット処理に優先順位を付けることにより達成することができる。モノリシックワークフローを用いると、優先順位付けを着信パケット待ち行列において実施することができるが、一方階層型処理を用いると、さらなる優先順位付けをワークフロー待ち行列において実装することができる。加重ラウンドロビン、アーリエスト・デッドライン・ファースト(earliest deadline first)などを含む、幅広いパケットスケジューリング分野を使用することができる。パケットフロー優先順位は、より多くのCPUを割り当てることによって達成することもできる。階層型手法において、より多くのCPUを割り当てることは、単一のパケットフローの1つより多いパケットを同時に処理して、いくつかのパケットフローにより速い処理スループットをもたらすことができることを意味する。同様に、同じプロトコルタイプの1つより多いパケットを同時に処理して、いくつかのプロトコルにより速い処理スループットをもたらすことができる。
【００４５】
図8aは、モノリシック処理を利用してパケットフローの優先順位付けを提供する、ソフトウェアプロトコルエンジンにおいて生じる例示的な動作800の流れ図を図示する。動作800は、ソフトウェアプロトコルエンジンがモノリシック処理を利用してパケットフロー優先順位付けを提供するとき、SDPネットワークノードの、ソフトウェアプロトコルエンジン500またはソフトウェアプロトコルエンジン600などのソフトウェアプロトコルエンジンにおいて生じる動作を表すことができる。
【００４６】
動作800は、SDPネットワークノードがパケットを受け取ること、およびソフトウェアプロトコルエンジンがパケットを共有待ち行列の中に配置すること(ブロック805)で開始することができる。ソフトウェアプロトコルエンジンは、パケットをプロトコルサイロに転送すること(ブロック807)ができる。ソフトウェアプロトコルエンジン(例えば、ディスパッチャ)は、処理するため、パケットをCPUおよび/またはASICにスケジューリングすること(ブロック809)ができる。パケットは、プロトコルサイロを使用して処理すること(ブロック811)ができ、処理の結果は、プロトコルデータベースをアップデートするのに使用すること(ブロック813)ができる。ソフトウェアプロトコルエンジンは、パケットを発信パケット待ち行列に転送すること(ブロック815)ができる。
【００４７】
図8bは、階層型処理を利用してパケットフローの優先順位付けを提供する、ソフトウェアプロトコルエンジンにおいて生じる例示的な動作850の流れ図を図示する。動作850は、ソフトウェアプロトコルエンジンが階層型処理を利用してパケットフロー優先順位付けを提供するとき、SDPネットワークノードの、ソフトウェアプロトコルエンジン500またはソフトウェアプロトコルエンジン600などのソフトウェアプロトコルエンジンにおいて生じる動作を表すことができる。
【００４８】
動作850は、SDPネットワークノードがパケットを受け取ること、およびソフトウェアプロトコルエンジンがパケットを共有待ち行列の中に配置することで開始する(ブロック855)ができる。ソフトウェアプロトコルエンジンは、パケットを作業待ち行列に転送すること(ブロック857)ができる。ソフトウェアプロトコルエンジン(例えば、ディスパッチャ)は、処理するため、パケットをCPUおよび/またはASICにスケジューリングすること(ブロック859)ができる。パケットフローの中の各プロトコルについて(ブロック861)、ソフトウェアプロトコルエンジンは、作業待ち行列からパケットを取り除くこと、(ブロック863)ができ、CPUおよび/またはASICを使用してパケットをプロトコル機能によって処理すること(ブロック865)ができる。ソフトウェアプロトコルエンジンは、パケットを作業待ち行列の中に戻して、または次のプロトコルの待ち行列の中に転送すること(ブロック867)、およびプロトコルデータベースをアップデートすること(ブロック869)ができる。ソフトウェアプロトコルエンジンは、作業待ち行列の中にさらにパケットがある場合、ブロック863に戻ることができる。ソフトウェアプロトコルエンジンは、パケットを発信パケット待ち行列に転送すること(ブロック871)ができる。
【００４９】
例示的な実施形態によれば、仮想化によって、単一のSDPネットワークノード上で、複数のVNNの同時共存を可能にすることができる。VNNの例示的な使用とは、SDPネットワークノードの各VNNが、単一の仮想ネットワークプロバイダに属し、セキュリティおよびデータ分離を可能にできることである。SDPネットワークノードのハードウェアは、複数のVNNにより共有される。VNNは、SDPネットワークノード上の仮想機械の中に実装することができる。仮想ネットワークを、所与のSDPネットワークノード上の1つのVNNに割り当てることができる。複数のVNNを、所与のSDPネットワークノード上の1つの仮想ネットワークノードに割り当てることができる。
【００５０】
例示的な実施形態によれば、VNNマネージャがSDPネットワークノードの中にあってよい。VNNマネージャは、(例えば、第1のVNNから第2のVNNにパケットフローを転送し、第1のVNNから第2のVNNに仮想ネットワークを転送するなど)ポリシールールセットまたは特定のコマンドを介して、SDPマネージャによる仮想ネットワークのVNNへのマッピングについて命令を受ける場合がある。VNNマネージャは、VNN間に、仮想ネットワークコンテンツおよび/またはフローコンテンツを転送することができる。VNNマネージャは、VNNに、CPU、ASIC、メモリなどのハードウェアリソースを割り当てることもできる。
【００５１】
共有仮想ネットワークノード(S-VNN)は、異なる仮想ネットワーク間の、ハードウェアリソースの共有を可能にすることができる。一般的に、仮想化なしで、物理的な要素について単一のS-VNNが存在することができる。仮想ネットワークまたはパケットフロー間のメモリの分離なしで、ハードウェアリソースのベストエフォート共有を実現することができる。
【００５２】
専用仮想ネットワークノード(D-VNN)によって、例えば、仮想機械の使用を介して、ハードウェアリソースの仮想ネットワークへの割当てを可能にすることができる。D-VNNは、CPU、ASIC、メモリなどのハードウェアリソースのハード共有を提供することができる。SDPネットワークノードハイパーバイザは、サービス品質(QoS)要件を満たすため、ハードウェアリソースの使用を再度バランスをとることができる。D-VNNは、仮想ネットワークまたはパケットフロー間の、メモリの完全な分離を実現することができる。
【００５３】
図9は、例示的なVNN900のアーキテクチャを図示する。VNN900に関連するSDPノードに到達するパケットは、着信パケット待ち行列905の中に受け取ることができる。パケット分類器907は、パケットを処理するため、仮想リソース(例えば、VNN)を割り当てることができる。パケット分類器907は、仮想リソースをパケットに割り当てるため、仮想ネットワークおよび/またはフローテーブル909の中に記憶された情報を使用することができる。仮想ネットワークおよび/またはフローテーブル909は、オプションの仮想ネットワーク識別子を用いた、パケットフローの仮想ネットワークへのマッピングについての情報を含む。パケット分類器907は、パケットをソートし、パケットをVNNに割り当てることができる。仮想リソースは、仮想機械マネージャ911が制御することができる、S-VNN913、およびD-VNN915などの複数のD-VNNを含むことができる。ハードウェアリソーススケジューラ917は、仮想リソースにCPUおよび/またはASICを割り当てることができる。パケットは、メモリ919に転送し、(CPU921など)CPUのうちの1つもしくは複数および/または(ASIC923など)1つまたは複数のASICを使用して、仮想リソースにより処理し、メモリ919または発信パケット待ち行列925に戻して転送することができる。発信パケット待ち行列925に転送されるパケットは、タイミングデッドライン、QoS要件などを満たすためにスケジューリングすることができる。
【００５４】
図10は、VNNマネージャにおいて生じる例示的な動作1000の流れ図を図示する。動作1000は、VNNマネージャにおいて生じる動作を表すことができる。動作1000は、ポリシーにより指示され、命令されるポリシー、およびVNNマネージャによる自律動作を図示する。
【００５５】
ポリシー指示される動作において、動作1000は、VNNマネージャが、SDPマネージャからVNNポリシー命令を受け取ることで開始すること(ブロック1005)ができる。VNNマネージャは、VNN性能を監視すること(ブロック1007)ができる。例として、VNNマネージャは、CPU使用、トラフィック負荷、移動性などを監視することができる。VNNマネージャは、VNNポリシー命令にしたがうVNN転送からもたらされる性能の変化が正当化されるかどうかを決定するための検査を実施すること(ブロック1009)ができる。性能の変化が正当化される場合、VNNマネージャは、必要な場合に新しいVNNを開始し(ブロック1011)、新しいVNNへの新しいVNNフローコンテキスト中にパケットフロー送付テーブルをインストールすること(ブロック1013)ができる。VNNマネージャは、仮想ネットワークテーブル中のエントリを変えて、トラフィックを新しいVNNに向けること(ブロック1015)ができ、古いVNNが、その影響されるパケットの全ての処理を終了(フラッシュ)するのを待つこと(ブロック1017)ができる。VNNマネージャは、古いVNNのパケットフロー送付テーブルから、古いパケットフロー送付エントリを削除すること(ブロック1019)ができる。古いVNNのパケットフロー送付テーブルにエントリがない場合、VNNマネージャは、古いVNNを削除してそのリソースを再割り振りすること(ブロック1021)ができる。
【００５６】
ポリシーにより命令される動作において、動作1000は、VNNマネージャが、SDPマネージャから、VNN送付テーブル変更メッセージを受け取ることで開始すること(ブロック1025)ができる。VNNマネージャは、必要な場合に新しいVNNを開始すること(ブロック1011)、新しいVNNへの新しいVNNフローコンテキスト中にパケットフロー送付テーブルをインストールすること(ブロック1013)ができる。VNNマネージャは、仮想ネットワークテーブル中のエントリを変えて、トラフィックを新しいVNNに向けること(ブロック1015)ができ、古いVNNが、その影響されるパケットの全ての処理を終了(フラッシュ)するのを待つこと(ブロック1017)ができる。VNNマネージャは、古いVNNのパケットフロー送付テーブルから、古いパケットフロー送付エントリを削除すること(ブロック1019)ができる。古いVNNのパケットフロー送付テーブルにエントリがない場合、VNNマネージャは、古いVNNを削除してそのリソースを再割り振りすること(ブロック1021)ができる。
【００５７】
自律動作において、動作1000は、VNNマネージャがVNN性能を監視することで開始すること(ブロック1030)ができる。例として、VNNマネージャは、CPU使用、トラフィック負荷、移動性などを監視することができる。VNNマネージャは、どのパケットフローがどのVNNに行くべきかを決定すること(ブロック1032)ができる。VNNマネージャは、必要な場合に新しいVNNを開始すること(ブロック1011)、新しいVNNへの新しいVNNフローコンテキスト中にパケットフロー送付テーブルをインストールすること(ブロック1013)ができる。VNNマネージャは、仮想ネットワークテーブル中のエントリを変えて、トラフィックを新しいVNNに向けること(ブロック1015)ができ、古いVNNが、その影響されるパケットの全ての処理を終了(フラッシュ)するのを待つこと(ブロック1017)ができる。VNNマネージャは、古いVNNのパケットフロー送付テーブルから、古いパケットフロー送付エントリを削除すること(ブロック1019)ができる。古いVNNのパケットフロー送付テーブルにエントリがない場合、VNNマネージャは、古いVNNを削除してそのリソースを再割り振りすること(ブロック1021)ができる。
【００５８】
例示的な実施形態によれば、SDPマネージャがVNNマネージャに直接命令を送信すると、VNNマネージャは、パケットフローまたは仮想ネットワークを動かすことができる。例として、SDPマネージャは、古いVNNおよび新しいVNNについての、仮想ネットワークおよびパケットフローのリストを指定することができる。SDPマネージャがVNNマネージャにポリシーを送信すると、VNNマネージャは、パケットフローまたは仮想ネットワークを動かすことができる。例として、ポリシーは、体感品質(QoE)、QoS、CPU負荷、メモリ負荷などについての閾値の組であってよい。さらに、ポリシーは、UEが通信システムの周りを動くとき、どのようにパケットフローを動かすのかを指定することができる。加えて、ポリシーは、セキュリティ要件に基づいて、例えば、セキュリティを備えないパケットフローを、共有仮想機械に動かすことができる。VNNマネージャは、パケットフローまたは仮想ネットワークを動かして、SDPマネージャが、自立的にパケットフローを動かして、最適化目標に到達することができる。例として、動くことによって、リソースの利用を最適化することができる。共有リソースの利用が指定された量を超える場合、閾値を使用して、共有リソースから専用リソースに動かすことができる。同様に、専用の利用が特定の値を満たし、専用リソースをなくすことができる場合、閾値を使用して、専用リソースから共有リソースに動かすことができる。
【００５９】
図11は、SDPネットワークノードがソフトウェアをアップグレードおよび/またはインストールするときに、SDPネットワークノードにおいて生じる例示的な動作1100の流れ図を図示する。動作1100は、SDPネットワークノードがソフトウェアをアップグレードおよび/またはインストールするときに、SDPネットワークノード209などのSDPネットワークノードにおいて生じる動作を示すことができる。
【００６０】
動作1100は、SDPネットワークノードが、ソフトウェアアップグレードを待つこと(ブロック1105)で開始することができる。SDPネットワークノードがソフトウェアアップデートを待つ一方、SDPネットワークノードは、他の動作を実施できることに留意されたい。SDPネットワークノードは、ソフトウェアアップデートならびにSDPマネージャの識別を受け取ること(ブロック1107)ができる。SDPネットワークノードは、SDPマネージャの識別を検証すること(ブロック1109)ができる。SDPマネージャは、デジタル証明書を使用して識別することができる。例として、中央の証明機関を使用することができ、または証明を前の使用からキャッシュすることができる。SDPマネージャの識別が検証される場合、SDPネットワークノードは、ソフトウェアアップデートの完全性を検証すること(ブロック1111)ができる。例として、ソフトウェアアップデートの完全性は、(例えば、md5、sha-256などのハッシング関数を使用して)チェックサムハッシュで検査することができる。仮想機械ハイパーバイザは、ソフトウェアアップデートの認証において支援することができる。アップデートが、SDPノード上の全てのプロトコルについて、またはSDPノード上の全体のソフトウェアについてである場合、SDPマネージャ識別のみで十分であってよいことに留意されたい。特定のプロトコルがアップデートされる場合、アップデートは、アップデートされるプロトコルの識別子、またはPIBのためのアップデート後に使用される、アップデートされるプロトコルの新しい識別子を含むことができる。ソフトウェアアップデートの完全性が検証される場合、SDPネットワークノードは、ソフトウェアアップデートをインストールし、ソフトウェアの能力のリストをアップデートすること(ブロック1113)ができる。インストールされるプロトコルは、それらの名前を、プロトコルが起動されるときに参照できる2進数アドレスまたは機能名にマッピングしてデータベースの中に記憶することができる。プロトコルは、共有メモリ中にインストールすることができ、その結果、プロトコルは、linux(登録商標)の共有オブジェクトライブラリと同様の方式で、複数のVNNが使用することができる。例として、コンポーネントオブジェクトモデル
(COM)のレジストリキーと同様のデータベース、または動的リンクライブラリ(DLL)中の関数テーブルを使用することができる。SDPマネージャの識別の検証またはソフトウェアアップデートの完全性のいずれかが失敗した場合、SDPネットワークノードは、ソフトウェアアップデートを拒否すること(ブロック1115)、およびさらなるアップデートを待つこと(ブロック1105)ができる。
【００６１】
本開示およびその利点が詳細に記載されてきたが、添付の請求項に規定されるように、本開示の精神および範囲から逸脱することなく、様々な変更、代替、および改変を本明細書に行うことができることを理解されたい。
【符号の説明】
【００６２】
100  ソフトウェア・デザインド・プロトコル(SDP)およびSDN相互作用
200  通信システム
205  SDNマネージャ
207  SDPマネージャ
209  SDPネットワークノード
211  SDPネットワークノード
213  SDPネットワークノード
215  SDPネットワークノード
219  VNN
221  プロトコル情報ベース、PIB
223  プロトコル、プロトコルスタック実装部
225  ソース
227  宛先
229  データ、パケット
231  ヘッダ
233  ヘッダP3
300  キャリアメタプロトコルパケットフォーマット
305  仮想ネットワーク識別子(VN ID)フィールド
307  フローIDフィールド
309  キャリアプロトコルヘッダフィールド
311  パッセンジャプロトコルヘッダおよびデータフィールド
350  キャリアメタプロトコルパケットフォーマット
355  仮想ネットワーク識別子(VN ID)フィールド
357  フローIDフィールド
359  キャリアプロトコルヘッダフィールド
361  サブプロトコルIDフィールド
363  サブプロトコルヘッダフィールド
365  サブプロトコルIDフィールド
367  サブプロトコルヘッダフィールド
369  パッセンジャプロトコルヘッダおよびデータフィールド
400  SDPネットワークノード
405  NIC
407  ネットワークポート
409  中央処理装置、ネットワークCPU
411  速いデータメモリ
413  メモリ
415  プロトコル状態
417  パケット処理ソフトウェアおよび/またはスクラッチメモリ、パケット処理
419  ソフトウェア、プログラム命令
421  汎用CPU、CPU
423  専用ASIC
500  ソフトウェアプロトコルエンジン
505  PIB
507  着信パケット待ち行列
509  プロトコルライブラリ
511  プロトコルスタック、プロトコルサイロ
513  ディスパッチャ
517  プロトコル状態データベース
519  発信パケット待ち行列
521  プロトコルプロビジョニングデータベース
523  SDPノード管理ユニット
600  ソフトウェアプロトコルエンジン
605  PIB
607  着信パケット待ち行列
609  プロトコルライブラリ
611  作業待ち行列
613  ディスパッチャ
615  アクティブな動作
617  プロトコル状態データベース
619  発信パケット待ち行列
621  プロトコルプロビジョニングデータベース
623  SDPノード管理ユニット
700  動作
800  動作
850  動作
900  VNN
905  着信パケット待ち行列
907  パケット分類器
909  仮想ネットワークおよび/またはフローテーブル、VN/フローテーブル
911  仮想機械マネージャ
913  S-VNN
915  D-VNN
917  ハードウェアリソーススケジューラ、HWリソーススケジューラ
919  メモリ
921  CPU
923  ASIC
925  発信パケット待ち行列
1000  動作
1100  動作
【図１】
2017505578.tif 000003
【図２】
2017505578.tif 000004
【図３Ａ】
2017505578.tif 000005
【図３Ｂ】
2017505578.tif 000006
【図４】
2017505578.tif 000007
【図５】
2017505578.tif 000008
【図６】
2017505578.tif 000009
【図７】
2017505578.tif 000010
【図８Ａ】
2017505578.tif 000011
【図８Ｂ】
2017505578.tif 000012
【図９】
2017505578.tif 000013
【図１０】
2017505578.tif 000014
【図１１】
2017505578.tif 000015
【手続補正書】
【提出日】平成28年10月6日(2016.10.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードを動作させるための方法であって、
前記SDPネットワークノードによって、処理命令を受け取るステップと、
前記SDPネットワークノードによって、第1のパケットを受け取るステップと、
前記SDPネットワークノードによって、前記第1のパケット内の情報を識別することにしたがい前記第1のパケットを分類するステップと、
前記SDPネットワークノードによって、前記処理命令にしたがい前記第1のパケットを処理するステップと
を含む、方法。
【請求項２】
前記処理命令がワークフローシーケンス記述を含む、請求項1に記載の方法。
【請求項３】
前記処理命令がソフトウェア・デザインド・ネットワーキング(SDN)コントローラから受け取られる、請求項1又は2に記載の方法。
【請求項４】
前処理記命令がプロトコルのソフトウェア記述を含む、請求項1から3のいずれか一項に記載の方法。
【請求項５】
前記処理命令がパケットフロー識別子およびプロトコルを含み、前記パケットフロー識別子が前記プロトコルに関連する、請求項1から4のいずれか一項に記載の方法。
【請求項６】
前記第1のパケットを分類するステップが、
前記第1のパケットのフロー識別子を構文解析するステップと、
前記第1のパケットが前記SDPネットワークノードによって処理されるべきであると決定することに応じて、前記第1のパケットをメモリに転送するステップと
を含む、請求項1から5のいずれか一項に記載の方法。
【請求項７】
前記第1のパケットを分類するステップが、
前記第1のパケットが前記SDPネットワークノードによって処理されるべきでないと決定することに応じて、前記第1のパケットを前記第1のパケットの宛先に送付するステップ
をさらに含む、請求項6に記載の方法。
【請求項８】
前記分類されたパケットを処理するステップが、
前記第1のパケットをネットワーク要素に転送するステップと、
前記第1のパケットを処理するためにプロトコルスタックを識別するステップと、
前記第1のパケットに対し、前記プロトコルスタックに関連するプロトコルを適用するステップであって、そのことにより処理済みパケットを生成する、ステップと、
前記処理済みパケットを、前記処理済みパケットの宛先に送付するステップと
を含む、請求項1から7のいずれか一項に記載の方法。
【請求項９】
前記プロトコルを適用するステップが、
プロトコル状態をアップデートするステップ
を含む、請求項8に記載の方法。
【請求項１０】
前記プロトコルを適用するステップが、前記第1のパケットに第1のプロトコルヘッダを付加するステップと前記第1のパケットに第2のプロトコルヘッダを削除するステップのうちの1つを含む、請求項8又は9に記載の方法。
【請求項１１】
前記プロトコルを適用するステップが、第2のパケットを生成するステップを含む、請求項9又は10に記載の方法。
【請求項１２】
ソフトウェア・デザインド・プロトコル(SDP)ネットワークノードであって、
処理命令を受け取り、パケットを受け取るように構成されるレシーバと、
前記レシーバに動作可能に結合されるプロセッサであって、前記パケット内の情報を識別することにしたがい前記パケットを分類し、前記処理命令にしたがい前記パケットを処理するように構成されるプロセッサと
を備える、ソフトウェア・デザインド・プロトコル(SDP)ネットワークノード。
【請求項１３】
前記プロセッサが、前記パケットのフロー識別子を構文解析し、前記パケットが前記SDPネットワークノードにより処理されるべきであると決定することに応じて、前記パケットをメモリに転送するように構成される、請求項12に記載のSDPネットワークノード。
【請求項１４】
前記プロセッサが、前記パケットが前記SDPネットワークノードにより処理されるべきでないと決定することに応じて、前記パケットの宛先に前記パケットを送付するように構成され、前記SDPネットワークノードが、前記プロセッサに動作可能に結合される送信器をさらに備え、前記送信器が、前記宛先に前記パケットを送信するように構成される、請求項13に記載のSDPネットワークノード。
【請求項１５】
前記プロセッサが、仮想ネットワーク要素に前記パケットを転送し、前記パケットを処理するためにプロトコルスタックを識別し、前記パケットに対して前記プロトコルスタックに関連するプロトコルを適用し、そのことによって処理済みパケットを生成し、前記処理済みパケットの宛先に前記処理済みパケットを送付するように構成される、請求項12から14のいずれか一項に記載のSDPネットワークノード。
【国際調査報告】
2017505578.tif 000016