JP2006333461A - Ｔｒｉｐプロトコルを使用する回線交換／パケット交換結合通信ネットワークにおけるピアリング及びルーティングの自動発見システム及び自動発見方法 - Google Patents

Abstract

【課題】回線交換の終端とパケット交換の終端との間の通信を制御する。
【解決手段】ＩＰ電話通信管理ドメイン（ＩＴＡＤ（IP Telephony Administrative Domain））間のルーティングに必要とされる情報が、ロケーションサーバ１７によって自動的に収集される。このロケーションサーバは、リスンオンリーモード(listen-only mode)で動作し、且つ、ＴＲＩＰインタードメインプロトコルでピアリング(peering)される。ピアリングされたロケーションサーバは、ＴＲＩＰプロトコルを使用してルーティング情報を発見する。それによって、内部電話及び外部の電話通信経路の双方の経路データの自動更新が可能になる。一実施形態では、ピアリングされたルータは、サービスプロバイダのルーティングの最新の状況を把握し、収集されたデータにタイムスタンプを付ける。それによって、履歴ＴＲＩＰ性能情報の収集及び利用が可能になる。
【選択図】図１

Description

本発明は、回線交換／パケット交換結合電話ネットワークに関し、より詳細には、電話終端ポイント間のルーティング構成及びピアリング構成を動的に確立することに関する。

これまでの電気通信サービスプロバイダは、それらプロバイダの既存の通信トラフィックを、回線交換ネットワーク（たとえば、ＧＳＴＮ）からパケット交換ネットワーク（たとえば、ＩＰネットワーク）へ移行させる過渡期にある。しかしながら、回線ベースのネットワークからパケットベースのネットワークへの移行は、主に現在の基盤（インフラ）に巨額の投資をしていることから、かなりの時間を要する可能性がある。移行期間中、いずれか一方の技術を使用する顧客が相互に通信できるようにする必要がある。たとえば、既存のＧＳＴＮの顧客が、インターネット電話を有する顧客に対し、その顧客のケーブルプロバイダに接続された音声インターネットプロトコル（ＶｏＩＰ）電話を使用して音声通話をしたい場合があるし、その逆の場合もある。

この通信を行うために、メディアゲートウェイ(media gateway)として知られているインターワーキング(inter-working)装置が、回線ベースの世界とパケットベースの世界との間をインターフェースするのに使用される。メディアゲートウェイは、ＧＳＴＮを送信元とする呼(call)を取り扱う回線ベースのトランク(trunk)を終端させ、そのコンテンツを、インターネットプロトコル（ＩＰ）ネットワークにわたって通過できるリアルタイム転送プロトコル（ＲＴＰ）ストリームに変換して、ＩＰベースの端末デバイス又は他のメディアゲートウェイのいずれかへ直接配信する。該他のメディアゲートウェイは、今度は、ＲＴＰストリームをＧＳＴＮの呼に変換して戻す。また、メディアゲートウェイは、ＧＳＴＮの顧客宛ての、ＩＰを送信元とする呼も変換することができる。

サービスプロバイダは、これらメディアゲートウェイの到達可能性に関する情報、及び、メディアゲートウェイがＧＳＴＮベースのネットワークとＩＰベースのネットワークとの間で呼を正確にルーティングできる場合には該メディアゲートウェイからアクセス可能な顧客に関する情報、を共有する必要がある。インターネットエンジニアリングタスクフォース（ＩＥＴＦ）は、２００２年１月に、ＩＰ上の電話通信ルーティング（ＴＲＩＰ（Telephony Routing Over IP））として知られているプロトコルを定義し、ＲＦＣ３２１９コメント要求(RFC3219 Request For Comments)に規定した。このコメント要求の文書は、本明細書で参照され（その一部は本明細書の付録Ａに含まれる）、電話通信ルーティング及びメディアゲートウェイの知識のこの共有を自動化するのに役立つ。これに加えて、ＩＥＴＦ内では、２００４年９月のＲＦＣ３８７２コメント要求に示すように、ネットワーク管理を目的として、ＴＲＩＰ対応デバイスのためのシンプルネットワーク管理プロトコル（ＳＮＭＰ）管理情報ベース（ＭＩＢ）を確立する作業が進行中である。このコメント要求の文書は、本明細書で参照される。これらのプロトコルは、ルーティング制御用に設計されているが、そのネットワークの健全性及び安定性の判断、又は、追加資源若しくは他の呼の経路を確立しなければならないかどうかの判断をどの時点でもネットワークが行えるように、ネットワークを追跡することには対応していない。

ネットワーク間の電話通信ルーティング情報を通信するための１つの方法は、手動でその情報を収集して配布することである。しかしながら、このような手動の手法は、その過程でヒューマンエラーの可能性を持ち込み、ピアリング(peering)情報の収集及び配布が不正確になる可能性があり、ＧＳＴＮの顧客グループがＩＰの顧客と通信できなくなる可能性がある。その逆の場合も同様である。これによって、収益が失われる可能性があり、この問題が有効に処置されない場合、最終的には、顧客の「不満」は増加する可能性がある。生のデータを手動で互いに相関させることによって、手動によるエラーの可能性が増加するという問題が、手動のプロセスを使用する問題を増大させている。結局のところ、手動プロセスに伴うタイムスケール、又は、手動プロセスにより持ち込まれるエラー数によって、このような手法のスケーラビリティ及び柔軟性が制限されることになる。

本発明の一実施形態では、ＩＰ電話通信管理ドメイン（ＩＴＡＤ（IP Telephony Administrative Domain））間のルーティングに必要とされる情報が、ロケーションサーバによって自動的に収集される。このロケーションサーバは、リスンオンリーモード(listen-only mode)で動作し、且つ、ＴＲＩＰインタードメインプロトコルでピアリング(peering)される。ピアリングされたロケーションサーバは、ＴＲＩＰプロトコルを使用してルーティング情報を発見する。それによって、内部電話通信経路及び外部電話通信経路の双方の経路データの自動更新が可能になる。一実施形態では、ピアリングされたルータは、サービスプロバイダのルーティングの最新の状況（picture）を把握し、収集されたデータにタイムスタンプを付ける。それによって、履歴ＴＲＩＰ性能情報の収集及び利用が可能になる。このような履歴解析に基づき、サービスプロバイダは、たとえば、その最も信頼できるピア(peers)、ピアリング経路、不安定な経路、利用不能な経路等を追跡することができる。

次に、本発明をより完全に理解するために、添付図面と共に取り入れられた以下の説明を参照する。

図１は、２つのＩＰ電話通信管理ドメイン（ＩＴＡＤ）間のルーティングの変化を追跡するための、本発明の概念を使用するシステムの一実施形態１０を示している。この実施形態１０は、２つのＩＴＡＤを示している。これら２つのＩＴＡＤは、互いにデータを通信する目的で相互接続されており、各ＩＴＡＤは、情報をどのようにルーティングすれば、他方のＩＴＡＤの宛先に到達するかを知っている。ＩＴＡＤ１１では、回線交換ラインは、ゲートウェイ１３−１〜１３−４（ＧＷ１〜ＧＷ４）等のゲートウェイで終端される。

図示した実施形態では、ゲートウェイ１３−１は、市外局番４１５−６００−００００から４１５−９９９−９９９９までの間の７桁を有するすべての回線交換の呼(call)を終端し、同様に、ゲートウェイ１３−４は、４０８−２００−００００から４０８−５９９−９９９９までの間の電話番号を有する回線交換ラインを制御する。さらに、ＩＴＡＤ１４では、ゲートウェイ１６−１が、回線交換電話番号９１６−３５０−００００から９１６−５５０−９９９９の呼を制御する。こうして、たとえば電話番号４１５−６００−１２３４宛ての、ＩＴＡＤ１４を介して到来した呼は、ＩＴＡＤ１１のゲートウェイ１３−１に送信しなければならない。

ＩＴＡＤ１１のロケーションサーバ１２−１及び１２−２や、ＩＴＡＤ１４のロケーションサーバ１５−１等の各ＩＴＡＤのロケーションサーバは、所望の電話番号４１５−６００−１２３４がＩＴＡＤ１１外でサービスされることを知る必要がある。ロケーションサーバ１５−１がこの情報を有するためには、該サーバ１５−１は、ＩＴＡＤ１１のロケーションサーバ１２−１から情報を受信しなければならない。これは、ＴＲＩＰプロトコルのインタードメイン(inter-domain)の使用を通じて達成される。

ＴＲＩＰアーキテクチャによれば、サービスプロバイダは、そのサービスエリアを１つ又は複数のＩＴＡＤに分割する。これら１つ又は複数のＩＴＡＤは、そのサービスプロバイダのオペレーションエリア内における電話通信ピアリング及びルーティングの管理及び制御に関して、独立したエンティティとして動作する。ＴＲＩＰプロトコルは、ボーダゲートウェイプロトコル（ＢＧＰ(Border Gateway Protocol)）に基づいている。しかしながら、ＢＧＰと異なり、フルメッシュトポロジー(full mesh topology)又はそれらのトポロジーに伴うルートリフレクタ（route reflector）は必要とされない。

上述したように、ＴＲＩＰプロトコルは、２００２年１月付けのネットワークワーキンググループの文書に記載されている。この文書は、インターネット学会(Internet Society (2002))による著作権を伴う。この出願の付録Ａは、その文書の、この出願に含まれる本発明概念の開示の理解に関連した部分を含む。

動作の際、ＩＴＡＤ１１のロケーションサーバ１２−１は、インタードメインＴＲＩＰを使用して、ＩＴＡＤ１１内のゲートウェイ１３−１〜１３−４によりサービスされる（該ゲートウェイが受け持つ）電話番号に関して、ＩＴＡＤ１４のロケーションサーバ１５−１を更新する。こうして、たとえば、ゲートウェイ１３−１によりサービスされる電話番号の或る部分が、異なるロケーションサーバに移動した場合、又は、ゲートウェイが何らかの理由で利用不能になったりオフラインになったりした場合、その情報は、インタードメインＴＲＩＰを介してロケーションサーバ１５−１に提供される。同様に、ＩＴＡＤ１４のロケーションサーバ１５−１は、９１６市外局番のうち、ＩＴＡＤ１４によりサービスされる部分の更新に関係したインタードメインＴＲＩＰメッセージを、ＩＴＡＤ１１のロケーションサーバ１２−１へ送信する。ＴＲＩＰプロトコルの下では、ＬＳ（ロケーションサーバ）１２−２は、ＬＳ１２−１を更新する（且つ、ＬＳ１２−１によって更新される）。これについては、たとえば、付録Ａの第１４ページを参照されたい。

本発明の一実施形態によれば、ＩＴＡＤ１１及び／又はＩＴＡＤ１４等の少なくとも１つのＩＴＡＤには、ロケーションサーバ１７及び１８もそれぞれ配置される。これらのロケーションサーバは、ロケーションサーバ１２−１から送出された更新及び１２−１に入来する更新をリスンする(listen)ように、リスンオンリー(listen-only)となるように設計され（ＴＲＩＰプロトコルに従って。たとえば、付録Ａの第１４ページを参照されたい）、その結果、ロケーションサーバ１７は、インタードメイン通信に関してはサイレント(silent、沈黙)を維持すると同時に、ＩＴＡＤ１１によりサービスされる電話番号の対応するゲートウェイのロケーションのそれぞれの正確な実時間のリストを保持する働きをする。同様に、ロケーションサーバ１８（もし設けられるならば）も、ＩＴＡＤ１４に関して同じ機能を実行し、ＩＴＡＤ１４が見るようなネットワークの現在のトポロジーの正確なリストを保持できるように、最新のトランザクションを常時監視する。後ろ向き検索を行って任意の所与の時刻におけるネットワークの状態又は所与の期間にわたるネットワークの状態を判断できるように、リスンオンリーロケーションサーバのエントリーのそれぞれを、必要に応じて、時間符号化(time coded)することができる。制御システム１０１を、ネットワークを追跡する目的で記憶された情報を収集するのに使用することができる。

制御システムは、ＬＳ１７（及び／又はＬＳ１８）に記憶された情報を使用して、ネットワークで最も信頼できるロケーションサーバはいずれであるか、どのＬＳが最も多くの経路を公表しているか、どれが最も多くの経路を除去しているか等の情報を作り出すことができる。この情報のいずれも、このプロトコルで直接運ばれるものではなく、リスナ(listener)によって導き出される（推論）されるものである。

次に図２に移って、プロセス制御を示すフロー図の一実施形態２０を示す。このフロー図のように、プロセス２０１は、当該プロセスが監視しているドメインのＴＲＩＰロケーションサーバとの受信オンリー(receiving only)のピア接続を確立する。このケースでは、ＩＴＡＤ１１に関して、ロケーションサーバ１７（図１）は、ロケーションサーバ１２−１との間に、ＴＲＩＰピアリング(peering)セッションを確立する。

プロセス２０２は、接続の確立が成功したかどうかを判断する。成功しなかった場合、プロセス２０３はタイムアウトし、プロセス２０１を介して再確立が再び試みられる。

プロセス２０４は、ＴＲＩＰパケットの到着を待機する。ＴＲＩＰパケットが通知(notification)メッセージである場合、システムは、プロセス２０３を介して再びタイムアウトし、２０１、２０２、及び２０４のようなプロセスが繰り返される。これが行われる理由は、通知メッセージがＴＲＩＰプロトコルのエラー状態を示すものであり、そのピア接続を解除する必要があるからである。

ＴＲＩＰパケットが通知メッセージでない場合（プロセス２０５）、プロセス２０６は、そのパケットがＵＰＤＡＴＥメッセージ（更新メッセージ）であるかどうかを判断する。更新メッセージが受信された場合、プロセス２０７は、取り消された経路(withdrawn route)がそのメッセージにあるかどうかを判断し、読み出しオンリーサーバによって保持された一組の操作統計値（operational statistics）を更新する。プロセス２０８は、取り消された経路をルーティングデータベースから除去し、プロセス２１１は、該除去された経路データにタイムスタンプを付ける。次に、プロセス２０９は、到達可能な経路（reachable route, 新たに追加された経路）がメッセージにあるかどうかを判断する。到達可能な経路がない場合、システムは、新たなＴＲＩＰメッセージ２０４を待つ。到達可能な経路がメッセージにある場合、それは新たな経路が追加されたことを意味し、その新たな経路は、プロセス２１０を介してルーティングデータベースに追加され、この場合も、プロセス２１１は、その追加されたデータにタイムスタンプを付ける。プロセス２１２は、その時々にストレージ（記憶装置）からデータを収集し、読み出しオンリーロケーションサーバによって保持された一組の操作統計値が更新される。計算することのできる統計値のうちのいくつかは、経路、ゲートウェイ、及びロケーションサーバの利用可能性／利用不能性である。これらのエンティティのそれぞれを、「利用可能」又は「利用不能」のいずれかとすることができる。これらのエンティティが最後に状態間を遷移してから各状態でどれだけの時間が費やされたか、及び、測定が開始されてから全体としてどれだけの時間が費やされたかを記録することによって、各エンティティについて可能な測定は４つあり、よって、３つのすべてのエンティティについては合計１２個の測定となる。ゲートウェイの該４つの測定値の例は、最後の状態遷移からの経路の利用可能性、経路の全体的な利用可能性、最後の状態遷移からの経路の利用不能性、及び経路の全体的な利用不能性である。

これらの測定を明確にするのを助けるために、以下の例を取り上げる。市外局番４０８の経路を観察する監視システムを仮定し、該経路が、まず午後１２：００に利用可能にされ、午後１：００に除去され、次いで、午後２：００に回復されたとする。４つの利用可能性／利用不能性の測定が午後４：００に行われた場合、以下の結果が計算される。すなわち、最後の遷移からの４０８の経路の利用可能性＝２時間、４０８の全体的な経路の利用可能性＝３時間、最後の遷移からの４０８の利用不能性＝０時間、４０８の全体的な経路の利用不能性＝１時間、が計算される。

ゲートウェイは、その関連した経路のすべてが取り消された場合に利用不能になると仮定される。ロケーションサーバの利用可能性／利用不能性は、ＴＲＩＰ ＵＰＤＡＴＥメッセージのＩＴＡＤトポロジー属性を観察することによって計算されることができる。

経路、ゲートウェイ、及びロケーションサーバの信頼性：エンティティの全体的な利用可能性が、エンティティが利用可能であった時間及び利用不能であった時間の合計によって除算される場合、利用可能であった時間の割合が得られる。これが、そのエンティティの信頼性の指標となる。同様に、エンティティが利用可能であった時間及び利用不能であった時間の合計によって除算されたエンティティの全体的な利用不能性は、そのエンティティが利用不能であった時間の割合を与える。これが、そのエンティティの非信頼性の指標となる。これは、経路、ゲートウェイ、及びロケーションサーバの３つのエンティティについて合計６つの測定になる。前の例を使用すると、計算は、午後４：００における４０８の経路の利用可能性及び利用不能性から行われることができ、利用可能性は７５％となり、利用不能性は２５％となる。

ゲートウェイ及びロケーションサーバによる最も新しく追加された経路の公表：この測定には２つのバリエーションがある。すなわち、測定システムが起動してからの追加された経路の個数をカウントする絶対バージョン、及び、或る特定の時間間隔において（たとえば、１時間あたりの）追加された個数をカウントする相対バージョンがある。これは、ゲートウェイ及びロケーションサーバのそれぞれに２つの測定となり、合計４つの測定になる。

ゲートウェイ及びロケーションサーバ当たりの経路の追加率：該相対的な形式の追加された経路測定の導関数を求めることによって、ゲートウェイ及びロケーションサーバの双方への経路の追加の変化率を計算することが可能である。これは、合計２つの新たな測定になる。

ゲートウェイ及びロケーションサーバによる最も除去された経路の公表(announcing)：この測定には２つのバリエーションがある。すなわち、測定システムが起動してからの除去された経路の個数をカウントする絶対バージョン、及び、或る特定の時間間隔において（たとえば、１時間あたりの）除去の個数をカウントする相対バージョンがある。これは、ゲートウェイ及びロケーションサーバのそれぞれに２つの測定となる、合計４つの測定になる。

ゲートウェイ及びロケーションサーバ当たりの経路の除去率：該相対的な形式の除去された経路測定の導関数を求めることによって、ゲートウェイ及びロケーションサーバの双方からの経路の除去の変化率を計算することが可能である。これは、合計２つの新たな測定になる。

次に、プロセスは、プロセス２０４を介して次のＴＲＩＰパケットの到着を待機する。これらのプロセスは、ＩＴＡＤ１１のロケーションサーバ１７等のリスンオンリーロケーションサーバが、常時、ロケーションサーバ１２−１によって使用されているルーティングの「写真(photograph)」を維持するように、続行される。

ロケーションサーバ１７によって編集（コンパイル）されたデータを、保持目的のために、又は、ネットワークの実時間の制御若しくは追跡のために、制御システム１０１によってダウンロードすることもできるし、読み出すこともできる。制御システム１０１は、ＩＴＡＤ１１に対するローカルなものとして、ＩＴＡＤ１１のみを受け持つ（サービスする）こともできるし、必要に応じて、いくつかのＩＴＡＤを受け持つこともできる（図示しない有線又は無線によって互いに接続されるＩＴＡＤ）。或いは、制御システム１０１は、すべてのＩＴＡＤの外部に配置されて、それらＩＴＡＤの１つ又は複数を受け持つこともできる。制御システム１０１は、必要に応じて、ＬＳ１７の一部とすることもできる。

ピアリングされたリスンオンリーロケーションサーバのネットワーク発見メカニズムをＴＲＩＰアーキテクチャ及びＳＮＭＰに基づくものとすることにより、サービスプロバイダのメディアゲートウェイのピアリング構成を発見するのに必要なプローブの個数が制限される。これは、１つのＩＴＡＤ当たり１つのプローブしか必要とされないからである。このプローブは、ＩＴＡＤのピアリング構成全体を発見するのに、そのＩＴＡＤにおけるＬＳ(s)のうちの１つで問い合わせしさえすればよい。

さらに、この発見メカニズムは、生成されている音声の呼を制御するのにサービスプロバイダ内で使用される特定のシグナリングプロトコル（たとえば、Ｈ．３２３又はＳＩＰ）からは独立している。これは、複数のシグナリングプロトコルと共に、同じプローブをネットワークで使用できることを意味する。

本発明及びその利点を詳細に説明したが、特許請求の範囲によって画定された本発明の精神及び範囲から逸脱することなく、さまざまな変更、置換、及び改変を本明細書において行えることが理解されるべきである。その上、本出願の範囲は、本明細書で説明したプロセス、マシン、製造物、合成物、手段、方法、及びステップの特定の実施の形態に限定されることを目的としていない。当業者は本発明の開示から容易に理解するように、本明細書で説明した対応する実施の形態と実質的に同じ機能を実行するか、又は、実質的に同じ結果を達成する、現在存在するか又は後に開発されるプロセス、マシン、製造物、合成物、手段、方法、又はステップは、本発明に従って利用することが可能である。したがって、特許請求の範囲は、このようなプロセス、マシン、製造物、合成物、手段、方法、又はステップをその範囲内に含むことを目的としている。

［付録Ａ］
＜第３ページ＞
以下は、ネットワークワーキンググループのコメント要求：３２１９文書から取り入れたものである。２００２年１月付けのＩＰ上の電話通信ルーティング（ＴＲＩＰ(Telephone Routing over IP）を購入されたい。ここで参照されるページ番号及び段落番号は、上記で特定した文書のページ番号である。この文書の総ページ数は７１ページである。
ＴＲＩＰの機能は、電話通信の宛先の到達可能性、それら宛先に関連した属性、及びそれら宛先に向かう経路（path、パス）の属性を宣伝する(advertise)ことである。
ＴＲＩＰの宛先：ＴＲＩＰは、複数のプロトコル（ＳＩＰ、Ｈ３２３等）のルーティングテーブルを管理するのに使用されることができる。ＴＲＩＰでは、宛先は、（ａ）１組のアドレス（アドレスファミリー及びアドレスプリフィックスによって与えられる）と、（ｂ）アプリケーションプロトコル（ＳＩＰ、Ｈ３２３等）と、を組み合わせたものである。
ゲートウェイロケーション及びルーティングの問題が［２］で紹介されている。この問題は、ＩＰ電話通信では、より困難な問題の１つと考えられている。ＰＳＴＮの最終的な宛先に向かってＩＰネットワークを横断する電話通信呼の出口ゲートウェイの選択は、主に、パスに沿ったさまざまなパーティのポリシーと、これらのパーティ間に確立された関係とによって推進される。このように、ユーザが宛先の電話番号を調べる出口ゲートウェイのグローバルディレクトリは、適した解（ソリューション）ではない。むしろ、出口ゲートウェイの利用可能性に関する情報は、プロバイダ間で交換され、ポリシーが適用され、ローカルに利用可能にされ、次いで、他のＩＴＡＤＳの他のプロバイダに伝播され、こうして、これらの出口ゲートウェイに向かう経路が作成される。これによって、各プロバイダは、到達可能な電話番号及び関連した経路の、それ自身のデータベースを作成することが可能になる。このようなデータベースは、ポリシーに依存した各プロバイダにとって非常に難しいものとなりうる。
ＴＲＩＰは、インタードメイン（すなわち、インターＩＴＡＤ）ゲートウェイロケーション及びルーティングのプロトコルである。ロケーションサーバ（ＬＳ）と呼ばれるＴＲＩＰスピーカの主要な機能は、他のＬＳと情報を交換することである。この情報は、ＰＳＴＮに存在する電話通信の宛先の到達可能性、これらの宛先に向かう経路、及びそれら電話通信の宛先に向かうゲートウェイに関する情報を含む。ＴＲＩＰの要件は［２］で説明されている。
ＬＳは、ルーティングのループを防止できるように、必要なルーティング情報を交換してＩＴＡＤ接続グラフを構築する。さらに、ＴＲＩＰは、ポリシーを適用すると共に、パス又はゲートウェイの特性に基づいて経路を選択するのに必要な属性を交換するのに使用されることができる。この仕様は、ＴＲＩＰの転送メカニズム及び同期メカニズム、その有限状態マシン、並びにＴＲＩＰデータを定義する。この仕様はまた、ＴＲＩＰの基本的属性を定義する。ＴＲＩＰの属性セットは拡張可能であり、したがって、今後の文書に属性を追加して定義することができる。

＜第４ページ＞
経路がネットワークを通じて宣伝される(advertise)と、ＴＲＩＰによって、経路を集約する(aggregation)ことが可能になる。ＴＲＩＰは、特定の経路選択アルゴリズムを定義しない。
ＴＲＩＰは、信頼できる転送プロトコル上で実行される。これによって、明示的(explicit)なフラグメンテーション、再送、肯定応答、及びシーケンス化（sequencing）を実施する必要がなくなる。ＴＲＩＰで使用されるエラー通知メカニズムは、その転送プロトコルが優雅なクローズをサポートすることを前提とする。すなわち、接続がクローズされる前にすべての未処理のデータが配信されることを前提とする。
ＴＲＩＰのオペレーションは、どの特定の電話通信シグナリングプロトコルからも独立している。したがって、ＴＲＩＰは、たとえばＨ３２３［７］及びＳＩＰ［８］といったこれらのプロトコルのいずれかのルーティングプロトコルとして使用されることができる。
ＬＳピアリングトポロジーは、ネットワークの物理トポロジーから独立している。さらに、ＩＴＡＤの境界は、レイヤ３のルーティング自律システム(routing autonomous system)の境界から独立している。内部のＴＲＩＰのピアも外部のＴＲＩＰのピアも、物理的に隣接している必要はない。

３．オペレーションの概要
このセクションは、ＴＲＩＰのオペレーションの概要を述べる。詳細は後のセクションで提供される。
３．１．ピアリングセッションの確立及び維持
２つのピアなＬＳは、相互間の転送プロトコル接続を形成する。それらＬＳは、オープンして接続パラメータを確認するためのメッセージ、並びに、各ＬＳの機能及びこの接続上で宣伝される情報のタイプを交渉するためのメッセージを交換する。
ＫｅｅｐＡｌｉｖｅメッセージは、定期的に送信されて、隣接するピアが動作可能であることを確保する。Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ（通知メッセージ）は、エラー状態又は特別な状態に応じて送信される。接続がエラー状態に遭遇した場合、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージが送信され、接続がクローズされる。

＜第５ページ＞
３．２．データベース交換
ピア接続が一旦確立されると、初期データフローは、その新しいピアに関連したすべての経路のダンプ(dump)である（外部ピアの場合、その外部ピアのＬＳのＡｄｊ−ＴＲＩＢ−Ｏｕｔのすべての経路。内部ピアの場合、Ｅｘｔ−ＴＲＩＢ及びすべてのＡｄｊ−ＴＲＩＢｓ−Ｉｎのすべての経路）。異なるＴＲＩＢが、３．５．のセクションで定義されることに留意されたい。
付加的な更新が、ＴＲＩＰルーティングテーブル（ＴＲＩＢ）の変更として送信される。ＴＲＩＰは、経路の定期的なリフレッシュを要しない。したがって、ＬＳは、すべてのルーティングエントリーの現在のバージョンを保持しなければならない。
或る特定のＩＴＡＤが複数のＬＳを有し、他のＩＴＡＤの通過サービスを提供している場合、該ＩＴＡＤ内のルーティングの一貫した見え方(view)を確保するように注意しなければならない。すべての内部ピアのＴＲＩＰルーティングテーブル、すなわちＬｏｃ−ＴＲＩＢは、同期されると、同一となる。

３．３．内部同期対外部同期
ＢＧＰと同様に、ＴＲＩＰは、内部ピアと外部ピアとを区別する。ＩＴＡＤ内では、内部ＴＲＩＰは、リンク状態メカニズムを使用して、任意のトポロジー上にデータベースの更新をフラッド(flood)させる。外部では、ＴＲＩＰは、ポイントツーポイントのピアリング関係を使用してデータベース情報を交換する。
内部同期を達成するために、内部ピア接続は、同じＩＴＡＤのＬＳ間において、結果として生じるイントラドメインＬＳトポロジーが接続されて十分な冗長性を有するように、構成される。これは、すべての内部ピアがフルメッシュトポロジーで接続されていることを必要とするＢＧＰの手法とは異なる。フルメッシュトポロジーは、結果的にスケーリング(scaling)問題になるおそれがある。更新が内部ピアから受信されると、該更新の経路がチェックされて、それら経路が、データベースにすでにあるバージョンよりも新しいかどうかが判断される。次に、より新しい経路は、同じドメインの他のすべてのピアにフラッドされる。

３．４．ＴＲＩＰ経路の宣伝
ＴＲＩＰでは、経路が、（ａ）一組の宛先アドレス（アドレスファミリーインジケータ及びアドレスプレフィックスによって与えられる）と、（ｂ）アプリケーションプロトコル（たとえば、ＳＩＰ、Ｈ３２３等）と、を組み合わせたものとして定義される。一般に、各経路に関連した追加の属性がある（たとえば、次のホップサーバ）。

＜第６ページ＞
ＴＲＩＰの経路は、ＵＰＤＡＴＥメッセージで一対のＬＳ間に宣伝される。宛先アドレスは、該ＵＰＤＡＴＥの属性である到達可能経路（ReachableRoute）に含まれ、他の属性は、パス又は出口ゲートウェイといったものを記述する。
ＬＳがＴＲＩＰ経路を宣伝することを選択した場合、そのＬＳは、その経路をピアに宣伝する前にその経路の属性を増やしたり、又は変更することができる。ＴＲＩＰは、ＬＳが、そのピアに、先に宣伝された経路がもはや利用可能でないことを通知できるメカニズムを提供する。或る経路がサービスから取り消されたことを所与のＬＳが示すことができる方法には、３つある。
−ＵＰＤＡＴＥメッセージの取り消し経路属性（WithdrawnRoutes Attribute）にその経路を含める。こうして、関連した宛先がもはや利用可能でないとして印を付ける。
−到達可能属性（ReachableRoutes Attribute）において、同じ一組の宛先を有する取り替え経路(replacement route)を宣伝する。
−フラッディング(flooding)を使用しない外部ピアの場合、ＬＳ対ＬＳピア接続をクローズすることができる。これによって、一対のＬＳがそのピアセッション上で互いに宣伝したすべての経路は、暗黙的に、サービスから除去される。フラッディングのため、複数の内部ピアから同じ経路が受信されている場合があるので、内部ピアリングセッションを終了することによって、ピアＬＳにより宣伝された経路が必ずしも除去されるとは限らないことに留意されたい。或るＬＳが、（他の内部ピアからのＵＰＤＡＴＥメッセージのＩＴＡＤトポロジー属性から）別の内部ＬＳがもはやアクティブでないと判断すると、その或るＬＳは、その別のＬＳによって作り出された該別のＬＳへのすべての経路を除去し、その決定プロセスに戻らなければならない。

＜第８ページ＞
３．７．集約(aggregation)
集約は、ＬＳがそのピアと同期させなければならないルーティングエントリーの個数を削減するために該ＬＳによって使用されるスケーリング強化である。集約は、ＬＳのＴＲＩＢに一組の経路｛Ｒ１，Ｒ２，…｝があるときに、該ＬＳによって実行されることができる。該実行は、Ｒのあらゆる有効な宛先が、該｛Ｒ１，Ｒ２，…｝の有効な宛先でもあり、その逆もまた同様であるような、より具体的でない経路（less specific route）Ｒが存在するようになされる。セクション５は、｛Ｒ１，Ｒ２，…｝経路の各属性（タイプによる）をＲの属性に組み合わせる方法の説明を含んでいる。
ＴＲＩＰ内には、特定のアドレスプリフィックスが特定のアドレスファミリー内で使用されず有効でもないことを通信するためのメカニズムがなく、したがって、これらのアドレスを、集約期間中はスキップされることができることに留意されたい。ＬＳは、ＴＲＩＰの外部のメソッドを使用して、集約期間中に無視できる無効なプリフィックスを知ることができる。
ＬＳは、集約を実行することを必要とはされないが、ＴＲＩＢを小さく維持することが重要な場合には、該集約は推奨される。ＬＳは、そのローカルポリシーに基づいて、一組の経路を、単一の集約経路に集約するかどうかを判断する。
ＮｅｘｔＨｏｐＳｅｒｖｅｒがすべての集約された経路で同一でない複数の経路を、ＬＳが集約するときは常に、該集約経路のＮｅｘｔＨｏｐＳｅｒｖｅｒ属性を、集約しているＬＳのドメインのシグナリングサーバに設定しなければならない。
ＬＳが、いずれかの経路のＮｅｘｔＨｏｐＳｅｒｖｅｒをリセットする場合（集約又は他の理由に起因してこれを実行できる）、これは、これら宛先へのシグナリングパスに沿って別のシグナリングサーバ(signaling server)を追加する、という効果を有する。最終結果として、２つの宛先間のシグナリングパスは、複数のドメインにわたる複数のシグナリングサーバから成る場合がある。

＜第１４ページ＞
送信オンリーモード(Send Only mode)でＬＳによってそのイントラドメインピアへ送信されたＵＰＤＡＴＥメッセージは、トポロジーが変化するごとにＩＴＡＤトポロジー属性を含まなければならない。外部ピアとの送信オンリーモードにおけるＬＳの有用なアプリケーションは、ゲートウェイ登録サービスを可能にする（イネーブルする）ことである。
サービスプロバイダが、自身が所有する一組のゲートウェイに対する呼を終端するものの、決して呼を開始することがない場合、そのサービスプロバイダは、そのＬＳを送信オンリーモードで動作するように設定することができる。その理由は、そのサービスプロバイダのＬＳは、常にＵＰＤＡＴＥメッセージを生成することのみ必要であるが、それらＵＰＤＡＴＥメッセージを受信しないからである。送受信モードのＬＳが、送信オンリーモードのピアとのピアリングセッションを有する場合、そのＬＳは、自身がどのＵＰＤＡＴＥメッセージもそのピアへ送信しないように、その経路配布ポリシー(route dissemination policy)を設定しなければならない。
受信オンリーモードでは、ＬＳは、受動的なＴＲＩＰリスナ(listener)として動作する。ＬＳは、そのピアからのＵＰＤＡＴＥメッセージを受信して処理するが、どのＵＰＤＡＴＥメッセージもそのピアへ送信してはならない。これは、表示目的でトポロジー情報を収集したい管理局にとって有益である。
送受信モードのＬＳの振る舞いは、この文書全体を通じて具体的に述べられるデフォルトのＴＲＩＰオペレーションである。
送受信の機能性は、４オクテットの符号なし数値で表される。この数値は、以下の値のうちの１つのみを取ることができる。
１−送受信モード
２−送信オンリーモード
３−受信オンリーモード
２つのＬＳの双方が送信オンリーモードである場合、又は、２つのＬＳの双方が受信オンリーモードである場合、ピアリングセッションは、それら２つのＬＳ間で確立されてはならない。ＯＰＥＮメッセージを処理する際に、ピアＬＳがこのような機能のミスマッチを検出した場合、そのピアＬＳは、ＮＯＴＩＦＩＣＡＴＩＯＮ（通知）メッセージで応答して、ピアセッションをクローズしなければならない。ＮＯＴＩＦＩＣＡＴＩＯＮメッセージのエラーコードは、「機能ミスマッチ（Capability Mismatch）」に設定されなければならない。
ＬＳを、すべてのピアについて同じ送受信モードで構成しなければならない。

４．３．ＵＰＤＡＴＥメッセージのフォーマット
ＵＰＤＡＴＥ（更新）メッセージは、ＬＳ間でルーティング情報を転送するのに使用される。ＵＰＤＡＴＥパケットの情報は、さまざまなＩＴＡＤ間の関係を記述するグラフを構築するのに使用されることができる。説明されるルールを適用することによって、ルーティング情報のループおよび何らかの他の例外事態を防止することができる。

＜第２２ページ＞
４．５．ＮＯＴＩＦＩＣＡＴＩＯＮメッセージフォーマット
ＮＯＴＩＦＩＣＡＴＩＯＮメッセージは、エラー状態が検出された時に送信される。ＴＲＩＰ転送接続は、ＮＯＴＩＦＩＣＡＴＩＯＮメッセージの送信直後にクローズされる。
＜第４１ページ＞
ＩＴＡＤ内では、各ＬＳは、ＬＳの故障を検出できるように、他のＬＳの状態を知っていなければならない。これを行うために、各ＬＳは、自身の内部トポロジーを、ドメイン内の他のＬＳへ宣伝する。或るＬＳが、別のＬＳがもはやアクティブでないことを検出すると、そのＬＳを情報源とする情報を削除することができる（そのピアのＡｄｊ−ＴＲＩＢ−Ｉｎをクリアすることができる）。ＩＴＡＤトポロジー属性を使用して、該ドメイン内の他のＬＳへこの情報を通信する。
ＬＳは、自身の内部ピアセットの変化を検出するごとに、トポロジー更新を送信しなければならない。このトポロジー更新は、ＵＰＤＡＴＥメッセージ単独で送信されることもできるし、到達可能経路情報及び／又は取り消し経路情報を含むＵＰＤＡＴＥメッセージでピギーバックされる(piggyback、運ばれる)こともできる。
ＬＳは、内部ＬＳからトポロジー更新を受信すると、どのＬＳがＩＴＡＤ内でアクティブであるかを、トポロジーにおける接続アルゴリズムを介して再計算しなければならない。

＜第４２ページ＞
５．１０．３．経路選択及びＩＴＡＤトポロジー
この属性は、ＵＰＤＡＴＥにおけるどのルーティング情報からも独立している。ＬＳは、ＩＴＡＤトポロジー属性を有するＵＰＤＡＴＥを受信すると、一組の作り出された(originated)ＩＴＡＤトポロジー属性によって与えられるＩＴＡＤトポロジーに対して接続試験を行うことにより、ドメインで現在アクティブな一組のＬＳを計算しなければならない。ＬＳは、ドメインにおいてもはやアクティブでないＬＳについて、Ａｄｊ−ＴＲＩＢ−Ｉｎをローカルにパージしなければならない。ＬＳは、他のＬＳも同様の決定を行うので、このパージ情報を他のＬＳへ伝播してはならない。

＜第４８ページ＞
ローカルＬＳは、ＯＰＥＮメッセージを受信すると、ＯｐｅｎＣｏｎｆｉｒｍ（オープン確認）状態にあるその接続のすべてを検査しなければならない。また、ＬＳは、このプロトコル以外の手段によってピアのＴＲＩＰ識別子を知っている場合には、ＯｐｅｎＳｅｎｔ（オープン送信）状態にある接続を検査する。これらの接続の中で、リモートＬＳへの接続があり、そのリモートＬＳのＴＲＩＰ識別子がＯＰＥＮメッセージのものと等しい場合、ローカルＬＳは、以下の衝突解決手順を実行しなければならない。
ローカルＬＳのＴＲＩＰ識別子及びＩＴＡＤは、（ＯＰＥＮメッセージで指定された）リモートＬＳのＴＲＩＰ識別子及びＩＴＡＤと比較される。ＴＲＩＰ識別子は、比較では、４オクテットの符号なし整数として取り扱われる。
ローカルＴＲＩＰ識別子の値が、リモートＴＲＩＰ識別子の値よりも小さい場合、又は、２つのＴＲＩＰ識別子が等しく、且つ、ローカルＬＳのＩＴＡＤの値がリモートＬＳのＩＴＡＤの値よりも小さい場合、ローカルＬＳは、すでに存在するＴＲＩＰ接続（ＯｐｅｎＣｏｎｆｉｒｍ状態にすでにあるＴＲＩＰ接続）をクローズしなければならず、リモートＬＳによって開始されたＴＲＩＰ接続を容認しなければならない。
１．それ以外の場合、ローカルＬＳは、新しく作成されたＴＲＩＰ接続をクローズして、既存の接続（すでにＯｐｅｎＣｏｎｆｉｒｍ状態にある接続）を続けて使用する。
２．確立（Established）状態にある既存のＴＲＩＰ接続との接続衝突が発生した場合、ＬＳは、新しく作成された接続を無条件にクローズしなければならない。アイドル（Idle）状態、接続（Connect）状態、又はアクティブ（Active）状態にある接続との接続衝突は検出できないことに留意されたい。
３．（衝突解決手順に起因する）ＴＲＩＰ接続をクローズするために、ＬＳは、エラーコード「中断（Cease）」を有するＮＯＴＩＦＩＣＡＴＩＯＮメッセージを送信しなければならず、ＴＲＩＰ接続を閉じなければならない。

７．ＴＲＩＰバージョン交渉
ピアＬＳは、ＴＲＩＰ接続をオープンする複数の試みを行うことにより、プロトコルのバージョンを交渉することができる。これは、それぞれがサポートする最も高いバージョン番号から開始する。オープンの試みがエラーコード「ＯＰＥＮメッセージエラー」及びエラーサブコード「サポートされないバージョン番号」で失敗した場合、ＬＳは、自身が試行したバージョン番号、そのピアが試行したバージョン番号、ＮＯＴＩＦＩＣＡＴＩＯＮメッセージでそのピアによって渡されたバージョン番号、及び自身がサポートするバージョン番号を用意する。２つのピアが１つ又は複数の共通のバージョンをサポートする場合、これによって、それらピアは、最も高い共通のバージョンを高速に決定することが可能になる。ＴＲＩＰバージョン交渉をサポートするために、ＴＲＩＰの将来のバージョンは、ＯＰＥＮメッセージ及びＮＯＴＩＦＩＣＡＴＩＯＮメッセージのフォーマットを保持しなければならない。

＜第５６ページ＞
１０．１．５．ＩＴＡＤ内の経路のパージ
ＬＳがＩＴＡＤ内で作り出した(originated)経路を取り消すために、ＬＳは、ＵＰＤＡＴＥメッセージのＷｉｔｈｄｒａｗｎＲｏｕｔｅ（取り消し経路）フィールドにその経路を含める。シーケンス番号は、経路の最後の有効なバージョンよりも大きくなければならない。ＬＳは、自身のＩＴＡＤ内の経路を取り消す場合に、ＭａｘＳｅｑｕｅｎｃｅＮｕｍ（最大シーケンス番号）のシーケンス番号の使用を選択することができるが、これは義務ではない。
経路を取り消した後、ＬＳは、自身のデータベースにおいてその経路に「取り消し済」の印を付けなければならず、取り消された経路をＭａｘＰｕｒｇｅＴｉｍｅ（最大パージ時間）秒の間、自身のデータベースに保持しなければならない。ＬＳが、パージされたがまだそのデータベースにある経路を再度作り出す必要がある場合、ＬＳは、取り消しで使用されたものよりも大きなシーケンス番号を使用して直ちに経路を再度作り出すこともできるし、経路が取り消されてからＭａｘＰｕｒｇｅＴｉｍｅ秒が満了するまで待機することもできる。

＜第６１ページ＞
１０３．更新送信（Update-Send）プロセス
更新送信プロセスは、ＵＰＤＡＴＥメッセージをすべてのピアへ宣伝することを担当する。たとえば、このプロセスは、決定プロセス(Decision Process)によって選ばれた経路を、同じＩＴＡＤ又は近傍のＩＴＡＤのいずれかに位置し得る他のＬＳに分配する。異なるＩＴＡＤに位置するピアＬＳ間の情報交換のルールは、１０．３．２に与えられている。同じＩＴＡＤに位置するピアＬＳ間の情報交換のルールは、１０．３．１に与えられている。
経路をピアに転送する前に、ＬＳは、どの属性をその経路と共に転送すべきかを決定する。既知でない非遷移的な属性（a not well-known non-transitive attribute）が認識されていない場合、その属性はそのまま無視される。既知でない依存遷移的な属性（a not well-known dependent-transitive attribute）が認識されておらず、且つ、ＮｅｘｔＨｏｐＳｅｒｖｅｒ（次のホップサーバ）の属性がＬＳによって変更されていた場合、その認識されていない属性はそのまま無視される。既知でない依存遷移的な属性が認識されておらず、且つ、ＮｅｘｔＨｏｐＳｅｒｖｅｒの属性がＬＳによって変更されていない場合、その属性フラグのオクテットの部分ビット(Partial bit)は１に設定され、その属性は、他のＴＲＩＰスピーカに伝播するために保持される。同様に、既知でない独立遷移的な属性（a not well-known independent-transitive attribute）が認識されていない場合も、属性フラグのオクテットの部分ビットは１にセットされ、その属性は、他のＴＲＩＰスピーカに伝播するために保持される。

＜第６７ページ＞
１１．ＴＲＩＰ転送
この仕様は、ＴＲＩＰのトランスポートレイヤとしてＴＣＰの使用を定義する。ＴＲＩＰはＴＣＰポート６０６９を使用する。ＴＲＩＰを他の転送プロトコル上で実行することは、今後の検討課題である。

１２．ＩＴＡＤトポロジー
ＴＲＩＰ ＬＳのイントラドメイントポロジーには何ら制限がない。たとえば、ＩＴＡＤ ＬＳは、フルメッシュ、スター、又は他の任意の接続トポロジーで構成されることができる。同様に、ＴＲＩＰ ＩＴＡＤのトポロジーにも何ら制限はない。たとえば、ＩＴＡＤは、フラットトポロジー（メッシュ又はリング）で編成されることもできるし、マルチレベルの階層又は他の任意のトポロジーで編成されることもできる。
２つのＴＲＩＰ ＩＴＡＤ間の境界は、２つのＴＲＩＰ ＬＳ間のリンク上に配置されることもできるし、ＴＲＩＰＬＳ上に一致させることもできる。後者の場合、同じＴＲＩＰ ＬＳが、複数のＩＴＡＤのメンバーとなり、そのＬＳは、当該ＬＳがメンバーである各ＩＴＡＤのＬＳにとって内部ピアであるように見える。

１３．ＩＡＮＡの考慮事項（考察）
この文書は、ＴＲＩＰパラメータの新しいＩＡＮＡレジストリを作成する。以下のＴＲＩＰパラメータはこのレジストリに含まれる。
−ＴＲＩＰ機能
−ＴＲＩＰ属性
−ＴＲＩＰアドレスファミリー
−ＴＲＩＰアプリケーションプロトコル
−ＴＲＩＰ ＩＴＡＤ番号
プロトコルパラメータは、頻繁に０に初期化／リセットされる。未セットのパラメータとそのパラメータの他の登録された値とを明確に区別するために、この文書は、上記ＴＲＩＰパラメータのそれぞれの値０を予約する。
上記パラメータのそれぞれのサブレジストリは、以下のセクションで解説される。

＜第７２ページ＞
Ａ．２．１：１つのメッセージあたり複数のネットワーク
ＴＲＩＰプロトコルによって、同じ宣伝パス及び次のホップサーバを伴う複数のアドレスプリフィックスを１つのメッセージで使用することが可能になる。この機能を利用することは、高く推奨される。１つのメッセージあたり１つのアドレスプリフィックスの場合、受信機のオーバーヘッドは大幅に増加する。複数のメッセージの受信により、システムのオーバーヘッドが増加するだけでなく、ルーティングテーブルをスキャンしてＴＲＩＰピアを更新するためのオーバーヘッドも何倍も被る。宣伝パス及び次のホップごとに多くのアドレスプリフィックスを含むメッセージを、宣伝パスごとに編成されていないルーティングテーブルから構築する１つの方法は、ルーティングテーブルがスキャンされる際に多くのメッセージを構築することである。各アドレスプリフィックスが処理される際に、関連した宣伝パス及び次のホップのメッセージが割り当てられ（該メッセージが存在しない場合）、新たなアドレスプリフィックスがそのメッセージに付加される。このようなメッセージが存在する場合、該新たなアドレスプリフィックスのそのメッセージへの付加のみが行われる。該新たなアドレスプリフィックスを保持する空間がメッセージにない場合、そのメッセージは送信され、新たなメッセージが割り当てられ、新たなアドレスプリフィックスは、その新たなメッセージに挿入される。ルーティングテーブル全体がスキャンされると、割り当てられたすべてのメッセージが送信され、それらの資源が解放される。アドレスプリフィックスによってカバーされるすべての宛先が、同じ次のホップサーバ及び共通の属性を共有する場合に、最大の圧縮が達成され、これにより、４０９６バイトの１つのメッセージで多くのアドレスプリフィックスを送信することが可能になる。
複数のアドレスプリフィックスを１つのメッセージに圧縮しないＴＲＩＰの一実施態様でピアリングする場合、ピアが取得された時又は大幅なネットワークトポロジーの変更が行われた時に受信されるデータのフラッドからオーバーヘッドを削減するステップを採用することが必要な場合がある。これを行う１つの方法は、更新レートを制限することである。これによって、ルーティングテーブルの冗長なスキャンが取り除かれて、ＴＲＩＰピアのフラッシュ更新(flash update)が提供されることになる。この手法の不都合な点は、この手法がルーティング情報の伝播待ち時間を増加させることである。複数のメッセージを処理するのに要する時間よりもそれほど大きくない最小フラッシュ更新間隔を選ぶことによって、この待ち時間は最小にされるはずである。より良い方法は、更新を送信する前に受信されたすべてのメッセージを読み出すことである。

Ａ．２．２：ストリームプロトコルにおけるメッセージの処理
ＴＲＩＰは、転送メカニズムとしてＴＣＰを使用する。ＴＣＰのストリーム性のために、受信されたメッセージのすべてのデータは、必ずしも同じ時刻に到着するとは限らない。これによって、データをメッセージとして処理することが困難になる可能性があり、特に、受信されたがまだ処理されていないデータがどれだけあるかを判断することができないシステムでは困難になる可能性がある。
この状況で使用できる１つの方法は、最初にメッセージヘッダのみの読み出しを試みることである。ＫＥＥＰＡＬＩＶＥメッセージタイプの場合、メッセージヘッダが完全なメッセージであり、他のメッセージタイプの場合、ヘッダは、特に全長(total length)が最初に検証されるべきである。すべてのチェックが成功した場合、指定された長さからメッセージヘッダのサイズを引いたものが、読み出しのために残されたデータ量である。ルーティング情報プロセスを「ハング（hang）」しつつ、ピアからの読み出しを試みる一実施態様では、ピアごとにメッセージバッファ（４０９６バイト）をセットアップすることができ、完全なメッセージが受信されるまで、そのメッセージバッファを、利用可能なデータで満たすことができる。

本発明の概念を使用するシステムの一実施の形態を示す図。 本発明の制御プロセスの一実施の形態のフロー図。

符号の説明

１１、１４ ＩＴＡＤ
１２−１、１２−２、１５−１ ロケーションサーバ
１７、１８ リスンオンリーのロケーションサーバ

Claims (10)

1. 回線交換の終端とパケット交換の終端との間の通信が交換可能に処理される通信システムであって、
   或る一組の終端に対する接続を制御するための少なくとも１つのＩＴＡＤ（１１）と、
   前記ＩＴＡＤ（１１）内の終端をサービスする複数のゲートウェイ（１３−１〜１３−４）と、
   前記ＩＴＡＤ（１１）における前記ゲートウェイ（１３−１〜１３−４）と通信するための少なくとも１つのロケーションサーバ（１２−１）であって、前記ゲートウェイ（１３−１〜１３−４）のＩＴＡＤ間電話通信ルーティング情報を提供すると共に、規定されたプロトコルを使用するピアリングセッションで第２のＩＴＡＤ（１４）と双方向に通信して、前記ＩＴＡＤ（１１）を受け持つゲートウェイに関するルーティング情報を前記第２のＩＴＡＤ（１４）に供給し、且つ、該第２のＩＴＡＤ（１４）を受け持つゲートウェイに関する前記電話通信ルーティング情報を該第２のＩＴＡＤ（１４）から受信する、少なくとも１つのロケーションサーバ（１２−１）と、
   前記規定されたプロトコルを使用して、前記ＩＴＡＤ（１１）における前記ロケーションサーバ（１２−１）と一方向でピアリングするための、該ＩＴＡＤ（１１）に関連付けられた監視ロケーションサーバ（１７）であって、該ピアリングにより、前記ＩＴＡＤにおける前記ロケーションサーバ間を通過する電話通信ルーティングデータが、前記監視ロケーションサーバ（１７）へ伝達される、監視ロケーションサーバ（１７）と、
   変化する電話通信ルーティングデータを特定するためのタイムスタンプ（２１１）と、
   前記タイムスタンプ（２１１）を付けられたデータを使用して解析的な測定を実行するための制御システム（１０１）と、
   を備える、通信システム。
2. 前記解析的な測定は、
   経路、ゲートウェイ、又はロケーションサーバのうちの少なくとも１つの利用可能性／利用不能性の測定を含む、
   請求項１に記載の通信システム。
3. 前記解析的な測定は、
   経路、ゲートウェイ、又はロケーションサーバのうちの少なくとも１つの信頼性の測定を含む、請求項１に記載の通信システム。
4. 前記解析的な測定は、
   ゲートウェイ又はロケーションサーバから成るリストからの、最も新しく追加された経路の公表、を含む、
   請求項１に記載の通信システム。
5. 前記解析的な測定は、
   ゲートウェイ又はロケーションサーバから成るリストについての経路の追加率の測定を含む、
   請求項１に記載の通信システム。
6. 前記解析的な測定は、
   ゲートウェイ又はロケーションサーバから成るリストからの、最も新しく追加された経路の公表、を含む、
   請求項１に記載の通信システム。
7. 前記解析的な測定は、
   ゲートウェイ又はロケーションサーバから成るリストについての、経路の除去率の測定を含む、
   請求項１に記載の通信システム。
8. 回線交換／パケット交換結合電気通信ネットワークにおけるルーティングの利用可能性を判断するための方法であって、
   異なるＩＴＡＤ（１１、１４）のロケーションサーバ間でＴＲＩＰデータを双方向に通信するステップであって、該通信は、ピアリングセッションが前記ロケーションサーバ間に確立された結果として行われる、ステップと、
   別のロケーションサーバ（１７）が、前記双方向ピアリングセッション中に、前記ＩＴＡＤ（１１、１４）間で通信されたＴＲＩＰデータを記憶するように、前記ＩＴＡＤ（１１、１４）の少なくとも１つにおいて、前記別のロケーションサーバ（１７）との一方向ピアリングセッションを確立するステップと、
   前記ＴＲＩＰデータにタイムスタンプを付けるステップ（２１１）と、
   前記タイムスタンプを付けられたＴＲＩＰデータを制御システム（１０１）へ通信するステップ（２１２）であって、それによって、後続の処理が前記ルーティングを判断する、ステップ（２１２）と、
   を含む、方法。
9. 電話通信の宛先の到達可能性、該宛先に関連した属性、及び該宛先に向かう経路の属性を、少なくとも１つの他のＩＴＡＤと双方向に通信するための第１のロケーションサーバ（１２−１）と、
   電話通信の宛先、該宛先に関連した属性、及び該宛先に向かう経路の属性に関する前記データのコピーを記憶するための第２のロケーションサーバ（１７）であって、前記第１のロケーションサーバ（１２−１）と一方向に通信する、第２のロケーションサーバ（１７）と、
   現在利用可能なルーティング及び現在利用可能なロケーションサーバのうちの少なくとも１つに関する少なくとも１つのシステムパラメータを生成できるように、前記第２のロケーションサーバ（１７）によって受信されたデータにタイムスタンプを付けるためのプロセッサ（１０１）と、
   を備える、ＩＴＡＤ。
10. 前記双方向通信及び前記一方向通信の両方は、ピアリングセッションで動作する電話通信ルーティング情報プロトコル（ＴＲＩＰ）を使用する、
    請求項９に記載のＩＴＡＤ。
    

Images