JP2002051083A - 専用ネットワーク間インターフェース階層ネットワークのプロトコル情報管理 - Google Patents

Abstract

(57)【要約】 【課題】 専用ネットワーク間インターフェース階層ネ
ットワークのプロトコル情報を管理する方法及び装置を
提供すること。 【解決手段】 ネットワークのＰＡＲ対応デバイス１に
よりネットワークから受信されたＰＡＲ ＰＴＳＥがチ
ェックされ、ＰＡＲ ＰＴＳＥにカプセル化された冗長
なプロトコル情報が識別される。受信されたＰＡＲ Ｐ
ＴＳＥのプロトコル情報は次に、ＰＡＲ対応デバイス１
に関連付けられたプロトコル・デバイスに提供される。
実施例によっては、冗長と識別されたプロトコル情報
が、プロトコル・デバイスに提供されるプロトコル情報
から除外される。他の実施例では、プロトコル・デバイ
スに提供されるプロトコル情報にタグが付けられ、冗長
なプロトコル情報と冗長ではないプロトコル情報が区別
される。これにより、当該プロトコルに関してネットワ
ーク・トポロジの効率的構成が促進される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にはＰＮＮＩ
（専用ネットワーク間インターフェース）ネットワーク
のプロトコル情報管理に関する。本発明の実施例は、物
理的ＡＴＭ（非同期伝送モード）ネットワーク・トポロ
ジに対する上位層トポロジの効率的構成を促進する方法
及び装置を与える。

【０００２】

【従来の技術】本発明について詳しく説明する前に、背
景について説明する。ＰＮＮＩは、ＡＴＭネットワーク
を対象にＡＴＭフォーラムにより定義された階層型動的
リンク状態ルーティング・プロトコルである。ＰＮＮＩ
プロトコルは、特に、ネットワークが個々のネットワー
ク・ノードからどのように"見える"か、従ってノードが
どのように通信するかを決定するトポロジ情報を作成・
配布するシステムを提供する。このプロトコルの基本機
能は、スイッチのグループを"ピア・グループ"にまとめ
る機能である。ピア・グループそれぞれの詳細が１つの
論理ノード（"論理グループ・ノード"すなわちＬＧＮ）
に抽象され、論理ノードがそのピア・グループの外部か
ら見える全てになる。各ピア・グループの１ノードは"
ピア・グループ・リーダ"として働き、階層の次の上位
レベルにある論理グループ・ノードとしてそのピア・グ
ループを代表する。このシステムは、ＰＮＮＩが階層
上、ネットワーク・トポロジ情報を伝播するように再帰
的に適用される。スイッチから利用できるＰＮＮＩトポ
ロジ情報は、各スイッチが自体のピア・グループの詳細
及びＰＮＮＩ階層の上位レベルで自体を代表するピア・
グループの詳細を見るようなものになっている。この階
層トポロジの抽象により、大規模ＡＴＭネットワークを
サポートするため必要なリソースが少なくなる。

【０００３】ＰＮＮＩネットワークを通して通信される
トポロジ・データは、ＰＮＮＩトポロジ状態要素（ＰＴ
ＳＥ）により定義される。ＰＴＳＥは、ネットワーク・
デバイスからアクセスできるノード、リンク、及びアド
レスに関するデータを含み、各ノードがそのネットワー
ク・ビューを定義するトポロジ・データベースを維持す
るように、ノードにより作成・配布される。ＰＴＳＥ
は、ピア・グループのノード間でフラッド（送出）され
る。これにより、各ピア・グループ・ノードのトポロジ
・データベースが同じになり、従ってネットワーク・ビ
ューも同じになる。しかし、階層の次のレベルではピア
・グループのトポロジは、前記のように１つの論理ノー
ドに抽象される。論理グループ・ノードは、その子ピア
・グループ内でアクセスできるＰＴＳＥ通知アドレス
（advertising addresses）を生成し、階層の次のレベ
ルの近隣（neighbors）に配布するが、ノードの詳細と
ピア・グループ内のリンクは失われる。論理グループ・
ノードによりこのように生成されたＰＴＳＥはまた、Ｌ
ＧＮによりその近隣から受信されたＰＴＳＥとともに階
層を元の方向へフラッドされ、下位ノードは"先祖"（つ
まりＰＮＮＩ階層の上位レベルで下位ノードを代表する
ノード）を識別でき、そのＰＮＮＩトポロジ・ビューを
維持することができる。

【０００４】一般に、ネットワークを通してフラッドさ
れたＰＴＳＥは、その元ノード（つまりＰＴＳＥを発送
または生成したノード）しか変更できないが、ＰＮＮＩ
は、ＰＴＳＥの"タイムアウト"システムを定義してお
り、これにより各ＰＴＳＥに有効期限（通常は１時間）
が与えられる。ＰＴＳＥの元ノードは、ＰＴＳＥをその
近隣に再配布することによって、ＰＴＳＥを定期的に"
リフレッシュ"することになるので、ＰＴＳＥは再びネ
ットワークを通してフラッドされる。ただし、ＰＴＳＥ
がリフレッシュされないままＰＴＳＥの有効期限が切れ
ると、ＰＴＳＥは有効なトポロジ情報とみなされなくな
り、削除されるかまたはネットワークから"フラッシュ"
される。従って、例えばリンク障害のためノードにアク
セスできなくなった場合、そのノードに関連するＰＴＳ
Ｅは最終的にはネットワークからフラッシュされる。ま
た１９９９年８月６日付欧州特許出願第９９１１５５８
０．５号は、ピア・グループ・リーダが自体のピア・グ
ループのアドレスのアクセス可能性をチェックし、その
ピア・グループのアドレス・アクセス可能性の変更を近
隣ノードに通知するメカニズムを開示している。

【０００５】ＰＮＮＩは、ＡＴＭ層での移動性をフルに
サポートする（"PNNI Addendum forMobility Extension
s v1.0"、ATM Forum af-ra-0123.000、April 1999）。
例えばＰＮＮＩ移性拡張機能では、ＡＴＭモバイル・ネ
ットワークを抽象する論理グループ・ノードは、地上系
バックボーン・ネットワークのＰＮＮＩ階層でローミン
グすることができる。正規のＰＮＮＩを通して、モバイ
ル・ネットワークの現在位置を詳しく示すルーティング
情報が通知されるので、地上系エンドシステムからモバ
イル・ネットワークのエンドシステムへのコール及びそ
の逆のコールを確立することができる。またＡＴＭネッ
トワークにより、ＩＰ（インターネット・プロトコル）
情報等の上位層プロトコル情報を伝えることができる。
これは、ＰＡＲ（ＰＮＮＩ増加ルーティング）と呼ばれ
るＰＮＮＩプロトコルの拡張機能を採用することによっ
て簡単に行える。ＰＡＲについては"PNNI Augmented Ro
uting（PAR）"、af-ra-0104.000、ATM Forum、January
1999を参照されたい。簡単には、ＰＡＲによりそれ自体
はＡＴＭネットワークの動作に関連しないＩＰ情報をネ
ットワークに配布することができる。ＰＡＲは、前述の
ＰＴＳＥを利用して、ＡＴＭトポロジ情報に加えてＩＰ
関連情報を配布する。ネットワーク内のＰＡＲ対応デバ
イスは、ＩＰ情報をＰＴＳＥにカプセル化する。これは
通常のＰＮＮＩ方式で配布される。いわゆる"ＰＡＲ
ＰＴＳＥ"のＩＰ情報は、ＰＡＲに対応していないＰＮ
ＮＩノードからは不透明であるが、ＰＡＲに対応した他
のノードはＰＡＲ ＰＴＳＥのＩＰ情報のフォーマット
を認識する。従ってネットワーク内にあるＰＡＲ対応デ
バイスは、ＰＡＲ ＰＴＳＥによってネットワークを通
してＩＰ情報を通信することができ、ＰＡＲに対応した
別のデバイスはそのＩＰ情報を抽出することができる。

【０００６】"Ｐｒｏｘｙ−ＰＡＲ"と呼ばれるＰＮＮＩ
プロトコルの他の拡張機能では、上位層プロトコル・デ
バイス、特にルータ等のＩＰデバイスは、自体がＰＮＮ
Ｉに参加することなく、ネットワークを通してＩＰ情報
を通信することができる。Ｐｒｏｘｙ−ＰＡＲについて
も"PNNI Augmented Routing（PAR）"、af-ra-0104.00
0、ATM Forum、January 1999を参照されたい。Ｐｒｏｘ
ｙ−ＰＡＲは、いわばシンプルな交換プロトコルであ
り、ＩＰデバイスをＡＴＭネットワークに統合すること
ができ、ＩＰデバイスでＰＮＮＩを実行する必要は全く
ない。ＩＰデバイスは、Ｐｒｏｘｙ−ＰＡＲサーバとし
て構成されたＰＡＲ対応デバイスを介してネットワーク
に接続することができる。ＩＰデバイス自体はＰｒｏｘ
ｙ−ＰＡＲクライアントとして構成される。Ｐｒｏｘｙ
−ＰＡＲクライアントは、Ｐｒｏｘｙ−ＰＡＲに従い、
それがサポートするＩＰサービスの詳細をＰｒｏｘｙ−
ＰＡＲサーバに登録することができる。この情報は前記
のようにＰＡＲ ＰＴＳＥにカプセル化され、通常のＰ
ＮＮＩ方式によりネットワークでフラッドされる。Ｐｒ
ｏｘｙ−ＰＡＲクライアントはまた、前記のようにＰＡ
Ｒ対応デバイスによりＰＡＲ ＰＴＳＥが受信されネッ
トワークに接続された他のＩＰデバイスに関する情報を
Ｐｒｏｘｙ−ＰＡＲサーバに要求することができる。こ
のようにしてＩＰ情報は、ＩＰデバイスがＰＮＮＩに参
加することなくＩＰデバイス間でやりとりされる。

【０００７】ＰＡＲとＰｒｏｘｙ−ＰＡＲを前記のよう
に使用することで、プロトコル・デバイス、特にＩＰデ
バイスは、ＰＮＮＩネットワーク上のプロトコル情報の
この通信を介して相互確認をすることができ、上位層プ
ロトコル・トポロジの構成に必要なプロトコル情報を各
デバイスに手動で入力する必要がなくなる。例えば、Ａ
ＴＭクラウドの端にあるＩＰルータは相互確認ができ、
ＩＰ隣接点（adjacencies）を手動で構成する必要がな
くなる。更に、１９９９年８月６日付欧州特許出願第９
９１１５５４４．１号は、ＩＰルータのＯＳＰＦ（Open
Shortest PathFirst）インターフェースを動的に構成
するメカニズムを開示している。例えばモバイル・ネッ
トワークのルータは、モバイル・ネットワークがローミ
ングし、新しい接続を確立する際、他の（固定またはモ
バイル）ネットワーク・ルータのＯＳＰＦエリアでＯＳ
ＰＦインターフェースを動的に構成することができる。
ＯＳＰＦインターフェースが動的に構成されるかどうか
にかかわらず、ＰＡＲとＰｒｏｘｙ−ＰＡＲでは、ルー
タがそのプロトコル情報（例えばＩＰアドレス、ＡＴＭ
アドレス、ＯＳＰＦエリア）を、ルータのサービス提供
側ＡＴＭスイッチに登録することができる。その場合Ａ
ＴＭはネットワーク全体にデータをフラッドする。他の
ルータは、そのサービス提供ＡＴＭスイッチに照会する
ことによってこのＩＰ情報を取得することができる。ル
ータはそこで、ルーティング情報を交換して、通常通
り、受信した情報から確認した他のルータとの近隣関係
または"ピア"を形成することができる。

【０００８】

【発明が解決しようとする課題】一般に、前記のように
ＰＮＮＩネットワークを通したプロトコル・デバイス間
プロトコル情報の通信にＰＡＲが用いられるとき、物理
的ＡＴＭネットワークでの上位層プロトコル・トポロジ
の構成は、ＰＡＲ対応スイッチによりそのクライアント
・デバイスにＰｒｏｘｙ−ＰＡＲを介して提供されるプ
ロトコル情報にもとづく。現在、ＰＡＲ対応スイッチ
は、そのクライアント・デバイスからのＰｒｏｘｙ−Ｐ
ＡＲリクエストに応答するため、ネットワークからＰＡ
Ｒ ＰＴＳＥで受信されている、要求されたタイプのプ
ロトコル情報を全て提供する。本発明は、これが不要で
あるという認識をもとにしており、当該プロトコルに関
してネットワーク・トポロジの効率的構成を処理するこ
とができる。

【０００９】

【課題を解決するための手段】本発明の側面に従い、Ｐ
ＮＮＩ階層ネットワークのＰＡＲ対応デバイスのプロト
コル情報を管理する方法が提供される。方法は、ＰＡＲ
対応デバイスによりネットワークから受信されたＰＡＲ
ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセ
ル化された冗長なプロトコル情報を識別するステップ
と、受信されたＰＡＲ ＰＴＳＥにカプセル化されたプ
ロトコル情報を、前記ＰＡＲ対応デバイスに関連付けら
れたプロトコル・デバイスに提供するステップと、を含
み、冗長と認識されたプロトコル情報はプロトコル・デ
バイスに提供されたプロトコル情報から除外される。

【００１０】本発明の第２の側面によれば、ＰＮＮＩ階
層ネットワークのＰＡＲ対応デバイスのプロトコル情報
を管理する方法が提供される。この方法は、ＰＡＲ対応
デバイスによりネットワークから受信されたＰＡＲ Ｐ
ＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化
された冗長なプロトコル情報を識別するステップと、受
信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコ
ル情報を、前記ＰＡＲ対応デバイスに関連付けられたプ
ロトコル・デバイスに提供するステップと、を含み、更
に、プロトコル・デバイスに提供されたプロトコル情報
にタグを付け、冗長なプロトコル情報いを冗長ではない
プロトコル情報と区別するステップが含まれる。

【００１１】従って、本発明の実施例では、ＰＡＲ Ｐ
ＴＳＥがＰＡＲ対応デバイスによってチェックされ、冗
長なプロトコル情報が識別される。実施例によっては、
関連付けられたプロトコル・デバイスに提供されたプロ
トコル情報にタグが付けられ、冗長なプロトコル情報と
冗長ではないプロトコル情報が区別されるので（例え
ば、冗長なプロトコル情報と冗長ではないプロトコル情
報のいずれか、または両方にタグを付けることによっ
て）、適宜構成されたプロトコル・デバイスはこの２つ
を区別でき、例えば冗長な情報を無視することができ
る。冗長とされたプロトコル情報は、他の好適実施例で
は、プロトコル・デバイスに提供されたプロトコル情報
から除外されるだけである。プロトコル情報が冗長であ
り得るのは、古いとき、複製されているとき、使用でき
ないとき、または不要なときであり、この冗長な情報を
指示することによって、またはプロトコル・デバイスに
提供されたプロトコル情報から除外することによって、
デバイスのプロトコル情報処理が簡略化され、当該プロ
トコルについてネットワーク・トポロジの効率的構成が
促進される。プロトコル・デバイスに提供された情報か
ら冗長なプロトコル情報を除外することは、"フィルタ"
操作とみなすことができ、これを適用することで、関連
するプロトコル情報のみプロトコル・デバイスにより受
信されるようになる。

【００１２】プロトコル情報は、以下に詳しく述べる好
適実施例では、ＩＰ情報を含み、ＰＡＲ対応デバイスに
関連付けられたプロトコル・デバイスはＩＰデバイス、
特にルータである。ただ、ＩＰは、ＰＮＮＩにより現在
サポートされているプロトコルであるが、当業者には明
らかなように、ＰＮＮＩは他のプロトコルも容易にサポ
ートすることができる。従って、プロトコル情報にＩＰ
Ｘ、ＮｅｔＢＩＯＳ（ネットワーク基本入出力システ
ム）、ＡＲＰ（アドレス解決プロトコル）等の情報が含
まれる実施例も考えられる。同様に、ＰＡＲ対応デバイ
スに関連付けられたプロトコル・デバイスは、ルータ、
ＤＮＳ（ドメイン・ネーム・システム）サーバ、ＡＴＭ
ＡＲＰサーバ、ディレクトリ・サーバ、ゲートウェイ
等、当該プロトコルに従ってＰＡＲ ＰＴＳＥから抽出
されたプロトコル情報を使用する任意のデバイスが考え
られる。

【００１３】ＰＡＲ対応デバイスにより様々なチェック
・プロセスを実行して冗長な情報を識別することができ
る。例えば、受信されたＰＡＲ ＰＴＳＥをチェックす
れば、そのＰＡＲ ＰＴＳＥの送信元であるネットワー
ク・ノードが、ＰＡＲ対応デバイスから見えるＰＮＮＩ
トポロジに存在するか確認することができる。存在しな
い場合、ＰＡＲ ＰＴＳＥにカプセル化されたプロトコ
ル情報は冗長とみなせる。このチェックは、ＰＡＲ Ｐ
ＴＳＥの送信元ノードＩＤを、ＰＡＲ対応デバイスから
見えるＰＮＮＩトポロジ（デバイスに保存された通常の
ＰＮＮＩトポロジ・データにより定義されている通り）
のノードのＩＤと比較することによって都合よく実行す
ることができる。このチェックにより、アクセスできな
くなった（例えば、モバイル・ネットワークが移動し、
送信元ノードとＰＡＲ対応デバイスの接続がなくなった
ため）ノードからのプロトコル情報を冗長と識別するこ
とができる。

【００１４】また前記に加えて、より好適には、ＰＡＲ
ＰＴＳＥをチェックすれば、プロトコル情報に指定さ
れたＩＰサービスのＡＴＭアドレスへのネットワークを
通したコール・パスをＰＡＲ対応デバイスから利用でき
るか確認することができる。通常のパス選択ロジックで
は、ＡＴＭアドレスへのコールを受け入れられない場合
（例えば、アドレスが到達不能で、パスを計算できない
ため、利用できるリソースが不十分なため等）、コール
・パスは利用できず、プロトコル情報は冗長とみなされ
る。このチェックは、例えばネットワークが分割され、
エンドシステムのアドレスが到達不能になったときに利
用できる。このメカニズムは、静的ＡＴＭネットワーク
に適用すれば、リセットされているノードとの接続が、
ノードによるそのＰＴＳＥのフラッシュが完了する前に
削除された"ゴースト"ＰＡＲ ＰＴＳＥを防ぐことがで
きる（ＡＴＭスイッチがリセットされた場合等）。

【００１５】この他（より好適には）、ＰＡＲ ＰＴＳ
Ｅをチェックすることで、ＰＡＲＰＴＳＥの送信元ノー
ドがＰＮＮＩ階層でＰＡＲ対応デバイスの先祖、つまり
ＰＮＮＩトポロジの上位レベルにあるデバイスを代表す
る論理ノード、であるか確認することができる。先祖ノ
ードである場合、ＰＡＲ ＰＴＳＥに含まれるプロトコ
ル情報は冗長とみなせる。このチェックは、ＰＡＲ Ｐ
ＴＳＥの送信元ノードＩＤをＰＡＲ対応デバイスに保存
されたＰＮＮＩトポロジ・データの先祖ノードのＩＤと
比較することによって都合よく実行することができる。
このチェックにより、先祖ノードによって生成されたＰ
ＴＳＥで受信されたプロトコル情報の複製を冗長と識別
することができる。

【００１６】前述のＰｒｏｘｙ−ＰＡＲによれば、ＰＡ
Ｒ対応デバイスに関連付けられたプロトコル・デバイス
は、Ｐｒｏｘｙ−ＰＡＲクライアントとして構成された
独立したデバイス（つまり、Ｐｒｏｘｙ−ＰＡＲにより
定義されたＰｒｏｘｙ−ＰＡＲクライアント動作を実装
する制御ロジックを含む）、またはＰｒｏｘｙ−ＰＡＲ
サーバとして構成されたＰＡＲ対応デバイス（つまり、
Ｐｒｏｘｙ−ＰＡＲにより定義されたＰｒｏｘｙ−ＰＡ
Ｒサーバ機能を実装する制御ロジックを含む）でもよ
い。その場合、プロトコル情報は、Ｐｒｏｘｙ−ＰＡＲ
クライアント・デバイスからの通常の定期的リクエスト
に応答してＰＡＲ対応デバイスから提供することができ
る。ただし、プロトコル・デバイスがＰＡＲ対応デバイ
スと統合された、例えば、ＡＴＭスイッチ・ロジックが
何らかの内部通信プロトコルを介してＩＰルータ・ロジ
ックと通信する組み合わせデバイスとして統合された他
の実施例も考えられる。その場合、ルータ・ロジック
は、ＰＡＲ対応スイッチ・ロジックのＩＰ情報を定期的
にポーリングすることができる。その後ＩＰ情報は、Ｐ
ｒｏｘｙ−ＰＡＲと同様なリクエストに応答してルータ
・ロジックに提供することができる。ただし、スイッチ
・ロジックはまた、ＩＰ情報をルータに自動的に、例え
ば一定間隔で、またはＰＮＮＩトポロジの変更、ネット
ワークからの新しいＰＡＲ ＰＴＳＥの受信等のイベン
トに応答して提供することもできる。いずれの場合で
も、ＰＡＲ ＰＴＳＥのチェック（或いはプロトコル情
報のタグ付け）は、プロトコル・デバイスにプロトコル
情報が提供されるとき、実装形態によるが、例えばリク
エストが受信されたとき実行することも、また場合によ
っては、ＰＡＲ ＰＴＳＥが受信されたとき前もって実
行することもできる。

【００１７】本発明の実施例は、固定ネットワーク、モ
バイル・ネットワークいずれのシナリオにも適用できる
ことは理解されよう。

【００１８】本発明の第３の側面では、ＰＮＮＩ階層ネ
ットワークに接続するＰＡＲ対応デバイスが提供され
る。このデバイスは、ＰＡＲ対応デバイスによりネット
ワークから受信されたＰＡＲ ＰＴＳＥを保存するメモ
リと、受信されたＰＡＲ ＰＴＳＥをチェックして、前
記ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコ
ル情報を識別し、冗長とされたプロトコル情報は除外
し、受信されたＰＡＲ ＰＴＳＥにカプセル化されたプ
ロトコル情報は、前記ＰＡＲ対応デバイスに関連付けら
れたプロトコル・デバイスに提供するよう構成された制
御ロジックと、を含む。

【００１９】本発明の第４の側面では、ＰＮＮＩ階層ネ
ットワークに接続するＰＡＲ対応デバイスが提供され
る。このデバイスは、ＰＡＲ対応デバイスによりネット
ワークから受信されたＰＡＲ ＰＴＳＥを保存するメモ
リと、受信したＰＡＲ ＰＴＳＥをチェックして、ＰＡ
Ｒ ＰＴＳＥにカプセル化された冗長なプロトコル情報
を識別し、受信されたＰＡＲ ＰＴＳＥにカプセル化さ
れたプロトコル情報を前記ＰＡＲ対応デバイスに関連付
けられたプロトコル・デバイスに提供するよう構成され
た制御ロジックと、を含み、制御ロジックは更に、プロ
トコル・デバイスに提供されたプロトコル情報にタグを
付け、冗長なプロトコル情報と冗長ではないプロトコル
情報を区別するよう構成される。

【００２０】全般には、本発明を具体化した方法を基準
に、機能や特徴について説明しているが、本発明を具体
化した装置では、対応する機能や特徴も得られ、逆も同
様であることは理解されよう。

【００２１】本発明の他の側面では、複数のＰＡＲ対応
デバイス及び複数のプロトコル・デバイスを含むＰＮＮ
Ｉ階層ネットワークが得られる。ＰＡＲ対応デバイスは
それぞれ、対応するプロトコル・デバイスに関連付けら
れ、そのプロトコル・デバイスにより生成されたプロト
コル情報のネットワークを通して通信が行われる。ＰＡ
Ｒ対応デバイスは、本発明の第３または第４の側面を具
体化した少なくとも１つのＰＡＲ対応デバイスを含む。
本発明の他の側面では、コンピュータ・プログラム・コ
ード手段を含むコンピュータ・プログラム要素が得られ
る。プログラム・コード手段は、ＰＮＮＩ階層ネットワ
ークに接続するため、ＰＡＲ対応デバイスのプロセッサ
にロードされると、前記のようにプロトコル情報管理方
法を実行するようプロセッサを構成する。

【００２２】

【発明の実施の形態】本発明の好適実施例について、Ｐ
ＡＲとＰｒｏｘｙ−ＰＡＲを通してＩＰルータ間でＩＰ
情報がやりとりされるモバイル・ネットワーク・システ
ムの文脈から説明する。実施例の動作について説明する
前に、実施例で扱う問題について、図１及び図２を参照
して説明する。まず図１を考える。これはモバイル・ネ
ットワークのシナリオの１例を示す。モバイル・ネット
ワークは、例えば"部隊"編成であり、見通し線リンク
（line-of-sight-links）を介して接触するときには一
時的にネットワークを形成することができ、地上の固定
ネットワークとの接続は、固定ネットワーク・インフラ
のアクセス・ポイントとの衛星接続を通して得られる。
図のスイッチＳ１及びＳ２は、固定ネットワークのアク
セス・ポイントを構成し、それぞれ、モバイル・ネット
ワークを固定ネットワークに接続する衛星リンクをサポ
ートする。アクセス・ポイント・スイッチＳ１はＩＰル
ータＲ１に、スイッチＳ２は同様にＩＰルータＲ２に接
続される。アクセス・ポイント・スイッチＳ１、Ｓ２は
それぞれ、ＰＮＮＩ階層の最下位のレベル（レベル８
８）にある他の１つ以上のスイッチとＰＮＮＩピア・グ
ループ（図の楕円）を形成する。この場合は各ピア・グ
ループに２つのスイッチが示してある。ピア・グループ
は、ここでは、各ピア・グループの固定ネットワーク・
ルータが１つだけになるように定義される。次のレベル
（階層のレベル６４）では、スイッチＳ１のレベル８８
ピア・グループは論理グループ・ノードＬＧＮ１．０に
より代表され、スイッチＳ２のピア・グループはレベル
６４の論理ノードＬＧＮ２．０により代表される

【００２３】図には２つのモバイル・ネットワークも示
してあり、それぞれ簡潔化のため、モバイル・ネットワ
ーク・ルータ（ＭＲ１、ＭＲ２）に接続された１つのス
イッチ（ＭＳ１、ＭＳ２）により表してある。モバイル
・ネットワーク・スイッチＭＳ１、ＭＳ２は、図のよう
に、レーザ見通し線リンク（laser line-of-sight lin
k）ＬＳを介して相互接続される。ＭＳ１はまた、図の
ように、固定ネットワークのアクセス・ポイント・スイ
ッチＳ２に衛星リンクを介して接続される。各スイッチ
ＭＳ１、ＭＳ２はＰＮＮＩレベル８８にピア・グループ
を形成する。次のレベル（ＰＮＮＩ階層のレベル７２）
では、ＭＳ１のモバイル・ネットワークが論理グループ
・ノードＬＧＮ２．１．１により代表され、同様にＭＳ
２のモバイル・ネットワークはレベル７２で論理グルー
プ・ノードＬＧＮ２．１．２により代表される。論理ノ
ードＬＧＮ２．１．１、ＬＧＮ２．１．２はレベル７２
でピア・グループを形成し、従ってこのレベルのモバイ
ル・ネットワークＭＳ２はモバイル・ネットワークＭＳ
１の階層を統合することができる。モバイル・ネットワ
ークＭＳ１は衛星を介してアクセス・ポイント・ノード
Ｓ２に接続されるので、モバイル・ネットワークのレベ
ル７２ピア・グループは、階層のレベル６４で論理ノー
ドＬＧＮ２．１により代表され、このレベルのアクセス
・ポイント・ノードを表すＬＧＮ２．０とピア・グルー
プを共有する。レベル６４は従って、モバイル・ネット
ワークがアクセス・ポイント・ネットワークの階層を統
合できるレベルである。レベル６４のＬＧＮ２．０とＬ
ＧＮ１．０の間に論理接続はない。アクセス・ポイント
はＰＮＮＩレベル３２（"アクセス・ポイント・レベ
ル"）で論理的に接続され、論理グループ・ノードＬＧ
Ｎ１、ＬＧＮ２は図に示すようにピア・グループを共有
する。

【００２４】各スイッチＳ１、Ｓ２、ＭＳ１、ＭＳ２は
ＰＡＲに対応しているので、ＰＡＲＰＴＳＥをフラッド
することによってＰＮＮＩネットワークＩＰ情報を通知
することができ、ネットワークから受信されたＰＡＲ
ＰＴＳＥからＩＰ情報を抽出することができる。更に各
スイッチは、これに接続されたルータのＰｒｏｘｙ−Ｐ
ＡＲサーバとして構成され、各ルータはＰｒｏｘｙ−Ｐ
ＡＲクライアントとして構成される。従ってＩＰ情報
は、ルータとそのサービス提供スイッチとの間で、前述
のようにＰｒｏｘｙ−ＰＡＲに従ってやりとりされる。

【００２５】Ｐｒｏｘｙ−ＰＡＲでは、ルータがＩＰ情
報をそのサービス提供スイッチに登録するとき、範囲を
指示することができ、スイッチによりＰＡＲ ＰＴＳＥ
にカプセル化されたＩＰ情報を、ＡＴＭネットワーク
で、指定範囲に一致するＰＮＮＩレベルに通知すること
ができる。本発明の例では、ルータはそのＩＰ情報を、
ＰＮＮＩレベル６４に等しい範囲で登録する。得られる
ＰＡＲ通知は、図では便宜上簡略化している。特に図
は、ルータＲ２により登録されたＩＰ情報のルータＭＲ
１への転送、及びルータＭＲ１により登録されたＩＰ情
報のルータＭＲ２への転送のみ示している。

【００２６】まずルータＲ２を考えると、ルータＲ２に
よりスイッチＳ２に登録され、ＩＰ情報を含むＰＡＲ通
知は、Ｓ２によりＰＡＲ ＰＴＳＥにカプセル化され、
スイッチのレベル８８ピア・グループ内でフラッドされ
る。これはレベル６４でＬＧＮ２．０としてピア・グル
ープを表すピア・グループ・リーダにより受信される。
ＬＧＮ２．０は従ってＩＰ情報のＰＡＲ ＰＴＳＥを生
成し、これはそのレベル６４ピア・グループ内でフラッ
ドされ、そこでＬＧＮ２．１により受信される。このノ
ードは、受信されたＰＴＳＥを下へその子ピア・グルー
プまでフラッドし、そこでＩＰ情報は最終的にスイッチ
ＭＳ１（及びスイッチＭＳ２）により受信される。ＭＳ
１は次に、図のように、ＩＰ情報をＰｒｏｘｙ−ＰＡＲ
を介してそのクライアント・ルータＭＲ１に転送する。
また同じく図に示すように、ＭＳ１は、ＭＲ１により登
録されたＩＰ情報を自体のピア・グループ内に通知す
る。これはレベル７２でＬＧＮ２．１．１として機能す
るピア・グループ・リーダにより受信される。このノー
ドは次にそのレベル７２内でＭＲ１を通知するＰＡＲＰ
ＴＳＥを生成し、これはＬＧＮ２．１．２により受信さ
れる。ＬＧＮ２．１．２はレベル８８でその子ピア・グ
ループにＰＴＳＥをフラッドし、そこでＭＳ２はＩＰ情
報をＰｒｏｘｙ−ＰＡＲを介してそのクライアント・ル
ータＭＲ２に転送する。

【００２７】このように、モバイル・ネットワークＭＳ
１はアクセス・ポイントＳ２との衛星接続を確立し、モ
バイル・ルータＭＲ１は固定ネットワーク・ルータＲ２
からＩＰ情報（ＩＰアドレス、ＡＴＭアドレス、ＯＳＰ
Ｆエリア等）を受信する。ＭＲ１はそこで、欧州特許出
願第９９１１５５４４．１号に述べられているように、
Ｒ２とのＯＳＰＦインターフェースを動的に構成するこ
とができる。従って、固定ネットワークとの接続が確立
されると、ＭＲ１は、現在のアクセス・ポイントに関連
付けられた固定ネットワーク・ルータ（ここではＲ２）
とのピアになることができる。ただし、モバイル・ネッ
トワークＭＳ１が、アクセス・ポイントＳ１との衛星接
続の圏外に移動したとすると、接続はアクセス・ポイン
トＳ２に移る。その場合、モバイル・スイッチＭＳ１は
まだ、固定ネットワーク・ルータＲ１に関連する、前の
衛生接続からのＰＡＲ ＰＴＳＥをそのメモリに持つ。
前述のように、ＰＡＲ ＰＴＳＥを変更できるのは送信
元ノードだけであり（ただしここには関連しないが"プ
ロキシ・フラッシュ"の場合を除く）、Ｒ１からの情報
はＰＴＳＥが３０分乃至６０分後に期限切れになるまで
まだＭＳ１にとどまる。その時間の間、ＭＳ１は、ＭＲ
１からの定期的Ｐｒｏｘｙ−ＰＡＲリクエストに応答し
てＲ１とＲ２両方に関連するＩＰ情報をそのクライアン
ト・ルータＭＲ１に返す。ＭＲ１は現在のアクセス・ポ
イントからの情報と古いアクセス・ポイントからの情報
を区別することができず、デフォルト動作は従ってＲ
１、Ｒ２両方とのピアになることである。従って、モバ
イル・ネットワークがローミングし、一連のアクセス・
ポイントを介して固定ネットワークに適合する際、ＰＡ
Ｒ情報の履歴をサービス提供側スイッチに蓄積でき、ク
ライアント・ルータは、現在のアクセス・ポイントに関
連するＰＡＲ情報及び古いアクセス・ポイントに関連す
るＰＡＲ情報を確認する手段を持たない。同様に、図の
モバイル・ネットワークＭＳ２がＭＳ１の圏外に移動
し、他のモバイル・ネットワークと新しい見通し線リン
クを確立した場合、ＭＲ２はそのサービス提供スイッチ
からＭＲ１に関する情報を受信し続け、これは関連付け
られたＰＡＲ ＰＴＳＥの有効期限が切れるまで続く。
この問題は以下に説明する本発明の実施例で扱う問題の
１つである。

【００２８】図２は第２モバイル・ネットワークのシナ
リオで、実施例で扱う別の問題を示す。ここでは簡潔化
のため、３つのモバイル・ネットワークを、それぞれモ
バイル・ネットワーク・ルータＭＲ１乃至ＭＲ３に接続
されたスイッチＭＳ１乃至ＭＳ３により表す。スイッチ
ＭＳ１乃至ＭＳ３は、図のように、モバイル・プラット
フォーム間の見通し線リンクＬＳを介して相互接続され
る。スイッチＭＳ３は、ＰＮＮＩ階層のレベル８８のＰ
ＮＮＩピア・グループを表し、スイッチＭＳ１、ＭＳ２
はレベル８８の別のピア・グループを共有する。次のレ
ベル（レベル７２）では、スイッチＭＳ３は論理グルー
プ・ノードＬＧＮ１．１．１により代表され、ＭＳ２の
レベル８８ピア・グループは論理グループ・ノードＬＧ
Ｎ１．１．２により代表される。これらのレベル７２ノ
ードは、ＰＮＮＩレベル６４のＬＧＮ１．１により代表
されるピア・グループを共有する。例えば図１のシナリ
オのように固定ネットワークとの接続があると仮定する
と、ＬＧＮ１．１はレベル６４ピア・グループを論理ノ
ードＬＧＮ１．０と共有し、レベル８８固定ネットワー
ク・ピア・グループを表す。

【００２９】このシステムでモバイル・ルータＭＲ１に
関連するＩＰ情報のやりとりは、図のＰＡＲ通知により
示される。ＭＲ１により登録されたＩＰ情報をカプセル
化したＰＡＲ ＰＴＳＥがスイッチＭＳ１により生成さ
れ、ＭＳ１のレベル８８ピア・グループ内にフラッドさ
れ、スイッチＭＳ２により受信される。ＬＧＮ１．１．
２は、同じＩＰ情報と自分自身のＰＮＮＩノードＩＤを
用いてレベル７２でＰＡＲ ＰＴＳＥを生成することに
より、このＰＴＳＥを抽象する。ＬＧＮ１．１．２はこ
のＰＴＳＥをそのレベル７２ピア・グループ内でフラッ
ドし、これはＬＧＮ１．１．１により受信される。ＬＧ
Ｎ１．１．１は受信されたＰＴＳＥを下へその子ピア・
グループまでフラッドし、そこでＰＴＳＥはスイッチＭ
Ｓ３により受信される。ＬＧＮ１．１．２はまた、この
ＰＴＳＥを下へ自体の子ピア・グループまでフラッド
し、そこでこれはスイッチＭＳ１、ＭＳ２により受信さ
れる。同様に、ＬＧＮ１．１はＬＧＮ１．１．２により
生成されたＰＡＲ ＰＴＳＥを抽象し、自体のノードＩ
Ｄでコピーを生成し、このＰＴＳＥをそのレベル６４ピ
ア・グループでフラッドし、また下へその子ピア・グル
ープまでフラッドする。このＰＴＳＥは従って、３つの
スイッチＭＳ１、ＭＳ２、ＭＳ３全てにより受信され
る。

【００３０】ＰＡＲ ＰＴＳＥはＰＮＮＩ階層の全ての
レベルで再生成されるため、スイッチＭＳ３は２つのＰ
ＡＲ ＰＴＳＥを受信し、両方ともＭＲ１に関連する同
じＩＰ情報を含む。１つは送信元がＬＧＮ１．１．２、
もう１つはＬＧＮ１．１である。従ってＭＳ３は、Ｐｒ
ｏｘｙ−ＰＡＲ照会をそのクライアント・ルータＭＲ３
から受信したとき、図に示すようにＩＰ情報の２つのコ
ピーをルータに提供する。（簡潔化のため、ＰＡＲ通知
を含むＰＡＲ ＰＴＳＥの送信元ノードのＩＤは、図で
は括弧内のＬＧＮ番号により示してある。）一方スイッ
チＭＳ２はこのＩＰ情報で３つのＰＡＲ ＰＴＳＥを受
信するので、ＩＰ情報の３つのコピーは、図に示すよう
に、ＭＳ２によりそのクライアント・ルータＭＲ２に送
信される。更にＭＳ１は、ＬＧＮ１．１．２とＬＧＮ
１．１により生成された２つのＰＡＲ ＰＴＳＥを受信
し、またそのメモリにそれが自体のレベル８８ピア・グ
ループ用に生成したＰＡＲ ＰＴＳＥを格納する。従っ
て、図に示すようにＭＳ１はここではＩＰ情報の３つの
コピーをＭＲ１に戻す。この例では２つはその先祖ノー
ドから受信されたコピー、１つは自体が生成したＰＴＳ
Ｅから受信されたコピーである。この例からわかるよう
に、ＰＡＲ ＰＴＳＥが異なる階層レベルで再生成され
ると、各ルータが同じＩＰ情報の複製を受信する。この
問題は、全ルータからのＰＡＲ通知を考慮すると明らか
に大きくなる。この問題はまた、以下に述べる本発明の
実施例の対象である。

【００３１】図３は、この実施例の動作に伴うスイッチ
の主な要素を示す簡略図である。スイッチ１は制御ロジ
ック２、メモリ３、及び回路４を含む。回路４は、デバ
イスがネットワークの他の部分及び関連するルータと通
信するためのインターフェースとスイッチング回路を含
む。この実施例のスイッチ１は、ＰＡＲ対応デバイスで
あり、関連するルータのＰｒｏｘｙ−ＰＡＲサーバとし
て機能する。制御ロジック２はスイッチの全体的動作を
制御し、従って通常のＰＡＲ、Ｐｒｏｘｙ−ＰＡＲ機
能、及びＰＴＳＥ生成・処理、コール・パス選択等の通
常のＰＮＮＩ機能を実装する。また制御ロジック２は、
ＩＰ情報管理機能を実行する（後述）。制御ロジック２
はＰＮＮＩに従い、メモリ３にトポロジ・データベース
を維持する。トポロジ・データベースは、ネットワーク
・トポロジに関するスイッチのビューを定義したトポロ
ジ・データを格納し、ＰＮＮＩ階層でのスイッチの先祖
を識別する（後述）。メモリ３はＰＴＳＥリポジトリを
格納し、リポジトリには制御ロジック２によりネットワ
ークから受信されたＰＴＳＥが保存される。保存期間
は、ＰＴＳＥが期限切れになるか、または通常のＰＮＮ
Ｉプロセスによりフラッシュされるまでである。一般に
制御ロジック２は、ハードウェア、ソフトウェア、また
はその組み合わせに実装することができるが、通常は、
ソフトウェアを実行するプロセッサにより実装され、ソ
フトウェアは前記機能を実行するようプロセッサを構成
する。適切なソフトウェアは、ここでの説明から当業者
には明らかであろう。（もちろん、スイッチ・プロセッ
サはあらかじめ適切なソフトウェアで構成しておける
が、そのようなソフトウェアを構成するプログラム・コ
ードは個別に提供することもできる。その場合プログラ
ム・コードは、デバイスにロードされ、前記のように動
作するようプロセッサが構成される。このようなプログ
ラム・コードは、独立した要素として、または複数の制
御機能用のプログラム・コードの要素として提供するこ
とも可能であり、ディスク等、コンピュータ可読媒体に
組み込んで、或いはスイッチにロードするためネットワ
ーク・オペレータに電子的に転送して提供することもで
きる。）

【００３２】制御ロジック２により実装されるＩＰ情報
管理プロセスは、この実施例では３つのフィルタ・メカ
ニズムを含む。各フィルタは、メモリ３に保存されたＰ
ＡＲＰＴＳＥのチェックを伴う。チェックにより冗長な
ＩＰ情報が識別され、Ｐｒｏｘｙ−ＰＡＲリクエストに
応答して、クライアント・ルータに提供されたＩＰ情報
から除外される。第１フィルタは、スイッチから見える
ＰＮＮＩトポロジにＰＡＲ ＰＴＳＥの送信元ノードが
存在するかチェックする。第２フィルタは、ネットワー
クでＰＡＲ ＰＴＳＥが関連するＩＰサービスのＡＴＭ
アドレスまでコール・パスが利用できるかチェックす
る。第３フィルタは、ＰＡＲ ＰＴＳＥの送信元ノード
がＰＮＮＩ階層でスイッチの先祖かどうかチェックす
る。このように各フィルタが、メモリ３に保存されたト
ポロジ・データを利用する。トポロジ・データにより定
義されるネットワーク・トポロジの簡単な例について、
図４を参照して説明する。

【００３３】前述のように、ＡＴＭネットワークでのＰ
ＮＮＩトポロジ・データの通信は、各スイッチから自体
のピア・グループの詳細、及びＰＮＮＩ階層の上位レベ
ルで代表される任意のピア・グループの詳細が見えるよ
うに行われる。図４は、図１のシステムのスイッチＭＳ
１から見た、衛星接続のスイッチＳ１からスイッチＳ２
へのハンドオーバーの後のＰＮＮＩトポロジを示す。こ
のトポロジ・ビューでは、ＭＳ１はレベル７２のＬＧＮ
２．１．２にアップリンクｕ１を介して接続される。Ｍ
Ｓ１とＳ２間の衛星接続のため、ＭＳ１はレベル６４の
ＬＧＮ２．０にもアップリンクｕ２を介して接続され
る。ＬＧＮ２．１．２は、水平リンクｈ１を介してレベ
ル７２のＬＧＮ２．１．１に接続される。ＬＧＮ２．
１．１はアップリンクｕ３を介してレベル６４のＬＧＮ
２．０に、ＬＧＮ２．０は、水平リンクｈ２を介してレ
ベル６４のＬＧＮ２．１にそれぞれ接続される。同様
に、ＬＧＮ２．０はアップリンクｕ４を介してレベル３
２のＬＧＮ１に、ＬＧＮ１は水平リンクｈ３を介してレ
ベル３２のＬＧＮ２にそれぞれ接続される。ＰＮＮＩ階
層のＭＳ１の先祖（つまり階層の上位層でＭＳ１を表す
論理ノード）は図では陰影を付けて示してある。この場
合のＭＳ１のトポロジ・データベースは、図のトポロジ
のリンク、ノードＩＤ、及びデバイス・アドレスを定義
したデータを、階層の先祖ノードのＩＤ（及びＡＴＭア
ドレス）を示すノード階層一覧とともに格納する。

【００３４】ネットワーク・システムでのスイッチ１の
動作については、スイッチ１はネットワークからＰＡＲ
ＰＴＳＥを受信し、ＰＡＲ ＰＴＳＥは制御ロジック
２によりメモリ３のＰＴＳＥリポジトリに保存される。
制御ロジック２は、クライアント・ルータにより定期的
に発行されるＰｒｏｘｙ−ＰＡＲリクエストに応答し
て、メモリ３に保存されたＰＡＲ ＰＴＳＥからＩＰ情
報を抽出し、このＩＰ情報を通常のＰＡＲサービス記述
パケットでルータに提供する。このＩＰ情報通信プロセ
スの一部としてスイッチ制御ロジック２により実行され
る動作を図５に詳しく示す。図５のステップ１０に示す
ように、ルータからのＰｒｏｘｙ−ＰＡＲリクエストの
受信後、制御ロジック２はメモリ３のＰＴＳＥリポジト
リにアクセスし、ステップ１１で、ルータにより発行さ
れるリクエストに従って第１のＰＡＲ ＰＴＳＥを選択
する。ステップ１２で、制御ロジックはＰＡＲ ＰＴＳ
Ｅの送信元ノードＩＤを、前記のように、スイッチのネ
ットワーク・ビューを定義したトポロジ・データのノー
ドＩＤと比較する。（他の実施例では、制御ロジックは
ここで、ＰＡＲ ＰＴＳＥに指定された送信元ノードの
ＡＴＭアドレスをトポロジ・データベースに保存された
ノードのＡＴＭアドレスと比較することもできる。）ス
テップ１３の"Ｎ"に示すように一致がなければ、送信元
ノードは現在のトポロジのスイッチによってはアクセス
できなくなっている。これは、例えばモバイル・ネット
ワークが移動し、新しいトポロジで送信元ノードとの接
続が存在しなくなった場合に生じることがある。その場
合、動作はステップ１４に進み、メモリ３にフラグが設
定されて、ＰＡＲ ＰＴＳＥにカプセル化されたＩＰ情
報は冗長であることが示される。ステップ１２、１３、
１４は、このように前記の第１フィルタを構成する。ス
テップ１４から動作はステップ１９に進み、メモリ３に
チェック対象のＰＡＲ ＰＴＳＥが残っているか制御ロ
ジックによりチェックされる。残っている場合、ステッ
プ２０で次のＰＴＳＥが選択され、動作はこのＰＴＳＥ
についてステップ１２に戻る。

【００３５】ステップ１３で一致があったとすると、動
作はステップ１５に進み、ＰＴＳＥのＩＰ情報により識
別されたＩＰサービスのＡＴＭアドレスへのコール・パ
スが利用できるか制御ロジックにより確認される。従っ
て、パス選択ロジックでＡＴＭアドレスへのパスを計算
できない場合（エンドシステムの障害によりＩＰサービ
スが到達不能なため等）、またはアドレスへのコールを
設定するネットワーク・リソースが不十分な場合（帯域
幅、遅延等）、パスは利用できないことがステップ１６
で確認される。その場合動作はステップ１４に進み、Ｉ
Ｐ情報は冗長とのフラグが設定され、前のようにステッ
プ１９に進む。ステップ１５、１６、１４はよって前記
の第２フィルタを構成する。

【００３６】ステップ１６でコール・パスが利用できる
とすると、ステップ１７で制御ロジックが、前記のよう
に、ＰＡＲ ＰＴＳＥの送信元ノードＩＤをメモリ３の
ノード階層一覧にあるノードＩＤと比較する。この実施
例では、ノード階層一覧にスイッチ自体のノードＩＤ、
及び上位レベルの先祖のＩＤが含まれると仮定してい
る。ステップ１８の"Ｙ"に示されるように一致があった
場合、スイッチ自体または階層の上位レベルの先祖によ
りＰＡＲ ＰＴＳＥが生成されている。その場合、動作
はステップ１４に戻り、ＩＰ情報は冗長とのフラグが設
定され、動作は前のように継続する。ステップ１７、１
８、１４は従って前記の第３フィルタを構成する。（ノ
ード階層一覧は関連ノードのＡＴＭアドレス及びこの例
のノードＩＤを含むので、このフィルタは、階層一覧の
ノードのＡＴＭアドレスをＰＡＲＰＴＳＥに指定された
送信元ノードのＡＴＭアドレスと比較することによって
も等しく実装することができる。）

【００３７】ステップ１８で一致がない場合、現在のＰ
ＴＳＥのＩＰ情報は冗長とみなされず、動作はステップ
１９に進み、ステップ２０に続く。ここで次のＰＡＲ
ＰＴＳＥが前のように選択される。ステップ１９の"Ｎ"
に示されるように、関連するＰＴＳＥが全てチェックさ
れると、制御ロジックはステップ２１に進む。ここで、
Ｐｒｏｘｙ−ＰＡＲリクエストに対応した、冗長ではな
いＩＰ情報がメモリから全て取得され、クライアント・
ルータに提供される。プロセスはここで完了する。

【００３８】図６は、図２に似たモバイル・ネットワー
ク・システムで、各スイッチＭＳ１、ＭＳ２、ＭＳ３は
前記実施例に従ったスイッチ１である。このシナリオで
は、図１のシナリオのように、アクセス・ポイント・ス
イッチＳ２（関連ルータＲ２）からの衛星接続のハンド
オーバーの後、スイッチＭＳ３に、固定ネットワークの
アクセス・ポイント・スイッチＳ１（関連ルータＲ１）
への衛星接続があると仮定している。ＰＡＲ通知は便宜
上簡略化している。特に図は、モバイル・ネットワーク
のモバイル・ルータＭＲ１からのＰＡＲ通知通信ととも
に、固定ネットワークからＭＲ３へのＰＡＲ通知の通信
のみ示している。スイッチＭＳ１乃至ＭＳ３により冗長
と識別され、従ってモバイル・ルータに送信されたＩＰ
情報から除外されたＰＡＲ通知は、図に打ち消しの斜線
で示している。ここからわかるように、スイッチＭＳ３
はそのクライアント・ルータＭＲ３に、固定ネットワー
ク・ルータＲ１のＰＡＲ通知とＬＧＮ１．１．２から受
信されたＭＲ１のＰＡＲ通知のみ送信する。アクセス・
ポイント・スイッチＳ２（図１のＬＧＮ２．０）を表す
ＬＧＮは、スイッチＭＳ３から見たＰＮＮＩトポロジで
は見えなくなり、従ってルータＲ２の"古い"ＰＡＲ通知
は、前記の第１フィルタの動作を通してＭＲ３に送信さ
れたＩＰ情報から除外される。ＭＳ３の先祖ノードＬＧ
Ｎ１．１から発生した複製ＰＡＲ通知は、前記の第３フ
ィルタによりなくなる。更に、Ｒ１へのコール・パスが
例えばＲ１の障害によりＭＳ３により利用できないこと
がわかった場合、Ｒ１のＰＡＲ通知は、前記の第２フィ
ルタにより冗長と識別され、ＭＳ３によりＭＲ３に提供
されない。

【００３９】ＭＳ２で、スイッチＭＳ１から受信された
ＭＲ１のＰＡＲ通知のみクライアント・ルータＭＲ２に
提供され、ＭＳ２の先祖ＬＧＮ１．１、ＬＧＮ１．１．
２から受信された複製ＰＡＲ通知は第３フィルタ・メカ
ニズムにより除外される。ＭＳ１の場合、この実施例の
ノード階層一覧はＭＳ１自体のノードＩＤを含むため、
ＭＲ１の全てのＰＡＲ通知が、前記のようにＭＳ１自体
により生成されたＰＴＳＥのＰＡＲ通知を含め、この第
３フィルタにより除外される。

【００４０】この実施例でルータにより受信されたＩＰ
情報の実質的な簡略化は、図６から明らかである。ただ
し、この利点は、図６に示す選択されたＰＡＲ通知だけ
ではなく、ＰＡＲ通知が全て考慮されるとき劇的に大き
くなることは理解されよう。従って、冗長な情報をなく
すことによって、ＰＡＲ対応デバイスにより、関連ルー
タに提供されるＩＰ情報が大幅に簡略化され、ルータで
のデータ処理も容易になり、ＩＰトポロジの最適構成が
促進されることは明らかである。

【００４１】本発明の、特に好適実施例について説明し
ているが、本発明の範囲から逸脱することなく、多くの
変更、変形が可能なことは理解されよう。例えば、前記
実施例では３つのフィルタ・メカニズムを採用している
が、これらフィルタ・メカニズムの１つまたは任意の組
み合わせもまた、必要に応じて他の実施例に採用するこ
とができる。更に、フィルタリングは、前記の実施例で
はＰｒｏｘｙ−ＰＡＲリクエストに応答して実行される
が、実施例によっては、例えばネットワークからＰＡＲ
ＰＴＳＥを受信したとき、あらかじめフィルタ・メカ
ニズムを１つ以上適用することもできる。また、前記実
施例のスイッチとルータは、Ｐｒｏｘｙ−ＰＡＲを介し
て通信する個別デバイスであるが、ルータをＰＡＲ対応
デバイスと統合した実施例も考えられる。その場合、ル
ータ・ロジックは、他の何らかの内部通信プロトコルを
介してＰＡＲロジックと通信することができる。

【００４２】他の実施例では、冗長なＩＰ情報を除外す
るのではなく、前記のように、スイッチによりＩＰ情報
にタグを付け、関連ルータが冗長な情報と冗長ではない
情報を区別できるようにすることもできる。また、本発
明の例は、モバイル・ネットワークのシナリオをもとに
説明しているが、本発明の実施例はまた、固定ネットワ
ーク・システムにも都合よく適用することができ、ＩＰ
トポロジの自動構成が促進されることは理解されよう。
更に前述のように、本発明の実施例は、ＩＰ以外のプロ
トコル、及びＩＰルータ以外のプロトコル・デバイスに
も適用することができる。

【００４３】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００４４】（１）専用ネットワーク間インターフェー
ス（ＰＮＮＩ）階層ネットワークのＰＮＮＩ増加ルーテ
ィング（ＰＡＲ）対応デバイスでプロトコル情報を管理
する方法であって、前記ネットワークから前記ＰＡＲ対
応デバイスにより受信されたＰＡＲ ＰＮＮＩトポロジ
状態要素（ＰＴＳＥ）をチェックし、前記ＰＡＲ ＰＴ
ＳＥにカプセル化された冗長なプロトコル情報を識別す
るステップと、受信されたＰＡＲ ＰＴＳＥにカプセル
化されたプロトコル情報を、前記ＰＡＲ対応デバイスに
関連付けられたプロトコル・デバイスに提供するステッ
プと、を含み、冗長と識別されたプロトコル情報は該プ
ロトコル・デバイスに提供されたプロトコル情報から除
外される、方法。 （２）ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイス
でプロトコル情報を管理する方法であって、前記ネット
ワークから前記ＰＡＲ対応デバイスにより受信されたＰ
ＡＲ ＰＴＳＥをチェックし、前記ＰＡＲ ＰＴＳＥに
カプセル化された冗長なプロトコル情報を識別するステ
ップと、受信されたＰＡＲ ＰＴＳＥにカプセル化され
たプロトコル情報を、前記ＰＡＲ対応デバイスに関連付
けられたプロトコル・デバイスに提供するステップと、
を含み、更に、前記プロトコル・デバイスに提供された
前記プロトコル情報にタグをつけて冗長なプロトコル情
報と冗長ではないプロトコル情報を区別するステップを
含む、方法。 （３）受信されたＰＡＲ ＰＴＳＥの前記チェックは、
該ＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノー
ドが前記ＰＡＲ対応デバイスから見たＰＮＮＩトポロジ
に存在するか確認するステップを含み、該ネットワーク
・ノードが該トポロジに存在しない場合は、該ＰＡＲ
ＰＴＳＥにカプセル化されたプロトコル情報は冗長と識
別される、前記（１）または（２）に記載の方法。 （４）前記ＰＡＲ ＰＴＳＥの送信元であるネットワー
ク・ノードが前記トポロジに存在するかを、前記ＰＡＲ
ＰＴＳＥの前記ネットワーク・ノードを識別するノー
ドＩＤを前記トポロジ内のネットワーク・ノードを識別
する前記ＰＡＲ対応デバイスに保存されたトポロジ・デ
ータのノードＩＤと比較することによって確認するステ
ップを含む、前記（３）記載の方法。 （５）受信されたＰＡＲ ＰＴＳＥの前記チェックは、
前記ネットワーク上に該ＰＡＲ ＰＴＳＥにカプセル化
された前記プロトコル情報のＡＴＭアドレスへのコール
・パスが前記ＰＡＲ対応デバイスから利用できるか確認
するステップを含み、該コール・パスが利用できない場
合は前記プロトコル情報は冗長と識別される、前記
（１）乃至（４）のいずれかに記載の方法。 （６）受信されたＰＡＲ ＰＴＳＥの前記チェックは、
該ＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノー
ドが前記ＰＮＮＩ階層の前記ＰＡＲ対応デバイスの先祖
であるか確認するステップを含み、該ネットワーク・ノ
ードが前記ＰＡＲ対応デバイスの先祖である場合は該Ｐ
ＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は冗
長と識別される、前記（１）乃至（５）のいずれかに記
載の方法。 （７）前記ＰＡＲ ＰＴＳＥの送信元である前記ネット
ワーク・ノードが前記ＰＡＲ対応デバイスの先祖である
か、前記ＰＡＲ ＰＴＳＥの前記ネットワーク・ノード
を識別するノードＩＤを、前記ＰＮＮＩ階層の前記ＰＡ
Ｒ対応デバイスの先祖を識別する前記ＰＡＲ対応デバイ
スに保存されたトポロジ・データのノードＩＤと比較す
ることによって確認するステップを含む、前記（６）記
載の方法。 （８）前記プロトコル・デバイスからのリクエストに応
答して前記プロトコル情報を前記プロトコル・デバイス
に提供するステップを含む、前記（１）乃至（７）のい
ずれかに記載の方法。 （９）前記プロトコル・デバイスからのリクエストに応
答して、前記チェックを実行するステップと、前記プロ
トコル情報を前記プロトコル・デバイスに提供するステ
ップを含む、前記（１）乃至（８）のいずれかに記載の
方法。 （１０）前記ＰＡＲ対応デバイスはＰｒｏｘｙ−ＰＡＲ
サーバとして構成され、前記プロトコル・デバイスはＰ
ｒｏｘｙ−ＰＡＲクライアントとして構成された、前記
（１）乃至（９）のいずれかに記載の方法。 （１１）前記プロトコル情報はＩＰ情報を含む、前記
（１）乃至（１０）のいずれかに記載の方法。 （１２）前記プロトコル・デバイスはルータを含む、前
記（１）乃至（１１）のいずれかに記載の方法。 （１３）ＰＮＮＩ階層ネットワークに接続するＰＡＲ対
応デバイスであって、前記ネットワークから前記ＰＡＲ
対応デバイスにより受信されたＰＡＲ ＰＴＳＥを保存
するメモリと、受信されたＰＡＲ ＰＴＳＥをチェック
して該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロ
トコル情報を識別し、冗長と識別されたプロトコル情報
は除外し、受信されたＰＡＲ ＰＴＳＥのプロトコル情
報を前記ＰＡＲ対応デバイスに関連付けられたプロトコ
ル・デバイスに提供するよう構成された制御ロジック
と、を含む、ＰＡＲ対応デバイス。 （１４）ＰＮＮＩ階層ネットワークに接続するＰＡＲ対
応デバイスであって、前記ネットワークから前記ＰＡＲ
対応デバイスにより受信されたＰＡＲ ＰＴＳＥを保存
するメモリと、受信されたＰＡＲ ＰＴＳＥをチェック
して該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロ
トコル情報を識別し、受信されたＰＡＲ ＰＴＳＥのプ
ロトコル情報を前記ＰＡＲ対応デバイスに関連付けられ
たプロトコル・デバイスに提供するよう構成された制御
ロジックと、を含み、前記制御ロジックは更に、前記プ
ロトコル・デバイスに提供されるプロトコル情報にタグ
を付けて冗長なプロトコル情報と冗長ではないプロトコ
ル情報を区別するよう構成された、ＰＡＲ対応デバイ
ス。 （１５）前記制御ロジックは、前記ＰＡＲ対応デバイス
から見たＰＮＮＩトポロジを定義したデータを含むトポ
ロジ・データを前記メモリに維持し、受信されたＰＡＲ
ＰＴＳＥの送信元であるネットワーク・ノードが該ト
ポロジに存在するか確認することによって、該受信され
たＰＡＲ ＰＴＳＥをチェックするよう構成され、該ネ
ットワーク・ノードが該トポロジに存在しない場合は、
該ＰＡＲＰＴＳＥにカプセル化されたプロトコル情報を
冗長と識別する、前記（１３）または（１４）に記載の
ＰＡＲ対応デバイス。 （１６）前記制御ロジックは、前記ＰＡＲ ＰＴＳＥの
前記ネットワーク・ノードを識別するノードＩＤを、前
記トポロジ内のネットワーク・ノードを識別する前記ト
ポロジ・データのノードＩＤと比較することによって、
前記ＰＡＲ ＰＴＳＥの送信元である前記ネットワーク
・ノードが前記トポロジに存在するか確認するよう構成
された、前記（１５）記載のＰＡＲ対応デバイス。 （１７）前記制御ロジックは、前記ネットワーク上で、
受信されたＰＡＲ ＰＴＳＥにカプセル化された前記プ
ロトコル情報のＡＴＭアドレスへのコール・パスが前記
ＰＡＲ対応デバイスから利用できるか確認することによ
って、該ＰＡＲＰＴＳＥをチェックするよう構成され、
該コール・パスが利用できない場合は前記プロトコル情
報を冗長と識別する、前記（１３）乃至（１６）のいず
れかに記載のＰＡＲ対応デバイス。 （１８）前記制御ロジックは、前記ＰＮＮＩ階層のＰＡ
Ｒ対応デバイスの先祖を識別するデータを含むトポロジ
・データを前記メモリに維持し、受信されたＰＡＲ Ｐ
ＴＳＥをチェックするために、該ＰＡＲ ＰＴＳＥの送
信元であるネットワーク・ノードが前記階層のＰＡＲ対
応デバイスの先祖であるか確認するよう構成され、該ネ
ットワーク・ノードが前記ＰＡＲ対応デバイスの先祖で
ある場合は、該ＰＡＲ ＰＴＳＥにカプセル化されたプ
ロトコル情報を冗長と識別する、前記（１３）乃至（１
７）のいずれかに記載のＰＡＲ対応デバイス。 （１９）前記制御ロジックは、前記ＰＡＲ ＰＴＳＥの
送信元である前記ネットワーク・ノードが前記ＰＡＲ対
応デバイスの先祖であるか確認するため、前記ＰＡＲ
ＰＴＳＥ内の前記ネットワーク・ノードを識別するノー
ドＩＤを、前記ＰＡＲ対応デバイスの先祖を識別する前
記トポロジ・データのノードＩＤと比較する、前記（１
８）記載のＰＡＲ対応デバイス。 （２０）前記制御ロジックは、前記プロトコル・デバイ
スからのリクエストに応答して前記プロトコル情報を前
記プロトコル・デバイスに提供するよう構成された、前
記（１３）乃至（１９）のいずれかに記載のＰＡＲ対応
デバイス。 （２１）前記制御ロジックは、前記プロトコル・デバイ
スからのリクエストに応答して、前記ＰＡＲ ＰＴＳＥ
をチェックし、前記プロトコル情報を前記プロトコル・
デバイスに提供するよう構成された、前記（１３）乃至
（２０）のいずれかに記載のＰＡＲ対応デバイス。 （２２）前記制御ロジックは、前記プロトコル・デバイ
スからのＰｒｏｘｙ−ＰＡＲリクエストに応答して前記
プロトコル情報を前記プロトコル・デバイスに提供する
Ｐｒｏｘｙ−ＰＡＲサーバ・ロジックを含む、前記（２
０）または（２１）のいずれかに記載のＰＡＲ対応デバ
イス。 （２３）複数のＰＡＲ対応デバイス及び複数のプロトコ
ル・デバイスを含むＰＮＮＩ階層ネットワークであっ
て、ＰＡＲ対応デバイスはそれぞれ、該プロトコル・デ
バイスにより生成されたプロトコル情報のネットワーク
で通信するため該プロトコル・デバイスに関連付けら
れ、該ＰＡＲ対応デバイスは前記（１３）乃至（２２）
のいずれかに記載の少なくとも１つのＰＡＲ対応デバイ
スを含む、ネットワーク。 （２４）コンピュータ・プログラム・コード手段を含む
コンピュータ・プログラム要素であって、ＰＮＮＩ階層
ネットワークに接続するＰＡＲ対応デバイスのプロセッ
サにロードされたとき、前記（１）乃至（１２）のいず
れかに記載の方法を実行するように該プロセッサを構成
する、プログラム要素。

【図面の簡単な説明】

【図１】本発明の実施例で扱う問題を示すモバイル・ネ
ットワーク・システムの図である。

【図２】本発明の実施例で扱う問題を示す他のモバイル
・ネットワーク・システムの図である。

【図３】本発明を具体化したスイッチを示す図である。

【図４】図１のシステムの１つのスイッチから見たＰＮ
ＮＩトポロジを示す図である。

【図５】図３のスイッチにより実装されたＩＰ情報管理
方法を示すフローチャートである。

【図６】実施例の動作を示すモバイル・ネットワーク・
システムの図である。

【符号の説明】

１ スイッチ ２ 制御ロジック ３ メモリ ４ インターフェースとスイッチング回路

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ハース・ロバート スイス、アドリスウィル シィ・エイチ− 8134、アルビストラッセ ９ (72)発明者 オズボーン・マイケル スイス、アウ シィ・エイチ−8804、ゾプ フストラッセ 24 Ｆターム(参考） 5K030 HA10 JT09 LB05 MD08 5K034 BB06 EE11 JJ24

Claims (24)

【特許請求の範囲】
1. 【請求項１】専用ネットワーク間インターフェース（Ｐ
   ＮＮＩ）階層ネットワークのＰＮＮＩ増加ルーティング
   （ＰＡＲ）対応デバイスでプロトコル情報を管理する方
   法であって、 前記ネットワークから前記ＰＡＲ対応デバイスにより受
   信されたＰＡＲ ＰＮＮＩトポロジ状態要素（ＰＴＳ
   Ｅ）をチェックし、前記ＰＡＲ ＰＴＳＥにカプセル化
   された冗長なプロトコル情報を識別するステップと、 受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロト
   コル情報を、前記ＰＡＲ対応デバイスに関連付けられた
   プロトコル・デバイスに提供するステップと、を含み、
   冗長と識別されたプロトコル情報は該プロトコル・デバ
   イスに提供されたプロトコル情報から除外される、 方法。
2. 【請求項２】ＰＮＮＩ階層ネットワークのＰＡＲ対応デ
   バイスでプロトコル情報を管理する方法であって、 前記ネットワークから前記ＰＡＲ対応デバイスにより受
   信されたＰＡＲ ＰＴＳＥをチェックし、前記ＰＡＲ
   ＰＴＳＥにカプセル化された冗長なプロトコル情報を識
   別するステップと、 受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロト
   コル情報を、前記ＰＡＲ対応デバイスに関連付けられた
   プロトコル・デバイスに提供するステップと、を含み、 更に、前記プロトコル・デバイスに提供された前記プロ
   トコル情報にタグをつけて冗長なプロトコル情報と冗長
   ではないプロトコル情報を区別するステップを含む、 方法。
3. 【請求項３】受信されたＰＡＲ ＰＴＳＥの前記チェッ
   クは、該ＰＡＲ ＰＴＳＥの送信元であるネットワーク
   ・ノードが前記ＰＡＲ対応デバイスから見たＰＮＮＩト
   ポロジに存在するか確認するステップを含み、該ネット
   ワーク・ノードが該トポロジに存在しない場合は、該Ｐ
   ＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は冗
   長と識別される、請求項１または請求項２に記載の方
   法。
4. 【請求項４】前記ＰＡＲ ＰＴＳＥの送信元であるネッ
   トワーク・ノードが前記トポロジに存在するかを、前記
   ＰＡＲ ＰＴＳＥの前記ネットワーク・ノードを識別す
   るノードＩＤを前記トポロジ内のネットワーク・ノード
   を識別する前記ＰＡＲ対応デバイスに保存されたトポロ
   ジ・データのノードＩＤと比較することによって確認す
   るステップを含む、請求項３記載の方法。
5. 【請求項５】受信されたＰＡＲ ＰＴＳＥの前記チェッ
   クは、前記ネットワーク上に該ＰＡＲ ＰＴＳＥにカプ
   セル化された前記プロトコル情報のＡＴＭアドレスへの
   コール・パスが前記ＰＡＲ対応デバイスから利用できる
   か確認するステップを含み、該コール・パスが利用でき
   ない場合は前記プロトコル情報は冗長と識別される、請
   求項１乃至請求項４のいずれかに記載の方法。
6. 【請求項６】受信されたＰＡＲ ＰＴＳＥの前記チェッ
   クは、該ＰＡＲ ＰＴＳＥの送信元であるネットワーク
   ・ノードが前記ＰＮＮＩ階層の前記ＰＡＲ対応デバイス
   の先祖であるか確認するステップを含み、該ネットワー
   ク・ノードが前記ＰＡＲ対応デバイスの先祖である場合
   は該ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情
   報は冗長と識別される、請求項１乃至請求項５のいずれ
   かに記載の方法。
7. 【請求項７】前記ＰＡＲ ＰＴＳＥの送信元である前記
   ネットワーク・ノードが前記ＰＡＲ対応デバイスの先祖
   であるか、前記ＰＡＲ ＰＴＳＥの前記ネットワーク・
   ノードを識別するノードＩＤを、前記ＰＮＮＩ階層の前
   記ＰＡＲ対応デバイスの先祖を識別する前記ＰＡＲ対応
   デバイスに保存されたトポロジ・データのノードＩＤと
   比較することによって確認するステップを含む、請求項
   ６記載の方法。
8. 【請求項８】前記プロトコル・デバイスからのリクエス
   トに応答して前記プロトコル情報を前記プロトコル・デ
   バイスに提供するステップを含む、請求項１乃至請求項
   ７のいずれかに記載の方法。
9. 【請求項９】前記プロトコル・デバイスからのリクエス
   トに応答して、前記チェックを実行するステップと、前
   記プロトコル情報を前記プロトコル・デバイスに提供す
   るステップを含む、請求項１乃至請求項８のいずれかに
   記載の方法。
10. 【請求項１０】前記ＰＡＲ対応デバイスはＰｒｏｘｙ−
    ＰＡＲサーバとして構成され、前記プロトコル・デバイ
    スはＰｒｏｘｙ−ＰＡＲクライアントとして構成され
    た、請求項１乃至請求項９のいずれかに記載の方法。
11. 【請求項１１】前記プロトコル情報はＩＰ情報を含む、
    請求項１乃至請求項１０のいずれかに記載の方法。
12. 【請求項１２】前記プロトコル・デバイスはルータを含
    む、請求項１乃至請求項１１のいずれかに記載の方法。
13. 【請求項１３】ＰＮＮＩ階層ネットワークに接続するＰ
    ＡＲ対応デバイスであって、 前記ネットワークから前記ＰＡＲ対応デバイスにより受
    信されたＰＡＲ ＰＴＳＥを保存するメモリと、 受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ
    ＰＴＳＥにカプセル化された冗長なプロトコル情報を識
    別し、冗長と識別されたプロトコル情報は除外し、受信
    されたＰＡＲ ＰＴＳＥのプロトコル情報を前記ＰＡＲ
    対応デバイスに関連付けられたプロトコル・デバイスに
    提供するよう構成された制御ロジックと、 を含む、ＰＡＲ対応デバイス。
14. 【請求項１４】ＰＮＮＩ階層ネットワークに接続するＰ
    ＡＲ対応デバイスであって、 前記ネットワークから前記ＰＡＲ対応デバイスにより受
    信されたＰＡＲ ＰＴＳＥを保存するメモリと、 受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ
    ＰＴＳＥにカプセル化された冗長なプロトコル情報を識
    別し、受信されたＰＡＲ ＰＴＳＥのプロトコル情報を
    前記ＰＡＲ対応デバイスに関連付けられたプロトコル・
    デバイスに提供するよう構成された制御ロジックと、を
    含み、 前記制御ロジックは更に、前記プロトコル・デバイスに
    提供されるプロトコル情報にタグを付けて冗長なプロト
    コル情報と冗長ではないプロトコル情報を区別するよう
    構成された、 ＰＡＲ対応デバイス。
15. 【請求項１５】前記制御ロジックは、前記ＰＡＲ対応デ
    バイスから見たＰＮＮＩトポロジを定義したデータを含
    むトポロジ・データを前記メモリに維持し、受信された
    ＰＡＲＰＴＳＥの送信元であるネットワーク・ノードが
    該トポロジに存在するか確認することによって、該受信
    されたＰＡＲ ＰＴＳＥをチェックするよう構成され、
    該ネットワーク・ノードが該トポロジに存在しない場合
    は、該ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル
    情報を冗長と識別する、請求項１３または請求項１４に
    記載のＰＡＲ対応デバイス。
16. 【請求項１６】前記制御ロジックは、前記ＰＡＲ ＰＴ
    ＳＥの前記ネットワーク・ノードを識別するノードＩＤ
    を、前記トポロジ内のネットワーク・ノードを識別する
    前記トポロジ・データのノードＩＤと比較することによ
    って、前記ＰＡＲ ＰＴＳＥの送信元である前記ネット
    ワーク・ノードが前記トポロジに存在するか確認するよ
    う構成された、請求項１５記載のＰＡＲ対応デバイス。
17. 【請求項１７】前記制御ロジックは、前記ネットワーク
    上で、受信されたＰＡＲ ＰＴＳＥにカプセル化された
    前記プロトコル情報のＡＴＭアドレスへのコール・パス
    が前記ＰＡＲ対応デバイスから利用できるか確認するこ
    とによって、該ＰＡＲ ＰＴＳＥをチェックするよう構
    成され、該コール・パスが利用できない場合は前記プロ
    トコル情報を冗長と識別する、請求項１３乃至請求項１
    ６のいずれかに記載のＰＡＲ対応デバイス。
18. 【請求項１８】前記制御ロジックは、前記ＰＮＮＩ階層
    のＰＡＲ対応デバイスの先祖を識別するデータを含むト
    ポロジ・データを前記メモリに維持し、受信されたＰＡ
    Ｒ ＰＴＳＥをチェックするために、該ＰＡＲ ＰＴＳ
    Ｅの送信元であるネットワーク・ノードが前記階層のＰ
    ＡＲ対応デバイスの先祖であるか確認するよう構成さ
    れ、該ネットワーク・ノードが前記ＰＡＲ対応デバイス
    の先祖である場合は、該ＰＡＲ ＰＴＳＥにカプセル化
    されたプロトコル情報を冗長と識別する、請求項１３乃
    至請求項１７のいずれかに記載のＰＡＲ対応デバイス。
19. 【請求項１９】前記制御ロジックは、前記ＰＡＲ ＰＴ
    ＳＥの送信元である前記ネットワーク・ノードが前記Ｐ
    ＡＲ対応デバイスの先祖であるか確認するため、前記Ｐ
    ＡＲＰＴＳＥ内の前記ネットワーク・ノードを識別する
    ノードＩＤを、前記ＰＡＲ対応デバイスの先祖を識別す
    る前記トポロジ・データのノードＩＤと比較する、請求
    項１８記載のＰＡＲ対応デバイス。
20. 【請求項２０】前記制御ロジックは、前記プロトコル・
    デバイスからのリクエストに応答して前記プロトコル情
    報を前記プロトコル・デバイスに提供するよう構成され
    た、請求項１３乃至請求項１９のいずれかに記載のＰＡ
    Ｒ対応デバイス。
21. 【請求項２１】前記制御ロジックは、前記プロトコル・
    デバイスからのリクエストに応答して、前記ＰＡＲ Ｐ
    ＴＳＥをチェックし、前記プロトコル情報を前記プロト
    コル・デバイスに提供するよう構成された、請求項１３
    乃至請求項２０のいずれかに記載のＰＡＲ対応デバイ
    ス。
22. 【請求項２２】前記制御ロジックは、前記プロトコル・
    デバイスからのＰｒｏｘｙ−ＰＡＲリクエストに応答し
    て前記プロトコル情報を前記プロトコル・デバイスに提
    供するＰｒｏｘｙ−ＰＡＲサーバ・ロジックを含む、請
    求項２０または請求項２１のいずれかに記載のＰＡＲ対
    応デバイス。
23. 【請求項２３】複数のＰＡＲ対応デバイス及び複数のプ
    ロトコル・デバイスを含むＰＮＮＩ階層ネットワークで
    あって、ＰＡＲ対応デバイスはそれぞれ、該プロトコル
    ・デバイスにより生成されたプロトコル情報のネットワ
    ークで通信するため該プロトコル・デバイスに関連付け
    られ、該ＰＡＲ対応デバイスは請求項１３乃至請求項２
    ２のいずれかに記載の少なくとも１つのＰＡＲ対応デバ
    イスを含む、ネットワーク。
24. 【請求項２４】コンピュータ・プログラム・コード手段
    を含むコンピュータ・プログラム要素であって、ＰＮＮ
    Ｉ階層ネットワークに接続するＰＡＲ対応デバイスのプ
    ロセッサにロードされたとき、請求項１乃至請求項１２
    のいずれかに記載の方法を実行するように該プロセッサ
    を構成する、プログラム要素。