(57)【要約】      （修正有）【課題】ネットワークフォワーディングエレメントでデータプレーンの振る舞いを構成するための方法及び装置に関する。【解決手段】ネットワークエレメントのコントロールプレーンで、ネットワークプロトコルのアプリケーションプログラミングインタフェースを利用してプロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報を受信する。受信された情報は、ネットワークプロトコルに対応するコントロールインタフェースを使用して処理される。処理されると、コントロールインタフェースは、プロトコルコンフィギュレーション情報に従ってネットワークエレメントの１以上のデータプレーンのフォワーディングエレメントをプログラムする。これに応じて、複数のネットワークプロトコルについて類似のコントロールインタフェースを提供することで、複数のベンダからのコンポーネント間の相互運用性が可能となる。【選択図】図４
2008125116.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークエレメントのコントロールプレーンで、第三者のプロトコルアプリケーションのネットワークプロトコルに対応するアプリケーションプログラミングインタフェース（ＡＰＩ）を使用して、第三者のプロトコルアプリケーションからプロトコルコンフィギュレーション情報を抽出するステップと、
前記抽出されたプロトコルコンフィギュレーション情報により規定されるネットワークプロトコルに対応するコントロールインタフェースを使用して、該抽出されたプロトコルコンフィギュレーション情報を処理するステップと、
前記コントロールインタフェースにより、前記抽出されたプロトコルコンフィギュレーション情報に従って、ネットワークエレメントのデータプレーンの１以上のフォワーディングエレメントを構成するステップと、
を備えることを特徴とする方法。
【請求項２】
前記抽出されたプロトコルコンフィギュレーション情報を処理するステップは、
前記抽出されたプロトコルコンフィギュレーション情報により規定される該ネットワークプロトコルを実現するため、前記データプレーンでフォワーディングエレメントを選択するステップと、
前記抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントで形成するための１以上のインタフェース特定テーブルを決定するステップと、
前記インタフェース特定テーブルを含んでいるフォワーディングエレメントが前記インタフェース特定テーブルでのエントリに従う決定を確定するように、前記インタフェース特定テーブルで１以上のエントリを決定するステップと、
を更に備える請求項１記載の方法。
【請求項３】
前記１以上のデータプレーンのフォワーディングエレメントを構成するステップは、
前記データプレーンからのイベントの受信を可能にするため、前記抽出されたプロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを前記データプレーンと登録するステップと、
ネットワークエレメントのデータプレーンのうちの１以上のフォワーディングエレメントからフォワーディングエレメントを選択するステップと、
前記プロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントでの１以上のインタフェース特定テーブルについて前記選択されたフォワーディングエレメントを照会するステップと、
前記第三者のプロトコルアプリケーションにより実現された前記ネットワークプロトコルに対応するパケットを処理するとき、データプレーンの振る舞いを制御するため、前記選択されたフォワーディングエレメントの前記インタフェース特定テーブルで１以上のエントリを生成してポピュレートするステップと、
を更に備える請求項１記載の方法。
【請求項４】
前記生成するステップは、
前記生成されたインタフェース特定テーブルを決定するため、前記選択されたフォワーディングエレメントを照会するステップと、
前記抽出されたプロトコルコンフィギュレーション情報に従って前記生成されたインタフェース特定テーブルをポピュレートするステップと、
を更に備える請求項３記載の方法。
【請求項５】
前記データプレーンエレメントを構成するステップは、
ブートアップの間に前記データプレーンからのイベントの受信を可能にするため、前記ネットワークプロトコルを前記ネットワークエレメントのデータプレーンで登録するステップと、
前記受信されたプロトコルコンフィギュレーション情報に従ってＩＰｖ４ルーティングプロトコルを実現するため、前記ネットワークエレメントの前記データプレーンでフォワーディングエレメントを選択するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントで生成されたフォワーディングテーブルについて前記選択されたフォワーディングエレメントを照会するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントで生成されたアドレスレゾリューションテーブルについて、前記選択されたフォワーディングエレメントを照会するステップと、
プロトコルアプリケーションのルート更新要求が受信されたとき、前記フォワーディングテーブルでＩＰｖ４ルーティングエントリを追加／削除するステップと、
プロトコルアプリケーションのアドレスレゾリューションテーブルの更新要求が受信されたとき、前記アドレスレゾリューションテーブルにＩＰｖ４エントリを追加／削除するステップと、
を更に備える請求項１記載の方法。
【請求項６】
前記１以上のデータプレーンのフォワーディングエレメントを構成するステップは、
ブートアップの間に前記データプレーンからのイベントの受信を可能にするため、前記ネットワークプロトコルを前記データプレーンと登録するステップと、
前記抽出されたプロトコルコンフィギュレーション情報に従ってＩＰｖ６ルーティングプロトコルを実現するため、前記ネットワークエレメントのデータプレーンのフォワーディングエレメントを選択するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントで生成されたＩＰｖ６フォワーディングテーブルについて前記選択されたフォワーディングエレメントを照会するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントで生成されたＩＰｖ６ネイバーテーブルについて前記選択されたフォワーディングエレメントを照会するステップと、
プロトコルアプリケーションのルート更新要求が受信されたとき、前記フォワーディングテーブルにＩＰｖ６ルーティングエントリを追加／削除するステップと、
プロトコルアプリケーションのネイバーテーブルの更新要求が受信されたとき、前記ネイバーテーブルにＩＰｖ６ネイバーエントリを追加／削除するステップと、
を更に備える請求項１記載の方法。
【請求項７】
前記データプレーンの前記１以上のフォワーディングエレメントを構成するステップは、
ブートアップの間にＭＰＬＳプロトコルを実現するために選択されたフォワーディングエレメントでＦＴＮテーブルを生成するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントでＩＬＭテーブルを生成するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントでＦＴＮ  ＤｉｆｆＳｅｒｖコンテクストテーブルを生成するステップと、
ブートアップの間に前記選択されたフォワーディングエレメントでＩＬＭ  ＤｉｆｆＳｅｒｖコンテクストテーブルを生成するステップと、
プロトコルアプリケーションのＦＴＮテーブル更新要求が受信されたとき、前記ＦＴＮテーブルにＭＰＬＳ  ＦＴＮエントリを追加／削除するステップと、
プロトコルアプリケーションのＩＬＭテーブル更新要求が受信されたとき、前記ＩＬＭテーブルにＭＰＬＳ  ＩＬＭエントリを追加／削除するステップと、
プロトコルアプリケーションのＭＰＬＳ  Ｅ−ＬＳＰコンフィギュレーション更新要求が受信されたとき、前記ＦＴＮ  ＤｉｆｆＳｅｒｖコンテクストテーブルにＭＰＬＳ  Ｅ−ＬＳＰコンフィギュレーションエントリを追加／削除するステップと、
プロトコルアプリケーションのＭＰＬＳ  Ｅ−ＬＳＰプレコンフィギュレーション更新要求が受信されたとき前記ＩＬＭ  ＤｉｆｆＳｅｒｖコンテクストテーブルにＭＰＬＳ  Ｅ−ＬＳＰプレコンフィギュレーションエントリを追加／削除するステップと、
を更に備える請求項１記載の方法。
【請求項８】
前記データプレーンの前記１以上のフォワーディングエレメントを構成するステップは、
ブートアップの間にＤｉｆｆＳｅｒｖネットワークプロトコルを実現するために選択されるフォワーディングエレメントで複数のＤｉｆｆＳｅｒｖテーブルを生成するステップと、
プロトコルアプリケーションの分類子更新要求が受信されたとき、前記選択されたフォワーディングエレメントで生成されたＤｉｆｆＳｅｒｖ分類子テーブルにフィルタエントリを追加／削除するステップと、
プロトコルアプリケーションのメーター更新要求が受信されたとき、前記選択されたフォワーディングエレメントで生成されたＤｉｆｆＳｅｒｖメーターテーブルにメーターエントリを追加／変更／削除するステップと、
プロトコルアプリケーションのマーカー更新要求が受信されたとき、前記選択されたフォワーディングエレメントで生成されたＤｉｆｆＳｅｒｖマーカーテーブルにマーカーエントリを追加／変更／削除するステップと、
プロトコルアプリケーションのドロッパー更新要求が受信されたとき、前記選択されたフォワードエレメントで生成されたＤｉｆｆＳｅｒｖアルゴリズムドロッパーテーブルにドロッパーエントリを追加／変更／削除するステップと、
プロトコルアプリケーションのキュー更新要求が受信されたとき、前記選択されたフォワーディングエレメントで生成されたＤｉｆｆＳｅｒｖキューテーブルに照会エントリを追加／変更／削除するステップと、
プロトコルアプリケーションのスケジューラ更新要求が受信されたとき、前記選択されたフォワーディングエレメントで生成されたＤｉｆｆＳｅｒｖスケジューラテーブルにスケジューラエントリを追加／変更／削除するステップと、
を更に備える請求項１記載の方法。
【請求項９】
前記データプレーンで、パケットを受信するステップと、
第一のイベントがトリガされたとき、受信されたパケットに対応するネットワークプロトコルを実現するプロトコルアプリケーションを通知するステップと、
さもなければ、前記受信されたパケットと関連されるネットワークプロトコルに対応する１以上のインタフェース特定テーブルでプログラムされるフォワーディングエレメントを決定するステップと、
第二のイベントがトリガされたとき、前記受信されたパケットに対応するネットワークプロトコルを実現するプロトコルアプリケーションを通知するステップと、
さもなければ、前記抽出されたプロトコルコンフィギュレーション情報に従って、前記受信されたパケットと関連される前記コントロールインタフェースにより生成されるインタフェース特定テーブルのエントリに従い前記受信されたパケットを処理するステップと、
を更に備える請求項１記載の方法。
【請求項１０】
前記ネットワークプロトコルのＡＰＩは、ルーティングプロトコルのＡＰＩ、スイッチングプロトコルのＡＰＩ、及びサービス品質（ＱｏＳ）プロトコルのＡＰＩのうちの１つである、
請求項１記載の方法。
【請求項１１】
前記ルーティングプロトコルのＡＰＩは、ＩＰｖ４プロトコル及びＩＰｖ６プロトコルのうちの１つである、
請求項１０記載の方法。
【請求項１２】
前記スイッチングプロトコルのＡＰＩは、ＭＰＬＳプロトコルのＡＰＩである、
請求項１０記載の方法。
【請求項１３】
前記ＱｏＳプロトコルのＡＰＩは、ＤｉｆｆＳｅｒｖプロトコルのＡＰＩである、
請求項１０記載の方法。
【請求項１４】
前記ネットワークプロトコルのＡＰＩは、特定のトラフィックフローのパケットを所望の特別な処理と関連付けするのを可能にするためのサービス品質の機能を備える、
請求項１記載の方法。
【請求項１５】
前記所望の特別の処理は、リアルタイムサービス又はデフォルトではないサービス品質のうちの少なくとも１つを備える、
請求項１４記載の方法。
【請求項１６】
プロセッサにより実行されたとき、コンピュータに、
ネットワークエレメントのコントロールプレーンで、プロトコルアプリケーションのネットワークプロトコルに対応するアプリケーションプログラミングインタフェース（ＡＰＩ）を利用して、プロトコルアプリケーションからプロトコルコンフィギュレーション情報を抽出するステップと、
前記抽出されたプロトコルコンフィギュレーション情報により規定されるネットワークプロトコルに対応するコントロールインタフェースを使用して、前記抽出されたプロトコルコンフィギュレーション情報を処理するステップと、
前記コントロールインタフェースにより、前記抽出されたプロトコルコンフィギュレーション情報に従って、前記ネットワークエレメントのデータプレーンの１以上のフォワーディングエレメントを構成するステップとを備え、
前記コントロールプレーンのベンダは前記データプレーンのベンダとは異なる、
方法を実行するように指示するプログラム命令を含むコンピュータ読取り可能な記憶媒体。
【請求項１７】
前記抽出されたプロトコルコンフィギュレーション情報を処理するステップは、
前記抽出されたプロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを実現するため、前記データプレーンでフォワーディングエレメントを選択するステップと、
前記抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントで形成するための１以上のインタフェース特定テーブルを決定するステップと、
前記インタフェース特定テーブルを含んでいるフォワーディングエレメントが前記インタフェース特定テーブルでのエントリに従う決定を確定するように、前記インタフェース特定テーブルで１以上のエントリを決定するステップと、
を更に備える請求項１６記載のコンピュータ読取り可能な記憶媒体。
【請求項１８】
前記１以上のデータプレーンのフォワーディングエレメントを構成するステップは、
ブートアップの間に前記データプレーンからのイベントの受信を可能にするため、前記抽出されたプロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを前記データプレーンと登録するステップと、
ネットワークエレメントのデータプレーンのうちの１以上のフォワーディングエレメントからフォワーディングエレメントを選択するステップと、
前記抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントでの１以上のインタフェース特定テーブルについて前記選択されたフォワーディングエレメントを照会するステップと、
前記第三者のプロトコルアプリケーションにより実現された前記ネットワークプロトコルに対応するパケットを処理するとき、データプレーンの振る舞いを制御するため、前記選択されたフォワーディングエレメントの前記インタフェース特定テーブルで１以上のエントリを生成してポピュレートするステップと、
を更に備える請求項１６記載のコンピュータ読取り可能な記憶媒体。
【請求項１９】
前記データプレーンで、パケットを受信するステップと、
第一のイベントがトリガされたとき、受信されたパケットに対応するネットワークプロトコルを実現する第三者のプロトコルアプリケーションを通知するステップと、
さもなければ、前記受信されたパケットと関連されるネットワークプロトコルに対応する１以上のインタフェース特定テーブルでプログラムされるフォワーディングエレメントを決定するステップと、
第二のイベントがトリガされたとき、前記受信されたパケットに対応するネットワークプロトコルを実現するプロトコルアプリケーションを通知するステップと、
さもなければ、前記抽出されたプロトコルコンフィギュレーション情報に従って、前記受信されたパケットと関連される前記コントロールインタフェースにより生成されるインタフェース特定テーブルのエントリに従い前記受信されたパケットを処理するステップと、
を更に備える請求項１６記載のコンピュータ読取り可能な記憶媒体。
【請求項２０】
前記ネットワークプロトコルのＡＰＩは、ルーティングプロトコルのＡＰＩ、スイッチングプロトコルのＡＰＩ、及びサービス品質（ＱｏＳ）プロトコルのＡＰＩのうちの１つである、
請求項１６記載のコンピュータ読取り可能な記憶媒体。
【請求項２１】
前記ルーティングプロトコルのＡＰＩは、ＩＰｖ４プロトコル及びＩＰｖ６プロトコルのうちの１つである、
請求項２０記載のコンピュータ読取り可能な記憶媒体。
【請求項２２】
前記スイッチングプロトコルのＡＰＩは、ＭＰＬＳプロトコルのＡＰＩである、
請求項２０記載のコンピュータ読取り可能な記憶媒体。
【請求項２３】
前記ＱｏＳプロトコルのＡＰＩは、ＤｉｆｆＳｅｒｖプロトコルのＡＰＩである、
請求項２０記載のコンピュータ読取り可能な記憶媒体。
【請求項２４】
前記ネットワークプロトコルのＡＰＩは、特定のトラフィックフローのパケットを所望の特別な処理と関連付けするのを可能にするためのサービス品質の機能を備える、
請求項１６記載のコンピュータ読取り可能な記憶媒体。
【請求項２５】
前記所望の特別の処理は、リアルタイムサービス又はデフォルトではないサービス品質のうちの少なくとも１つを備える、
請求項２４記載のコンピュータ読取り可能な記憶媒体。
【請求項２６】
それぞれのフォワーディングエレメントに含まれる対応するインタフェース特定テーブルに従って受信されたパケットを処理するために１以上のフォワーディングエレメントを含むデータプレーンと、
相互接続リンクを介して前記データプレーンに結合され、ネットワークプロトコルを実現する少なくとも１つのプロトコルアプリケーションを含み、第三者のプロトコルアプリケーションのネットワークプロトコルに対応するアプリケーションプログラミングインタフェース（ＡＰＩ）を提供するコントロールプレーンと、
前記第三者のプロトコルアプリケーションのネットワークプロトコルに対応するＡＰＩを使用することで、前記コントロールプレーンの前記第三者のプロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報に従って前記データプレーンに含まれるインタフェース特定テーブルを生成及び構成するコントロールインタフェースと、
を備えることを特徴とするネットワークエレメント。
【請求項２７】
前記コントロールインタフェースは、
プロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを実現するために前記データプレーンでフォワーディングエレメントを選択し、
抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントで形成される１以上のインタフェース特定テーブルを決定し、
前記インタフェース特定テーブルを含んでいるフォワーディングエレメントが前記インタフェース特定テーブルでのエントリに従うプロトコルの決定を確定するように、プロトコルコンフィギュレーション情報に従って、前記インタフェース特定テーブルで１以上のエントリを決定する、
請求項２６記載のネットワークエレメント。
【請求項２８】
前記コントロールインタフェースは、
ブートアップの間に前記データプレーンからのイベントの受信を可能にするため、前記プロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを前記データプレーンで登録し、
ネットワークエレメントのデータプレーンの１以上のフォワーディングエレメントからフォワーディングエレメントを選択し、
ブートアップの間に前記選択されたフォワーディングエレメントで生成された１以上のインタフェース特定テーブルについて前記選択されたフォワーディングエレメントを照会し、
抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントの前記インタフェース特定テーブルで１以上のエントリを生成及びポピュレートする、
請求項２６記載のネットワークエレメント。
【請求項２９】
前記コントロールインタフェースは、
前記データプレーンで、パケットを受信し、
前記パケットと関連されるネットワークプロトコルに対応する１以上のインタフェース特定テーブルでプログラムされるフォワーディングエレメントを決定し、
前記受信されたプロトコルコンフィギュレーション情報に従って前記コントロールインタフェースにより生成されるインタフェース特定テーブルのエントリに従いパケットを処理し、
イベントがトリガされたときに、前記パケットと関連されるネットワークプロトコルを実現する前記プロトコルアプリケーションを通知する、
請求項２６記載のネットワークエレメント。
【請求項３０】
前記相互接続リンクは、バス、ケーブル、光ファイバ、及びＥｔｈｅｒｎｅｔ（登録商標）リンクのうちの１つである、
請求項２６記載のネットワークエレメント。
【請求項３１】
複数の結合されたネットワークエレメントを含むネットワークを備えるシステムであって、
前記ネットワークエレメントは、
それぞれのフォワーディングエレメントに含まれる対応するインタフェース特定テーブルに従って受信されたパケットを処理するために１以上のフォワーディングエレメントを含むデータプレーンと、
相互接続リンクを介して前記データプレーンに結合され、ネットワークプロトコルを実現する少なくとも１つのプロトコルアプリケーションを含み、ネットワークプロトコルに対応するアプリケーションプログラミングインタフェース（ＡＰＩ）を提供するコントロールプレーンと、
それぞれのプロトコルＡＰＩにより前記コントロールプレーンの前記プロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報に従って前記データプレーンに含まれるインタフェース特定テーブルを生成及び構成するコントロールインタフェースとを備え、
前記コントロールプレーンのベンダは、前記データプレーンのベンダとは異なる、
ことを特徴とするシステム。
【請求項３２】
前記コントロールインタフェースは、
プロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを実現するために前記データプレーンでフォワーディングエレメントを選択し、
抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントで形成される１以上のインタフェース特定テーブルを決定し、
前記インタフェース特定テーブルを含んでいるフォワーディングエレメントが前記インタフェース特定テーブルでのエントリに従うプロトコルの決定を確定するように、プロトコルコンフィギュレーション情報に従って、前記インタフェース特定テーブルで１以上のエントリを決定する、
請求項３１記載のシステム。
【請求項３３】
前記コントロールインタフェースは、
ブートアップの間に前記データプレーンからのイベントの受信を可能にするため、前記プロトコルコンフィギュレーション情報により規定される前記ネットワークプロトコルを前記データプレーンで登録し、
ネットワークエレメントのデータプレーンの１以上のフォワーディングエレメントからフォワーディングエレメントを選択し、
ブートアップの間に前記選択されたフォワーディングエレメントで生成された１以上のインタフェース特定テーブルについて前記選択されたフォワーディングエレメントを照会し、
抽出されたプロトコルコンフィギュレーション情報に従って前記選択されたフォワーディングエレメントの前記インタフェース特定のテーブルで１以上のエントリを生成及びポピュレートする、
請求項３１記載のシステム。
【請求項３４】
前記コントロールインタフェースは、
前記データプレーンで、パケットを受信し、
前記パケットと関連されるネットワークプロトコルに対応する１以上のインタフェース特定テーブルでプログラムされるフォワーディングエレメントを決定し、
前記受信されたプロトコルコンフィギュレーション情報に従って前記コントロールインタフェースにより生成されるインタフェース特定テーブルのエントリに従いパケットを処理し、
イベントがトリガされたときに、前記パケットと関連されるネットワークプロトコルを実現する前記プロトコルアプリケーションを通知する、
請求項３１記載のシステム。
【請求項３５】
前記相互接続リンクは、バス、ケーブル、光ファイバ及びＥｔｈｅｒｎｅｔ（登録商標）リンクのうちの１つである、
請求項３１記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の１以上の実施の形態は、ネットワーク通信及びプロトコルの分野全般に関する。より詳細には、本発明の１以上の実施の形態は、ネットワークフォワーディングエレメント（network  forwarding  elements）でデータプレーンの振る舞いを構成するための方法及び装置に関する。
【背景技術】
【０００２】
今日、様々な独立したハードウェアベンダ（IHV:  Independent  Hardware  Vendors）は、無数のパケット処理タスクを実行するためのネットワーキング特定用途向け集積回路（ASIC:  Application  Specific  Integrated  Circuits）を製造している。残念なことに、かかるＡＳＩＣへの現在のインタフェースは、対応するビットレベルの振る舞い及びドキュメンテーションを有するメモリマップドレジスタである。しかし、全てのＩＨＶがレジスタレベルの記述にそれらの製品を制限しているのではなく、Ｃレベル又はハードウェアに対する他のソフトウェアインタフェースを提供するものがある。しかし、これらのインタフェースは、基礎をなすレジスタを便宜的に反映するものであり、したがって、ＩＨＶ毎に異なる。
【０００３】
さらに、レジスタレベルの記述又はハードウェアＡＳＩＣへのそれらのソフトウェアインタフェースは、これらの様々な製品を使用するのを非常に難しくする。実際に、これらのレジスタレベルのモデルは、スティープラーニングカーブを表し、ある製品でＡＳＩＣ又はネットワーキングシリコンを使用するのを望む相手先ブランド製造（OEM:  Original  Equipment  Manufacturer）又は独立したソフトウェアベンダ（ISV:  Independent  Software  Vendors）からの堅い結合を表している。かかるマイクロレベルの記述（すなわちレジスタビット）では、これらの様々なＡＳＩＣにわたって再使用可能なコードを書き込むことは困難である。さらに、ＡＳＩＣのネットワーキングシリコンのマイクロレベルの機能性を解読することも困難である。
【０００４】
ネットワーキング産業における最近のトレンドは、よりプログラマブルであるが、ネットワークプロセッサのようなパフォーマンス指向のネットワーク装置との、ＡＳＩＣのリプレースメントであり、これは比較的融通がきかない。残念なことに、ネットワークプロセッサは、一般的に初期のステージにあり、アブストラクトプログラミングモデルを有さないか、又はプロセッサ自身における進歩につれて成長するに十分に表現的であってフレキシブルなモデルを有さない。一般に、スイッチ及びルータのようなネットワークエレメントは、コントロールプレーン（control  plane）、フォワーディングプレーン（forwarding  plane）及びマネージメントプレーン（management  plane）という、３つの論理的な動作コンポーネントに分類することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
一般に、コントロールプレーンは、異なるシグナリング及び／又はルーティングプロトコルを実行し、全てのルーティング情報をフォワーディングプレーンに提供する。フォワーディングプレーンは、この情報に基づいて決定し、分類のフォワーディング、フィルタリング等のようなパケットに関する動作を実行する。直交するマネージメントプレーンは、コントロール及びフォワーディングプレーンを管理する。しかし、上述されたプレーンないに標準化されたアプリケーションプログラミングインタフェース（API:  Application  Programming  Interfaces）を導入することで、システムベンダＯＥＭ及びこれらネットワークエレメントのエンドユーザは、かれらの装置の選択を達成するために異なるベンダから利用可能なコンポーネントを混成及び整合させるのに役立つことができる。
【発明を実施するための最良の形態】
【０００６】
本発明の様々な実施の形態は、添付図面における、限定されるものではない例示により説明される。
【０００７】
ネットワークフォワーディングエレメントでデータプレーンの振る舞いを構成するための方法及び装置が記載される。１実施の形態では、本方法は、ネットワークエレメントのコントロールプレーン内でネットワークプロトコルのアプリケーションプログラミングインタフェース（ＡＰＩ）を利用したネットワークプロトコルスタック（プロトコルアプリケーション）から抽出されたプロトコルコンフィギュレーション情報を受信することを含んでいる。ひとたび、プロトコルコンフィギュレーション情報が受信されると、プロトコルコンフィギュレーション情報は、対応するコントロールプレーンのコントロールインタフェースを使用して処理される。
【０００８】
ひとたび、プロトコルコンフィギュレーション情報が処理されると、コントロールインタフェースは、受信されたプロトコルコンフィギュレーション情報に従って、ネットワークエレメントの１以上のデータプレーンフォワーディングエレメントをプログラムする。これに応じて、多数のネットワークプロトコルについて同様にコントロールインタフェースを提供することで、多数のベンダからのコンポーネント間の相互運用性が可能になる。結果として、ベンダの独立性が達成され、将来的なネットワークエレメントについて販売、改善された効率、より低いコスト及びより大きな革新のためのより迅速な時間が得られる。
【０００９】
以下の説明では、説明のため、本発明の実施の形態の全体的な理解を提供するため、様々な特定の詳細が述べられる。しかし、本発明の様々な実施の形態がこれら特定の詳細なしに実施される場合があることは当業者にとって明らかであろう。さらに、以下の説明は、本発明の実施の形態に関する全ての可能な実現の使い尽くされたリストを提供するよりはむしろ、可能な実施の形態及びその添付図面のサブセットを提供するものである。他の例では、公知の構造及び装置は、本発明の様々な実施の形態の詳細を曖昧にするのを回避するため、ブロック図の形式で示されている。
【００１０】
［システムアーキテクチャ］
図１は、インターネットを介してホストコンピュータ１４０（１４０−１，．．．，１４０−Ｎ）に結合されるインターネットホスト１０２を含んでいる、従来のネットワーク１００を説明するブロック図である。一般に、インターネットホスト１０２とホストコンピュータ１４０との間の情報のルーティングは、データパケットを転送するための従来の手段に従って実行される。インターネットホスト１０２から様々なホストコンピュータ１４０にインターネット内で様々なパケットが経路制御される。従来のパケット化された情報を送信するときにこのモデルは上手くいくが、マルチメディアアプリケーションと同様に、遠隔地間会議を含む様々なアプリケーションが登場しており、これらのアプリケーションは、従来のネットワーク内で受ける遅延に対して感度が高い。
【００１１】
結果として、かかるマルチメディア及びリアルタイムアプリケーションの出現は、図１に示されるようなネットワークを利用しており、変動するサービス品質（QoS:  Quality  of  Service）と同様に、ネットワークから利用可能なスイッチング、ルーティング等を改善するための要求を駆動している。同様に、様々な情報（パケット）は、ネットワーク１００を通して経路制御される場合があり、様々な特別なプロトコルアクティビティを必要とする場合がある。残念なことに、図１に示されるようなネットワークは、伝統的な最善努力サービスモデルを利用しており、このサービスモデルは、ネットワークトラフィックを処理するために帯域幅を前もって割り当てないが、最善の努力に基づいて現在利用可能な帯域幅を利用してパケットを単に経路制御する。結果として、変動する問合せの遅延及びインターネットに渡る混雑がかなり一般的である。
【００１２】
ネットワーク１００により実現される最善努力のサービスモデルは、伝送制御プロトコル（TCP:  Transmission  Control  Protocol）／インターネットプロトコル（IP:  Internet  Protocol）（ＴＣＰ／ＩＰ）に基づいている。プロトコルの実現は、インターネットプロトコル・バージョン４（ＩＰｖ４）を示している。一般に、ＩＰｖ４は、今日使用されている最も広く設けられているインターネットプロトコルのレベルである。当業者には知られているように、ＩＰアドレスは、インターネットにわたりパケットで送出される情報のそれぞれ送信側と受信側を識別する３２ビット数である。一般に、ＩＰアドレスは、インターネット上の特定のネットワークの識別子、及びネットワーク内の特定の装置の識別子という、２つのパートを有している。
【００１３】
かかるように、インターネットは、多くの個々のネットワークの相互接続であり、ＩＰｖ４は、ネットワークがその自身のインターネットアドレスを知っており、該ネットワークが通信する他のネットワークのインターネットアドレスを知っているという前提で、別のネットワークと通信する一方のネットワークのためのルールのセットである。残念ながら、ＩＰｖ４により規定される３２ビットのＩＰアドレスは、超えるに非常に近い。言い換えれば、インターネットの成長により、新たなアーキテクチャなしに、ＩＰｖ４により提供されるアドレス指定方法を使用した可能なネットワークアドレスの数を間もなく超える可能性があることである。同様に、現在のＴＣＰ／ＩＰにより提供される最善努力のサービスモデルは、様々な現在及び将来的なネットワーキングアプリケーションにとって不十分である。
【００１４】
これに応じて、次の世代のバージョンのインターネットプロトコルが実現されてきている。当業者には知られているように、この次の世代のインターネットプロトコルは、「インターネットプロトコル・バージョン６（ＩＰｖ６）」と呼ばれている。ＩＰｖ４に対するＩＰｖ６における最も明らかな実現は、ＩＰアドレスが３２ビットから１２８ビットに長くされていることである。結果として、この拡張により、インターネットのかなりの将来的な成長を期待することができ、ネットワークアドレスの差し迫った不足として認識されることについての軽減を提供する。さらに、ＩＰｖ６は、ユニキャスト（あるホストから別のホストへ）、エニーキャスト（あるホストから複数のホストのうちで最も近いホストへ）、及びマルチキャスト（あるホストから複数のホストへ）といった、３つのタイプのアドレス指定についてのルールを記述している。
【００１５】
さらに、ＩＰｖ６は、様々なエンハンスを提供している。たとえば、ＩＰｖ６は、他のネットワークトラフィックパケットと相対的に高いＱｏｓを必要とすると思われるパケットについて識別メカニズムを可能にする。言い換えれば、エンド・トゥ・エンドパス（すなわちフロウ）に属しているパケットは、たとえば、リアルタイムの到着を必要とするマルチメディアプレゼンテーションの一部として識別することができる。結果として、この識別を提供することで、リアルタイムデリバリを必要とするパケット、すなわち遅延に対する感度が高いパケットには、標準的なネットワークトラフィックに関して高いＱｏＳが与えられる。
【００１６】
たとえば、図２は、たとえばリアルタイムアプリケーションサーバ（ソースコンピュータ）２００とデスティネーションコンピュータ２２０との間の様々なネットワークエレメントを例示するために示される図１のネットワークを更に例示するブロック図である。ネットワークがたとえばＩＰｖ４ルーティングプロトコルに従って構成されているため、受信されたネットワークトラフィックは、ベストエフォートサービスモデルに基づいて送出される。結果として、リアルタイムアプリケーションサーバ２００とデスティネーションコンピュータ２２０との間にパケット化されたデータの転送は、インターネットにわたる混雑がインターネットの増加する広い使用の結果としてかなり一般的であるという事実のために様々なルーティング遅延を受ける。たとえば、ピーク時間の間、リアルタイムのパケット化されたデータの転送は、デスティネーションソースコンピュータで使用不可能なアプリケーションをレンダリングするため、多量の遅延を受ける。トラフィックフローについてサービス区分（変動するＱｏＳ）を提供するための現在のネットワークプロトコルは、ＤｉｆｆＳｅｒｖ（Differentiated  Services）モデルである。ＤｉｆｆＳｅｒｖモデルは、遅延限界のような困難な保証及び統合サービス（ＩｎｔＳｅｒｖ）モデルにより提供される帯域幅とは異なる集合体を流すための定量的な区分（qualitative  differentiation）を提供する。たとえば、ＤｉｆｆＳｅｒｖモデルにより提供された定量的な区分は、クラスＢよりも優先度が高いクラスＡを提供するために構成される場合がある。さらに、ＤｉｆｆＳｅｒｖモデルは、限定されるものではないが、分類子（classifiers）、メーター（meters）、ドロッパー（droppers）、キュー（queues）及びスケジューラ（schedulers）を含むデータパスエレメント（DPE:  Data  Pass  Element）を提供する。
【００１７】
たとえばオーディオ及びボイスアプリケーションのようなネットワーク内での待ち時間をなす遅延及び混雑に対して非常に感度が高いアプリケーションを実現するため、たとえば、ネットワークトラフィックを高速化するための利用される場合がある更なるネットワークプロトコルは、マルチプロトコルラベルスイッチングプロトコル（MPLS:  Multi-Protocol  Label  Switching）プロトコルである。ＭＰＬＳプロトコルは、その簡略化された管理と同様に、ネットワークトラフィックフローを高速化するための標準的に承認されている技術である。ＭＰＬＳは、それぞれのパケットに付されるラベルにより識別される所与のパケット系列のための特別のパスを設定することを含んでいる。結果として、パケットを転送するために次のノードへのアドレスを見るためにルータにとって一般に必要とされる時間が節約される。
【００１８】
さらに、ＭＰＬＳは、当業者には知られているように、インターネットプロトコル、非同期転送モード（ＡＴＭ）プロトコル、及びフレームリレーネットワークプロトコルと共に機能するので、マルチプロトコルと呼ばれている。さらに、ＭＰＬＳは、大部分のパケットがレイヤ３（ルーティング）レベルよりはむしろレイヤ２（スイッチング）レベルで送出されるのを可能にする。さらに、トラフィックを高速に移動することに加えて、ＭＰＬＳは、ネットワークのサービス品質（ＱｏＳ）及びトラフィックエンジニアリングの簡略化された管理を提供する。これに応じて、ＭＰＬＳプロトコルを実現するネットワークは、異なるネットワークトラフィックの混成に対して十分なサービス品質を提供することができる。本明細書で説明されたように、先に記載された各種ルーティング。スイッチング及びＱｏＳプロトコルは、「ネットワークプロトコル」と集合的に呼ばれる。
【００１９】
図３を参照して、図３は、図２に示されたように、ネットワーク３００内で利用される従来のネットワークエレメント３０２である。例示されるように、ネットワークエレメントは、コントロールプレーン３１０により示されるように、到来パケットを目的地に経路制御するための入力ファイバブロック３０４、転送決定ブロック３９０、及び出力ファイバブロック３０６を使用するフォワーディングプレーン３８０を含んでいる。残念なことに、ネットワークエレメント３０２は、１つの装置内で、堅く結合されるフォワーディング及びコントロールプレーンを提供する。結果として、ネットワークエレメント３０２内で、遅延に感度が高いアプリケーションにより必要とされるように、変動するＱｏＳを実現することは、該装置内で使用される適切なインタフェースの詳細な知識を一般に必要とする。
【００２０】
しかし、ネットワーキング産業における最近のトレンドは、よりプログラマブルな、パフォーマンス指向のネットワークプロセッサのようなネットワーク装置と従来のネットワークエレメントを置き換えることであり、これは比較的フレキシブルではない。残念なことに、ネットワークプロセッサは、一般にそれら初期のステージにあり、アブストラクトプログラミングモデルを有していないか、プロセッサ自身における進歩につれて成長するに十分に表現的かつフレキシブルなモデルを有していない。
【００２１】
一般に、スイッチ及びルータのようなネットワークエレメントは、コントロールプレーン、フォワーディングプレーン及びマネージメントプレーンといった、３つの論理的な動作コンポーネントに分類することができる。たとえば、コントロールプレーンは、異なるシグナリング又はルーティングプロトコルを実行し、全てのルーティング情報をフォワーディングプレーンに提供する。フォワーディングプレーンは、この情報に基づいて決定を行い、転送、分類、フィルタリング等のようなパケットに関する動作を実行する。直交するマネージメントプレーンは、コントロール及びフォワーディングプレーンを管理する。
【００２２】
しかし、上述されたプレーン内での標準化されたアプリケーションプログラミングインタフェース（ＡＰＩ）の導入により、これらのネットワークエレメントのシステムベンダ、ＯＥＭ及びエンドユーザは、彼らの装置の選択を達成するために異なるベンダから入手可能なコンポーネントを混成して整合させるのに役立たせることができる。これに応じて、図４は、本発明の１実施の形態に係る、相互接続４０２を介して互いに結合される個別のコントロールプレーン４１０及びデータプレーン４３０から構成されるネットワークエレメント４００を例示するブロック図である。
【００２３】
１実施の形態では、コントロールインタフェース４１０は、データプレーン４３０のフォワーディングエレメントをプログラムするために必要とされる情報を決定するためにデータプレーンの照会を可能にする。これにより、ネットワークフォワーディングエレメントにおける特定の振る舞いを制御することにおいて大きな程度の一般化が可能となる。本明細書で記載されるように、テーブルを生成し、それぞれのプロトコルを実現するためにそれらのエントリをポピュレートするための様々なパラメータ及び情報は、「プロトコルコンフィギュレーション情報（protocol  configuration  information）」と集合的に呼ばれる。
【００２４】
これに応じて、コントロールインタフェース４２０は、データプレーンのベンダソースにも関わらず、データプレーン４３０内で第三者のネットワークプロトコルスタック（プロトコルアプリケーション）を実現するため、選択されたデータプレーンフォワーディングエレメントをプログラムすることができる。１実施の形態では、コントロールインタフェース４２０は、該プロトコルに対応するＡＰＩによりプロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報に従ってデータプレーン４３０をプログラムする。たとえば、ネットワークエレメント４００は、アプリケーション４２４及び４２６を介して、ＭＰＬＳ及びＤｉｆｆＳｅｒｖネットワークプロトコル（「ネットワークプロトコル」）と同様に、ＩＰｖ４，ＩＰｖ６ルーティングプロトコルを実現するように例示されている。同様に、マネージメント／コンフィギュレーションアプリケーション４２２も提供される。
【００２５】
異なる第三者の開発者からの様々なプロトコルアプリケーションを可能にするため、本発明の１実施の形態は、たとえばＩＰｖ４ルーティングプロトコル、ＩＰｖ６ルーティングプロトコル、ＭＰＬＳネットワークプロトコル及びＤｉｆｆＳｅｒｖネットワークプロトコルを提供する。しかし、望まれる更なるプロトコルのための様々なＡＰＩは、本発明の実施の形態に従って実現される場合がある。これに応じて、本発明の実施の形態に係るＡＰＩを利用することで、第三者のプロトコルアプリケーションは、ベンダＢのデータプレーン内の第三者のソフトウェア開発者により望まれる特定のプロトコルを実現するため、ベンダＡのコントロールプレーンにロードされる場合がある。
【００２６】
１実施の形態では、コミュニケーションインターフェーシングは、データプレーン４３０内でのプロトコルの実現と同様に、それぞれのプロトコルＡＰＩにより処理される。言い換えれば、コントロールインタフェース４２０は、先に記載されたプロトコルについてＡＰＩを露出する。結果として、対応するＡＰＩを従来のプロトコルアプリケーションに組み込むことで、プラットフォームに独立なプロトコルアプリケーションが提供される。かかるように、１実施の形態では、対応するＡＰＩは、プロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報をコントロールプレーン４２０に提供する。
【００２７】
１実施の形態では、コントロールプレーン４２０は、このプロトコルコンフィギュレーション情報を使用して、プロトコルを実現するためにデータプレーン４３０のフォワーディングエレメントをプログラムする。さらに、コントロールインタフェース４２０とデータプレーン４３０との間の通信は、たとえば、相互接続メッセージプロトコル等を使用して達成される。たとえば、ＩＰｖ６ルーティングプロトコルは、フォワーディングエレメント４４０内で実現される場合がある。例示されるように、ＩＰｖ６フォワーディングテーブル（forwarding  table）は、ネイバーテーブル（neighbor  table）４６０もまた、装置のブートアップの間にフォワーディングエレメント４４０内で形成される。さらに、プロトコルコンフィギュレーション情報により指示されるように、インタフェース４４２を介して受信されたパケットの経路制御を指示するため、インタフェース特定テーブルのエントリ（４６２及び４６４）が生成され、それぞれのテーブル４６０内に取り込まれる。
【００２８】
同様に、ＭＰＬＳ、ＦＴＮ（ＮＨＬＦＥ（next  hop  label-forwarding  entry）へのＦＥＣ（forward  equivalence  class）、及びＩＬＭ（incoming  label  map）テーブルは、特定のエントリ４５２，４５４及び４５６をもつフォワーディングエレメント４４０内で実現される場合もある。特定のエントリは、インタフェース４４２を介して対応するパケットを受信したとき、フォワーディングエレメントの振る舞いを制御するため、対応するＬＤＰ（label  distribution  protocol）アプリケーションにより指示される。同様に、ＩＰｖ４ルーティングプロトコルは、ＤｉｆｆＳｅｒｖルーティングプロトコルと同様に、フォワーディングエレメント４７０内で実現される場合もある。
【００２９】
この能力は、１実施の形態において、コントロールインタフェース４２０がデータプレーン４３０内の多くの特定のエレメントのうちの１つをターゲットとするためのメカニズムを提供するという事実により提供される。すなわち、多数のフォワーディングエレメントのうちの１つエレメントのうちの、１以上のテーブルのうちの特定のテーブルのエントリがアドレス指定される場合がある。同様に、１実施の形態では、コントロールインタフェースは、コントロールプレーンのコンポーネント（プロトコルアプリケーション）にとって、データプレーンのパラメータ及び機能を決定するためのフォワーディングエレメントを照会するためのメカニズムを提供する。
【００３０】
これに応じて、図５は、本発明の１実施の形態に係る、図４に示されたようなネットワークエレメント４００を利用するネットワーク５００を例示するブロック図である。例示されるように、リアルタイムアプリケーションサーバ２００は、たとえば、ネットワークエレメント４００内のＤｉｆｆＳｅｒｖネットワークプロトコルにより提供される改善された／変動するＱｏＳを受信することができる。同様に、他の様々なソースコンピュータは、たとえば、ＩＰｖ４（レガシーアプリケーションについて）及びＩＰｖ６ルーティングプロトコル、ＭＰＬＳネットワーク等のような個別のルーティング／ネットワークプロトコルを必要とする。これらのプロトコルは、本発明の実施の形態に従って、対応するプロトコルＡＰＩを含むたとえば第三者のプロトコルアプリケーションを使用してネットワーク内で実現される場合がある。
【００３１】
さらに、ネットワークエレメント４００内のコントロールインタフェース４２０は、コントロールプレーンとデータプレーンとの間のいずれかの種類の相互接続技術をサポートするために本質的に完全な非同期であるように設計される。コントロールプレーンとデータプレーンは、イーサネット（登録商標）、ケーブルライン、バス又は光ファイバのようなネットワーク技術を使用して接続することができる。同様に、コントロールプレーンとデータプレーンとの間の接続は、コンパクトＰＣＩ（Peripheral  Component  Interconnect）のようなバステクノロジーを介して達成されるか、又はコントロールプレーンとデータプレーンは、同じ位置に配置され、プロセス間通信を介して接続される。ここで、本発明の実施の形態を実現するための手順的な方法が説明される。
【００３２】
［動作］
図６は、本発明の１実施の形態に係る、図４に示されるような、たとえばネットワークエレメント４００のネットワークフォワーディングエレメントによるデータプレーンの振る舞いを構成するための方法６００を説明するフローチャートである。プロセスブロック６０２で、プロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報は、ネットワークエレメントのコントロールプレーンで受信される。１実施の形態では、プロトコルアプリケーションは、プロトコルのアプリケーションプログラミングインタフェース（ＡＰＩ）を利用してネットワーク／ルーティングプロトコルを実現し、このＡＰＩは、プロトコルコンフィギュレーション情報を抽出するための責任を果たす。
【００３３】
１実施の形態では、プロトコルＡＰＩは、たとえば、ＤｉｆｆＳｅｒｖネットワークプロトコル、ＭＰＬＳネットワークプロトコル、ＩＰｖ４及びＩＰｖ６ルーティングプロトコルのようなネットワークプロトコルをサポートする。これに応じて、受信されたプロトコルコンフィギュレーション情報により規定されたそれぞれのプロトコルの実現は、アプリケーションプログラマから隠されている。ひとたび、プロトコルコンフィギュレーション情報のアプリケーションが受信されると、プロセスブロック６０４で、受信されたプロトコルコンフィギュレーション情報は、受信されたプロトコルアプリケーションにより実現されたプロトコルに対応するコントロールインタフェースを使用して処理される。
【００３４】
たとえば、図４を参照して示されるように、コントロールインタフェース４２０は、コントロールインタフェースＩＰｖ４、ＩＰｖ６、ＭＰＬＳ及びＤｉｆｆＳｅｒｖコントロールインタフェースから構成される。結果として、コントロールインタフェース４２０は、たとえば第三者の開発者から受信されたアプリケーションを処理するために対応するプロトコルインタフェースを決定する。かかるように、ひとたび選択されると、プロセスブロック６２０で、ネットワークエレメントの１以上のデータプレーンフォワーディングエレメントは、たとえば図４に例示されるように、プロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報に従ってプログラムされる。
【００３５】
図７は、本発明の１実施の形態に係る、図６に示されるような、プロセスブロック６０４での受信されたプロトコルコンフィギュレーション情報の処理のための方法６０６を例示するフローチャートである。プロセスブロック６０８で、コントロールインタフェースは、受信されたプロトコルコンフィギュレーション情報と関連されるネットワークルーティング又はノンルーティングプロトコルを実現するため、データプレーン内のフォワーディングエレメントを選択する。たとえば、コントロールインタフェース４２０は、ＩＰｖ６ルーティングプロトコルを実現するため、フォワーディングエレメント４４０を選択する。
【００３６】
つぎに、プロセスブロック６１０で、選択されたフォワーディングエレメント内の情報を要求する１以上のインタフェース特定テーブルが決定される。ひとたび、プロセスブロック６１２で決定されると、プロトコルコンフィギュレーション情報に従って、コントロールインタフェースによりインタフェース特定（プロトコル特定）テーブル内の１以上のエントリが決定される。結果として、インタフェース特定テーブルを含むフォワーディングエレメントは、インタフェース特定テーブル内のエントリに従ってルーティングの決定を確定する。たとえば、ＩＰｖ６テーブル４６０のエントリ１及び２に加えてＭＰＬＳテーブル４５０のエントリ１−３が決定される。
【００３７】
図８は、本発明の１実施の形態に係る、図６に示されるような、プロセスブロック６２０のデータプレーンフォワーディングエレメントをプログラミングするための方法６２２を説明するフローチャートである。プロセスブロック６２４では、データプレーンにより提供されるプロトコル機能を照会した後、プロトコルコンフィギュレーション情報により規定されるネットワークプロトコルは、データプレーンからイベントの受信を可能にするために装置のブートアップの間、データプレーンに登録される。言い換えれば、フォワーディングエレメントでの各種の処理の間、実現されるプロトコルは、データプレーンでのその後の処理の振る舞いを決定するため、コントロールプレーンへの通信を必要とするイベントをトリガする場合がある。
【００３８】
プロセスブロック６２６では、コントロールインタフェースは、たとえばフォワーディングエレメント４４０（図４）のようなネットワークデータプレーンのうちの１以上のフォワーディングエレメントからフォワーディングエレメントを選択する。つぎに、プロセスブロック６２８では、デバイスのブートアップで選択されたフォワーディングエレメントで発生される１以上のインタフェース特定テーブルが選択される。プロセスブロック６３０でひとたび選択されると、コントロールインタフェースは、対応するプロトコルＡＰＩにより受信されたプロトコルアプリケーションから抽出されたプロトコルコンフィギュレーション情報により指示されるように、選択されたフォワーディングエレメントのインタフェース特定テーブルの１以上のエントリを発生する。
【００３９】
図９は、本発明の１実施の形態に係る、ＩＰｖ４ルーティングプロトコルを実現するため、図６に示されるような、プロセスブロック６２０のデータプレーンの振る舞いをプログラミングする方法６３２のためのフローチャートである。プロセスブロック６３４では、ＩＰｖ４ルーティングプロトコルは、データプレーンからイベントの受信を可能にするため、装置のブートアップの間にネットワークエレメントのデータプレーンに登録される。プロセスブロック６３６では、ＩＰｖ４フォワーディングテーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで選択されたフォワーディングエレメントで選択される。プロセスブロック６３８では、アドレスレソリューション（ＡＲＰ）テーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで生成される。
【００４０】
つぎに、プロセスブロック６４０では、データプレーンでのフォワーディングエレメントは、ＩＰｖ４ルーティングプロトコルを実現するために選択される。プロセスブロック６４２では、要求がプロトコルアプリケーションから受信されたかが判定され、この要求は、ルート更新要求及びＡＲＰ更新要求を含んでいる場合がある。ルート要求が受信されたとき、プロセスブロック６４４で、ＩＰｖ４ルーティングエントリは、受信された更新要求に従ってフォワーディングテーブルで追加又は削除のいずれかされる。ＡＲＰ要求が受信されたとき、プロセスブロック６４６で、ＩＰｖ４エントリは、受信された要求に従ってアドレスレゾリューションテーブルで追加又は削除される。これに応じて、プロセスブロック６４２〜６４６は、フォワーディングエレメントのプログラミングが完了するまで繰り返される。
【００４１】
図１０は、本発明の１実施の形態に係る、ＩＰｖ６ルーティングプロトコルを実現するため、図６に示されるような、プロセスブロック６２０のデータプレーンをプログラミングするための方法６５０を説明するためのフローチャートである。プロセスブロック６５２では、ＩＰｖ６ルーティングプロトコルは、先に示されたように、データプレーンからのイベントの受信を可能にするため、装置のブートアップの間にデータプレーンで登録される。プロセスブロック６５４では、ＩＰｖ６フォワーディングテーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで生成される。ひとたびプロセスブロック６５６で選択されると、ＩＰｖ６ネイバーテーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで生成される。
【００４２】
つぎに、プロセスブロック６５８で、フォワーディングエレメントは、ネットワークエレメントのデータプレーンから選択される。プロセスブロック６６では、要求がプロトコルアプリケーションから受信されたかが判定され、この要求は、ルート更新要求及びネイバーテーブル更新要求を含んでいる場合がある。ルート要求が受信されたとき、プロセスブロック６６２では、ＩＰｖ６ルーティングエントリは、受信された要求に従ってフォワーディングテーブルで追加又は削除される。ネイバーテーブル更新要求が受信されたとき、プロセスブロック６６４では、ＩＰｖ６ネイバーエントリは、受信された要求に従ってネイバーテーブルに追加又は削除される。これに応じて、プロセスブロック６６０〜６６４は、フォワードエレメントのプログラミングが完了するまで繰り返される。
【００４３】
図１１は、本発明の１実施の形態に係る、ＭＰＬＳネットワークプロトコルを実現するため、図６に示されるような、プロセスブロック６２０でのデータプレーンのフォワードエレメントをプログラミングするための方法６７０を説明するフローチャートである。プロセスブロック６７２では、ＦＴＮテーブルがＭＰＬＳスイッチングプロトコルを実現するため、装置のブートアップの間に、選択されたフォワーディングエレメントで生成される。プロセスブロック６７４では、ＩＬＭテーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで生成される。つぎに、プロセスブロック６７６では、ＦＴＮ  ＤｉｆｆＳｅｒｖコンテクストテーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで生成される。
【００４４】
ひとたび生成されると、プロセスブロック６７８では、ＩＬＭ  ＤｉｆｆＳｅｒｖコンテクストテーブルは、装置のブートアップの間に選択されたフォワーディングエレメントで発生される。ひとたび生成されると、プロセスブロック６８０では、プロトコルアプリケーション要求が受信されたかが決定される。ＦＴＮ要求が受信されたとき、プロセスブロック６８２及び６８４が実行される。しかし、ＩＬＭ要求が受信されたとき、プロセスブロック６８６及び６８８が形成される。さもなければ、制御フローは、プロセスブロック６２０（図６）に戻り、これは、データプレーンのフォワーディングエレメントのプログラミングがそれぞれのプロトコルアプリケーション要求のためのプロセスブロック６８０−６８８の繰返しにより完了されると一般に生じる。
【００４５】
これに応じて、プロセスブロック６８２では、ＭＰＬＳ  ＦＴＮエントリは、ＭＰＬＳ  ＦＴＮエントリの要求が受信されたとき、ＦＴＮテーブルで追加又は削除される。同様に、プロセスブロック６８４では、ＭＰＬＳ  Ｅ−ＬＳＰ（explicit  route  label  switch  path）コンフィギュレーションのエントリは、ＭＰＬＳ  Ｅ−ＬＳＰコンフィギュレーションのエントリ要求が受信されたとき、ＦＴＮ  ＤｉｆｆＳｅｒｖコンテクストテーブルで追加又は削除される。さもなければ、プロセスブロック６８６で、ＭＰＬＳ  ＩＬＭエントリは、ＭＰＬＳ  ＩＬＭエントリ要求が受信されたときにＩＬＭテーブルで追加又は削除される。同様に、プロセスブロック６８６では、ＭＰＬＳ  Ｅ−ＬＳＰプレコンフィギュレーションエントリは、ＭＰＬＳ  Ｅ−ＬＳＰプリコンフィギュレーションのエントリ要求が受信されたときに、ＩＬＭ  ＤｉｆｆＳｅｒｖコンテクストテーブルに追加又は削除される。
【００４６】
図１２は、本発明の１実施の形態に係る、ＤｉｆｆＳｅｒｖネットワークプロトコルを実現するため、図６に示されるような、プロセスブロック６２０のデータプレーンフォワーディングエレメントをプログラミングするための方法６９０を説明するためのフローチャートである。プロセスブロック６９２では、複数のＤｉｆｆＳｅｒｖテーブルは、装置のブートアップの間、たとえばＤｉｆｆＳｅｒｖ  ＤＰＥであるＤｉｆｆＳｅｒｖルーティングプロトコルを実現するために選択されたフォワーディングエレメントで生成される。１実施の形態では、それぞれのコール（プロトコルアプリケーション要求）は、以下のタイプのうちの１つのエントリを含んでいる。フィルタ、メーター、マーカー、キュー又はスケジューラ。プロセスブロック６９４では、フィルタエントリは、分類子テーブルのエントリ要求が受信されたときＤｉｆｆＳｅｒｖ分類子テーブルで追加又は削除される。プロセスブロック６９６では、ＤｉｆｆＳｅｒｖメーターテーブルでのメーターエントリは、メーターエントリ要求が受信されたとき追加、変更又は削除される。
【００４７】
さらに、プロセスブロック６９８では、ＤｉｆｆＳｅｒｖマーカーテーブルでのマーカーエントリは、マーカーテーブルのエントリ要求が受信されたときに追加、変更又は削除される。プロセスブロック７００では、ドロッパーエントリは、ドロッパーエントリ要求が受信されたとき、選択されたフォワーディングエレメントで生成されたＤｉｆｆＳｅｒｖアルゴリズムのドロッパーテーブルで追加、変更又は削除される。プロセスブロック７０２では、ＤｉｆｆＳｅｒｖキューでのキューエントリは、キューのエントリ要求が受信されたときに追加、変更又は削除される。最後に、プロセスブロック７０４では、ＤｉｆｆＳｅｒｖスケジューラテーブルでのスケジューラエントリは、スケジューラテーブルのエントリ要求が受信されたときに追加、変更又は削除される。
【００４８】
最後に、図１３は、本発明の１実施の形態に係る、たとえばコントロールインタフェースを実現するネットワークエレメントの振る舞いのための方法７１０を説明するフローチャートである。プロセスブロック７１２では、パケットが受信されたかが判定される。プロセスブロック７１４でひとたび受信されると、「プロトコルがサポートされていない」イベントのような受信されたパケットによりイベントがトリガされたかが判定される。イベントがトリガされたとき、プロセスブロック７１６が実行される。プロセスブロック７１６では、フォワードエレメントアプリケーションは、受信されたパケットに対応するネットワークプロトコルを実現するものであって、イベントが通知される。１実施の形態では、通知は、責任のあるフォワーディングエレメントに受信されたパケットを転送することを含んでいる場合がある。
【００４９】
さもなければ、プロセスブロック７１８では、該パケットと関連されるネットワークプロトコルに対応する１以上のインタフェース特定テーブルでプログラムされたフォワーディングエレメントが決定される。ひとたび決定されると、プロセスブロック７２０では、「エントリが失われている／エントリが見つからない」イベントのような、テーブルのルックアップによりイベントがトリガされているかが判定される。イベントがトリガされたとき、プロセスブロック７２２が実行される。プロセスブロック７２２では、受信されたパケットに対応するネットワークプロトコルを実現するフォワードエレメントアプリケーションにはイベントが通知される。１実施の形態では、「エントリが見つからない」イベントは、フォワーディングエレメントにより受信されたパケットのＤＲＯＰアクションを引き起こす。
【００５０】
さもなければ、プロセスブロック７２４では、フォワーディングエレメントは、該パケットと関連されるネットワークプロトコルに対応するエントリであって、対応するプロトコルコンフィギュレーション情報に従ってポピュレートされるインタフェース特定テーブルのエントリに従ってパケットを処理する。１実施の形態では、コントロールプレーンとデータプレーンとの間の通信は、たとえば、当該技術分野にて知られているように、インターコネクトメッセージングプロトコルを介して提供される。代替的な実施の形態では、コントロールプレーンとデータプレーンとの間の更なるメッセージング又は通信プロトコルが利用される場合がある。
【００５１】
これに応じて、本発明の実施の形態を利用して、たとえばネットワークプロセッサのための第三者のプロトコルアプリケーションの開発は、ネットワークプロセッサのようなフォワーディングエレメントのコントロールプレーン又はデータプレーンエレメントのいずれかのベンダソースに関わらず実現される場合がある。言い換えれば、本発明の実施の形態に係る、コントロールインタフェース及び対応するＡＰＩの使用により、改善された変動するサービス品質を複数の変動するネットワークトラフィックに提供するためにネットワークエレメントを実現するための複数のベンダのコンポーネント間の相互運用性を可能にする。
【００５２】
これに応じて、データプレーンでのネットワーク／ルーティングプロトコルの実現を第三者のプロトコルアプリケーションの開発者から分離することで、プラットフォームの独立性が達成される。改善された効率及び低コスト及び高い斬新さをもつ製品の販売に対して迅速な時間が得られる。さらに、提供されるコントロールインタフェースは、コントロールプレーンとデータプレーンとの間でいずれかの種類のインターネットの相互接続技術サポートするため、本来完全に非同期であるように設計される。結果として、コントロールプレーンとデータプレーンは、たとえばＥｔｈｅｒｎｅｔ（登録商標）ファイバのようなネットワーク技術を使用して接続することができる。
【００５３】
同様に、コントロールプレーンとデータプレーンとの間のコネクション（相互接続リンク）は、コンパクトＰＣＩのようなバステクノロジーを介して行うことができるか、又はコントロールプレーン及びデータプレーンは、同じ位置に配置され、プロセス間通信を介して接続される。さらに、コントロールインタフェースは、ネットワークプロセッサのデータプレーンでＩＰｖ４／ＩＰｖ６／ＭＰＬＳ／ＤｉｆｆＳｅｒｖの振る舞いを構成するため、使用するのが容易であって、スケーラブルかつロバスト性の高いインタフェースを提供する。１実施の形態では、マネージメント、アプリケーション及びコントロールプレーンで実行するルーティング／ＭＰＬＳ／Ｑｏｓアプリケーションのため、たとえばカリフォルニア州サンタクララにあるインテル社により製造されるようなネットワークプロセッサが使用される。さらに、第三者のルーティングスタック及びマネージメントアプリケーションの統合もまた、本発明の実施の形態に従ってコントロールインタフェースを利用して容易に実現される。
【００５４】
［代替的な実施の形態］
複数のデータプレーンの振る舞いを構成するためのコントロールインタフェース及びＡＰＩの１実現の幾つかの態様が記載される。しかし、コントロールインタフェース及びＡＰＩの様々な実現は、先に記載された機能を補足、補充、及び／又は置換することを含む様々な機能を提供する。機能は、コントロールプレーンの一部として、又は異なる実施の形態の実現におけるネットワークエレメントの一部として実現することができる。さらに、上述された記載は、説明のために、本発明の実施の形態の全体的な理解を提供するために特定の用語が使用されている。しかし、本発明の実施の形態を実施するため、特定の詳細が必要とされていないことは、当業者にとって明らかであろう。
【００５５】
さらに、本明細書で記載される実施の形態は、ネットワークエレメントのコントロールインタフェース及びＡＰＩに向けられるが、本発明の実施の形態は、他のシステムに適用することもできることは当業者により理解されるであろう。実際に、特許請求の範囲により定義されるように、ネットワークエレメントで多数のプロトコルをサポートするためのシステムは、本発明の実施の形態に含まれる。先に記載された実施の形態は、本発明の実施の形態の原理及びその実用的な用途を最良に説明するために選択及び記載された。これらの実施の形態は、当業者が本発明を最良に利用するのを可能にするために選択され、様々な変更による様々な実施の形態は、予想される特定の使用に適している。
【００５６】
なお、本発明の様々な実施の形態の様々な特徴及び利点は、本発明の様々な実施の形態の構造及び機能の詳細と共に、上述された記載で述べられたが、この開示は例示的なものであることが理解される。あるケースでは、所定のサブアセンブリのみが１つのかかる実施の形態で詳細に記載される。しかし、かかるサブアセンブリは本発明の他の実施の形態で使用される場合があることが認識及び意図される。特に、本発明の実施の形態の原理での構造及び部材のマネージメントの事項が特許請求の範囲で表現される用語の広く一般的な意味により示される十分な範囲にまで、変形を詳細に行うことができる。
【００５７】
例示的な実施の形態及び最良のモードが開示されたが、特許請求の範囲により定義される本発明の実施の形態の範囲のままで、変更及び変形が開示された実施の形態に対してなされる場合がある。
【図面の簡単な説明】
【００５８】
【図１】当該技術分野で知られている従来のコンピュータネットワークを例示するブロック図である。
【図２】図１に示される従来のコンピュータネットワークを例示するブロック図であり、従来技術で知られているネットワーク内でパケットを経路制御するために利用される様々なネットワークエレメントを更に例示する図である。
【図３】図２に示される従来のネットワーク内で利用される従来のネットワークエレメントを例示するブロック図である。
【図４】本発明の１実施の形態に係る、ネットワークエレメントを例示するブロック図である。
【図５】本発明の１実施の形態に係る、図４に示されるネットワークエレメントを利用したコンピュータネットワークの図である。
【図６】本発明の１実施の形態に係る、ネットワークフォワーディングエレメントでデータプレーンの振る舞いを形成するための方法を説明するフローチャートである。
【図７】本発明の１実施の形態に係る、受信されたコンフィギュレーション情報により実現されるネットワークプロトコルに対応するコントロールインタフェースを使用して受信されたコンフィギュレーション情報を処理するための方法を説明するフローチャートである。
【図８】本発明の１実施の形態に係る、ネットワークプロトコルに従って１以上のデータプレーンのフォワーディングエレメントをプログラミングするための方法を説明するフローチャートである。
【図９】本発明の１実施の形態に係る、ＩＰｖ４（Internet  Protocol  version  4）ルーティングプロトコルに係る１以上のデータプレーンのフォワーディングエレメントをプログラミングするための方法を説明するフローチャートである。
【図１０】本発明の１実施の形態に係る、ＩＰｖ６（Internet  Protocol  version  6）ルーティングプロトコルに係る１以上のデータプレーンフォワーディングエレメントをプログラミングするための方法を説明するフローチャートである。
【図１１】本発明の１実施の形態に係る、ＭＰＬＳ（Multi-protocol  label  switching）プロトコルに係る１以上のデータプレーンフォワーディングエレメントをプログラミングするための方法を説明するフローチャートである。
【図１２】本発明の１実施の形態に係る、ＤｉｆｆＳｅｒｖ（Differentiated-Services）プロトコルに係る１以上のデータプレーンフォワーディングエレメントをプログラミングするための方法を説明するフローチャートである。
【図１３】本発明の１実施の形態に係る、ルーティングプロトコルを実現するためのコントロールプレーンのコントロールインタフェースに従ってプログラムされるフォワーディングエレメント内で受信されたパケットを処理するための方法を説明するためのフローチャートである。
【符号の説明】
【００５９】
４００：ネットワークエレメント
４１０：コントロールプレーン
４３０：データプレーン
４４０：フォワーディングエレメント１
４７０：フォワーディングエレメント２
４２６：ＩＰｖ４／ＩＰｖ６ルーティングアプリケーション
４２４：ＭＰＬＳ／ＤｉｆｆＳｅｒｖアプリケーション
４２２：マネージメント／コンフィギュレーションアプリケーション
４２０：ＩＰｖ４／ＩＰｖ６／ＭＰＬＳ／ＤｉｆｆＳｅｒｖコントロールインタフェース
４６０：ＩＰｖ６フォワーディング／ネイバーテーブル
４５０：ＭＰＬＳ  ＦＴＮ／ＩＬＭテーブル
４８０：ＩＰｖ４  ＰＲＥＦＩＸ／ＮＥＸＴ  ＨＯＰテーブル
４９０：ＤｉｆｆＳｅｒｖ  ＰＨＢテーブル
【図１】
2008125116.tif 000003
【図２】
2008125116.tif 000004
【図３】
2008125116.tif 000005
【図４】
2008125116.tif 000006
【図５】
2008125116.tif 000007
【図６】
2008125116.tif 000008
【図７】
2008125116.tif 000009
【図８】
2008125116.tif 000010
【図９】
2008125116.tif 000011
【図１０】
2008125116.tif 000012
【図１１】
2008125116.tif 000013
【図１２】
2008125116.tif 000014
【図１３】
2008125116.tif 000015