JP4476292B2

JP4476292B2 - リアルタイムサービスデータ伝送路の選択方法

Info

Publication number: JP4476292B2
Application number: JP2006525027A
Authority: JP
Inventors: チェン，ユエペン; ファン，リンユアン; ウ，デンチャオ; スゥ，ボ; スイ，シャオシュアイ; フアン，ジャンツォン; チン，ウ
Original assignee: ファーウェイチーシュヨウシェンゴンス
Priority date: 2003-09-02
Filing date: 2004-09-02
Publication date: 2010-06-09
Anticipated expiration: 2024-09-02
Also published as: EP1659729A4; EP1659729B1; DE602004027390D1; JP2007504725A; US7818450B2; WO2005022824A1; US20080130627A1; ATE469478T1; AU2004302573A1; AU2004302573B2; EP1659729A1

Description

技術分野
本発明は、ルーティング選択技術、より詳しくは、ＩＰネットワークにおけるリアルタイムサービスデータ伝送路を選択し決定する方法に関する。

発明の背景
インターネットの発展に伴い、種々のネットワークサービスおよび高度なマルチメディアシステムが提案されている。リアルタイムサービスは、ネットワーク伝送遅延、遅延ジッタなどのファンクションに敏感であるため、高いバースト性を有するファイル転送プロトコル（ＦＴＰ）またはイメージファイルなどのハイパーテキストトランスファープロトコル（ＨＴＴＰ）のようなサービスがある場合、リアルタイムサービスは、大きな影響を与えるであろう。また、マルチメディアサービスは、広い範囲の帯域幅を占めるため、保証されるべき重要なサービスは、従前のネットワークでは、確実に伝送されることができない。したがって、重要なサービスについての信頼性のある伝送を保証するため、種々のクオリティーオブサービス（ＱｏＳ）技術が提案されている。インターネットエンジニアリングタスクフォース（ＩＥＴＦ）は、ＱｏＳ要求に対する多くのサービスモデルおよびメカニズムを提案している。現在のところ、当該技術分野でかなり認識された技術は、ネットワークのアクセスエリアまたは境界エリア付近において、統合サービス（Ｉｎｔ−Ｓｅｒｖ）モデルを導入し、ネットワークのコアエリアにおいて、クラス別サービス（Ｄｉｆｆ−Ｓｅｒｖ）モデルを導入する。

Ｄｉｆｆ−Ｓｅｒｖモデルは、優先順位を設定することだけで、ＱｏＳを保証し、ライン利用率が高いとしても、実際の影響を予測不可能にさせる。したがって、独立したベアラ制御階層は、基幹ネットワークのＤｉｆ−Ｓｅｒｖモデルに導入され、専用のＤｉｆｆ−ＳｅｒｖｅＱｏＳシグナリングメカニズムが構築され、ネットワークのトポロジリソースを管理するための専用のリソース管理階層がＤｉｆｆ−Ｓｅｒｖネットワークに対して構築される。かかるリソースマネージングＤｉｆｆ−Ｓｅｒｖモードは、独立したベアラ制御階層を有するＤｉｆｆ−Ｓｅｒｖモデルとみなされる。図１は、独立したベアラ制御階層を有するＤｉｆｆ−Ｓｅｒｖモデルのようなモデルを示す。図１に示されるように、ベアラ制御階層１０２は、本モデルのベアラネットワーク１０３とサービス制御階層１０１との間に設置される。サービス制御階層１０１におけるコールエージェント（ＣＡ）は、ソフト交換機能を実行できるソフト交換などのサービスサーバーである。ベアラ制御階層１０２は、管理ルールおよびネットワークトポロジを設定すること、クライアントサービス帯域幅要求のリソースアロケーションを割り当てること、全てのベアラネットワークリソースマネージャーを制御し管理して、クライアントサービス帯域幅アプリケーション要求および結果ならびにシグナリング、例えば、ベアラネットワークリソースマネージャー１、２および３の間のコミュニケーションの制御および管理のために、中間にサービスアプリケーションを割り当てられたルートパス情報を転送することを管理している、１または２以上のベアラネットワークリソースマネージャーを含む。ベアラネットワーク１０３において、各ベアラネットワークリソースマネージャーは、対応するベアラネットワークリソースマネージャーの管理ドメインと呼ばれる所定のベアラネットワークエリアを管理する。例えば、ベアラネットワークリソースマネージャー１は、管理ドメイン１０５を管理し、ベアラネットワークリソースマネージャー２は、管理ドメイン１０６を管理し、ベアラネットワークリソースマネージャー３は、管理ドメイン１０７を管理する。ベアラネットワーク１０３は、エッジルーター（ＥＲ）、ボーダールーター（ＢＲ）およびコアルーター１０４を含み、ＥＲ、ＢＲおよびコアルーターは、全て、ベアラネットワークに属し、一般的に、接続ノード（ＣＮｓ）と呼ばれる。

ベアラ制御階層は、ユーザーサービス帯域幅アプリケーションを処理する場合、ユーザーサービスのパスを決定し、ベアラネットワークリソースマネージャーは、ＥＲに特定のパスにしたがってサービスストリームを転送するを知らせるであろう。ベアラネットワークリソースマネージャーにおけるルートは、２つのタイプ：シグナリングルートおよびサービスルートを含む。シグナリングルートは、どのように各ベアラネットワークリソースマネージャーがベアラネットワークリソースマネージャーのネクストホップを見つけるかの手順を意味する。サービスルートは、どのようにベアラネットワークリソースマネージャーがサービスストリーム情報にしたがって適切なベアララベル交換パス（ＬＳＰ）を見つけるかの手順を意味する。サービスルートは、ドメイン内ルートとドメイン間ルートとを含む。

一般的に言えば、ベアラネットワークは、ベアラ制御階層により決定されたパスに従った特定のルートを有するユーザーサービスストリームを転送する。現在、ＬＳＰは、マルチプロトコルラベル交換（ＭＰＬＳ）技術を用いることにより、リソース予約様式を手段として、ベアラ制御階層により特定されたサービスストリームパスに沿って構築されるか、あるいは、エンド・ツー・エンドＬＳＰは、トラフィックエンジニアリングエクステンション付リソース予約セットアッププロトコル（ＲＳＶＰ−ＴＥ）または制約ルートラベル分配プロトコル（ＣＲ−ＬＤＰ）に基づく明示ルートを用いることにより構築される。

現在、以下のように、ルートパス構築およびベアラネットワークリソースマネージャーのリソースアロケーションのいくつかのスキームがある：

１つのスキームは、要求のもとにルートパスを構築する技術、すなわち、発呼側パーティが呼び出しを開始した場合、ベアラネットワークリソースマネージャーは、カレントネットワークトポロジおよび管理ルールにより、ベアラネットワークのルーターからリアルタイムにＬＳＰ情報を取得し、ＬＳＰ情報からの通話中呼に適したＬＳＰを選択し、通話中呼が終わった後、このＬＳＰを解除する。本スキームにおいて、ベアラネットワークリソースマネージャーは、ベアラネットワークから直接的にＬＳＰ情報を取得し、各呼び出しについて対応するＬＳＰを再取得し、再選択することを要求するため、ＬＳＰ情報は、繰り返し用いられ得ず、高いルーティング負荷と低い効率のベアラネットワークリソースマネージャーをもたらす。

他のスキームは、クオリティオブサービスバックボーン（ＱＢｏｎｅ）実験的ネットワークの帯域ブローカーモデルを用いる。そのネットワーク構造モデルを図２に示す。本モデルにおいて、対応する帯域ブローカーは、帯域ブローカー１、２、３などの各Ｄｉｆｆ−Ｓｅｒｖ管理ドメインに設定される。帯域ブローカーは、ユーザーホスト、サービスサーバーまたはネットワーク保守管理者からの帯域アプリケーション要求を処理すること、および現行ネットワークのリソース予約状態、設定されたストラテジーおよびユーザーにサインされたサービス品質保証の同意（ＳＬＡ）にしたがってユーザー帯域アプリケーションに権限を与えるかどうかを決定することを管理している。この帯域ブローカーは、ＳＬＡ設定状況情報、物理ネットワークのトポロジ情報、ルーターの設定状況情報およびストラテジー情報、ユーザー権限情報、現行リソース予約、情報、ネットワーク占有状態情報などの種々の静的または動的な情報を記録し、ユーザーサービスストリームパスおよびクロスドメイン下流帯域ブローカーのロケーションを承認するようにルート情報をも記録する。

図２の帯域ブローカーの内部構造が図３に示され、他のベアラ制御階層の帯域ブローカーとコミュニケーションするドメイン間インターフェース、サービスサーバーとモミュニケーションするユーザーサービスインターフェース、ホスト／ユーザーおよびネットワーク維持デバイス、ストラテジー制御に用いられるストラテジーインターフェース、ネットワークマネージメントインターフェース、ベアラネットワークリソースマネージャーのドメイン内ルート情報を記録するルート情報記憶デバイス、データベース、ドメイン内インターフェースおよび単純ストラテジーサービスモジュールを含む。帯域ブローカー内部のモジュールは、互いに連携する。この帯域ブローカーは、ＳＬＡ設定状況情報、物理ネットワークのトポロジ情報、ルーターの設定情報およびストラテジー情報、ユーザー認証情報、現行リソース予約情報、ネットワーク占有状況情報などの種々の静的または動的情報を記録し、クロスドメインダウンストリーム帯域ブローカーのユーザーサービスストリームパスおよびロケーションを確認するようにルート情報も記録する。

図２に示されるネットワーク構造モデルにおいて、ベアラネットワークのルーターは、帯域ブローカーにリアルタイムにルートパスリソース情報を報告する。帯域ブローカーは、報告されたルートパスリソース情報からクライアントの呼び出しサービスに適したルートパス情報を取得し、クライアントの呼び出しサービスのルートパスを選択し、ルートパスの帯域リソースを予約する。この技術スキームは、以下のような欠点、帯域ブローカーが、エリアの全てのルーターのリソースおよび設定情報を直接的に管理するため、トポロジおよび管理は、大変複雑である点；帯域ブローカーが不安定なネットワーク予約を導くであろうローカルエリアの動的ルート情報を記録する必要があるため、ルーティングテーブルがしばしばアップデートされる必要がある点；ローカルエリアの動的ルート情報にしたがって帯域ブローカーにより決定されたサービスルートが、サービスストリームの現実の転送ルートと同じであることが困難である点、がある。

代替スキームは、ＮＥＣ社より提案されたＲｉｃｈＱｏＳスキームである。そのネットワーク構造モデルは、図４に示され、主要要素としてのＱｏＳサーバー４０１、ストラテジーサーバー４０２、カタログサーバー４０３、ネットワークマネージメントモニターサーバー４０４などを含み、それらは、ＱｏＳサーバーにより補助する。ここで、ＱｏＳサーバーは、ベアラネットワークのトポロジおよびリソース状況にしたがってＱｏＳサービス要求に対して所望のベアラパスを割り当てることを管理している。ＱｏＳサーバー４０１と管理インターフェースなどのストラテジー設定情報とにより、ストラテジーサーバー４０２は、関連するルーターのパラメータおよび設定を設定する。カタログサーバー４０３は、ネットワークデバイス設定情報、ユーザー情報およびＱｏＳ情報を保存するのに用いられた統合された集約データベースである。ネットワークマネージメントモニターサーバー４０４は、サービスアプリケーションのルートを選択する場合のＱｏＳサーバーの参照として、ルーターの設定状況、ベアラネットワークにおけるリンクなどの情報を集めることを管理している。

このスキームにおいて、ＬＳＰ情報は、ＱｏＳサーバーに設定される。ＱｏＳサーバーは、ＬＳＰ情報からクライアントの呼び出しサービスに適したＬＳＰ情報を取得し、クライアントの呼び出しサービスに対するＬＳＰを選択し、ＬＳＰにおける帯域リソースを予約する。サービスサーバーがＱｏＳサーバーに帯域要求を送った後、ＱｏＳサーバーは、この呼び出しに対する接続リソース要求を記録し、ＱｏＳ要求ならびにベアラネットワークの現行トポロジおよび現行リソース状況にしたがって、サービス要求に対する十分なベアラパスを割り当て、ついで、割り当て結果をサービスサーバーに返す。ＱｏＳサーバーに設定されたＬＳＰ情報は、優先順位に基づく種々のレベルに分けられ、ＱｏＳサーバーは、高い優先順位のサービス要求に対する高い優先順位のＬＳＰ情報および低い優先順位のサービス要求に対する低い優先順位のＬＳＰ情報を選択する。しかしながら、大量の低い優先順位のサービス要求および少量の高い優先順位のサービス要求があるならば、低い優先順位のサービスの際のネットワーク輻輳および高い優先順位のサービスの際の帯域空きを導き、それゆえに、このスキームは、融通が利かず、ルーティングの効率が低い。

さらに、このＲｉｃｈＱｏＳスキームは、多数のルーターを有するかなり複雑なベアラネットワークに関する。その一方で、ＱｏＳサーバーおよびストラテジーサーバーは、明示的ルートＭＰＬＳＬＳＰ構築技術およびエンド・ツー・エンドＬＳＰの構築方法を用いることにより、エッジルーターに通知し、拡張性が乏しく制限されたネットワークスケールをもたらす。したがって、このスキームは、パブリックネットワークにおけるエンド・ツー・エンドサービス要求に適用可能ではない。

上記がリソースを構築し割り当てるためのいくつかのスキームである。多重ルートパスにサービスルートパスおよびシグナリングルートパスをどのように含むかおよび適切なルートをどのように選択するかに関して、多数のアルゴリズムが導入されうる。サービスルートパスおよびシグナリングルートパスの選択は、同じ又は異なるアルゴリズムを採用しうる。しかしながら、各ドメインが一定のベアラネットワークリソースマネージャーにより個々に管理されるので、ベアラネットワークリソースマネージャーは、他のベアラネットワークリソースマネージャーにより管理された他のドメインにおけるＬＳＰリソース状況を知ることができず、ルート利用可能性の不特定因子をもたらし、そのため、ネットワークのサービス効率に影響を与えるであろう。

例えば、フォワードルーティング様式がソースベアラネットワークリソースマネージャーと宛先ベアラネットワークリソースマネージャーとの間に導入される場合、図５に示されるネットワーク構造に関して、ドメイン内ルートおよびドメイン間ルートは、順に、ソースＥＲから宛先ＥＲホップまでホップにより選択されるが、このルート選択様式は、ルート選択失敗を導く傾向がある。これは、サービスストリームがＥＲ２からＥＲ３まで転送されるべきであれば、ベアラネットワークリソースマネージャー１および２間の全４つのドメイン間ＬＳＰ、すなわち、ＬＳＰ１１、ＬＳＰ１２、ＬＳＰ１３およびＬＳＰ１４が全て選択可能であるためである；しかしながら、ベアラネットワークリソースマネージャー２内部のＢＲ３とＥＲ３との間のＬＳＰリソースがＢＲ４とＥＲ３との間のリソースが空き状態まで用いられる場合、ベアラネットワークリソースマネージャー２により管理されたドメイン内部のＬＳＰリソース占有状況が不明であるため、ベアラネットワークリソースマネージャー１は、いまだ、ルートロードシェアリングアルゴリズムにより、ドメイン間ＬＳＰを選択するであろう。ＬＳＰ１１またはＬＳＰ１３が選択される場合、ベアラネットワークリソースマネージャー１からベアラネットワークリソースマネージャー２までのルート選択は、失敗し、そのため、全ルーティングの失敗をもたらすであろう。したがって、前記ケースにおいては、フォワードルート選択様式を導入することのみでは、妥当なリソース割り当てを得ることができず、主な理由は、１つのベアラネットワークリソースマネージャーが、他のベアラネットワークリソースマネージャーにより管理されたこれらのドメインにおけるＬＳＰリソース使用状態を知らないことである。さらに、所定のベアラネットワークリソースマネージャーに管理されたドメインにおいて、ある特定のパフォーマンス要求およびサービスについてのいくつかのルール制約があるであろうし、例えば、いくつかの特定のストリームは、所定のドメイン内ＬＳＰにおいて、通すことできるか、または通すことが禁止され、ルート選択の失敗も導くかもしれないしかしながら、フォワードルート選択とバックワードルート選択とを単純に置き換えた場合、前記問題も避けられない。したがって、種々のサービスの要求は、十分に満足させれない。

他の場合、先行技術において、このパスにおける帯域を通過し占有するであろうサービス要求を通すパスは、各ルーターのルーティングテーブルにしたがって計算される。この場合において、ドメイン内ルート選択を実行する間に、所定のルーターの情報がアップデートされれば、例えば、新たなサービスを開発し、またはサービスをアップデートする場合、ベアラ制御階層のベアラネットワークリソースマネージャーの情報もアップデートされるべきであり、ネットワーク予約の不安定性をもたらすかもしれない。一方では、ベアラネットワークリソースマネージャーは、ローカルドメインの動的ルート情報を記録する必要があり、ルーティングテーブルがしばしばアップデートされるであろう問題をもたらすかもしれない。この場合では、ネットワーク予約は、不安定であろうし、決定されたサービスルートが、サービスストリームの現実の転送ルートと同じであることを保証することも困難である。

発明の要旨
この観点から、本発明の主な目的は、ルーティングの成功率を増やすだけでなく、簡単で自由自在な様式で至適なエンド・ツー・エンドルートを得、妥当なリソース割り当てを保証しうる、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

本発明の別の目的は、ルーティングの成功率を増やし、信頼できるルートの構築を保証しうる、フォワード制約およびバックワードルーティングに基づく、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

本発明のさらに他の目的は、ベアラネットワークリソースマネージャーによるネクストホップルートの検索の成功率を増やし、リソース割り当ての信頼性を保証しうる、ホップ・バイ・ホップルーティングに基づく、リアルタイムサービスデータ伝送路を選択する方法を提供することにある。

本発明のさらに別の目的は、ベアラネットワークリソースマネージャーによりベアラ階層に対するベアラサービス接続の選択の成功率を増やし、リソース割り当ての信頼性を保証しうる、ホップバイホップルーティングに基づく、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

本発明のさらに他の目的は、ベアラネットワークリソースマネージャーのルーティングを実行するだけでなく、ルーティングの成功率をも増やしうる、ラベル交換に基づく、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

本発明のさらに他の目的は、自由自在に、高い効率のルーティングおよびリソース割り当てで、ベアラネットワークリソースマネージャーのルーティング負荷を減らし、ネットワーク安定性を維持しうる、静的ルートに基づく、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

本発明のさらに別の目的は、ＱｏＳ保証クロス独立オペレーションネットワークのサービスルートルーティングを実行しうる、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

本発明のさらに別の目的は、Ｅ．１６４アドレス指定とＩＰアドレス指定との両方の利点を兼ね備え、ルーティングテーブルを単純化し、ネットワークアドレス指定能を増やし、オペレーションネットワークにおける大規模ＩＰネットワークのルーティングを簡単にかつ迅速にし、ネットワークルートの安定性を増やしうる、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

前記目的に基づき、本発明は、サービス制御階層とベアラネットワークとの間に２以上のベアラネットワークリソースマネージャーを備えた独立ベアラ制御階層を構築するステップを含み、サービス制御階層に接続されるソースベアラネットワークリソースマネージャーがリアルタイムサービスの接続要求を受けた後、ソースベアラネットワークリソースマネージャーから、宛先ベアラネットワークリソースマネージャー、各ベアラネットワークリソースマネージャーに対応する管理ドメインのリアルタイムサービスに対するドメイン内ルートパス、および隣接ベアラネットワークリソースマネージャーに対応する隣接管理ドメインの間のドメイン間ルートパスの方へ、規則的に選択し決定するステップをさらに含む、リアルタイムサービスデータ伝送路の選択方法を提供することにある。

ドメイン間ルートパスを選択し、決定するステップは、接続要求が、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーセグメントに、セグメントで送られ、各ベアラネットワークリソースマネージャーが、それ自体と隣接ネクストホップベアラネットワークリソースマネージャーとの間の利用可能なルートパスリソースを受ける接続要求を受けるものである場合、宛先ベアラネットワークリソースマネージャーに接続要求が届いた後、宛先ベアラネットワークリソースマネージャーからソースベアラネットワークリソースマネージャーまで、セグメントごとに、隣接ベアラネットワークリソースマネージャー間の最終ルートを決定することおよび決定されたルートについて受けたものを除くルートパスリソースを回収することを含んでもよい。

一方、ドメイン内ルートパスまたはドメイン間ルートパスを選択し、決定するステップは、それ自体と隣接するネクストホップベアラネットワークリソースマネージャーまたは接続ノードとの間のルートパスを決定するに過ぎない接続要求を受けるベアラネットワークリソースマネージャーにより管理された管理ドメイン内部の各ベアラネットワークリソースマネージャーまたは接続ノードを含んでもよい。ここで、ルートパスは、ラベル交換パスである。

前記スキームにおいて、接続要求は、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまで、セグメントごとに、送られる。ネクストホップベアラネットワークリソースマネージャーから接続リソース応答をうけた後、宛先ベアラネットワークリソースマネージャーに先立ち、各ベアラネットワークリソースマネージャーが、それぞれの管理ドメインにおけるパスリソースを割り当てる。

前記スキームにおいて、本方法は、ドメイン内ルートパスまたはドメイン間ルートパスを選択し、決定するステップが、前もってセットされた利用可能なルートパスから正しいルートを選択し、決定する接続要求を受ける各ベアラネットワークリソースマネージャーを含むものである、各ベアラネットワークリソースマネージャーにより要求される全ルートパスの情報を前もってセットすることをさらに含んでもよい。

ＩＰルートを導入すれば、本方法はドメイン内ルートパスまたはドメイン間ルートパスを選択し、決定するステップが、構築されたドメイン間ルート情報関係テーブルおよび構築されたドメイン内ルート情報テーブルにしたがってベアラネットワークリソースマネージャーのドメイン内ルートパスまたはドメイン間ルートパスを選択するステップを含むものである、Ｅ．１６４様式に従って、各ベアラネットワークリソースマネージャーの管理ドメインに対するエリアコードを設定するステップ、および各管理エリアに対するドメイン間ルート情報関係テーブルおよびドメイン内ルート情報テーブルを構築することをさらに含んでもよい。

前記スキームにおいて、２以上のベアラネットワークリソースマネージャーが同じオペレーションネットワークまたは異なるオペレーションネットワークに属する。

前記スキームにおいて、ドメイン間ルートパスを選択し、決定するステップは、前もってセットされたリソース制約状況または現行ルーティングストラテジーにしたがって、ルート間パスを決定することを含んでもよい。

前記スキームにおいて、本方法は、隣接するベアラネットワークリソースマネージャー間の全てのボーダールーターを、それぞれ、入口ルーターおよび出口ルーターとして取得するステップ、各入口ルーターと各出口ルーターとの間のパスなどのパス集約を得るステップ、およびついで、パス集約にしたがって、隣接するベアラネットワークリソースマネージャー間の所望のドメイン間ルートを選択するステップをさらに含んでもよい。

前記スキームにおいて、本方法は、入口ＩＰアドレス識別子および出口ＩＰアドレス識別子それぞれとして、隣接するベアラネットワークリソースマネージャーの間の全てのボーダールーターに対応するＩＰアドレスセグメントを取得するステップ、および各入口ＩＰアドレス識別子と各出口ＩＰアドレス識別子との間のラベル交換チパスなどのラベル交換パス集約を得るステップ、ついで、ラベル交換パス集約にしたがって、隣接ベアラネットワークリソースマネージャーの間の所望のドメイン間ルートを選択するステップをさらに含んでもよい。

前記スキームにおいて、本方法は、ドメイン内ルートパスを選択し、決定するステップは、前もってセットしたリソース制約状況または前もってセットしたルーティングストラテジーにしたがって、ベアラネットワークリソースマネージャーの管理ドメインにおけるドメイン内ルートパスを決定することを含んでもよい。

前記スキームにおいて、本方法は、各ベアラネットワークリソースマネージャーについて、ベアラネットワークリソースマネージャーの管理ドメイン内の全ルーターを、入口ルーターおよび出口ルーターそれぞれとして取得するステップ、各入口ルーターおよび各出口ルーターの間のパスを含むパス集約を得るステップ、ならびにパス集約にしたがい、ベアラネットワークリソースマネージャーの所望のドメイン内ルートを選択するステップをさらに含んでもよい。

前記スキームにおいて、本方法は、各ベアラネットワークリソースマネージャーについて、ベアラネットワークリソースマネージャーの管理ドメインの内部の全てのＩＰアドレスセグメントを、入口ＩＰアドレス識別子および出口ＩＰアドレス識別子それぞれとして取得するステップ、各入口ＩＰアドレス識別子と各出口ＩＰアドレス識別子との間のラベル交換パスを含むラベル交換パス集約を得るステップ、および、ついで、ラベル交換パス集約にしたがって、ベアラネットワークリソースマネージャーの所望のドメイン内ルートを選択するステップをさらに含んでもよい。

また、本発明は、
Ａ１．ベアラネットワークリソースマネージャーが、接続リソース要求を受けた後、それ自体が宛先ベアラネットワークリソースマネージャーであるかどうかを判断し、もしそうであれば、ステップＣ１を実行し、さもなければ、ステップＢ１を実行するステップ；
Ｂ１．接続リソース要求を受ける現行ベアラネットワークリソースマネージャーが、接続リソース要求を、ネクストホップベアラネットワークリソースマネージャーに送り、ドメイン間ルートリソースを予約し、および、ついで、ステップＡ１に戻るステップ；
Ｃ１．接続リソース要求を受ける現行ベアラネットワークリソースマネージャーが、それ自体がソースベアラネットワークリソースマネージャーであるかどうかを判断し、もしそうであれば、ルートパスの構築を実施し、現行ルーティング手順を終了し、そうでなければ、ステップＦ１を実行するステップ；
Ｄ１．接続リソース応答を受けるベアラネットワークリソースマネージャーは、ドメイン間ルートリソースを回収するステップ；
Ｅ１．接続リソース応答を受ける現行ベアラネットワークリソースマネージャーが、それ自体がソースベアラネットワークリソースマネージャーであるかどうかを判断し、もしそうであれば、ルートパスの構築を実施し、現行ルーティングフローを終了し、そうでなければ、現行ベアラネットワークリソースマネージャーが受けた接続リソース応答にしたがって、受けた対応する接続リソース要求を探し出すステップ；ならびに
Ｆ１．現行ベアラネットワークリソースマネージャーが、入口ボーダールーターを選択し、接続リソース要求にしたがって前ホップベアラネットワークリソースマネージャーを確認し、接続リソース応答を、前ホップベアラネットワークリソースマネージャーに戻し、ついで、ステップＤ１に戻すステップ、
を含む、フォワード制約およびバックワードルーティングに基づく、リアルタイムサービスデータ伝送路の選択方法を提供する。

また、本発明は、
Ａ２．接続リソース要求を受けるベアラネットワークリソースマネージャーが、宛先ベアラネットワークリソースマネージャーであるかどうかを判断し、そうであれば、シグナリングルートパスの構築を実行し、現行ルーティング手順を終了し、そうでなければ、ステップＢ２を実行するステップ；および
Ｂ２．現行ベアラネットワークリソースマネージャーが、ネクストホップベアラネットワークリソースマネージャーを選択し、接続リソース要求を、ネクストホップベアラネットワークリソースマネージャーに送り、ステップＡ２に戻るステップ、
を含む、ホップバイホップルーティングに基づく、リアルタイムサービスデータ伝送路の選択方法を提供する。

また、本発明は、
Ａ３．現行ベアラネットワークリソースマネージャーが、受けた接続リソース要求にしたがって、ドメイン内入口接続ノード（ＣＮ）を見出し、見出された入口ＣＮの情報を、検索されたルーターの集約に加えるステップ；
Ｂ３．現行ベアラネットワークリソースマネージャーが、現行入口ＣＮにしたがってドメイン内ラベル交換パスを選択するステップ；
Ｃ３．現行ベアラネットワークリソースマネージャーが、選択されたドメイン内ラベル交換パスの出口ＣＮが現行ベアラネットワークリソースマネージャーの管理ドメイン内のエッジサーバーまたはボーダーサーバーであるかどうかを判断し、もしそうであれば、サービスルートパスの構築を実行し、現行ルーティング手順を終了し、そうでなければ、ステップＤ３を実行するステップ；および
Ｄ３．現行ベアラネットワークリソースマネージャーが、現行出口ＣＮの情報が既に検索したルーターの集約に加えられたかどうかを判断し、そうであれば、選択されたドメイン内ラベル交換パスの選択を放棄し、ステップＢ３に戻り、そうでなければ、現行入口ＣＮとして、現行出口ＣＮを取得し、検索したルーターの集約に、このＣＮの情報を記録し、ステップＢ３に戻る、
を含む、ホップバイホップルーティングに基づく、リアルタイムサービスデータ伝送路の選択方法を提供する。

また、本発明は、
Ａ４．ソースベアラネットワークリソースマネージャーから、各ホップベアラネットワークリソースマネージャーとネクストホップベアラネットワークリソースマネージャーとの間のドメイン間ラベル交換パスを規則的に決定し、ドメイン間ラベル交換パスを記録し、接続リソース要求をネクストホップベアラネットワークリソースマネージャーに送り、ネクストホップベアラネットワークリソースマネージャーが宛先ベアラネットワークリソースマネージャーであるかどうかを判断し、もしそうであれば、ステップＢ４を実行し、そうでなければ、ステップＡ４を繰り返すステップ；
Ｂ４．宛先ベアラネットワークリソースマネージャーから、各ホップベアラネットワークリソースマネージャーのドメイン内ラベル交換パスを決定し、ドメイン内ラベル交換パスを記録し、ベアラネットワークリソースマネージャーにより記録されたドメイン間ラベル交換パスおよびドメイン内ラベル交換パスを、ソースベアラネットワークリソースマネージャーに対するサービスルートリソース確認応答により、前ホップベアラネットワークリソースマネージャーに送るステップ；ならびに
Ｃ４．ソースベアラネットワークリソースマネージャーがドメイン内ラベル交換パスを構築し、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでである全ラベル交換パスを、ストリームマッピングコマンドにより、エンドオフィスルーター／タンデムオフィスルーターに送るステップ、
を含む、ラベル交換に基づく、リアルタイムサービスデータ伝送路の選択方法を提供する。

また、本発明は、
Ａ５．ベアラネットワークリソースマネージャーにより要求されたルートパス情報を前もって設定するステップ；ならびに
Ｂ５．接続リソース要求または接続リソース応答を受けた後、ベアラネットワークリソースマネージャーは、接続リソース要求または接続リソース応答にしたがって、ステップＡ５で設定されたルートパス情報から正しいルートパスを選択するステップ、
を含む、静的設定に基づく、リアルタイムサービスデータ伝送路の選択方法を提供する。

また、本発明は、独立オペレーションネットワークにおいて、ボーダールーターを管理するベアラネットワークリソースマネージャーにおける仮想宛先ユーザーを前もってセットし、現行独立オペレーションネットワークにおいて、このバーチャル宛先ユーザーを、宛先ユーザーを管理する宛先独立オペレーションネットワークのゲートウェイと接続されるボーダールーターと結ぶステップ、を含み、
Ａ６．現行独立オペレーションネットワークのユーザーが、宛先独立オペレーションネットワークの宛先ユーザーに、サービスを送る場合、現行独立オペレーションネットワークのリソースマネージャーが、このサービスの宛先アドレスにしたがって、仮想宛先ユーザーを決定し、現行独立オペレーションネットワークを仮想宛先ユーザーと結ぶボーダールーターを決定し、ベアラリソースと、このサービスの現行独立オペレーションネットワークにおけるボーダールーターにサービスを送るユーザーからのルートとを割り当てるステップ；ならびに、
Ｂ６．現行独立オペレーションネットワークおよび宛先独立オペレーションネットワークが、ベアラリソースおよびステップＡ６で割り当てられたルートにしたがって、サービスを宛先ユーザーに送るユーザーからのルート、現行独立オペレーションネットワークと宛先独立オペレーションネットワークとの間の前もってセットされたルートならびにベアラリソースと宛先独立オペレーションネットワークによりセットされたルートを決定し、ついで、サービスを送るステップ、
をさらに含む、ネットワーククロス独立オペレーションネットワークにおけるリアルタイムサービスデータ伝送路の選択方法を提供する。

また、本発明は、Ｅ．１６４様式にしたがって、各ベアラ制御サーバーに対応する管理エリアの管理エリアコード設定し、異なる管理エリア間のルートの情報を保存するトポロジ関係テーブルを構築し、管理エリア内のルートの情報を保存するルート情報テーブルを構築するステップ；
を含み、
Ａ７．発呼ユーザーが、発呼ユーザーが位置づけられる管理エリアのサービスサーバーに、発呼要求を送るステップ；
Ｂ７．サービスサーバーが受けた発呼要求ルートにしたがって、管理エリアに対応するベアラ制御サーバーに、要求を送るステップ；
Ｃ７．ベアラ制御サーバーが、受けたルート要求および保存されたトポロジ関係テーブルにしたがって、発呼ユーザーのルートを割り当てるステップ；ならびに
Ｄ７．割り当てられたルートが、着呼ユーザーが位置づけられる管理エリアに到着した後、着呼ユーザーが位置づけられる管理エリアのベアラ制御サーバーが、管理エリアの構築されたルート情報テーブルにしたがって、ルートを選択するステップ、
をさらに含む、リアルタイムサービスデータ伝送路の選択方法を提供する。

本発明で提供されるリアルタイムサービスデータ伝送路の選択方法によれば、ソースベアラネットワークソースマネージャーからベアラ制御階層により設定されたＩＰネットワークにおけるリアルタイムサービスの宛先ベアラネットワークソースマネージャーまでのエンド・ツー・エンドルートを構築する必要がある場合、隣接するベアラネットワークソースマネージャーの間のベアラネットワークソースマネージャーおよびドメイン間ルートのそれぞれのドメイン内ルートが、ベアラネットワークソースマネージャーの管理ドメインの区域の使用を行なうことにより、セグメント毎に決定される。したがって、至適なエンド・ツー・エンドルートが選択され得、インターネットにおける帯域リソースが、十分にかつ合理的に利用され得、パス構築の信頼性が保証され得、パス選択効率および成功率は、さらに増加されうる。本発明は、種々の複雑な構造のネットワークなどの任意のトポロジ構造のネットワークに応用でき、実行、維持および管理が簡単である。

発明の詳細な説明
本発明の目的、技術スキーム、および利点を明らかにさせるため、以下、本発明を、添付図面および具体的な実施形態を参照して、詳細に述べる。

本発明の中核となるアイディアは：図１に示されるネットワークトポロジ構造において、サービス制御階層において、コールエージェントにより送られたリアルタイムサービスに対する接続要求を受けた後、ソースベアラネットワークリソースマネージャーは、接続要求を、それ自体から順に、宛先ベアラネットワークリソースマネージャーに送り、各ベアラネットワークリソースマネージャーに対応する管理ドメインにおけるリアルタイムサービスのドメイン内ルートパスと、隣接するベアラネットワークリソースマネージャーに対応する隣接する管理ドメイン間のドメイン間ルートパスとを規則的に選択し、決定し、それにより、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでの至適ルートを選択する。

ここで、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーへのルートは、エンド・ツー・エンドルートとも呼ばれうる。至適なエンド・ツー・エンドルートは、フォワード制約バックワードルーティング、ホップバイホップルーティング、静的設定ルーティングなどの複数の異なるルーティング様式により決定されうる。ルートパスは、ラベル交換パスまたは別のベアラネットワークパスでありうる。

第１の実施形態：フォワード制約およびバックワードルーティング
このルーティング方法の主なアイディアは、以下のとおりである。ソースベアラネットワークリソースマネージャーなどの各ベアラネットワークリソースマネージャーは、要求メッセージにおける宛先アドレスにしたがって、ネクストホップベアラネットワークリソースマネージャーを選択し、それ自体の検出後のネットワークトポロジ構造は、受けた接続リソース要求メッセージによる宛先ベアラネットワークリソースマネージャーではなく、すなわち、この要求メッセージにおけるサービスストリームを検出した後は、このベアラネットワークリソースマネージャーの管理ドメイン内の任意のＥＲを介して外部ネットワークに送信されるべきでなく、それゆえ、接続リソース要求メッセージを、ネクストホップベアラネットワークリソースマネージャーに送り、それ自体とネクストホップベアラネットワークリソースマネージャーとの間のドメイン間ルートリソースを予約する。それ自体が、受けた接続リソース要求メッセージによる宛先ベアラネットワークリソースマネージャーであることを検出、すなわち、この要求メッセージにおけるサービスストリームが、このベアラネットワークリソースマネージャーの管理ドメイン内の所定のＥＲを介して外部ネットワークに伝送される必要があることを検出すれば、所定のベアラネットワークリソースマネージャーは入口ＢＲおよびこのベアラネットワークリソースマネージャーより管理されたドメイン内のＬＳＰを、要求メッセージにしたがって選択し、ついで、選択された入口ＢＲについての情報を含む接続リソース応答メッセージを、前ホップベアラネットワークリソースマネージャーに送る。前ホップベアラネットワークリソースマネージャーは、この入口ＢＲにしたがって、そのドメイン内の所定のＬＳＰを選択し、予約されたドメイン間ルートリソースを回収し、さらに、それ自体により選択されたＬＳＰにおける入口ＢＲについての情報を含む接続リソース応答メッセージを、その前ホップベアラネットワークリソースマネージャーに送る。残りは、さらに、ソースベアラネットワークリソースマネージャーが接続リソース応答メッセージを受けるまで、アナロジーにより推定されてもよい。ついで、ソースベアラネットワークリソースマネージャーは、同じ方法によりドメイン内ＬＳＰを選択し、予約されたドメイン間ルートリソースを回収し、最後に、接続リソース応答メッセージを、ＣＡに送る。今のところ、全ルートパスが構築されている。

図６は、フォワードおよびバックワードルーティングのルーティング方法を利用することによる、ベアラネットワークリソースマネージャー間のシグナリングルートパス構築のフローチャートである。

ステップ６０１において、リソースベアラネットワークリソースマネージャーは、ＣＡから、接続情報、ＱｏＳパラメータ、サービスタイプなどの要求メッセージを含む接続リソース要求メッセージを受ける。ここで、接続情報は、セッションＩＤ、発呼側パーティーのＩＰアドレスまたはドメインネーム、着呼側パーティーのＩＰアドレスまたはドメインネームを含む。ＱｏＳパラメータは、フロー記述子および帯域幅要求情報を含む。

ステップ６０２において、接続リソース要求メッセージを受けた後、ベアラネットワークリソースマネージャーは、それ自体が宛先ベアラネットワークリソースマネージャー、すなわち、この要求メッセージにおけるサービスストリームが、このベアラネットワークリソースマネージャーの管理ドメインの内部の所定のＥＲを介して外部ネットワークに送信されるべきであるかどうかを判断する。もしそうであれば、ステップ６０５は、実行され、そうでなければ、ステップ６０３が事項されるであろう。

ステップ６０３においてベアラネットワークリソースマネージャーは、接続リソース要求メッセージにおける宛先アドレスにしたがって、ネクストホップベアラネットワークリソースマネージャーを選択し、それ自体とネクストホップベアラネットワークリソースマネージャーとの間のドメイン内ＬＳＰを選別する場合、ネクストホップベアラネットワークリソースマネージャー側の各選択可能なＢＲに対するＬＳＰを選択し、各選択されたＬＳＰにおけるいくつかの帯域幅を予約、すなわち、ドメイン内ルートリソースを予約する。

ステップ６０４において、このベアラネットワークリソースマネージャーは、接続リソース要求メッセージを、ネクストホップベアラネットワークリソースマネージャーに送り、ついで、ステップ６０２が実行されるであろう。

ステップ６０５において、このベアラネットワークリソースマネージャーは、それ自体が、ソースベアラネットワークリソースマネージャーであるかどうかを判断する。もしそうであれば、ステップ６１０が、実行され、そうでなければ、ステップ６０９が、実行されるであろう。

ステップ６０６において、応答メッセージにおいて提供された入口ＢＲにしたがって、接続リソース応答メッセージを受けるベアラネットワークリソースマネージャーがそれ自体と応答メッセージを戻すネクストホップベアラネットワークリソースマネージャーとの間の提供された入口ＢＲ以外のこれらのＢＲに関連するＬＳＰについて予約された帯域幅を回収し、すなわち、ドメイン内ルートリソースを予約する。

ステップ６０７において、このベアラネットワークリソースマネージャーは、それ自体がソースベアラネットワークリソースマネージャーであるかどうかを判断する。もしそうであれば、ステップ６１０が実行され、そうでなければ、ステップ６０８が実行されるであろう。

ステップ６０８において、このベアラネットワークリソースマネージャーは、接続リソース応答メッセージにしたがって、受けた対応する接続リソース要求メッセージを見出す。

ステップ６０９において、それ自体とネクストホップベアラネットワークリソースマネージャーとの間のシグナリングルートパス、および接続リソース要求情報において提供された選択可能なボーダールーターについての情報にしたがって、このベアラネットワークリソースマネージャーは、それ自体の管理ドメイン内の適切なドメイン内ＬＳＰを選択し、ついで、選択されたドメイン内ＬＳＰにしたがって、入口ＢＲを決定する。接続リソース要求メッセージにしたがって、前ホップベアラネットワークリソースマネージャーを決定した後、ベアラネットワークリソースマネージャーは、このベアラネットワークリソースマネージャーに選択された入口ＢＲについての情報および下流のベアラネットワークリソースマネージャーのルート選択情報を含む応答メッセージである接続リソース応答メッセージを、前ホップベアラネットワークリソースマネージャーに戻し、ついで、ステップ６０６に戻して実行する。

ステップ６１０において、ルートパス構築を達成する。具体的には、ソースベアラネットワークリソースマネージャーは、ストリームマッピングコマンドを、ローカルドメイン内のＥＲに送る。ここで、ＥＲは、前記構築されたルートパスの入口ＥＲである。コマンドは、ＱｏＳ、ストリーム情報、ルートパス情報などを含む。ソースベアラネットワークリソースマネージャーは、そのドメイン内のＥＲからのストリームマッピングコマンドに対する応答を受けた後、接続リソース応答メッセージを、ＣＡに戻す。

ここで、ステップ６０４における接続リソース要求メッセージは、制約集約と呼ばれるＢＲ集約を含む。この制約集約における各ＢＲは、現行ベアラネットワークリソースマネージャーネクストホップベアラネットワークリソースマネージャーとの間の各選択可能なドメイン内ＬＳＰの出口ＢＲであり、各出口ＢＲは、ネクストホップベアラネットワークリソースマネージャーに属する。実際に、この制約集約は、ネクストホップベアラネットワークリソースマネージャーについての制約状況を提供し、すなわち、ネクストホップベアラネットワークリソースマネージャーは、この制約集約からのドメイン内ＬＳＰの入口ＢＲを選択しうるにすぎない。

代わりに、ステップ６０９において、接続リソース要求メッセージにしたがって、それぞれの管理ドメインにおける入口ＢＲを選択した後、このベアラネットワークリソースマネージャーは、ドメイン内ＬＳＰを選択し、ついで、接続リソース要求メッセージにしたがって、前ホップベアラネットワークリソースマネージャーを決定する。

図７は、多数のベアラネットワークリソースマネージャーの間のメッセージ相互作用を示す概念図である。ここで、ベアラネットワークリソースマネージャー１は、ソースベアラネットワークリソースマネージャーであり、ベアラネットワークリソースマネージャーｎは、宛先ベアラネットワークリソースマネージャーであり、他のベアラネットワークリソースマネージャーは、中間ベアラネットワークリソースマネージャーである。

ソースベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャー１は、それ自体が、ＣＡにより送られた接続リソース要求を受けた後の宛先ベアラネットワークリソースマネージャーでないことを判断する場合、この接続要求およびネットワークトポロジ構造における宛先アドレスにしたがって、ネクストホップベアラネットワークリソースマネージャーを選択する。それ自体とベアラネットワークリソースマネージャー２などのネクストホップベアラネットワークリソースマネージャーとの間のドメイン間ＬＳＰを選択する場合、これらのＬＳＰの出口がベアラネットワークリソースマネージャー２の側のＢＲと異なる場合、ベアラネットワークリソースマネージャー１は、接続リソース要求メッセージにより、ベアラネットワークリソースマネージャー２の側の全利用可能なドメイン間ＬＳＰの出口ＢＲから構成された集約、すなわち、制約集約のネクストホップベアラネットワークリソースマネージャーに知らせるであろう。一方では、ベアラネットワークリソースマネージャー１は、ドメイン間ルーティングを行なうことおよびベアラネットワークリソースマネージャー２がドメイン内ルーティングを行なう場合、選択されたドメイン間ＬＳＰの入口ＢＲが前記制約集約における１つのＢＲである必要があることを、ベアラネットワークリソースマネージャー２に通知する。ついで、ベアラネットワークリソースマネージャー１は、制約集約における各選択可能なＢＲについてのドメイン間ＬＳＰを選択し、各選択されたドメイン間ＬＳＰの所定の帯域幅を予約、すなわち、ドメイン間ルートリソースを予約し、接続リソース要求メッセージを、ベアラネットワークリソースマネージャー２に送る。ベアラネットワークリソースマネージャー１により送られた接続リソース要求を受けた後、ベアラネットワークリソースマネージャー２は、それ自体が宛先ベアラネットワークリソースマネージャーでないことを決定し、ベアラネットワークリソースマネージャー１により用いられるのと同じ方法で、ネクストホップベアラネットワークリソースマネージャーを選択、すなわち、ベアラネットワークリソースマネージャー３を選択し、ドメイン間ルートリソースを予約し接続リソース要求メッセージを、ベアラネットワークリソースマネージャー３に送るであろう。残りは、アナロジーにより推定されてもよい。すなわち、それ自体が、前ホップベアラネットワークリソースマネージャーにより送られた接続リソース要求を受けた後の宛先ベアラネットワークリソースマネージャーでないことが決定されれば、各ベアラネットワークリソースマネージャーが、ベアラネットワークリソースマネージャー１により用いられたのと同じ方法でネクストホップベアラネットワークリソースマネージャーを選択し、所定のドメイン間ルートリソースを予約し、接続リソース要求メッセージを、ネクストホップベアラネットワークリソースマネージャーに送るであろう。

前ホップベアラネットワークリソースマネージャーにより送られた接続リソース要求メッセージにしたがって、それ自体が宛先ベアラネットワークリソースマネージャーであることを決定する場合、宛先ベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャーｎは、このメッセージで提供された制約集約から、入口ＢＲを選択し、接続リソース要求メッセージにしたがって、ドメイン内ＬＳＰを決定し、前ホップベアラネットワークリソースマネージャーを決定した後に、接続リソース応答メッセージを前ホップベアラネットワークリソースマネージャーに戻し、この応答メッセージにより、選択された入口ＢＲの前ホップベアラネットワークリソースマネージャーに通知するであろう。受けた接続リソース応答メッセージにおいて提供された入口ＢＲによれば、ベアラネットワークリソースマネージャーｎの前ホップベアラネットワークリソースマネージャーは、それ自体とベアラネットワークリソースマネージャーｎとの間の提供された入口ＢＲ以外のこれらのＢＲｓに関連するＬＳＰについて予約されたドメイン間ルートリソースを回収し、ついで、それ自体がソースベアラネットワークリソースマネージャーであるかどうかを判断する。もしそうでなければ、ベアラネットワークリソースマネージャーｎから戻された受けた接続リソース応答メッセージに対応する接続リソース要求メッセージを見出し、ついで、ベアラネットワークリソースマネージャーｎにより用いられたのと同じ方法で、入口ＢＲおよびドメイン内ＬＳＰを選択し、その前ホップベアラネットワークリソースマネージャーを決定し、ついで、接続リソース応答メッセージを、その前ホップベアラネットワークリソースマネージャーに戻し、応答メッセージにより、選択された入口ＢＲの前ホップベアラネットワークリソースマネージャーに通知する。残りは、アナロジーにより推定されてもよい。すなわち、ソースベアラネットワークリソースマネージャー以外の各ベアラネットワークリソースマネージャーは、前記方法を用いることにより、ドメイン間ルートリソースを回収し、入口ＢＲおよびドメイン内ＬＳＰを選択し、接続リソース応答メッセージがソースベアラネットワークリソースマネージャーに届くまで、接続リソース応答メッセージを、その前ホップベアラネットワークリソースマネージャーに戻す。接続リソース応答メッセージを受けた後、ソースベアラネットワークリソースマネージャーは、メッセージにおいて提供された入口ＢＲにしたがって、それ自体と接続リソース応答メッセージを送るネクストホップベアラネットワークリソースマネージャーとの間の提供された入口ＢＲ以外のこれらのＢＲに関連するＬＳＰについて予約されたドメイン間ルートリソースを回収し、ついで、ドメイン内ＬＳＰを選択し、最終的に、全ルートパスの構築を終える。ついで、ソースベアラネットワークリソースマネージャーは、ストリームマッピングコマンドを、ローカルドメイン内のＥＲに送り、ドメイン内ＥＲからのストリームマッピングコマンドに対する応答を受けた後、接続リソース応答メッセージを、ＣＡに戻す。

前記手順において、過度のドメイン間またはドメイン内選択可能なパス情報があれば、複雑な計算を導き、システムの諸経費を増やすであろう。この場合、サービスタイプ、優先順位、いくつかのローカルに設定されたルーティングストラテジー、いくつかの特定のＱｏＳ要求などのいくつかの制約状況ならびにリソース利用可能性状況サービスフローなどの現行ネットワーク状況が、算出を容易にするために加えられうる。

前記ルーティング方法の具体的な実施形態は、以下、図５を参照して述べられるであろう。ベアラネットワークリソースマネージャー２がエッジサーバーＥＲ３およびＥＲ４を管理するとともに、ベアラネットワークリソースマネージャー１がエッジサーバーＥＲ１およびＥＲ２を管理することおよびＥＲ１〜ＥＲ４により接続されたアドレスセグメントが、図５に示されるように、それぞれ１０．１．０．０〜１０．１．２５５．２５５、１０．２．０．０〜１０．２．２５５．２５５、１０．３．０．０〜１０．３．２５５．２５５および１０．４．０．０〜１０．４．２５５．２５５であることを仮定する。

ここで、ＣＡが接続リソース要求メッセージを、ベアラネットワークリソースマネージャー１に送り、ベアラネットワークリソースマネージャー１により管理されたＥＲ２から、ベアラネットワークリソースマネージャー２により管理されたＥＲ３まで、所定のサービスストリームを転送することを要求すれば、ベアラネットワークリソースマネージャー１は、この接続リソース要求メッセージにしたがって、それ自体が、宛先ベアラネットワークリソースマネージャーでないことを決定、すなわち、それ自体のドメインにおける任意のＥＲを介して、このサービスストリームが外部ネットワークに転送されないべきであることを決定し、ついで、要求メッセージおよびネットワークトポロジ構造における宛先アドレスにしたがって、ベアラネットワークリソースマネージャー２などのネクストホップベアラネットワークリソースマネージャーを選択する。ネクストホップベアラネットワークリソースマネージャーを選択した後、ベアラネットワークリソースマネージャー１は、このサービスストリームが、ドメイン内ＬＳＰにより、ＥＲ２からＢＲ１またはＢＲ２に転送されることおよびベアラネットワークリソースマネージャー２が、ＢＲ３またはＢＲ４を用いて、ベアラネットワークリソースマネージャー１により転送されたサービスストリームを受けうることを検出し、すなわち、ベアラネットワークリソースマネージャー１および２の間の４つの選択可能なドメイン間ＬＳＰ：ＬＳＰ１１、ＬＳＰ１２、ＬＳＰ１３およびＬＳＰ１４がある。しかしながら、４つのドメイン間ＬＳＰは、ベアラネットワークリソースマネージャー２により管理されたＢＲ３およびＢＲ４の２つの出口、具体的には、ＬＳＰ１１およびＬＳＰ１３の出口がＢＲ３であり、ＬＳＰ１２およびＬＳＰ１４の出口がＢＲ４である。この場合、ベアラネットワークリソースマネージャー１は、ベアラネットワークリソースマネージャー２の側の選択可能なＢＲにしたがって、各選択可能なＢＲに対してドメイン間ＬＳＰを選択、例えば、ＬＳＰ１１とＬＳＰ１２とを、またはＬＳＰ１１とＬＳＰ１４とを、またはＬＳＰ１２とＬＳＰ１３とを、またはＬＳＰ１３とＬＳＰ１４とを選択するに過ぎないであろう。ついで、ベアラネットワークリソースマネージャー１は、各選択されたドメイン間ＬＳＰに対する所定の帯域幅を予約、すなわち、ドメイン間ルートリソースを予約し、ついで、接続リソース要求メッセージを、ベアラネットワークリソースマネージャー２に送る。メッセージは、集約からＢＲを選択するためのベアラネットワークリソースマネージャー２に対する制約集約｛ＢＲ３、ＢＲ４｝を含む。ドメイン内ルート選択を行ないながら、ベアラネットワークリソースマネージャー２は、前記集約からのものである選択されたＬＳＰの入口ＢＲを保証しなければならない。

ベアラネットワークリソースマネージャー１により送られた接続リソース要求メッセージを受けた後、このメッセージにしたがって、ベアラネットワークリソースマネージャー２は、転送対象のサービスストリームが、それ自体により管理されたドメイン内のＥＲ、すなわち、ＥＲ３を介して、外部ネットワークに、転送されることを決定し、それ自体により管理されたドメインにおいて、ＢＲ３とＥＲ３との間の選択可能なドメイン内ＬＳＰおよびＢＲ４とＥＲ３との間の選択可能なドメイン内ＬＳＰである。ついで、ベアラネットワークリソースマネージャー２は、所定の状況またはアルゴリズムにしたがって、ドメイン内ＬＳＰの入口ＢＲとしてＢＲ３またはＢＲ４のいずれかを選択し得る。ＢＲ４を選択し、ＢＲ４からＥＲ３までのドメイン内ＬＳＰを決定する場合、ベアラネットワークリソースマネージャー２は、接続リソース応答メッセージを、ベアラネットワークリソースマネージャー１に送り、このメッセージにより、ＢＲ４の情報を、ベアラネットワークリソースマネージャー１に報告する。前記選択結果によれば、ベアラネットワークリソースマネージャー１は、出口ＢＲがＢＲ３である全ＬＳＰに対して予約された帯域幅を回収し、それぞれのドメイン内のＬＳＰの出口ＢＲを決定し、ＥＲ２からこの出口ＢＲまでのドメイン内ＬＳＰを選択し、それにより、全ルートパスの構築を終わらせる。その後、ベアラネットワークリソースマネージャー１は、ＱｏＳ、ストリーム情報、ルートパスなどの情報を含むコマンドであるストリームマッピングコマンドを、それぞれのドメイン内のＥＲ２に送る。ＥＲ２からのストリームマッピングコマンドに対する応答を受けた後、ベアラネットワークリソースマネージャー１は、接続リソース応答メッセージをＣＡに戻す。

前記手順において、ベアラネットワークリソースマネージャー２がドメイン内ＬＳＰの入口ＢＲとしてＢＲ３を選択し、ＢＲ３からＥＲ３までのドメイン内ＬＳＰを決定する場合、ベアラネットワークリソースマネージャー２は、接続リソース応答メッセージを、ベアラネットワークリソースマネージャー１に送り、このメッセージにより、ＢＲ３の情報を、ベアラネットワークリソースマネージャー１に報告する。前記選択結果によれば、ベアラネットワークリソースマネージャー１は、出口ＢＲがＢＲ４である全ＬＳＰについて予約された帯域幅を回収し、それぞれのドメイン内のＬＳＰの出口ＢＲを決定し、ＥＲ２からこの出口ＢＲまでのドメイン内ＬＳＰを選択し、それにより、全ルートパスの構築を終了させる。その後、ベアラネットワークリソースマネージャー１は、ＱｏＳ、ルートパスなどの情報を含むコマンドであるストリームマッピングコマンドを、それぞれのドメイン内のＥＲ２に送る。ＥＲ２からのストリームマッピングコマンドに対する応答を受けた後、ベアラネットワークリソースマネージャー１は、接続リソース応答メッセージをＣＡに戻す。

それぞれ、２つのＢＲを含む２つのベアラネットワークリソースマネージャーの間のサービスストリーム送信手段を例として前記実施形態を説明するが、本実施形態は、１または２以上のＢＲをそれぞれ含む２または３以上のベアラネットワークリソースマネージャーの間のサービスストリーム送信手段にも応用されうる。

また、ベアラネットワークリソースマネージャー１および２などの２つのベアラネットワークリソースマネージャー間に、複数のドメイン間ＬＳＰがあり、る場合、ａｎｄ各ドメイン間ＬＳＰの入口ＢＲがベアラネットワークリソースマネージャー１の側にあり、出口ＢＲがベアラネットワークリソースマネージャー２の側にある場合、１または２以上のドメイン間ＬＳＰが、各選択可能な出口ＢＲについて選択され得、所定の帯域幅が、各選択されたＬＳＰについて予約、すなわち、ドメイン間ルートリソースが予約される。実際の適用において、前記様式は、多量のドメイン間リソースの浪費を導き、それゆえ、ベアラネットワークリソースマネージャー１は、所定のアルゴリズムにしたがって、前記至適な集約における全入口ＢＲに対応するドメイン間ＬＳＰの出口ＢＲの集約が、ベアラネットワークリソースマネージャー２の側の全利用可能な出口ＢＲを含むように、ベアラネットワークリソースマネージャー１側の入口ＢＲの至適な集約を選択してもよい。

本ルーティングスキームは、フォワード制約およびバックワードルーティングのルーティング様式を提供する。詳しくは、ベアラネットワークリソースマネージャーは、ドメイン間ＬＳＰを選択する場合、いくつかのドメイン間ルートリソースを予約し、全利用可能なＬＳＰの出口ＢＲを、ネクストホップベアラネットワークリソースマネージャーに報告するであろう。出口ＢＲの集約は、ネクストホップベアラネットワークリソースマネージャーの入口ＢＲを示す。ＬＳＰを選択した後、ネクストホップベアラネットワークリソースマネージャーは、選択された出口ＢＲを、前ホップベアラネットワークリソースマネージャーに報告するであろう。ついで、前ホップベアラネットワークリソースマネージャーは、他のＢＲと関連するこれらのＬＳＰについて予約されたルートリソースを回収する。ドメイン間ルートリソースを事前に予約し、ついで、ドメイン内およびドメイン間ルートを決定するこの方法は、十分にかつ合理的に各ベアラネットワークリソースマネージャーのリソースを利用し、ルーティングの成功率を増やすことを可能にする。

フォワードルーティングおよびバックワードルーティングを組み合わせるメカニズムを導入することおよびドメイン間ルートリソースを事前に予約し、ついで、ドメイン内およびドメイン間ルートを決定することにより、現行ルーティング方法は、各ベアラネットワークリソースマネージャーのリソースの十分でかつ合理的な使用を可能にし得、ルートの信頼できる構築を保証し、それゆえ、ネットワークリソースを合理的に利用し、ルーティングの効率および成功率を増やすことを可能にする。現行ルーティング方法は、任意のトポロジ構造のネットワークに応用可能であり、実行、維持および管理を容易にする。

第２の実施形態：ホップバイホップルーティング様式
本ルーティングスキームは、その主なアイディアが、ベアラ制御階層における各ベアラネットワークリソースマネージャーが、それぞれの管理ドメインのトポロジ構造を識別するに過ぎない状況下または各ＣＮがその隣接するＣＮを認識するに過ぎない状況下、ベアラネットワークリソースマネージャーまたはＣＮが、ネクストホップベアラネットワークリソースマネージャーまたはネクストホップＣＮをただ選択し、決定するであろうことである、ベアラネットワークにおけるホップバイホップルーティングの方法を提供する。

図８は、現行実施形態のホップバイホップルーティング方法を利用することによるベアラ制御階層におけるシグナリングルートパス構築のフローチャートである。

ステップ８０１において、ソースベアラネットワークリソースマネージャーは、ＣＡから、接続情報、ＱｏＳパラメータ、サービスタイプなどを含む要求メッセージである接続リソース要求メッセージを受ける。ここで、接続情報は、セッションＩＤ、発呼側パーティーのＩＰアドレスまたはドメインネーム、着呼側パーティーのＩＰアドレスまたはドメインネームを含む。ＱｏＳパラメータは、フロー記述子および帯域幅要求情報を含む。

ステップ８０２において、接続リソース要求メッセージを受ける現行ベアラネットワークリソースマネージャーが、それ自体とこの要求メッセージを送るデバイスとの間の接続が利用可能であるかどうかを判断し、もし利用不可能であれば、ステップ８０５が実行され、そうでなければ、ステップ８０３が実行されるであろう。利用不可能とは、現行ベアラネットワークリソースマネージャーと前ホップベアラネットワークリソースマネージャーとの間の接続が現行ベアラネットワークリソースマネージャーのリソースが利用不可能であること、それ自体の機能不良または他の理由により利用できないことを意味する。

ステップ８０３において、接続リソース要求メッセージにおける宛先アドレスにしたがって、現行ベアラネットワークリソースマネージャーは、それ自体が宛先ベアラネットワークリソースマネージャーであるかどうかを判断し、もしそうであれば、ステップ８０７が実行され、そうでなければ、ステップ８０４が実行されるであろう。

ステップ８０４において、接続リソース要求メッセージにおける宛先アドレスにしたがって、現行ベアラネットワークリソースマネージャーは、ネクストホップベアラネットワークリソースマネージャーを決定し、接続リソース要求メッセージを、選択されたネクストホップベアラネットワークリソースマネージャーに送る。ついで、ステップ８０２が実行されるであろう。

ステップ８０５において、接続リソース要求メッセージを受ける現行ベアラネットワークリソースマネージャーは、接続リソース拒絶メッセージを、この接続リソース要求メッセージを送るベアラネットワークリソースマネージャーに戻す。

ステップ８０６において、この接続リソース拒絶メッセージにしたがい、接続リソース拒絶メッセージを受ける現行ベアラネットワークリソースマネージャーが受けた対応する接続リソース要求メッセージを見出す。ついで、ステップ８０４が実行されるであろう。

ステップ８０７において、接続リソース要求メッセージにしたがって、現行ベアラネットワークリソースマネージャーは、接続リソース応答メッセージを、この要求メッセージを送るベアラネットワークリソースマネージャーに戻す。

ステップ８０８において、接続リソース応答メッセージを受ける現行ベアラネットワークリソースマネージャーは、それ自体がソースベアラネットワークリソースマネージャーであるかどうかを判断する。もしそうであれば、ステップ８１０が実行され、そうでなければ、ステップ８０９が実行されるであろう。

ステップ８０９において、接続リソース応答メッセージにしたがって、現行ベアラネットワークリソースマネージャーは、受けた対応する接続リソース要求メッセージを見出す。ついで、ステップ８０７が実行されるであろう。

ステップ８１０において、シグナリングルートパスの構築が達成される。

シグナリングルートパスが構築された後、ＣＡにより送られた前記接続リソース要求メッセージにしたがって、ソースベアラネットワークリソースマネージャーは、セッションＩＤ、ストリーム情報、ＱｏＳパラメータ、フロー記述子および全パスのラベルスタックを含むコマンドであるストリームマッピングコマンドを、それぞれのドメイン内の対応する入口ＥＲに送るであろう。

ベアラネットワークリソースマネージャーが接続リソース応答メッセージを前ホップベアラネットワークリソースマネージャーに順に送る前記メカニズムは、確認メカニズムと呼ばれ得、ベアラネットワークリソースマネージャーが接続リソース拒絶メッセージを前ホップベアラネットワークリソースマネージャーに順に送り、前ホップベアラネットワークリソースマネージャーがネクストホップベアラネットワークリソースマネージャーを再選択する前記メカニズムは、バックスペースメカニズムと呼ばれうる。そのようなバックスペースメカニズムおよび確認メカニズムをホップバイホップルーティング方法に加えることにより、本実施形態は、接続構築の信頼性を最大化し得、ネットワークリソースをセーブしうる。もちろん、自由なバックスペースは、許されず、そのため、バックスペースの番号または所定のタイムスパン制限は、ホップバイホップ調査効率を保証するために前もってセットされうる。例えば、バックスペースの数が、前もってセットされた数を超える場合、または所定のベアラネットワークリソースマネージャーが接続リソース拒絶メッセージを受けるが、この受けた拒絶メッセージと対応する接続リソース要求メッセージとの間のタイムスパンが前もってセットされたタイムスパン制限を超えることを見出す場合、現行ルーティングは、失敗とみなされ、次のルーティングが回位されるであろう。さもなくば、バックスペースフラグが用いられ得、該フラグが１回だけバックスペースに用いられうる。

実際の適用において、入り組んだネットワークなどのいくつかのネットワークは、複雑な構造を有する。前記ローティング手順において、選択されたルートパスにおける既に選択されたベアラネットワークリソースマネージャーが、このパスにおける所定のベアラネットワークリソースマネージャーのネクストホップベアラネットワークリソースマネージャーとして再選択されることを回避するために、検索したベアラネットワークリソースマネージャーの集約が、セットされてもよい。この場合、ステップ８０４は、接続リソース要求メッセージを、ネクストホップベアラネットワークリソースマネージャーに送る前、現行ベアラネットワークリソースマネージャーは、選択されたネクストホップベアラネットワークリソースマネージャーが検索したベアラネットワークリソースマネージャーの前記集約にあるかどうかを判断し、もしそうであれば、現行ベアラネットワークリソースマネージャーが、選択されたネクストホップベアラネットワークリソースマネージャーを放棄し、ステップ８０４におけるネクストホップベアラネットワークリソースマネージャーを再選択し、そうでなければ、現行ベアラネットワークリソースマネージャーは、その情報を、検索したベアラネットワークリソースマネージャーの集約に加え、ついで、接続リソース要求メッセージを選択されたネクストホップベアラネットワークリソースマネージャーに送るステップをさらに含んでもよい。

図９は、本実施形態による多数のベアラネットワークリソースマネージャー間のメッセージ相互作用を示す概念図である。図９において、ベアラネットワークリソースマネージャー１は、ソースベアラネットワークリソースマネージャーであり、ベアラネットワークリソースマネージャーｎは、宛先ベアラネットワークリソースマネージャーであり、他は、中間ベアラネットワークリソースマネージャーである。

ソースベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャー１が、ＣＡにより送られた接続リソース要求メッセージを受ける場合、それ自体とこの要求メッセージの送信側との間の接続、すなわち、ＣＡがそれぞれの状況にしたがって利用可能であるかどうかを判断する。この要求メッセージにより、それ自体が宛先ベアラネットワークリソースマネージャーでないことを決定した後、ベアラネットワークリソースマネージャー１は、サービスタイプ、リソース利用可能状態、優先順位、ローカルに設定されたルーティングストラテジー、受けた接続リソース要求メッセージにおける宛先アドレスなどの情報にしたがって、ネクストホップベアラネットワークリソースマネージャーを選択し、ついで、接続リソース要求メッセージを、選択されたネクストホップベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャー２に送る。ベアラネットワークリソースマネージャー１により送られた接続リソース要求メッセージを受けた後、リソースアンアベイラビリティ、自己機能不良または他の理由などのそれぞれの状況にしたがって、ベアラネットワークリソースマネージャー２は、それ自体とこの要求メッセージの送信側、すなわち、ベアラネットワークリソースマネージャー１との間の接続が利用可能ではないことを決定し、ついで、接続リソース拒絶メッセージを、ベアラネットワークリソースマネージャー１に戻す。ベアラネットワークリソースマネージャー２により戻された接続リソース拒絶メッセージにしたがって、ベアラネットワークリソースマネージャー１は、ネクストホップベアラネットワークリソースマネージャーを再選択し、接続リソース要求メッセージを、再選択されたネクストホップベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャー３に送る。残りは、アナロジーにより推定されてもよい。その前ホップベアラネットワークリソースマネージャーにより送られた接続リソース要求メッセージを受けた後、各中間ベアラネットワークリソースマネージャーは、それぞれの状況にしたがって、それ自体と前ホップベアラネットワークリソースマネージャーとの間の接続が利用可能かどうかを判断するであろう。所定の中間ベアラネットワークリソースマネージャーは、それぞれの状況にしたがって、それ自体と前ホップベアラネットワークリソースマネージャーとの間の接続が利用不可能であることを決定し、接続リソース拒絶メッセージを、前ホップベアラネットワークリソースマネージャーに送るであろう。前ホップベアラネットワークリソースマネージャーは、戻った接続リソース拒絶メッセージにしたがって、ネクストホップベアラネットワークリソースマネージャーを再選択し、接続リソース要求メッセージを、新たに選択したネクストホップベアラネットワークリソースマネージャーに送るであろう。その前ホップベアラネットワークリソースマネージャーにより送られた接続リソース要求メッセージを受けた後、所定の中間ベアラネットワークリソースマネージャーは、それぞれの状況にしたがって、それ自体と前ホップベアラネットワークリソースマネージャーとの間の接続が利用可能であることおよびこの要求メッセージにしたがって、それ自体が宛先ベアラネットワークリソースマネージャーでないことを決定し、サービスタイプ、リソース利用可能状態、優先順位、ローカルに設定されたルーティングストラテジー、受けた接続リソース要求メッセージにおける宛先アドレスなどの情報にしたがって、ネクストホップベアラネットワークリソースマネージャーを選択し、ついで、接続リソース要求メッセージを、選択されたネクストホップベアラネットワークリソースマネージャーに送るであろう。

宛先ベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャーｎがその前ホップベアラネットワークリソースマネージャーにより送られた接続リソース要求メッセージを受けた後、それ自体と前ホップベアラネットワークリソースマネージャーとの間の接続が利用可能であることを決定するであろう。この要求メッセージにしたがって、ベアラネットワークリソースマネージャーｎが、それ自体が宛先ベアラネットワークリソースマネージャーであることを決定する場合、接続リソース応答メッセージを、この要求メッセージを送ったベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャーｎの前ベアラネットワークリソースマネージャーに戻すであろう。ベアラネットワークリソースマネージャーｎの前ホップベアラネットワークリソースマネージャーは、それ自体が、受けた接続リソース応答メッセージにより、ソースベアラネットワークリソースマネージャーでないことを決定し、ベアラネットワークリソースマネージャーｎにより戻された接続応答メッセージにしたがって、受けた対応する接続リソース要求メッセージを見出し、ついで、接続リソース応答メッセージを、この接続リソース要求メッセージを送っているベアラネットワークリソースマネージャーへ、すなわち、現行ベアラネットワークリソースマネージャーの前ホップベアラネットワークリソースマネージャーへ戻す。残りは、アナロジーにより推定されてもよい。各中間ベアラネットワークリソースマネージャーは、前記方法にしたがって、接続リソース応答メッセージを、その前ホップベアラネットワークリソースマネージャーに戻す。ソースベアラネットワークリソースマネージャー、すなわち、ベアラネットワークリソースマネージャー１が、ネクストホップベアラネットワークリソースマネージャーにより戻された接続リソース応答メッセージを受ける場合、この応答メッセージにしたがって、受けた対応する接続リソース要求メッセージを見出し、ついで、接続リソース応答メッセージを、この接続リソース要求メッセージを送っているＣＡへ戻すであろう。今までのところ、シグナリングルートパスの構築の全手順が達成される。

図９から、各ベアラネットワークリソースマネージャーが、それぞれ受けた接続リソース要求メッセージに対する接続リソース応答メッセージまたは接続リソース拒絶メッセージを提供するべきであること、および各ベアラネットワークリソースマネージャーが、接続リソース応答メッセージまたは接続リソース拒絶メッセージを、そのネクストホップベアラネットワークリソースマネージャーから接続リソース応答メッセージまたは接続リソース拒絶メッセージを受けたちょうど後のその前ホップベアラネットワークリソースマネージャーへ送ることがわかる。この確認メカニズムとバックスペースメカニズムを通して、リソース割り当ての信頼性を確保し、リソースの浪費を避ける。

図１０は、本実施形態によるベアラ制御階層のシグナリングルートパス構を示す概念図である。本実施形態において、シグナリングルートパスの構築方法は、以下のとおりである。

ＣＡにより送られた接続リソース要求メッセージを受ける場合、ベアラネットワークリソースマネージャー１００１は、この要求メッセージにしたがって、それ自体が宛先ベアラネットワークリソースマネージャーでないことを決定し、ついで、この要求メッセージにおける宛先アドレスにしたがって、ネクストホップベアラネットワークリソースマネージャーとして選択されうる全ベアラネットワークリソースマネージャーならびにベアラネットワークリソースマネージャー１００１に隣接する他のベアラネットワークリソースマネージャーのトポロジを選択する。図１０に示されるように、ベアラネットワークリソースマネージャー１００２および１００４は、ベアラネットワークリソースマネージャー１００１に隣接するので、ベアラネットワークリソースマネージャー１００１は、選択可能なネクストホップベアラネットワークリソースマネージャーとして、ベアラネットワークリソースマネージャー１００２および１００４の両方を取得し、ついで、ネクストホップベアラネットワークリソースマネージャーとして、サービスタイプ、ソース利用可能状態、優先順位、ローカルに設定されたルーティングストラテジーなどの情報にしたがって、ベアラネットワークリソースマネージャー１００２または１００４のいずれかを選択する。本実施形態において、ベアラネットワークリソースマネージャー１００１により選択されたネクストホップベアラネットワークリソースマネージャーが、ベアラネットワークリソースマネージャー１００２であると仮定すると、ベアラネットワークリソースマネージャー１００１は、接続リソース要求メッセージを、ベアラネットワークリソースマネージャー１００２に送る。要求メッセージは、セッションＩＤ、５倍量（ｑｕｉｎｔｕｐｌｅ）、サービスタイプ、ＱｏＳパラメータ、選択されたドメイン間ＬＳＰの出口ＢＲのアドレスなどの情報を含み、ベアラネットワークリソースマネージャー１００２がドメイン内ルーティングを行なうのに用いられる。おそらく、ベアラネットワークリソースマネージャー１００１により送られた接続リソース要求メッセージにしたがって、ベアラネットワークリソースマネージャー１００２は、それ自体が宛先ベアラネットワークリソースマネージャーでないことを決定し、そのため、ネクストホップベアラネットワークリソースマネージャーとして選択されうる全ベアラネットワークリソースマネージャーを選択するための前記ルールに従う。ここで、選択可能なベアラネットワークリソースマネージャーは、図１０に示されるように、ベアラネットワークリソースマネージャー１００３および１００５であり、そして、ベアラネットワークリソースマネージャー１００２は、ネクストホップベアラネットワークリソースマネージャーとしてベアラネットワークリソースマネージャー１００３または１００５のいずれかを選択する。本実施形態において、ベアラネットワークリソースマネージャー１００２が、ベアラネットワークリソースマネージャー１００３を、ネクストホップベアラネットワークリソースマネージャーとして選択し、接続リソース要求メッセージをそれに送ると仮定する。ベアラネットワークリソースマネージャー１００２により送られた接続リソース要求メッセージにしたがって、ベアラネットワークリソースマネージャー１００３は、それ自体が、まさに宛先ベアラネットワークリソースマネージャーであることを決定し、ついで、接続リソース応答メッセージを、ベアラネットワークリソースマネージャー１００２に戻す。同様に、ベアラネットワークリソースマネージャー１００２は、接続リソース応答メッセージを、ベアラネットワークリソースマネージャー１００１に戻す；ベアラネットワークリソースマネージャー１００１は、接続リソース応答メッセージを、ＣＡに戻し、最後に、シグナリングルートパスの構築の全手順を達成する。その後、前記の受けた接続リソース要求メッセージにしたがって、ベアラネットワークリソースマネージャー１００１は、セッションＩＤ、ストリーム情報、ＱｏＳパラメータ、フロー記述子および全パスのラベルスタックを含むストリームマッピングコマンドを、ローカルドメインの入口であるＥＲ１００６に送る。

前記手順において、このシグナリングルートパスの所定のベアラネットワークリソースマネージャーが、それ自体とその前ホップベアラネットワークリソースマネージャーとの間の接続が、リソースアンアベイラビリティ、自己機能不良または他の理由により利用不可であることを検出すると、このベアラネットワークリソースマネージャーは、接続リソース拒絶メッセージを、その前ホップベアラネットワークリソースマネージャーに送り、前ホップベアラネットワークリソースマネージャーに通知し、選択可能なルートパスの他のベアラネットワークリソースマネージャーを、ネクストホップベアラネットワークリソースマネージャーとして、選択するであろう。例えば、前記実施形態において、ベアラネットワークリソースマネージャー１００２が、それ自体、機能不良であるか、それ自体とベアラネットワークリソースマネージャー１００１との間のＬＳＰにおけるリソースが使い尽くされることが検出される場合、ベアラネットワークリソースマネージャー１００２は、接続リソース拒絶メッセージを、ベアラネットワークリソースマネージャー１００１に送り、ベアラネットワークリソースマネージャー１００１は、この拒絶メッセージにしたがって、ネクストホップベアラネットワークリソースマネージャーを再選択しうる。前記実施形態において、ベアラネットワークリソースマネージャー１００１は、ネクストホップベアラネットワークリソースマネージャーとしてベアラネットワークリソースマネージャー１００４を選択しうる、残りは、アナロジーにより、推定されてもよく、シグナリングルートパスは、ルージュパスを経由し、ベアラネットワークリソースマネージャー１００４からベアラネットワークリソースマネージャー１００３まで、ベアラネットワークリソースマネージャー１００５を介して、構築されうる。

ベアラネットワークリソースマネージャーが、接続リソース拒絶メッセージを、順に、前ホップベアラネットワークリソースマネージャーに送る前記メカニズムを、バックスペースメカニズムと呼び、それは、接続構築の信頼性を最大化しうる。実際の適用において、バックスペースの番号または所定のタイムスパン制限は、ホップバイホップ問い合わせ効率を保証するために、前もってセットされうる。

前記は、本実施形態のホップバイホップルーティング方法を導入することによる、シグナリングルートパスの構築手順を述べる。また、この方法の原理およびメカニズムは、その管理されたドメインにおける所定のベアラネットワークリソースマネージャーのドメイン内ルーティングに適用可能であり、唯一の違いは、各ベアラネットワークリソースマネージャーが、独立して、ベアラネットワークリソースマネージャー間のメッセージ相互作用を導入することよりむしろ、そのドメイン内ルーティングを達成することである。ベアラネットワークリソースマネージャーにより管理されたドメインにおいて、各ＣＮは、その特有のルーティングテーブルを保存する。したがって、本実施形態により提供された方法において、各ベアラネットワークリソースマネージャーは、そのドメインにおいて、ＣＮ毎にルーティングテーブルをシミュレーション、すなわち、ベアラネットワークリソースマネージャーが、ＣＮにより保存されたルーティング情報を得、それ自体でそれを保存する。その後、ベアラネットワークリソースマネージャーは、各ＣＮのルーティングテーブルにしたがって、ドメイン内ルーティングを行なう。ドメイン内ルーティングを行ないながら、各ベアラネットワークリソースマネージャーは、ホップバイホップルーティング方法を利用して、種々のＣＮの間のルートを選択し、ＬＳＰパス集約を選択して、このサービスストリームを搬送しうる。

図１１は、本実施形態による、ベアラ制御階層におけるサービスルートパス構築のフローチャートである。具体的なステップは、下記のとおりである。

ステップ１１０１において、ドメイン内ルーティングを行なっているベアラネットワークリソースマネージャーは、それ自体がソースベアラネットワークリソースマネージャーであるかどうかを判断する。もしそうであれば、このベアラネットワークリソースマネージャーは、ＣＡから受けた接続リソース要求メッセージにおけるＩＰアドレス情報にしたがって、そのドメイン内の入口ＥＲを見出し、見出された入口ＥＲを、入口ＣＮとして取得し、この入口ＥＲの情報を、検索されたルーターの集約に加える；そうでなければ、受けた接続リソース要求メッセージにおける情報にしたがって、現行ベアラネットワークリソースマネージャーは、入口ＢＲを見出し、入口ＣＮとして、見出された入り口ＢＲを取得し、この入口ＥＲの情報を、検索されたルーターの集約に加える。ここで、任意のドメイン内ＬＳＰは、入口ＣＮと出口ＣＮとを含む。

ステップ１１０２において、ドメイン内ＬＳＰは、現行入口ＣＮにしたがって、選択される。このドメイン内ＬＳＰは、ランダムに、あるいは、ユーザーアドレス、ＬＳＰ有効化状況、ルーティング優先順位、帯域幅要求などのあらゆる状況にしたがって、選択されうる。

ステップ１１０３において、他端における選択されたルーター、すなわち、出口ＣＮが、ＢＲまたは現行ベアラネットワークリソースマネージャーにより管理されたドメイン内のＥＲであるかどうかを判断し、もしそうであれば、このドメイン内ＬＳＰが、うまく選択され、ステップ１１０６が実行されるであろうし、そうでなければ、ステップ１１０４が実行されるであろう。

ステップ１１０４において、前記出口ＣＮが、検索されたルーターの前記集約に既に加えられるかどうかが判断され、もしそうであれば、前記選択されたＬＳＰの選択は、放棄され、ＬＳＰが再選択されるステップ１１０２が実行され、そうでなければ、ステップ１１０５が実行されるであろう。

ステップ１１０５において、ステップ１１０３の出口ＣＮは、入口ＣＮとして取得され、ステップ１１０２は、実行されるであろう。

ステップ１１０６において、サービスルートパスの構築手順は、達成され、現行ルーティングフローが終了されるであろう。

要約すれば、本実施形態のホップバイホップルーティング方法は、ドメイン間シグナリングルートパスとドメイン内サービスルーティングとの両方を選択するのに導入され、あるいは、本実施形態のホップバイホップルーティング方法は、シグナリングルートを選択するのに導入され、他のアルゴリズムがサービスルートを選択するのに用いられ、あるいは、本実施形態のホップバイホップルーティング方法は、サービスルートを選択するのに導入され、他のアルゴリズムがシグナリングルートを選択するのに用いられる。すなわち、本実施形態のホップバイホップルーティング方法は、ドメイン内ルートを選択するのに導入され、他のアルゴリズムがドメイン間ルートを選択するのに用いられる；逆の場合も同様である。具体的なルーティングスキームは、ネットワーク状況およびサービス要求にしたがって、決定されうる。

ホップバイホップアプリケーションおよび確認のメカニズムならびにバックスペースおよび本ルーティングスキームによる再選択方法を用いることにより、リソース割り当て信頼性が保証され、ベアラ制御階層における各ベアラネットワークリソースマネージャーによるドメイン間およびドメイン内ルーティングの成功率が改善される。このルーティング方法を導入することにより、この方法におけるバックスペースおよびメカニズムの再選択があるので、たとえ、機能不良がネットワークにおける所定のノードまたはリンクに対して起こっても、機能不良は、正確なルート情報を提供することにほんのわずかな影響を与えるに過ぎないであろう。さらに、本実施形態で提供されたホップバイホップルーティング方法は、ネットワーク構造について、特別な要求はなく、種々の複雑なネットワークを含む任意のトポロジ構造のネットワークに応用されうる。

第３の実施形態：静的ルーティング様式
本実施形態の主要なアイディアは、下記のとおりである。ルートパス情報は、ベアラネットワークリソースマネージャーにおいて、静的に、または、専用のデータベースを利用することにより、前もって設定される。ベアラネットワークリソースマネージャーは、有効化された場合、設定されたルートパス情報を獲得し、接続リソース要求または接続リソース応答を受けた後、前もって設定されたルートパス情報から正しいルートパスを選別し、ルートパスの構築および選択は、十分に分けられる。ここで、設定されたルートパス情報は、入口ルーターおよび出口ルーターを有するルーティングテーブルにおいて、それぞれ、縦列項目および横列項目として、置かれうる。テーブルは、ＥＲとＢＲとの間の関係を示すルーティングテーブルまたはＢＲ間の関係を示すものでありうる。

本実施形態において、データ送信は、図１に示されるＤｉｆｆ−ｓｅｒｖモデルに基づき、ネットワークを介して導入されうる。このモデルのベアラ制御階層におけるルートは、ベアラネットワークリソースマネージャー間のシグナリングルート、すなわち、ドメイン間ルートと、ＣＮ間のサービスルート，すなわち、ドメイン内ルートとを含む。図１に示されるように、ベアラネットワークリソースマネージャー１は、ソースベアラネットワークリソースマネージャーであり、中間ベアラネットワークリソースマネージャーと呼ばれうるベアラネットワークリソースマネージャー２は、ベアラネットワークリソースマネージャー１または宛先ベアラネットワークリソースマネージャー以外に、現行要求を通すベアラネットワークリソースマネージャーであり、ベアラネットワークリソースマネージャー３は、宛先ベアラネットワークリソースマネージャーである。管理ドメイン１０５、１０６および１０７は、それぞれ、ベアラネットワークリソースマネージャー１、２および３により管理される。いくつかの中間ベアラネットワークリソースマネージャーがあってもよく、なにもなくてもよい。本実施形態においては、１つのみの中間ベアラネットワークリソースマネージャーがある。

本実施形態において、ベアラネットワークリソースマネージャーにより要求されるルートパス情報が、前もって設定されべきである。ここで、ルートパス情報は、ＬＳＰ情報およびルート情報を含む。ここで、ＬＳＰ情報は、特定のパス情報を示し、ルート情報は、サービスルーティングについての制約情報の種類を示し、ＬＳＰ識別子とユーザーＩＰアドレス、フロー情報、帯域幅情報およびサービスタイプ情報それぞれとの間の対応する関係を示す。本実施形態は、主に、ＬＳＰ情報に関するので、以下、主に、ＬＳＰ情報に関して示す。

以下のように、ＬＳＰ情報を予め設定するための２つの方法がある。

１つの方法は、ベアラネットワークリソースマネージャーにおいて、ＬＳＰ情報を静的に設定すること、すなわち、ネットワーク管理者が、ベアラネットワークリソースマネージャーにおいて、ＬＳＰ情報を静的に設定することである。静的に設定されたＬＳＰ情報は、ベアラネットワークで既に構築されるＬＳＰの情報と、いまだ構築されていないＬＳＰの情報との両方を含む。ＬＳＰが構築されない場合、ベアラネットワークリソースマネージャーは、要求を、ベアラネットワークにおけるＣＮに送る。この要求を受けた後、ＣＮは、要求におけるＬＳＰ情報にしたがって、ベアラネットワークにおいて、ＬＳＰを構築し、構築の成功を示す応答を戻す；あるいは、ベアラネットワークリソースマネージャーは、この設定されたＬＳＰ情報を、ＣＮに伝送し、ＣＮは、ＬＳＰを構築し、ＬＳＰがうまく構築すれば、ＣＮは、構築の成功を示す応答を戻し、そうでなければ、ＣＮは、失敗メッセージ要求を戻し、この設定されたＬＳＰ情報を削除するであろう。

他の方法は、専用のデータベースを用いて、ＬＳＰ情報を設定することである。この方法では、専用のルートパス情報データベースを構築し、ベアラネットワークにおいて、既に構築されたＬＳＰの情報と、いまだ構築されていないＬＳＰの情報とを、構築し、ベアラネットワークにおけるＣＮによりリアルタイムに報告されたＬＳＰ情報が、受けられ、このルートパス情報データベースに保存される。

ルートパス情報データベースが、ベアラネットワークに構築されていないＬＳＰの情報を保存すると、要求を、ベアラネットワークにおけるＣＮに送るであろう。この要求を受けた後、ＣＮは、要求におけるＬＳＰ情報にしたがって、ベアラネットワークにおけるＬＳＰを構築し、構築の成功を示す応答を戻す；あるいは、ベアラネットワークリソースマネージャーは、この設定されたＬＳＰ情報をＣＮに伝送し、ＣＮは、ＬＳＰを構築し、ＬＳＰがうまく構築されれば、ＣＮは、構築の成功を示す応答を戻し；そうでなければ、ＣＮは、失敗メッセージ要求を戻し、この設定されたＬＳＰ情報を削除するであろう。

前もって設定されたＬＳＰ情報を明確に述べるために、ＬＳＰ情報の内容を、本実施形態において、マトリックステーブルの形態で、提示する。

ＬＳＰ情報は、現行ベアラネットワークリソースマネージャーのドメイン内ＬＳＰ情報と、現行ベアラネットワークリソースマネージャーとネクストホップベアラネットワークリソースマネージャーとの間のドメイン間ＬＳＰ情報とを含む。ドメイン内ＬＳＰ情報は、ドメイン内ＬＳＰマトリックステーブルに保存され、ドメイン間ＬＳＰ情報は、ドメイン間ＬＳＰマトリックステーブルに保存される。

接続リソース要求または接続リソース応答を受けた後、ベアラネットワークリソースマネージャーは、設定されたＬＳＰ情報から、ユーザーコールサービスに対する正しいＬＳＰ情報を選択し、このコールサービスに対するＬＳＰにおける帯域リソースを受ける。図１２は、ルートパス情報の構築とベアラネットワークリソースマネージャーによるリソースの割り当てとのフローを示す。図１および１２に示されるように、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでのルートパスの選択手順は、以下のとおりである。

ステップ１２０１において、ＣＡは、ユーザーにより送られた発呼要求を受け、接続リソース要求をベアラネットワークリソースマネージャー１に送る。接続リソース要求は、接続情報、ＱｏＳパラメータ、サービスタイプなどを含む。接続情報は、セッションＩＤ、発呼側パーティーのＩＰアドレスまたはドメインネームならびに着呼側パーティーのＩＰアドレスまたはドメインネームを含む。ＱｏＳパラメータは、フロー記述子および帯域幅要求情報を含む。

ステップ１２０２において、ＣＡにより送られた接続リソース要求を受けた後、ベアラネットワークリソースマネージャー１は、この接続リソース要求における発呼側パーティーのＩＰアドレスまたはドメインネームにしたがって、管理ドメイン１０５からの発呼側パーティーのＩＰアドレスまたはドメインネームに対応するＥＲを選択し、このＥＲを全ＬＳＰの入口ルーターとして取得し、入口ルーターは、一般的に、発呼末端オフィスルーターまたは発呼タンデムオフィスルーターを意味し、ここで、それは、ＥＲ１である。本実施形態において、管理１０５におけるドメイン内ＬＳＰ情報の具体的な内容は、表１に示されるマトリックステーブルからわかる。ここで、ＥＲ３およびＢＲ５は、図１に提示されない。

表１から、入口ルーターとして、ＥＲ１を取得する３つのＬＳＰ：ＬＳＰａ、ＬＳＰ１およびＬＳＰがあり、それから１つを、負荷分割原理、ポーリング様式、またはサービス要求により設定された優先順位を利用すること、を含む、特定の方法により選択するであろうことがわかる。ここで、負荷分割原理は、全ＬＳＰの負荷を均等にし、負荷のないＬＳＰを優先的に選択することを意味する；ポーリング様式は、順に、選択可能なＬＳＰを選択することを意味する；サービス要求により設定された優先順位の利用は、サービス優先順位に基づく特別の要求にしたがって、対応するＬＳＰを選択することを意味する。

ＬＳＰ１が選択され、ＬＳＰ１の出口ルーターがＢＲ１であると仮定する；帯域リソースは、接続リソース要求におけるＱｏＳパラメータにしたがって、ＬＳＰ１に予約される。

ベアラネットワークリソースマネージャー１は、管理ドメイン１０５と１０６との間のドメイン間ＬＳＰの入口ルーターとして、ＢＲ１を取得し、ＢＲ６およびＢＲ７が図１に示されないものである表２に示されるドメイン内ＬＳＰマトリックステーブルから管理ドメイン１０５と１０６との間のドメイン間ＬＳＰを選択する。このドメイン間ＬＳＰマトリックステーブルおよびドメイン内ＬＳＰマトリックステーブルは、１つの表に組み込まれうる。

表２から、入口ルーターとして、ＢＲ１を取得する２つのＬＳＰ：ＬＳＰ３およびＬＳＰ１０があり、負荷分割原理、またはポーリング様式、またはサービス要求により設定された優先順位を導入することにより、対応するＬＳＰが選択されることがわかる。ＬＳＰ３が選択され、ＬＳＰ３の出口ルーターがＢＲ２であると仮定し、所定の帯域リソースが接続リソース要求におけるＱｏＳパラメータにしたがって、ＬＳＰ３に予約される。

ステップ１２０３において、ベアラネットワークリソースマネージャー１は、接続リソース要求をベアラネットワークリソースマネージャー２に送る。接続リソース要求は、オリジナルのＱｏＳパラメータ、サービスタイプおよび接続情報が含まれる。ここで、接続情報は、ベアラネットワークリソースマネージャー２のアドレスおよびＢＲ２のものをさらに含む。

ステップ１２０４において、ベアラネットワークリソースマネージャー２は、ベアラネットワークリソースマネージャー１により送られた接続リソース要求を受け、管理ドメイン１０６のドメイン内ＬＳＰの入口ルーターとして、この接続リソース要求におけるＢＲ２を取得し、ベアラネットワークリソースマネージャー２のドメイン内ＬＳＰマトリックステーブルから、管理ドメイン１０６のドメイン内ＬＳＰを、ステップ１２０２において用いられるものと同じ方法により選択する。ＬＳＰ１６が、選択され、ＬＳＰ１６の出口ルーターがＢＲ３であると仮定し、ある帯域リソースが、接続リソース要求のＱｏＳパラメータにしたがって、ＬＳＰ１６に予約される。

ベアラネットワークリソースマネージャー２は、管理ドメイン１０６と１０７との間のドメイン間ＬＳＰの入口ルーターとして、ＢＲ３を取得し、ベアラネットワークリソースマネージャー２のドメイン間ＬＳＰマトリックステーブルから、ステップ１２０２において用いられるのと同じ方法により、管理ドメイン１０６と１０７との間のドメイン間ＬＳＰを選択する。ＬＳＰ１７が選択され、ＬＳＰ１７の出口ルーターがＢＲ４であると仮定し、ある帯域リソースが、接続リソース要求におけるＱｏＳパラメータにしたがって、ＬＳＰ１７に予約される。

ステップ１２０５において、ベアラネットワークリソースマネージャー２は、接続リソース要求を、ベアラネットワークリソースマネージャー３に送る。接続リソース要求は、元のＱｏＳパラメータ、サービスタイプおよび接続情報を含む。ここで、接続情報は、ベアラネットワークリソースマネージャー３のアドレスおよびＢＲ４のアドレスをさらに含む。

ステップ１２０６において、ベアラネットワークリソースマネージャー３は、ベアラネットワークリソースマネージャー２により送られた接続リソース要求を受け、この接続リソース要求のＢＲ４を、管理ドメイン１０７のドメイン内ＬＳＰの入口ルーターとして取得し、ついで、管理１０７における着呼側パーティーのＩＰアドレスまたはドメインネームに対応するＥＲを選択し、このＥＲを、全ＬＳＰの出口ルーターとして取得する、該出口ルーターは、一般的に、着呼末端オフィスルーターまたは着呼タンデムオフィスルーターをいい、ここで、それは、ＥＲ２である。ベアラネットワークリソースマネージャー３は、管理ドメイン１０７のドメイン内ＬＳＰの出口ルーターとして、ＥＲ２を選択し、ベアラネットワークリソースマネージャー３のドメイン内ＬＳＰマトリックステーブルから、ステップ１２０２において用いられるものと同じ方法により、管理ドメイン１０７のドメイン内ＬＳＰを選択する。ＬＳＰ１８を選択すると仮定すると、ある帯域リソースは、接続リソース要求におけるＱｏＳパラメータにしたがって、ＬＳＰ１８に予約される。

ステップ１２０７において、ベアラネットワークリソースマネージャー３は、ＢＲ４およびＬＳＰ１８の情報を含む接続リソース応答を、ベアラネットワークリソースマネージャー２に戻す。

ステップ１２０８において、ベアラネットワークリソースマネージャー２は、ベアラネットワークリソースマネージャー３により予約された接続リソース応答を受け、この要求に対するベアラネットワークリソースマネージャー２により予約された帯域リソースを確認し、接続リソース応答を、ベアラネットワークリソースマネージャー１に送る。接続リソース応答は、ベアラネットワークリソースマネージャー３により戻された接続リソース応答におけるＢＲ２の情報、ＬＳＰ１８の情報、ベアラネットワークリソースマネージャー２により選択されたＬＳＰ１６およびＬＳＰ１７の情報を含む。

ステップ１２０９において、ベアラネットワークリソースマネージャー１は、ベアラネットワークリソースマネージャー２により戻された接続リソース応答を受け、ベアラネットワークリソースマネージャー１によりこの要求に対して予約された帯域リソースを確認し、この要求に対するＬＳＰパス集約の選択を達成する。ＬＳＰパス集約は、ベアラネットワークリソースマネージャー１により受けられた接続リソース応答におけるＬＳＰ１８、ＬＳＰ１７およびＬＳＰ１６、ベアラネットワークリソースマネージャー１により選択されたＬＳＰ３およびＬＳＰ１を含む。ついで、ベアラネットワークリソースマネージャー１は、ストリームマッピングコマンドにより、このＬＳＰパス集約ならびに接続リソース要求における接続情報およびＱｏＳパラメータをＥＲ１に伝送し、リソース割り当てを達成し、ＥＲ１が、現行コールに対して、ベアラ制御ネットワークにより割り当てられたＬＳＰ情報を得る。

図１３に示されるように、ＥＲ１は、現行コールのＬＳＰ情報１３０１を獲得し、ここで、情報１３０１は、ＬＳＰ１、ＬＳＰ２、ＬＳＰ３、ＬＳＰ４およびＬＳＰ５を含む。前記ステップで選択されたＬＳＰは、ＬＳＰ１を介してＥＲ１からＢＲ１までである。ＬＳＰ１のラベル情報は、ＬＳＰ１’に変更されるとともにＬＳＰがコアルーター１３０３を通り、ＢＲ１に達するＬＳＰ情報１３０２は、ＬＳＰ２、ＬＳＰ３、ＬＳＰ４およびＬＳＰ５を含む。その後、ＬＳＰは、ＬＳＰ２を介してＢＲ１からＢＲ２に移動し、ＬＳＰ２のラベル情報が、ＬＳＰ２’に変更されるとともに、ＬＳＰは、コアルーター１３０４を通る。ＢＲ１に達するＬＳＰ情報１３０３は、ＬＳＰ３、ＬＳＰ４およびＬＳＰ５を含む。残りは、アナロジーにより推定されてもよく、すなわち、ＬＳＰが、その後、ＬＳＰ３を介してＢＲ２からＢＲ３まで移動し、ついで、ＬＳＰ４を介してＢＲ４に移動し、最後に、ＬＳＰ５を介してＥＲ２に移動する。このように、発呼側パーティーは、このＬＳＰを通って、情報を着呼側パーティーに送りうる。

ステップ１２１０において、ＥＲ１からストリームマッピングコマンド応答を受けた後、ベアラネットワークリソースマネージャー１は、接続リソース応答を、ＣＡに送り、ＬＳＰ情報の獲得の成功およびリソース割り当ての成功を示す。

図１４は、本実施形態による、ＬＳＰ情報の設定とベアラネットワークリソースマネージャーによるリソースの割り当てとの別のフローを示す。このフローにおいて、特定の方法は、図１２に示されるものと類似し、唯一の違いは、ベアラネットワークリソースマネージャーが最初にドメイン間ＬＳＰを選択し、ついで、接続リソース応答を受けた後、ドメイン内ＬＳＰを選択することである。したがって、このフローのステップは、図１４に示されるように、簡単に示されるであろうし、このルーティング手順は、以下のとおりである。

ステップ１４０１において、ＣＡは、接続リソース要求を、ベアラネットワークリソースマネージャー１に送る。

ステップ１４０２において、ベアラネットワークリソースマネージャー１は、管理ドメイン１０５と１０６との間のドメイン間ＬＳＰを選択する。

ステップ１４０３において、ベアラネットワークリソースマネージャー１は、接続リソース要求をベアラネットワークリソースマネージャー２に送る。

ステップ１４０４において、ベアラネットワークリソースマネージャー２は、管理ドメイン１０６と１０７との間のドメイン間ＬＳＰを選択する。

ステップ１４０５において、ベアラネットワークリソースマネージャー２は、接続リソース要求を、ベアラネットワークリソースマネージャー３に送る。

ステップ１４０６において、ベアラネットワークリソースマネージャー３は、ドメイン内ＬＳＰマトリックステーブルから、管理ドメイン１０７のドメイン内ＬＳＰを選択する。

ステップ１４０７において、ベアラネットワークリソースマネージャー３は、接続リソース応答をベアラネットワークリソースマネージャー２に戻す。

ステップ１４０８において、ベアラネットワークリソースマネージャー２は、ドメイン内ＬＳＰマトリックステーブルから、管理ドメイン１０６のドメイン内ＬＳＰを選択する。

ステップ１４０９において、ベアラネットワークリソースマネージャー２は、接続リソース応答を、ベアラネットワークリソースマネージャー１に戻す。

ステップ１４１０において、ベアラネットワークリソースマネージャー１は、ドメイン内ＬＳＰマトリックステーブルから、管理ドメイン１０５のドメイン内ＬＳＰを選択し、全ＬＳＰパス集約ならびに接続リソース要求における接続情報およびＱｏＳパラメータを、入口ルーターに伝送し、リソース割り当てを達成する。

ステップ１４１１において、ベアラネットワークリソースマネージャー１は、接続リソース応答を、ＣＡに戻す。

本実施形態において、ベアラネットワークリソースマネージャーにより要求されたＬＳＰ情報が、前もって設定されるのでベアラネットワークリソースマネージャーがＬＳＰを選択する場合、またはクライアントコールサービスに対するＬＳＰおよび帯域リソースを割り当てる場合、ベアラネットワークリソースマネージャーからのＬＳＰ情報を直接獲得し、ＬＳＰ情報から、現行コールに対する正しいＬＳＰを選択する。したがって、ＬＳＰ情報は、繰り返し用いられ得、それにより、ベアラネットワークリソースマネージャーのルーティング負荷を減少させ、ルーティング効率を増加させ、ネットワーク安定性を維持する。また、ベアラネットワークリソースマネージャーに設定されたＬＳＰ情報について優先順位の制限がないため、ルーティングおよびリソース割り当ては、柔軟に、かつ高い効率で達成されうる。

第４の実施形態：ラベル交換ルーティング様式
本スキームは、ベアラ制御階層ルートが、シグナリングベアラネットワークリソースマネージャー間のルートと、ドメイン内ルートとドメイン間ルートとを具体的に含むＣＮ間のサービスルートとを含む図１に示されるＤｉｆｆ−ｓｅｒｖモデルを採用し、データ送信を実施する。ベアラネットワークリソースマネージャーにおけるルートを決定する２つの概念がある：１つの概念は、ベアラネットワークリソースマネージャー間のルートを決定し、ネクストホップベアラネットワークリソースマネージャーを決定し、このようにして、シグナリングルートパスを構築することである；他の概念は、各ベアラネットワークリソースマネージャーは、ベアラ階層における各サービスについてルートパスを決定し、このようにして、サービスルートパスを構築することである。ここで、ＣＮは、ＥＲ、ＢＲ、および交換ルーターなどの他のルーターであってもよい。

図１５は、本ルーティング様式のベアラネットワークリソースマネージャーによりルーティングのフローチャートである。具体的なステップは、以下のとおりである。

ステップ１５００において、ＣＡは、このユーザーの宛先ＩＰアドレスまたはドメインネームを含む接続リソース要求をソースベアラネットワークリソースマネージャーに送る。

ステップ１５０１において、このＩＰアドレスまたはドメインネームにより、エンドオフィスルーター／タンデムオフィスルーターが、ＣＡにより開始されたサービスにアクセスするベアラネットワークリソースマネージャーを決定し、ソースベアラネットワークリソースマネージャーにおけるこのサービスの出口ルーターを決定する。このソースベアラネットワークリソースマネージャーのＢＲは、ＣＡにより送られた接続リソース要求におけるサービスタイプおよびサービスパラメータのような情報ならびにソースベアラネットワークリソースマネージャーにおけるルート情報にしたがって、決定されうる。このソースベアラネットワークリソースマネージャーのルート情報は、ソースベアラネットワークリソースマネージャーに前もってセットされ、保存され得、またはソースベアラネットワークリソースマネージャーにおけるＣＮにより、ソースベアラネットワークリソースマネージャーに伝えられうる。

ステップ１５０２において、ベアラネットワークリソースマネージャーは、現行ベアラネットワークリソースマネージャーとＣＡにより開始されたサービスに対するネクストホップベアラネットワークリソースマネージャーとの間でドメイン間ルーティングを行なう。現行ベアラネットワークリソースマネージャーとＣＡにより開始されたサービスについてのネクストホップベアラネットワークリソースマネージャーとの間でドメイン間ルーティングを行ないながら、利用可能なＬＳＰは、サービスのサービスタイプ、リソース利用可能状態、優先順位、設定されたルーティングストラテジーおよびＱｏＳ要求にしたがって、決定され、特定の帯域幅は、このアプリケーションについての現行ベアラネットワークリソースマネージャーにおけるこのＬＳＰに予約される。現行ベアラネットワークリソースマネージャーは、このサービスのネクストホップベアラネットワークリソースマネージャー、ＱｏＳパラメータおよびサービスタイプへのドメイン間ルートパスの入口ルーターならびにネクストホップベアラネットワークリソースマネージャーの宛先ＩＰアドレスを含む接続リソース要求を、ネクストホップベアラネットワークリソースマネージャーに送る。

ステップ１５０３において、ステップ１５０２におけるベアラネットワークリソースマネージャーのＬＳＰの選択された出口ルーターにしたがって、ネクストホップベアラネットワークリソースマネージャーの入口ルーターが決定され、このルーターの情報が、ネクストホップベアラネットワークリソースマネージャーに送られるべき接続リソース要求メッセージで伝えられる。

ステップ１５０４において、ネクストホップベアラネットワークリソースマネージャーの出口ルーターは、前ホップベアラネットワークリソースマネージャーにより送られた接続リソース要求におけるサービスタイプおよびサービスパラメータならびに現行ベアラネットワークリソースマネージャーのルート情報にしたがって決定される。このベアラネットワークリソースマネージャーが、宛先ベアラネットワークリソースマネージャー、すなわち、エンドオフィスルーター／エンドオフィスルーターであるかどうかが判断され、もしそうであれば、ステップ１５０６が、実行され、そうでなければ、ステップ１５０５が実行されるであろう。

ステップ１５０５において、このベアラネットワークリソースマネージャーは、現行ベアラネットワークリソースマネージャーとして取得され、ついで、ステップ１５０２が実行されるであろう。

ステップ１５０６において、ベアラネットワークリソースマネージャー間のドメイン間ＬＳＰルーティングが達成された後、各ベアラネットワークリソースマネージャーのドメイン内入口ルーターおよびドメイン内出口ルーターにしたがって、各ベアラネットワークリソースマネージャーのドメイン内ＬＳＰが決定され、ベアラネットワークリソースマネージャーが帯域リソースを照会し、ＬＳＰリソース情報を記録し、ついで、応答がソースベアラネットワークリソースマネージャーに届くまで、接続リソース応答により、それ自体により記録されたＬＳＰリソースおよびネクストホップベアラネットワークリソースマネージャーを、その前ホップベアラネットワークリソースマネージャーに伝達する。

ステップ１５０７において、ソースベアラネットワークリソースマネージャーは、このベアラネットワークリソースマネージャーのドメイン内ＬＳＰを、ドメイン内ルートパスとして選択し、ストリームマッピングコマンドを開始し、ＥＲセッションＩＤ、ストリーム情報、ＱｏＳパラメータ、フロー記述子ならびにソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでのこのサービスの全ＬＳＰパス集約に送り、そうして、このサービスについてのベアラネットワークリソースマネージャー間のルーティングを達成する。

本実施形態記載の方法を、ベアラネットワークリソースマネージャーのドメイン内ＬＳＰルーティングを行なうことに適用する場合、異なるルーティングアルゴリズムが採用されうる。例えば、ベアラネットワークリソースマネージャーのドメイン内ルーティングテーブルを前もってセットするステップおよびテーブルにおけるこのベアラネットワークリソースマネージャーのＢＲおよびＥＲを調べることによりＬＳＰを決定するステップを含む、ルートパスを前もって算出する方法が採用されうる；所定のドメイン内ＣＮから他のＣＮまでＬＳＰを選択するステップおよびこのＬＳＰの出口ルーターがこの管理ドメイン内の所定のＢＲであるまでこの手順を繰り返すステップを含む、ホップバイホップルートアルゴリズムが採用されうる；ベアラネットワークリソースマネージャーのドメイン内ルーティングテーブルを前もってセットするステップおよびテーブルのこのベアラネットワークリソースマネージャーのＢＲを調べることによりＬＳＰを決定するステップを含む、マトリックスルートアルゴリズムが採用されうる。また、Ｄｉｊａｋｓｔｒａアルゴリズム、Ｂｅｌｌｍａｎ−Ｆｏｒｄアルゴリズムまたは静的設定アルゴリズムも採用されうる。

本実施形態記載の方法をベアラネットワークリソースマネージャーのドメイン間ルーティングを行なうことに適用する場合、種々のルートアルゴリズムが採用されうる。例えば、所定のドメイン間ＢＲから他のＣＮまでのＬＳＰを選択するステップおよびこのＬＳＰの出口ルーターが所定のベアラネットワークリソースマネージャーＢＲであるまで、この手順を繰り返すステップを含む、ホップバイホップルートアルゴリズムが採用されうる。

ベアラネットワークリソースマネージャーについてのドメイン内ルーティングおよびドメイン間ルーティングは独立するが、これらも分けられず、すなわち、接続リソース要求を受けた後、ベアラネットワークリソースマネージャーは、このベアラネットワークリソースマネージャーのドメイン内ＬＳＰを決定するだけでなく、それ自体とネクストホップベアラネットワークリソースマネージャーとの間のドメイン間ＬＳＰを決定する必要がある。

本実施態様のルーティング方法が、具体例およびベアラネットワークリソースマネージャーによるルーティングを示す概念図である図５を参照して説明される。

ベアラネットワークリソースマネージャー１のドメインに、ＥＲ１、ＥＲ２、ＢＲ１およびＢＲ２があり、ベアラネットワークリソースマネージャー２のドメインに、ＢＲ３、ＢＲ４、ＥＲ３およびＥＲ４があり、他のＣＮ（図５に示さず）ならびにベアラネットワークリソースマネージャー１および２の両方のドメインにおける中間のＬＳＰ（図５に示さず）がある。ベアラネットワークリソースマネージャー１と２との間のルートは、ＬＳＰ１１、ＬＳＰ１２、ＬＳＰ１３およびＬＳＰ１４を含む。

ＣＡにより送られた接続リソース要求を１０．１．０．０／１６のＩＰアドレスで受ける場合、ベアラネットワークリソースマネージャー１は、この要求のＩＰアドレスにしたがって、ＥＲ１として入口ルーターを決定し、ついで、宛先アドレス、サービスタイプおよびこの接続リソース要求のサービスパラメータにしたがって、ＢＲ１として出口ルーターを決定する。サービスパラメータは、帯域幅要求、優先順位などを含んでもよい。ベアラネットワークリソースマネージャー１は、サービスタイプ、リソース利用可能状態、優先順位、設定されたルーティングストラテジーおよびＣＡにより開始されたこのサービスのＱｏＳ要求によりＬＳＰ１１およびＬＳＰ２２の両方が、ベアラネットワークリソースマネージャー２に達しうることを検出する場合、利用可能なＬＳＰを決定し、それを記録し、例えば、ＬＳＰ１１が、ＢＲ１からＢＲ３までのドメイン間ルートパスとして選択され、したがって、ベアラネットワークリソースマネージャー２の入口ルーターが、ＢＲ３として決定される。ベアラネットワークリソースマネージャー１は、接続リソース要求を、ベアラネットワークリソースマネージャー２に送り、ベアラネットワークリソースマネージャー２は、その出口ルーターが、それ自体のルート情報によるＥＲ４であることを学ぶ。その後、ベアラネットワークリソースマネージャー１は、ＥＲ１およびＢＲ１によりＬＳＰを選択し、ＬＳＰを記録し、ベアラネットワークリソースマネージャー２は、ＢＲ３と要求におけるサービスの宛先アドレスとにより、ＬＳＰのドメイン内ルートパス、例えば、ＥＲ４を選択する。最後に、ベアラネットワークリソースマネージャー２は、ベアラネットワークリソースマネージャー２のドメイン内ＬＳＰを含む接続リソース応答を、ベアラネットワークリソースマネージャー１に戻し、ベアラネットワークリソースマネージャー１、すなわち、ソースベアラネットワークリソースマネージャーが、このＣＡのサービスルートパスを取得し、このＣＡに対するベアラネットワークリソースマネージャーの間のルーティングを達成しうる。

本実施態様で提供された方法は、ベアラネットワークリソースマネージャーの間のドメイン間ルートが、最初に決定され、ついで、ベアラネットワークリソースマネージャーのドメイン内ルートが選択される、複雑な構造のネットワーク応用可能である。ベアラネットワークリソースマネージャーのドメイン内ルーティングおよびドメイン間ルーティングは、データがベアラネットワークリソースマネージャー間で、よく伝送されることならびにベアラネットワークリソースマネージャーのネットワークリソースが、より高いルーティング成功率で、簡単な実装かつ簡便な維持で、合理的に用いられることを保証するように、それぞれ、実際の状況により種々のルーティングアルゴリズムで行なわれうる。

第５の実施態様：仮想宛先ユーザーアドレスセグメントを伴うルーティング様式
一般的に、独立オペレーションネットワークにおけるボーダールーターがある。ボーダールーターは、他の独立オペレーションネットワークのボーダールーターと連結し、独立オペレーションネットワークの間の相互接続を実現するのに用いられる。独立オペレーションネットワークが構築される場合、本実施形態において、宛先ユーザーアドレスセグメント情報クロス独立オペレーションネットワークを有する仮想宛先ユーザーが、ベアラネットワークリソースマネージャーで前もって設定される。このベアラネットワークリソースマネージャーは、現行独立オペレーションネットワークにおけるボーダールーターを管理し、前もってセットされた仮想宛先ユーザーは、ボーダールーターと結び付けられる。一方では、現実の宛先ユーザーへのルートが、宛先独立オペレーションネットワークのゲートウェイで構築され、この宛先独立オペレーションネットワークのゲートウェイが、現行リソースマネージャーのこのボーダールーターに連結される。

独立オペレーションネットワークにおける多数のボーダールーターが存在し得、そのため、仮想宛先ユーザーおよび対応するボーダールーターが、互いに結び付けられる必要があり、対応するボーダールーターが、現実の宛先ユーザーを管理する宛先独立オペレーションネットワークのゲートウェイに連結される。このようにして、現行独立オペレーションネットワークのリソースマネージャーは、サービスクロス独立オペレーションネットワークの伝送された宛先アドレスにより、現行独立オペレーションネットワークの仮想宛先ユーザーを決定することができ、そのようにして、この仮想宛先ユーザーに連結されるボーダールーターを決定し、サービスを送るユーザーからこのボーダールーターまでの現行独立オペレーションネットワークにおけるルートを割り当てる。

本実施形態において、仮想宛先ユーザーによりセットされた宛先ユーザーアドレスセグメントは、１つのアドレスまたはアドレスのセグメントのいずれかでありうる。

ベアラ制御階層におけるベアラネットワークリソースマネージャーが、サービスサーバーを介した現行独立オペレーションネットワークのユーザーにより送られた接続リソース要求クロス独立オペレーションネットワークを受ける場合、この独立オペレーションネットワークのベアラネットワークリソースマネージャーは、この要求におけるサービスの宛先アドレスにより、このサービスが仮想宛先ユーザーに送られるべきであることを決定し、そうして、この独立オペレーションネットワークとこのサービスが送られる仮想宛先ユーザーとを結び付けるボーダールーターを得る。ＱｏＳプロパティー、宛先アドレスおよび送信元アドレスによれば、ベアラネットワークリソースマネージャーは、要求を送るユーザーからこのボーダールーターまでのこの独立オペレーションネットワークのベアラ階層において、ネットワークリソースおよびルートを割り当て、このサービスは、この独立オペレーションネットワークのベアラ階層における割り当てられたネットワークリソースおよびルートにより、現行独立オペレーションネットワークのこのボーダールーターに伝送される。現行独立オペレーションネットワークのこのボーダールーターは、このサービスを、宛先独立オペレーションネットワークのゲートウェイに伝え、宛先独立オペレーションネットワークのゲートウェイは、このサービスを、前もってセットされたルートにより、現実の宛先ユーザーに伝える。

現行独立オペレーションネットワークのボーダールーターが多数の独立オペレーションネットワークのボーダールーターに連結される場合、宛先ユーザーのアドレスセグメント情報と宛先ネットワークのゲートウェイとの間の対応する関係のテーブルが、先行技術における現行独立オペレーションネットワークのボーダールーターに前もってセットされるため、現行独立オペレーションネットワークのボーダールーターは、サービスの宛先アドレスにより、このテーブルを調べ、このサービスが送られるべきである宛先独立オペレーションネットワークのゲートウェイを決定し、ついで、このサービスを、宛先独立オペレーションネットワークの決定されたゲートウェイに送る。

宛先独立オペレーションネットワークがＱｏＳ保証を有するベアラネットワークである場合、宛先独立オペレーションネットワークにおけるゲートウェイは、ボーダールーターである。他方、ボーダールーターから宛先ユーザーまでのルートが宛先独立オペレーションネットワークに前もって設定されないが、ベアラ制御階層は、宛先アドレスとボーダールーターにより伝えられるべきサービスのＱｏＳパラメータとにより、ルーティングを行ない、宛先独立オペレーションネットワークの現行状況により、ベアラリソースおよびルートを割り当て、ついで、ボーダールーターは、この割り当てられたベアラリソースおよびルートにより、このサービスを、宛先ユーザーに伝える。

このルート選択スキームは、具体的な実施形態および本ルーティングスキームによるルーティングクロス独立オペレーションネットワークを実行するためのネットワーク構造を示す概念図である図１６を参照して、説明される。ここで、現行独立オペレーションネットワークおよび宛先独立オペレーションネットワークの両方は、ＱｏＳ保証のものである。図１６に示されるように、現行独立オペレーションネットワークのユーザー１が、データを宛先ネットワークのユーザー２に伝えると仮定すると、現行独立オペレーションネットワークのベアラネットワークリソースマネージャー１および２は、リソース割り当ておよび現行独立オペレーションネットワークのベアラ階層のルーティングを制御し、宛先独立オペレーションネットワークのベアラネットワークリソースマネージャー３は、リソース割り当てと宛先独立オペレーションネットワークのベアラ階層のルーティングとを制御する。ユーザー１は、現行独立オペレーションネットワークのボーダールーターＥＲ１ならびにサービスサーバーＣＡ１に連結され、宛先ユーザークロス独立オペレーションネットワークの仮想ユーザー２は、現行独立オペレーションネットワークのベアラネットワークリソースマネージャー２にセットされ、ＢＲ１と結び付けられる。ベアラネットワークリソースマネージャー２は、セットされた仮想ユーザー２によりＢＲ１を制御し、ＢＲ１は、宛先独立オペレーションネットワークのＥＲ２に連結され、宛先独立オペレーションネットワークにおける現実のユーザー２は、ＥＲ３およびＣＡ２の両方に連結され、ＣＡ１は、ＣＡ２に連結される。

図１７に示されるように、図１６に示されるネットワーク構造を採用することにより、ルーティングクロス独立オペレーションネットワークを実施する手順は、ユーザー１がサービスをユーザー２に送るとすれば、以下のステップを含む。

ステップ１７００において、ユーザー１は、ＱｏＳパラメータ、送信元アドレス、このサービスの宛先アドレスなどの情報を含む接続リソース要求を、ＣＡ１を介してベアラネットワークリソースマネージャー１に送る。

ステップ１７０１において、この要求を受けた後、ベアラネットワークリソースマネージャー１は、現行独立オペレーションネットワークにおいて、他のベアラネットワークリソースマネージャーと交渉し、この要求に含まれる宛先アドレスが、現行独立オペレーションネットワークにより管理されるアドレスであるかどうかを判断し、もしそうであれば、ステップ１７０２を実行し、そうでなければ、ステップ１７０３を実行するであろう。ここで、現行独立オペレーションネットワークにおける他のベアラネットワークリソースマネージャーと交渉するベアラネットワークリソースマネージャー１の手順は、ベアラネットワークリソースマネージャー１と２との間の交渉であり得、交渉は、先行技術の任意の技術で実行されうる。

ステップ１７０２において、ＱｏＳパラメータの情報によれば、このサービスの送信元アドレスおよび宛先アドレス、現行独立オペレーションネットワークにおけるベアラネットワークリソースマネージャー１および他のベアラネットワークリソースマネージャーは、このサービスについて、ベアラ階層リソースおよびルートを割り当てユーザー１により送られたサービスは、割り当てられたベアラ階層リソースおよびベアラ階層を通したルートにしたがい、宛先アドレスのユーザーに転相される。

ステップ１７０３において、この宛先アドレスが、他の独立オペレーションネットワークにより管理される場合、現行独立オペレーションネットワークにおけるベアラネットワークリソースマネージャー１および他のベアラネットワークリソースマネージャーは、ＱｏＳパラメータ、このサービスの送信元アドレスおよび宛先アドレスにしたがい、前もってセットされた仮想ユーザー２を決定し、そうして、仮想ユーザー２に結び付けられ、このサービスが送られる現行独立オペレーションネットワークのボーダールーターＢＲ１を決定し、この要求を、このサービスのボーダールーターＢＲ１に送るユーザー１間の現行独立オペレーションネットワークにおいて、ベアラ階層リソースおよびルートを割り当てる。

前もってセットされた仮想ユーザー２を決定する手順は、このサービスの宛先アドレスが仮想ＥＲ２のアドレスセグメントにあるかどうかを判断するステップを含んでもよい。

ステップ１７０４において、現行独立オペレーションネットワークのルーティングが、終わった後、現行独立オペレーションネットワークのボーダールーターＢＲ１から宛先独立オペレーションネットワークのボーダールーターＢＲ２までのルートが、前もってセットされた対応の関係テーブルにしたがって、決定され、最後に、ＣＡ１がサービスリソース要求をＣＡ２に送る。サービスリソース要求が、宛先独立オペレーションネットワークのベアラネットワークリソースマネージャー３に転送され、ついで、ベアラネットワークリソースマネージャー３は、ＱｏＳパラメータ、送信元アドレスおよびこのサービスのＥＲ２のネットワークセグメント情報にしたがって、ネットワークリソースおよび宛先独立オペレーションネットワークにおけるＥＲ２からユーザー２までのルートを割り当てる。

ステップ１７０５において、ベアラ階層リソースおよびこの要求を送るユーザーからステップ１７０４において割り当てられたボーダールーターＢＲ１までのルートであり宛先独立オペレーションネットワークのＥＲ２に対する現行独立オペレーションネットワークのＢＲ１とベアラ階層リソースおよびエッジルーターＥＲ２から、宛先独立オペレーションネットワークにより割り当てられた宛先ユーザーユーザー２までのルートとの間にセットされたルートにしたがって、ユーザー１により送られたサービスは、ベアラ階層における現行独立オペレーションネットワークのボーダールーターＢＲ１および宛先独立オペレーションネットワークのＥＲ２を介して、宛先ユーザー２に転送される。

宛先独立オペレーションネットワークは、ＩＰネットワークなどの、ＱｏＳ保証のない他のネットワークでもありうる。この場合、宛先独立オペレーションネットワークに送られたサービスは、宛先独立オペレーションネットワークそれ自体によりセットされたルートにしたがって、宛先ユーザーに転送される。

本実施形態で提供された方法は、ベアラ制御階層におけるＱｏＳ保証とのコミュニケーションパスを構築することができ、異なる独立オペレーションネットワークのトポロジ構造を遮蔽することができ、そうして、ＱｏＳ保証クロス独立オペレーションネットワークを有するサービスの送信を現実化する。

本実施形態において、アドレスセグメント情報を有する仮想宛先ユーザーは、現行独立オペレーションネットワークのリソースマネージャーにセットされる。現行独立オペレーションネットワークのユーザーが、サービスを、他の独立オペレーションネットワークの宛先ユーザーに送る場合、現行独立オペレーションネットワークのリソースマネージャーは、サービスで送られた宛先アドレスにしたがい、仮想宛先ユーザーを決定し、ついで、ＱｏＳパラメータ、送信元アドレスおよびこのサービスの宛先アドレスにしたがって、リソースマネージャーは、ルートおよびベアラリソースを、このサービスについて仮想宛先ユーザーに割り当てることができる。ついで、このサービスを割り当てられたルートおよびベアラリソースにしたがって、仮想宛先ユーザーに伝送し、仮想宛先ユーザーのネットワークセグメント情報を有するボーダールーターは、このサービスを、宛先独立オペレーションネットワークのゲートウェイに伝送し、宛先独立オペレーションネットワークのゲートウェイは、前もってセットされたルートにしたがって、このサービスを、現実の宛先ユーザーに伝送する。したがって、ＱｏＳ保証クロス独立オペレーションネットワークのサービスのルーティングは、本実施形態により、現実化されうる。

第６の実施形態：Ｅ．１６４アドレス指定とＩＰルートアドレス指定との組み合わせ
ＩＰアドレスルート様式は、ＩＰパケットに含まれる宛先ＩＰアドレスであり、インターネットに連結された各ホストコンピュータに割り当てられた独自のアドレスである宛先ＩＰアドレスを通してアドレス指定を行なうことである。図１８は、ＩＰｖ４のＩＰデータグラムフォーマットを示し、図１８に示されるように、ＩＰデータグラムは、ヘッドとデータとから構成される。ＩＰｖ４について、ヘッドの４バイトは、宛先ステーションのＩＰアドレスを示すのに用いられ、ＩＰルートは、アドレス指定についての宛先ステーションのこのＩＰアドレスを単に用い、ここで、まず、ネットワークが、宛先ステーションのＩＰアドレスにおけるネット−ＩＤにしたがって、見いだされ、ついで、ホストが、ホスト−ＩＤにしたがって、見出される。

ベアラ制御階層を有するネットワークにおけるＩＰアドレス様式を用いることにより、ベアラネットワークにおけるベアラパスをアドレス指定する方法は、ベアラ制御サーバーのＩＰアドレスにしたがって、アドレス指定する正確な方法である。保存されたルート情報は、一般的に、アドレス指定する宛先としてＩＰアドレスを有するＩＰルーティングテーブル情報であり、ルーティングテーブルは、ベアラネットワークベアラパスを選択するのに用いられる。

ＩＰアドレス構造は、インターネット上のアドレスを便利にさせるが、ＩＰアドレスは、ホストの位置に関する任意の地理学的な情報を反映できない。現行ネットワークは、地理学的な位置に関して全て構築され、現行ネットワークにおけるＩＰルーティングテーブルの番号は、ネットワークセグメントに関してＩＰアドレスを組み合わせる機能を示すＩＰアドレスの集約程度に依存する。ＩＰアドレス集約の機能は、新たなＩＰセグメントが加えられるにつれてだんだん弱くなり、ＩＰルーティングテーブルの番号の増加は、ＩＰルート安定性を弱くさせ、タイムスパンおよびＩＰルートアドレス指定の困難性を増加させるであろう。

Ｅ．１６４は、現行テレコミュニケーションネットワークにおけるラベリングおよびアドレス指定様式の種類であり、公衆交換電話ネットワーク（ＰＳＴＮ）および総合デジタル通信ネットワーク（ＩＳＤＮ）に広く適用される。Ｅ．１６４は、ユーザー位置の地理的情報を含むユーザー番号の種類であり、現在、ＩＰネットワークに適用されない。

本ルーティングスキームのコアアイディアは、ネットワークを、多数の異なる管理エリアに分け、ルーティングに際して、異なる制御様式を採用し、具体的には、Ｅ．１６４アドレス指定様式にしたがって、異なる管理エリア間のルートを選択し、ＩＰルートアドレス指定様式にしたがって、管理エリア内のルートを選択することである。

図１９を参照して、本ルーティングスキームにおけるネットワークルーティング手順は、下記ステップを含む：

ステップ１９０１〜１９０２：ネットワークを、多数の異なる管理エリアに分割し、各管理エリアについて、対応するベアラ制御サーバーをセットするステップ。管理エリアは、大都市圏ネットワーク、地方の基幹ネットワークまたは国の基幹ネットワークであり得る。

ステップ１９０３：Ｅ．１６４様式にしたがって、各管理エリアについてのエリアコードをセットするステップ。

当業者に周知のように、Ｅ．１６４は、標準電話ラベリングシステムから発展し、国際テレコミュニケーションラベリングについて、特に、ＩＳＤＮ、交換マルチメガビットデータサービス（ＳＭＤＢ）およびブロードバンドＩＳＤＮにおけるラベリングについてのＩＴＵ−Ｔにより推奨される標準である。Ｅ．１６４番号は、以下の要素：国番号（１〜３桁）、エリアコード（ｎ桁）および電話番号（１５〜ｎ桁）から構成される。Ｅ．１６４番号は、地理的位置情報を含み、テレコミュニケーションネットワークは、ネットワークルートアドレス指定をつくる地理的位置にしたがって、Ｅ．１６４様式を用いて、簡便にかつ迅速に、構築される。

他の国が、同じネットワークフレームワークを採用し、相互接続を通して、クロスカントリーネットワークを構築する場合、国コードは、異なる国間のアドレス指定を容易にするように特定されうる。

１つの管理エリアは、１つのベアラ管理サーバーに対応し、そのため、ベアラ管理サーバーも、対応するラベルを有する。したがって、異なるベアラ管理サーバーをラベリングすることにより、対応する管理エリアは、対応するエリアコードを得ることができる。

ステップ１９０４：各ベアラ制御サーバーにおける対応する管理エリアコードおよび他の管理エリアを含むトポロジ関係テーブルを構築するステップ。テーブルは、宛先エリアコード、ネクストホップエリアコード、パスおよび他の情報を含み、テーブルは、ネットワーク内のこの管理エリアと他の管理エリアとの間のルート情報を保存するのに用いられる。

ステップ１９０５：各ベアラ制御サーバーにおける管理エリアの対応するエリア内ルート情報テーブルを構築するステップ。テーブルは、宛先ＩＰアドレス、ネクストホップパスおよび他の情報を含む。テーブルは、この管理エリアの設定されたルート情報を保存するのに用いられる。

ステップ１９０６：異なる管理エリアのユーザーサービスがある場合、異なる管理エリアにわたるエリア内ルーティングは、セットされたエリアコードにしたがって行なわれ、管理エリア内のエリア内ルーティングは、この管理エリア内の構築されたルート情報テーブルにしたがって行なわれる。

ステップ１９０７：同じ管理エリアのユーザーサービスがある場合、管理エリア内のエリア内ルーティングは、この管理エリア内の構築されたルート情報テーブルにしたがって、行なわれる。

ステップ１９０６におけるルート制御様式は、異なる管理エリアにおけるユーザーのコール手順を参照して、以下、詳細に述べられるであろう。

図２０に示されるように、異なる管理エリアにおけるユーザーのコール手順は、以下のステップを含む。

ステップ２００１において、発呼ユーザーは、発呼要求を、発呼ユーザーが位置する管理エリアのサービスサーバーに送る。発呼要求は、着呼ユーザーが位置する管理エリアのエリアコードと着呼ユーザー番号とを含む。

ステップ２００２において、発呼要求を受けた後、サービスサーバーは、ルート要求メッセージを、この発呼要求にしたがって、現行管理エリアの対応するベアラ制御サーバーに送る。このルート要求メッセージは、発呼ユーザーが位置付けられる管理エリアのエリアコード、発呼ユーザー番号、着呼ユーザーが位置づけられる管理エリアのエリアコードおよび着呼ユーザー番号を含む。発呼ユーザー番号および着呼ユーザー番号は、任意の他のサービスプロバイダーにより、または発呼ユーザーのＩＰアドレス、着呼ユーザーのＩＰアドレスまたは他の内部番号などの先の様式により、割り付けられうる。発呼ユーザーおよび着呼ユーザーは、同じ管理エリアにある場合、着呼ユーザーが位置づけられる管理エリアのエリアコードが省略される。

ステップ２００３において、ベアラ制御サーバーは、着呼ユーザーが、受けたルート要求メッセージにしたがって、位置づけられる管理エリアのエリアコードを得る。

ステップ２００４において、ベアラ制御サーバーは、着呼ユーザーは、現行管理エリアのユーザーであるかどうかを判断し、もしそうであれば、ステップ２００５が実行され、そうでなければ、ステップ２００６が実行されるであろう。

ステップ２００５において、ルートは、管理エリア内の構築されたルート情報テーブルにしたがって、選択され、関連したルーターは、選択されたルートにしたがって、ユーザーサービスを着呼ユーザーに転送するために通知される。

ステップ２００６において、受けたルート要求メッセージおよび保存されたトポロジ関係テーブルにしたがって、ベアラ制御サーバーは、発呼ユーザーについて、ルートを割り付け、一方では、着呼ユーザー情報のネクストホップエリアコードに対応するベアラ制御サーバーに通知し、ついで、ネクストエリアコードに対応するベアラ制御サーバーが、着呼ユーザーがこの管理エリアのユーザーであるかどうかを判断するステップ２００４に戻す。

サービスが、着呼ユーザーが位置づけられる管理エリアに送られるまで、前記ステップ２００６が繰り返され、ついで、サービスが、ステップ２００５における様式にしたがって、着呼ユーザーに送られる。

当業者に公知であるものとして、独立ベアラ制御階層を用いることにより、拡張アップデートおよびベアラネットワークのコアデバイスにおける改良が回避され、ベアラ制御の処理能力は、より強く、安全に、安定的になりうる。したがって、よりよいベアラ制御能を提供するために、現行実施形態におけるベアラ制御サーバーは、ベアラ階層から分離され得、すなわち、ベアラ制御サーバーは、独立ベアラ制御階層を構成して、ベアラネットワークルーティングにおける制御を満たす。

この方法のルーティング手順は、以下、本実施形態の具体的なアプリケーションを参照して、説明されるであろう。図２１を参照して、それぞれ、管理エリアＡ、Ｂ、ＣおよびＤである４つの管理エリアがあると仮定する。本実施形態において、ベアラネットワークリソースマネージャーは、ベアラ制御サーバーである。

まず、Ｅ．１６４様式のラベル計画は、各管理エリアについてエリアコードを割り当てることにより、これらの４つの管理エリアで行なわれ、管理エリアＡ、Ｂ、ＣおよびＤが、それぞれ、０１、０２、０３および０４として、ラベルされると仮定すると、各管理エリアは、１つのベアラ制御サーバーに対応し、サーバーが、着呼ベアラ制御サーバーＡ、Ｂ、ＣおよびＤでありうる。したがって、ベアラ制御サーバーも対応するラベルを得、ラベル設計が、ベアラ制御サーバーに際して行なわれるように思われうる。管理エリアと、これらの管理エリア間の相互作用を説明するトポロジ関係のラベルとは、ベアラ制御サーバーに保存され、例えば、ベアラ制御サーバーＡの特定の設定は、宛先エリア０４が、エリア０２および０３を経由して達成されうることを表す。エリアコードアドレス指定にしたがって、各管理エリアへのルートも、各ベアラ制御サーバーに構成され、この種のルートは、長距離エリアコードを用いて、長距離リレールーティングを行なうために、ＰＳＴＮネットワークにおける交換デバイスに用いられるルートのように作動する。本例示において、可能なラベルおよび管理エリアのトポロジ関係、すなわち、ルート設定状況は以下のとおりである：

ユーザーＳ１が、コールをユーザーＳ２に開始すると仮定する：

１）ユーザーＳ１は、着呼ユーザーＳ２の番号をダイアルし、ここで、ダイアルした番号は、ユーザーＳ２が位置づけられる管理エリアのエリアコードを含み、ダイアルフォーマットは、着呼ユーザーのエリアコード＋着呼ユーザーの番号でありうる。ここで、着呼ユーザーの番号は、先の様式にしたがって、サービスプロバイダーまたはネットワークにより割り当てられ、ＩＰアドレスまたは決められた番号「２３４５４４」または自己決定ドメインネーム「ｌｉｙｉｍｉｎｇ」などの他の内部番号でありうる。発呼ユーザーおよび着呼ユーザーが、同じ管理エリアにある場合、着呼ユーザーが位置づけられる管理エリアのエリアコードが省略されうる。

２）サービスサーバーは、ユーザー要求を解析し、受け入れることができる割合、末端の圧縮コーディングなどの２つの末端の能力を交渉し、ついで、交渉が成功した後、発呼ユーザーおよび着呼ユーザーのＩＰアドレスと、発呼ユーザーおよび着呼ユーザーがそれぞれ位置づけられる管理エリアのエリアコードとを含む、アプリケーションを、ベアラ制御サーバーＡに送る。

３）ベアラ制御サーバーＡは、まず、着管理エリアのエリアコードにしたがって、アドレス指定を行なう。本例におけるアドレス指定は、ＰＳＴＮにおける長距離エリアコードアドレス指定と同様に、管理エリア０１から管理エリア０４である。詳しくは、エリアコード０３は、エリアコード０４に対する自己記録ルートにしたがって、エリアコード０１のベアラ制御サーバーＡによりアドレス指定される；エリア０４は、宛先エリアコードにしたがって、エリア０３のベアラ制御サーバーによりアドレス指定され、ソースエリアコードから宛先エリアコードまでアドレス指定され、ソースエリアから宛先エリアまでのパスは、それに応じて、選択され、現行の選択されたパスが、「ＬＳＰａ１／ＬＳＰａｃ／ＬＳＰｃｄ」であることを仮定する。

４）ベアラ制御サーバーＤは、着呼ユーザーのＩＰアドレスにしたがって、それぞれの管理エリアにおけるアドレス指定を行なう。そうして、Ｅ２がアドレス指定される。

したがって、現行の選択されたパスは、「ＬＳＰａ１／ＬＳＰａｃ／ＬＳＰｃｄ／ＬＳＰｄ１」である。

５）現行サービスについてパスを選択した後、ベアラ制御階層は、このパスを、エッジルーターＥ１に送り、それが、２方向サービスストリームであれば、また、パスは、エッジルーターＥ２に送られるはずである。エッジルーターは、データパケットヘッダにパス情報を入れ、ついで、エッジルーターおよび中間ルーターは、特定のパスにしたがって、サービスストリームを伝送する。

このように、サービスルーティングおよび転送の手順が達成される。

本実施形態において、ＩＰネットワークによるＥ．１６４アドレス指定様式を統合することにより、ベアラネットワークにおけるベアラパスを選択する手順の間、Ｅ．１６４とＩＰルートアドレス指定様式との両方の利点を組み合わせることにより、ベアラ制御サーバーは、同時に、Ｅ．１６４番号とＩＰアドレスとを利用し、該ベアラ制御サーバーは、Ｅ．１６４番号によりアドレス指定を通じてそれが位置づけられる管理ドメインに送り、その結果、大量のＩＰアドレスが、遮蔽され、宛先ドメインへのルーティング様式が、簡便かつ迅速になされる。ついで、ベアラ制御サーバーは、ＩＰアドレスを用いることにより、管理ドメイン内の特定のユーザーを位置づけし、現行ＩＰネットワークでＩＰアドレスを用いる種々の利点が予約される。したがって、アドレス指定は、大規模ネットワークフレームワークにおいて、より簡便かつ迅速であり、大規模ネットワークにおける複雑性および不安定性は、アドレス指定にＩＰアドレスが単に用いられる場合、克服される。一方では、ネットワークの拡張性が、増強される。

ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでの前記ルーティング手順から、エンド・ツー・エンドルーティングは、主に２つのパート：各ベアラネットワークリソースマネージャー内のドメイン内ルーティングと異なるベアラネットワークリソースマネージャー間のドメイン間ルーティングとを含むことがわかる。また、ドメイン内ルーティングまたはドメイン間ルーティングの点からみて、異なるルーティング様式、例えば、パスマトリックス様式、出口／入口ルーターＩＰ識別子様式、制約状況ルーティング様式、セッティングルーティングストラテジーなどがある。これらの様式では、いくつかは、ドメイン内ルーティングとドメイン間ルーティングとの両方に適用でき、いくつかは、ドメイン内ルーティングまたはドメイン間ルーティングのいずれかにのみ適用可能である。

各ドメイン内ルーティングまたはドメイン間ルーティングの具体的な実行手順および応用性は、Ｄｉｆｆ−ｓｅｒｖモデルの対応するネットワーク構造を参照して、以下、述べられるであろう。

第１の様式：パスマトリックステーブルを導入することによるルーティング様式
このルーティング様式は、図１に示されるＤｉｆｆ−ｓｅｒｖモデルを適用し、ネットワークにわたるデータ送信を実行する。このモデルにおいて、ベアラ制御階層ルートは、ベアラネットワークリソースマネージャーの間のシグナリングルートと、ＣＮ間のサービスルートとを含む。サービスルートは、ドメイン間ルートとドメイン内ルートとを含み、本ルーティング様式は、主に、ドメイン内ルートに関する。本方法の中心となるアイディアは、ベアラネットワークリソースマネージャーにおけるドメイン内ＣＮ間の連絡可能なパスのマトリックステーブルを構築し、維持し、このマトリックステーブルを用いて、各ベアラネットワークリソースマネージャーのドメイン内ルーティングを実行し、そうして、各ベアラネットワークリソースマネージャーのドメイン内サービスルートを決定する。ここで、ＣＮは、ＥＲ、ＢＲまたは転送ルーターなどの他のルーターでありうる。

図５を参照して、ベアラネットワークリソースマネージャー１および２は、それぞれ、都市圏ネットワーク１および２を管理し、各都市圏ネットワークは、２以上のＥＲまたはＢＲを含む。ベアラネットワークリソースマネージャー１により管理された管理ドメインを例とすると、ベアラネットワークリソースマネージャー１の管理ドメインにおける出口ルーターまたは入口ルーターとして取得されうるＥＲ１、ＥＲ２、ＢＲ１およびＢＲ２があり、また、他のドメイン内ＣＮと、それらの間のラベル交換パス（ＬＳＰ）とがある。ドメイン内サービスパスルーティングが行なわれる前、各出口と各入口との間のこれらのＬＳＰパスの集約が、このドメイン内に、前もって構築され、この構築されたパス集約にしたがって、ドメイン内ルーティングが行なわれる。本実施形態では、このＬＳＰパス集約が構築され、マトリックス様式で保存され、このＬＳＰパス集約を構築する手順は、以下のとおりである：

ステップ１１：入口または出口として取得されうるＥＲ１、ＥＲ２、ＢＲ１およびＢＲ２のいずれか１つを、入口ルーターとして、ランダムに選択するステップ。本実施形態において、ＥＲ１は、最初に、入口ルーターとして選択され、ＥＲ１の情報を、検索されたルーターの集約に加える。

ステップ１２：ＥＲ１に連結された全てのＬＳＰからＬＳＰを、繰り返さずに、選択するステップ。

ステップ１３：選択されたＬＳＰの他端のルーターが、ドメイン内ＢＲまたはＥＲであるかどうかと、このルーターの情報が、検索されたルーターの集約に含まれないかどうかを判断し、もしそうであれば、現行の検索を終わらせ、選択されたＬＳＰを記録し、ＥＲ１の他の可能なＬＳＰパスの検索が、ＥＲ１の全ての可能なＬＳＰパスが検索されるまで継続されるステップ１２に戻り、そうでなければ、現行ルーターとして選択されたＬＳＰの他端でルーターを取得し、検索されたルーターの集約におけるこのルーターの情報を記録し、ステップ１４を実行するステップ。

ステップ１４：開始点として、現行ルーターを取得する全てのＬＳＰからＬＳＰを選択し、選択されたＬＳＰの他端のルートの情報が、検索されたルーターの集約に含まれるかどうかを判断し、もしそうであれば、選択されたＬＳＰがループパスを構成することができ、ついで、選択されたＬＳＰを放棄し、ネクストＬＳＰを選択し、判断を行なうことが継続されるステップ１４に戻り、そうでなければ、ステップ１５を実行するステップ。

ステップ１５：このルーターは、現行ドメインのＢＲまたはＥＲであるかどうかを判断し、もしそうであれば、現行の検索を終わらせ、ステップ１２に戻り；そうでなければ、現行ルーターとしてこのルーターを取得し、検索されたルーターの集約におけるこのルーターの情報を記録し、検索されたＬＳＰの他端におけるルートが、ドメイン内ＢＲまたはＥＲとなるまで、検索が、開始点としてこのルーターにより継続されるステップ１４を実行することに戻る。

同様に、ステップ１１からステップ１５までの前記方法にしたがって、入口ルーターとしてのＥＲ２、ＢＲ１およびＢＲ２によるＬＳＰパスの集約が、検索により得られる。

表３に示されるように、ステップ１１からステップ１５までの前記方法により得られたＬＳＰパスの集約を、マトリックステーブルで保存する。

この表において、横項目および縦項目は、それぞれ、ベアラネットワークリソースマネージャー１のドメイン内の出口ルーターおよび入口ルーターを表す。入口ルーターテーブル項目および出口ルーターテーブル項目は、それぞれ、この管理ドメインにおける全ＥＲまたはＢＲを含み、横列と縦列との交点は、１つのＥＲ／ＢＲから他のＥＲ／ＢＲへのパス集約を示す。ステップ１１からステップ１５により得られたパス集約は、この表において対応する位置に記入され、そうして、入口ルーターと出口ルーターとの間のパス集約が、このテーブルに記録される。このテーブルにおけるパス集約は、以下の状態を有する：

１０。表３の「−」またはスペースは、入口ルーターと出口ルーターとの間に利用可能なパスがないことを意味する。

２１つのみ利用可能なパスがある。例えば、表３の｛（ＬＳＰ１）｝は、入口ルーターと出口ルーターとの間に１つのみの最適なパスがあることを意味し；表３における｛（ＬＳＰ３，ＬＳＰ４）｝は、このパスが複数のドメイン内ＬＳＰを通過することを意味する。

３多数のパスがある。例えば、表３における丸括弧により分けられた｛（ＬＳＰ５），（ＬＳＰ２，ＬＳＰ４）｝は、入口ルーターと出口ルーターとの間に多数の最適なパスがあることを意味する。

ベアラネットワークリソースマネージャー１は、表３中の前もって算出され、かつ保存されたパス集約にしたがって、ドメイン内ルーティングを行なう。本実施形態において、ベアラネットワークリソースマネージャー１は、コールに対するソースベアラネットワークリソースマネージャーであり、そのため、ベアラネットワークリソースマネージャー１は、まず、発呼側パーティーのＩＰアドレスにしたがって、入口ルーターＥＲ２を見出し、ついで、表３にクレリーを行ない、ＥＲ２からベアラネットワークリソースマネージャー２のドメインに達する可能性があるＬＳＰパス集約が、ＥＲ２からＢＲ１までのＬＳＰパス：｛（ＬＳＰ５），（ＬＳＰ２，ＬＳＰ４）｝；ＥＲ２からＢＲ２までのパス：｛（ＬＳＰ３，ＬＳＰ４）｝を含むことを見出す。

本実施形態において、ＬＳＰ５は、負荷分割またはサービスタイプ、優先順位、ローカルに設定されたルーティングストラテジー、現行ネットワーク状況および具体的なＱｏＳ要求に応じて、ベアラネットワークリソースマネージャー１のドメイン内パスとして選択される。ここで、現行ネットワーク状況は、リソース利用可能状態と現行サービスフローとを含みうる。本ルーティング様式を用いる他の実施形態では、他の状況にしたがって、前記ルーティング手順が行なわれうる。

本ルーティング様式において、Ｄｉｊａｋｓｔｒａアルゴリズム、Ｂｅｌｌｍａｎ−Ｆｏｒｄアルゴリズムまたは静的設定アルゴリズムも、前記ステップのほかにドメイン内パス集約を決定するのに用いられうる。

ベアラネットワークリソースマネージャー１におけるドメイン内ルーティングの手順が、本ルーティング様式を適用することにより達成された後、ベアラネットワークリソースマネージャー１と２との間のドメイン間ルーティングも行なわれうる。確かに、ベアラネットワークリソースマネージャー間のドメイン間ルーティングを行なうことも適用され得、ついで、ルーティング結果で決定された入口ルーターと出口ルーターとにしたがって、本ルーティング様式を適用することにより、ドメイン内ルーティングを行なう。

パスマトリックスを利用するこのルーティングスキームについて、各ベアラネットワークリソースマネージャーの実際の状況にしたがって、ドメイン内ルーティングは、前もって構築されたドメイン内パス情報を通して行なわれ得、この方法は、高スピード、簡単な実行、簡単なアプリケーション、簡単なメインテナンスおよび管理などの利点を有し、複雑なネットワークに適用するに適切である。

第２の様式：出口／入口ルーターＩＰ識別子を導入することによるルーティング様式
このルーティング様式は、図１に示されるＤｉｆｆ−ｓｅｒｖモデルを採用し、ネットワークにわたって、データ送信を実行する。このモデルにおいて、ベアラ制御階層ルートは、ベアラネットワークリソースマネージャーの間のシグナリングルートと、ＣＮ間のサービスルートとを含む。サービスルートは、ドメイン間ルートとドメイン内ルートとを含み、本ルーティング様式は、主に、ドメイン内ルートに関する。本方法の中心となるアイディアは、ベアラネットワークリソースマネージャーにおけるドメイン内ＣＮ間の連絡可能なパスのルーティングテーブルを構築し、維持し、このルーティングテーブルを用いて、ベアラ制御階層における各ベアラネットワークリソースマネージャーのドメイン内ルーティングを実行し、そうして、各ベアラネットワークリソースマネージャーのドメイン内サービスルートを決定することである。ここで、ＣＮは、ＥＲ、ＢＲまたは転送ルーターなどの他のルーターでありうる。

図５を再び参照して、ベアラネットワークリソースマネージャー１および２は、それぞれ、都会ネットワーク１および２を管理する。ベアラネットワークリソースマネージャー１により管理される管理ドメインを例としてとると、ベアラネットワークリソースマネージャー１の管理ドメインにおける出口ルーターまたは入口ルーターとして取得されうるＥＲ１、ＥＲ２、ＢＲ１およびＢＲ２がある。事実上、他のＣＮ（図５に示さず）と、ベアラネットワークリソースマネージャー１の管理ドメインにおけるそれらの間のＬＳＰ（図５に示さず）とがある。ドメイン内サービスパスルーティングが行なわれる前、各出口ルーターおよび各入口ルーターにおけるこれらのＬＳＰパスの集約は、前もって、このドメイン内に構築され、ついで、ＩＰ識別子は、全ドメイン内出口ルーターおよび入口ルーターにより管理されたＩＰアドレスセグメントにしたがって、セットされる。

本実施形態において、このＬＳＰパス集約は、ルーティングテーブルにより構築される。入口ルーターとして取得されうるＥＲ１、ＥＲ２、ＢＲ１およびＢＲ２の任意のルーターは、入口ルーターとして選択され、ＥＲ１は、本実施形態における入口ルーターとして選択される。ＬＳＰパス集約を構築する手順は、以下のステップを含む：

ステップ２１：ＩＰ１として、ベアラネットワークリソースマネージャーのＥＲ１により管理されたＩＰアドレスセグメントをセットし、ＥＲ１の情報を、検索されたルーターの集約に加えるステップ。

ステップ２２：ＥＲ１に連結された全てのＬＳＰからＬＳＰを選択するステップ。

ステップ２３：選択されたＬＳＰの他端におけるルーターが、ドメイン内ＢＲまたはＥＲであるかどうか、およびこのルーターの情報が、検索されたルーターの集約に含まれるかどうかを判断し、もしそうであれば、現行の検索を終わらせ、選択されたＬＳＰを記録し、ＥＲ１の全ての可能なＬＳＰパスが検索されるまで、ＥＲ１の他の可能なＬＳＰパスの検索が継続されるステップ２２に戻り；そうでなければ、現行ルーターとして選択されたＬＳＰの他端におけるルーターを取得し、検索されたルーターの集約におけるこのルーターの情報を記録し、ステップ２４を実行するステップ。

ステップ２４：開始点として現行ルーターを取得する全てのＬＳＰからＬＳＰを選択し、選択されたＬＳＰの他端におけるルートの情報が、検索されたルーターの集約に含まれるかどうかを判断し、もしそうであれば、選択されたＬＳＰが、ループパスを構成することができることを意味し、ついで、選択されたＬＳＰを放棄し、ネクストＬＳＰを選択し、判断を行なうことを継続するステップ２４に戻り；そうでなければ、ステップ２５を実行するステップ。

ステップ１５：このルーターが、現行ドメインのＢＲまたはＥＲであるかどうかを判断し、もしそうであれば、現行の検索を終わらせ、ステップ２２に戻り；そうでなければ、このルーターを現行ルーターとして取得し、検索されたルーターの集約におけるこのルーターの情報を記録し、検索されたＬＳＰの他端におけるルートがドメイン内ＢＲまたはＥＲとなるまで、開始点としてこのルーターにより、検索が継続されるステップ２４を実行することに戻る。

現行ルーティング様式では、Ｄｉｊａｋｓｔｒａアルゴリズム、Ｂｅｌｌｍａｎ−Ｆｏｒｄアルゴリズムまたは静的設定アルゴリズムも、前記ステップのそばのベアラネットワークリソースマネージャーのドメイン内ＬＳＰパス集約を得るのに用いられうる。

ＬＳＰパス集約を構築する前記方法にしたがって、ＥＲ２、ＢＲ１、およびＢＲ２は、それぞれ、入口ルーターとして取得され、ＥＲ２、ＢＲ１およびＢＲ２により管理されたそれぞれアドレスセグメントは、それぞれ、ＩＰ２、ＩＰ３およびＩＰ４としてセットされ、ＥＲ２の全ＬＳＰｓ、ＢＲ１およびＢＲ２が検索される。

ベアラネットワークリソースマネージャーにより管理されたＩＰアドレスセグメントは、このベアラネットワークリソースマネージャーにおけるＥＲ１、ＥＲ２、ＢＲ１およびＢＲ２に割り当てられる。識別子ＩＰ１は、ＥＲ１に、ＩＰ２は、ＥＲ２に、ＩＰ３は、ＢＲ１に、およびＩＰ４は、ＢＲ２に割り当てられる。ベアラネットワークリソースマネージャーの管理ドメインにおけるＩＰアドレスセグメントテーブルを、表４に示されるように構築した。

表４において、１０．１．０．１〜１０．１．２５５．２５５のＩＰアドレスセグメントは、ＩＰ１に、１０．２．０．１〜１０．２．２５５．２５５は、ＩＰ２に、１０．３．０．１〜１０．３．２５５．２５５は、ＩＰ３に、１０．４．０．１〜１０．４．２５５．２５５は、ＩＰ４に割り当てられる。このように、ＩＰアドレスを伴うサービスストリームは、出口ルーターのＩＰ識別子およびベアラネットワークリソースマネージャーの管理ドメイン内の入口ルーターのＩＰ識別子を見出しうる。

本ルーティング様式において、ベアラネットワークリソースマネージャーのドメイン内ＬＳＰテーブルは、構築されたＬＳＰパス集約およびＩＰの間の関係にしたがって、表５に示されるようにセットされる：

表５において、出口ルーターおよび入口ルーターのＩＰアドレスは、ＩＰ識別子により両方表され、すなわち、縦テーブル項目は、ベアラネットワークリソースマネージャーのドメイン内入口ＩＰ識別子を示し、横テーブル項目は、ベアラネットワークリソースマネージャーのドメイン内出口ＩＰ識別子を示し、このサービスストリームの出口ＩＰ識別子および入口ＩＰ識別子にしたがって、所望のＬＳＰは、テーブルのクロスポイントに見出されうる。

このサービスストリームの出口ＩＰ識別子および入口ＩＰ識別子にしたがって、表５に基づき、２つのＬＳＰを見出される場合、例えば、このサービスストリームの出口ＩＰ識別子および入口ＩＰ識別子は、それぞれ、ＩＰ３およびＩＰ２である場合、ついで、表５から、このサービスストリームは、ＬＳＰ５ルートまたは（ＬＳＰ２，ＬＳＰ４）ルートを選択できることが得られる。このルーティング様式は、負荷分割、サービスタイプ、リソース利用可能性、優先順位、ローカルに設定されたルーティングストラテジー、またはある特定のＱｏＳ要求などにしたがって、ＬＳＰを選択できる。例えば、ＬＳＰ５は、ベアラネットワークリソースマネージャーのドメイン内ルートパスとして選択される。

具体例をとって、本ルーティング様式における前記表４および表５を利用することにより、ルーティング手順を説明するであろう。

発呼ユーザーが、ＣＡを介してサービスストリームを、ベアラネットワークリソースマネージャーに送る要求を送り、発呼ユーザーのＩＰアドレスが１０．２．０．０であると仮定すると、ベアラネットワークリソースマネージャーにおけるドメイン内ルーティングの手順は、以下のとおりである：

ステップ２１０：発呼ユーザーのＩＰアドレスにしたがって、表４を調べることにより、ＩＰ２として現行サービスストリームの入口ＩＰ識別子を得るステップ。

ステップ２２０：現行サービスストリームを送信するための出口ルーターのＩＰアドレスをセットし、このＩＰアドレスにしたがって、表４を調べ、得られた出口ＩＰ識別子がＩＰ１であると仮定すると、現行サービスストリームを送信するための出口ＩＰ識別子を得るステップ。

ステップ２３０：現行サービスストリームの入口ＩＰ識別子および出口ＩＰ識別子にしたがって、表５を調べ、ＬＳＰ４である現行サービスストリームについて、ルートパスを得、そして、現行サービスストリームを、ベアラネットワークリソースマネージャーの管理ドメインにおいて、ＬＳＰ４を通して送信するステップ。

本ルーティング様式では、ＬＳＰは、直接的に、送信対象のサービスストリームの入口ルーターおよび出口ルーターにしたがってでなくＩＰ識別子にしたがって、決定される。このように、ＩＰアドレスセグメントおよびベアラネットワークリソースマネージャーにおけるＥＲまたはＢＲの間の対応する関係をセットすることが自由自在であり、したがって、サービスストリームの入口ルーターおよび出口ルーターを正確に知る必要はなく、かわりに、サービスストリームの入口ＩＰアドレスおよび出口ＩＰアドレスが十分であることを知ることが十分である。

表５を構築する場合、ベアラネットワークリソースマネージャーにより管理された各ＩＰアドレスセグメントは、所定のＥＲもしくはＢＲに対応、または多数のＢＲもしくはＥＲに対応しうる。同様に、各ＢＲまたはＥＲは、多数のＩＰアドレスセグメントに対応しうる。しかし、異なる通信様式は、表５における種々のＬＳＰに導く。

現行ルーティング様式において、ベアラネットワークリソースマネージャーの管理ドメイン内のＣＮにわたって全ＬＳＰを算出することが要求されるため、ネットワークが大規模を有する場合、表４および表５のスケールは、非常に大きいであろうし、そのため、テーブルを調べるのに便利でない。そのため、このルーティング様式は、非常に大規模でないネットワークに適用するのに適切である。

この種のルーティングスキームにおいて、出口／入口ルーターのＩＰ識別子を用いることにより、ベアラネットワークリソースマネージャーの管理ドメインにより管理されたＩＰアドレスセグメントは、このベアラネットワークリソースマネージャーの管理ドメイン内の全出口ルーターおよび入口ルーターに割り当てられ、ＩＰ識別子によりセットされ、ついで、ベアラネットワークリソースマネージャーのドメイン内ルーティングテーブルが、全出口ＩＰ識別子、入口ＩＰ識別子およびＬＳＰにしたがってセットされる。接続リソース要求を処理する場合、ＬＳＰは、ベアラネットワークリソースマネージャーのドメイン内ルーティングテーブルにしたがって、選択され、そのため、ベアラ制御階層における各ベアラネットワークリソースマネージャーのドメイン内ルーティングは、容易な実行、および簡便な維持および管理で実行される。

第３の様式：リソース制約状況にしたがうルーティング様式
この方法は、図１に示されるＤｉｆｆ−ｓｅｒｖモデルを適用して、ネットワークにわたるデータ送信を実行する。このモデルにおいて、ベアラ制御階層ルートは、ベアラネットワークリソースマネージャーの間のシグナリングルート、ならびにドメイン間ルートとドメイン内ルートとを含む、ＣＮ間のサービスルートを含む。ユーザーサービス帯域幅アプリケーションを処理する場合、ベアラ制御階層は、ユーザーサービスパスを決定し、ベアラネットワークリソースマネージャーは、特定のサービスパスにしたがって、ＥＲに通知し、サービスストリームを送るであろう。このルーティング様式の方法は、サービスルートおよびシグナリングルートに適用されうる。しかしながら、ドメイン間ネットワークトポロジが、通常、単純であるため、シグナリングルートのリソース制約を行なうことは、必要ではなく、ネットワークの管理維持コストを増加させ、このルーティング様式の実施形態は、サービスルートルーティング、すなわち、ドメイン内ルーティングを示すだけである。ここで、前記ＣＮは、ＥＲ、ＢＲまたはフォワーディングルーターなどの他のルーターであってもよい。

図２２に示されるように、本ルーティング様式の実施形態において、

のルートパスは、構築される必要がある。図２２において、破線は、サービス要求として１０Ｍ帯域幅の接続リソース要求構築パスを表す。図２３を参照して、このルーティング様式の実施形態におけるこのルートパスを構築する手順は、以下のステップを含む：

ステップ３１において、ＣＡからの発呼要求にしたがって、ベアラネットワークリソースマネージャー１は、発呼エンドオフィスルーターまたはエンドオフィスルーターとしてＥＲ１を決める。この決定された入口ルーターにしたがって、ベアラネットワークリソースマネージャー１は、１０Ｍ帯域幅要求に基づくドメイン内ＬＳＰを決定する。ドメイン内ＬＳＰを決定するベアラネットワークリソースマネージャー１の特定の手順は、以下のとおりである。

表６に示されるように、全ドメイン内パスの情報は、前もって、ベアラネットワークリソースマネージャー１に保存される。このテーブルにおけるコンテンツから、ベアラネットワークリソースマネージャー１は、発呼エンドオフィスルーターとしてＥＲ１を有する３つのＬＳＰ：ＬＳＰ１、ＬＳＰａおよびＬＳＰ３を得る。３つのＬＳＰは、それぞれ、前もって、リソース制約状況により構成され、ルーティング様式のこの実施形態におけるリソース制約状況は、帯域幅要求を参照する。詳しくは、ＬＳＰ１の全帯域幅は、５００００Ｍであり、各ストリームについての最大許容帯域幅は、５０Ｍである；ＬＳＰａの全帯域幅は、１００００Ｍであり、各ストリームの最大許容帯域幅は、１０Ｍであり；ＬＳＰ３の全帯域幅は、１０００Ｍであり、各ストリームの各最大許容の帯域幅は、１Ｍである。ＬＳＰａの各ストリームの最大許容帯域幅は、１０Ｍサービス帯域幅要求と同等の１０Ｍであるので、ベアラネットワークリソースマネージャーは、ベアラネットワークリソースマネージャー１におけるドメイン内パスとしてＬＳＰａを選択する。前記３つの選択可能なＬＳＰの間で、ＬＳＰ１の各ストリームの最大許容帯域幅は、１０Ｍサービス帯域幅要求を満たすに十分である５０Ｍであるが、リソースセービングに関して、ＬＳＰ１が適用されるのであれば、ネットワークリソースは、消耗されるであろう。したがって、ＬＳＰａは、本ルーティング様式の実施形態において、ベアラネットワークリソースマネージャー１におけるドメイン内パスとして選択される。また、ルーティング手順に際して、現行ネットワーク状況をも考慮されうる。ＬＳＰａの帯域幅が、ほとんど全体として割り付けられ、いまだ使用されていないリソースがあり、ＬＳＰ１は、つぎに選択されうる。

要するに、リソース束縛状況によるルーティング手順に際して、リソース束縛状況がサービス要求よりも少ないことは、許容できるであろう。複数の利用可能なＬＳＰがある場合、リソース消費を含む他の状況は、最適なＬＳＰを選択することを考慮にいれられてもよい。

ベアラネットワークリソースマネージャー１におけるドメイン内パスとしてＬＳＰが選択された後、ＢＲ１は、表６の内容にしたがって、ベアラネットワークリソースマネージャー１の出口ルーターとして決定される。

表６において、横項目および縦項目それぞれは、ベアラネットワークリソースマネージャー１のドメイン内の出口ルーターおよび入口ルーターを示す。入口ルーターテーブル項目および出口ルーターテーブル項目それぞれは、この管理ドメインにおける全ＥＲまたはＢＲを含み、横と縦とのクロスポイントは、一方のＥＲ／ＢＲから他方のＥＲ／ＢＲまでのパス集約を示す。このテーブルにおけるパス集約は、下記の状況を有する：

１空値。表６における「−」またはスペースは、入口ルーターと出口ルーターとの間に利用可能なパスがないことを意味する。
２１つだけ利用可能なパスがある。例えば、表６における｛（ＬＳＰ１）｝は、表６における入口ルーターと出口ルーターとの間に、１つだけ至適なパスがあることを意味する；｛（ＬＳＰ３，ＬＳＰ４）｝との間の１つのみの至適なパスは、このパスが複数のドメイン内ＬＳＰを通過することを意味する。
３多数のパスがある。例えば、表６における丸かっこにより分けられた｛（ＬＳＰ５），（ＬＳＰ２，ＬＳＰ４）｝は、入口ルーターと出口ルーターとの間の多数の至適なパスがあることを意味する。

ステップ３２において、前もってセットされたドメイン間ＬＳＰ帯域幅要求によれば、ベアラネットワークリソースマネージャー１または２はベアラネットワークリソースマネージャー１と２との間の全ドメイン間ＬＳＰから、要求を満たすＬＳＰを選択する。

詳しくは、ＢＲ１は、本ステップにおいて、すでに、ステップ３１におけるベアラネットワークリソースマネージャー１の出口ルーターとして決定されているので、開始点としてＢＲ１を有する全ドメイン間ＬＳＰが列挙される。これらのＬＳＰの帯域幅要求が得られ、１つのＬＳＰは、１０Ｍ帯域幅要求にしたがって、これらのＬＳＰから選択され、ベアラネットワークリソースマネージャー２の入口ルーターは、選択されたＬＳＰの終点にしたがって決定される。ここで、ＬＳＰ１３は、ベアラネットワークリソースマネージャー１と２との間のドメイン間ＬＳＰとして選択され、ＢＲ３は、ベアラネットワークリソースマネージャー２の入口ルーターとして決定される。

ステップ３３において、サービス帯域幅要求によれば、ベアラネットワークリソースマネージャー２は、ベアラネットワークリソースマネージャー２の全ドメイン内ＬＳＰから、サービス帯域幅要求を満たすＬＳＰを選択し、ベアラネットワークリソースマネージャー２の出口ルーターは、選択されたＬＳＰに基づき決定される。本ステップにおけるＬＳＰの選択方法は、ステップ３１におけるものと類似しており、ベアラネットワークリソースマネージャー２の決定されたドメイン内ＬＳＰは、ＬＳＰｂであり、ＢＲ４は、ＬＳＰｂに基づくベアラネットワークリソースマネージャー２の出口ルーターとして決定される。

ステップ３４において、ステップ３２におけるものと似た方法を導入することにより、ＬＳＰ２３が、ベアラネットワークリソースマネージャー２と４との間のドメイン間ＬＳＰとして決定され、ＢＲ５が、ＬＳＰ２３に基づくベアラネットワークリソースマネージャー４の入口ルーターとして決定される。そして、ステップ３１におけるものと似た方法を導入することにより、ベアラネットワークリソースマネージャー４は、ＬＳＰｃとしてベアラネットワークリソースマネージャー４のドメイン内ＬＳＰを、ＥＲ３として、ベアラネットワークリソースマネージャー４の出口ルーターを決定する。

本実施形態において、ＬＳＰ帯域幅要求情報は、各ベアラネットワークリソースマネージャーに保存される。本ルーティング様式の他の実施形態において、専用のデータベースが構築され、ＬＳＰ帯域幅要求情報を保存しうる。

本実施形態において、ルーティング手順に際して、選択可能なＬＳＰのどれもがサービス帯域幅要求を満たすことができないことが検出される場合、現行ＥＲまたはＢＲは、上流ＥＲまたはＢＲに対する、ルーティング失敗情報を含むリソース拒否応答を報告するであろう。ついで、上流ＥＲまたはＢＲを管理するベアラネットワークリソースマネージャーは、前ホップベアラネットワークリソースマネージャーまたはＣＡへ、接続リソース要求の拒否応答を報告し、それにより、この接続リソース要求は拒否される。

前記方法にしたがって、サービス帯域幅要求を満たすルートパス

が、構築されうる。現行ルーティング様式の他の実施形態では、サービス帯域幅要求は、ドメイン内ルーティングまたはドメイン間ルーティングを行なう場合、考慮されるであろう。さらに、他のサービス要求は、ルーティングに対するリソース制約状況として取得され得、例えば、リソース制約状況は、ＬＳＰにおける規則制限であってもよく、該ルールは、このＬＳＰを通すことを許容するかおよびどれが許容しないかを指定する。

本方法を適用することにより、ネットワークサービスプロバイダーは、このユーザーサービス要求にしたがって、このユーザーを委ねるように、このサービスを実行するために、関連したサービス要求により、ユーザーについての特定パスを選択できる。ネットワークプランをつくる場合、サービスプロバイダーは、サービスおよび実行要求を満たすように、適宜、将来のフローおよび制約ＬＳＰを推定できる。

したがって、本方法は、帯域幅要求にあうパスを選択し、所望の品質のサービスが、ユーザーコールが受け取られた後に達成されうるように、サービス要求に関して、リソース制約に基づくルーティングを実行する。さらに、サービスプロバイダーは、分類されたチャージングを実行し、よりよい経済パフォーマンスを得るために前もってセットされたリソース制約状況にしたがって、チャージング基準をセットしうる。この方法は、実行、維持および管理が簡単である。

第４の様式：セットルーティングストラテジーによるルーティング様式
この方法は、図１に示されるＤｉｆｆ−ｓｅｒｖモデルを適用して、ネットワークにわたるデータ送信を実行する。このモデルにおいてベアラ制御階層ルートは、ベアラネットワークリソースマネージャー間のシグナリングルートと、ドメイン間ルートとドメイン内ルートとを含むＣＮ間のサービスルートとを含む。このルーティング様式のストラテジールーティング方法は、サービスルートおよびシグナリングルートの両方に適用しうる。ここで、前記ＣＮは、ＥＲ、ＢＲまたは転送ルーターなどの他のルーターであってもよい。

図２２を参照して、本ルーティング様式の実施形態において、ＣＡ１からベアラネットワークリソースマネージャー４へのルートパスは、構築される必要があり、図２２に示されるように、ＣＡ１からベアラネットワークリソースマネージャー４への５つのシグナリングルートパス：

がある。

本実施形態において、各ベアラネットワークリソースマネージャーは、ストラテジールーティング情報を保存し、保存されたストラテジールーティング情報にしたがって、前記５つのシグナリングルートパスにわたって、ストラテジールーティングを行なう。具体的な手順は、下記のとおりである。

ステップ４１において、まず第一に、各ベアラネットワークリソースマネージャーは、帯域リソース状況にしたがって、ルーティングを行なう。本ルーティング様式のこの実施形態において、シグナリングルートパス１、２、３および４は、十分な帯域リソースを有し、シグナリングルートパス５は、ほとんど帯域リソースがない。したがって、シグナリングルートパス１、２、３および４が候補パスとして選択される。

ステップ４２において、各ベアラネットワークリソースマネージャーは、サービス要求の優先順位にしたがって、ルーティングを行なう。本ルーティング様式のこの実施形態において、サービスは、高い優先順位を有する。前記シグナリングルートパス１、２および３は、高い優先順位の要求を満足し、シグナリングルートパス４および５は、該要求を満足しないので、シグナリングルートパス１、２および３は、ステップＡで選択された前記シグナリングルートパス１、２、３および４から候補パスとして、選択される。

ステップ４３において、ルーティングは、ネットワークにおける各パスの現行サービスフローにしたがって、行なわれる。本ルーティング様式のこの実施形態において、シグナリングルートパス２および５は、目下、大きいサービスフローを有し、シグナリングルートパス１、３および４は、相対的に小さいサービスフローを有する。したがって、シグナリングルートパス１および３は、ステップＢにおける候補シグナリングルートパス１、２および３からの現行サービスフロー状況と一致する候補パスとしてさらに選択される。

ステップ４４において、ルーティングは、着呼ユーザーのＩＰアドレスにしたがって行なわれる。本ルーティング様式のこの実施形態において、ルーティングストラテジーは、この着呼ユーザーのＩＰアドレスに対するサービスが、パス３をとおして送信されることを規定する。したがって、パス３は、ステップＣにおける候補パス１および３からさらに選択される。

したがって、シグナリングルートパスは、

として決定される。

前記記載は、ベアラネットワークリソースマネージャーを用いることにより、シグナリングルートを実行する１つの実施形態であり、他の種のストラテジーは、ルートパスのホップの番号または発呼ユーザーのＩＰアドレスなどの他の実施形態の本ルーティング様式におけるルーティングを実行するのにも適用されうる。さらに、前記実施形態で説明されるように、選択を通した削除の様式のルーティングは、所定の順番で、多数のストラテジーを適用することにより行なわれ得、あるいは、ルーティングは、各ストラテジーそれぞれを適用することにより行なわれ得、ついで、全選択されたパスから、比較的に最適なパスが選択される。本ルーティング様式のこの実施形態における多数のルーティングストラテジーがあるが、本ルーティング様式の他の実施形態における唯一のルーティングストラテジーもありうる。

本ルーティング様式において、サービスルートルーティングを行ないながら、各ベアラネットワークリソースマネージャーも、ルーティングストラテジーを利用することにより、ドメイン内またはドメイン間ルーティングを行ないうる。ドメイン内ルーティングを行なうベアラネットワークリソースマネージャー１を例としてとり、図２４を参照して、本実施形態におけるこのドメイン内の有利なルーティングを実行する手順は、以下のとおりである。

ベアラネットワークリソースマネージャー１におけるサービスの入口ルーターおよび出口ルーターは、それぞれ、ＥＲ１およびＢＲ１であることがあらかじめ決定され、パス情報マトリックステーブルは、あらかじめ、ベアラネットワークリソースマネージャー１に保存される。このマトリックステーブルを調べることにより、入口ルーターとしてＥＲ１を有し、出口ルーターとしてＢＲ１を有する２つのＬＳＰ、ＬＳＰ１＋ＬＳＰ２とＬＳＰ３＋ＬＳＰ４とがあることを決定する。

表７において、横項目および縦項目は、それぞれ、ベアラネットワークリソースマネージャー１のドメイン内の出口ルーターおよび入口ルーターを表す。入口ルーターテーブル項目および出口ルーターテーブル項目は、それぞれ、この管理ドメインにおける全ＥＲまたはＢＲを含み、横列と縦列との交点は、１つのＥＲ／ＢＲから他のＥＲ／ＢＲまでのパス集約を示す。このテーブルのパス集約は、以下の状況である：

１０。表７の「−」またはスペースは、入口ルーターと出口ルーターとの間に利用可能なパスがないことを意味する。
２１つのみ利用可能なパスがある。例えば、表７の｛（ＬＳＰ１）｝は、入口ルーターと出口ルーターとの間に１つのみ最適なパスがあることを意味し；表７の｛（ＬＳＰ２，ＬＳＰ４）｝は、このパスが、複数のドメイン内ＬＳＰを通過することを意味する。
３多数のパスがある。例えば、丸括弧により分けられた表７の｛（ＬＳＰ５），（ＬＳＰ３，ＬＳＰ４）｝は、入口ルーターと出口ルーターとの間に多数の最適なパスがあることを意味する。

以下のストラテジー：ベアラネットワークリソースマネージャー１のＥＲ１におけるルート情報の宛先ＩＰアドレスとして、１０．１０．１．０／２４を有するサービスストリームについて、「ＬＳＰ１＋ＬＳＰ２」を選択することは、ベアラネットワークリソースマネージャー１に前もってセットされているので、ベアラネットワークリソースマネージャー１は、このストラテジーにしたがって、ドメイン内パスとして「ＬＳＰ１＋ＬＳＰ２」を選択し、それにより、ベアラネットワークリソースマネージャー１の出口ルーターがＢＲ１であることを決定するであろう。ベアラネットワークリソースマネージャー１は、適宜、

のパスを決定する。本実施形態において、ベアラネットワークリソースマネージャー１は、宛先アドレスにしたがって、ルーティングを行ない、本ルーティング様式の他の実施形態において、ベアラネットワークリソースマネージャー１も、優先順位による有利なルーティング、現行サービスフロー、帯域リソース状況および他のファクターを行なうことができ、ルーティング方法は、前記と同じである。

本実施形態において、他のベアラネットワークリソースマネージャーのドメイン内の有利なルーティング様式は、ベアラネットワークリソースマネージャー１のものと同じであり、ベアラネットワークリソースマネージャーのストラテジーは、同一か、または異なるかのいずれかであり、これは、このルーティング様式の実行に影響しない。

本ルーティング様式において、各ベアラネットワークリソースマネージャーは、有利なルーティングを利用することにより、サービスルートについてのドメイン間ルーティングを行ない、具体的なドメイン間ルーティング方法は、ドメイン内ルーティング方法と同様である。

前記有利なルーティング手順において、ルートパスのいずれもが、有利なルーティング要求を満たさず、ルーティング失敗情報が含まれる接続拒否応答は、上流ベアラネットワークリソースマネージャーに通知するであろう。このベアラネットワークリソースマネージャーは、接続拒否応答メッセージを、前ホップベアラネットワークリソースマネージャーまたはＣＡに通知し、この接続リソース要求を拒否する。

本ルーティング様式の他の実施形態において、他のタイプのストラテジーも、ルーティングに適用され得、例えば：ルーティングストラテジーは、どのストリームが、このＬＳＰを通過することが許容され、どれが許容されないかなどを含む、ドメイン内ＬＳＰの際の規則制約でありうる。

本ルーティング様式の実施形態において、ルーティングに適用されたストラテジー情報は、各ベアラネットワークリソースマネージャーに保存され、本ルーティング様式の他の実施形態において、ルーティングに適用されたストラテジー情報も全ベアラネットワークリソースマネージャーにより探されうる専用のストラテジーデータベースに保存されうる。

本ルーティング様式の方法を提供することにより、ネットワークサービスプロバイダーは、ユーザーの対応するサービスを実行する有利なルーティングにより特定のパスを、このユーザーサービス要求にしたがって、ユーザーをチャージするように、選択する。さらに、ユーザーのサービスに対するプリペイド状況は、ルーティングストラテジーとしてとられ、ルーティングを考慮にいれられうる。ネットワークプランをつくる際、サービスプロバイダーは、ユーザーに十分なリソースを提供できることを保証するように、よいネットワークプランをつくるはずである。

したがって、本方法は、サービス要求に関するストラテジーに基づきルーティングを、帯域幅要求にあうパスを選択するように実行でき、そうして、ユーザーコールを受けた後、所望の品質のサービスを保証しうる。

さらに、サービスプロバイダーは、分類されたチャージングを実行し、よりよい経済パフォーマンスを得るために、前もってセットされたリソース制約状況にしたがって、チャージング基準をセットできる。この方法は、実行、維持および管理が容易である。

前述の説明は、本発明に対する限定よりもむしろ例示であることを意味するべきである。

図１は、先行技術の独立ベアラ制御階層を有するＤｉｆｆ−Ｓｅｒｖモデルを示す。図２は、先行技術のＱＢｏｎｅネットワークにおける帯域ブローカーモデルのネットワークフレームワークを示す。図３は、図２に示された帯域ブローカーの内部構造を示す概念図である。図４は、先行技術のＮＥＣ社により示されたＲｉｃｈＱｏＳスキームのネットワーク構造を示す。図５は、ベアラネットワークリソースマネージャーによるルーティングを示す概念図である。図６は、本発明の第１の実施形態のベアラネットワークリソースマネージャー間のルートパス構築のフローチャートである。図７は、本発明の第１の実施形態の多重ベアラネットワークリソースマネージャー間のメッセージ相互作用を示す概念図である。図８は、本発明の第２の実施形態のベアラ制御階層のシグナリングルートパス構築のフローチャートである。図９は、本発明の第２の実施形態のシグナリングルートパス構築のプロセスに際する多数のベアラネットワークリソースマネージャー間のメッセージ相互作用を示す概念図である。図１０は、本発明の第２の実施形態のベアラ制御階層のシグナリングルートパス構築を示す概念図である。図１１は、本発明の第２の実施形態のベアラ制御階層におけるサービスルートパス構築のフローチャートである。図１２は、ルートパス情報を設定し、本発明の第３の実施形態のベアラネットワークリソースマネージャーによりリソースを割り当てるフローを示す。図１３は、本発明の第３の実施形態のベアラ制御階層におけるルート選択手順を示す概念図である。図１４は、ルートパス情報を構築し、本発明の第３の実施形態のベアラネットワークリソースマネージャーによりリソースを割り当てる他のフローを示す。図１５は、本発明の第４の実施形態のベアラネットワークリソースマネージャーによるルート選択のフローチャートである。図１６は、本発明の第５の実施形態のルート選択クロス独立オペレーションネットワークを実行するためのネットワーク構造を示す概念図である。図１７は、本発明の第５の実施形態のルート選択クロス独立オペレーションネットワークのフローチャートである。図１８は、ＩＰｖ４におけるＩＰデータパケットの構成的構造を示す概念図である。図１９は、本発明の第５の実施形態のネットワークルート制御方法のフローチャートである。図２０は、本発明の第５の実施形態の異なる管理エリアにおけるユーザー間の呼手順を示すフローチャートである。図２１は、本発明の第５の実施形態のネットワークルートの制御手順を示す。図２２は、本発明のサービスルート選択様式におけるベアラ制御階層を示す概念図である。図２３は、図２２に示される条件下でベアラネットワークにおいてＬＳＰを構築する手順を示す。図２３は、本発明の他のサービスルーティング様式におけるドメイン内パスを示す概念図である。

Claims

２以上のベアラネットワークリソースマネージャー（１００１，１００２，１００３，１００４，１００５）を含む独立ベアラ制御階層が、サービス制御階層とベアラネットワークとの間に構築され、一つのベアラネットワークリソースマネージャーが一つのドメインに対応し、そして、サービス制御階層からリアルタイムサービスのための接続リソース要求をソースベアラネットワークリソースマネージャーが受信（１２０１，１４０１，１５００）したときのラベルスイッチングに基づいたリアルタイムサービスデータ伝送路を選択する方法であり、
ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでホップバイホップして、宛先ベアラネットワークリソースマネージャーが接続リソース要求を受けるまで、ローカルドメインとネクストホップドメインとの間のドメイン間のラベルスイッチパス（ＬＳＰ）を決定（１２０２，１２０４，１２０６，１４０２，１４０４，１４０６，１４０８，１４１１，１５０１）し、ネクストホップベアラネットワークリソースマネージャーに接続リソース要求を送り（１２０３，１２０５，１４０３，１４０５，１５０２）、そして、
宛先ベアラネットワークリソースマネージャーからソースベアラネットワークリソースマネージャーまでホップバイホップして、ソースベアラネットワークリソースマネージャーに接続リソース応答が送られるまで、決定されたドメイン間ＬＳＰと接続リソース応答におけるローカルドメインのドメイン内ＬＳＰとを前ホップのベアラネットワークリソースマネージャーに送る（１２０７，１２０８，１２１０，１４０７，１４０９，１４１０，１５０６）ことで、このソースベアラネットワークリソースマネージャーが接続リソース応答を受け取り、ソースベアラネットワークリソースマネージャーから宛先ベアラネットワークリソースマネージャーまでの接続リソース要求のための全部のＬＳＰの集約を獲得することを含んでいる方法。
各ベアラネットワークリソースマネージャーがＩＰアドレスを有し、リアルタイムサービスの発呼及び着呼がＩＰアドレスによって識別され、そして、ベアラネットワークリソースマネージャーがＬＳＰをＩＰアドレスに基づいて選択する請求項１記載の方法。
ベアラネットワークにおけるリアルタイムサービスのストリームの入口（１００６）に全部のＬＳＰの集約を送信することをさらに含む請求項１記載の方法。
接続リソース要求を受けた後に、各ベアラネットワークリソースマネージャーによって、ローカルドメインのドメイン内ＬＳＰを決定（１２０２，１２０４，１２０６）することをさらに含む請求項１の方法。
宛先ベアラネットワークリソースマネージャーによって、接続リソース要求を受けた後にドメイン内ＬＳＰを決定（１４０６）し、そして、
宛先ベアラネットワークリソースマネージャーを除く各ベアラネットワークリソースマネージャーによって、接続リソース応答を受けた後にドメイン内ＬＳＰを決定（１４０８，１４１０）することをさらに含む請求項１の方法。
ルーティングストラテジーにしたがってベアラネットワークリソースマネージャーがＬＳＰを選択することをさらに含む請求項１乃至５のいずれか１項に記載の方法。
ローカルドメインにおける全てのボーダールーター（ＢＲ）とエッジルーター（ＥＲ）との間のＬＳＰのセットを前もって算出し、ドメイン内ルーティングテーブルを構築し、そして、ローカルドメインの入口ルーターと出口ルーターとにしたがってドメイン内ＬＳＰを得るためにドメイン内ルーティングテーブルにクエリーを実施するか；
目下選択されているＬＳＰの出口ルーターが、ローカルドメインにおけるＢＲ又はＥＲとなるまでドメイン内ＬＳＰをホップバイホップして選択し、そして、少なくとも一つのＬＳＰを含むドメイン内ＬＳＰを得るか；
マトリックスドメイン内ルートアルゴリズムにより、各ドメインのドメイン内ＬＳＰを選択するか；
前もって設定されたリソース制約状況またはルーティングストラテジーにしたがってドメイン内ＬＳＰを選択するか；
ベアラネットワークリソースマネージャーの管理ドメイン内の出口ＩＰアドレス識別子および入口ＩＰアドレス識別子の全てを含むパスの集約にしたがって各ドメインのドメイン内ＬＳＰを選択するか；
の何れかのドメイン内ＬＳＰを選択するモードを含む請求項１乃至５のいずれか１項に記載の方法。
接続リソース要求が現行ネットワーク状況とクオリティーオブサービス（ＱｏＳ）とを包含している請求項１乃至５のいずれか１項に記載の方法。
ローカルドメインにおける全てのＢＲとＥＲとの間のＬＳＰの内の少なくとも１セットを算出し、
この少なくとも１セットのＬＳＰを
横項目が入口接続ノード（ＣＮ）識別子で、縦項目が出口ＣＮ識別子であり、横項目と縦項目との一つのペアが、一つの入口ＣＮから一つの出口ＣＮまでのＬＳＰを全て含んでいる１以上のＬＳＰのセットの内の一つと対応しており、横項目でこの一つの入口ＣＮが識別され、縦項目でこの一つの出口ＣＮが識別されるか、
又は、横項目が出口ＣＮ識別子で、縦項目が入口ＣＮ識別子であり、横項目と縦項目との一つのペアが、一つの入口ＣＮから一つの出口ＣＮまでのＬＳＰを全て含んでいる１以上のＬＳＰのセットの内の一つと対応しており、横項目でこの一つの出口ＣＮが識別され、縦項目でこの一つの入口ＣＮが識別されるマトリックステーブルにソートし、
ローカルドメインにおけるＬＳＰのセットを得るためにローカルドメインの現行入口ルーターにしたがってマトリックステーブルにクエリーを実施し、そして、
ルーティングストラテジー、現行ネットワーク状況、及び所定のＱｏＳ要求にしたがってローカルドメインにおいて得られたＬＳＰのセットからドメイン内ＬＳＰとして一つのＬＳＰを選択することを含んだマトリックスドメイン内ルートアルゴリズムによる各ドメインのドメイン内ＬＳＰを選択する請求項７記載の方法。
ローカルドメインにおける全てのＢＲとＥＲとの間のＬＳＰのセットを１以上算出し、
ＢＲとＥＲとのそれぞれのためのＩＰアドレスセグメントを割り当て、
１以上のＬＳＰのセットを、
横項目が入口ＣＮのＩＰアドレスセグメントで、縦項目が出口ＣＮのＩＰアドレスセグメントであり、横項目と縦項目との一つのペアが、一つの入口ＣＮから一つの出口ＣＮまでのＬＳＰを全て含んでいる１以上のＬＳＰのセットの内の一つと対応しており、横項目でこの一つの入口ＣＮが識別され、縦項目でこの一つの出口ＣＮが識別されるか、
又は、横項目が出口ＣＮのＩＰアドレスセグメントで、縦項目が入口ＣＮのＩＰアドレスセグメントであり、横項目と縦項目との一つのペアが、一つの入口ＣＮから一つの出口ＣＮまでのＬＳＰを全て含んでいる１以上のＬＳＰのセットの内の一つと対応しており、横項目でこの一つの出口ＣＮが識別され、縦項目でこの一つの入口ＣＮが識別されるマトリックステーブルにソートし、
ローカルドメインにおけるＬＳＰのセットを得るためにローカルドメインの入口ＣＮのＩＰアドレスセグメントにしたがってマトリックステーブルにクエリーを実施し、そして、
ルーティングストラテジー、現行ネットワーク状況、及び所定のＱｏＳ要求にしたがってローカルドメインにおいて得られたＬＳＰのセットからドメイン内ＬＳＰとして一つのＬＳＰを選択することを含んだマトリックスドメイン内ルートアルゴリズムによる各ドメインのドメイン内ＬＳＰを選択する請求項７記載の方法。
各ベアラネットワークリソースマネージャーがＥ．１６４番号のエリアコードを有し、リアルタイムサービスの発呼及び着呼がＩＰアドレス、Ｅ．１６４番号又は自己決定番号のいずれかによって識別されており、そして、ベアラネットワークリソースマネージャーがＥ．１６４番号のエリアコードに基づいてドメイン間ＬＳＰを選択し、ＩＰアドレスに基づいてドメイン内ＬＳＰを選択する請求項１記載の方法。
ベアラネットワークリソースマネージャーがドメイン内ルーティング情報にしたがってドメンイン内ＬＳＰを選択し、そして、このドメイン内ルーティング情報がベアラネットワークリソースマネージャーかデータベースに静的に設定されているか、又は、接続リソース要求を受けているベアラネットワークリソースマネージャーから動的に得られるものである請求項１記載の方法。
接続リソース要求がサービスタイプとＱｏＳパラメータとを包含しており、
さらに、接続リソース要求によってもたらされるサービスタイプとＱｏＳパラメータとにしたがってベアラネットワークリソースマネージャーがＬＳＰを選択する請求項１記載の方法。
さらに、ルーティングストラテジーにしたがってベアラネットワークリソースマネージャーがＬＳＰを選択する請求項１３記載の方法。
ルーティングストラテジーにしたがったＬＳＰの選択には、負荷分割原理か、ポーリング様式か、サービス要求について設定された優先順位にしたがうかの何れかによるＬＳＰの選択が含まれている請求項１４記載の方法。
ドメイン内ＬＳＰの選択には、
１）接続リソース要求にしたがってローカルドメインにおける入口ＣＮを見出し、この入口ＣＮの情報を、見出されたＣＮの集約に加えるステップ、
２）この入口ＣＮにしたがって一つのドメンイン内ＬＳＰを選択し、この選択されたドメンイン内ＬＳＰの出口ＣＮがローカルドメインにおけるＥＲかＢＲかを判断し、もし、それがＥＲかＢＲかであった場合には、ドメンイン内ＬＳＰの選択を完了し、それ以外の場合は、ステップ３）を実施するステップ、
３）現在選択されているドメイン内ＬＳＰの出口ＣＮの情報が、検索されたＣＮの集約に既に加えられているかどうかを判断し、もし、検索されたＣＮの集約に加えられていたのであれば現在選択されているドメイン内ＬＳＰを放棄してステップ２）に戻り、そして、それ以外の場合は、現在選択されているドメイン内ＬＳＰの出口ＣＮの情報を検索されたＣＮの集約に加え、そして、この現在選択されているドメイン内ＬＳＰの出口ＣＮを入口ＣＮとして取得してステップ２）を実施させるステップ、
を含む請求項１記載の方法。
ソースユーザーと宛先ユーザーとが異なる独立オペレーションネットワークに属している場合に、
ソースユーザーが属する独立オペレーションネットワークのボーダールーターを管理するためのベアラネットワークリソースマネージャーにおける宛先ユーザーのアドレスセグメントを有する仮想宛先ユーザーを前もって設定し、
ソースユーザーが属する独立オペレーションネットワークにおけるボーダールーターと仮想宛先ユーザーを連結し、該ボーダールーターを、宛先ユーザーが属する独立オペレーションネットワークのゲートウェイに接続された状態とし、
接続リソース要求を受けた際には、
ソースユーザーが属する独立オペレーションネットワークにおけるボーダールーターを管理するベアラネットワークリソースマネージャーによって、仮想宛先ユーザーまで行くボーダールーターを、接続リソース要求でもたらされる宛先ユーザーのアドレスにしたがって決定し、
ソースユーザーが属する独立オペレーションネットワークにおけるボーダールーターを管理するベアラネットワークリソースマネージャーによって、ソースユーザーから仮想宛先ユーザーまでのルートを決定し、
宛先ユーザーが属する独立オペレーションネットワークのゲートウェイによって宛先ユーザーまでのルートを決定する請求項１記載の方法。
２以上のベアラネットワークリソースマネージャー（１００１，１００２，１００３，１００４，１００５）を含む独立ベアラ制御階層を、サービス制御階層とベアラネットワークとの間に構築させ、一つのベアラネットワークリソースマネージャーを一つのドメインに対応させた、ラベルスイッチングに基づくリアルタイムサービスデータの伝送路の選択のためのベアラネットワークリソースマネージャーであって、
サービス制御階層からリアルタイムサービスのための接続リソース要求を受信し、ローカルドメインとネクストホップドメインとの間のドメイン間のラベルスイッチパス（ＬＳＰ）を決定（１２０２，１２０４，１２０６，１４０２，１４０４，１４０６，１４０８，１４１１，１５０１，１５０２）し、
接続リソース応答においてもたらされるドメイン間ＬＳＰとローカルドメインのドメイン内ＬＳＰとを前ホップのベアラネットワークリソースマネージャーに送る（１２０７，１２０８，１２１０，１４０７，１４０９，１５０６）ための回路であるベアラネットワークリソースマネージャー。
ベアラネットワークにおけるリアルタイムサービスのストリームの入口に全部のＬＳＰの集約を送信するためのものである請求項１８記載のベアラネットワークリソースマネージャー。
ルーティングストラテジーにしたがってＬＳＰを選択するためのものである請求項１８又は１９記載のベアラネットワークリソースマネージャー。
ローカルドメインにおける全てのボーダールーター（ＢＲ）とエッジルーター（ＥＲ）との間のＬＳＰのセットを前もって算出し、ドメイン内ルーティングテーブルを構築し、そして、ローカルドメインの入口ルーターと出口ルーターとにしたがってドメイン内ＬＳＰを得るためにドメイン内ルーティングテーブルにクエリーを実施するか；
目下選択されているＬＳＰの出口ルーターが、ローカルドメインにおけるＢＲ又はＥＲとなるまでホップバイホップしてドメイン内ＬＳＰを選択し、そして、少なくとも一つのＬＳＰを含むドメイン内ＬＳＰを得るか；
マトリックスドメイン内ルートアルゴリズムにより、ローカルドメインのドメイン内ＬＳＰを選択するか；
前もって設定されたリソース制約状況またはルーティングストラテジーにしたがってドメイン内ＬＳＰを選択するか；
ベアラネットワークリソースマネージャーの管理ドメイン内の全ての入口ＩＰアドレス識別子および出口ＩＰアドレス識別子を含むパスの集約にしたがって各ドメインのドメイン内ＬＳＰを選択するか；
の何れかでドメイン内ＬＳＰを選択するためのものである請求項１８又は１９記載のベアラネットワークリソースマネージャー。
ソースベアラネットワークリソースマネージャーではないときに、前ホップのベアラネットワークリソースマネージャー送られた接続リソース応答におけるローカルドメインのドメンイン内ＬＳＰを、接続リソース要求を受けた後に決定するためのものである請求項１８記載のベアラネットワークリソースマネージャー。
ソースベアラネットワークリソースマネージャーでも宛先ベアラネットワークリソースマネージャーでもないときに、前ホップのベアラネットワークリソースマネージャー送られた接続リソース応答におけるローカルドメインのドメンイン内ＬＳＰを、接続リソース応答を受けた後に決定し、そして、
宛先ベアラネットワークリソースマネージャーではないときには、前ホップのベアラネットワークリソースマネージャー送られた接続リソース応答におけるローカルドメインのドメンイン内ＬＳＰを、接続リソース要求を受けた後に決定するためのものである請求項１８記載のベアラネットワークリソースマネージャー。