(57)【要約】プロトコル回線レイヤが記述される。プロトコル回線レイヤは、ルーティングレイヤを用いて回線を設定するときの最適ルートを決定することができる。回線レイヤは、リンクレイヤを用いてデータパケットをリンクで他のネットワークノードに送信することができる。ネーミングレイヤは、回線を用いて、ネットワークノードアドレスと、これらのアドレスのネットワークロケーションとの関連付けを行なう分散データベースを構築することができる。
2009525709.tif 000002
【特許請求の範囲】
【請求項１】
データ通信ネットワークに接続される物理デバイスの間のネットワーク通信を可能にするシステムであって、
複数のデータ通信パケットを受け渡しするプロトコル回線レイヤを備え、各データ通信パケットは一つの回線を４タプルによって特定し、前記４タプルは、送信元ノード、送信先ノード、送信元サービス、及び送信先サービスの識別子を含み、データ通信パケットはデータを送信元ノードから送信先ノードに伝送する、システム。
【請求項２】
回線レッグの下流方向にのみ伝送される回線制御パケットを更に備える請求項１記載のシステム。
【請求項３】
回線レッグの下流方向にのみ伝送される回線制御パケットを更に備える請求項１記載のシステム。
【請求項４】
前記プロトコル回線レイヤは、回線を設定するときにルーティングレイヤを用いて最適ルートを決定する、請求項１記載のシステム。
【請求項５】
前記プロトコル回線レイヤは、リンクレイヤを用いてリンクを介してデータパケットを他のネットワークノードに送信する、請求項１記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願の相互参照
本出願は、２００６年２月１日出願の「プロトコル回線レイヤ」と題する米国仮特許出願第６０／７６３，９７７号の利益を主張し、そして２００６年２月１日出願の「プロトコルリンクレイヤ」と題する米国仮特許出願第６０／７６３，９５９号、及び２００６年２月１日出願の「ＣＳＭＡ方式伝送媒体における輻輳管理及び遅延予測」と題する米国仮特許出願第６０／７６４，０１３号に関連する。
【０００２】
コンピュータをネットワーク化することによりデータをコンピュータ間で数十年間に亘って授受してきている。一つの重要なネットワークであるインターネットは、通信チャネルで相互接続される非常に多くのコンピュータ及びコンピュータネットワークを含む。インターネットは、電子商取引、電子メールのような情報交換、情報の抽出及び調査の実施などを含む種々の理由により使用される。多くの規格が、情報をインターネット経由で授受するために設定され、規格として、電子メール、ゴーファー（Ｇｏｐｈｅｒ），及びワールドワイドウェブ（ＷＷＷ）を挙げることができる。ＷＷＷサービスによって、サーバコンピュータシステム（すなわち、ウェブサーバまたはウェブサイト）は情報をグラフィカルなウェブページの形でリモートクライアントコンピュータシステムに送信することができる。従って、リモートクライアントコンピュータシステムはウェブページを表示することができる。ＷＷＷの各リソース（例えば、コンピュータまたはウェブページ）は、ユニフォームリソースロケータ（ＵＲＬ）によって一意に特定することができる。特定のウェブページを閲覧するために、クライアントコンピュータシステムは、当該ウェブページに対応するＵＲＬをリクエスト（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエスト）として指定する。リクエストは、ウェブページをサポートするウェブサーバに転送される。当該ウェブサーバがリクエストを受信すると、サーバはリクエストされたウェブページをクライアントコンピュータシステムに送信する。クライアントコンピュータシステムが当該ウェブページを受信すると、クライアントコンピュータシステムは通常、ブラウザを使用してウェブページを表示する。ブラウザは通常、ウェブページをリクエストし、そして表示する特定用途向けプログラムである。
【０００３】
現在、ウェブページは多くの場合、ハイパーテキストマークアップ言語（ＨＴＭＬ）を使用して記述される。ＨＴＭＬには一連の標準のタグが使用され、これらのタグは、ウェブページを表示する方法について記述する。ユーザがリクエストをブラウザに対して行なってウェブページを表示させる場合、ブラウザはリクエストをサーバコンピュータシステムに送信し、サーバコンピュータシステムに、ウェブページを記述するＨＴＭＬドキュメントをクライアントコンピュータシステムに転送させる。リクエストされたＨＴＭＬドキュメントをクライアントコンピュータシステムが受信すると、ブラウザは、ＨＴＭＬドキュメントに記述されたウェブページを表示する。ＨＴＭＬドキュメントは種々のタグを含み、これらのタグで、テキスト、グラフィックス、コントロール、及び他の機能の表示を制御する。ＨＴＭＬドキュメントには、当該サーバコンピュータシステムで、または他のサーバコンピュータシステムで利用することができる他のウェブページのＵＲＬが含まれる。
【０００４】
拡張可能マークアップ言語（ＸＭＬ）及びワイヤレスアクセスプロトコル（ＷＡＰ）のような新規のプロトコルが存在する。ＸＭＬはＨＴＭＬよりも高いフレキシビリティを持つ。ＷＡＰは種々の機能の中でもとりわけ、ウェブページを、携帯電話機及び携帯型コンピュータ（例えばＰＤＡ）のような携帯型無線機器で閲覧する機能を実現する。これらのプロトコルの全てが、情報を人々に種々のデータ処理装置を介して提供する手段を容易にするように機能する。データをデータ処理装置の間で授受する多くの他のプロトコル及び手段が継続的に開発されることにより、情報の授受が更に容易になる。
【発明を実施するための最良の形態】
【０００５】
本文における回線レイヤ
ＣｏＣｏプロトコルは、ユーザと物理インターフェースとの間を仲介する４つのレイヤを含む。これらのレイヤは、
・リンクレイヤ
・ルーティングレイヤ
・回線レイヤ
・ネーミングシステムレイヤ
である。
【０００６】
図１はこれらのレイヤの関係を示している。
回線レイヤは全ての他のプロトコルレイヤだけでなく、ユーザアプリケーションと相互作用することができるので、回線レイヤはこれらのレイヤの中で中心的な役割を果たす。図２は、回線レイヤと他のレイヤとの間のインターフェースを示し、相互作用を更に明示的に示している。回線レイヤは回線を設定する場合に、ルーティングレイヤを使用して最適ルートを求める。回線レイヤはリンクレイヤを使用して、データパケットをリンク経由で他のネットワークノードに送信する。ネーミングレイヤは回線を使用して、ネットワークノードアドレスと、これらのアドレスのネットワークロケーションとの関連付けを行なう分散データベースを構築する。ユーザアプリケーションは回線レイヤを使用してリモートネットワークノードとのエンドツーエンドネットワーク接続を確立する。
【０００７】
回線の抽象化
回線は、データのエンドツーエンドのフロー、すなわちネットワーク送信元からネットワーク送信先に達する接続を表わすプログラミング抽象化である。送信元及び送信先は、＜ｓｅｒｖｉｃｅ，  ｎｏｄｅ＞ペアによって表わされる。すなわち、＜ｓｅｒｖｉｃｅ，  ｎｏｄｅ＞ペアは、特定ノードで実行されるサービスを指す。サービスは、ＦＴＰまたはテルネットのようなインターネットプロトコル規格とすることができるが、音声及びビデオストリームアプリケーションを含むこともできる。サービスネームは広く用いられる必要があるので、いずれかの一連のＣｏＣｏネットワークが統合されている場合には、サービスがかち合うことがなく、大規模な統合ネットワークで相互運用される。本文では、ウェルノウンサービスは、インターネットプロトコルのウェルノウンポートに関する表記に類似する。例えば、テルネットにはポート２３を使用する。インターネット協会（ＩＳＯＣ）によって認可されている組織であるインターネット割り当て番号機関（ＩＡＮＡ）は、固有パラメータ値をインターネットプロトコルに割り当てる中央調整機関である。現在、ココ・コミュニケーションズ・コーポレーションがこのサービスを提供している。一旦、ＣｏＣｏプロトコルが、認知された規格制定団体によって承認されると、ココ・コミュニケーションズはこの役割を同様の機関に移譲する。
【０００８】
送信元ノード、送信元サービス、送信先ノード、及び送信先サービスは、ネットワーク全体を通じて回線を一意に特定するので、回線は、
＜ｓｏｕｒｃｅ  ｎｏｄｅ，  ｓｏｕｒｃｅ  ｓｅｒｖｉｃｅ，  ｄｅｓｔｉｎａｔｉｏｎ  ｎｏｄｅ，  ｄｅｓｔｉｎａｔｉｏｎ  ｓｅｒｖｉｃｅ＞
の４タプルによって特定することができる。
【０００９】
或る回線の送信元及び送信先は通常、同じ種類のサービスを使用することになるが、或る回線を送信元サービス及び送信先サービスの両方を使用して指定することによって、複数の接続が同じ種類のサービスに対応する２つのノードの間で可能になる。例えば、一つよりも多くのＦＴＰ（ファイル転送プロトコル）セッションを同時に、同じクライアントとサーバコンピュータとの間で、異なる送信元サービス（一つのサービスが真のサービスであり、他のサービスはダミーの複製サービスである）を指定することにより確立することができる。
【００１０】
回線は単方向性である。ユーザアプリケーションが２ウェイ通信を必要とする場合、ユーザアプリケーションは或る回線を各方向に設定する必要がある。或る回線は複数の経路を辿り、そして当該回線では、回線が使用するいずれの経路も経時的に調整することにより、変化するネットワーク状態を図３に示すように受け入れることができる。一例として、ノードＢとＮとの間、及びノードＮとＤとの間の直接のネットワーク接続のようなｈｅｎネットワーク接続は利用することができず（図３の例におけるように）、他のルートを選択することができる。
【００１１】
各ネットワークノードは、当該ノードを通過する回線の存在及びステータスに関するステータス情報を維持する。回線は、ユーザアプリケーション及びネーミングシステムレイヤからのリクエスト時に設定され、そして展開される。
【００１２】
回線の内、単一のリンクを通過する部分はレッグ（ｌｅｇ）と呼ばれ、そしてレッグの集合体が一つの回線を構成する。次の節では、レッグについて詳細に議論する。
レッグ（ｌｅｇｓ）
図４は、一つの回線レッグを示すブロック図である。一つの回線の一つのレッグは隣接ノードの間の単一ホップであり、単一ホップは、一つの回線の経路の一部分である。一つのレッグは上流ノード及び下流ノードを有し、これらのノードは一ホップだけ離れている。構造上、上流ノードを回線の送信元に近い方に位置させ、そして下流ノードを回線の送信先ノードに近い方に位置させる。回線設定の詳細は、「回路制御プロセス」と題する節において説明されている。
【００１３】
図５は、ネットワークパケットの方向性を示すブロック図である。全てのユーザデータ及び或る制御データが一つのレッグを経由して、上流ノードから下流ノードに流れる。データフローの方向は、順方向または下り方向と表記される。或る制御データは、逆方向または上り方向と呼ばれる反対方向に流れる。「回線制御パケット」と題する節では、データ制御パケットのパケットフォーマットについて説明する。
【００１４】
レッグの上流ノードから眺めると、レッグは発信レッグと呼ばれる。下流ノードから眺めると、レッグは着信レッグと呼ばれる。
ノード
いずれの回線の送信元ノード及び送信先ノードもエンドポイントと呼ばれる。全ての中間ノードは中継ポイントと呼ばれる。
【００１５】
図６では、ノードＷが送信元ノードであり、そしてノードＺが送信先ノードであり、これらのノードがエンドポイントである。ノードＸ，Ａ，Ｂ，Ｎ，Ｃ，Ｄ，及びＹは中継ポイントである。各エッジに沿った矢印は流れの方向を示す。
【００１６】
図７は、２つの異なる回線に対応する回線送信先エンドポイントとして機能するノードを示し、各回線は別のサービスに接続される。
識別情報
一つの回線に関する唯一の識別情報は当該回線の４タプル、
＜ｓｏｕｒｃｅ  ｎｏｄｅ，  ｓｏｕｒｃｅ  ｓｅｒｖｉｃｅ，  ｄｅｓｔｉｎａｔｉｏｎ  ｎｏｄｅ，  ｄｅｓｔｉｎａｔｉｏｎ  ｓｅｒｖｉｃｅ＞
である。
【００１７】
各レッグは、ＬｏｃａｌＬｅｇＩＤとして知られる識別子を有し、この識別子は、同じ２つのノードの間の同じリンクを同じ方向に向かう全ての他のレッグに関して一意とする必要がある。ＬｏｃａｌＬｅｇＩＤによって一つのレッグが完全に指定される訳ではない。各ＬｏｃａｌＬｅｇＩＤはリンク及び＜ｕｐｓｔｒｅａｍ  ｎｏｄｅ，  ｄｏｗｎｓｔｒｅａｍ  ｎｏｄｅ＞ペアを特定する。例えば、
・異なる方向に向かい、かつ同じＬｏｃａｌＬｅｇＩＤを有する２つのレッグは同じレッグではなく、２つの異なるレッグであり、各レッグは異なる回線に属する。
・同じノードから異なる送信先ノードに向かい、異なるリンクから出て行き、かつ同じＬｏｃａｌＬｅｇＩＤを持つ２つのレッグも同じレッグではない。
【００１８】
従って、一つのノードに入力する方向に向かう一つのレッグは、当該レッグのＬｏｃａｌＬｅｇＩＤによってのみ指定されるのではない。一つのレッグを一意に指定するためには、一つのリンク、及び当該リンクの方向も必要となり（３倍の長さの形式＜ｄｉｒｅｃｔｉｏｎ，ＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ）、この場合、ｄｉｒｅｃｔｉｏｎは着信または発信のいずれかとすることができる。同じ回線の異なるレッグは、異なるＬｏｃａｌＬｅｇＩＤ値を有することができるので、ＬｏｃａｌＬｅｇＩＤによって一つの回線が完全に決定される訳ではない（異なるＬｏｃａｌＬｅｇＩＤ値がローカルレッグ識別子と呼ばれる所以である−識別子は、特定ノードに固有の回線レッグを指す）。
【００１９】
拡張
回線拡張は、特殊要件を持つ回線を処理する機構である。回線拡張の２つの例は、
・エンドツーエンド暗号化を必要とする回線
・音声品質のような特定のＱｏＳ要件を満たす必要のある回線
である。
【００２０】
回線拡張は、ルーティングを含む回線動作に影響を与えることができる。回線拡張は、中継ポイント及びエンドポイントの両方に任意に用いることができるか、または必要である。例えば、暗号化拡張にはエンドポイントが暗号化をサポートする必要があるが、中継ポイントはその必要はない。なぜならば、各中継ポイントは当該ポイントの発信レッグで、当該ポイントが当該ポイントの着信レッグで受信するものを単に送信するだけだからである。これとは異なり、音声品質ＱｏＳ拡張を行なう回線では、各中継ポイントが着信レッグ及び発信レッグに十分に広い帯域を持たせてエンドツーエンド音声要件を満たす必要がある。
【００２１】
全てのノードが拡張をそれぞれ実行する必要がある訳ではないが、一つの回線が特定の拡張を必要とする場合には、当該拡張をサポートしないどのノードも、当該回線に使用することができない。回線には、拡張をサポートしないノードを、当該拡張が当該回線に任意に用いられる場合に使用することができる。この場合、ノードは当該ノードのデフォルト動作を用いる。拡張が必要であり、かつノードが当該拡張をサポートしない場合、回線は設定されないことになる。
【００２２】
各拡張は固有の公知の番号に関連付けられ、この番号はＩＰの公知のポートに類似する。
回線制御パケット
６つの異なる回線パケットが存在し、これらのパケットの内の３つのパケットだけが、順方向に、または下り方向にレッグで伝送され、そしてこれらのパケットの内の３つのパケットだけが、逆方向に、または上り方向に伝送される。
【００２３】
順方向回線パケットは、
・回線を経由して実際のユーザデータを移動させる、ＣＤＡＴ（回線データ）パケット
・回線を設定する、ＣＥＳＴ（回線設定）パケット
・回線を閉鎖する、ＣＣＬＳ（回線閉鎖）パケット
を含む。
【００２４】
逆方向回線パケットは、
・回線設定の確認応答を返す、ＣＡＣＫ（回線確認応答）パケット
・回線を拒否するか、または障害を通知する、ＣＲＳＴ（回線リセット）パケット
・回線が不明であること、または回線が在ることを忘れ去られていたことを通知する、ＣＵＮＫ（回線不明）パケット
を含む。
【００２５】
ＣｏＣｏプロトコルリンクレイヤがデータパケットを受信する場合、リンクレイヤパケットヘッダの８ビットタイプフィールド（［ＢＭ］を参照）には、パケットタイプを指定する値が入っている。パケットタイプが回線レイヤパケットの上述の６つのタイプの内の一つのタイプである場合、リンクレイヤがパケットを回線レイヤに転送し、そしてパケットタイプを回線レイヤに（ＯｎＲｅｃｅｉｖｅＰａｃｋｅｔコールを利用して）直接送信する。以下のパケットタイプは、回線レイヤパケットタイプに対応するタイプフィールド値である。
【００２６】
【表１】
2009525709.tif 000003
パケットフォーマット
図８〜図１３は、回線制御パケットのパケットヘッダフォーマットのようなパケットフォーマットを示している。パケットヘッダはパケットタイプの符号化データを含まない。なぜならば、符号化データはリンクレイヤヘッダに既に含まれているからである。リンクレイヤが既にタイプを認識しているので、この情報を回線レイヤヘッダの中で繰り返す必要はない。
【００２７】
リンクレイヤは、送信元アドレス及び送信先アドレスをイーサネット／物理レイヤフレームヘッダから取得する。回線レイヤは、ｌｉｎｋＩＤ及びパケットタイプをリンクレイヤから取得し、リンクレイヤは、上位レイヤに渡す必要があるデータを物理レイヤから当該リンクレイヤで受信したときに、回線レイヤＡＰＩエントリポイント関数ＣｉｒｃｕｉｔＲｅｃｅｉｖｅＰａｃｋｅｔ（ｕ３２  ｌｉｎｋＩＤ，  ｕ８  ｔｙｐｅ，  Ｄａｔａ  ｂｕｆｆｅｒ）を呼び出す。
【００２８】
「回線制御プロセス」と題する節では、回線レイヤプロトコルが前の「回線制御パケット」と題する節で説明した回線制御パケットをどのように使用するかについて説明する。
図８に示すＣＥＳＴパケットフォーマットは、レッグの下流（受信側）ノードに向かうパケットを特定するＬｏｃａｌＬｅｇＩＤを含む。下流ノードは、パケットが到着するときに経由するリンクを検出するので、当該ノードは、どの回線を、このＣＥＳＴパケットで設定しようとしているかについて判断するために十分な情報を持ち、そしてエントリ＜ｉｎｃｏｍｉｎｇ，  ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ＞を当該ノードの回線テーブルに加える。残りのフィールドは、送信元ノード及び送信先ノードのロケーション及びサービス名を確認するために利用される。
【００２９】
「ＮｕｍＳｒｃＬｏｃＵｎｉｔｓ」は８ビットフィールドであり、８ビットフィールドは、送信元のロケーションにおけるロケーションユニットの数ｎを含む。送信元のロケーションは、ｎ個の固有ノード識別子（ＵＮＩｓ）により構成され、この場合、ｎはネットワークにおけるクラスターレベルの現在数である。クラスターに関する情報については、［ＢＬＭＳ］を参照されたい。
【００３０】
「ＮｕｍＤｅｓＬｏｃＵｎｉｔｓ」は８ビットフィールドであり、８ビットフィールドは、送信先のロケーションにおけるロケーションユニットの数ｎを含む。送信先のロケーションは、ｎ個の固有ノード識別子（ＵＮＩｓ）により構成され、この場合、ｎはネットワークにおけるクラスターレベルの現在数である。
【００３１】
「ＳｉｚｅＳｒｃＳｒｖｃＮａｍｅ」は送信元サービスの名前のバイト単位で指定されるサイズである。サービス名のサイズは、ＵＴＦ−８における当該サービス名の表示に必要なバイト数とすることができる。
【００３２】
「ＳｉｚｅＤｅｓＳｒｖｃＮａｍｅ」は、送信先サービスの名前のバイト単位で指定されるサイズである。
「Ｓｏｕｒｃｅ  Ｌｏｃａｔｉｏｎ」は、回線を表わすノードのロケーションを表現する。ロケーションは、ｎ個のＵＮＩにより構成され、この場合、ｎはＮｕｍＳｒｃＬｏｃＵｎｉｔｓフィールドにおける値である。
【００３３】
「Ｄｅｓｔｉｎａｔｉｏｎ  Ｌｏｃａｔｉｏｎ」は、回線を表わすノードのロケーションを表現する。ロケーションは、ｎ個のＵＮＩにより構成され、この場合、ｎはＮｕｍＳｒｃＬｏｃＵｎｉｔｓフィールドにおける値である。
【００３４】
「Ｓｏｕｒｃｅ  Ｓｅｒｖｉｃｅ  Ｎａｍｅ」は、送信元ノードに提供され、かつＵＴＦ−８ストリングとして表わされるサービスの名前である。
「Ｄｅｓｔｉｎａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｎａｍｅ」は、送信先ノードに提供され、かつＵＴＦ−８ストリングとして表わされるサービスの名前である。
【００３５】
図９に示すＣＡＣＫパケットフォーマットは、レッグの上流（受信側）ノードに向かうパケットを特定するＬｏｃａｌＬｅｇＩＤを含む。上流ノードは、パケットが到着するときに経由するリンクに頻繁に利用されるので、当該ノードは、どの回線を、このＣＡＣＫパケットで確認応答しようとしているかについて判断するために十分な情報を有する。
【００３６】
拡張ブロックは、（例えば、レッグのＱｏＳ機能、及び暗号化ハンドシェーク情報を含む）拡張固有のリクエストに対する拡張固有のアンサーを含む。
図１０に示すＣＤＡＴパケットヘッダフォーマットは、レッグの下流（受信側）ノードに向かうパケットを特定するＬｏｃａｌＬｅｇＩＤを含む。ＭｅｓｓａｇｅＩＤフィールドは、回線経由で送信されるパケットごとに順番に大きくなるので、受信側は、どのパケットが、そしてどの位多くのパケットが廃棄されたかを検出することができる。回線レイヤはこの情報を使用して、各レッグがサポートすることができるサービス品質を求めることができる。
【００３７】
ＣＲＳＴパケット，ＣＣＬＳパケット，及びＣＵＮＫパケットは、図１１に示すようにＬｏｃａｌＬｅｇＩＤのみから成る。他のタイプの回線パケットのパケットヘッダと同じように、タイプ自体は受信側ノードに認識されるが、これは、タイプがリンクレイヤヘッダに現われ、そしてリンクレイヤが当該タイプを回線レイヤにＯｎＲｅｃｅｉｖｅＰａｃｋｅｔ（ＬｉｎｋＩＤ，  Ｔｙｐｅ，  Ｐａｃｋｅｔ）コール関数で渡すからである。
ヘッダ圧縮機構としてのレッグ
レッグというコンセプトを知るために、レッグがローカルヘッダ圧縮機構として動作する様子を分析する。全ての回線データパケットは４タプル全体、及び関連オプションの全てを含むことができ、これらは、転送制御プロトコルがどのように動作するかを表わす。この場合、４タプル＜ｓｏｕｒｃｅ  ｎｏｄｅ，  ｓｏｕｒｃｅ  ｓｅｒｖｉｃｅ，  ｄｅｓｔｉｎａｔｉｏｎ  ｎｏｄｅ，  ｄｅｓｔｉｎａｔｉｏｎ  ｓｅｒｖｉｃｅ＞をデータパケットに取り込むために、中間ノードが関連回線に関するステート情報を維持する必要はない。４タプルをデータパケットに取り込むことにより、プロトコルを簡単にし、かつ実行し易くすることもできる。しかしながら、ステートレスな回線プロトコルでは、帯域容量をＱｏＳ管理に関して確保することができず、回線プロトコルには、大型で更に複雑なパケットに対応する更に大きな容量のメモリが必要となり、そしてルーティング決定ロジックをパケットごとに実行する必要があるので回線プロトコルの速度が非常に遅くなる。
【００３８】
概念的には、所定のリンク及び方向に関するＬｏｃａｌＬｅｇＩＤを認識することにより、一つの回線が決定される。一つのレッグはシングルホップよりも長いローカルなコンセプトであるが、（当該レッグの方向、及び当該レッグに使用されるリンクとともなう）ＬｏｃａｌＬｅｇＩＤは、回線全体を参照するために重要な要素である；「回線レイヤデータ構造」と題する節では、この要素に関する機構について説明する。このコンセプトによって、パケットごとに単一のネットワーク接続を経由して行なわれる全ての繰り返し動作を、回線が一度設定されるだけで行なうことができる。これにより、各パケットに関するルーティングロジックはテーブルルックアップを行なうだけで済むので、ロジックが高速になる。このアプローチによってＱｏＳの合意、リンク容量確保、及びエンドツーエンドの暗号化機構が可能になる。
【００３９】
回線レイヤデータ構造
回線制御プロセス仕様によれば、２つのテーブル、すなわち回線テーブル、及びレッグテーブルを各ノードに設ける必要がある。
【００４０】
回線テーブル
図１２は、或る実施形態に用いられる回線テーブルを示すブロック図である。或るノードの回線テーブルは一つのエントリを、ローカルノードを使用する各回線に対応して含む。回線は次のように４タプルで表わされる。ｃｉｒｃｕｉｔ＝＜ｓｏｕｒｃｅ  ｎｏｄｅ，  ｓｏｕｒｃｅ  ｓｅｒｖｉｃｅ，  ｄｅｓｔ  ｎｏｄｅ，  ｄｅｓｔ  ｓｅｒｖｉｃｅ＞。各回線はこの４タプルによって完全に決定される。使い勝手を良くするために、各４タプルを３２ビットＣｉｒｃｕｉｔＩＤフィールドにも関連付け、ＣｉｒｃｕｉｔＩＤフィールドによって回線を一意に決定し、そして指定する。４タプルをルックアップし、そして回線ＩＤを取得する。各回線は、ＯｐｅｎｉｎｇまたはＲｅａｄｙのいずれかであるステートを持つ。ＣｉｒｃｕｉｔＩＤ及び関連する４タプルで、それぞれ一つの回線を指定するのではあるが、ＣｉｒｃｕｉｔＩＤを維持してレッグテーブルを相互参照することが有用である。
【００４１】
レッグテーブル
図１３は、或る実施形態に用いられるレッグテーブルを示すブロック図である。レッグテーブルは一つのエントリを、ローカルノードへの着信レッグであり、かつローカルノードからの発信レッグである各レッグに対応して含む。このエントリは、レッグを含む回線のＣｉｒｃｕｉｔＩＤを含む。レッグは以下のように、３タプルで表わされる。ｌｅｇ＝＜ｄｉｒｅｃｔｉｏｎ，  ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ＞。レッグテーブルエントリは、ＣｉｒｃｕｉｔＩＤ，レッグＬ，ステートｓから成り、ＬはＣｉｒｃｕｉｔＩＤによって指定される回線の一部分であり、かつステートｓの状態になっている。
【００４２】
３つのフィールドＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎは一体となって、このテーブルの重要な一つの要素を構成するので、＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  ｄｉｒｅｃｔｉｏｎ＞のような３タプルが与えられると、関連するＣｉｒｃｕｉｔＩＤフィールド及びＳｔａｔｅフィールドを効率的に取得して、このレッグが一部分となって回線を構成することになるのはどの回線であるかについて、そしてレッグのステートについてそれぞれ判断することができる。
【００４３】
レッグテーブル及び回線テーブルは、図１４に示すように、ＣｉｒｃｕｉｔＩＤフィールドによって関連付けられる。例えば、所定のＣｉｒｃｕｉｔＩＤによって指定される一つの回線に関連付けられるレッグの全てを、当該ＣｉｒｃｕｉｔＩＤを持つレッグテーブルのエントリの全てを見付け出すことによって取得することができる。以下の概略説明では、この関係を示し、そして一つの回線が，一つのノードに入り、そして／または一つのノードから出て行く複数のレッグを有することができることを示す。
【００４４】
テーブル演算
回線テーブル及びレッグテーブルは以下の関数をサポートする：
Ｓｔａｔｅ（ＣｉｒｃｕｉｔＩＤ）
ＣｉｒｃｕｉｔＩＤが与えられると、この関数は回線のステートを返す。ステートはＯｐｅｎｉｎｇまたはＲｅａｄｙのいずれかである。回線テーブルの構造が与えられると、この演算は簡単に実行される。所定のＣｉｒｃｕｉｔＩＤを持つ回線テーブルエントリを見付け出し、そして当該エントリのステートフィールドを返す。
【００４５】
Ｓｔａｔｅ（＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  ｄｉｒｅｃｔｉｏｎ＞）
Ｓｔａｔｅ（Ｌｅｇ）
ＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎによって指定されるレッグが与えられると、この関数はレッグのステートを返す。ステートはＯｐｅｎｉｎｇまたはＲｅａｄｙのいずれかである。回線テーブルの構造が与えられると、この演算は簡単に実行される。所定のＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎを持つレッグテーブルエントリを見付け出し、そして当該エントリのステートフィールドを返す。
【００４６】
表記を分かり易くするために、ｌｅｇ＝＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  ｄｉｒｅｃｔｉｏｎ＞と表現する。ここで、ｌｅｇは３タプルの簡便な表記である。例えば、以下のように記述することができる。
【００４７】
【表２】
2009525709.tif 000004
ＵｐｄａｔｅＬｅｇＳｔａｔｅ（Ｌｅｇ，  Ｓｔａｔｅ）
この手順では、Ｌｅｇ（レッグ）のステートをＳｔａｔｅに更新する。
【００４８】
ＵｐｄａｔｅＣｉｒｃｕｉｔＳｔａｔｅ（Ｃｉｒｃｕｉｔ，  Ｓｔａｔｅ）
この手順では、Ｃｉｒｃｕｉｔ（回線）のステートをＳｔａｔｅに更新する。
ＩｎｃｏｍｉｎｇＬｅｇｓ（ＣｉｒｃｕｉｔＩＤ）
ＣｉｒｃｕｉｔＩＤが与えられると、着信レッグ集合をローカルノードに返す。レッグテーブルの構造を使用して、この演算は、レッグテーブルをｄｉｒｅｃｔｉｏｎフィールドがｉｎｃｏｍｉｎｇである所定のＣｉｒｃｕｉｔＩＤフィールドを持つ全ての行（エントリ）に関して調査し、そして該当するＬｉｎｋＩＤ／ＬｏｃａｌＬｅｇＩＤペアを返すことにより実行することができる。
【００４９】
ＯｕｔｇｏｉｎｇＬｅｇｓ（ＣｉｒｃｕｉｔＩＤ）
ＣｉｒｃｕｉｔＩＤが与えられると、発信レッグ集合をローカルノードに返す。レッグテーブルの構造を使用して、この演算は、レッグテーブルをｄｉｒｅｃｔｉｏｎフィールドがｏｕｔｇｏｉｎｇである所定のＣｉｒｃｕｉｔＩＤフィールドを持つ全ての行（エントリ）に関して調査し、そして該当するＬｉｎｋＩＤ／ＬｏｃａｌＬｅｇＩＤペアを返すことにより実行することができる。
【００５０】
ＧｅｎｅｒａｔｅＮｅｗＣｉｒｃｕｉｔＩＤ（）
この関数は、現在、ＣｉｒｃｕｉｔＩＤとして使用されていない（従って、新規の回線に対応するＣｉｒｃｕｉｔＩＤとして使用することができる）値を返す。
【００５１】
ＧｅｎｅｒａｔｅＮｅｗＬｏｃａｌＬｅｇＩＤ（）
この関数は、現在、ＬｏｃａｌＬｅｇＩＤとして使用されていない（従って、新規のレッグに対応するＬｏｃａｌＬｅｇＩＤとして使用することができる）値を返す。
【００５２】
ＡｄｄＣｉｒｃｕｉｔ（Ｓｒｃ  ｎｏｄｅ，Ｓｒｃ  ｓｅｒｖｉｃｅ，  Ｄｅｓｔ  ｎｏｄｅ，Ｄｅｓｔ  ｓｅｒｖｉｃｅ，  ＣｉｒｃｕｉｔＩＤ，  Ｓｔａｔｅ）
この演算では、一つの回線を回線テーブルに加える。
【００５３】
ＡｄｄＬｅｇ（ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  Ｄｉｒｅｃｔｉｏｎ，  Ｓｔａｔｅ，  ＣｉｒｃｕｉｔＩＤ）
この演算では、ＬｉｎｋＩＤ，ＬｏｃａｌＬｅｇＩＤ，及びｄｉｒｅｃｔｉｏｎによって指定されるレッグを、ＣｉｒｃｕｉｔＩＤによって指定される回線に加える。この演算では、ｄｉｒｅｃｔｉｏｎがｉｎｃｏｍｉｎｇまたはｏｕｔｇｏｉｎｇのいずれかである３タプル＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  ｄｉｒｅｃｔｉｏｎ＞によって表わされる新規のレッグを確立し、そしてこのレッグをレッグテーブルに加える。レッグテーブルの構造を使用して、この演算を、回線が存在することをチェックし（ＣｉｒｃｕｉｔＩＤが回線テーブルに含まれることをチェックし）、そして新規のテーブルエントリに所定のパラメータを追加することにより実行することができる。
【００５４】
ＣｉｒｃｕｉｔＩＤ（＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  ｄｉｒｅｃｔｉｏｎ＞）
ＣｉｒｃｕｉｔＩＤ（Ｌｅｇ）
３タプル＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  Ｄｉｒｅｃｔｉｏｎ＞が与えられると、当該タプルが属する回線を、関連するＣｉｒｃｕｉｔＩＤを返すことにより取得する。
【００５５】
ＣｉｒｃｕｉｔＩＤ（＜Ｓｒｃ  ｎｏｄｅ，  Ｓｒｃ  ｓｅｒｖｉｃｅ，  Ｄｅｓｔ  ｎｏｄｅ，  Ｄｅｓｔ  ｓｅｒｖｉｃｅ＞）
ＣｉｒｃｕｉｔＩＤ（Ｃｉｒｃｕｉｔ）
この関数は、回線のＣｉｒｃｕｉｔＩＤを返す。
【００５６】
ＲｅｍｏｖｅＬｅｇ（＜ＬｉｎｋＩＤ，  ＬｏｃａｌＬｅｇＩＤ，  Ｄｉｒｅｃｔｉｏｎ＞）
ＲｅｍｏｖｅＬｅｇ（Ｌｅｇ）
各回線に、ＬｅｇＩＤによって指定されるレッグが使用される場合、＜ＣｉｒｃｕｉｔＩＤ，  ＬｅｇＩＤ＞関連付けを回線テーブル及びレッグテーブルから削除する。当該関連付けが、一つの回線に関連付けられる唯一の関連付けである場合、当該回線も回線テーブルから削除される。
【００５７】
ＲｅｍｏｖｅＣｉｒｃｕｉｔ（ＣｉｒｃｕｉｔＩＤ）
この演算では、ＣｉｒｃｕｉｔＩＤによって指定される回線を回線テーブルから削除する。
【００５８】
回線制御プロセス
回線の設定及び閉鎖、及び回線経由のデータ伝送のような回線制御プロセスは、ステートマシン図か、または疑似コードフォーマットで記述することができる。ステートマシンアプローチを使用する場合、各着信レッグ及び発信レッグは、ステートマシンによって管理される。着信レッグにおけるステータス変化によって、一つ以上の新規のステートマシンが生成されて発信レッグが記述されるので、複雑さが増大する。更に、ステートマシンは、ノードが中継ポイントまたはエンドポイントのいずれであるかによって若干異なる。これらの理由により、次の節では、上位の疑似コードを使用して回線制御プロセスを指定する。
【００５９】
レッグ操作の基本
定義：ノードＹにノードＸから到達するコストをｃｏｓｔ（Ｘ，Ｙ）で表わす。
定義：ノードＳ，Ｎ，Ｄのいずれに関しても、ｄｏｗｎｈｉｌｌ（Ｓ，Ｎ，Ｄ）が、ｃｏｓｔ（Ｎ，Ｄ）＜ｃｏｓｔ（Ｓ，Ｄ）の場合に成り立つ。
【００６０】
定義：ノードＳからノードＤに達する下りリンク（ｄｏｗｎｈｉｌｌ  ｌｉｎｋ）で、ノードＳをノードＮに接続し、この場合、ｄｏｗｎｈｉｌｌ（Ｓ，Ｎ，Ｄ）が成り立つ。
１．１．１．１  ＧｅｔＤｏｗｎｈｉｌｌＬｉｎｋＳｅｔ
ノードＮで実行される回線制御プロセスがＬｉｎｋＳｅｔ＝ＧｅｔＤｏｗｎｈｉｌｌＬｉｎｋＳｅｔ（ｄｅｓｔＬｏｃａｔｉｏｎ）関数を呼び出す場合、当該プロセスは、ノードＮからｄｅｓｔＬｏｃａｔｉｏｎ（送信先ロケーション）に達する全ての下りリンクの集合を、ルーティングレイヤのＡＰＩ関数ＧｅｔＮｅｘｔＨｏｐｓ（ｄｅｓｔＬｏｃａｔｉｏｎ）を呼び出すことにより取得する。
【００６１】
１．１．１．２  ＣｒｅａｔｅＬｅｇＳｅｔ
ノードＮの回線レイヤはＧｅｔＤｏｗｎｈｉｌｌＬｉｎｋＳｅｔを呼び出してネットワーク送信先のノードＤに向かう一連の下りリンクを取得した後、当該レイヤは、ＬｅｇＳｅｔ＝ＣｒｅａｔｅＬｅｇＳｅｔ（ＬｉｎｋＳｅｔ）を呼び出してコスト効率の高い一連のレッグを取得し、これらのレッグを経由して、ノードＮの回線レイヤがＣＥＳＴパケットを送信して、ノードＤに達する回線の確立を継続する。以下の疑似コードはＣｒｅａｔｅＬｅｇＳｅｔプロシージャの概要を示す。
【００６２】
【表３】
2009525709.tif 000005
１．１．１．３  ＰｅｒＰａｃｋｅｔＬｅｇＳｅｔ
ＰｅｒＰａｃｋｅｔＬｅｇＳｅｔ（ＣｉｒｃｕｉｔＩＤ，  Ｐａｃｋｅｔ）関数は、ＣｒｅａｔｅＬｅｇＳｅｔ（）によって返されるレッグの内のどのレッグに沿って、回線レイヤがＰａｃｋｅｔ（パケット）を送信すべきかについて決定する。ＰｅｒＰａｃｋｅｔＬｅｇＳｅｔの内部ロジックは、回線のＱｏＳ要件、及び回線について考えられる他の拡張要件によって変わる。
【００６３】
Ｃｉｒｃｕｉｔ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ
或るノードがＣＥＳＴパケットを着信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＥＳＴプロシージャを実行する。
【００６４】
【表４】
2009525709.tif 000006
回線の閉鎖
或るノードがＣＣＬＳパケットを着信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＣＬＳ（ＬｅｇＩＤ）プロシージャを実行する。
【００６５】
【表５】
2009525709.tif 000007
回線のリセット
或るノードがＣＲＳＴパケットを発信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＲＳＴ（ＬｅｇＩＤ）プロシージャを実行する。
【００６６】
【表６】
2009525709.tif 000008
回線の確認応答
或るノードがＣＡＣＫパケットを発信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＡＣＫ（ＬｅｇＩＤ）プロシージャを実行する。
【００６７】
【表７】
2009525709.tif 000009
回線データ
或るノードがＣＤＡＴパケットを着信レッグで受信する場合、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＤＡＴ（ＬｅｇＩＤ）プロシージャを実行する。
【００６８】
【表８】
2009525709.tif 000010
不明の回線
或るノードがＣＵＮＫパケットを発信レッグで受信すると、当該ノードは、以下の疑似コードに概要が示されるＯｎＣＵＮＫ（ＬｅｇＩＤ）プロシージャを実行する。
【００６９】
【表９】
2009525709.tif 000011
回線レイヤのＡＰＩ
回線レイヤのＡＰＩ（アプリケーションプログラムインターフェース）は以下のプロシージャの集まりである。幾つかのプロシージャにはユーザアプリケーションプログラムがアクセスする。他のプロシージャにはリンクレイヤがアクセスする。
【００７０】
或るノードがパケットをリンクレイヤから受信すると、当該ノードは、以下の疑似コードに概要が示されるＯｎＲｅｃｖＰａｃｋｅｔ（）プロシージャを実行する。
【００７１】
【表１０】
2009525709.tif 000012
データが回線で指定タイムアウト期間の間に到着しなかった後、回線レイヤは、以下の疑似コードに概要が示されるＯｎＴｉｍｅｏｕｔプロシージャを実行する。
【００７２】
【表１１】
2009525709.tif 000013
リンクレイヤが、リンクが閉鎖したことを検出すると、リンクレイヤは、以下の疑似コードに概要が示される回線レイヤのＬｉｎｋＤｏｗｎプロシージャを呼び出す。
【００７３】
【表１２】
2009525709.tif 000014
リンクレイヤが、リンクが設定されたことを検出すると、リンクレイヤは、以下の疑似コードに概要が示される回線レイヤのＬｉｎｋＵｐプロシージャを呼び出す。
【００７４】
【表１３】
2009525709.tif 000015
ユーザアプリケーションで或る回線を、或るサービスがリモートノードで実行されるように構築すると、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＯｐｅｎプロシージャを呼び出す。
【００７５】
【表１４】
2009525709.tif 000016
ユーザアプリケーションが、当該アプリケーションで既に構築されている回線の使用を終了すると、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＣｌｏｓｅプロシージャを呼び出す。
【００７６】
【表１５】
2009525709.tif 000017
ユーザアプリケーションがデータを、当該アプリケーションで既に構築されている回線で受信すると予測される場合、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＲｅａｄプロシージャを呼び出す。
【００７７】
【表１６】
2009525709.tif 000018
ユーザアプリケーションがデータを、当該アプリケーションで既に構築されている回線で送信する必要がある場合、当該アプリケーションは、以下の疑似コードに概要が示される回線レイヤのＷｒｉｔｅプロシージャを呼び出す。
【００７８】
【表１７】
2009525709.tif 000019
関連するセマンティックのコンセプト
・回線
・回線の設定
・ハンドオフ
・エンドツーエンド接続
・単方向性
・回線レッグ
・回線の中継ポイント
・回線のエンドポイント
・回線の拡張
・サービス品質のサポート
・公知のポート
・ネットワークサービス
結論
ＣｏＣｏプロトコルの回線レイヤはＣｏＣｏネットワーク経由のエンドツーエンド接続を可能にする。回線レイヤによってマルチパス回線が可能になるので、帯域が広くなり、かつハンドオフ管理の性能が向上する。この文書では、回線レイヤで使用されるＡＰＩ（アプリケーションプログラムインターフェース）及びパケットフォーマットについて要約している。
【００７９】
回線レイヤは少なくともこれらの機能を提供する：
１．適応的自動調整回線を、スケーラブルかつ動的である均質な通信ネットワークにおいて設定する方法。プロトコルという用語は、これに関連して方法と同じ意味に使用される。
（ａ）通信ネットワークは、データを互いに対して送信し、そして互いから受信する機能を備える通信デバイスの集合体である。ネットワークデバイスまたはネットワークノードは、プロトコルソフトウェアを実行するために十分な計算能力を持ついずれかのデバイス、及び他のデバイスとの接続を確立する手段である。
（ｂ）均質な通信ネットワークは、複数タイプのネットワークデバイス、及び複数タイプの通信リンクの集合体から成る通信ネットワークである。別の表現をするト、ネットワークはハイブリッドネットワークであり、ハイブリッドネットワークは、異なるタイプ及び製造業者のデバイスから成り、これらのデバイスとして（これらには制限されないが）、携帯電話機、ラップトップコンピュータ、携帯情報端末を挙げることができ、これらのデバイスは互いに有線接続または無線接続によって接続され、これらの接続は（これらには制限されないが）、ＷｉＦｉリンク，イーサネットリンク、衛星リンク、及びセルラーリンクを含む種々の下位の転送機構のいずれかによって確立することができる。均質である（１種類のデバイス及び／又は１種類の転送機構により全体が構成される）ネットワークは均質な通信ネットワークの特殊事例である。
（ｃ）動的ネットワークによってデバイスは、これらの通信デバイスのユーザの意のままに任意の時点で、かつデバイスが地理的に移動するいずれの場所でもオン及びオフすることができる。
（ｄ）スケーラブルなネットワークとは、ネットワークにおける通信デバイスの数が増大するときに、正しく、かつ効率的に動作し続けるネットワークである。
２．回線を通信ネットワークにおいて管理する方法。
３．回線のハンドオフを、動的な変化がネットワーク形態に発生している状態で管理する方法。
４．回線を、サービス品質が保証されるレベルで実現する方法。
５．回線を、エンドツーエンドセキュリティが保証されるレベルで実現する方法。
６．マルチキャスト回線を確立する方法。
７．エンドツーエンド回線を、ＣｏＣｏクラスタリング方法に関する特許請求項に記載される下位のルーティングレイヤを利用して作成する方法。
８．回線を、回線テーブル及びレッグテーブルとして知られる関係テーブルを使用して管理する方法。
【００８０】
これまでの記述から、本発明の特定の実施形態について本明細書において説明して例示を行なってきたが、種々の変更を本発明の技術思想及び技術範囲から逸脱しない限り加え得ることを理解できるであろう。従って、本発明は、添付の請求項によって規定される以外には制限されない。
【図面の簡単な説明】
【００８１】
【図１】種々の実施形態におけるＣｏＣｏ通信プロトコルの種々のネットワークアーキテクチャレイヤを示すブロック図である。
【図２】種々の実施形態における回線レイヤと他のレイヤとの間のインターフェースを示すブロック図である。
【図３】種々の実施形態における複数のネットワーク経路を示すブロック図である。
【図４】或る実施形態における回線レッグを示すブロック図である。
【図５】或る実施形態におけるネットワークパケットの方向性を示すブロック図である。
【図６】種々の実施形態におけるエンドポイント及び中継ポイントを示すブロック図である。
【図７】２つの回線の一つのエンドポイントとして動作するネットワークノードを示すブロック図である。
【図８】或る実施形態において用いられるＣＥＳＴパケットフォーマットを示すブロック図である。
【図９】或る実施形態において用いられるＣＡＣＫパケットフォーマットを示すブロック図である。
【図１０】或る実施形態において用いられるＣＤＡＴパケットフォーマットを示すブロック図である。
【図１１】或る実施形態において用いられるＣＲＳＴ，ＣＣＬＳ，及びＣＵＮＫパケットフォーマットを示すブロック図である。
【図１２】或る実施形態において用いられる回線テーブルを示すブロック図である。
【図１３】或る実施形態において用いられるレッグテーブルを示すブロック図である。
【図１４】回線テーブルとレッグテーブルとの関係を示すブロック図である。
【図１】
2009525709.tif 000020
【図２】
2009525709.tif 000021
【図３】
2009525709.tif 000022
【図４】
2009525709.tif 000023
【図５】
2009525709.tif 000024
【図６】
2009525709.tif 000025
【図７】
2009525709.tif 000026
【図８】
2009525709.tif 000027
【図９】
2009525709.tif 000028
【図１０】
2009525709.tif 000029
【図１１】
2009525709.tif 000030
【図１２】
2009525709.tif 000031
【図１３】
2009525709.tif 000032
【図１４】
2009525709.tif 000033
【国際調査報告】
2009525709.tif 000034