(57)【要約】  複数の異質のタイプのパケット処理アプリケーションをシームレスに保有するプラットフォーム。１つまたは複数のアプリケーションが、プラットフォーム上のサービスカード上にロードされる。パケットの特性に従って、複数のサービスカードの１つまたは複数によりパケット処理用の論理経路をマッピングするプログラム可能パス構造が含まれる。多数のパス構造をプラットフォーム内にプログラムして、異なるタイプのパケット向けに異なるサービスパスを与えることができる。
2010532631.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークのエッジにおいてパケットの処理を実施するプラットフォームであって、
各サービスカードが、少なくとも１つの特定のネットワークアプリケーションを実行するように構成された、転送プレーンの複数のサービスカードと、
パケットの特性に従って、複数のサービスカードの１つまたは複数を通してパケット処理用の論理経路をマッピングする、プログラム可能なサービスパス構造と、
プログラム可能サービスパス構造に従って、１つまたは複数の複数のサービスカードの進入から退出までパケットを物理的に経路指定するように構成された複数の入力および出力ポートを含むファブリックとを備える、プラットフォーム。
【請求項２】
複数の入出力（Ｉ／Ｏ）カードをさらに備え、各Ｉ／Ｏカードが、プラットフォームの進入から退出までパケットを経路指定するように構成された、請求項１に記載のプラットフォーム。
【請求項３】
少なくとも１つのアプリケーションの実行が、ファイアウォールプロセス、ディープパケット検査プロセス、ウィルス検出プロセス、およびサービス拒否検出プロセスの少なくとも１つを含むネットワークセキュリティに関連したアプリケーションの実行を含む、請求項１に記載のプラットフォーム。
【請求項４】
少なくとも１つのアプリケーションの実行が、フロー監視プロセス、トラフィック測定プロセス、および調査プロセスの少なくとも１つを含むトラフィックアカウンティング／監視に関連したアプリケーションの実行を含む、請求項１に記載のプラットフォーム。
【請求項５】
転送プレーンに結合された制御プレーンをさらに備え、制御プレーンが、少なくとも１つの帯域幅管理またはトラフィック管理プロセスに関連したアプリケーションを実行する転送プレーンとともに使われる少なくとも１つの機能サーバを備える、請求項１に記載のプラットフォーム。
【請求項６】
転送プレーンに結合された制御プレーンをさらに備え、制御プレーンが、少なくとも１つのコンテンツ適応プロセスまたはアプリケーション高速化プロセスに関連したアプリケーションを実行する転送プレーンとともに使われる少なくとも１つの機能サーバを備える、請求項１に記載のプラットフォーム。
【請求項７】
転送プレーンに結合された制御プレーンをさらに備え、制御プレーンが、プログラム可能サービスパス構造の１つまたは複数の部分を制御する、請求項１に記載のプラットフォーム。
【請求項８】
サービスカードおよび／またはＩ／Ｏカードの少なくとも１つが、パケットの少なくとも１つの特性を識別し、識別された少なくとも１つの特性に基づいてパケットに分類子を割り当てるように構成され、パケットが次いで、プログラム可能サービスパス構造の１つまたは複数を通してパケットをナビゲートするのに使われる、請求項２に記載のプラットフォーム。
【請求項９】
パケットを処理するシステムであって、
特有の処理セグメントをパケットに対して実施するようにそれぞれが構成された複数のサービスアプリケーションと、
サービスアプリケーションの１つに関連した処理の１つの特有セグメントの処理の完了を、サービスアプリケーションのうち別の１つの、別の特有セグメントの処理の開始にリンクするようにプログラム可能に構成され、そうすることによって、パケット処理の各部分を、特有の順序で、複数のサービスパスによって指定された複数のサービスアプリケーションのどれによっても実施することができる複数のサービスパスとを備える、システム。
【請求項１０】
ネットワーク内でのパケット処理用のプラットフォームであって、
各サービスカードが、（ｉ）少なくとも１つの特定のネットワークアプリケーションを実行し、（ｉｉ）プラットフォームの進入から退出までパケットを経路指定するように構成された、転送プレーンを形成する複数のサービスカードと、
パケットの特性に従って、複数のサービスカードの１つまたは複数を通してパケット処理用の論理経路をマッピングする、プログラム可能なサービスパス構造と、
プログラム可能サービスパス構造に従って、１つまたは複数の複数のサービスカードの進入から退出までパケットを物理的に経路指定するように構成された複数の入力および出力ポートを含むファブリックとを備える、プラットフォーム。
【発明の詳細な説明】
【技術分野】
【０００１】
本特許出願は、本発明と同時に出願し、本発明の譲受人に譲渡された「ＮＥＴＷＯＲＫ  ＳＹＳＴＥＭ  ＨＡＶＩＮＧ  ＡＮ  ＥＸＴＥＮＳＩＢＬＥ  ＣＯＮＴＲＯＬ  ＰＬＡＮＥ」という名称の米国特許出願第１１／８２４，５５５号（整理番号Ｈａｖｅｍａｎｎ  ４−２０−４３）、および「ＮＥＴＷＯＲＫ  ＳＹＳＴＥＭ  ＨＡＶＩＮＧ  ＡＮ  ＥＸＴＥＮＳＩＢＬＥ  ＦＯＲＷＡＲＤＩＮＧ  ＰＬＡＮＥ」という名称の米国特許出願第１１／８２４，５６５号（整理番号Ｈａｖｅｍａｎｎ  ５−２１−４４）という米国特許出願に関連する。上で引用した出願の内容は、参照によって本明細書に完全に組み込まれている。
【０００２】
本発明は概して、ネットワーク接続に関し、より詳細には、単一のプラットフォーム上での相異なるネットワーク接続アプリケーションの統合に関する。
【背景技術】
【０００３】
エッジ装置は、コアネットワーク内へのパケット接続入口点を提供する。こうした装置は一般に、コアネットワークに入るトラフィックのフローを制御し分析し、有害なトラフィックが入るのを防止することによってコアネットワークにセキュリティを提供し、またはアプリケーションを向上させる。
【０００４】
トラフィックを監視し分析するエッジ装置の例は、トラフィック監視システム、トラフィック分析システム、フロー複製システム、およびコアネットワークに入るトラフィックのタイプを監視し制御する他の様々なシステムを含む。
【０００５】
ネットワークに入るデータの内容を分析して、コアネットワークにセキュリティを提供するエッジ装置の例は、ファイアウォールおよび検出／防止機器を含む。
【０００６】
簡単に言うと、ファイアウォールは、私設ネットワークへの認可されたフロー／ユーザのアクセスのみを許可することによって、ネットワークへのアクセスを制限する装置を指す。
【０００７】
一方、検出／防止機器は、コンピュータウィルス、ワーム、トロイの木馬、スパム、マルウェア、スパイウェア、アドウェア、ならびに他の悪意のある望ましくないソフトウェアなどだがそれに限定されない、悪意のあるコードを識別し、ネットワークに入るのを防ぐシステムを指す。侵入検出機器は、サービス拒否攻撃などの攻撃がコアネットワーク上で行われているときを検出するシステムも含み得る。
【０００８】
アプリケーションを向上させるエッジ装置の例は、パケットのフローを改善するアプリケーション、コンテンツ適応アプリケーション、および高速化アプリケーションファンクションを含む。
【０００９】
多くの事例では、企業および組織は、ネットワークのエッジで使用するために、最高級のエッジ装置ソリューションを購入する。たとえば、ある組織は、それぞれが最高級なので、または他の何らかの理由で、ベンダＡのウィルス検出製品、ベンダのＢファイアウォール、ベンダのＣフロー複製製品、およびベンダのＤのルータを購入する場合がある。
【００１０】
その結果、コアネットワークのエッジにおいて備えられるほとんどの装置は、異なるタスクをそれぞれが実施する、相互接続された同類でない装置の寄せ集めである。こうした異質エッジソリューションのセットアップおよび操作のための総コストは、制御不能なほど上昇しつつある。こうした異なるすべてのソリューションの購入に加え、機器の継続稼動および異質の機器すべての上でのソフトウェア管理に関連するコストもある。さらに、増え続けるネットワーク要求を扱うためにネットワークのエッジに機器を追加するのは、しばしば複雑であり、柔軟性がない。
【００１１】
さらに、たとえばマルウェア、ＤＤｏＳ、ファイアウォール、経路指定など、異なる目的のためにパケットを検査するのに様々なタイプの機器が必要とされると、パケットがネットワークのエッジで受信されたときから、宛先に経路指定されるときまでの間に、多数のパケット検査が行われる可能性がある。残念ながら、パケットが検査され分析される度に遅延が引き起こされるが、これは、音声や映像などのリアルタイムデータを含むパケットなど、サービス品質を要求するパケットにとっては特に望ましくない。
【００１２】
現在、異なるタイプのパケットまたはトラフィックフローへの柔軟なサービス法はない。パケットは、エッジに入ると、固定の一連のベンダソリューションにより経路指定される。パケットのタイプに関わらず、ネットワークに入る各パケットに対してどのサービスが実施されるかの選択に関して、選択肢はほとんどない。たとえば、比較的高い優先レベル（または信頼されるソース）を有する一部のパケットタイプにとっては、効率を上げるために一定のパケット分析機器を迂回することは困難である。ベンダの装置およびサービスの異なる組合せによりパケットフローを通過させる（たとえば経路指定する）ことも困難である。
【００１３】
さらに、異なるベンダ機器によって提供される機能性の大部分は、範囲が特定のアプリケーションに制限される固定の機能性を有する。したがって、特定のアプリケーションを、その意図した使用のためにプログラムし直す（アップグレードする）ことは可能ではあり得るが、現在、意図した目的を完全に変えるように装置を動的にプログラムし直すことはできない。たとえば、現在、スパイウェアを稼動する装置を、コード変換を実施する装置にコンバートすることはできない。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】米国特許出願公開第２００６００９２９７４号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１５】
現在、ネットワークに入るパケットにより効率的にサービスして、パケットタイプごとに所望の最低限のレベルまで検査量を削減したいという要望がある。最高優先レベルに分類される一部のパケットを、ネットワークのエッジでのより効率的な検査プロセスにより経路指定できるようにするために、サービス品質が犠牲にされないことを保証したいという要望もある。さらに、現時点で、しばしば相異なるベンダによって提供される、ネットワークのエッジまたは他の場所で実施される様々な異質のタイプの機能性を簡素化し、より柔軟に統合したいという要望もある。
【課題を解決するための手段】
【００１６】
従来技術の上述した欠陥に対処するために、本発明は、複数の異質のタイプのパケット処理アプリケーションをシームレスに保有する単一のネットワークプラットフォームを提供し、各アプリケーションは、相異なるベンダによって提供することができる。本明細書で使用する「プラットフォーム」とは、単一の物理装置を含んでもよく、論理的には単一のネットワークエンティティとして運営される、１つにリンクされた多数の装置を（１つまたは複数の場所に）含んでもよい。
【００１７】
一実施形態では、プラットフォームは、転送プレーンを形成する複数のサービスカードを含み、各サービスカードは、ネットワークセキュリティ、コード変換、トラフィック分析、または他のパケット処理機能性の実施に関連づけられた１つまたは複数の特定のパケット処理アプリケーション（アプリケーション）を実行するように構成される。プラットフォームは、１つまたは複数の入出力（Ｉ／Ｏ）カードも含んでよく、各カードは、プラットフォームの進入から退出までパケットを経路指定するように構成される。パケットの特性に従って、複数のサービスカードの１つまたは複数およびＩ／Ｏカードの１つまたは複数によりパケット処理用の論理経路をマッピングするプログラム可能サービスパス構造が含まれる。多数のパス構造をネットワークプラットフォーム内にプログラムして、異なるタイプのパケット向けに異なるサービスパスを与えることができる。
【００１８】
一実施形態では、どのようにしてパケットがプラットフォームに入り、または出るか（すなわち、プラットフォームからのパケットの転送）についての決定は、パケット処理のためにどのアプリケーションがトラバースされる（たとえば、実行される）かについての決定とは分離される。
【００１９】
別の実施形態では、プログラム可能サービスパス構造に従って、１つまたは複数のサービスカードおよび１つまたは複数のＩ／Ｏカードとの間でパケットを物理的に経路指定するように構成された複数の入力および出力ポートを有するプラットフォーム上に、ファブリックが含まれる。
【００２０】
別の実施形態では、各サービスカードは、アプリケーションをアップグレードし、またはアプリケーションを完全に消去して、全く新しい目的および機能性をもつ新しいアプリケーションと置き換えるなど、ランタイム中に動的にプログラムし直すことができる。たとえば、ウィルス保護の実施に関連したアプリケーションの実行から、コード変換に関連したアプリケーションの実行に、サービスカードを動的に構成し直すことが可能である。
【００２１】
革新的な本プラットフォームの特徴および利点は、通常は別々の装置において見られる多数のネットワークパケットサービスアプリケーションを柔軟に統合できる能力を備えたルータの従来の機能性を組み込むことができることである。
【００２２】
例示的な追加実装形態および特徴／利点について、添付の図面とともに詳細な説明に記載する。
【００２３】
詳細な説明を、添付の図面を参照して記述する。図面において、参照番号の左端の（複数）桁は、参照番号が最初に表れる図を識別する。図面は、必ずしも縮尺通りに描いておらず、例示目的のみであることに留意されたい。
【図面の簡単な説明】
【００２４】
【図１】本発明を実装することができる例示的な環境を示す図である。
【図２】本発明を内部で完全に、または部分的に実装することができるパケットサービスプラットフォーム（プラットフォーム１０６）を示す図である。
【図３】プラットフォームによるパケット経路指定のための論理サービスパス構造を示す図である。
【図４】パケット経路指定のための無数の例示的な論理サービスパス構造の別のものを示す図である。
【図５】パケットのサービスおよび処理のためのプログラム可能サービスパス構造の別の例を示す図である。
【図６】パケットに関する様々な特性ならびに対応するプログラム可能分類子およびパケットをサービスする論理経路を示す図表である。
【図７】負荷最適配分性能を含むプラットフォームの進入から退出までのパケットの転送を示す論理図である。
【図８Ａ】線形であるパケットフローのためのデータ経路を示す別の論理図である。
【図８Ｂ】非線形であるパケットフローのためのデータ経路を示す論理図である。
【図８Ｃ】ＡＮＤおよびＯＲ演算子を使って、どのようにしてアプリケーションを１つにリンクするかについての拡張例を示す図である。
【図９】本発明の態様を内部で完全または部分的に実装することができるサービスカードを実装する一般的プラットフォームを示す図である。
【図１０】サンドボックスを含む、統合プラットフォーム用の制御プレーンの一部として実装される機能サーバを示す論理図である。
【図１１】異質のネットワークファンクションをもつプラットフォームを通してパケットを柔軟に経路指定する例示的な方法を示す図である。
【図１２】どのようにして制御パケットフローが制御プレーンの機能サーバに経路指定され、データパケットフローが転送プレーンのサービスカードに経路指定されるかを示す論理ブロック図である。
【図１３】プラットフォームのコア制御ファンクションにアクセスするように、ユーザ定義制御／管理プロセスを機能サーバ内にどのようにして実装することができるかに関するプログラミングモデルを示す図である。
【発明を実施するための形態】
【００２５】
概要
本明細書における、「一実施形態」、「実施形態」、「実装形態」または「一実装形態」への言及あるいは本明細書における同様の記述は、実施形態との関連で記載するある特定の特徴、構造、作用、または特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、このような言い回しまたは記述が本明細書において現れた場合、必ずしもすべてが同じ実施形態を指すわけではない。さらに、特定の様々な特徴、構造、作用、または特性は、１つまたは複数の実施形態において適切にどのように組み合わせてもよい。
【００２６】
以下の記述では、本発明を完全に理解してもらうために、説明目的で、具体的な数、物体および構成について説明する。ただし、本発明は、具体的な各例なしでも実施できることが当業者には明らかであろう。他の事例では、本発明の例示的な実施形態の説明を分かりやすくし、そうすることによって本発明をより分かりやすく説明するために、よく知られている特徴は省略され、または簡略化される。
【００２７】
例示的な環境
図１は、本発明を実装することができる例示的な環境１００を示す。環境１００は、第１のネットワーク１０２および第２のネットワーク１０４を含む。第１のネットワーク１０２および第２のネットワーク１０４は、コンピュータネットワークまたは電気通信ネットワークである。たとえば、一実施形態では、第１のネットワーク１０２はコアネットワークである。コアネットワークは一般に、通信ネットワーク（すなわち、サービスプロバイダ）の幹線を形成し、高容量スイッチおよび他のデータ伝送装置の組合せを含む。
【００２８】
一方、第２のネットワーク１０４は、サービスプロバイダネットワークに接続することができ、異なる管理権限をもち得るコンピュータネットワークまたは電気通信ネットワークである。たとえば、一実施形態では、第２のネットワーク１０４は、ユーザおよび他のネットワークを第１のネットワーク１０２に、ならびにその逆に接続する通信ネットワークの一部分を形成するアクセスネットワークである。他の実施形態では、第２のネットワーク１０４は、別のコアネットワーク、あるいは私的組織または行政機関などの顧客ネットワークを表し得る。
【００２９】
第１のネットワーク１０２と第２のネットワーク１０４との間に置かれているのは、アクセスネットワーク１０４からコアネットワーク１０２に、およびその逆にパケットを経路指定するパケットサービスプラットフォーム（プラットフォーム）１０６である。
【００３０】
一実施形態では、プラットフォーム１０６は、ネットワークのエッジにあるが、ネットワークのエッジ以外のネットワーク内部のポイントに配置してもよい。プラットフォーム１０６は、ネットワーク１０２とネットワーク１０４との間の通信を容易にするのに使われる。たとえば、図１の例示では、プラットフォーム１０６は、第１のネットワーク１０２と第２のネットワーク１０４との間の接続性アクセスを提供する。プラットフォーム１０６は、他のコアネットワークまたはアクセスポイントの間の接続を可能にすることもできる。
【００３１】
プラットフォーム１０６は、複数の異質のネットワーク機能性を単一の統合プラットフォーム内でホストしている。異質のネットワーク機能性はそれぞれ、異なるベンダから選択することができる。プラットフォーム１０６に組み込むことができる異なるタイプの機能性の例は、パケット経路指定、セキュリティサービス（ファイアウォール（複数可）、サービス拒否検出、マルウェア検出など）、パケット分析（トラフィックアカウンティング、およびフロー監視など）、ならびに他の現在または将来のパケットサービス技術を含むが、必ずしもそれに限定されない。
【００３２】
したがって、本発明の一態様によるプラットフォーム１０６は、通常は別々の装置で見られる、多数のネットワークパケットサービスアプリケーションを柔軟に統合する能力を備えたルータの従来の機能性をすべて含む。
【００３３】
例示的なパケットサービスプラットフォーム
図２は、本発明を内部で完全に、または部分的に実装することができるパケットサービスプラットフォーム（プラットフォーム１０６）を示す。一実装形態では、プラットフォーム１０６は、複数のサービスカード２０２（１）、．．．、２０２（Ｎ）、入出力カード２０６、ファブリック２０８、制御要素２１２、および機能サービス２１４を含む。図面で使われる印「Ｎ」は、１以上の数を示す。印Ｎは、装置ごとに異なる数量の装置を表し得る。たとえば、Ｎは、サービスカードに関しては８に等しい場合があるが、Ｉ／Ｏカード２０６に関しては２という数だけを指す場合もある。
【００３４】
第２のネットワーク１０４からパケットを受信し、第１のネットワーク１０２を介してパケットを宛先に送るための、およびその逆のための、第１のネットワーク１０２と第２のネットワーク１０４との間のインタフェースは、入出力（Ｉ／Ｏ）カード２０６によって提供される。
【００３５】
パケットは、データまたは制御パケットの形でよい。本明細書で使用するように、パケットとは、ネットワークによって搬送される、フォーマットされたどの情報ブロックも指す。本明細書におけるいくつかの例では、パケットという用語は、単一のパケット、パケットフロー（パケットの集合体）あるいはフレームなど、１つまたは複数のパケットからなる他の何らかの記述を指し得る。
【００３６】
プラットフォーム１０６は概して、転送プレーン２０１および制御プレーン２０３を含む。概して、転送プレーン２０１は、パケットを移送し、パケットのフローに関連したパケット処理サービスを実施する。制御プレーン１０３は、プラットフォーム１０６の管理および運営用の制御情報を処理する。
【００３７】
着信パケットは、Ｉ／Ｏカード２０６のポートに入り、プラットフォーム１０６の転送プレーン２０１または制御プレーン２０３のどちらかに送られる。つまり、着信パケットは、Ｉ／Ｏカード２０６に入り、ファブリック２０８を経由して、１つまたは複数のサービスカード２０２、制御要素２１２、または機能サーバ２１４に転送される。着信パケットは、退出などのために追加サービスが必要とされない場合は別のＩ／Ｏカード２０６に直接転送してもよい。Ｉ／Ｏカード２０６は概して、パケットが、カードによって受信されると、転送プレーン２０１または制御プレーン２０３のどちらに送られるか判定する。ただし、他の実装形態では、パケットが転送プレーン２０１または制御プレーン２０３のどちらに送られるか、他の要素が判定してよい。たとえば、サービスカード２０２が、Ｉ／Ｏカードのこのファンクションを実施することができる。
【００３８】
サービスカード２０２は、パケットを処理する、プラットフォーム１０６用の転送プレーンの一部分を備える。各サービスカード２０２は、パケット処理サービスを実施する少なくとも１つのパケット処理アプリケーションを含む。パケット処理サービス例は、ポリシー強化（ファイアウォール（複数可）、およびトラフィック調整器の実装など）の実施、侵入検出および防止（サービス拒否検出、マルウェア検出など）の実施、パケット分析（アカウンティング／計測およびトラフィック監視など）の実施、ネットワークアドレス変換の実施、コード変換、またはネットワーク内に展開することができる他の適切なパケットサービスを含む。本開示の利益を受ける当業者には容易に理解されるように、他のパケット処理サービスを実施することもできる。
【００３９】
一実装形態では、少なくとも１つのサービスカード２０２がスロットカードとして物理的に実装され、普通は、１つまたは複数のネットワークアプリケーションに関連したコードを実行する能力をもつプロセッサベースのブレードまたは回路パックとも呼ばれる。
【００４０】
サービスカードは他の形をとり得ることを、本開示の利益を受けた当業者は理解されたい。たとえば、一実装形態では、サービスカード２０２は、構成可能なフィールドプログラム可能ゲートアレイ（ＦＰＧＡ）を使うなどして、ファームウェアで実装することができ、再プログラム可能でよい。
【００４１】
さらに別の実装形態では、サービスカード２０２はハードウェアベースでよく、たとえば特定用途向け集積回路（ＡＳＩＣ）を使って実装することができる。
【００４２】
プラットフォーム１０６上に存在するものとして示してあるが、１つまたは複数のサービスカード２０２は、プラットフォーム１０６から遠隔でよいことを、本開示の利益を受けた当業者は理解されたい。たとえば、サービスカード２０２は、プラットフォーム１０６から離れた多数のホップでよく、プラットフォーム１０６と同じ場所に配置しなくてよい。
【００４３】
Ｉ／Ｏカード２０６（１）．．．．、２０６（Ｎ）は、プラットフォーム１０６用の転送プレーンの一部分を形成する。１つまたは複数のＩ／Ｏカード２０６は、プラットフォーム１０６の進入から退出までパケットを経路指定するように構成される。つまり、各Ｉ／Ｏカード２０６は、Ｉ／Ｏポート２０４またはファブリック２０８から受信された着信パケットを処理することができ、転送のために適切なＩ／Ｏポート２０４に送ることができる。
【００４４】
Ｉ／Ｏカード２０６は、ファブリック２０８を介して、１つまたは複数のサービスカード２０２あるいは他のＩ／Ｏカード２０６によって予め処理された着信パケットを処理することもできる。Ｉ／Ｏカード２０６は、パケットを処理し、制御要素２１２によってファブリック２０８を介してＩ／Ｏカード２０６上にロードされた転送規則に基づく、パケット向けの次のホップまたは宛先の判定などを含む経路決定を行うことができる。
【００４５】
あるいは、別の実施形態では、１つまたは複数のサービスカード２０２が、プラットフォーム１０６用の転送の一部を形成することができる。つまり、１つまたは複数のサービスカード２０２は、パケットを処理し、制御要素２１２によってファブリック２０８を介してサービスカード２０２上にロードされた経路指定規則に基づく、パケット向けの次のホップまたは宛先の判定を含む経路決定を行うことができる。パケットは、ファブリック２０８、およびＩ／Ｏカード２０６のポート２０４を介して次のホップ先に転送することができる。
【００４６】
プラットフォーム１０６上に存在するものとして示してあるが、１つまたは複数のＩ／Ｏカード２０６は、プラットフォーム１０６とは遠隔でよいことを、本開示の利益を受けた当業者は理解されたい。たとえば、Ｉ／Ｏカード２０２は、プラットフォーム１０６から離れた多数のホップでよく、プラットフォーム１０６と同じ場所に配置しなくてよい。
【００４７】
制御要素２１２は、プラットフォーム１０６用の制御プレーン２０３の一部分を形成する。制御要素２１２は、サービスカード２０２、およびＩ／Ｏカード２０６を構成する構成情報を伝送することができる。また、機能サーバ２１４（後でより詳しく説明する）は、サービスカード２０２を構成するための構成情報を伝送することができる。さらに、制御要素２１２は、新しい機能サーバアプリケーションをインストールするように機能サーバ２１４を構成することもできる。制御要素２１２は、ファブリック２０８を制御する論理（図示せず）と対話して、サービスカード２０２とＩ／Ｏカード２０６との間の接続を効果的に確立することができる。制御要素２１２は、「プログラム可能サービスパス構造」（後で説明する図３から図５を参照）と呼ばれる、プラットフォーム１０６内部でパケットを経路指定する情報をサービスカード２０２に提供することもできる。プログラム可能サービスパス構造は、ファブリック接続２０８を介して各サービスカード２０２に伝えることができる。
【００４８】
制御要素２１２は、ファブリック接続２０８と通信して、サービスカード２０２とＩ／Ｏカード２０６との間の接続を確立することもできる。制御要素２１２は、経路指定構成の変更が行われたとき、ネットワーク１０２内のネットワーク要素（図示せず）の間のリンク状況、経路変更、およびアップデート情報についての知識をもち続ける。制御要素２１２は、プラットフォーム１０６の一般動作全般を制御できるようにすることもできる。
【００４９】
プラットフォーム１０６上に存在するものとして示してあるが、１つまたは複数の制御要素２１２は、プラットフォーム１０６から遠隔でよいことを、本開示の利益を受けた当業者は理解されたい。たとえば、制御要素２１２は、プラットフォーム１０６から離れた多数のホップでよく、プラットフォーム１０６と同じ場所に配置しなくてよい。したがって、プラットフォーム１０６が起動する（電源が入る）と、プラットフォーム１０６は、プラットフォーム１０６に関連づけられる制御要素１１２を発見する。このような実装において、何らかの論理または制御ユニットは、データプレーンと制御プレーンとの間の直接的な初期接触を可能にする。起動中などにどのようにして制御要素２１２を転送プレーン２０１にリンクすることができるかについてのこれ以上の詳細は、その全体が参照によって本明細書に完全に組み込まれる、本発明の権利者が共同所有する「Ｓｏｆｔｒｏｕｔｅｒ」という名称の米国特許出願公開第２００６００９２９７４号に記載してある。
【００５０】
図２は、プラットフォーム１０６用の制御プレーン２０３を実装する一実施形態のみを示すことも、本開示の利益を受けた当業者は理解されたい。いくつかの制御要素２１２を図２に示してあるが、制御プレーン２０３は、単一の制御要素のみを含んでもよいことを理解されたい。さらに、制御プレーン２０３のいくつかの部分は、上述したように遠隔に実装することができるが、制御プレーン２０３のいくつかの部分は、転送プレーン２０１と同じ物理プラットフォーム上にあってよい。転送プレーン２０１および制御プレーン２０３は、論理的に互いとは別個のものとして示してあるが、物理的に存在しても、かつ／または統合方式で動作してもよいことも理解されたい。
【００５１】
ファブリック２０８は、単一のブロックとして示されており、プラットフォーム１０６に含まれる全要素用の通信ハブを供給する。ファブリック２０８は、クロスバースイッチ、相互接続スイッチ、他の適切なクロスポイント技術、およびこのような接続性技術の組合せとして実装することができることが、本開示の利益を受ける当業者には理解されよう。
【００５２】
たとえば、一実装形態では、ファブリック２０８は、協調して作用するいくつかのイーサネット（登録商標）スイッチを用いるギガビットイーサネット（登録商標）ネットワークなど、内部に含まれる交換ネットワークを含み得る。
【００５３】
ファブリック２０８は、トラフィックの多数の並列通信セッションも容易にし、かつ、制御要素２１２およびサービスカード２０２など多数のエンティティに、同時方式で互いと通信させる。ファブリック２０８は概して、単一のプラットフォームまたはシャーシ内部に存在するものとして示してあるが、ファブリック２０８の１つまたは複数の部分を、ネットワークを越えて異なる場所に分散し、リンクして単一の大規模ファブリックを形成することも可能であることに留意されたい。
【００５４】
後で説明するように、プラットフォーム１０６内部でのパケットのイントラ経路指定（すなわち、パス構造）は、プログラム可能である。つまり、サービスカード２０２によってパケットをサービスする正確な順序は、完全に構成可能である。したがって、プラットフォーム１０６は、各サービスカード２０２によって提供されるファンクションを、１つまたは複数の異なるサービスからなるプログラム可能な組合せに統合することを容易にする。このような各サービス組合せは、パケットの特性に基づいて、着信パケットに対して実施される。
【００５５】
例示的なプログラム可能なサービスの組合せ
図３は、プラットフォーム１０６によるパケット経路指定のための論理サービスパス構造３０２を示す。論理サービスパス構造３０２は、プラットフォーム１０６によって受信されたパケットの特性に従って、パケット処理用の論理経路を、複数のサービスカード２０２の１つまたは複数を通してマッピングする。
【００５６】
図示する例では、パケットが、Ｉ／Ｏカード２０６（１）によって進入ポートで受信され、論理サービスパス構造３０２に従って、ファブリック２０８を介してサービスカード２０２（２）に転送される。パケットは、サービスカード２０２（２）に関連づけられた少なくとも１つのアプリケーション２２２によって処理され、次のサービスカード２０２（３）に転送される。次に、パケットは、サービスカード２０２（３）において別のアプリケーション２２２によってサービスされ、論理サービスパス構造３０２に従って、Ｉ／Ｏカード２０６（２）に転送される。最後に、パケットは、Ｉ／Ｏカード２０６（２）の退出ポート２０４を介して第１のネットワーク１０４または第２のネットワーク１０２に転送される。
【００５７】
図４は、プラットフォーム１０６によるパケット経路指定のための無数の例示的な論理サービスパス構造の別のもの（たとえば、サービスパス構造４０２）を示す。この例では、サービスパス構造４０２に従って、パケットフローが、サービスカード２０２（１）においてアプリケーション２２２によってサービスされ、次いで、サービスカード２０２（２）、２０２（３）をスキップしてから、Ｉ／Ｏカード２０６（２）を経由して退出ポート２０４に届く。
【００５８】
図５は、プラットフォーム１０６によるパケットサービスおよび処理のためのプログラム可能サービスパス構造の別の例５０２を示す。この例では、パケットの処理用にサービスカード２０２（１）において利用可能な多数の個別アプリケーション５０４（１）、５０４（２）、５０４（３）がある。各アプリケーション５０４は、パケットに対して、あるクラスの処理を直接実施することも、パケットに関連づけられた処理を実施することも可能である。一実装形態では、アプリケーションに関連づけられた各処理クラスは一般に、サービスカード２０２に個別コードとしてロードされる。
【００５９】
図５に示すように、プラットフォーム１０６の進入から退出までパケットを移送するとき、プログラム可能サービスパス構造５０２は、１つまたは複数のアプリケーション５０４（１）、５０４（３）を選択しリンクするように構成される。プログラム可能サービスパス構造５０２は、パケットがサービスカード２０２（１）をトラバースするとき、アプリケーション５０４（２）など、１つまたは複数のアプリケーションを迂回するようにも構成される。
【００６０】
したがって、サービスカード２０２（１）は、多数のアプリケーション５０４を含んでよく、こうした特定のアプリケーションはそれぞれ、プログラム可能サービスパス構造５０２に従って選択しても迂回してもよい。
【００６１】
上記の例は、３つのネットワークサービスアプリケーションを示すだけであるが、サービスカードは、より多くまたはより少ないアプリケーションを含み得ることを、本開示の利益を受けた当業者は理解されることに留意されたい。
【００６２】
図５は、サービスカード、またはサービスカード２０２（２）などによってサービスカード上に実装されるネットワークファンクションは、パケットまたはパケットフロー向けの次のホップ先を選択する能力をＩ／Ｏ機能性に与え得ることも示す。
【００６３】
したがって、図３、図４、図５の例に基づいて、各パケットフローがプラットフォーム１０６をトラバースするときにとる論理経路（すなわち、プログラム可能サービスパス構造）は、プラットフォーム１０６内にプログラムすることができることが、当業者には明らかなはずである。したがって、図３、図４、図５は、進入から退出プラットフォーム１０６までのパケットフローの処理用の論理経路を示す。
【００６４】
サービスカード２０２で実施されるアプリケーションの完了を、（同じカード内または異なるカード上の）別のアプリケーションの開始にリンクするために、メッセージシステムを使用してパケットを移送してよく、そうすることによってプラットフォーム１０６を通したパケットフローが容易になる。
【００６５】
一実装形態では、メッセージシステムは、サービスパスフローＩＤ（次のモジュール、Ｉ／Ｏカード、またはポートを指すポインタ）を使用し、このＩＤは、パケットフロー向けの次のホップを示すサービスカードによってルックアップされる。次いで、次のホップＩＤがパケットフローのヘッダーの中にエンコードされ、パケットフローの次の宛先を示す。したがって、プログラム可能サービスパス構造の各サブパス（たとえば、セグメント）は、パケットをサービスする次のサービスカード２０２または一連のサービスカード２０２をリンクするのに必要な情報を提供する。
【００６６】
別の実装形態では、プログラム可能サービスパス構造を形成する一連のサービスカード２０２およびアプリケーション全体は、プラットフォーム１０６へのパケットの進入の際に判定することができる。このようなシナリオにおいて、フローＩＤは、パケットのヘッダー（複数可）に組み込むことができ、どのサービスフロー（パス／サブパス）をとるべきか示す。このような実装において、Ｉ／Ｏカード２０６は、パケットが最初に受信されたときにトラフィックが向けられるべき適切なサービスカード２０２を判定することができる。一連のサービスおよびファンクションを実施するための多数の連続アプリケーションは、ファブリック２０８を介して確立される接続を通じてデイジーチェーン接続され得るサービスカード２０２を使って実施することができる。
【００６７】
別の実装形態では、論理サービスパス構造を備えるどの一連のサービスカード２０２が、プラットフォーム１０６を通したパケットフローの経路指定用に選ばれるか、パケットの特性を用いて判定することができる。
【００６８】
図６は、パケットに関する様々な特性ならびに対応するプログラム可能分類子およびパケットをサービスするプログラム可能サービスパス構造を示す図表を示す。
【００６９】
たとえば、複数のプログラム可能サービスパス構造（すなわち、サービスパス１、サービスパス２、サービスパス３、．．．、またはサービスパスＮ）のどの１つにパケットフローが従うべきか判定するためのエンコード済み分類子Ｘを、特性タイプＡのパケットがパケット中にもつと仮定する。各プログラム可能サービスパス構造は、モジュール単位で１つまたは複数のサービスカード２０２ならびにアプリケーションを含み得る一連のアプリケーションを含む。分類子Ｘに対応するプログラム可能サービスパス構造は、サービスパス１であると仮定する。サービスパス１のためのプログラム可能サービスパス構造は、サービスアプリケーション１（ファイアウォール）、サービスアプリケーション２（ウィルス検出）および次いでＩ／Ｏカード２０６（経路指定）を含むとさらに仮定する。この論理経路は、分類子Ｘをもつどの受信パケットも、Ｉ／Ｏカード２０６およびサービスカード２０２に、サービスパス１に対応するプログラム可能サービスパス構造に従って各パケットを転送させるように、Ｉ／Ｏカード２０６およびサービスカード２０２中にプログラムすることができる。
【００７０】
図７は、サービスパス１またはサービスパス２という２通りのサービスパスを含み得る、プログラム可能サービスパス構造サンプルのブロック図を示す。
【００７１】
どのようにしてパケットがプラットフォーム１０６を通して経路指定されるか判定するのに使用することができる特性は、パケットのソース、ソースが信頼されるかどうか、パケットのタイプ（すなわち、データ、制御、ビデオなど）、パケットに関連づけられたサービス品質などを含む。パケットのヘッダー中のフィールドやペイロードに関連づけられたデータなど、パケットに関連づけられたどの特性も、どのサービスパスが選択される（サービスパス１、サービスパス２、．．．、またはサービスパスＮ）か判定するのに使うことができる。
【００７２】
したがって、パス経路指定実装形態では、１つまたは複数のサービスカード、およびＩ／Ｏカード上に組み込まれる一連のアプリケーション全体は、プラットフォーム１０６に入るときに、フロー分類子を使って選択される。
【００７３】
別の実装形態では、プログラム可能サービスパス構造は、オンザフライで動的に判定することができる。つまり、プラットフォーム１０６内部の次のホップは、パケット分類を用いて、各Ｉ／Ｏカードまたはサービスカードの後に新たに判定される。たとえば、サービスカードは、２通りのサービスカードのどちらかが次のホップの一部として含まれていた場合、このようなカードの１つを選択して、トラフィックを分散することができる。
【００７４】
別の実施形態では、サービスカード２０２は、パケットの特性に基づいて、どのプログラム可能サービスパスにパケットフローが従うべきか判定することもできる。
【００７５】
図７は、負荷最適配分性能を含むプラットフォーム１０６の進入から退出までのパケットの転送の論理図を示す。この例では、パケットは、トラフィックフローの負荷最適配分に基づいて、サービスパス１に従っても、サービスパス２に従ってもよい。各サービスパスは、パケットを処理する１つまたは複数のアプリケーションを含む。
【００７６】
プログラム可能サービスパス構造は、たとえば図８Ａに示すように線形でよく、図８Ａで、第１のサービスアプリケーションが実行され、その後に第２の後続サービスアプリケーションが続き、その後に次のサービスアプリケーションが続き、以下同様に、サービスパス構造内で全サービスアプリケーションが実行されるまで続く。さらに、プログラム可能サービスパス構造を形成するアプリケーション１、２、３、．．．、Ｎは各々、構成可能であり再構成可能である。制御プレーンを通してＩ／Ｏカード、サービスカードの１つまたは複数を単にプログラムし直す／構成し直すことによって、異なるアプリケーションを追加することもサービスパスから削除することもできる。
【００７７】
プログラム可能サービスパス構造は、たとえば図８Ｂに示すように非線形でもよい。「ＡＮＤ」および「ＯＲ」演算子は、プログラマ／ユーザによって、論理サービスパス構造を構築し、異なるアプリケーションをリンクするのに使うことができる基本要素である。具体的には、ＡＮＤ演算子は、パケットフローを複製する。たとえば、図８ＢでＡＮＤ演算子を使用すると、パケットフローがアプリケーション２ＡＮＤ３用に再現されることになる。言い換えると、パケットフローが複製されるべきである場合、すなわち２つ以上のコピーを作成する場合、パケットフローの１つのコピーはアプリケーション２への上位パスに従い、パケットフローの１つの複製コピーは、アプリケーション３への下位パスに従う。
【００７８】
一方、ＯＲ演算子は、少なくとも２つのサブパスのうち特定の１つを選択する。具体的には、図８ＢでＯＲ演算子を使用すると、パケットフローは、負荷最適配分などのために、アプリケーション２ＯＲ３に送られることになる。
【００７９】
したがって、基本フロー演算子ＡＮＤおよびＯＲを使って、アプリケーションの間にどちらかの演算子を挿入してリンクを提供することによって、次のアプリケーションを前のアプリケーションと論理的にリンクすることも可能である。
【００８０】
ただ１つの分岐があるときは、ＡＮＤまたはＯＲ演算子を、アプリケーションの間のリンクとして線形方式で使うことができることに留意されたい。したがって、図８の参照に戻ると、各アプリケーション１、アプリケーション２、．．．、アプリケーションＮは、ＡＮＤまたはＯＲ演算子を使って、１つにリンクすることができる。したがって、ＡＮＤまたはＯＲ演算子は、多数の分岐をリンクすることができる。
【００８１】
図８Ｃは、ＡＮＤおよびＯＲ演算子を使って、どのようにしてアプリケーションを１つにリンクするかについてのより拡張した例を示す。構造は、定義されると、物理的実装にマッピングされる必要がある。つまり、図８Ｃの構造は、どのようにしてサービスアプリケーションがリンクされるかを示す論理構造である。この論理構造が開発されると、異なるアプリケーションをサービスカード１０２上にインストールし、ＯＲおよびＡＮＤ演算子を使ってパス経路指定構造を作成することによって、論理構造をプラットフォーム１０６内にマッピングすることが可能である。
【００８２】
一実施形態では、プラットフォーム１０６に統合することができない外部装置またはファンクションを、サービスパス構造に含めることも可能である。１つまたは複数のＩ／Ｏカード１０６およびサービスカード１０２を通過し、次いでプラットフォーム１０６から、パケットを処理する外部装置に流出するサービスパス構造を定義することが可能である。外部装置がパケットを処理した後、パケットはプラットフォーム１０６に返信され、パケットは、サービスパス構造がプラットフォーム１０６を出るまで、サービスパス構造によって処理され続ける。したがって、サービスパス構造は、外部装置にパケットを引き渡すための外部ポートを有するＩ／ＯカードまたはサービスカードのＩ／Ｏポートに接続することができる外部要素を含み得る。
【００８３】
サービスカード用の例示的なコンピューティングプラットフォーム
図９は、本発明の態様を内部で完全または部分的に実装することができるサービスカード２０２を実装する一般的プラットフォームを示す。上述したように、各サービスカードは一般に、ブレードなどのコンピューティング装置または回路基板である。ただし、サービスカード２０２は、他の汎用または特殊目的コンピューティング装置でもよい。
【００８４】
一実施形態では、サービスカード２０２は、少なくとも１つのプロセッサ９０４およびメモリ９０８を含む。メモリ９０８は、揮発性メモリ（たとえば、ＲＡＭ）および／または不揮発性メモリ（たとえば、ＲＯＭ）を含み得る。いくつかの実装形態では、揮発性メモリは、コンピューティング装置のキャッシュの一部として使われ、アプリケーションコードおよび／またはデータがプロセッサ９０４によって素早くアクセスされ実行されることを可能にする。メモリ９０８は、フラッシュメモリ、連想メモリなどの形の不揮発性メモリも含み得る。様々な物理プロパティを有する他のメモリ媒体がサービスカード２０２の一部として含まれることも可能である。
【００８５】
サービスカード２０２は、他の特殊な他のハードウェア支援装置（図示せず）も含み得る。たとえば、暗号化／復号などのセキュリティファンクションを実施することができる特殊目的プロセッサ（図示せず）、またはペイロードサーチエンジンを、汎用プロセッサとともに含み得る。
【００８６】
オペレーティングシステム９２２は、コンピュータ実行可能命令および／または論理の形の構成要素としてメモリ９０８内に存在してよく、実行されると、メモリに格納されたコードとの間の論理インタフェースとして働くファイルシステムを含み得る。一実装形態では、オペレーティングシステム９２２は、完全にオープンなプラットフォームを可能にするＬｉｎｕｘオペレーティングシステムである。他のオペレーティングシステムをモジュール２０２に組み込むこともできることが、本開示の利益を受ける当業者には理解されよう。
【００８７】
サービスカード２０２は、データを送信し、かつ／または受信するための１つまたは複数の入力／出力ポート９１６も含み得る。Ｉ／Ｏポート９１６は一般に、コントローラ９０２（プロセッサ９０２およびメモリ９０８）に何らかの方式で接続される。Ｉ／Ｏポート９１６は通常、コンピューティング装置９００を通信リンク９１８に接続するハードウェアで少なくとも部分的に実装され、有線ならびに無線性能を含み得る。通信リンク９１８は、ケーブル、光ファイバ、および無線技術などだが、それに限定されない、サービスカード２０２との間のデータの伝送を扱う適切などの接続手段も含み得る。通信リンク９１８は、プラットフォーム１０６のバックプレーンまたはフェースプレート（図示せず）との間のコネクタも含み得る。
【００８８】
メモリ９０８の１つまたは複数の部分に格納されるのは、サービスエンジン９５０である。つまり、サービスエンジン９５０は、コンピュータ可読媒体（メモリ９０８など）上に常駐する、１つまたは複数のコンピュータ実行可能コードセットを含む。サービスエンジン９５０は、上述したように、１つまたは複数のサービスアプリケーション９５６に関連したファンクションを実施する。サービスアプリケーション９５６は各々、様々なパケットサービスを実施するようにプログラムし、プログラムし直すことができる。
【００８９】
サービスエンジン９５０は、パケットを経路指定するべき次のホップまたは次のポイントを選ぶ目的で使われるフロールックアップテーブルなどのアプリケーションおよび構成データ９５８も含み得る。
【００９０】
一実装形態では、サービスエンジン９５０は、制御要素の間の通信法に関連した１つのコードセットである通信モジュール９７０も含み得る。一実装形態では、通信モジュール９７０は、制御要素との通信用の「ＦｏｒＣＥＳ」などの標準プロトコルを含み得る。他の通信プロトコルをモジュール２０２に組み込んでもよいことが、本開示の利益を受けた当業者には理解されよう。
【００９１】
コードによって記載されるが、例示的なサービスエンジン９５０は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せで実装することができる。さらに、サービスエンジン９５０の全構成要素は、互いに通信可能に接続することができる。サービスエンジン９５０の構成要素の多くは、オペレーティングシステム９２２の制御下で、ファイルとして格納し識別することができることが、当業者には理解されよう。
【００９２】
他の実施形態では、サービスカード２０２は、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）、ＡＳＩＣ、ネットワークプロセッサ、または上記のどの組合せとしても実装することができる。
【００９３】
例示的な拡張可能データプレーン
図２の参照に戻ると、プラットフォーム１０６に関連した大部分の機能性は、再構成およびスケーラビリティをさらに容易にするソフトウェアで実装される。たとえば、プラットフォーム１０６ごとのサービスカード２０２およびＩ／Ｏカード２０６の数量は変わり得る。さらに、サービスカード２０２またはＩ／Ｏカード２０６は、必要に応じて追加する（または削除する）ことができ、ファブリック２０８は、必要な接続に合わせるように再構成可能である。上述したように、適切な接続を動的な方式で確立するように、サービスカード２０２、Ｉ／Ｏカード２０６、およびファブリック２０８を構成し、構成し直すことが可能である。このようなすべての構成は、そのそれぞれの装置に制御要素２１２（図２）を介してロードすることができる。
【００９４】
制御に関して、複数の制御要素２１２は、プラットフォーム１０６に対して遠隔に、および／またはプラットフォーム１０６の内部に実装することができる。転送プレーン２０１は、個々の各制御要素２１２を意識しなくてよいので、単一の仮想ユニットとしての制御要素２１２と論理的に通信することができる。こうすることにより、制御プレーン２０３の容量をより多くの制御要素２１２で拡大し増大することが可能になる。というのは、転送プレーン２０１は、制御要素を単一の仮想制御プレーンとして論理的に取り扱うからである。
【００９５】
したがって、転送プレーン２０１へのスケーラビリティの提供に加えて、プラットフォーム１０６は、制御プレーン２０３にもスケーラビリティを提供する。具体的には、制御要素の数は可変であり、クラスタを仮想化することができるので、変更があったことをプラットフォーム１０６が知ることなく、追加制御要素２１２を制御要素２１２として追加することができる。
【００９６】
制御要素２１２の利用可能な処理は、互いに協力して、制御プレーンの処理負担を必要に応じて共有することができる。したがって、プラットフォーム１０６の制御プレーンによって与えられる処理性能は、制御要素２１２を追加することによって、プラットフォーム１０６の有効期間を通してスケーリングすることができ、こうすることにより、転送要素用の制御処理資源が増大する。
【００９７】
上記に基づいて、プラットフォーム１０６は、制御プレーンおよび転送プレーンとは独立した方式で、Ｉ／Ｏ用スケーラビリティを含むスケーラビリティを提供する。制御プレーンおよび転送プレーン資源、ならびにＩ／Ｏカードおよび関連ポートの数に依存して、ファブリック２０８は、追加サービスカード２０２、またはＩ／Ｏカード２０６に合わせるように動的に構成することができる。
【００９８】
ファブリック２０８は、交換ネットワーク（ギガビットイーサネット（登録商標））を用いて実装されると、互いと通信するのに先立って、それぞれの通信エンティティにネットワークが利用可能になるのを待つよう要求することなく、同時通信をサポートする。したがって、モジュールの間の接続は固定ではなく、効果的にソフトウェア制御下であり、そうすることによって、物理的に静的な接続を回避する。プラットフォーム１０６は、実装されると、上述した要素それぞれの接続を容易にする適切なバックプレーンを含むことが、本開示の利益を受ける当業者には容易に理解されよう。
【００９９】
例示的な拡張可能制御プレーン
制御要素２１２は仮想方式で実装することができるので、機能サーバ２１４によって実行される新しいサービス機能性を、サンドボックス内に展開することが可能である。
【０１００】
図１０は、サンドボックス１００４を含む、プラットフォーム１０６用の制御プレーン２０３の一部として実装される機能サーバ２１４の論理図を示す。サンドボックス１００４は、保護された環境において、メモリ内にあるデータおよびコードとは区別されるサービスファンクションを実行させる。制限された環境においてすべてのコードが実行中であるとき、この環境は、制御プレーン２０３ならびに転送プレーン２０１によって使われるメモリに格納されたコードおよびデータを保護する。
【０１０１】
一実装形態では、機能サーバ２１４は、サンドボックス１００４を含み、サンドボックス１００４は、エンドユーザによって作成されたコード１００６がインストールされる、メモリの区分エリアである。サンドボックス１００４は、信頼されるアプリケーションコードまたはオペレーティングシステムコードがある他のメモリエリアからは分離される、制御プレーン中のメモリエリアである。サンドボックス１００４は、ユーザによって作成されたコードがどのようなシステム資源をリクエストし、またはアクセスすることができるかに関して厳しい制限がある環境を作り出す。ソフトウェアで実装されるセキュリティマネージャ１００８は、明確なアプリケーションプログラミングインタフェース（ＡＰＩ）を通じたアクセスを有する、サンドボックス１００４内のコードによってどのランタイム環境も置き換えられないことを保証する。セキュリティマネージャ１００８はまた、システムに危害を引き起こし得る危険な動作を実施する可能性があるどの動作も防ぐ。セキュリティマネージャ１００８には、セキュリティ例外を生成することによって、動作を拒否するという選択肢がある。
【０１０２】
別の実施形態では、サンドボックスは、各アプリケーションごとに定義することができる。つまり、各サービスアプリケーションごとに異なるサンドボックスがあってよい。
【０１０３】
より具体的には、顧客実装アプリケーションとともに実装される機能サーバ２１４は、安全であり効率的なやり方で、プラットフォーム１０６の既存の制御状態に直接アクセスすることができる。機能サーバ２１４によって与えられる安全性は、制限されたファンクションＡＰＩの使用、および論理的または物理的サンドボックス１００６の使用により保証される。
【０１０４】
データを守る例示的な方法
図１１は、異質のネットワークファンクションをもつプラットフォーム１０６を通してパケットを柔軟に経路指定する例示的な方法１１００を示す。方法１１００は、ブロック１１０２、１１０３、１１０４、１１０５、１１０５Ａ、１１０６、１１０８（こうしたブロックはそれぞれ、１つまたは複数の動作行為を表す）を含む。この方法が記述される順序は、限定として企図されるべきではなく、記載する任意の数の方法ブロックは、本方法を実装するためにどの順序で組み合わせてもよい。さらに、本方法は、適切などのハードウェア、ソフトウェア、ファームウェア、またはその組合せでも実装することができる。
【０１０５】
ブロック１１０２で、データパケットがプラットフォーム１０６によって受信される。たとえば、パケットは、プラットフォーム１０６の進入ポート（図２）で受信される。
【０１０６】
決定ブロック１１０３で、パケットが制御パケットであるか、それともデータパケットであるか判定が行われる。ブロック１１０３で、着信パケットが制御パケットであると判定された場合、プロセス１１００はブロック１１０５に進む。ブロック１１０３で、パケットは、１つまたは複数の機能サーバまたは制御要素に経路指定される。
【０１０７】
一方、ブロック１１０３で、着信パケットがデータパケットであると判定された場合、プロセス１１００はブロック１１０４に進む。ブロック１１０４で、パケットの特性が、ヘッダーまたはペイロード情報に基づいて判定される。
【０１０８】
さらに、プラットフォーム１０６が、パケット、たとえば制御要素２１２または機能サーバ２１４から発せられたパケットを、ブロック１１０２で受信されたパケットに基づいて発することが可能である。したがって、ブロック１１０５Ａで、パケットは、制御要素または機能サーバから発せられ得る。
【０１０９】
ブロック１１０６で、論理サービスパス（フルパス）のどのサービスパス（または次のホップ、すなわちサブパス）にパケットが従うべきかを示す情報を中継するフローＩＤが、パケットのヘッダーに挿入される。この論理経路は、構成可能であり再構成可能な異なる複数のサービスパスの１つから選択することができる。各フローＩＤは、サービスカード（サービスアプリケーション）の１つに関連した処理の、１つの固有セグメント処理の完了を、サービスカードの別の１つの、別の固有セグメント処理の開始にリンクするように構成され、その結果、パケットの処理の各部分は、固有の順序で、複数のサービスパスによって指定された、複数のサービスカードのどれによっても実施することができるようになる。パケットは、選択された論理経路に従って、サービスカードに経路指定され、各サービスアプリケーションが実行される。
【０１１０】
ブロック１１０８で、パケットは、サービスカードからＩ／Ｏカードに経路指定され、Ｉ／Ｏカードは、プラットフォームからのパケットの退出のために、ポートにパケットを経路指定するように構成される。フローＩＤまたは何らかの他のポインタ、あるいはメッセージを使って、データカードへのパケットの経路指定のためにサービスパスをデータカードとリンクすることができる。
【０１１１】
方法１１００のいくつかの動作行為は、異なるやり方で実施することができることを、本開示の利益を受ける当業者は理解されたい。たとえば、サービスパスを選択するために、パケットにフローＩＤを挿入する必要がない場合がある。そうではなく、各サービスカードは、パケットに関連づけられたペイロードまたはヘッダーの特性に基づいて次のホップまたはサービスチェーンを選択するように構成することができる。さらに、１つまたは複数のサービスカードは、パケットの次のホップの判定用に、専用のテーブルをもつことができる。さらにそれ以上の情報が、サービスパスを選択するために依拠され得る追加ビットを追加することなく、フィールドヘッダーに挿入される。
【０１１２】
さらに、サービスカード、論理経路またはファンクションブロックによって提供される例示的などの機能性も、コンピュータのプロセッサによって実行されるコンピュータ実行可能コードの一般的状況で説明することができる。概して、コンピュータ実行可能コードは、モジュール、ルーチン、プログラム、オブジェクト、構成要素、データ構造、論理、およびコンピューティング装置によって実行されると、特定のタスクを実施し、または特定の抽象データタイプを実装する他の実行可能コードを含む。コンピュータ実行可能コードは、メモリ記憶装置を含む、ローカル、リモート、および／または分散コンピュータ記憶媒体などだが、それに限定されないコンピュータ可読媒体内に配置することができる。
【０１１３】
図１２は、どのようにして制御パケットフローが機能サーバ２１４に経路指定され、データパケットフローが転送プレーン２０１のサービスカード２０２に経路指定されるかを示す論理ブロック図である。
【０１１４】
図１３は、制御要素２１２など、プラットフォーム１０６のコア制御ファンクションにアクセスするように、ユーザ定義制御／管理プロセスを機能サーバ２１４内にどのようにして実装することができるかに関するプログラミングモデルを示す。機能サーバ２１４は、転送プレーン２０１内のサービスカード２０２と通信することもできる。機能サーバは、顧客が付加価値のある独自の機能をアプリケーションに追加することができるように、プラットフォーム１０６の制御ファンクションの拡張も可能にする。このような付加価値のある機能のいくつかの例は、顧客経路指定、カスタムプロトコル処理、カスタムネットワーク測定、カスタムデータ管理を含む。
【０１１５】
カスタム経路指定：ＩＰ経路指定において共通して用いられる標準最短パス経路指定は、一部のアプリケーションにとっては適切でない場合がある。たとえば、ＶｏＩＰは、最短パスではなく最少遅延パスに沿って経路指定されるべきである。概して、キャリア（またはその顧客）は、従来のプロトコルとはうまく調和しない、特有の経路指定要件をもっている場合がある。このような経路指定要件を最短パス経路指定フレームワークに無理に合わせることは、非現実的な場合がある。カスタム経路指定プロトコルをホストする能力により、この問題を解決することができる。これにより、顧客は、独自バージョンの遅延に基づく経路指定と、そのピアとのドメイン間ＱｏＳ経路指定さえも展開することができる。
【０１１６】
カスタムプロトコル処理：ＩＰＴＶの登場により、ＩＰマルチキャストが改めて注目されるようになった。ＩＰＴＶの主要な課題は、高速チャネル変更を実施する能力である。これは一般に、ＩＧＭＰ処理に関するマルチキャストグループ参加／離脱として実装される。特殊なＩＧＭＰ処理は、顧客をそのＩＰＴＶネットワークに一意に区別させることができる。
【０１１７】
カスタムネットワーク測定：基本ネットワーク測定は、たとえばキューの長さ、リンク使用など、移送レベルのみでの統計をとる。キャリアは、こうした測度を用いて、アプリケーションのパフォーマンスを間接的に推論することができる。アプリケーションのパフォーマンスを理解するには、アプリケーションレベルで直接測定する。たとえば、拡張制御プレーンを使うと、ＶｏＩＰシグナリングまたはベアラトラフィックを注入してＳＩＰシグナリングおよびＶｏＩＰ品質を直接測定することは比較的やさしい。
【０１１８】
カスタムデータ管理：ルータが、たくさんの内部統計を収集する。この統計での既存の入手法はやりにくく、非効率である。たとえば、異なる粒度でデータを取得しようとする場合、ＳＮＭＰは非常に非効率である。機能サーバを通して、データは、プラットフォーム１０６内で前処理し（たとえば、集約し）、カスタマイズ形式でエクスポートすることができる。
【０１１９】
本発明は、上述した実施形態に限定されず、その同等物を含む請求項の範囲内のあらゆる実施形態を包含することを理解されたい。
【図１】
2010532631.tif 000003
【図２】
2010532631.tif 000004
【図３】
2010532631.tif 000005
【図４】
2010532631.tif 000006
【図５】
2010532631.tif 000007
【図６】
2010532631.tif 000008
【図７】
2010532631.tif 000009
【図８Ａ】
2010532631.tif 000010
【図８Ｂ】
2010532631.tif 000011
【図８Ｃ】
2010532631.tif 000012
【図９】
2010532631.tif 000013
【図１０】
2010532631.tif 000014
【図１１】
2010532631.tif 000015
【図１２】
2010532631.tif 000016
【図１３】
2010532631.tif 000017
【国際調査報告】
2010532631.tif 000018
2010532631.tif 000019
2010532631.tif 000020