JP3557405B2 - 専用ネットワーク間インターフェース階層ネットワークのプロトコル情報管理 - Google Patents
専用ネットワーク間インターフェース階層ネットワークのプロトコル情報管理 Download PDFInfo
- Publication number
- JP3557405B2 JP3557405B2 JP2001173974A JP2001173974A JP3557405B2 JP 3557405 B2 JP3557405 B2 JP 3557405B2 JP 2001173974 A JP2001173974 A JP 2001173974A JP 2001173974 A JP2001173974 A JP 2001173974A JP 3557405 B2 JP3557405 B2 JP 3557405B2
- Authority
- JP
- Japan
- Prior art keywords
- par
- ptse
- protocol
- network
- protocol information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
- H04L2012/5621—Virtual private network [VPN]; Private-network - network-interface (P-NNI)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
- H04L2012/5667—IP over ATM
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、一般にはＰＮＮＩ（専用ネットワーク間インターフェース）ネットワークのプロトコル情報管理に関する。本発明の実施例は、物理的ＡＴＭ（非同期伝送モード）ネットワーク・トポロジに対する上位層トポロジの効率的構成を促進する方法及び装置を与える。
【０００２】
【従来の技術】
本発明について詳しく説明する前に、背景について説明する。ＰＮＮＩは、ＡＴＭネットワークを対象にＡＴＭフォーラムにより定義された階層型動的リンク状態ルーティング・プロトコルである。ＰＮＮＩプロトコルは、特に、ネットワークが個々のネットワーク・ノードからどのように”見える”か、従ってノードがどのように通信するかを決定するトポロジ情報を作成・配布するシステムを提供する。このプロトコルの基本機能は、スイッチのグループを”ピア・グループ”にまとめる機能である。ピア・グループそれぞれの詳細が１つの論理ノード（”論理グループ・ノード”すなわちＬＧＮ）に抽象され、論理ノードがそのピア・グループの外部から見える全てになる。各ピア・グループの１ノードは”ピア・グループ・リーダ”として働き、階層の次の上位レベルにある論理グループ・ノードとしてそのピア・グループを代表する。このシステムは、ＰＮＮＩが階層上、ネットワーク・トポロジ情報を伝播するように再帰的に適用される。スイッチから利用できるＰＮＮＩトポロジ情報は、各スイッチが自体のピア・グループの詳細及びＰＮＮＩ階層の上位レベルで自体を代表するピア・グループの詳細を見るようなものになっている。この階層トポロジの抽象により、大規模ＡＴＭネットワークをサポートするため必要なリソースが少なくなる。
【０００３】
ＰＮＮＩネットワークを通して通信されるトポロジ・データは、ＰＮＮＩトポロジ状態要素（ＰＴＳＥ）により定義される。ＰＴＳＥは、ネットワーク・デバイスからアクセスできるノード、リンク、及びアドレスに関するデータを含み、各ノードがそのネットワーク・ビューを定義するトポロジ・データベースを維持するように、ノードにより作成・配布される。ＰＴＳＥは、ピア・グループのノード間でフラッド（送出）される。これにより、各ピア・グループ・ノードのトポロジ・データベースが同じになり、従ってネットワーク・ビューも同じになる。しかし、階層の次のレベルではピア・グループのトポロジは、前記のように１つの論理ノードに抽象される。論理グループ・ノードは、その子ピア・グループ内でアクセスできるＰＴＳＥ通知アドレス（ａｄｖｅｒｔｉｓｉｎｇ ａｄｄｒｅｓｓｅｓ）を生成し、階層の次のレベルの近隣（ｎｅｉｇｈｂｏｒｓ）に配布するが、ノードの詳細とピア・グループ内のリンクは失われる。論理グループ・ノードによりこのように生成されたＰＴＳＥはまた、ＬＧＮによりその近隣から受信されたＰＴＳＥとともに階層を元の方向へフラッドされ、下位ノードは”先祖”（つまりＰＮＮＩ階層の上位レベルで下位ノードを代表するノード）を識別でき、そのＰＮＮＩトポロジ・ビューを維持することができる。
【０００４】
一般に、ネットワークを通してフラッドされたＰＴＳＥは、その元ノード（つまりＰＴＳＥを発送または生成したノード）しか変更できないが、ＰＮＮＩは、ＰＴＳＥの”タイムアウト”システムを定義しており、これにより各ＰＴＳＥに有効期限（通常は１時間）が与えられる。ＰＴＳＥの元ノードは、ＰＴＳＥをその近隣に再配布することによって、ＰＴＳＥを定期的に”リフレッシュ”することになるので、ＰＴＳＥは再びネットワークを通してフラッドされる。ただし、ＰＴＳＥがリフレッシュされないままＰＴＳＥの有効期限が切れると、ＰＴＳＥは有効なトポロジ情報とみなされなくなり、削除されるかまたはネットワークから”フラッシュ”される。従って、例えばリンク障害のためノードにアクセスできなくなった場合、そのノードに関連するＰＴＳＥは最終的にはネットワークからフラッシュされる。また１９９９年８月６日付欧州特許出願第９９１１５５８０．５号は、ピア・グループ・リーダが自体のピア・グループのアドレスのアクセス可能性をチェックし、そのピア・グループのアドレス・アクセス可能性の変更を近隣ノードに通知するメカニズムを開示している。
【０００５】
ＰＮＮＩは、ＡＴＭ層での移動性をフルにサポートする（”ＰＮＮＩ Ａｄｄｅｎｄｕｍ ｆｏｒＭｏｂｉｌｉｔｙ Ｅｘｔｅｎｓｉｏｎｓ ｖ１．０”、ＡＴＭ Ｆｏｒｕｍ ａｆ−ｒａ−０１２３．０００、Ａｐｒｉｌ １９９９）。例えばＰＮＮＩ移性拡張機能では、ＡＴＭモバイル・ネットワークを抽象する論理グループ・ノードは、地上系バックボーン・ネットワークのＰＮＮＩ階層でローミングすることができる。正規のＰＮＮＩを通して、モバイル・ネットワークの現在位置を詳しく示すルーティング情報が通知されるので、地上系エンドシステムからモバイル・ネットワークのエンドシステムへのコール及びその逆のコールを確立することができる。またＡＴＭネットワークにより、ＩＰ（インターネット・プロトコル）情報等の上位層プロトコル情報を伝えることができる。これは、ＰＡＲ（ＰＮＮＩ増加ルーティング）と呼ばれるＰＮＮＩプロトコルの拡張機能を採用することによって簡単に行える。ＰＡＲについては”ＰＮＮＩ Ａｕｇｍｅｎｔｅｄ Ｒｏｕｔｉｎｇ（ＰＡＲ）”、ａｆ−ｒａ−０１０４．０００、ＡＴＭ Ｆｏｒｕｍ、Ｊａｎｕａｒｙ １９９９を参照されたい。簡単には、ＰＡＲによりそれ自体はＡＴＭネットワークの動作に関連しないＩＰ情報をネットワークに配布することができる。ＰＡＲは、前述のＰＴＳＥを利用して、ＡＴＭトポロジ情報に加えてＩＰ関連情報を配布する。ネットワーク内のＰＡＲ対応デバイスは、ＩＰ情報をＰＴＳＥにカプセル化する。これは通常のＰＮＮＩ方式で配布される。いわゆる”ＰＡＲ ＰＴＳＥ”のＩＰ情報は、ＰＡＲに対応していないＰＮＮＩノードからは不透明であるが、ＰＡＲに対応した他のノードはＰＡＲ ＰＴＳＥのＩＰ情報のフォーマットを認識する。従ってネットワーク内にあるＰＡＲ対応デバイスは、ＰＡＲ ＰＴＳＥによってネットワークを通してＩＰ情報を通信することができ、ＰＡＲに対応した別のデバイスはそのＩＰ情報を抽出することができる。
【０００６】
”Ｐｒｏｘｙ−ＰＡＲ”と呼ばれるＰＮＮＩプロトコルの他の拡張機能では、上位層プロトコル・デバイス、特にルータ等のＩＰデバイスは、自体がＰＮＮＩに参加することなく、ネットワークを通してＩＰ情報を通信することができる。Ｐｒｏｘｙ−ＰＡＲについても”ＰＮＮＩ Ａｕｇｍｅｎｔｅｄ Ｒｏｕｔｉｎｇ（ＰＡＲ）”、ａｆ−ｒａ−０１０４．０００、ＡＴＭ Ｆｏｒｕｍ、Ｊａｎｕａｒｙ １９９９を参照されたい。Ｐｒｏｘｙ−ＰＡＲは、いわばシンプルな交換プロトコルであり、ＩＰデバイスをＡＴＭネットワークに統合することができ、ＩＰデバイスでＰＮＮＩを実行する必要は全くない。ＩＰデバイスは、Ｐｒｏｘｙ−ＰＡＲサーバとして構成されたＰＡＲ対応デバイスを介してネットワークに接続することができる。ＩＰデバイス自体はＰｒｏｘｙ−ＰＡＲクライアントとして構成される。Ｐｒｏｘｙ−ＰＡＲクライアントは、Ｐｒｏｘｙ−ＰＡＲに従い、それがサポートするＩＰサービスの詳細をＰｒｏｘｙ−ＰＡＲサーバに登録することができる。この情報は前記のようにＰＡＲ ＰＴＳＥにカプセル化され、通常のＰＮＮＩ方式によりネットワークでフラッドされる。Ｐｒｏｘｙ−ＰＡＲクライアントはまた、前記のようにＰＡＲ対応デバイスによりＰＡＲ ＰＴＳＥが受信されネットワークに接続された他のＩＰデバイスに関する情報をＰｒｏｘｙ−ＰＡＲサーバに要求することができる。このようにしてＩＰ情報は、ＩＰデバイスがＰＮＮＩに参加することなくＩＰデバイス間でやりとりされる。
【０００７】
ＰＡＲとＰｒｏｘｙ−ＰＡＲを前記のように使用することで、プロトコル・デバイス、特にＩＰデバイスは、ＰＮＮＩネットワーク上のプロトコル情報のこの通信を介して相互確認をすることができ、上位層プロトコル・トポロジの構成に必要なプロトコル情報を各デバイスに手動で入力する必要がなくなる。例えば、ＡＴＭクラウドの端にあるＩＰルータは相互確認ができ、ＩＰ隣接点（ａｄｊａｃｅｎｃｉｅｓ）を手動で構成する必要がなくなる。更に、１９９９年８月６日付欧州特許出願第９９１１５５４４．１号は、ＩＰルータのＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ ＰａｔｈＦｉｒｓｔ）インターフェースを動的に構成するメカニズムを開示している。例えばモバイル・ネットワークのルータは、モバイル・ネットワークがローミングし、新しい接続を確立する際、他の（固定またはモバイル）ネットワーク・ルータのＯＳＰＦエリアでＯＳＰＦインターフェースを動的に構成することができる。ＯＳＰＦインターフェースが動的に構成されるかどうかにかかわらず、ＰＡＲとＰｒｏｘｙ−ＰＡＲでは、ルータがそのプロトコル情報（例えばＩＰアドレス、ＡＴＭアドレス、ＯＳＰＦエリア）を、ルータのサービス提供側ＡＴＭスイッチに登録することができる。その場合ＡＴＭはネットワーク全体にデータをフラッドする。他のルータは、そのサービス提供ＡＴＭスイッチに照会することによってこのＩＰ情報を取得することができる。ルータはそこで、ルーティング情報を交換して、通常通り、受信した情報から確認した他のルータとの近隣関係または”ピア”を形成することができる。
【０００８】
【発明が解決しようとする課題】
一般に、前記のようにＰＮＮＩネットワークを通したプロトコル・デバイス間プロトコル情報の通信にＰＡＲが用いられるとき、物理的ＡＴＭネットワークでの上位層プロトコル・トポロジの構成は、ＰＡＲ対応スイッチによりそのクライアント・デバイスにＰｒｏｘｙ−ＰＡＲを介して提供されるプロトコル情報にもとづく。現在、ＰＡＲ対応スイッチは、そのクライアント・デバイスからのＰｒｏｘｙ−ＰＡＲリクエストに応答するため、ネットワークからＰＡＲ ＰＴＳＥで受信されている、要求されたタイプのプロトコル情報を全て提供する。本発明は、これが不要であるという認識をもとにしており、当該プロトコルに関してネットワーク・トポロジの効率的構成を処理することができる。
【０００９】
【課題を解決するための手段】
本発明の側面に従い、ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイスのプロトコル情報を管理する方法が提供される。方法は、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別するステップと、
受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するステップと、を含み、冗長と認識されたプロトコル情報はプロトコル・デバイスに提供されたプロトコル情報から除外される。
【００１０】
本発明の第２の側面によれば、ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイスのプロトコル情報を管理する方法が提供される。この方法は、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別するステップと、
受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するステップと、を含み、
更に、プロトコル・デバイスに提供されたプロトコル情報にタグを付け、冗長なプロトコル情報いを冗長ではないプロトコル情報と区別するステップが含まれる。
【００１１】
従って、本発明の実施例では、ＰＡＲ ＰＴＳＥがＰＡＲ対応デバイスによってチェックされ、冗長なプロトコル情報が識別される。実施例によっては、関連付けられたプロトコル・デバイスに提供されたプロトコル情報にタグが付けられ、冗長なプロトコル情報と冗長ではないプロトコル情報が区別されるので（例えば、冗長なプロトコル情報と冗長ではないプロトコル情報のいずれか、または両方にタグを付けることによって）、適宜構成されたプロトコル・デバイスはこの２つを区別でき、例えば冗長な情報を無視することができる。冗長とされたプロトコル情報は、他の好適実施例では、プロトコル・デバイスに提供されたプロトコル情報から除外されるだけである。プロトコル情報が冗長であり得るのは、古いとき、複製されているとき、使用できないとき、または不要なときであり、この冗長な情報を指示することによって、またはプロトコル・デバイスに提供されたプロトコル情報から除外することによって、デバイスのプロトコル情報処理が簡略化され、当該プロトコルについてネットワーク・トポロジの効率的構成が促進される。プロトコル・デバイスに提供された情報から冗長なプロトコル情報を除外することは、”フィルタ”操作とみなすことができ、これを適用することで、関連するプロトコル情報のみプロトコル・デバイスにより受信されるようになる。
【００１２】
プロトコル情報は、以下に詳しく述べる好適実施例では、ＩＰ情報を含み、ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスはＩＰデバイス、特にルータである。ただ、ＩＰは、ＰＮＮＩにより現在サポートされているプロトコルであるが、当業者には明らかなように、ＰＮＮＩは他のプロトコルも容易にサポートすることができる。従って、プロトコル情報にＩＰＸ、ＮｅｔＢＩＯＳ（ネットワーク基本入出力システム）、ＡＲＰ（アドレス解決プロトコル）等の情報が含まれる実施例も考えられる。同様に、ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスは、ルータ、ＤＮＳ（ドメイン・ネーム・システム）サーバ、ＡＴＭ ＡＲＰサーバ、ディレクトリ・サーバ、ゲートウェイ等、当該プロトコルに従ってＰＡＲ ＰＴＳＥから抽出されたプロトコル情報を使用する任意のデバイスが考えられる。
【００１３】
ＰＡＲ対応デバイスにより様々なチェック・プロセスを実行して冗長な情報を識別することができる。例えば、受信されたＰＡＲ ＰＴＳＥをチェックすれば、そのＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが、ＰＡＲ対応デバイスから見えるＰＮＮＩトポロジに存在するか確認することができる。存在しない場合、ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は冗長とみなせる。このチェックは、ＰＡＲ ＰＴＳＥの送信元ノードＩＤを、ＰＡＲ対応デバイスから見えるＰＮＮＩトポロジ（デバイスに保存された通常のＰＮＮＩトポロジ・データにより定義されている通り）のノードのＩＤと比較することによって都合よく実行することができる。このチェックにより、アクセスできなくなった（例えば、モバイル・ネットワークが移動し、送信元ノードとＰＡＲ対応デバイスの接続がなくなったため）ノードからのプロトコル情報を冗長と識別することができる。
【００１４】
また前記に加えて、より好適には、ＰＡＲ ＰＴＳＥをチェックすれば、プロトコル情報に指定されたＩＰサービスのＡＴＭアドレスへのネットワークを通したコール・パスをＰＡＲ対応デバイスから利用できるか確認することができる。通常のパス選択ロジックでは、ＡＴＭアドレスへのコールを受け入れられない場合（例えば、アドレスが到達不能で、パスを計算できないため、利用できるリソースが不十分なため等）、コール・パスは利用できず、プロトコル情報は冗長とみなされる。このチェックは、例えばネットワークが分割され、エンドシステムのアドレスが到達不能になったときに利用できる。このメカニズムは、静的ＡＴＭネットワークに適用すれば、リセットされているノードとの接続が、ノードによるそのＰＴＳＥのフラッシュが完了する前に削除された”ゴースト”ＰＡＲ ＰＴＳＥを防ぐことができる（ＡＴＭスイッチがリセットされた場合等）。
【００１５】
この他（より好適には）、ＰＡＲ ＰＴＳＥをチェックすることで、ＰＡＲ ＰＴＳＥの送信元ノードがＰＮＮＩ階層でＰＡＲ対応デバイスの先祖、つまりＰＮＮＩトポロジの上位レベルにあるデバイスを代表する論理ノード、であるか確認することができる。先祖ノードである場合、ＰＡＲ ＰＴＳＥに含まれるプロトコル情報は冗長とみなせる。このチェックは、ＰＡＲ ＰＴＳＥの送信元ノードＩＤをＰＡＲ対応デバイスに保存されたＰＮＮＩトポロジ・データの先祖ノードのＩＤと比較することによって都合よく実行することができる。このチェックにより、先祖ノードによって生成されたＰＴＳＥで受信されたプロトコル情報の複製を冗長と識別することができる。
【００１６】
前述のＰｒｏｘｙ−ＰＡＲによれば、ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスは、Ｐｒｏｘｙ−ＰＡＲクライアントとして構成された独立したデバイス（つまり、Ｐｒｏｘｙ−ＰＡＲにより定義されたＰｒｏｘｙ−ＰＡＲクライアント動作を実装する制御ロジックを含む）、またはＰｒｏｘｙ−ＰＡＲサーバとして構成されたＰＡＲ対応デバイス（つまり、Ｐｒｏｘｙ−ＰＡＲにより定義されたＰｒｏｘｙ−ＰＡＲサーバ機能を実装する制御ロジックを含む）でもよい。その場合、プロトコル情報は、Ｐｒｏｘｙ−ＰＡＲクライアント・デバイスからの通常の定期的リクエストに応答してＰＡＲ対応デバイスから提供することができる。ただし、プロトコル・デバイスがＰＡＲ対応デバイスと統合された、例えば、ＡＴＭスイッチ・ロジックが何らかの内部通信プロトコルを介してＩＰルータ・ロジックと通信する組み合わせデバイスとして統合された他の実施例も考えられる。その場合、ルータ・ロジックは、ＰＡＲ対応スイッチ・ロジックのＩＰ情報を定期的にポーリングすることができる。その後ＩＰ情報は、Ｐｒｏｘｙ−ＰＡＲと同様なリクエストに応答してルータ・ロジックに提供することができる。ただし、スイッチ・ロジックはまた、ＩＰ情報をルータに自動的に、例えば一定間隔で、またはＰＮＮＩトポロジの変更、ネットワークからの新しいＰＡＲ ＰＴＳＥの受信等のイベントに応答して提供することもできる。いずれの場合でも、ＰＡＲ ＰＴＳＥのチェック（或いはプロトコル情報のタグ付け）は、プロトコル・デバイスにプロトコル情報が提供されるとき、実装形態によるが、例えばリクエストが受信されたとき実行することも、また場合によっては、ＰＡＲ ＰＴＳＥが受信されたとき前もって実行することもできる。
【００１７】
本発明の実施例は、固定ネットワーク、モバイル・ネットワークいずれのシナリオにも適用できることは理解されよう。
【００１８】
本発明の第３の側面では、ＰＮＮＩ階層ネットワークに接続するＰＡＲ対応デバイスが提供される。このデバイスは、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥを保存するメモリと、
受信されたＰＡＲ ＰＴＳＥをチェックして、前記ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別し、冗長とされたプロトコル情報は除外し、受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するよう構成された制御ロジックと、を含む。
【００１９】
本発明の第４の側面では、ＰＮＮＩ階層ネットワークに接続するＰＡＲ対応デバイスが提供される。このデバイスは、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥを保存するメモリと、
受信したＰＡＲ ＰＴＳＥをチェックして、ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別し、受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するよう構成された制御ロジックと、を含み、
制御ロジックは更に、プロトコル・デバイスに提供されたプロトコル情報にタグを付け、冗長なプロトコル情報と冗長ではないプロトコル情報を区別するよう構成される。
【００２０】
全般には、本発明を具体化した方法を基準に、機能や特徴について説明しているが、本発明を具体化した装置では、対応する機能や特徴も得られ、逆も同様であることは理解されよう。
【００２１】
本発明の他の側面では、複数のＰＡＲ対応デバイス及び複数のプロトコル・デバイスを含むＰＮＮＩ階層ネットワークが得られる。ＰＡＲ対応デバイスはそれぞれ、対応するプロトコル・デバイスに関連付けられ、そのプロトコル・デバイスにより生成されたプロトコル情報のネットワークを通して通信が行われる。ＰＡＲ対応デバイスは、本発明の第３または第４の側面を具体化した少なくとも１つのＰＡＲ対応デバイスを含む。本発明の他の側面では、コンピュータ・プログラム・コード手段を含むコンピュータ・プログラム要素が得られる。プログラム・コード手段は、ＰＮＮＩ階層ネットワークに接続するため、ＰＡＲ対応デバイスのプロセッサにロードされると、前記のようにプロトコル情報管理方法を実行するようプロセッサを構成する。
【００２２】
【発明の実施の形態】
本発明の好適実施例について、ＰＡＲとＰｒｏｘｙ−ＰＡＲを通してＩＰルータ間でＩＰ情報がやりとりされるモバイル・ネットワーク・システムの文脈から説明する。実施例の動作について説明する前に、実施例で扱う問題について、図１及び図２を参照して説明する。まず図１を考える。これはモバイル・ネットワークのシナリオの１例を示す。モバイル・ネットワークは、例えば”部隊”編成であり、見通し線リンク（ｌｉｎｅ−ｏｆ−ｓｉｇｈｔ−ｌｉｎｋｓ）を介して接触するときには一時的にネットワークを形成することができ、地上の固定ネットワークとの接続は、固定ネットワーク・インフラのアクセス・ポイントとの衛星接続を通して得られる。図のスイッチＳ１及びＳ２は、固定ネットワークのアクセス・ポイントを構成し、それぞれ、モバイル・ネットワークを固定ネットワークに接続する衛星リンクをサポートする。アクセス・ポイント・スイッチＳ１はＩＰルータＲ１に、スイッチＳ２は同様にＩＰルータＲ２に接続される。アクセス・ポイント・スイッチＳ１、Ｓ２はそれぞれ、ＰＮＮＩ階層の最下位のレベル（レベル８８）にある他の１つ以上のスイッチとＰＮＮＩピア・グループ（図の楕円）を形成する。この場合は各ピア・グループに２つのスイッチが示してある。ピア・グループは、ここでは、各ピア・グループの固定ネットワーク・ルータが１つだけになるように定義される。次のレベル（階層のレベル６４）では、スイッチＳ１のレベル８８ピア・グループは論理グループ・ノードＬＧＮ１．０により代表され、スイッチＳ２のピア・グループはレベル６４の論理ノードＬＧＮ２．０により代表される
【００２３】
図には２つのモバイル・ネットワークも示してあり、それぞれ簡潔化のため、モバイル・ネットワーク・ルータ（ＭＲ１、ＭＲ２）に接続された１つのスイッチ（ＭＳ１、ＭＳ２）により表してある。モバイル・ネットワーク・スイッチＭＳ１、ＭＳ２は、図のように、レーザ見通し線リンク（ｌａｓｅｒ ｌｉｎｅ−ｏｆ−ｓｉｇｈｔ ｌｉｎｋ）ＬＳを介して相互接続される。ＭＳ１はまた、図のように、固定ネットワークのアクセス・ポイント・スイッチＳ２に衛星リンクを介して接続される。各スイッチＭＳ１、ＭＳ２はＰＮＮＩレベル８８にピア・グループを形成する。次のレベル（ＰＮＮＩ階層のレベル７２）では、ＭＳ１のモバイル・ネットワークが論理グループ・ノードＬＧＮ２．１．１により代表され、同様にＭＳ２のモバイル・ネットワークはレベル７２で論理グループ・ノードＬＧＮ２．１．２により代表される。論理ノードＬＧＮ２．１．１、ＬＧＮ２．１．２はレベル７２でピア・グループを形成し、従ってこのレベルのモバイル・ネットワークＭＳ２はモバイル・ネットワークＭＳ１の階層を統合することができる。モバイル・ネットワークＭＳ１は衛星を介してアクセス・ポイント・ノードＳ２に接続されるので、モバイル・ネットワークのレベル７２ピア・グループは、階層のレベル６４で論理ノードＬＧＮ２．１により代表され、このレベルのアクセス・ポイント・ノードを表すＬＧＮ２．０とピア・グループを共有する。レベル６４は従って、モバイル・ネットワークがアクセス・ポイント・ネットワークの階層を統合できるレベルである。レベル６４のＬＧＮ２．０とＬＧＮ１．０の間に論理接続はない。アクセス・ポイントはＰＮＮＩレベル３２（”アクセス・ポイント・レベル”）で論理的に接続され、論理グループ・ノードＬＧＮ１、ＬＧＮ２は図に示すようにピア・グループを共有する。
【００２４】
各スイッチＳ１、Ｓ２、ＭＳ１、ＭＳ２はＰＡＲに対応しているので、ＰＡＲＰＴＳＥをフラッドすることによってＰＮＮＩネットワークＩＰ情報を通知することができ、ネットワークから受信されたＰＡＲ ＰＴＳＥからＩＰ情報を抽出することができる。更に各スイッチは、これに接続されたルータのＰｒｏｘｙ−ＰＡＲサーバとして構成され、各ルータはＰｒｏｘｙ−ＰＡＲクライアントとして構成される。従ってＩＰ情報は、ルータとそのサービス提供スイッチとの間で、前述のようにＰｒｏｘｙ−ＰＡＲに従ってやりとりされる。
【００２５】
Ｐｒｏｘｙ−ＰＡＲでは、ルータがＩＰ情報をそのサービス提供スイッチに登録するとき、範囲を指示することができ、スイッチによりＰＡＲ ＰＴＳＥにカプセル化されたＩＰ情報を、ＡＴＭネットワークで、指定範囲に一致するＰＮＮＩレベルに通知することができる。本発明の例では、ルータはそのＩＰ情報を、ＰＮＮＩレベル６４に等しい範囲で登録する。得られるＰＡＲ通知は、図では便宜上簡略化している。特に図は、ルータＲ２により登録されたＩＰ情報のルータＭＲ１への転送、及びルータＭＲ１により登録されたＩＰ情報のルータＭＲ２への転送のみ示している。
【００２６】
まずルータＲ２を考えると、ルータＲ２によりスイッチＳ２に登録され、ＩＰ情報を含むＰＡＲ通知は、Ｓ２によりＰＡＲ ＰＴＳＥにカプセル化され、スイッチのレベル８８ピア・グループ内でフラッドされる。これはレベル６４でＬＧＮ２．０としてピア・グループを表すピア・グループ・リーダにより受信される。ＬＧＮ２．０は従ってＩＰ情報のＰＡＲ ＰＴＳＥを生成し、これはそのレベル６４ピア・グループ内でフラッドされ、そこでＬＧＮ２．１により受信される。このノードは、受信されたＰＴＳＥを下へその子ピア・グループまでフラッドし、そこでＩＰ情報は最終的にスイッチＭＳ１（及びスイッチＭＳ２）により受信される。ＭＳ１は次に、図のように、ＩＰ情報をＰｒｏｘｙ−ＰＡＲを介してそのクライアント・ルータＭＲ１に転送する。また同じく図に示すように、ＭＳ１は、ＭＲ１により登録されたＩＰ情報を自体のピア・グループ内に通知する。これはレベル７２でＬＧＮ２．１．１として機能するピア・グループ・リーダにより受信される。このノードは次にそのレベル７２内でＭＲ１を通知するＰＡＲＰＴＳＥを生成し、これはＬＧＮ２．１．２により受信される。ＬＧＮ２．１．２はレベル８８でその子ピア・グループにＰＴＳＥをフラッドし、そこでＭＳ２はＩＰ情報をＰｒｏｘｙ−ＰＡＲを介してそのクライアント・ルータＭＲ２に転送する。
【００２７】
このように、モバイル・ネットワークＭＳ１はアクセス・ポイントＳ２との衛星接続を確立し、モバイル・ルータＭＲ１は固定ネットワーク・ルータＲ２からＩＰ情報（ＩＰアドレス、ＡＴＭアドレス、ＯＳＰＦエリア等）を受信する。ＭＲ１はそこで、欧州特許出願第９９１１５５４４．１号に述べられているように、Ｒ２とのＯＳＰＦインターフェースを動的に構成することができる。従って、固定ネットワークとの接続が確立されると、ＭＲ１は、現在のアクセス・ポイントに関連付けられた固定ネットワーク・ルータ（ここではＲ２）とのピアになることができる。ただし、モバイル・ネットワークＭＳ１が、アクセス・ポイントＳ１との衛星接続の圏外に移動したとすると、接続はアクセス・ポイントＳ２に移る。その場合、モバイル・スイッチＭＳ１はまだ、固定ネットワーク・ルータＲ１に関連する、前の衛生接続からのＰＡＲ ＰＴＳＥをそのメモリに持つ。前述のように、ＰＡＲ ＰＴＳＥを変更できるのは送信元ノードだけであり（ただしここには関連しないが”プロキシ・フラッシュ”の場合を除く）、Ｒ１からの情報はＰＴＳＥが３０分乃至６０分後に期限切れになるまでまだＭＳ１にとどまる。その時間の間、ＭＳ１は、ＭＲ１からの定期的Ｐｒｏｘｙ−ＰＡＲリクエストに応答してＲ１とＲ２両方に関連するＩＰ情報をそのクライアント・ルータＭＲ１に返す。ＭＲ１は現在のアクセス・ポイントからの情報と古いアクセス・ポイントからの情報を区別することができず、デフォルト動作は従ってＲ１、Ｒ２両方とのピアになることである。従って、モバイル・ネットワークがローミングし、一連のアクセス・ポイントを介して固定ネットワークに適合する際、ＰＡＲ情報の履歴をサービス提供側スイッチに蓄積でき、クライアント・ルータは、現在のアクセス・ポイントに関連するＰＡＲ情報及び古いアクセス・ポイントに関連するＰＡＲ情報を確認する手段を持たない。同様に、図のモバイル・ネットワークＭＳ２がＭＳ１の圏外に移動し、他のモバイル・ネットワークと新しい見通し線リンクを確立した場合、ＭＲ２はそのサービス提供スイッチからＭＲ１に関する情報を受信し続け、これは関連付けられたＰＡＲ ＰＴＳＥの有効期限が切れるまで続く。この問題は以下に説明する本発明の実施例で扱う問題の１つである。
【００２８】
図２は第２モバイル・ネットワークのシナリオで、実施例で扱う別の問題を示す。ここでは簡潔化のため、３つのモバイル・ネットワークを、それぞれモバイル・ネットワーク・ルータＭＲ１乃至ＭＲ３に接続されたスイッチＭＳ１乃至ＭＳ３により表す。スイッチＭＳ１乃至ＭＳ３は、図のように、モバイル・プラットフォーム間の見通し線リンクＬＳを介して相互接続される。スイッチＭＳ３は、ＰＮＮＩ階層のレベル８８のＰＮＮＩピア・グループを表し、スイッチＭＳ１、ＭＳ２はレベル８８の別のピア・グループを共有する。次のレベル（レベル７２）では、スイッチＭＳ３は論理グループ・ノードＬＧＮ１．１．１により代表され、ＭＳ２のレベル８８ピア・グループは論理グループ・ノードＬＧＮ１．１．２により代表される。これらのレベル７２ノードは、ＰＮＮＩレベル６４のＬＧＮ１．１により代表されるピア・グループを共有する。例えば図１のシナリオのように固定ネットワークとの接続があると仮定すると、ＬＧＮ１．１はレベル６４ピア・グループを論理ノードＬＧＮ１．０と共有し、レベル８８固定ネットワーク・ピア・グループを表す。
【００２９】
このシステムでモバイル・ルータＭＲ１に関連するＩＰ情報のやりとりは、図のＰＡＲ通知により示される。ＭＲ１により登録されたＩＰ情報をカプセル化したＰＡＲ ＰＴＳＥがスイッチＭＳ１により生成され、ＭＳ１のレベル８８ピア・グループ内にフラッドされ、スイッチＭＳ２により受信される。ＬＧＮ１．１．２は、同じＩＰ情報と自分自身のＰＮＮＩノードＩＤを用いてレベル７２でＰＡＲ ＰＴＳＥを生成することにより、このＰＴＳＥを抽象する。ＬＧＮ１．１．２はこのＰＴＳＥをそのレベル７２ピア・グループ内でフラッドし、これはＬＧＮ１．１．１により受信される。ＬＧＮ１．１．１は受信されたＰＴＳＥを下へその子ピア・グループまでフラッドし、そこでＰＴＳＥはスイッチＭＳ３により受信される。ＬＧＮ１．１．２はまた、このＰＴＳＥを下へ自体の子ピア・グループまでフラッドし、そこでこれはスイッチＭＳ１、ＭＳ２により受信される。同様に、ＬＧＮ１．１はＬＧＮ１．１．２により生成されたＰＡＲ ＰＴＳＥを抽象し、自体のノードＩＤでコピーを生成し、このＰＴＳＥをそのレベル６４ピア・グループでフラッドし、また下へその子ピア・グループまでフラッドする。このＰＴＳＥは従って、３つのスイッチＭＳ１、ＭＳ２、ＭＳ３全てにより受信される。
【００３０】
ＰＡＲ ＰＴＳＥはＰＮＮＩ階層の全てのレベルで再生成されるため、スイッチＭＳ３は２つのＰＡＲ ＰＴＳＥを受信し、両方ともＭＲ１に関連する同じＩＰ情報を含む。１つは送信元がＬＧＮ１．１．２、もう１つはＬＧＮ１．１である。従ってＭＳ３は、Ｐｒｏｘｙ−ＰＡＲ照会をそのクライアント・ルータＭＲ３から受信したとき、図に示すようにＩＰ情報の２つのコピーをルータに提供する。（簡潔化のため、ＰＡＲ通知を含むＰＡＲ ＰＴＳＥの送信元ノードのＩＤは、図では括弧内のＬＧＮ番号により示してある。）一方スイッチＭＳ２はこのＩＰ情報で３つのＰＡＲ ＰＴＳＥを受信するので、ＩＰ情報の３つのコピーは、図に示すように、ＭＳ２によりそのクライアント・ルータＭＲ２に送信される。更にＭＳ１は、ＬＧＮ１．１．２とＬＧＮ１．１により生成された２つのＰＡＲ ＰＴＳＥを受信し、またそのメモリにそれが自体のレベル８８ピア・グループ用に生成したＰＡＲ ＰＴＳＥを格納する。従って、図に示すようにＭＳ１はここではＩＰ情報の３つのコピーをＭＲ１に戻す。この例では２つはその先祖ノードから受信されたコピー、１つは自体が生成したＰＴＳＥから受信されたコピーである。この例からわかるように、ＰＡＲ ＰＴＳＥが異なる階層レベルで再生成されると、各ルータが同じＩＰ情報の複製を受信する。この問題は、全ルータからのＰＡＲ通知を考慮すると明らかに大きくなる。この問題はまた、以下に述べる本発明の実施例の対象である。
【００３１】
図３は、この実施例の動作に伴うスイッチの主な要素を示す簡略図である。スイッチ１は制御ロジック２、メモリ３、及び回路４を含む。回路４は、デバイスがネットワークの他の部分及び関連するルータと通信するためのインターフェースとスイッチング回路を含む。この実施例のスイッチ１は、ＰＡＲ対応デバイスであり、関連するルータのＰｒｏｘｙ−ＰＡＲサーバとして機能する。制御ロジック２はスイッチの全体的動作を制御し、従って通常のＰＡＲ、Ｐｒｏｘｙ−ＰＡＲ機能、及びＰＴＳＥ生成・処理、コール・パス選択等の通常のＰＮＮＩ機能を実装する。また制御ロジック２は、ＩＰ情報管理機能を実行する（後述）。制御ロジック２はＰＮＮＩに従い、メモリ３にトポロジ・データベースを維持する。トポロジ・データベースは、ネットワーク・トポロジに関するスイッチのビューを定義したトポロジ・データを格納し、ＰＮＮＩ階層でのスイッチの先祖を識別する（後述）。メモリ３はＰＴＳＥリポジトリを格納し、リポジトリには制御ロジック２によりネットワークから受信されたＰＴＳＥが保存される。保存期間は、ＰＴＳＥが期限切れになるか、または通常のＰＮＮＩプロセスによりフラッシュされるまでである。一般に制御ロジック２は、ハードウェア、ソフトウェア、またはその組み合わせに実装することができるが、通常は、ソフトウェアを実行するプロセッサにより実装され、ソフトウェアは前記機能を実行するようプロセッサを構成する。適切なソフトウェアは、ここでの説明から当業者には明らかであろう。（もちろん、スイッチ・プロセッサはあらかじめ適切なソフトウェアで構成しておけるが、そのようなソフトウェアを構成するプログラム・コードは個別に提供することもできる。その場合プログラム・コードは、デバイスにロードされ、前記のように動作するようプロセッサが構成される。このようなプログラム・コードは、独立した要素として、または複数の制御機能用のプログラム・コードの要素として提供することも可能であり、ディスク等、コンピュータ可読媒体に組み込んで、或いはスイッチにロードするためネットワーク・オペレータに電子的に転送して提供することもできる。）
【００３２】
制御ロジック２により実装されるＩＰ情報管理プロセスは、この実施例では３つのフィルタ・メカニズムを含む。各フィルタは、メモリ３に保存されたＰＡＲＰＴＳＥのチェックを伴う。チェックにより冗長なＩＰ情報が識別され、Ｐｒｏｘｙ−ＰＡＲリクエストに応答して、クライアント・ルータに提供されたＩＰ情報から除外される。第１フィルタは、スイッチから見えるＰＮＮＩトポロジにＰＡＲ ＰＴＳＥの送信元ノードが存在するかチェックする。第２フィルタは、ネットワークでＰＡＲ ＰＴＳＥが関連するＩＰサービスのＡＴＭアドレスまでコール・パスが利用できるかチェックする。第３フィルタは、ＰＡＲ ＰＴＳＥの送信元ノードがＰＮＮＩ階層でスイッチの先祖かどうかチェックする。このように各フィルタが、メモリ３に保存されたトポロジ・データを利用する。トポロジ・データにより定義されるネットワーク・トポロジの簡単な例について、図４を参照して説明する。
【００３３】
前述のように、ＡＴＭネットワークでのＰＮＮＩトポロジ・データの通信は、各スイッチから自体のピア・グループの詳細、及びＰＮＮＩ階層の上位レベルで代表される任意のピア・グループの詳細が見えるように行われる。図４は、図１のシステムのスイッチＭＳ１から見た、衛星接続のスイッチＳ１からスイッチＳ２へのハンドオーバーの後のＰＮＮＩトポロジを示す。このトポロジ・ビューでは、ＭＳ１はレベル７２のＬＧＮ２．１．２にアップリンクｕ１を介して接続される。ＭＳ１とＳ２間の衛星接続のため、ＭＳ１はレベル６４のＬＧＮ２．０にもアップリンクｕ２を介して接続される。ＬＧＮ２．１．２は、水平リンクｈ１を介してレベル７２のＬＧＮ２．１．１に接続される。ＬＧＮ２．１．１はアップリンクｕ３を介してレベル６４のＬＧＮ２．０に、ＬＧＮ２．０は、水平リンクｈ２を介してレベル６４のＬＧＮ２．１にそれぞれ接続される。同様に、ＬＧＮ２．０はアップリンクｕ４を介してレベル３２のＬＧＮ１に、ＬＧＮ１は水平リンクｈ３を介してレベル３２のＬＧＮ２にそれぞれ接続される。ＰＮＮＩ階層のＭＳ１の先祖（つまり階層の上位層でＭＳ１を表す論理ノード）は図では陰影を付けて示してある。この場合のＭＳ１のトポロジ・データベースは、図のトポロジのリンク、ノードＩＤ、及びデバイス・アドレスを定義したデータを、階層の先祖ノードのＩＤ（及びＡＴＭアドレス）を示すノード階層一覧とともに格納する。
【００３４】
ネットワーク・システムでのスイッチ１の動作については、スイッチ１はネットワークからＰＡＲ ＰＴＳＥを受信し、ＰＡＲ ＰＴＳＥは制御ロジック２によりメモリ３のＰＴＳＥリポジトリに保存される。制御ロジック２は、クライアント・ルータにより定期的に発行されるＰｒｏｘｙ−ＰＡＲリクエストに応答して、メモリ３に保存されたＰＡＲ ＰＴＳＥからＩＰ情報を抽出し、このＩＰ情報を通常のＰＡＲサービス記述パケットでルータに提供する。このＩＰ情報通信プロセスの一部としてスイッチ制御ロジック２により実行される動作を図５に詳しく示す。図５のステップ１０に示すように、ルータからのＰｒｏｘｙ−ＰＡＲリクエストの受信後、制御ロジック２はメモリ３のＰＴＳＥリポジトリにアクセスし、ステップ１１で、ルータにより発行されるリクエストに従って第１のＰＡＲ ＰＴＳＥを選択する。ステップ１２で、制御ロジックはＰＡＲ ＰＴＳＥの送信元ノードＩＤを、前記のように、スイッチのネットワーク・ビューを定義したトポロジ・データのノードＩＤと比較する。（他の実施例では、制御ロジックはここで、ＰＡＲ ＰＴＳＥに指定された送信元ノードのＡＴＭアドレスをトポロジ・データベースに保存されたノードのＡＴＭアドレスと比較することもできる。）ステップ１３の”Ｎ”に示すように一致がなければ、送信元ノードは現在のトポロジのスイッチによってはアクセスできなくなっている。これは、例えばモバイル・ネットワークが移動し、新しいトポロジで送信元ノードとの接続が存在しなくなった場合に生じることがある。その場合、動作はステップ１４に進み、メモリ３にフラグが設定されて、ＰＡＲ ＰＴＳＥにカプセル化されたＩＰ情報は冗長であることが示される。ステップ１２、１３、１４は、このように前記の第１フィルタを構成する。ステップ１４から動作はステップ１９に進み、メモリ３にチェック対象のＰＡＲ ＰＴＳＥが残っているか制御ロジックによりチェックされる。残っている場合、ステップ２０で次のＰＴＳＥが選択され、動作はこのＰＴＳＥについてステップ１２に戻る。
【００３５】
ステップ１３で一致があったとすると、動作はステップ１５に進み、ＰＴＳＥのＩＰ情報により識別されたＩＰサービスのＡＴＭアドレスへのコール・パスが利用できるか制御ロジックにより確認される。従って、パス選択ロジックでＡＴＭアドレスへのパスを計算できない場合（エンドシステムの障害によりＩＰサービスが到達不能なため等）、またはアドレスへのコールを設定するネットワーク・リソースが不十分な場合（帯域幅、遅延等）、パスは利用できないことがステップ１６で確認される。その場合動作はステップ１４に進み、ＩＰ情報は冗長とのフラグが設定され、前のようにステップ１９に進む。ステップ１５、１６、１４はよって前記の第２フィルタを構成する。
【００３６】
ステップ１６でコール・パスが利用できるとすると、ステップ１７で制御ロジックが、前記のように、ＰＡＲ ＰＴＳＥの送信元ノードＩＤをメモリ３のノード階層一覧にあるノードＩＤと比較する。この実施例では、ノード階層一覧にスイッチ自体のノードＩＤ、及び上位レベルの先祖のＩＤが含まれると仮定している。ステップ１８の”Ｙ”に示されるように一致があった場合、スイッチ自体または階層の上位レベルの先祖によりＰＡＲ ＰＴＳＥが生成されている。その場合、動作はステップ１４に戻り、ＩＰ情報は冗長とのフラグが設定され、動作は前のように継続する。ステップ１７、１８、１４は従って前記の第３フィルタを構成する。（ノード階層一覧は関連ノードのＡＴＭアドレス及びこの例のノードＩＤを含むので、このフィルタは、階層一覧のノードのＡＴＭアドレスをＰＡＲ ＰＴＳＥに指定された送信元ノードのＡＴＭアドレスと比較することによっても等しく実装することができる。）
【００３７】
ステップ１８で一致がない場合、現在のＰＴＳＥのＩＰ情報は冗長とみなされず、動作はステップ１９に進み、ステップ２０に続く。ここで次のＰＡＲ ＰＴＳＥが前のように選択される。ステップ１９の”Ｎ”に示されるように、関連するＰＴＳＥが全てチェックされると、制御ロジックはステップ２１に進む。ここで、Ｐｒｏｘｙ−ＰＡＲリクエストに対応した、冗長ではないＩＰ情報がメモリから全て取得され、クライアント・ルータに提供される。プロセスはここで完了する。
【００３８】
図６は、図２に似たモバイル・ネットワーク・システムで、各スイッチＭＳ１、ＭＳ２、ＭＳ３は前記実施例に従ったスイッチ１である。このシナリオでは、図１のシナリオのように、アクセス・ポイント・スイッチＳ２（関連ルータＲ２）からの衛星接続のハンドオーバーの後、スイッチＭＳ３に、固定ネットワークのアクセス・ポイント・スイッチＳ１（関連ルータＲ１）への衛星接続があると仮定している。ＰＡＲ通知は便宜上簡略化している。特に図は、モバイル・ネットワークのモバイル・ルータＭＲ１からのＰＡＲ通知通信とともに、固定ネットワークからＭＲ３へのＰＡＲ通知の通信のみ示している。スイッチＭＳ１乃至ＭＳ３により冗長と識別され、従ってモバイル・ルータに送信されたＩＰ情報から除外されたＰＡＲ通知は、図に打ち消しの斜線で示している。ここからわかるように、スイッチＭＳ３はそのクライアント・ルータＭＲ３に、固定ネットワーク・ルータＲ１のＰＡＲ通知とＬＧＮ１．１．２から受信されたＭＲ１のＰＡＲ通知のみ送信する。アクセス・ポイント・スイッチＳ２（図１のＬＧＮ２．０）を表すＬＧＮは、スイッチＭＳ３から見たＰＮＮＩトポロジでは見えなくなり、従ってルータＲ２の”古い”ＰＡＲ通知は、前記の第１フィルタの動作を通してＭＲ３に送信されたＩＰ情報から除外される。ＭＳ３の先祖ノードＬＧＮ１．１から発生した複製ＰＡＲ通知は、前記の第３フィルタによりなくなる。更に、Ｒ１へのコール・パスが例えばＲ１の障害によりＭＳ３により利用できないことがわかった場合、Ｒ１のＰＡＲ通知は、前記の第２フィルタにより冗長と識別され、ＭＳ３によりＭＲ３に提供されない。
【００３９】
ＭＳ２で、スイッチＭＳ１から受信されたＭＲ１のＰＡＲ通知のみクライアント・ルータＭＲ２に提供され、ＭＳ２の先祖ＬＧＮ１．１、ＬＧＮ１．１．２から受信された複製ＰＡＲ通知は第３フィルタ・メカニズムにより除外される。ＭＳ１の場合、この実施例のノード階層一覧はＭＳ１自体のノードＩＤを含むため、ＭＲ１の全てのＰＡＲ通知が、前記のようにＭＳ１自体により生成されたＰＴＳＥのＰＡＲ通知を含め、この第３フィルタにより除外される。
【００４０】
この実施例でルータにより受信されたＩＰ情報の実質的な簡略化は、図６から明らかである。ただし、この利点は、図６に示す選択されたＰＡＲ通知だけではなく、ＰＡＲ通知が全て考慮されるとき劇的に大きくなることは理解されよう。従って、冗長な情報をなくすことによって、ＰＡＲ対応デバイスにより、関連ルータに提供されるＩＰ情報が大幅に簡略化され、ルータでのデータ処理も容易になり、ＩＰトポロジの最適構成が促進されることは明らかである。
【００４１】
本発明の、特に好適実施例について説明しているが、本発明の範囲から逸脱することなく、多くの変更、変形が可能なことは理解されよう。例えば、前記実施例では３つのフィルタ・メカニズムを採用しているが、これらフィルタ・メカニズムの１つまたは任意の組み合わせもまた、必要に応じて他の実施例に採用することができる。更に、フィルタリングは、前記の実施例ではＰｒｏｘｙ−ＰＡＲリクエストに応答して実行されるが、実施例によっては、例えばネットワークからＰＡＲ ＰＴＳＥを受信したとき、あらかじめフィルタ・メカニズムを１つ以上適用することもできる。また、前記実施例のスイッチとルータは、Ｐｒｏｘｙ−ＰＡＲを介して通信する個別デバイスであるが、ルータをＰＡＲ対応デバイスと統合した実施例も考えられる。その場合、ルータ・ロジックは、他の何らかの内部通信プロトコルを介してＰＡＲロジックと通信することができる。
【００４２】
他の実施例では、冗長なＩＰ情報を除外するのではなく、前記のように、スイッチによりＩＰ情報にタグを付け、関連ルータが冗長な情報と冗長ではない情報を区別できるようにすることもできる。また、本発明の例は、モバイル・ネットワークのシナリオをもとに説明しているが、本発明の実施例はまた、固定ネットワーク・システムにも都合よく適用することができ、ＩＰトポロジの自動構成が促進されることは理解されよう。更に前述のように、本発明の実施例は、ＩＰ以外のプロトコル、及びＩＰルータ以外のプロトコル・デバイスにも適用することができる。
【図面の簡単な説明】
【図１】本発明の実施例で扱う問題を示すモバイル・ネットワーク・システムの図である。
【図２】本発明の実施例で扱う問題を示す他のモバイル・ネットワーク・システムの図である。
【図３】本発明を具体化したスイッチを示す図である。
【図４】図１のシステムの１つのスイッチから見たＰＮＮＩトポロジを示す図である。
【図５】図３のスイッチにより実装されたＩＰ情報管理方法を示すフローチャートである。
【図６】実施例の動作を示すモバイル・ネットワーク・システムの図である。
【符号の説明】
１ スイッチ
２ 制御ロジック
３ メモリ
４ インターフェースとスイッチング回路
【発明の属する技術分野】
本発明は、一般にはＰＮＮＩ（専用ネットワーク間インターフェース）ネットワークのプロトコル情報管理に関する。本発明の実施例は、物理的ＡＴＭ（非同期伝送モード）ネットワーク・トポロジに対する上位層トポロジの効率的構成を促進する方法及び装置を与える。
【０００２】
【従来の技術】
本発明について詳しく説明する前に、背景について説明する。ＰＮＮＩは、ＡＴＭネットワークを対象にＡＴＭフォーラムにより定義された階層型動的リンク状態ルーティング・プロトコルである。ＰＮＮＩプロトコルは、特に、ネットワークが個々のネットワーク・ノードからどのように”見える”か、従ってノードがどのように通信するかを決定するトポロジ情報を作成・配布するシステムを提供する。このプロトコルの基本機能は、スイッチのグループを”ピア・グループ”にまとめる機能である。ピア・グループそれぞれの詳細が１つの論理ノード（”論理グループ・ノード”すなわちＬＧＮ）に抽象され、論理ノードがそのピア・グループの外部から見える全てになる。各ピア・グループの１ノードは”ピア・グループ・リーダ”として働き、階層の次の上位レベルにある論理グループ・ノードとしてそのピア・グループを代表する。このシステムは、ＰＮＮＩが階層上、ネットワーク・トポロジ情報を伝播するように再帰的に適用される。スイッチから利用できるＰＮＮＩトポロジ情報は、各スイッチが自体のピア・グループの詳細及びＰＮＮＩ階層の上位レベルで自体を代表するピア・グループの詳細を見るようなものになっている。この階層トポロジの抽象により、大規模ＡＴＭネットワークをサポートするため必要なリソースが少なくなる。
【０００３】
ＰＮＮＩネットワークを通して通信されるトポロジ・データは、ＰＮＮＩトポロジ状態要素（ＰＴＳＥ）により定義される。ＰＴＳＥは、ネットワーク・デバイスからアクセスできるノード、リンク、及びアドレスに関するデータを含み、各ノードがそのネットワーク・ビューを定義するトポロジ・データベースを維持するように、ノードにより作成・配布される。ＰＴＳＥは、ピア・グループのノード間でフラッド（送出）される。これにより、各ピア・グループ・ノードのトポロジ・データベースが同じになり、従ってネットワーク・ビューも同じになる。しかし、階層の次のレベルではピア・グループのトポロジは、前記のように１つの論理ノードに抽象される。論理グループ・ノードは、その子ピア・グループ内でアクセスできるＰＴＳＥ通知アドレス（ａｄｖｅｒｔｉｓｉｎｇ ａｄｄｒｅｓｓｅｓ）を生成し、階層の次のレベルの近隣（ｎｅｉｇｈｂｏｒｓ）に配布するが、ノードの詳細とピア・グループ内のリンクは失われる。論理グループ・ノードによりこのように生成されたＰＴＳＥはまた、ＬＧＮによりその近隣から受信されたＰＴＳＥとともに階層を元の方向へフラッドされ、下位ノードは”先祖”（つまりＰＮＮＩ階層の上位レベルで下位ノードを代表するノード）を識別でき、そのＰＮＮＩトポロジ・ビューを維持することができる。
【０００４】
一般に、ネットワークを通してフラッドされたＰＴＳＥは、その元ノード（つまりＰＴＳＥを発送または生成したノード）しか変更できないが、ＰＮＮＩは、ＰＴＳＥの”タイムアウト”システムを定義しており、これにより各ＰＴＳＥに有効期限（通常は１時間）が与えられる。ＰＴＳＥの元ノードは、ＰＴＳＥをその近隣に再配布することによって、ＰＴＳＥを定期的に”リフレッシュ”することになるので、ＰＴＳＥは再びネットワークを通してフラッドされる。ただし、ＰＴＳＥがリフレッシュされないままＰＴＳＥの有効期限が切れると、ＰＴＳＥは有効なトポロジ情報とみなされなくなり、削除されるかまたはネットワークから”フラッシュ”される。従って、例えばリンク障害のためノードにアクセスできなくなった場合、そのノードに関連するＰＴＳＥは最終的にはネットワークからフラッシュされる。また１９９９年８月６日付欧州特許出願第９９１１５５８０．５号は、ピア・グループ・リーダが自体のピア・グループのアドレスのアクセス可能性をチェックし、そのピア・グループのアドレス・アクセス可能性の変更を近隣ノードに通知するメカニズムを開示している。
【０００５】
ＰＮＮＩは、ＡＴＭ層での移動性をフルにサポートする（”ＰＮＮＩ Ａｄｄｅｎｄｕｍ ｆｏｒＭｏｂｉｌｉｔｙ Ｅｘｔｅｎｓｉｏｎｓ ｖ１．０”、ＡＴＭ Ｆｏｒｕｍ ａｆ−ｒａ−０１２３．０００、Ａｐｒｉｌ １９９９）。例えばＰＮＮＩ移性拡張機能では、ＡＴＭモバイル・ネットワークを抽象する論理グループ・ノードは、地上系バックボーン・ネットワークのＰＮＮＩ階層でローミングすることができる。正規のＰＮＮＩを通して、モバイル・ネットワークの現在位置を詳しく示すルーティング情報が通知されるので、地上系エンドシステムからモバイル・ネットワークのエンドシステムへのコール及びその逆のコールを確立することができる。またＡＴＭネットワークにより、ＩＰ（インターネット・プロトコル）情報等の上位層プロトコル情報を伝えることができる。これは、ＰＡＲ（ＰＮＮＩ増加ルーティング）と呼ばれるＰＮＮＩプロトコルの拡張機能を採用することによって簡単に行える。ＰＡＲについては”ＰＮＮＩ Ａｕｇｍｅｎｔｅｄ Ｒｏｕｔｉｎｇ（ＰＡＲ）”、ａｆ−ｒａ−０１０４．０００、ＡＴＭ Ｆｏｒｕｍ、Ｊａｎｕａｒｙ １９９９を参照されたい。簡単には、ＰＡＲによりそれ自体はＡＴＭネットワークの動作に関連しないＩＰ情報をネットワークに配布することができる。ＰＡＲは、前述のＰＴＳＥを利用して、ＡＴＭトポロジ情報に加えてＩＰ関連情報を配布する。ネットワーク内のＰＡＲ対応デバイスは、ＩＰ情報をＰＴＳＥにカプセル化する。これは通常のＰＮＮＩ方式で配布される。いわゆる”ＰＡＲ ＰＴＳＥ”のＩＰ情報は、ＰＡＲに対応していないＰＮＮＩノードからは不透明であるが、ＰＡＲに対応した他のノードはＰＡＲ ＰＴＳＥのＩＰ情報のフォーマットを認識する。従ってネットワーク内にあるＰＡＲ対応デバイスは、ＰＡＲ ＰＴＳＥによってネットワークを通してＩＰ情報を通信することができ、ＰＡＲに対応した別のデバイスはそのＩＰ情報を抽出することができる。
【０００６】
”Ｐｒｏｘｙ−ＰＡＲ”と呼ばれるＰＮＮＩプロトコルの他の拡張機能では、上位層プロトコル・デバイス、特にルータ等のＩＰデバイスは、自体がＰＮＮＩに参加することなく、ネットワークを通してＩＰ情報を通信することができる。Ｐｒｏｘｙ−ＰＡＲについても”ＰＮＮＩ Ａｕｇｍｅｎｔｅｄ Ｒｏｕｔｉｎｇ（ＰＡＲ）”、ａｆ−ｒａ−０１０４．０００、ＡＴＭ Ｆｏｒｕｍ、Ｊａｎｕａｒｙ １９９９を参照されたい。Ｐｒｏｘｙ−ＰＡＲは、いわばシンプルな交換プロトコルであり、ＩＰデバイスをＡＴＭネットワークに統合することができ、ＩＰデバイスでＰＮＮＩを実行する必要は全くない。ＩＰデバイスは、Ｐｒｏｘｙ−ＰＡＲサーバとして構成されたＰＡＲ対応デバイスを介してネットワークに接続することができる。ＩＰデバイス自体はＰｒｏｘｙ−ＰＡＲクライアントとして構成される。Ｐｒｏｘｙ−ＰＡＲクライアントは、Ｐｒｏｘｙ−ＰＡＲに従い、それがサポートするＩＰサービスの詳細をＰｒｏｘｙ−ＰＡＲサーバに登録することができる。この情報は前記のようにＰＡＲ ＰＴＳＥにカプセル化され、通常のＰＮＮＩ方式によりネットワークでフラッドされる。Ｐｒｏｘｙ−ＰＡＲクライアントはまた、前記のようにＰＡＲ対応デバイスによりＰＡＲ ＰＴＳＥが受信されネットワークに接続された他のＩＰデバイスに関する情報をＰｒｏｘｙ−ＰＡＲサーバに要求することができる。このようにしてＩＰ情報は、ＩＰデバイスがＰＮＮＩに参加することなくＩＰデバイス間でやりとりされる。
【０００７】
ＰＡＲとＰｒｏｘｙ−ＰＡＲを前記のように使用することで、プロトコル・デバイス、特にＩＰデバイスは、ＰＮＮＩネットワーク上のプロトコル情報のこの通信を介して相互確認をすることができ、上位層プロトコル・トポロジの構成に必要なプロトコル情報を各デバイスに手動で入力する必要がなくなる。例えば、ＡＴＭクラウドの端にあるＩＰルータは相互確認ができ、ＩＰ隣接点（ａｄｊａｃｅｎｃｉｅｓ）を手動で構成する必要がなくなる。更に、１９９９年８月６日付欧州特許出願第９９１１５５４４．１号は、ＩＰルータのＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ ＰａｔｈＦｉｒｓｔ）インターフェースを動的に構成するメカニズムを開示している。例えばモバイル・ネットワークのルータは、モバイル・ネットワークがローミングし、新しい接続を確立する際、他の（固定またはモバイル）ネットワーク・ルータのＯＳＰＦエリアでＯＳＰＦインターフェースを動的に構成することができる。ＯＳＰＦインターフェースが動的に構成されるかどうかにかかわらず、ＰＡＲとＰｒｏｘｙ−ＰＡＲでは、ルータがそのプロトコル情報（例えばＩＰアドレス、ＡＴＭアドレス、ＯＳＰＦエリア）を、ルータのサービス提供側ＡＴＭスイッチに登録することができる。その場合ＡＴＭはネットワーク全体にデータをフラッドする。他のルータは、そのサービス提供ＡＴＭスイッチに照会することによってこのＩＰ情報を取得することができる。ルータはそこで、ルーティング情報を交換して、通常通り、受信した情報から確認した他のルータとの近隣関係または”ピア”を形成することができる。
【０００８】
【発明が解決しようとする課題】
一般に、前記のようにＰＮＮＩネットワークを通したプロトコル・デバイス間プロトコル情報の通信にＰＡＲが用いられるとき、物理的ＡＴＭネットワークでの上位層プロトコル・トポロジの構成は、ＰＡＲ対応スイッチによりそのクライアント・デバイスにＰｒｏｘｙ−ＰＡＲを介して提供されるプロトコル情報にもとづく。現在、ＰＡＲ対応スイッチは、そのクライアント・デバイスからのＰｒｏｘｙ−ＰＡＲリクエストに応答するため、ネットワークからＰＡＲ ＰＴＳＥで受信されている、要求されたタイプのプロトコル情報を全て提供する。本発明は、これが不要であるという認識をもとにしており、当該プロトコルに関してネットワーク・トポロジの効率的構成を処理することができる。
【０００９】
【課題を解決するための手段】
本発明の側面に従い、ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイスのプロトコル情報を管理する方法が提供される。方法は、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別するステップと、
受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するステップと、を含み、冗長と認識されたプロトコル情報はプロトコル・デバイスに提供されたプロトコル情報から除外される。
【００１０】
本発明の第２の側面によれば、ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイスのプロトコル情報を管理する方法が提供される。この方法は、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別するステップと、
受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するステップと、を含み、
更に、プロトコル・デバイスに提供されたプロトコル情報にタグを付け、冗長なプロトコル情報いを冗長ではないプロトコル情報と区別するステップが含まれる。
【００１１】
従って、本発明の実施例では、ＰＡＲ ＰＴＳＥがＰＡＲ対応デバイスによってチェックされ、冗長なプロトコル情報が識別される。実施例によっては、関連付けられたプロトコル・デバイスに提供されたプロトコル情報にタグが付けられ、冗長なプロトコル情報と冗長ではないプロトコル情報が区別されるので（例えば、冗長なプロトコル情報と冗長ではないプロトコル情報のいずれか、または両方にタグを付けることによって）、適宜構成されたプロトコル・デバイスはこの２つを区別でき、例えば冗長な情報を無視することができる。冗長とされたプロトコル情報は、他の好適実施例では、プロトコル・デバイスに提供されたプロトコル情報から除外されるだけである。プロトコル情報が冗長であり得るのは、古いとき、複製されているとき、使用できないとき、または不要なときであり、この冗長な情報を指示することによって、またはプロトコル・デバイスに提供されたプロトコル情報から除外することによって、デバイスのプロトコル情報処理が簡略化され、当該プロトコルについてネットワーク・トポロジの効率的構成が促進される。プロトコル・デバイスに提供された情報から冗長なプロトコル情報を除外することは、”フィルタ”操作とみなすことができ、これを適用することで、関連するプロトコル情報のみプロトコル・デバイスにより受信されるようになる。
【００１２】
プロトコル情報は、以下に詳しく述べる好適実施例では、ＩＰ情報を含み、ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスはＩＰデバイス、特にルータである。ただ、ＩＰは、ＰＮＮＩにより現在サポートされているプロトコルであるが、当業者には明らかなように、ＰＮＮＩは他のプロトコルも容易にサポートすることができる。従って、プロトコル情報にＩＰＸ、ＮｅｔＢＩＯＳ（ネットワーク基本入出力システム）、ＡＲＰ（アドレス解決プロトコル）等の情報が含まれる実施例も考えられる。同様に、ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスは、ルータ、ＤＮＳ（ドメイン・ネーム・システム）サーバ、ＡＴＭ ＡＲＰサーバ、ディレクトリ・サーバ、ゲートウェイ等、当該プロトコルに従ってＰＡＲ ＰＴＳＥから抽出されたプロトコル情報を使用する任意のデバイスが考えられる。
【００１３】
ＰＡＲ対応デバイスにより様々なチェック・プロセスを実行して冗長な情報を識別することができる。例えば、受信されたＰＡＲ ＰＴＳＥをチェックすれば、そのＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが、ＰＡＲ対応デバイスから見えるＰＮＮＩトポロジに存在するか確認することができる。存在しない場合、ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は冗長とみなせる。このチェックは、ＰＡＲ ＰＴＳＥの送信元ノードＩＤを、ＰＡＲ対応デバイスから見えるＰＮＮＩトポロジ（デバイスに保存された通常のＰＮＮＩトポロジ・データにより定義されている通り）のノードのＩＤと比較することによって都合よく実行することができる。このチェックにより、アクセスできなくなった（例えば、モバイル・ネットワークが移動し、送信元ノードとＰＡＲ対応デバイスの接続がなくなったため）ノードからのプロトコル情報を冗長と識別することができる。
【００１４】
また前記に加えて、より好適には、ＰＡＲ ＰＴＳＥをチェックすれば、プロトコル情報に指定されたＩＰサービスのＡＴＭアドレスへのネットワークを通したコール・パスをＰＡＲ対応デバイスから利用できるか確認することができる。通常のパス選択ロジックでは、ＡＴＭアドレスへのコールを受け入れられない場合（例えば、アドレスが到達不能で、パスを計算できないため、利用できるリソースが不十分なため等）、コール・パスは利用できず、プロトコル情報は冗長とみなされる。このチェックは、例えばネットワークが分割され、エンドシステムのアドレスが到達不能になったときに利用できる。このメカニズムは、静的ＡＴＭネットワークに適用すれば、リセットされているノードとの接続が、ノードによるそのＰＴＳＥのフラッシュが完了する前に削除された”ゴースト”ＰＡＲ ＰＴＳＥを防ぐことができる（ＡＴＭスイッチがリセットされた場合等）。
【００１５】
この他（より好適には）、ＰＡＲ ＰＴＳＥをチェックすることで、ＰＡＲ ＰＴＳＥの送信元ノードがＰＮＮＩ階層でＰＡＲ対応デバイスの先祖、つまりＰＮＮＩトポロジの上位レベルにあるデバイスを代表する論理ノード、であるか確認することができる。先祖ノードである場合、ＰＡＲ ＰＴＳＥに含まれるプロトコル情報は冗長とみなせる。このチェックは、ＰＡＲ ＰＴＳＥの送信元ノードＩＤをＰＡＲ対応デバイスに保存されたＰＮＮＩトポロジ・データの先祖ノードのＩＤと比較することによって都合よく実行することができる。このチェックにより、先祖ノードによって生成されたＰＴＳＥで受信されたプロトコル情報の複製を冗長と識別することができる。
【００１６】
前述のＰｒｏｘｙ−ＰＡＲによれば、ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスは、Ｐｒｏｘｙ−ＰＡＲクライアントとして構成された独立したデバイス（つまり、Ｐｒｏｘｙ−ＰＡＲにより定義されたＰｒｏｘｙ−ＰＡＲクライアント動作を実装する制御ロジックを含む）、またはＰｒｏｘｙ−ＰＡＲサーバとして構成されたＰＡＲ対応デバイス（つまり、Ｐｒｏｘｙ−ＰＡＲにより定義されたＰｒｏｘｙ−ＰＡＲサーバ機能を実装する制御ロジックを含む）でもよい。その場合、プロトコル情報は、Ｐｒｏｘｙ−ＰＡＲクライアント・デバイスからの通常の定期的リクエストに応答してＰＡＲ対応デバイスから提供することができる。ただし、プロトコル・デバイスがＰＡＲ対応デバイスと統合された、例えば、ＡＴＭスイッチ・ロジックが何らかの内部通信プロトコルを介してＩＰルータ・ロジックと通信する組み合わせデバイスとして統合された他の実施例も考えられる。その場合、ルータ・ロジックは、ＰＡＲ対応スイッチ・ロジックのＩＰ情報を定期的にポーリングすることができる。その後ＩＰ情報は、Ｐｒｏｘｙ−ＰＡＲと同様なリクエストに応答してルータ・ロジックに提供することができる。ただし、スイッチ・ロジックはまた、ＩＰ情報をルータに自動的に、例えば一定間隔で、またはＰＮＮＩトポロジの変更、ネットワークからの新しいＰＡＲ ＰＴＳＥの受信等のイベントに応答して提供することもできる。いずれの場合でも、ＰＡＲ ＰＴＳＥのチェック（或いはプロトコル情報のタグ付け）は、プロトコル・デバイスにプロトコル情報が提供されるとき、実装形態によるが、例えばリクエストが受信されたとき実行することも、また場合によっては、ＰＡＲ ＰＴＳＥが受信されたとき前もって実行することもできる。
【００１７】
本発明の実施例は、固定ネットワーク、モバイル・ネットワークいずれのシナリオにも適用できることは理解されよう。
【００１８】
本発明の第３の側面では、ＰＮＮＩ階層ネットワークに接続するＰＡＲ対応デバイスが提供される。このデバイスは、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥを保存するメモリと、
受信されたＰＡＲ ＰＴＳＥをチェックして、前記ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別し、冗長とされたプロトコル情報は除外し、受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するよう構成された制御ロジックと、を含む。
【００１９】
本発明の第４の側面では、ＰＮＮＩ階層ネットワークに接続するＰＡＲ対応デバイスが提供される。このデバイスは、
ＰＡＲ対応デバイスによりネットワークから受信されたＰＡＲ ＰＴＳＥを保存するメモリと、
受信したＰＡＲ ＰＴＳＥをチェックして、ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別し、受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するよう構成された制御ロジックと、を含み、
制御ロジックは更に、プロトコル・デバイスに提供されたプロトコル情報にタグを付け、冗長なプロトコル情報と冗長ではないプロトコル情報を区別するよう構成される。
【００２０】
全般には、本発明を具体化した方法を基準に、機能や特徴について説明しているが、本発明を具体化した装置では、対応する機能や特徴も得られ、逆も同様であることは理解されよう。
【００２１】
本発明の他の側面では、複数のＰＡＲ対応デバイス及び複数のプロトコル・デバイスを含むＰＮＮＩ階層ネットワークが得られる。ＰＡＲ対応デバイスはそれぞれ、対応するプロトコル・デバイスに関連付けられ、そのプロトコル・デバイスにより生成されたプロトコル情報のネットワークを通して通信が行われる。ＰＡＲ対応デバイスは、本発明の第３または第４の側面を具体化した少なくとも１つのＰＡＲ対応デバイスを含む。本発明の他の側面では、コンピュータ・プログラム・コード手段を含むコンピュータ・プログラム要素が得られる。プログラム・コード手段は、ＰＮＮＩ階層ネットワークに接続するため、ＰＡＲ対応デバイスのプロセッサにロードされると、前記のようにプロトコル情報管理方法を実行するようプロセッサを構成する。
【００２２】
【発明の実施の形態】
本発明の好適実施例について、ＰＡＲとＰｒｏｘｙ−ＰＡＲを通してＩＰルータ間でＩＰ情報がやりとりされるモバイル・ネットワーク・システムの文脈から説明する。実施例の動作について説明する前に、実施例で扱う問題について、図１及び図２を参照して説明する。まず図１を考える。これはモバイル・ネットワークのシナリオの１例を示す。モバイル・ネットワークは、例えば”部隊”編成であり、見通し線リンク（ｌｉｎｅ−ｏｆ−ｓｉｇｈｔ−ｌｉｎｋｓ）を介して接触するときには一時的にネットワークを形成することができ、地上の固定ネットワークとの接続は、固定ネットワーク・インフラのアクセス・ポイントとの衛星接続を通して得られる。図のスイッチＳ１及びＳ２は、固定ネットワークのアクセス・ポイントを構成し、それぞれ、モバイル・ネットワークを固定ネットワークに接続する衛星リンクをサポートする。アクセス・ポイント・スイッチＳ１はＩＰルータＲ１に、スイッチＳ２は同様にＩＰルータＲ２に接続される。アクセス・ポイント・スイッチＳ１、Ｓ２はそれぞれ、ＰＮＮＩ階層の最下位のレベル（レベル８８）にある他の１つ以上のスイッチとＰＮＮＩピア・グループ（図の楕円）を形成する。この場合は各ピア・グループに２つのスイッチが示してある。ピア・グループは、ここでは、各ピア・グループの固定ネットワーク・ルータが１つだけになるように定義される。次のレベル（階層のレベル６４）では、スイッチＳ１のレベル８８ピア・グループは論理グループ・ノードＬＧＮ１．０により代表され、スイッチＳ２のピア・グループはレベル６４の論理ノードＬＧＮ２．０により代表される
【００２３】
図には２つのモバイル・ネットワークも示してあり、それぞれ簡潔化のため、モバイル・ネットワーク・ルータ（ＭＲ１、ＭＲ２）に接続された１つのスイッチ（ＭＳ１、ＭＳ２）により表してある。モバイル・ネットワーク・スイッチＭＳ１、ＭＳ２は、図のように、レーザ見通し線リンク（ｌａｓｅｒ ｌｉｎｅ−ｏｆ−ｓｉｇｈｔ ｌｉｎｋ）ＬＳを介して相互接続される。ＭＳ１はまた、図のように、固定ネットワークのアクセス・ポイント・スイッチＳ２に衛星リンクを介して接続される。各スイッチＭＳ１、ＭＳ２はＰＮＮＩレベル８８にピア・グループを形成する。次のレベル（ＰＮＮＩ階層のレベル７２）では、ＭＳ１のモバイル・ネットワークが論理グループ・ノードＬＧＮ２．１．１により代表され、同様にＭＳ２のモバイル・ネットワークはレベル７２で論理グループ・ノードＬＧＮ２．１．２により代表される。論理ノードＬＧＮ２．１．１、ＬＧＮ２．１．２はレベル７２でピア・グループを形成し、従ってこのレベルのモバイル・ネットワークＭＳ２はモバイル・ネットワークＭＳ１の階層を統合することができる。モバイル・ネットワークＭＳ１は衛星を介してアクセス・ポイント・ノードＳ２に接続されるので、モバイル・ネットワークのレベル７２ピア・グループは、階層のレベル６４で論理ノードＬＧＮ２．１により代表され、このレベルのアクセス・ポイント・ノードを表すＬＧＮ２．０とピア・グループを共有する。レベル６４は従って、モバイル・ネットワークがアクセス・ポイント・ネットワークの階層を統合できるレベルである。レベル６４のＬＧＮ２．０とＬＧＮ１．０の間に論理接続はない。アクセス・ポイントはＰＮＮＩレベル３２（”アクセス・ポイント・レベル”）で論理的に接続され、論理グループ・ノードＬＧＮ１、ＬＧＮ２は図に示すようにピア・グループを共有する。
【００２４】
各スイッチＳ１、Ｓ２、ＭＳ１、ＭＳ２はＰＡＲに対応しているので、ＰＡＲＰＴＳＥをフラッドすることによってＰＮＮＩネットワークＩＰ情報を通知することができ、ネットワークから受信されたＰＡＲ ＰＴＳＥからＩＰ情報を抽出することができる。更に各スイッチは、これに接続されたルータのＰｒｏｘｙ−ＰＡＲサーバとして構成され、各ルータはＰｒｏｘｙ−ＰＡＲクライアントとして構成される。従ってＩＰ情報は、ルータとそのサービス提供スイッチとの間で、前述のようにＰｒｏｘｙ−ＰＡＲに従ってやりとりされる。
【００２５】
Ｐｒｏｘｙ−ＰＡＲでは、ルータがＩＰ情報をそのサービス提供スイッチに登録するとき、範囲を指示することができ、スイッチによりＰＡＲ ＰＴＳＥにカプセル化されたＩＰ情報を、ＡＴＭネットワークで、指定範囲に一致するＰＮＮＩレベルに通知することができる。本発明の例では、ルータはそのＩＰ情報を、ＰＮＮＩレベル６４に等しい範囲で登録する。得られるＰＡＲ通知は、図では便宜上簡略化している。特に図は、ルータＲ２により登録されたＩＰ情報のルータＭＲ１への転送、及びルータＭＲ１により登録されたＩＰ情報のルータＭＲ２への転送のみ示している。
【００２６】
まずルータＲ２を考えると、ルータＲ２によりスイッチＳ２に登録され、ＩＰ情報を含むＰＡＲ通知は、Ｓ２によりＰＡＲ ＰＴＳＥにカプセル化され、スイッチのレベル８８ピア・グループ内でフラッドされる。これはレベル６４でＬＧＮ２．０としてピア・グループを表すピア・グループ・リーダにより受信される。ＬＧＮ２．０は従ってＩＰ情報のＰＡＲ ＰＴＳＥを生成し、これはそのレベル６４ピア・グループ内でフラッドされ、そこでＬＧＮ２．１により受信される。このノードは、受信されたＰＴＳＥを下へその子ピア・グループまでフラッドし、そこでＩＰ情報は最終的にスイッチＭＳ１（及びスイッチＭＳ２）により受信される。ＭＳ１は次に、図のように、ＩＰ情報をＰｒｏｘｙ−ＰＡＲを介してそのクライアント・ルータＭＲ１に転送する。また同じく図に示すように、ＭＳ１は、ＭＲ１により登録されたＩＰ情報を自体のピア・グループ内に通知する。これはレベル７２でＬＧＮ２．１．１として機能するピア・グループ・リーダにより受信される。このノードは次にそのレベル７２内でＭＲ１を通知するＰＡＲＰＴＳＥを生成し、これはＬＧＮ２．１．２により受信される。ＬＧＮ２．１．２はレベル８８でその子ピア・グループにＰＴＳＥをフラッドし、そこでＭＳ２はＩＰ情報をＰｒｏｘｙ−ＰＡＲを介してそのクライアント・ルータＭＲ２に転送する。
【００２７】
このように、モバイル・ネットワークＭＳ１はアクセス・ポイントＳ２との衛星接続を確立し、モバイル・ルータＭＲ１は固定ネットワーク・ルータＲ２からＩＰ情報（ＩＰアドレス、ＡＴＭアドレス、ＯＳＰＦエリア等）を受信する。ＭＲ１はそこで、欧州特許出願第９９１１５５４４．１号に述べられているように、Ｒ２とのＯＳＰＦインターフェースを動的に構成することができる。従って、固定ネットワークとの接続が確立されると、ＭＲ１は、現在のアクセス・ポイントに関連付けられた固定ネットワーク・ルータ（ここではＲ２）とのピアになることができる。ただし、モバイル・ネットワークＭＳ１が、アクセス・ポイントＳ１との衛星接続の圏外に移動したとすると、接続はアクセス・ポイントＳ２に移る。その場合、モバイル・スイッチＭＳ１はまだ、固定ネットワーク・ルータＲ１に関連する、前の衛生接続からのＰＡＲ ＰＴＳＥをそのメモリに持つ。前述のように、ＰＡＲ ＰＴＳＥを変更できるのは送信元ノードだけであり（ただしここには関連しないが”プロキシ・フラッシュ”の場合を除く）、Ｒ１からの情報はＰＴＳＥが３０分乃至６０分後に期限切れになるまでまだＭＳ１にとどまる。その時間の間、ＭＳ１は、ＭＲ１からの定期的Ｐｒｏｘｙ−ＰＡＲリクエストに応答してＲ１とＲ２両方に関連するＩＰ情報をそのクライアント・ルータＭＲ１に返す。ＭＲ１は現在のアクセス・ポイントからの情報と古いアクセス・ポイントからの情報を区別することができず、デフォルト動作は従ってＲ１、Ｒ２両方とのピアになることである。従って、モバイル・ネットワークがローミングし、一連のアクセス・ポイントを介して固定ネットワークに適合する際、ＰＡＲ情報の履歴をサービス提供側スイッチに蓄積でき、クライアント・ルータは、現在のアクセス・ポイントに関連するＰＡＲ情報及び古いアクセス・ポイントに関連するＰＡＲ情報を確認する手段を持たない。同様に、図のモバイル・ネットワークＭＳ２がＭＳ１の圏外に移動し、他のモバイル・ネットワークと新しい見通し線リンクを確立した場合、ＭＲ２はそのサービス提供スイッチからＭＲ１に関する情報を受信し続け、これは関連付けられたＰＡＲ ＰＴＳＥの有効期限が切れるまで続く。この問題は以下に説明する本発明の実施例で扱う問題の１つである。
【００２８】
図２は第２モバイル・ネットワークのシナリオで、実施例で扱う別の問題を示す。ここでは簡潔化のため、３つのモバイル・ネットワークを、それぞれモバイル・ネットワーク・ルータＭＲ１乃至ＭＲ３に接続されたスイッチＭＳ１乃至ＭＳ３により表す。スイッチＭＳ１乃至ＭＳ３は、図のように、モバイル・プラットフォーム間の見通し線リンクＬＳを介して相互接続される。スイッチＭＳ３は、ＰＮＮＩ階層のレベル８８のＰＮＮＩピア・グループを表し、スイッチＭＳ１、ＭＳ２はレベル８８の別のピア・グループを共有する。次のレベル（レベル７２）では、スイッチＭＳ３は論理グループ・ノードＬＧＮ１．１．１により代表され、ＭＳ２のレベル８８ピア・グループは論理グループ・ノードＬＧＮ１．１．２により代表される。これらのレベル７２ノードは、ＰＮＮＩレベル６４のＬＧＮ１．１により代表されるピア・グループを共有する。例えば図１のシナリオのように固定ネットワークとの接続があると仮定すると、ＬＧＮ１．１はレベル６４ピア・グループを論理ノードＬＧＮ１．０と共有し、レベル８８固定ネットワーク・ピア・グループを表す。
【００２９】
このシステムでモバイル・ルータＭＲ１に関連するＩＰ情報のやりとりは、図のＰＡＲ通知により示される。ＭＲ１により登録されたＩＰ情報をカプセル化したＰＡＲ ＰＴＳＥがスイッチＭＳ１により生成され、ＭＳ１のレベル８８ピア・グループ内にフラッドされ、スイッチＭＳ２により受信される。ＬＧＮ１．１．２は、同じＩＰ情報と自分自身のＰＮＮＩノードＩＤを用いてレベル７２でＰＡＲ ＰＴＳＥを生成することにより、このＰＴＳＥを抽象する。ＬＧＮ１．１．２はこのＰＴＳＥをそのレベル７２ピア・グループ内でフラッドし、これはＬＧＮ１．１．１により受信される。ＬＧＮ１．１．１は受信されたＰＴＳＥを下へその子ピア・グループまでフラッドし、そこでＰＴＳＥはスイッチＭＳ３により受信される。ＬＧＮ１．１．２はまた、このＰＴＳＥを下へ自体の子ピア・グループまでフラッドし、そこでこれはスイッチＭＳ１、ＭＳ２により受信される。同様に、ＬＧＮ１．１はＬＧＮ１．１．２により生成されたＰＡＲ ＰＴＳＥを抽象し、自体のノードＩＤでコピーを生成し、このＰＴＳＥをそのレベル６４ピア・グループでフラッドし、また下へその子ピア・グループまでフラッドする。このＰＴＳＥは従って、３つのスイッチＭＳ１、ＭＳ２、ＭＳ３全てにより受信される。
【００３０】
ＰＡＲ ＰＴＳＥはＰＮＮＩ階層の全てのレベルで再生成されるため、スイッチＭＳ３は２つのＰＡＲ ＰＴＳＥを受信し、両方ともＭＲ１に関連する同じＩＰ情報を含む。１つは送信元がＬＧＮ１．１．２、もう１つはＬＧＮ１．１である。従ってＭＳ３は、Ｐｒｏｘｙ−ＰＡＲ照会をそのクライアント・ルータＭＲ３から受信したとき、図に示すようにＩＰ情報の２つのコピーをルータに提供する。（簡潔化のため、ＰＡＲ通知を含むＰＡＲ ＰＴＳＥの送信元ノードのＩＤは、図では括弧内のＬＧＮ番号により示してある。）一方スイッチＭＳ２はこのＩＰ情報で３つのＰＡＲ ＰＴＳＥを受信するので、ＩＰ情報の３つのコピーは、図に示すように、ＭＳ２によりそのクライアント・ルータＭＲ２に送信される。更にＭＳ１は、ＬＧＮ１．１．２とＬＧＮ１．１により生成された２つのＰＡＲ ＰＴＳＥを受信し、またそのメモリにそれが自体のレベル８８ピア・グループ用に生成したＰＡＲ ＰＴＳＥを格納する。従って、図に示すようにＭＳ１はここではＩＰ情報の３つのコピーをＭＲ１に戻す。この例では２つはその先祖ノードから受信されたコピー、１つは自体が生成したＰＴＳＥから受信されたコピーである。この例からわかるように、ＰＡＲ ＰＴＳＥが異なる階層レベルで再生成されると、各ルータが同じＩＰ情報の複製を受信する。この問題は、全ルータからのＰＡＲ通知を考慮すると明らかに大きくなる。この問題はまた、以下に述べる本発明の実施例の対象である。
【００３１】
図３は、この実施例の動作に伴うスイッチの主な要素を示す簡略図である。スイッチ１は制御ロジック２、メモリ３、及び回路４を含む。回路４は、デバイスがネットワークの他の部分及び関連するルータと通信するためのインターフェースとスイッチング回路を含む。この実施例のスイッチ１は、ＰＡＲ対応デバイスであり、関連するルータのＰｒｏｘｙ−ＰＡＲサーバとして機能する。制御ロジック２はスイッチの全体的動作を制御し、従って通常のＰＡＲ、Ｐｒｏｘｙ−ＰＡＲ機能、及びＰＴＳＥ生成・処理、コール・パス選択等の通常のＰＮＮＩ機能を実装する。また制御ロジック２は、ＩＰ情報管理機能を実行する（後述）。制御ロジック２はＰＮＮＩに従い、メモリ３にトポロジ・データベースを維持する。トポロジ・データベースは、ネットワーク・トポロジに関するスイッチのビューを定義したトポロジ・データを格納し、ＰＮＮＩ階層でのスイッチの先祖を識別する（後述）。メモリ３はＰＴＳＥリポジトリを格納し、リポジトリには制御ロジック２によりネットワークから受信されたＰＴＳＥが保存される。保存期間は、ＰＴＳＥが期限切れになるか、または通常のＰＮＮＩプロセスによりフラッシュされるまでである。一般に制御ロジック２は、ハードウェア、ソフトウェア、またはその組み合わせに実装することができるが、通常は、ソフトウェアを実行するプロセッサにより実装され、ソフトウェアは前記機能を実行するようプロセッサを構成する。適切なソフトウェアは、ここでの説明から当業者には明らかであろう。（もちろん、スイッチ・プロセッサはあらかじめ適切なソフトウェアで構成しておけるが、そのようなソフトウェアを構成するプログラム・コードは個別に提供することもできる。その場合プログラム・コードは、デバイスにロードされ、前記のように動作するようプロセッサが構成される。このようなプログラム・コードは、独立した要素として、または複数の制御機能用のプログラム・コードの要素として提供することも可能であり、ディスク等、コンピュータ可読媒体に組み込んで、或いはスイッチにロードするためネットワーク・オペレータに電子的に転送して提供することもできる。）
【００３２】
制御ロジック２により実装されるＩＰ情報管理プロセスは、この実施例では３つのフィルタ・メカニズムを含む。各フィルタは、メモリ３に保存されたＰＡＲＰＴＳＥのチェックを伴う。チェックにより冗長なＩＰ情報が識別され、Ｐｒｏｘｙ−ＰＡＲリクエストに応答して、クライアント・ルータに提供されたＩＰ情報から除外される。第１フィルタは、スイッチから見えるＰＮＮＩトポロジにＰＡＲ ＰＴＳＥの送信元ノードが存在するかチェックする。第２フィルタは、ネットワークでＰＡＲ ＰＴＳＥが関連するＩＰサービスのＡＴＭアドレスまでコール・パスが利用できるかチェックする。第３フィルタは、ＰＡＲ ＰＴＳＥの送信元ノードがＰＮＮＩ階層でスイッチの先祖かどうかチェックする。このように各フィルタが、メモリ３に保存されたトポロジ・データを利用する。トポロジ・データにより定義されるネットワーク・トポロジの簡単な例について、図４を参照して説明する。
【００３３】
前述のように、ＡＴＭネットワークでのＰＮＮＩトポロジ・データの通信は、各スイッチから自体のピア・グループの詳細、及びＰＮＮＩ階層の上位レベルで代表される任意のピア・グループの詳細が見えるように行われる。図４は、図１のシステムのスイッチＭＳ１から見た、衛星接続のスイッチＳ１からスイッチＳ２へのハンドオーバーの後のＰＮＮＩトポロジを示す。このトポロジ・ビューでは、ＭＳ１はレベル７２のＬＧＮ２．１．２にアップリンクｕ１を介して接続される。ＭＳ１とＳ２間の衛星接続のため、ＭＳ１はレベル６４のＬＧＮ２．０にもアップリンクｕ２を介して接続される。ＬＧＮ２．１．２は、水平リンクｈ１を介してレベル７２のＬＧＮ２．１．１に接続される。ＬＧＮ２．１．１はアップリンクｕ３を介してレベル６４のＬＧＮ２．０に、ＬＧＮ２．０は、水平リンクｈ２を介してレベル６４のＬＧＮ２．１にそれぞれ接続される。同様に、ＬＧＮ２．０はアップリンクｕ４を介してレベル３２のＬＧＮ１に、ＬＧＮ１は水平リンクｈ３を介してレベル３２のＬＧＮ２にそれぞれ接続される。ＰＮＮＩ階層のＭＳ１の先祖（つまり階層の上位層でＭＳ１を表す論理ノード）は図では陰影を付けて示してある。この場合のＭＳ１のトポロジ・データベースは、図のトポロジのリンク、ノードＩＤ、及びデバイス・アドレスを定義したデータを、階層の先祖ノードのＩＤ（及びＡＴＭアドレス）を示すノード階層一覧とともに格納する。
【００３４】
ネットワーク・システムでのスイッチ１の動作については、スイッチ１はネットワークからＰＡＲ ＰＴＳＥを受信し、ＰＡＲ ＰＴＳＥは制御ロジック２によりメモリ３のＰＴＳＥリポジトリに保存される。制御ロジック２は、クライアント・ルータにより定期的に発行されるＰｒｏｘｙ−ＰＡＲリクエストに応答して、メモリ３に保存されたＰＡＲ ＰＴＳＥからＩＰ情報を抽出し、このＩＰ情報を通常のＰＡＲサービス記述パケットでルータに提供する。このＩＰ情報通信プロセスの一部としてスイッチ制御ロジック２により実行される動作を図５に詳しく示す。図５のステップ１０に示すように、ルータからのＰｒｏｘｙ−ＰＡＲリクエストの受信後、制御ロジック２はメモリ３のＰＴＳＥリポジトリにアクセスし、ステップ１１で、ルータにより発行されるリクエストに従って第１のＰＡＲ ＰＴＳＥを選択する。ステップ１２で、制御ロジックはＰＡＲ ＰＴＳＥの送信元ノードＩＤを、前記のように、スイッチのネットワーク・ビューを定義したトポロジ・データのノードＩＤと比較する。（他の実施例では、制御ロジックはここで、ＰＡＲ ＰＴＳＥに指定された送信元ノードのＡＴＭアドレスをトポロジ・データベースに保存されたノードのＡＴＭアドレスと比較することもできる。）ステップ１３の”Ｎ”に示すように一致がなければ、送信元ノードは現在のトポロジのスイッチによってはアクセスできなくなっている。これは、例えばモバイル・ネットワークが移動し、新しいトポロジで送信元ノードとの接続が存在しなくなった場合に生じることがある。その場合、動作はステップ１４に進み、メモリ３にフラグが設定されて、ＰＡＲ ＰＴＳＥにカプセル化されたＩＰ情報は冗長であることが示される。ステップ１２、１３、１４は、このように前記の第１フィルタを構成する。ステップ１４から動作はステップ１９に進み、メモリ３にチェック対象のＰＡＲ ＰＴＳＥが残っているか制御ロジックによりチェックされる。残っている場合、ステップ２０で次のＰＴＳＥが選択され、動作はこのＰＴＳＥについてステップ１２に戻る。
【００３５】
ステップ１３で一致があったとすると、動作はステップ１５に進み、ＰＴＳＥのＩＰ情報により識別されたＩＰサービスのＡＴＭアドレスへのコール・パスが利用できるか制御ロジックにより確認される。従って、パス選択ロジックでＡＴＭアドレスへのパスを計算できない場合（エンドシステムの障害によりＩＰサービスが到達不能なため等）、またはアドレスへのコールを設定するネットワーク・リソースが不十分な場合（帯域幅、遅延等）、パスは利用できないことがステップ１６で確認される。その場合動作はステップ１４に進み、ＩＰ情報は冗長とのフラグが設定され、前のようにステップ１９に進む。ステップ１５、１６、１４はよって前記の第２フィルタを構成する。
【００３６】
ステップ１６でコール・パスが利用できるとすると、ステップ１７で制御ロジックが、前記のように、ＰＡＲ ＰＴＳＥの送信元ノードＩＤをメモリ３のノード階層一覧にあるノードＩＤと比較する。この実施例では、ノード階層一覧にスイッチ自体のノードＩＤ、及び上位レベルの先祖のＩＤが含まれると仮定している。ステップ１８の”Ｙ”に示されるように一致があった場合、スイッチ自体または階層の上位レベルの先祖によりＰＡＲ ＰＴＳＥが生成されている。その場合、動作はステップ１４に戻り、ＩＰ情報は冗長とのフラグが設定され、動作は前のように継続する。ステップ１７、１８、１４は従って前記の第３フィルタを構成する。（ノード階層一覧は関連ノードのＡＴＭアドレス及びこの例のノードＩＤを含むので、このフィルタは、階層一覧のノードのＡＴＭアドレスをＰＡＲ ＰＴＳＥに指定された送信元ノードのＡＴＭアドレスと比較することによっても等しく実装することができる。）
【００３７】
ステップ１８で一致がない場合、現在のＰＴＳＥのＩＰ情報は冗長とみなされず、動作はステップ１９に進み、ステップ２０に続く。ここで次のＰＡＲ ＰＴＳＥが前のように選択される。ステップ１９の”Ｎ”に示されるように、関連するＰＴＳＥが全てチェックされると、制御ロジックはステップ２１に進む。ここで、Ｐｒｏｘｙ−ＰＡＲリクエストに対応した、冗長ではないＩＰ情報がメモリから全て取得され、クライアント・ルータに提供される。プロセスはここで完了する。
【００３８】
図６は、図２に似たモバイル・ネットワーク・システムで、各スイッチＭＳ１、ＭＳ２、ＭＳ３は前記実施例に従ったスイッチ１である。このシナリオでは、図１のシナリオのように、アクセス・ポイント・スイッチＳ２（関連ルータＲ２）からの衛星接続のハンドオーバーの後、スイッチＭＳ３に、固定ネットワークのアクセス・ポイント・スイッチＳ１（関連ルータＲ１）への衛星接続があると仮定している。ＰＡＲ通知は便宜上簡略化している。特に図は、モバイル・ネットワークのモバイル・ルータＭＲ１からのＰＡＲ通知通信とともに、固定ネットワークからＭＲ３へのＰＡＲ通知の通信のみ示している。スイッチＭＳ１乃至ＭＳ３により冗長と識別され、従ってモバイル・ルータに送信されたＩＰ情報から除外されたＰＡＲ通知は、図に打ち消しの斜線で示している。ここからわかるように、スイッチＭＳ３はそのクライアント・ルータＭＲ３に、固定ネットワーク・ルータＲ１のＰＡＲ通知とＬＧＮ１．１．２から受信されたＭＲ１のＰＡＲ通知のみ送信する。アクセス・ポイント・スイッチＳ２（図１のＬＧＮ２．０）を表すＬＧＮは、スイッチＭＳ３から見たＰＮＮＩトポロジでは見えなくなり、従ってルータＲ２の”古い”ＰＡＲ通知は、前記の第１フィルタの動作を通してＭＲ３に送信されたＩＰ情報から除外される。ＭＳ３の先祖ノードＬＧＮ１．１から発生した複製ＰＡＲ通知は、前記の第３フィルタによりなくなる。更に、Ｒ１へのコール・パスが例えばＲ１の障害によりＭＳ３により利用できないことがわかった場合、Ｒ１のＰＡＲ通知は、前記の第２フィルタにより冗長と識別され、ＭＳ３によりＭＲ３に提供されない。
【００３９】
ＭＳ２で、スイッチＭＳ１から受信されたＭＲ１のＰＡＲ通知のみクライアント・ルータＭＲ２に提供され、ＭＳ２の先祖ＬＧＮ１．１、ＬＧＮ１．１．２から受信された複製ＰＡＲ通知は第３フィルタ・メカニズムにより除外される。ＭＳ１の場合、この実施例のノード階層一覧はＭＳ１自体のノードＩＤを含むため、ＭＲ１の全てのＰＡＲ通知が、前記のようにＭＳ１自体により生成されたＰＴＳＥのＰＡＲ通知を含め、この第３フィルタにより除外される。
【００４０】
この実施例でルータにより受信されたＩＰ情報の実質的な簡略化は、図６から明らかである。ただし、この利点は、図６に示す選択されたＰＡＲ通知だけではなく、ＰＡＲ通知が全て考慮されるとき劇的に大きくなることは理解されよう。従って、冗長な情報をなくすことによって、ＰＡＲ対応デバイスにより、関連ルータに提供されるＩＰ情報が大幅に簡略化され、ルータでのデータ処理も容易になり、ＩＰトポロジの最適構成が促進されることは明らかである。
【００４１】
本発明の、特に好適実施例について説明しているが、本発明の範囲から逸脱することなく、多くの変更、変形が可能なことは理解されよう。例えば、前記実施例では３つのフィルタ・メカニズムを採用しているが、これらフィルタ・メカニズムの１つまたは任意の組み合わせもまた、必要に応じて他の実施例に採用することができる。更に、フィルタリングは、前記の実施例ではＰｒｏｘｙ−ＰＡＲリクエストに応答して実行されるが、実施例によっては、例えばネットワークからＰＡＲ ＰＴＳＥを受信したとき、あらかじめフィルタ・メカニズムを１つ以上適用することもできる。また、前記実施例のスイッチとルータは、Ｐｒｏｘｙ−ＰＡＲを介して通信する個別デバイスであるが、ルータをＰＡＲ対応デバイスと統合した実施例も考えられる。その場合、ルータ・ロジックは、他の何らかの内部通信プロトコルを介してＰＡＲロジックと通信することができる。
【００４２】
他の実施例では、冗長なＩＰ情報を除外するのではなく、前記のように、スイッチによりＩＰ情報にタグを付け、関連ルータが冗長な情報と冗長ではない情報を区別できるようにすることもできる。また、本発明の例は、モバイル・ネットワークのシナリオをもとに説明しているが、本発明の実施例はまた、固定ネットワーク・システムにも都合よく適用することができ、ＩＰトポロジの自動構成が促進されることは理解されよう。更に前述のように、本発明の実施例は、ＩＰ以外のプロトコル、及びＩＰルータ以外のプロトコル・デバイスにも適用することができる。
【図面の簡単な説明】
【図１】本発明の実施例で扱う問題を示すモバイル・ネットワーク・システムの図である。
【図２】本発明の実施例で扱う問題を示す他のモバイル・ネットワーク・システムの図である。
【図３】本発明を具体化したスイッチを示す図である。
【図４】図１のシステムの１つのスイッチから見たＰＮＮＩトポロジを示す図である。
【図５】図３のスイッチにより実装されたＩＰ情報管理方法を示すフローチャートである。
【図６】実施例の動作を示すモバイル・ネットワーク・システムの図である。
【符号の説明】
１ スイッチ
２ 制御ロジック
３ メモリ
４ インターフェースとスイッチング回路
Claims (23)
- 専用ネットワーク間インターフェース（ＰＮＮＩ）階層ネットワークのＰＮＮＩオーグメント・ルーティング（PNNI Augmented Routing；ＰＡＲ）対応デバイスでプロトコル情報を管理する方法であって、
前記ネットワークから前記ＰＡＲ対応デバイスにより受信されたＰＡＲ ＰＮＮＩトポロジ状態要素（ＰＴＳＥ）をチェックし、前記ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別するステップと、
受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するステップと、を含み、冗長と識別されたプロトコル情報は該プロトコル・デバイスに提供されたプロトコル情報から除外される、
方法。 - ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイスでプロトコル情報を管理する方法であって、
前記ネットワークから前記ＰＡＲ対応デバイスにより受信されたＰＡＲ ＰＴＳＥをチェックし、前記ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別するステップと、
受信されたＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を、前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するステップと、を含み、
更に、前記プロトコル・デバイスに提供された前記プロトコル情報にタグをつけて冗長なプロトコル情報と冗長ではないプロトコル情報を区別するステップを含む、
方法。 - 受信されたＰＡＲ ＰＴＳＥの前記チェックは、該ＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが前記ＰＡＲ対応デバイスから見たＰＮＮＩトポロジに存在するか確認するステップを含み、該ネットワーク・ノードが該トポロジに存在しない場合は、該ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は冗長と識別される、請求項１または請求項２に記載の方法。
- 前記ＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが前記トポロジに存在するかを、前記ＰＡＲ ＰＴＳＥの前記ネットワーク・ノードを識別するノードＩＤを前記トポロジ内のネットワーク・ノードを識別する前記ＰＡＲ対応デバイスに保存されたトポロジ・データのノードＩＤと比較することによって確認するステップを含む、請求項３記載の方法。
- 受信されたＰＡＲ ＰＴＳＥの前記チェックは、前記ネットワーク上に該ＰＡＲ ＰＴＳＥにカプセル化された前記プロトコル情報のＡＴＭアドレスへのコール・パスが前記ＰＡＲ対応デバイスから利用できるか確認するステップを含み、該コール・パスが利用できない場合は前記プロトコル情報は冗長と識別される、請求項１乃至請求項４のいずれかに記載の方法。
- 受信されたＰＡＲ ＰＴＳＥの前記チェックは、該ＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが前記ＰＮＮＩ階層の前記ＰＡＲ対応デバイスの先祖であるか確認するステップを含み、該ネットワーク・ノードが前記ＰＡＲ対応デバイスの先祖である場合は該ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報は冗長と識別される、請求項１乃至請求項５のいずれかに記載の方法。
- 前記ＰＡＲ ＰＴＳＥの送信元である前記ネットワーク・ノードが前記ＰＡＲ対応デバイスの先祖であるか、前記ＰＡＲ ＰＴＳＥの前記ネットワーク・ノードを識別するノードＩＤを、前記ＰＮＮＩ階層の前記ＰＡＲ対応デバイスの先祖を識別する前記ＰＡＲ対応デバイスに保存されたトポロジ・データのノードＩＤと比較することによって確認するステップを含む、請求項６記載の方法。
- 前記プロトコル・デバイスからのリクエストに応答して前記プロトコル情報を前記プロトコル・デバイスに提供するステップを含む、請求項１乃至請求項７のいずれかに記載の方法。
- 前記プロトコル・デバイスからのリクエストに応答して、前記チェックを実行するステップと、前記プロトコル情報を前記プロトコル・デバイスに提供するステップを含む、請求項１乃至請求項８のいずれかに記載の方法。
- 前記ＰＡＲ対応デバイスはＰｒｏｘｙ−ＰＡＲサーバとして構成され、前記プロトコル・デバイスはＰｒｏｘｙ−ＰＡＲクライアントとして構成された、請求項１乃至請求項９のいずれかに記載の方法。
- 前記プロトコル情報はＩＰ情報を含む、請求項１乃至請求項１０のいずれかに記載の方法。
- 前記プロトコル・デバイスはルータを含む、請求項１乃至請求項１１のいずれかに記載の方法。
- ＰＮＮＩ階層ネットワークに接続するＰＡＲ対応デバイスであって、
前記ネットワークから前記ＰＡＲ対応デバイスにより受信されたＰＡＲ ＰＴＳＥを保存するメモリと、
受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別し、冗長と識別されたプロトコル情報は除外し、受信されたＰＡＲ ＰＴＳＥのプロトコル情報を前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するよう構成された制御ロジックと、
を含む、ＰＡＲ対応デバイス。 - ＰＮＮＩ階層ネットワークに接続するＰＡＲ対応デバイスであって、
前記ネットワークから前記ＰＡＲ対応デバイスにより受信されたＰＡＲ ＰＴＳＥを保存するメモリと、
受信されたＰＡＲ ＰＴＳＥをチェックして該ＰＡＲ ＰＴＳＥにカプセル化された冗長なプロトコル情報を識別し、受信されたＰＡＲ ＰＴＳＥのプロトコル情報を前記ＰＡＲ対応デバイスに関連付けられたプロトコル・デバイスに提供するよう構成された制御ロジックと、を含み、
前記制御ロジックは更に、前記プロトコル・デバイスに提供されるプロトコル情報にタグを付けて冗長なプロトコル情報と冗長ではないプロトコル情報を区別するよう構成された、
ＰＡＲ対応デバイス。 - 前記制御ロジックは、前記ＰＡＲ対応デバイスから見たＰＮＮＩトポロジを定義したデータを含むトポロジ・データを前記メモリに維持し、受信されたＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが該トポロジに存在するか確認することによって、該受信されたＰＡＲ ＰＴＳＥをチェックするよう構成され、該ネットワーク・ノードが該トポロジに存在しない場合は、該ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を冗長と識別する、請求項１３または請求項１４に記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記ＰＡＲ ＰＴＳＥの前記ネットワーク・ノードを識別するノードＩＤを、前記トポロジ内のネットワーク・ノードを識別する前記トポロジ・データのノードＩＤと比較することによって、前記ＰＡＲ ＰＴＳＥの送信元である前記ネットワーク・ノードが前記トポロジに存在するか確認するよう構成された、請求項１５記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記ネットワーク上で、受信されたＰＡＲ ＰＴＳＥにカプセル化された前記プロトコル情報のＡＴＭアドレスへのコール・パスが前記ＰＡＲ対応デバイスから利用できるか確認することによって、該ＰＡＲ ＰＴＳＥをチェックするよう構成され、該コール・パスが利用できない場合は前記プロトコル情報を冗長と識別する、請求項１３乃至請求項１６のいずれかに記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記ＰＮＮＩ階層のＰＡＲ対応デバイスの先祖を識別するデータを含むトポロジ・データを前記メモリに維持し、受信されたＰＡＲ ＰＴＳＥをチェックするために、該ＰＡＲ ＰＴＳＥの送信元であるネットワーク・ノードが前記階層のＰＡＲ対応デバイスの先祖であるか確認するよう構成され、該ネットワーク・ノードが前記ＰＡＲ対応デバイスの先祖である場合は、該ＰＡＲ ＰＴＳＥにカプセル化されたプロトコル情報を冗長と識別する、請求項１３乃至請求項１７のいずれかに記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記ＰＡＲ ＰＴＳＥの送信元である前記ネットワーク・ノードが前記ＰＡＲ対応デバイスの先祖であるか確認するため、前記ＰＡＲ ＰＴＳＥ内の前記ネットワーク・ノードを識別するノードＩＤを、前記ＰＡＲ対応デバイスの先祖を識別する前記トポロジ・データのノードＩＤと比較する、請求項１８記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記プロトコル・デバイスからのリクエストに応答して前記プロトコル情報を前記プロトコル・デバイスに提供するよう構成された、請求項１３乃至請求項１９のいずれかに記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記プロトコル・デバイスからのリクエストに応答して、前記ＰＡＲ ＰＴＳＥをチェックし、前記プロトコル情報を前記プロトコル・デバイスに提供するよう構成された、請求項１３乃至請求項２０のいずれかに記載のＰＡＲ対応デバイス。
- 前記制御ロジックは、前記プロトコル・デバイスからのＰｒｏｘｙ−ＰＡＲリクエストに応答して前記プロトコル情報を前記プロトコル・デバイスに提供するＰｒｏｘｙ−ＰＡＲサーバ・ロジックを含む、請求項２０または請求項２１のいずれかに記載のＰＡＲ対応デバイス。
- 複数のＰＡＲ対応デバイス及び複数のプロトコル・デバイスを含むＰＮＮＩ階層ネットワークであって、ＰＡＲ対応デバイスはそれぞれ、該プロトコル・デバイスにより生成されたプロトコル情報のネットワークで通信するため該プロトコル・デバイスに関連付けられ、該ＰＡＲ対応デバイスは請求項１３乃至請求項２２のいずれかに記載の少なくとも１つのＰＡＲ対応デバイスを含む、ネットワーク。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP00112293 | 2000-06-08 | ||
| EP00112293.6 | 2000-06-08 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002051083A JP2002051083A (ja) | 2002-02-15 |
| JP3557405B2 true JP3557405B2 (ja) | 2004-08-25 |
Family
ID=8168942
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001173974A Expired - Fee Related JP3557405B2 (ja) | 2000-06-08 | 2001-06-08 | 専用ネットワーク間インターフェース階層ネットワークのプロトコル情報管理 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6944674B2 (ja) |
| JP (1) | JP3557405B2 (ja) |
| DE (1) | DE60131047T2 (ja) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7320025B1 (en) | 2002-03-18 | 2008-01-15 | Music Choice | Systems and methods for providing a broadcast entertainment service and an on-demand entertainment service |
| US6879963B1 (en) * | 2000-04-12 | 2005-04-12 | Music Choice | Cross channel delivery system and method |
| US20020042754A1 (en) | 2000-10-10 | 2002-04-11 | Del Beccaro David J. | System and method for receiving broadcast audio/video works and for enabling a consumer to purchase the received audio/video works |
| JP3633503B2 (ja) * | 2001-04-20 | 2005-03-30 | 日本電気株式会社 | 階層化された移動ネットワークの位置管理システムおよびその方法 |
| US7480239B1 (en) * | 2001-11-27 | 2009-01-20 | Cisco Technology, Inc. | Method and apparatus for true priority based connection establishment within a PNNI ATM network |
| DE10162986B4 (de) * | 2001-12-20 | 2004-01-15 | Siemens Ag | Anbindung von Netzwerken mit unterschiedlichen Protokollen |
| US7747747B1 (en) * | 2002-05-06 | 2010-06-29 | Apple Inc. | Method and arrangement for supressing duplicate network resources |
| JP3831696B2 (ja) * | 2002-09-20 | 2006-10-11 | 株式会社日立製作所 | ネットワーク管理装置およびネットワーク管理方法 |
| US20040073659A1 (en) * | 2002-10-15 | 2004-04-15 | Carl Rajsic | Method and apparatus for managing nodes in a network |
| US7733860B2 (en) * | 2002-11-01 | 2010-06-08 | Alcatel-Lucent Canada Inc. | Method for advertising reachable address information in a network |
| US7512703B2 (en) * | 2003-01-31 | 2009-03-31 | Hewlett-Packard Development Company, L.P. | Method of storing data concerning a computer network |
| US7334033B2 (en) * | 2003-01-31 | 2008-02-19 | Brocade Communications Systems, Inc. | Fabric membership monitoring |
| JP4103816B2 (ja) * | 2003-02-12 | 2008-06-18 | 松下電器産業株式会社 | ルータ設定方法及びルータ装置 |
| US7733869B2 (en) * | 2003-12-10 | 2010-06-08 | Alcatel-Lucent | Providing VPLS-like service over native ATM networks |
| US7924726B2 (en) * | 2004-07-12 | 2011-04-12 | Cisco Technology, Inc. | Arrangement for preventing count-to-infinity in flooding distance vector routing protocols |
| US7529845B2 (en) * | 2004-09-15 | 2009-05-05 | Nokia Corporation | Compressing, filtering, and transmitting of protocol messages via a protocol-aware intermediary node |
| GB2422981A (en) * | 2005-02-03 | 2006-08-09 | Marconi Comm Gmbh | PNNI protocol in ATM networks |
| US7668538B2 (en) * | 2005-06-15 | 2010-02-23 | Music Choice | Systems and methods for facilitating the acquisition of content |
| US7542432B2 (en) * | 2005-10-27 | 2009-06-02 | Alcatel Lucent | Resource matched topology database synchronization in communications networks having topology state routing protocols |
| US20070206512A1 (en) * | 2006-03-03 | 2007-09-06 | Nortel Networks Limited | Network data model and topology discovery method |
| US9197937B1 (en) | 2012-04-26 | 2015-11-24 | Music Choice | Automatic on-demand navigation based on meta-data broadcast with media content |
| US10219027B1 (en) | 2014-10-24 | 2019-02-26 | Music Choice | System for providing music content to a user |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6208623B1 (en) * | 1998-04-13 | 2001-03-27 | 3Com Corporation | Method of combining PNNI and E-IISP in an asynchronous transfer mode network |
| US6600724B1 (en) * | 1998-04-28 | 2003-07-29 | Cisco Technology, Inc. | Routing table structures |
| US6262984B1 (en) * | 1998-05-12 | 2001-07-17 | 3Com Corporation | Method of preventing overlapping branches in point to multipoint calls in PNNI networks |
| US6741585B1 (en) * | 2000-05-05 | 2004-05-25 | Lucent Technologies Inc. | Interworking of addressing in an internetwork |
-
2001
- 2001-04-17 DE DE60131047T patent/DE60131047T2/de not_active Expired - Lifetime
- 2001-06-08 JP JP2001173974A patent/JP3557405B2/ja not_active Expired - Fee Related
- 2001-06-08 US US09/877,483 patent/US6944674B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE60131047D1 (de) | 2007-12-06 |
| US20020023163A1 (en) | 2002-02-21 |
| JP2002051083A (ja) | 2002-02-15 |
| DE60131047T2 (de) | 2008-07-31 |
| US6944674B2 (en) | 2005-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3557405B2 (ja) | 専用ネットワーク間インターフェース階層ネットワークのプロトコル情報管理 | |
| TWI839379B (zh) | 在網路路由環境中的單節點和多節點資料儲存空間架構 | |
| JP7432744B2 (ja) | 複数のサービス通信プロキシを有する電気通信ネットワークにおけるルーティング通信 | |
| US7177951B1 (en) | Address management in PNNI hierarchical networks | |
| US6757258B1 (en) | Method and apparatus for reducing OSPF flooding | |
| US7155534B1 (en) | Arrangement for aggregating multiple router configurations into a single router configuration | |
| JP4759135B2 (ja) | デジタル通信ネットワークのための分散スイッチと接続制御構成および方法 | |
| US7120119B2 (en) | Management of protocol information in PNNI hierarchical networks | |
| US7907544B2 (en) | Overlay network for location-independent communication between computer systems | |
| US7843837B2 (en) | Management of protocol information in PNNI hierarchical networks | |
| US8572284B2 (en) | Method and apparatus for registering a mobile object on a foreign network | |
| CN103825826A (zh) | 一种动态路由的实现方法和装置 | |
| Steenstrup | An architecture for inter-domain policy routing | |
| US20020089990A1 (en) | Routing system providing continuity of service for the interfaces associated with neighboring networks | |
| US7529821B1 (en) | Network element management | |
| EP1162863B1 (en) | Management of protocol information in PNNI hierarchical networks | |
| Steenstrup | IDPR: An approach to policy routing in large diverse internetworks | |
| Verma et al. | NPF HA architecture model and framework Implementation Agreement | |
| KR19990016748A (ko) | 교환 시스템의 자동 주소 설정 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040203 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040402 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040511 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040517 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080521 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080521 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090521 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100521 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110521 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110521 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |