JP5219842B2 - プロトコル回線レイヤ - Google Patents

Description

関連出願の相互参照
本出願は、２００６年２月１日出願の「プロトコル回線レイヤ」と題する米国仮特許出願第６０／７６３，９７７号の利益を主張し、そして２００６年２月１日出願の「プロトコルリンクレイヤ」と題する米国仮特許出願第６０／７６３，９５９号、及び２００６年２月１日出願の「ＣＳＭＡ方式伝送媒体における輻輳管理及び遅延予測」と題する米国仮特許出願第６０／７６４，０１３号に関連する。

コンピュータをネットワーク化することによりデータをコンピュータ間で数十年間に亘って授受してきている。一つの重要なネットワークであるインターネットは、通信チャネルで相互接続される非常に多くのコンピュータ及びコンピュータネットワークを含む。インターネットは、電子商取引、電子メールのような情報交換、情報の抽出及び調査の実施などを含む種々の理由により使用される。多くの規格が、情報をインターネット経由で授受するために設定され、規格として、電子メール、ゴーファー（Ｇｏｐｈｅｒ），及びワールドワイドウェブ（ＷＷＷ）を挙げることができる。ＷＷＷサービスによって、サーバコンピュータシステム（すなわち、ウェブサーバまたはウェブサイト）は情報をグラフィカルなウェブページの形でリモートクライアントコンピュータシステムに送信することができる。従って、リモートクライアントコンピュータシステムはウェブページを表示することができる。ＷＷＷの各リソース（例えば、コンピュータまたはウェブページ）は、ユニフォームリソースロケータ（ＵＲＬ）によって一意に特定することができる。特定のウェブページを閲覧するために、クライアントコンピュータシステムは、当該ウェブページに対応するＵＲＬをリクエスト（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエスト）として指定する。リクエストは、ウェブページをサポートするウェブサーバに転送される。当該ウェブサーバがリクエストを受信すると、サーバはリクエストされたウェブページをクライアントコンピュータシステムに送信する。クライアントコンピュータシステムが当該ウェブページを受信すると、クライアントコンピュータシステムは通常、ブラウザを使用してウェブページを表示する。ブラウザは通常、ウェブページをリクエストし、そして表示する特定用途向けプログラムである。

現在、ウェブページは多くの場合、ハイパーテキストマークアップ言語（ＨＴＭＬ）を使用して記述される。ＨＴＭＬには一連の標準のタグが使用され、これらのタグは、ウェブページを表示する方法について記述する。ユーザがリクエストをブラウザに対して行なってウェブページを表示させる場合、ブラウザはリクエストをサーバコンピュータシステムに送信し、サーバコンピュータシステムに、ウェブページを記述するＨＴＭＬドキュメントをクライアントコンピュータシステムに転送させる。リクエストされたＨＴＭＬドキュメントをクライアントコンピュータシステムが受信すると、ブラウザは、ＨＴＭＬドキュメントに記述されたウェブページを表示する。ＨＴＭＬドキュメントは種々のタグを含み、これらのタグで、テキスト、グラフィックス、コントロール、及び他の機能の表示を制御する。ＨＴＭＬドキュメントには、当該サーバコンピュータシステムで、または他のサーバコンピュータシステムで利用することができる他のウェブページのＵＲＬが含まれる。

拡張可能マークアップ言語（ＸＭＬ）及びワイヤレスアクセスプロトコル（ＷＡＰ）のような新規のプロトコルが存在する。ＸＭＬはＨＴＭＬよりも高いフレキシビリティを持つ。ＷＡＰは種々の機能の中でもとりわけ、ウェブページを、携帯電話機及び携帯型コンピュータ（例えばＰＤＡ）のような携帯型無線機器で閲覧する機能を実現する。これらのプロトコルの全てが、情報を人々に種々のデータ処理装置を介して提供する手段を容易にするように機能する。データをデータ処理装置の間で授受する多くの他のプロトコル及び手段が継続的に開発されることにより、情報の授受が更に容易になる。

本文における回線レイヤ
ＣｏＣｏプロトコルは、ユーザと物理インターフェースとの間を仲介する４つのレイヤを含む。これらのレイヤは、
・リンクレイヤ
・ルーティングレイヤ
・回線レイヤ
・ネーミングシステムレイヤ
である。

図１はこれらのレイヤの関係を示している。
回線レイヤは全ての他のプロトコルレイヤだけでなく、ユーザアプリケーションと相互作用することができるので、回線レイヤはこれらのレイヤの中で中心的な役割を果たす。図２は、回線レイヤと他のレイヤとの間のインターフェースを示し、相互作用を更に明示的に示している。回線レイヤは回線を設定する場合に、ルーティングレイヤを使用して最適ルートを求める。回線レイヤはリンクレイヤを使用して、データパケットをリンク経由で他のネットワークノードに送信する。ネーミングレイヤは回線を使用して、ネットワークノードアドレスと、これらのアドレスのネットワークロケーションとの関連付けを行なう分散データベースを構築する。ユーザアプリケーションは回線レイヤを使用してリモートネットワークノードとのエンドツーエンドネットワーク接続を確立する。

回線の抽象化
回線は、データのエンドツーエンドのフロー、すなわちネットワーク送信元からネットワーク送信先に達する接続を表わすプログラミング抽象化である。送信元及び送信先は、＜ｓｅｒｖｉｃｅ， ｎｏｄｅ＞ペアによって表わされる。すなわち、＜ｓｅｒｖｉｃｅ， ｎｏｄｅ＞ペアは、特定ノードで実行されるサービスを指す。サービスは、ＦＴＰまたはテルネットのようなインターネットプロトコル規格とすることができるが、音声及びビデオストリームアプリケーションを含むこともできる。サービスネームは広く用いられる必要があるので、いずれかの一連のＣｏＣｏネットワークが統合されている場合には、サービスがかち合うことがなく、大規模な統合ネットワークで相互運用される。本文では、ウェルノウンサービスは、インターネットプロトコルのウェルノウンポートに関する表記に類似する。例えば、テルネットにはポート２３を使用する。インターネット協会（ＩＳＯＣ）によって認可されている組織であるインターネット割り当て番号機関（ＩＡＮＡ）は、固有パラメータ値をインターネットプロトコルに割り当てる中央調整機関である。現在、ココ・コミュニケーションズ・コーポレーションがこのサービスを提供している。一旦、ＣｏＣｏプロトコルが、認知された規格制定団体によって承認されると、ココ・コミュニケーションズはこの役割を同様の機関に移譲する。

送信元ノード、送信元サービス、送信先ノード、及び送信先サービスは、ネットワーク全体を通じて回線を一意に特定するので、回線は、
＜ｓｏｕｒｃｅ ｎｏｄｅ， ｓｏｕｒｃｅ ｓｅｒｖｉｃｅ， ｄｅｓｔｉｎａｔｉｏｎ ｎｏｄｅ， ｄｅｓｔｉｎａｔｉｏｎ ｓｅｒｖｉｃｅ＞
の４タプルによって特定することができる。

或る回線の送信元及び送信先は通常、同じ種類のサービスを使用することになるが、或る回線を送信元サービス及び送信先サービスの両方を使用して指定することによって、複数の接続が同じ種類のサービスに対応する２つのノードの間で可能になる。例えば、一つよりも多くのＦＴＰ（ファイル転送プロトコル）セッションを同時に、同じクライアントとサーバコンピュータとの間で、異なる送信元サービス（一つのサービスが真のサービスであり、他のサービスはダミーの複製サービスである）を指定することにより確立することができる。

回線は単方向性である。ユーザアプリケーションが２ウェイ通信を必要とする場合、ユーザアプリケーションは或る回線を各方向に設定する必要がある。或る回線は複数の経路を辿り、そして当該回線では、回線が使用するいずれの経路も経時的に調整することにより、変化するネットワーク状態を図３に示すように受け入れることができる。一例として、ノードＢとＮとの間、及びノードＮとＤとの間の直接のネットワーク接続のようなｈｅｎネットワーク接続は利用することができず（図３の例におけるように）、他のルートを選択することができる。

各ネットワークノードは、当該ノードを通過する回線の存在及びステータスに関するステータス情報を維持する。回線は、ユーザアプリケーション及びネーミングシステムレイヤからのリクエスト時に設定され、そして展開される。

回線の内、単一のリンクを通過する部分はレッグ（ｌｅｇ）と呼ばれ、そしてレッグの集合体が一つの回線を構成する。次の節では、レッグについて詳細に議論する。
レッグ（ｌｅｇｓ）
図４は、一つの回線レッグを示すブロック図である。一つの回線の一つのレッグは隣接ノードの間の単一ホップであり、単一ホップは、一つの回線の経路の一部分である。一つのレッグは上流ノード及び下流ノードを有し、これらのノードは一ホップだけ離れている。構造上、上流ノードを回線の送信元に近い方に位置させ、そして下流ノードを回線の送信先ノードに近い方に位置させる。回線設定の詳細は、「回路制御プロセス」と題する節において説明されている。

図５は、ネットワークパケットの方向性を示すブロック図である。全てのユーザデータ及び或る制御データが一つのレッグを経由して、上流ノードから下流ノードに流れる。データフローの方向は、順方向または下り方向と表記される。或る制御データは、逆方向または上り方向と呼ばれる反対方向に流れる。「回線制御パケット」と題する節では、データ制御パケットのパケットフォーマットについて説明する。

レッグの上流ノードから眺めると、レッグは発信レッグと呼ばれる。下流ノードから眺めると、レッグは着信レッグと呼ばれる。
ノード
いずれの回線の送信元ノード及び送信先ノードもエンドポイントと呼ばれる。全ての中間ノードは中継ポイントと呼ばれる。

図６では、ノードＷが送信元ノードであり、そしてノードＺが送信先ノードであり、これらのノードがエンドポイントである。ノードＸ，Ａ，Ｂ，Ｎ，Ｃ，Ｄ，及びＹは中継ポイントである。各エッジに沿った矢印は流れの方向を示す。

図７は、２つの異なる回線に対応する回線送信先エンドポイントとして機能するノードを示し、各回線は別のサービスに接続される。
識別情報
一つの回線に関する唯一の識別情報は当該回線の４タプル、
＜ｓｏｕｒｃｅ ｎｏｄｅ， ｓｏｕｒｃｅ ｓｅｒｖｉｃｅ， ｄｅｓｔｉｎａｔｉｏｎ ｎｏｄｅ， ｄｅｓｔｉｎａｔｉｏｎ ｓｅｒｖｉｃｅ＞
である。

各レッグは、ＬｏｃａｌＬｅｇＩＤとして知られる識別子を有し、この識別子は、同じ２つのノードの間の同じリンクを同じ方向に向かう全ての他のレッグに関して一意とする必要がある。ＬｏｃａｌＬｅｇＩＤによって一つのレッグが完全に指定される訳ではない。各ＬｏｃａｌＬｅｇＩＤはリンク及び＜ｕｐｓｔｒｅａｍ ｎｏｄｅ， ｄｏｗｎｓｔｒｅａｍ ｎｏｄｅ＞ペアを特定する。例えば、
・異なる方向に向かい、かつ同じＬｏｃａｌＬｅｇＩＤを有する２つのレッグは同じレッグではなく、２つの異なるレッグであり、各レッグは異なる回線に属する。
・同じノードから異なる送信先ノードに向かい、異なるリンクから出て行き、かつ同じＬｏｃａｌＬｅｇＩＤを持つ２つのレッグも同じレッグではない。

従って、一つのノードに入力する方向に向かう一つのレッグは、当該レッグのＬｏｃａｌＬｅｇＩＤによってのみ指定されるのではない。一つのレッグを一意に指定するためには、一つのリンク、及び当該リンクの方向も必要となり（３倍の長さの形式＜ｄｉｒｅｃｔｉｏｎ，ＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ）、この場合、ｄｉｒｅｃｔｉｏｎは着信または発信のいずれかとすることができる。同じ回線の異なるレッグは、異なるＬｏｃａｌＬｅｇＩＤ値を有することができるので、ＬｏｃａｌＬｅｇＩＤによって一つの回線が完全に決定される訳ではない（異なるＬｏｃａｌＬｅｇＩＤ値がローカルレッグ識別子と呼ばれる所以である−識別子は、特定ノードに固有の回線レッグを指す）。

拡張
回線拡張は、特殊要件を持つ回線を処理する機構である。回線拡張の２つの例は、
・エンドツーエンド暗号化を必要とする回線
・音声品質のような特定のＱｏＳ要件を満たす必要のある回線
である。

回線拡張は、ルーティングを含む回線動作に影響を与えることができる。回線拡張は、中継ポイント及びエンドポイントの両方に任意に用いることができるか、または必要である。例えば、暗号化拡張にはエンドポイントが暗号化をサポートする必要があるが、中継ポイントはその必要はない。なぜならば、各中継ポイントは当該ポイントの発信レッグで、当該ポイントが当該ポイントの着信レッグで受信するものを単に送信するだけだからである。これとは異なり、音声品質ＱｏＳ拡張を行なう回線では、各中継ポイントが着信レッグ及び発信レッグに十分に広い帯域を持たせてエンドツーエンド音声要件を満たす必要がある。

全てのノードが拡張をそれぞれ実行する必要がある訳ではないが、一つの回線が特定の拡張を必要とする場合には、当該拡張をサポートしないどのノードも、当該回線に使用することができない。回線には、拡張をサポートしないノードを、当該拡張が当該回線に任意に用いられる場合に使用することができる。この場合、ノードは当該ノードのデフォルト動作を用いる。拡張が必要であり、かつノードが当該拡張をサポートしない場合、回線は設定されないことになる。

各拡張は固有の公知の番号に関連付けられ、この番号はＩＰの公知のポートに類似する。
回線制御パケット
６つの異なる回線パケットが存在し、これらのパケットの内の３つのパケットだけが、順方向に、または下り方向にレッグで伝送され、そしてこれらのパケットの内の３つのパケットだけが、逆方向に、または上り方向に伝送される。

順方向回線パケットは、
・回線を経由して実際のユーザデータを移動させる、ＣＤＡＴ（回線データ）パケット
・回線を設定する、ＣＥＳＴ（回線設定）パケット
・回線を閉鎖する、ＣＣＬＳ（回線閉鎖）パケット
を含む。

逆方向回線パケットは、
・回線設定の確認応答を返す、ＣＡＣＫ（回線確認応答）パケット
・回線を拒否するか、または障害を通知する、ＣＲＳＴ（回線リセット）パケット
・回線が不明であること、または回線が在ることを忘れ去られていたことを通知する、ＣＵＮＫ（回線不明）パケット
を含む。

ＣｏＣｏプロトコルリンクレイヤがデータパケットを受信する場合、リンクレイヤパケットヘッダの８ビットタイプフィールド（［ＢＭ］を参照）には、パケットタイプを指定する値が入っている。パケットタイプが回線レイヤパケットの上述の６つのタイプの内の一つのタイプである場合、リンクレイヤがパケットを回線レイヤに転送し、そしてパケットタイプを回線レイヤに（ＯｎＲｅｃｅｉｖｅＰａｃｋｅｔコールを利用して）直接送信する。以下のパケットタイプは、回線レイヤパケットタイプに対応するタイプフィールド値である。

パケットフォーマット
図８〜図１３は、回線制御パケットのパケットヘッダフォーマットのようなパケットフォーマットを示している。パケットヘッダはパケットタイプの符号化データを含まない。なぜならば、符号化データはリンクレイヤヘッダに既に含まれているからである。リンクレイヤが既にタイプを認識しているので、この情報を回線レイヤヘッダの中で繰り返す必要はない。

リンクレイヤは、送信元アドレス及び送信先アドレスをイーサネット／物理レイヤフレームヘッダから取得する。回線レイヤは、ｌｉｎｋＩＤ及びパケットタイプをリンクレイヤから取得し、リンクレイヤは、上位レイヤに渡す必要があるデータを物理レイヤから当該リンクレイヤで受信したときに、回線レイヤＡＰＩエントリポイント関数ＣｉｒｃｕｉｔＲｅｃｅｉｖｅＰａｃｋｅｔ（ｕ３２ ｌｉｎｋＩＤ， ｕ８ ｔｙｐｅ， Ｄａｔａ ｂｕｆｆｅｒ）を呼び出す。

「回線制御プロセス」と題する節では、回線レイヤプロトコルが前の「回線制御パケット」と題する節で説明した回線制御パケットをどのように使用するかについて説明する。
図８に示すＣＥＳＴパケットフォーマットは、レッグの下流（受信側）ノードに向かうパケットを特定するＬｏｃａｌＬｅｇＩＤを含む。下流ノードは、パケットが到着するときに経由するリンクを検出するので、当該ノードは、どの回線を、このＣＥＳＴパケットで設定しようとしているかについて判断するために十分な情報を持ち、そしてエントリ＜ｉｎｃｏｍｉｎｇ， ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ＞を当該ノードの回線テーブルに加える。残りのフィールドは、送信元ノード及び送信先ノードのロケーション及びサービス名を確認するために利用される。

「ＮｕｍＳｒｃＬｏｃＵｎｉｔｓ」は８ビットフィールドであり、８ビットフィールドは、送信元のロケーションにおけるロケーションユニットの数ｎを含む。送信元のロケーションは、ｎ個の固有ノード識別子（ＵＮＩｓ）により構成され、この場合、ｎはネットワークにおけるクラスターレベルの現在数である。クラスターに関する情報については、［ＢＬＭＳ］を参照されたい。

「ＮｕｍＤｅｓＬｏｃＵｎｉｔｓ」は８ビットフィールドであり、８ビットフィールドは、送信先のロケーションにおけるロケーションユニットの数ｎを含む。送信先のロケーションは、ｎ個の固有ノード識別子（ＵＮＩｓ）により構成され、この場合、ｎはネットワークにおけるクラスターレベルの現在数である。

「ＳｉｚｅＳｒｃＳｒｖｃＮａｍｅ」は送信元サービスの名前のバイト単位で指定されるサイズである。サービス名のサイズは、ＵＴＦ−８における当該サービス名の表示に必要なバイト数とすることができる。

「ＳｉｚｅＤｅｓＳｒｖｃＮａｍｅ」は、送信先サービスの名前のバイト単位で指定されるサイズである。
「Ｓｏｕｒｃｅ Ｌｏｃａｔｉｏｎ」は、回線を表わすノードのロケーションを表現する。ロケーションは、ｎ個のＵＮＩにより構成され、この場合、ｎはＮｕｍＳｒｃＬｏｃＵｎｉｔｓフィールドにおける値である。

「Ｄｅｓｔｉｎａｔｉｏｎ Ｌｏｃａｔｉｏｎ」は、回線を表わすノードのロケーションを表現する。ロケーションは、ｎ個のＵＮＩにより構成され、この場合、ｎはＮｕｍＳｒｃＬｏｃＵｎｉｔｓフィールドにおける値である。

「Ｓｏｕｒｃｅ Ｓｅｒｖｉｃｅ Ｎａｍｅ」は、送信元ノードに提供され、かつＵＴＦ−８ストリングとして表わされるサービスの名前である。
「Ｄｅｓｔｉｎａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｎａｍｅ」は、送信先ノードに提供され、かつＵＴＦ−８ストリングとして表わされるサービスの名前である。

図９に示すＣＡＣＫパケットフォーマットは、レッグの上流（受信側）ノードに向かうパケットを特定するＬｏｃａｌＬｅｇＩＤを含む。上流ノードは、パケットが到着するときに経由するリンクに頻繁に利用されるので、当該ノードは、どの回線を、このＣＡＣＫパケットで確認応答しようとしているかについて判断するために十分な情報を有する。

拡張ブロックは、（例えば、レッグのＱｏＳ機能、及び暗号化ハンドシェーク情報を含む）拡張固有のリクエストに対する拡張固有のアンサーを含む。
図１０に示すＣＤＡＴパケットヘッダフォーマットは、レッグの下流（受信側）ノードに向かうパケットを特定するＬｏｃａｌＬｅｇＩＤを含む。ＭｅｓｓａｇｅＩＤフィールドは、回線経由で送信されるパケットごとに順番に大きくなるので、受信側は、どのパケットが、そしてどの位多くのパケットが廃棄されたかを検出することができる。回線レイヤはこの情報を使用して、各レッグがサポートすることができるサービス品質を求めることができる。

ＣＲＳＴパケット，ＣＣＬＳパケット，及びＣＵＮＫパケットは、図１１に示すようにＬｏｃａｌＬｅｇＩＤのみから成る。他のタイプの回線パケットのパケットヘッダと同じように、タイプ自体は受信側ノードに認識されるが、これは、タイプがリンクレイヤヘッダに現われ、そしてリンクレイヤが当該タイプを回線レイヤにＯｎＲｅｃｅｉｖｅＰａｃｋｅｔ（ＬｉｎｋＩＤ， Ｔｙｐｅ， Ｐａｃｋｅｔ）コール関数で渡すからである。
ヘッダ圧縮機構としてのレッグ
レッグというコンセプトを知るために、レッグがローカルヘッダ圧縮機構として動作する様子を分析する。全ての回線データパケットは４タプル全体、及び関連オプションの全てを含むことができ、これらは、転送制御プロトコルがどのように動作するかを表わす。この場合、４タプル＜ｓｏｕｒｃｅ ｎｏｄｅ， ｓｏｕｒｃｅ ｓｅｒｖｉｃｅ， ｄｅｓｔｉｎａｔｉｏｎ ｎｏｄｅ， ｄｅｓｔｉｎａｔｉｏｎ ｓｅｒｖｉｃｅ＞をデータパケットに取り込むために、中間ノードが関連回線に関するステート情報を維持する必要はない。４タプルをデータパケットに取り込むことにより、プロトコルを簡単にし、かつ実行し易くすることもできる。しかしながら、ステートレスな回線プロトコルでは、帯域容量をＱｏＳ管理に関して確保することができず、回線プロトコルには、大型で更に複雑なパケットに対応する更に大きな容量のメモリが必要となり、そしてルーティング決定ロジックをパケットごとに実行する必要があるので回線プロトコルの速度が非常に遅くなる。

概念的には、所定のリンク及び方向に関するＬｏｃａｌＬｅｇＩＤを認識することにより、一つの回線が決定される。一つのレッグはシングルホップよりも長いローカルなコンセプトであるが、（当該レッグの方向、及び当該レッグに使用されるリンクとともなう）ＬｏｃａｌＬｅｇＩＤは、回線全体を参照するために重要な要素である；「回線レイヤデータ構造」と題する節では、この要素に関する機構について説明する。このコンセプトによって、パケットごとに単一のネットワーク接続を経由して行なわれる全ての繰り返し動作を、回線が一度設定されるだけで行なうことができる。これにより、各パケットに関するルーティングロジックはテーブルルックアップを行なうだけで済むので、ロジックが高速になる。このアプローチによってＱｏＳの合意、リンク容量確保、及びエンドツーエンドの暗号化機構が可能になる。

回線レイヤデータ構造
回線制御プロセス仕様によれば、２つのテーブル、すなわち回線テーブル、及びレッグテーブルを各ノードに設ける必要がある。

回線テーブル
図１２は、或る実施形態に用いられる回線テーブルを示すブロック図である。或るノードの回線テーブルは一つのエントリを、ローカルノードを使用する各回線に対応して含む。回線は次のように４タプルで表わされる。ｃｉｒｃｕｉｔ＝＜ｓｏｕｒｃｅ ｎｏｄｅ， ｓｏｕｒｃｅ ｓｅｒｖｉｃｅ， ｄｅｓｔ ｎｏｄｅ， ｄｅｓｔ ｓｅｒｖｉｃｅ＞。各回線はこの４タプルによって完全に決定される。使い勝手を良くするために、各４タプルを３２ビットＣｉｒｃｕｉｔＩＤフィールドにも関連付け、ＣｉｒｃｕｉｔＩＤフィールドによって回線を一意に決定し、そして指定する。４タプルをルックアップし、そして回線ＩＤを取得する。各回線は、ＯｐｅｎｉｎｇまたはＲｅａｄｙのいずれかであるステートを持つ。ＣｉｒｃｕｉｔＩＤ及び関連する４タプルで、それぞれ一つの回線を指定するのではあるが、ＣｉｒｃｕｉｔＩＤを維持してレッグテーブルを相互参照することが有用である。

レッグテーブル
図１３は、或る実施形態に用いられるレッグテーブルを示すブロック図である。レッグテーブルは一つのエントリを、ローカルノードへの着信レッグであり、かつローカルノードからの発信レッグである各レッグに対応して含む。このエントリは、レッグを含む回線のＣｉｒｃｕｉｔＩＤを含む。レッグは以下のように、３タプルで表わされる。ｌｅｇ＝＜ｄｉｒｅｃｔｉｏｎ， ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ＞。レッグテーブルエントリは、ＣｉｒｃｕｉｔＩＤ，レッグＬ，ステートｓから成り、ＬはＣｉｒｃｕｉｔＩＤによって指定される回線の一部分であり、かつステートｓの状態になっている。

３つのフィールドＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎは一体となって、このテーブルの重要な一つの要素を構成するので、＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， ｄｉｒｅｃｔｉｏｎ＞のような３タプルが与えられると、関連するＣｉｒｃｕｉｔＩＤフィールド及びＳｔａｔｅフィールドを効率的に取得して、このレッグが一部分となって回線を構成することになるのはどの回線であるかについて、そしてレッグのステートについてそれぞれ判断することができる。

レッグテーブル及び回線テーブルは、図１４に示すように、ＣｉｒｃｕｉｔＩＤフィールドによって関連付けられる。例えば、所定のＣｉｒｃｕｉｔＩＤによって指定される一つの回線に関連付けられるレッグの全てを、当該ＣｉｒｃｕｉｔＩＤを持つレッグテーブルのエントリの全てを見付け出すことによって取得することができる。以下の概略説明では、この関係を示し、そして一つの回線が，一つのノードに入り、そして／または一つのノードから出て行く複数のレッグを有することができることを示す。

テーブル演算
回線テーブル及びレッグテーブルは以下の関数をサポートする：
Ｓｔａｔｅ（ＣｉｒｃｕｉｔＩＤ）
ＣｉｒｃｕｉｔＩＤが与えられると、この関数は回線のステートを返す。ステートはＯｐｅｎｉｎｇまたはＲｅａｄｙのいずれかである。回線テーブルの構造が与えられると、この演算は簡単に実行される。所定のＣｉｒｃｕｉｔＩＤを持つ回線テーブルエントリを見付け出し、そして当該エントリのステートフィールドを返す。

Ｓｔａｔｅ（＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， ｄｉｒｅｃｔｉｏｎ＞）
Ｓｔａｔｅ（Ｌｅｇ）
ＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎによって指定されるレッグが与えられると、この関数はレッグのステートを返す。ステートはＯｐｅｎｉｎｇまたはＲｅａｄｙのいずれかである。回線テーブルの構造が与えられると、この演算は簡単に実行される。所定のＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎを持つレッグテーブルエントリを見付け出し、そして当該エントリのステートフィールドを返す。

表記を分かり易くするために、ｌｅｇ＝＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， ｄｉｒｅｃｔｉｏｎ＞と表現する。ここで、ｌｅｇは３タプルの簡便な表記である。例えば、以下のように記述することができる。

ＵｐｄａｔｅＬｅｇＳｔａｔｅ（Ｌｅｇ， Ｓｔａｔｅ）
この手順では、Ｌｅｇ（レッグ）のステートをＳｔａｔｅに更新する。

ＵｐｄａｔｅＣｉｒｃｕｉｔＳｔａｔｅ（Ｃｉｒｃｕｉｔ， Ｓｔａｔｅ）
この手順では、Ｃｉｒｃｕｉｔ（回線）のステートをＳｔａｔｅに更新する。
ＩｎｃｏｍｉｎｇＬｅｇｓ（ＣｉｒｃｕｉｔＩＤ）
ＣｉｒｃｕｉｔＩＤが与えられると、着信レッグ集合をローカルノードに返す。レッグテーブルの構造を使用して、この演算は、レッグテーブルをｄｉｒｅｃｔｉｏｎフィールドがｉｎｃｏｍｉｎｇである所定のＣｉｒｃｕｉｔＩＤフィールドを持つ全ての行（エントリ）に関して調査し、そして該当するＬｉｎｋＩＤ／ＬｏｃａｌＬｅｇＩＤペアを返すことにより実行することができる。

ＯｕｔｇｏｉｎｇＬｅｇｓ（ＣｉｒｃｕｉｔＩＤ）
ＣｉｒｃｕｉｔＩＤが与えられると、発信レッグ集合をローカルノードに返す。レッグテーブルの構造を使用して、この演算は、レッグテーブルをｄｉｒｅｃｔｉｏｎフィールドがｏｕｔｇｏｉｎｇである所定のＣｉｒｃｕｉｔＩＤフィールドを持つ全ての行（エントリ）に関して調査し、そして該当するＬｉｎｋＩＤ／ＬｏｃａｌＬｅｇＩＤペアを返すことにより実行することができる。

ＧｅｎｅｒａｔｅＮｅｗＣｉｒｃｕｉｔＩＤ（）
この関数は、現在、ＣｉｒｃｕｉｔＩＤとして使用されていない（従って、新規の回線に対応するＣｉｒｃｕｉｔＩＤとして使用することができる）値を返す。

ＧｅｎｅｒａｔｅＮｅｗＬｏｃａｌＬｅｇＩＤ（）
この関数は、現在、ＬｏｃａｌＬｅｇＩＤとして使用されていない（従って、新規のレッグに対応するＬｏｃａｌＬｅｇＩＤとして使用することができる）値を返す。

ＡｄｄＣｉｒｃｕｉｔ（Ｓｒｃ ｎｏｄｅ，Ｓｒｃ ｓｅｒｖｉｃｅ， Ｄｅｓｔ ｎｏｄｅ，Ｄｅｓｔ ｓｅｒｖｉｃｅ， ＣｉｒｃｕｉｔＩＤ， Ｓｔａｔｅ）
この演算では、一つの回線を回線テーブルに加える。

ＡｄｄＬｅｇ（ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， Ｄｉｒｅｃｔｉｏｎ， Ｓｔａｔｅ， ＣｉｒｃｕｉｔＩＤ）
この演算では、ＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎによって指定されるレッグを、ＣｉｒｃｕｉｔＩＤによって指定される回線に加える。この演算では、ｄｉｒｅｃｔｉｏｎがｉｎｃｏｍｉｎｇまたはｏｕｔｇｏｉｎｇのいずれかである３タプル＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， ｄｉｒｅｃｔｉｏｎ＞によって表わされる新規のレッグを確立し、そしてこのレッグをレッグテーブルに加える。レッグテーブルの構造を使用して、この演算を、回線が存在することをチェックし（ＣｉｒｃｕｉｔＩＤが回線テーブルに含まれることをチェックし）、そして新規のテーブルエントリに所定のパラメータを追加することにより実行することができる。

ＣｉｒｃｕｉｔＩＤ（＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， ｄｉｒｅｃｔｉｏｎ＞）
ＣｉｒｃｕｉｔＩＤ（Ｌｅｇ）
３タプル＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， Ｄｉｒｅｃｔｉｏｎ＞が与えられると、当該タプルが属する回線を、関連するＣｉｒｃｕｉｔＩＤを返すことにより取得する。

ＣｉｒｃｕｉｔＩＤ（＜Ｓｒｃ ｎｏｄｅ， Ｓｒｃ ｓｅｒｖｉｃｅ， Ｄｅｓｔ ｎｏｄｅ， Ｄｅｓｔ ｓｅｒｖｉｃｅ＞）
ＣｉｒｃｕｉｔＩＤ（Ｃｉｒｃｕｉｔ）
この関数は、回線のＣｉｒｃｕｉｔＩＤを返す。

ＲｅｍｏｖｅＬｅｇ（＜ＬｉｎｋＩＤ， ＬｏｃａｌＬｅｇＩＤ， Ｄｉｒｅｃｔｉｏｎ＞）
ＲｅｍｏｖｅＬｅｇ（Ｌｅｇ）
各回線に、ＬｅｇＩＤによって指定されるレッグが使用される場合、＜ＣｉｒｃｕｉｔＩＤ， ＬｅｇＩＤ＞関連付けを回線テーブル及びレッグテーブルから削除する。当該関連付けが、一つの回線に関連付けられる唯一の関連付けである場合、当該回線も回線テーブルから削除される。

ＲｅｍｏｖｅＣｉｒｃｕｉｔ（ＣｉｒｃｕｉｔＩＤ）
この演算では、ＣｉｒｃｕｉｔＩＤによって指定される回線を回線テーブルから削除する。

回線制御プロセス
回線の設定及び閉鎖、及び回線経由のデータ伝送のような回線制御プロセスは、ステートマシン図か、または疑似コードフォーマットで記述することができる。ステートマシンアプローチを使用する場合、各着信レッグ及び発信レッグは、ステートマシンによって管理される。着信レッグにおけるステータス変化によって、一つ以上の新規のステートマシンが生成されて発信レッグが記述されるので、複雑さが増大する。更に、ステートマシンは、ノードが中継ポイントまたはエンドポイントのいずれであるかによって若干異なる。これらの理由により、次の節では、上位の疑似コードを使用して回線制御プロセスを指定する。

レッグ操作の基本
定義：ノードＹにノードＸから到達するコストをｃｏｓｔ（Ｘ，Ｙ）で表わす。
定義：ノードＳ，Ｎ，Ｄのいずれに関しても、ｄｏｗｎｈｉｌｌ（Ｓ，Ｎ，Ｄ）が、ｃｏｓｔ（Ｎ，Ｄ）＜ｃｏｓｔ（Ｓ，Ｄ）の場合に成り立つ。

定義：ノードＳからノードＤに達する下りリンク（ｄｏｗｎｈｉｌｌ ｌｉｎｋ）で、ノードＳをノードＮに接続し、この場合、ｄｏｗｎｈｉｌｌ（Ｓ，Ｎ，Ｄ）が成り立つ。
１．１．１．１ ＧｅｔＤｏｗｎｈｉｌｌＬｉｎｋＳｅｔ
ノードＮで実行される回線制御プロセスがＬｉｎｋＳｅｔ＝ＧｅｔＤｏｗｎｈｉｌｌＬｉｎｋＳｅｔ（ｄｅｓｔＬｏｃａｔｉｏｎ）関数を呼び出す場合、当該プロセスは、ノードＮからｄｅｓｔＬｏｃａｔｉｏｎ（送信先ロケーション）に達する全ての下りリンクの集合を、ルーティングレイヤのＡＰＩ関数ＧｅｔＮｅｘｔＨｏｐｓ（ｄｅｓｔＬｏｃａｔｉｏｎ）を呼び出すことにより取得する。

１．１．１．２ ＣｒｅａｔｅＬｅｇＳｅｔ
ノードＮの回線レイヤはＧｅｔＤｏｗｎｈｉｌｌＬｉｎｋＳｅｔを呼び出してネットワーク送信先のノードＤに向かう一連の下りリンクを取得した後、当該レイヤは、ＬｅｇＳｅｔ＝ＣｒｅａｔｅＬｅｇＳｅｔ（ＬｉｎｋＳｅｔ）を呼び出してコスト効率の高い一連のレッグを取得し、これらのレッグを経由して、ノードＮの回線レイヤがＣＥＳＴパケットを送信して、ノードＤに達する回線の確立を継続する。以下の疑似コードはＣｒｅａｔｅＬｅｇＳｅｔプロシージャの概要を示す。

１．１．１．３ ＰｅｒＰａｃｋｅｔＬｅｇＳｅｔ
ＰｅｒＰａｃｋｅｔＬｅｇＳｅｔ（ＣｉｒｃｕｉｔＩＤ， Ｐａｃｋｅｔ）関数は、ＣｒｅａｔｅＬｅｇＳｅｔ（）によって返されるレッグの内のどのレッグに沿って、回線レイヤがＰａｃｋｅｔ（パケット）を送信すべきかについて決定する。ＰｅｒＰａｃｋｅｔＬｅｇＳｅｔの内部ロジックは、回線のＱｏＳ要件、及び回線について考えられる他の拡張要件によって変わる。

Ｃｉｒｃｕｉｔ Ｅｓｔａｂｌｉｓｈｍｅｎｔ
或るノードがＣＥＳＴパケットを着信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＥＳＴプロシージャを実行する。

回線の閉鎖
或るノードがＣＣＬＳパケットを着信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＣＬＳ（ＬｅｇＩＤ）プロシージャを実行する。

回線のリセット
或るノードがＣＲＳＴパケットを発信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＲＳＴ（ＬｅｇＩＤ）プロシージャを実行する。

回線の確認応答
或るノードがＣＡＣＫパケットを発信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＡＣＫ（ＬｅｇＩＤ）プロシージャを実行する。

回線データ
或るノードがＣＤＡＴパケットを着信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＤＡＴ（ＬｅｇＩＤ）プロシージャを実行する。

不明の回線
或るノードがＣＵＮＫパケットを発信レッグで受信すると、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＵＮＫ（ＬｅｇＩＤ）プロシージャを実行する。

回線レイヤのＡＰＩ
回線レイヤのＡＰＩ（アプリケーションプログラムインターフェース）は以下のプロシージャの集まりである。幾つかのプロシージャにはユーザアプリケーションプログラムがアクセスする。他のプロシージャにはリンクレイヤがアクセスする。

或るノードがパケットをリンクレイヤから受信すると、当該ノードは、以下の疑似コードに概要が示されるＯｎＲｅｃｖＰａｃｋｅｔ（）プロシージャを実行する。

データが回線で指定タイムアウト期間の間に到着しなかった後、回線レイヤは、以下の疑似コードに概要が示されるＯｎＴｉｍｅｏｕｔプロシージャを実行する。

リンクレイヤが、リンクが閉鎖したことを検出すると、リンクレイヤは、以下の疑似コードに概要が示される回線レイヤのＬｉｎｋＤｏｗｎプロシージャを呼び出す。

リンクレイヤが、リンクが設定されたことを検出すると、リンクレイヤは、以下の疑似コードに概要が示される回線レイヤのＬｉｎｋＵｐプロシージャを呼び出す。

ユーザアプリケーションで或る回線を、或るサービスがリモートノードで実行されるように構築すると、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＯｐｅｎプロシージャを呼び出す。

ユーザアプリケーションが、当該アプリケーションで既に構築されている回線の使用を終了すると、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＣｌｏｓｅプロシージャを呼び出す。

ユーザアプリケーションがデータを、当該アプリケーションで既に構築されている回線で受信すると予測される場合、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＲｅａｄプロシージャを呼び出す。

ユーザアプリケーションがデータを、当該アプリケーションで既に構築されている回線で送信する必要がある場合、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＷｒｉｔｅプロシージャを呼び出す。

関連するセマンティックのコンセプト
・回線
・回線の設定
・ハンドオフ
・エンドツーエンド接続
・単方向性
・回線レッグ
・回線の中継ポイント
・回線のエンドポイント
・回線の拡張
・サービス品質のサポート
・公知のポート
・ネットワークサービス
結論
ＣｏＣｏプロトコルの回線レイヤはＣｏＣｏネットワーク経由のエンドツーエンド接続を可能にする。回線レイヤによってマルチパス回線が可能になるので、帯域が広くなり、かつハンドオフ管理の性能が向上する。この文書では、回線レイヤで使用されるＡＰＩ（アプリケーションプログラムインターフェース）及びパケットフォーマットについて要約している。

回線レイヤは少なくともこれらの機能を提供する：
１．適応的自動調整回線を、スケーラブルかつ動的である均質な通信ネットワークにおいて設定する方法。プロトコルという用語は、これに関連して方法と同じ意味に使用される。
（ａ）通信ネットワークは、データを互いに対して送信し、そして互いから受信する機能を備える通信デバイスの集合体である。ネットワークデバイスまたはネットワークノードは、プロトコルソフトウェアを実行するために十分な計算能力を持ついずれかのデバイス、及び他のデバイスとの接続を確立する手段である。
（ｂ）均質な通信ネットワークは、複数タイプのネットワークデバイス、及び複数タイプの通信リンクの集合体から成る通信ネットワークである。別の表現をするト、ネットワークはハイブリッドネットワークであり、ハイブリッドネットワークは、異なるタイプ及び製造業者のデバイスから成り、これらのデバイスとして（これらには制限されないが）、携帯電話機、ラップトップコンピュータ、携帯情報端末を挙げることができ、これらのデバイスは互いに有線接続または無線接続によって接続され、これらの接続は（これらには制限されないが）、ＷｉＦｉリンク，イーサネットリンク、衛星リンク、及びセルラーリンクを含む種々の下位の転送機構のいずれかによって確立することができる。均質である（１種類のデバイス及び／又は１種類の転送機構により全体が構成される）ネットワークは均質な通信ネットワークの特殊事例である。
（ｃ）動的ネットワークによってデバイスは、これらの通信デバイスのユーザの意のままに任意の時点で、かつデバイスが地理的に移動するいずれの場所でもオン及びオフすることができる。
（ｄ）スケーラブルなネットワークとは、ネットワークにおける通信デバイスの数が増大するときに、正しく、かつ効率的に動作し続けるネットワークである。
２．回線を通信ネットワークにおいて管理する方法。
３．回線のハンドオフを、動的な変化がネットワーク形態に発生している状態で管理する方法。
４．回線を、サービス品質が保証されるレベルで実現する方法。
５．回線を、エンドツーエンドセキュリティが保証されるレベルで実現する方法。
６．マルチキャスト回線を確立する方法。
７．エンドツーエンド回線を、ＣｏＣｏクラスタリング方法に関する特許請求項に記載される下位のルーティングレイヤを利用して作成する方法。
８．回線を、回線テーブル及びレッグテーブルとして知られる関係テーブルを使用して管理する方法。

これまでの記述から、本発明の特定の実施形態について本明細書において説明して例示を行なってきたが、種々の変更を本発明の技術思想及び技術範囲から逸脱しない限り加え得ることを理解できるであろう。従って、本発明は、添付の請求項によって規定される以外には制限されない。

種々の実施形態におけるＣｏＣｏ通信プロトコルの種々のネットワークアーキテクチャレイヤを示すブロック図である。 種々の実施形態における回線レイヤと他のレイヤとの間のインターフェースを示すブロック図である。 種々の実施形態における複数のネットワーク経路を示すブロック図である。 或る実施形態における回線レッグを示すブロック図である。 或る実施形態におけるネットワークパケットの方向性を示すブロック図である。 種々の実施形態におけるエンドポイント及び中継ポイントを示すブロック図である。 ２つの回線の一つのエンドポイントとして動作するネットワークノードを示すブロック図である。 或る実施形態において用いられるＣＥＳＴパケットフォーマットを示すブロック図である。 或る実施形態において用いられるＣＡＣＫパケットフォーマットを示すブロック図である。 或る実施形態において用いられるＣＤＡＴパケットフォーマットを示すブロック図である。 或る実施形態において用いられるＣＲＳＴ，ＣＣＬＳ，及びＣＵＮＫパケットフォーマットを示すブロック図である。 或る実施形態において用いられる回線テーブルを示すブロック図である。 或る実施形態において用いられるレッグテーブルを示すブロック図である。 回線テーブルとレッグテーブルとの関係を示すブロック図である。

Claims (8)

1. データ通信ネットワークに接続される物理デバイスの間のネットワーク通信を可能にするシステムであって、
   少なくとも第１のノードおよび前記第１のノードと隣接する第２のノードであって、前記第１のノードと、前記第２のノードとの間に回線リンクを備え、各ノードは、前記リンク上の区間を一意的に識別し、前記リンク上の各区間は、方向、リンクＩＤ、およびローカル区間ＩＤを備える３タプルによりそれぞれ識別される、前記少なくとも第１のノードおよび第２のノードと、
   前記第１のノードから前記第２のノードにデータ通信パケットを伝送するプロトコル回線レイヤであって、各データ通信パケットは、データを有するペイロードと、前記第１のノードと前記第２のノードとの間の前記回線リンクを識別する前記ローカル区間ＩＤとを含む、前記プロトコル回線レイヤとを備え、
   前記第１のノードは、前記通信パケットに関連付けされた回線を識別する第１のノードに記憶された情報にアクセスし、前記第１のノードに記憶された情報は、４タプルにより前記回線を識別し、該４タプルは、送信元ノード、送信先ノード、送信元サービス、および送信先サービスの識別子を含み、前記第１のノードに記憶された前記情報は、前記ローカル区間ＩＤと、前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として関連付けされた、前記第１のノードと前記第２のノードとの間の回線リンクとを含み、
   前記ローカル区間ＩＤ及び前記回線を識別する前記記憶された情報は、前記第１のノードと前記第２のノードとの間の前記回線リンクを、前記第１のノードから前記第２のノードへ前記データ通信パケットを伝送するように用いられるべき前記回線リンクとして識別するためにアクセスされ、
   前記第１のノードは、前記第１のノードと前記第２のノードとの間の前記回線リンクを識別する前記ローカル区間ＩＤを前記データ通信パケットに付与し、
   前記第１のノードは、前記付与されたローカル区間ＩＤを有する前記データ通信パケットを前記第２のノードに伝送し、
   前記付与されたローカル区間ＩＤを有する前記データ通信パケットを受信したことに応答して、前記第２のノードは、前記通信パケットに関連付けされた前記回線を識別する前記第２のノードに記憶された情報にアクセスし、前記第２のノードに記憶された情報は、前記４タプルによって前記回線を識別し、さらに前記第２のノードと前記第２のノードとの間の前記回線リンク上の区間を識別する３タプルの各々を前記回線の一部分として識別し、
   前記ローカル区間ＩＤ及び前記４タプルを含む回線設定パケットは、前記第１のノードから前記第２のノードに伝送されて、前記第２のノードからの確認パケットが前記第１のノードにて受信され、
   前記回線リンクは、前記第１のノードと前記第２のノードとの間の第１の回線リンクであり、前記ローカル区間ＩＤは、第１のローカル区間ＩＤであり、通信ネットワークは、前記第２のノードと隣接する第３のノードを含み、さらに前記通信ネットワークは、第２のローカル区間ＩＤにより識別された前記第２のノードと前記第３のノードとの間の第２の回線リンクを含み、
   前記第２のノードは、前記第２のノードと前記第３のノードとの間の前記回線リンクを前記回線の一部分として識別する、前記第２のノードに記憶された前記情報にアクセスし、
   前記第２のノードは、前記第２の回線リンクに関連付けされた前記第２のローカル区間ＩＤを前記データ通信パケットに付与し、
   前記第２のノードは、前記付与された第２のローカル区間ＩＤを有する前記データ通信パケットを前記第３のノードに伝送し、
   前記通信ネットワークは、前記第２のノードに隣接する第４のノードをさらに含み、第３のローカル区間ＩＤにより識別された前記第２のノードと前記第４のノードとの間の第３の回線リンクを含み、
   前記第２の回線リンクの失敗に応答して、前記第２のノードは、前記第２のノードと前記第４のノードとの間の前記第３の回線リンクを識別する、前記第２のノードに記憶された前記情報にアクセスし、
   前記第２のノードは、前記第３の回線リンクを、前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として関連付け、
   前記第２のノードは、前記第２のノードと前記第４のノードとの間の前記第３の回線リンクを識別する前記第３のローカル区間ＩＤを、前記第４のノードに伝送される回線設定パケットを付与し、前記回線設定パケットは、前記回線の前記４タプルを含み、
   前記第２のノードは、その記憶された情報を更新して、前記第３のローカル区間ＩＤにより識別された前記第３の回線リンクを、前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として識別し、
   前記第４のノードが前記第２のノードから前記回線設定パケットを受信することに応答して、前記第４のノードは、前記４タプルと前記第３のローカル区間ＩＤとを有するその記憶された情報を更新して、前記第３の回線リンクを前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として識別し、
   前記第２のノードは、前記付与された第３のローカル区間ＩＤを有する前記データ通信パケットを前記第３の回線リンクを介して前記第４のノードに伝送する、システム。
2. 回線区間の下流方向にのみ伝送される回線制御パケットを更に備える請求項１記載のシステム。
3. 前記第１のノードと前記第２のノードとの間の回線区間の上流方向にのみ伝送される回線制御パケットを更に備える請求項１記載のシステム。
4. 前記プロトコル回線レイヤは、回線を設定するときにルーティングレイヤを用いて最適ルートを決定する、請求項１記載のシステム。
5. 前記プロトコル回線レイヤは、リンクレイヤを用いてリンクを介してデータパケットを他のネットワークノードに送信する、請求項１記載のシステム。
6. 第１のネットワークノードと第２のネットワークノードとの間の通信リンクを設定する方法を前記第１のネットワークノードおよび前記第２のネットワークノードに実行させるように使用可能なコンピュータ実行可能命令を有する不揮発性のコンピュータ読み取り可能媒体であって、
   各ノードは、前記リンク上の区間を一意的に識別し、前記リンク上の各区間は、方向、リンクＩＤ、およびローカル区間ＩＤを備える３タプルによりそれぞれ識別され、
   前記方法は、
   前記ローカル区間ＩＤ及び４タプルを含む回線設定パケットを生成することであって、前記ローカル区間ＩＤは、通信リンクを識別し、前記４タプルは、第１のネットワークノードの識別子、前記第２のネットワークノードの識別子、前記第１のネットワークノードにより提供されるサービスの識別子、及び第２のネットワークノードにより提供されるサービスの識別子を含み、送信元ノードと送信先ノードとの間の回線リンクを特定する、前記回線設定パケットを生成すること、
   前記回線設定パケットを前記第１ノードから第２ノードに通信すること、
   前記第１ノードにおいて、前記第２ノードからの確認パケットを受信すること、
   前記第１ノードにおいて、前記第１ノードと前記第２ノードとの間の通信リンクを識別するローカル区間ＩＤを、前記送信元ノードと前記送信先ノードとの間で通信されるデータ通信パケットに付加すること、
   前記ローカル区間ＩＤに関連する通信リンクに渡って前記第１ノードから前記第２ノードに複数のデータ通信パケットを通信することを備え、
   プロトコル回線レイヤは、前記第１のノードから前記第２のノードにデータ通信パケットを伝送し、各データ通信パケットは、データを有するペイロードと、前記第１のノードと前記第２のノードとの間の前記回線リンクを識別する前記ローカル区間ＩＤとを含み、
   前記第１のノードは、前記通信パケットに関連付けされた回線を識別する第１のノードに記憶された情報にアクセスし、前記第１のノードに記憶された情報は、４タプルにより前記回線を識別し、該４タプルは、送信元ノード、送信先ノード、送信元サービス、および送信先サービスの識別子を含み、前記第１のノードに記憶された前記情報は、ローカル区間ＩＤと、前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として関連付けされた、前記第１のノードと前記第２のノードとの間の回線リンクとを含み、
   前記ローカル区間ＩＤ及び前記回線を識別する前記記憶された情報は、前記第１のノードと前記第２のノードとの間の前記回線リンクを、前記第１のノードから前記第２のノードへ前記データ通信パケットを伝送するように用いられるべき前記回線リンクとして識別するためにアクセスされ、
   前記第１のノードは、前記第１のノードと前記第２のノードとの間の前記回線リンクを識別する前記ローカル区間ＩＤを前記データ通信パケットに付与し、
   前記第１のノードは、前記付与されたローカル区間ＩＤを有する前記データ通信パケットを前記第２のノードに伝送し、
   前記付与されたローカル区間ＩＤを有する前記データ通信パケットを受信したことに応答して、前記第２のノードは、前記通信パケットに関連付けされた前記回線を識別する前記第２のノードに記憶された情報にアクセスし、前記第２のノードに記憶された情報は、前記４タプルによって前記回線を識別し、さらに前記第２のノードと前記第２のノードとの間の前記回線リンク上の区間を識別する３タプルの各々を前記回線の一部分として識別し、
   前記ローカル区間ＩＤ及び前記４タプルを含む回線設定パケットは、前記第１のノードから前記第２のノードに伝送されて、前記第２のノードからの確認パケットが前記第１のノードにて受信され、
   前記回線リンクは、前記第１のノードと前記第２のノードとの間の第１の回線リンクであり、前記ローカル区間ＩＤは、第１のローカル区間ＩＤであり、前記通信ネットワークは、前記第２のノードと隣接する第３のノードを含み、さらに前記通信ネットワークは、第２のローカル区間ＩＤにより識別された前記第２のノードと前記第３のノードとの間の第２の回線リンクを含み、
   前記第２のノードは、前記第２のノードと前記第３のノードとの間の前記回線リンクを前記回線の一部分として識別する、前記第２のノードに記憶された前記情報にアクセスし、
   前記第２のノードは、前記第２の回線リンクに関連付けされた前記第２のローカル区間ＩＤを前記データ通信パケットに付与し、
   前記第２のノードは、前記付与された第２のローカル区間ＩＤを有する前記データ通信パケットを前記第３のノードに伝送し、
   前記通信ネットワークは、前記第２のノードに隣接する第４のノードをさらに含み、第３のローカル区間ＩＤにより識別された前記第２のノードと前記第４のノードとの間の第３の回線リンクを含み、
   前記第２の回線リンクの失敗に応答して、前記第２のノードは、前記第２のノードと前記第４のノードとの間の前記第３の回線リンクを識別する、前記第２のノードに記憶された前記情報にアクセスし、
   前記第２のノードは、前記第３の回線リンクを、前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として関連付け、
   前記第２のノードは、前記第２のノードと前記第４のノードとの間の前記第３の回線リンクを識別する前記第３のローカル区間ＩＤを、前記第４のノードに伝送される回線設定パケットを付与し、前記回線設定パケットは、前記回線の前記４タプルを含み、
   前記第２のノードは、その記憶された情報を更新して、前記第３のローカル区間ＩＤにより識別された前記第３の回線リンクを、前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として識別し、
   前記第４のノードが前記第２のノードから前記回線設定パケットを受信することに応答して、前記第４のノードは、前記４タプルと前記第３のローカル区間ＩＤとを有するその記憶された情報を更新して、前記第３の回線リンクを前記送信元ノードと前記送信先ノードとの間の前記回線の一部分として識別し、
   前記第２のノードは、前記付与された第３のローカル区間ＩＤを有する前記データ通信パケットを前記第３の回線リンクを介して前記第４のノードに伝送する、コンピュータ読み取り可能媒体。
7. 前記通信リンクを構築することは、前記第１および第２ネットワーク間の直接パスのコストと、前記第２ネットワークと、前記第１および第２ネットワークノードの中間位置と前記第３ネットワークノードとの間のパスのコストとを比較する、請求項６に記載のコンピュータ読み取り可能媒体。
8. 回線テーブルを生成することをさらに備え、
   前記回線テーブルは、前記第１ネットワークノードを含む複数の通信リンクの各々を識別する複数の４タプルを含み、
   前記回線リンクを構築することは、前記回線テーブルを更新することを含む、請求項６に記載のコンピュータ読み取り可能媒体。

Images