(57)【要約】【課題】多数のドメインに及ぶマルチドメイン多制約のＴＥ経路の自動的で且つ動的なセットアップを可能にし、各ドメインが、それ自身の内部構造及びオペレーションモードに基づき経路のドメイン内の部分及びその関連リソースを選択し、計算し及び割り当てることができるようにすることである。【解決手段】少なくとも２つのドメインを横切ってデータを搬送する方法及び装置。少なくとも２つのドメインを横切って少なくとも１つのサービスが広告され、少なくとも２つのドメインを横切って少なくとも１つのサービスが要求され、少なくとも２つのドメインを横切って少なくとも１つのサービスが利用される、少なくとも２つのドメインを横切ってデータを搬送する方法及び装置が提供される。更に、前記装置を含む通信システムが示唆される。【選択図】図５
2015507404.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２つのドメインを横切ってデータを搬送する方法において、
−少なくとも２つのドメインを横切って少なくとも１つのサービスを広告し、
−少なくとも２つのドメインを横切って少なくとも１つのサービスを要求し、
−少なくとも２つのドメインを横切って少なくとも１つのサービスを利用する、
ようにした方法。
【請求項２】
少なくとも１つのサービスに向けられた要求を受け容れ、そして各ドメイン内及びドメイン間でネットワークエレメントを横切って経路を構成することにより、少なくとも２つのドメインを横切って少なくとも１つのサービスを利用する、請求項１に記載の方法。
【請求項３】
少なくとも２つのドメイン間にドメイン間ルーティングプロトコルのメッセージを搬送することにより、少なくとも１つのサービスを広告し、要求し及び／又は利用する、請求項１又は２に記載の方法。
【請求項４】
前記ドメイン間ルーティングプロトコルのメッセージは、サービステンプレートを使用して少なくとも１つのサービスを明示する、請求項３に記載の方法。
【請求項５】
前記ドメイン間ルーティングプロトコルは、ボーダーゲートウェイプロトコルに基づく、請求項３又は４に記載の方法。
【請求項６】
前記ドメイン間ルーティングプロトコルのメッセージは、ＢＧＰ  ＵＰＤＡＴＥメッセージである、請求項５に記載の方法。
【請求項７】
−第１ドメインのコントロールエンティティにより第１ドメインの少なくとも１つのエッジノードを経て第２ドメインの少なくとも１つの第１エッジノードへ少なくとも１つのサービスを広告し、
−第２ドメインの少なくとも１つの第１エッジノードが、第２ドメインのコントロールエンティティに、第１ドメインからの少なくとも１つの広告されたサービスに関して通知し、
−第２ドメインのコントロールエンティティが、第２ドメインの少なくとも１つの第２エッジノードを経て第３ドメインの少なくとも１つのエッジノードへ少なくとも１つのサービスを広告し、
−第３ドメインの少なくとも１つのエッジノードが、第３ドメインのコントロールエンティティに、第１ドメインからの少なくとも１つの広告されたサービスに関して通知する、請求項１から６のいずれかに記載の方法。
【請求項８】
−第３ドメインのコントロールエンティティにより経路要求を受け取り、
−少なくとも１つの広告されたサービスのうちのサービスを選択し、そして第３ドメインを横切る経路を第３ドメインのコントロールエンティティにより決定し、
−サービス要求を第３ドメインのコントロールエンティティにより少なくとも１つのエッジノードを経て第２ドメインの少なくとも１つの第２エッジノードへ搬送し、
−第２ドメインの少なくとも１つの第２エッジノードから第２ドメインのコントロールエンティティへサービス要求を転送し、
−第２ドメインのコントロールエンティティにおいてサービスを選択し、そして第２ドメインを横切る経路を第２ドメインのコントロールエンティティにより決定し、
−サービス要求を第２ドメインのコントロールエンティティにより第２ドメインの少なくとも１つの第１エッジノードを経て第１ドメインの少なくとも１つのエッジノードへ搬送し、
−第１ドメインの少なくとも１つのエッジノードから第１ドメインのコントロールエンティティへサービス要求を転送し、
−第１ドメインのコントロールエンティティが第１ドメインを横切る経路を決定する、請求項７に記載の方法。
【請求項９】
−第１ドメインのコントロールエンティティにより第１ドメインの少なくとも１つのエッジノードを経て第２ドメインの少なくとも１つの第１エッジノードへ受け容れサービス要求を搬送し、
−第２ドメインの少なくとも１つの第１エッジノードが受け容れサービス要求を第２ドメインのコントロールエンティティへ転送し、
−第２ドメインのコントロールエンティティにより第２ドメインの少なくとも１つの第２エッジノードを経て第３ドメインの少なくとも１つのエッジノードへ受け容れサービス要求を搬送し、
−第３ドメインの少なくとも１つのエッジノードが受け容れサービス要求を第３ドメインのコントロールエンティティへ転送する、請求項８に記載の方法。
【請求項１０】
サービステンプレートは、次のもの、即ち
−行先情報、
−価格又はコスト情報、
−チャンネル特性、
−帯域巾情報、
−提供され又は要求されたサービス又はサービス品質に関する情報、
−ドメインに関する情報、
−遅延情報、
−遅延ジッタ情報、
−トラフィック情報、
のうちの少なくとも１つを含む、請求項４から９のいずれかに記載の方法。
【請求項１１】
第１ドメイン、第２ドメイン、及び第３ドメインにおけるドメイン内経路は、各コントロールエンティティを経て又はシグナリングプロトコルを経てセットアップされる、請求項８から１０のいずれかに記載の方法。
【請求項１２】
コントロールエンティティは、次のもの、即ち、
−ネットワークマネージメントシステム、
−エレメントマネージメントシステム、
−サービスマネージメントシステム、
−ドメインコントローラ、
のうちの少なくとも１つである、請求項７から１１のいずれかに記載の方法。
【請求項１３】
少なくとも２つのドメインを横切ってデータを搬送する装置において、
−少なくとも２つのドメインを横切って少なくとも１つのサービスを広告し、
−サービス要求に従って少なくとも２つのドメインを横切って広告された少なくとも１つのサービスを利用する、
ように構成された処理ユニットを備えた装置。
【請求項１４】
前記処理ユニットは、第１、第２又は第３ドメインの少なくとも１つのコントロールエンティティの方法ステップを実行するように構成された、請求項１３に記載の装置。
【請求項１５】
第１ドメイン、第２ドメイン及び第３ドメインを備えた通信システムにおいて、
−少なくとも１つのサービスが第１ドメインにより第２ドメインを経て第３ドメインへ広告され、
−第３ドメインが少なくとも１つのサービス又はその一部分を第１ドメインから第２ドメインを経て要求し、
−その要求された少なくとも１つのサービスが第２ドメインを経て第１ドメインにより受け容れられ又は拒絶される、
ようにした通信システム。
【請求項１６】
不揮発性記憶媒体に記憶され、且つデジタルコンピュータのメモリにロード可能であるコンピュータプログラムであって、請求項１から１２に記載の方法のいずれかのステップをコンピュータに遂行させるソフトウェアコード部分を備えたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、少なくとも２つのドメインを横切ってデータを搬送する方法及び装置に関する。この方法及び装置は、好ましくは、通信ネットワークにおいてマルチドメインＱｏＳイネーブルサービスを提供するのに使用される。又、それに応じた通信システムも示唆される。
【背景技術】
【０００２】
現在のインターネット解決策は、基本的に、関連ドメインエッジノード間のリンクを経て相互接続された自律的システム（ドメイン又はネットワークドメインとも称される）で構成される。自律的システムの所有者は、彼等の内部ネットワークをどのように構築して運用するかについて自由に選択を行う。通常、これは、ネットワーク要素（ノード）及び相互接続リンクから構築された構造体を含む。しかしながら、相互運用性の理由で、自律的システムは、例えば、ＲＦＣ４２７１、“A Border Gateway Protocol 4 (BGP-4)”に定義されたボーダーゲートウェイプロトコル（ＢＧＰ）のような共通のプロトコルを使用することが要求され、これは、ドメイン間ルーティング情報交換を可能にする。異なるドメイン間の構造及び内部オペレーションは、しばしば、機密に保持される。従って、ネットワークセグメントの帯域巾、レイテンシー及びジッタのようなネットワークトポロジー及びトラフィックエンジニアリング属性は、通常、異なるドメイン間に共有されない。慣習的な非制約の行先ベースのルーティングは、例えば、上述したＢＧＰ−４のような従来のルーティングプロトコルによって通常配布される到達性情報しか要求しない。しかしながら、自動ドメイン間トラフィックエンジニアリング（ＴＥ）経路予約システムが確実に且つ効率的に機能できるためには、他のドメインからのより多くの情報が要求される。
【０００３】
単一ドメイン内で実行される有意義な多制約ＴＥ経路計算は、そのような経路に対して使用されるドメインの各ネットワークセグメントのネットワークトポロジー及びＴＥ属性に関する詳細な情報を必要とする。それ故、ＴＥ情報は、ドメイン内で配布する必要があるか、或いは例えば、サービスマネージメントシステム（ＳＭＳ）、ネットワークマネージメントシステム（ＮＭＳ）又は経路計算要素（ＰＣＥ）のようなコントロールのための接触点へ収集搬送されてもよい。
【０００４】
他方、ドメイン内経路は、実際には、ネットワークマネージメントハイアラーキーを経てセットアップされるか、或いはシグナリングプロトコル（例えば、ＲＳＶＰ−ＴＥ）を使用してコントロールプレーンを経てシグナリングされる。ネットワークマネージメントハイアラーキーは、大きなネットワークを管理するための典型的な方法であり、通常は、少なくとも１つのＮＭＳ及び多数のエレメントマネージメントシステム（ＥＭＳ）で構成されるが、サービスマネージメントシステム（ＳＭＳ）をレバレッジしてサービスを管理することもできる。ＳＭＳは、少なくとも１つのＮＭＳをコントロールするハイアラーキーのトップにあり、ＮＭＳは、ＥＭＳをコントロールし、ＥＭＳは、ネットワークノードから情報を収集してそれらを構成するのに使用される。
【０００５】
ＢＧＰルータは、ＵＰＤＡＴＥメッセージを、ドメイン内（ｉＢＧＰを使用する）ピア及びドメイン間（ｅＢＧＰ）ピアの両方と交換して、経路ベクトルのフォーマットで接続性情報を広告する。経路ベクトルは、行先プレフィックスに関する情報と、経路に沿った自律的システム（ＡＳ）番号と、ルートの有用性及び潜在的な好ましさに関する判断を可能にする他の必須の及び任意の属性とを搬送する。各既知の行先への最良のルートだけが更に広告され、そして互いに接近した多数のプレフィックスを、より広い範囲のプレフィックスへとアグリゲートすることができる。
【０００６】
インターネット形式のインフラストラクチャーを使用するネットワーク及びサービスプロバイダー並びに他のインスタンスは、多数のドメインを横切って彼等の顧客にサービスクオリティ（ＱｏＳ）イネーブルサービスを提供するために、マルチドメインＴＥ経路を形成する必要がある。現在のところ、そのような経路のセットアップは、ネゴシエーション、サービスレベルアグリーメント（ＳＬＡ）、及びルータの静的な構成を含む厄介なタスクである。これは、著しい量の時間やリソースを消費し、低速で、静的で且つ非効率的なものにし、その有用性を限定する。
【０００７】
コントロールプレーン（ＣＰ）又はマネージメントプレーン（ＭＰ）を経て動的にプロビジョニングすることが好ましいが、そのようなシステムを効率的に配備するためには、現在のドメイン間モデル及びインフラストラクチャーを考慮に入れて、できるだけ保存することが要求される。従って、各ドメインは、内部では互いに異なる仕方で構成及び動作され、ドメイン間ルーティングプロトコルが唯一共通の分母及び接着剤である。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従って、本発明の目的は、多数のドメインに及ぶマルチドメイン多制約のＴＥ経路の自動的で且つ動的なセットアップを可能にし、各ドメインが、それ自身の内部構造及びオペレーションモードに基づき経路のドメイン内の部分及びその関連リソースを選択し、計算し及び割り当てることができるようにすることである。
【課題を解決するための手段】
【０００９】
この目的は、少なくとも２つのドメインを横切ってデータを搬送する方法及び装置であって、
−少なくとも２つのドメインを横切って少なくとも１つのサービスが広告され、
−少なくとも２つのドメインを横切って少なくとも１つのサービスが要求され、
−少なくとも２つのドメインを横切って少なくとも１つのサービスが利用される、
ようにした方法及び装置によって達成される。
【００１０】
サービスは、サービスクラス、又はサービスクオリティ（ＱｏＳ）、又は単一ドメインを越えて好都合に利用される他の特性を含む。例えば、ここに示唆される解決策は、互いに個別に且つ完全に異なる仕方で維持及び動作できるドメインを横切って、例えば、帯域巾及び／又はデータレート要件、遅延、遅延ジッタ及び／又は価格制約、信頼性及び利用性予想、等により特徴付けられる特定形式のサービスをサポートする通信経路をセットアップできるようにする。
【００１１】
従って、ここに提示される解決策は、隣接ドメインが異なる技術を使用してドメイン内ＴＥ経路を形成できるようにし、一方、圧倒的多数のドメインに現在存在するネットワークエレメントタイプ及び具現化に基づいてドメイン間通信経路を決定することができる。
【００１２】
関連サービスは、起点ドメインからスタートし、１つ以上の中間ドメインを通過し、そして行先ドメインで終了するように、３つ以上のドメインを横切って広がる。更に、サービスは、ポイント対ポイント、ポイント対マルチポイント、マルチポイント対ポイント、又はマルチポイント対マルチポイントのサービスであり、従って、少なくとも２つのドメインは、１つ以上の起点及び／又は行先ドメインを含む。起点及び行先ドメインは、各サービスのエンドドメインとも称される。
【００１３】
いずれのドメインもエンドドメイン又は中間ドメインの役割を同時に果たすが、一度に異なるサービス及び／又は異なるサービス要求に対するものだけであるから、本明細書及び特許請求の範囲全体を通じて次の用語が使用される。
【００１４】
「第１ドメイン」と表わされるドメインは、サービスの広告を開始するドメインの役割を有し、従って、そのサービスの要求の行先ドメインである。従って、第１ドメインは、首尾良いサービス要求に応答して受け容れ手順も開始する。第１ドメインの役割、タスク及び活動に関する詳細は、本明細書のこれ以降の部分から得られる。
【００１５】
「第２ドメイン」と表わされるドメインは、中間ドメインとして働く。これは、第１ドメインから受け取ったサービス広告を登録し、そしてそのサービス広告を更に別の（第２又は第３の）ドメインへ転送する。第２ドメインは、第３（又は他の第２）のドメインから受け取ったサービス要求も登録し、そしてそれらを、関連サービスを広告した第１ドメインの方向に更に別のドメインへ転送する。第２ドメインは、更に、第１ドメインから発せられて第３ドメインへ向けられる要求受け容れ情報を受け取って転送する。第２ドメインの役割、タスク及び活動に関する詳細は、本明細書のこれ以降の部分から得られる。
【００１６】
「第３ドメイン」と表わされるドメインは、第１ドメインによって発せられて潜在的に第２ドメインにより転送されるサービス広告を受け取って登録する。これは、ユーザから経路要求を受け取り、適当なサービスを選択し、そして各サービスを広告した関連第１ドメインの方向に関連サービス要求を転送する。一般的に、第３ドメインの役割は、サービス要求に対する起点ドメインである。第３ドメインの役割、タスク及び活動に関する詳細は、本明細書のこれ以降の部分から得られる。
【００１７】
上述したように、ドメインは、異なるサービスに対する異なる役割を同時に有する。
【００１８】
第１、第２及び第３ドメインの役割は、本明細書のこれ以降の部分及び特許請求の範囲全体を通じて規範的に使用される。より詳細には、ここに開示する方法及びシステムの文脈においてドメインの異なる役割及び機能を説明し且つ例示するために、３つのタイプのドメイン役割各々の厳密に１つだけを含む構成を使用する。
【００１９】
明らかに、「少なくとも２つのドメイン」を伴うシナリオは、必ずしも、上述した３つのタイプのドメインを全て含ませるというものではない。一例として、第２ドメインを伴わないシナリオを容易に想像することができる。しかしながら、それなりの当業者であれば、４つ以上のドメインを伴うシナリオを同様に想像できるであろう。３つのタイプのドメイン役割及びそれらの振る舞いが定義されると、上述したマルチポイントトポロジーをもつサービスを含む多数のドメインで関連構成を具現化することは容易なエンジニアリングタスクとなる。
【００２０】
一実施形態において、少なくとも１つのサービスに向けられた要求を受け容れ、そして各ドメイン内及びドメイン間でネットワークエレメントを横切って経路を構成することにより、少なくとも１つのサービスが少なくとも２つのドメインを横切って利用される。ドメイン間経路セグメントは、ドメインエッジノード間に予めインストールされた相互接続リンクを使用する。
【００２１】
サービス要求に応じられない場合、例えば、ドメインが、要求されたサービスに必要な経路及び／又はリソースを提供できない場合、或いは応答が遅いか又は応答欠落のためにサービス要求が時間切れとなる場合、或いは要求されたサービスが旧式のものとなる場合、或いはサービス要求又は経路セットアップ段階全体にわたり他に何か悪くなったものがある場合には、問題を検出するドメインは、サービス要求に含まれた他のドメインに向けて拒絶情報を送信する。拒絶情報を受け取るドメインは、潜在的に予約されたリソースを解除し、そして関連サービスをそのデータベースから除去し、且つそれが関連要求の起点ドメインでない場合には、拒絶情報を他の当該ドメインへ転送する。起点ドメインが次に最良のルート候補を見つけられる場合には、要求しているユーザに相談せずに新たな経路の確立を試みることができる。
【００２２】
選択肢として、提案されたサービス（及び例えば、その価格）は、最終的な確立及び経路の使用の前に、要求者、例えば、起点ドメインに接続されたユーザにより検証される。
【００２３】
経路は、異なる仕方でセットアップすることができ、例えば、単一のドメイン間経路に沿って各ドメイン内の異なる方法及び手段を使用してセットアップできることに注意されたい。
【００２４】
他の実施形態では、ドメイン間ルーティングプロトコルのメッセージを少なくとも２つのドメイン間に搬送することにより少なくとも１つのサービスが広告され、要求され及び／又は利用される。
【００２５】
特に、ドメイン間ルーティングプロトコルをサービス広告のために、並びにサービス要求及びサービス受け入れ／拒絶機能のために使用することが示唆され、ドメイン間ルーティングプロトコルのメッセージは、サービステンプレートを使用して少なくとも１つのサービスを指定する。
【００２６】
更に別の実施形態では、ドメイン間ルーティングプロトコルは、ボーダーゲートウェイプロトコルに基づく。ドメイン間ルーティングプロトコルは、特に、ＲＦＣ４２７１に規定されたＢＧＰに基づくものである。ＢＧＰは、ここに示唆される要件を満足するように変更することができる。特に、（少なくとも２つの）ドメイン間のボーダーを横切ってサービスを広告し及び利用するのを許すテンプレートを搬送するためにＢＧＰの属性を使用できることに注意されたい。
【００２７】
より詳細には、ＢＧＰ  ＵＰＤＡＴＥメッセージは、「ｅＢＧＰサービス」と称される任意の非推移(non-transitive)属性で拡張され、サービステンプレート、ＴＥ経路要求テンプレート、及び／又は要求受け容れ又は要求拒絶テンプレートを隣接ドメインから搬送できるようにする。これらのテンプレートは、各ドメインがそのボーダー（エッジノードとも称される）にある特定のＢＧＰルータを経て広告し、要求し、受け容れ又は拒絶するサービスに関する詳細な情報を搬送する。行先情報、価格情報のようなエレメント、及び／又は帯域巾、遅延及び／又は遅延ジッタのような１つ以上のＱｏＳをテンプレートに含ませることができる。
【００２８】
従って、ある実施形態では、特にＢＧＰ  ＵＰＤＡＴＥメッセージを経て搬送されるサービステンプレートを使用することによりドメイン間で少なくとも１つのサービスが広告される。更に別の実施形態では、特にＢＧＰ  ＵＰＤＡＴＥメッセージを経て搬送されるサービステンプレートを使用することにより、ドメイン間で少なくとも１つのサービスが要求される。更に別の実施形態では、特にＢＧＰ  ＵＰＤＡＴＥメッセージを経て搬送されるサービステンプレートを使用することによりドメイン間で少なくとも１つのサービスが受け容れられる。従って、ドメイン間ルーティングプロトコルのメッセージがＢＧＰ  ＵＰＤＡＴＥメッセージであることは、有効な選択肢である。
【００２９】
次の実施形態では、
−第１ドメインのコントロールエンティティにより第１ドメインの少なくとも１つのエッジノードを経て第２ドメインの少なくとも１つの第１エッジノードへ少なくとも１つのサービスが広告され、
−第２ドメインの少なくとも１つの第１エッジノードが、第２ドメインのコントロールエンティティに、第１ドメインからの少なくとも１つの広告されたサービスに関して通知し、
−第２ドメインのコントロールエンティティが、第２ドメインの少なくとも１つの第２エッジノードを経て第３ドメインの少なくとも１つのエッジノードへ少なくとも１つのサービスを広告し、
−第３ドメインの少なくとも１つのエッジノードが、第３ドメインのコントロールエンティティに、第１ドメインからの少なくとも１つの広告されたサービスに関して通知する。
【００３０】
上述したように、この実施形態は、厳密に３つのドメインにわたるサービス広告の規範的なケースを網羅するもので、それらの各々は、第１、第２及び第３ドメインの３つの役割の１つを表わす。それなりの当業者であれば、２つのドメインしかもたないシナリオ、即ち第２ドメインがないとき、或いは４つ以上のドメインをもつシナリオ、即ち第２タイプの２つ以上のドメインに及ぶときに、この例を容易に適応させることができよう。これと同じ容易な仕方で、マルチポイントトポロジーサービスを伴うシナリオを採用することができる。
【００３１】
別の実施形態によれば、
−第３ドメインのコントロールエンティティにより経路要求が受け取られ、
−少なくとも１つの広告されたサービスのうちのサービス（広告されたサービスのうちの少なくとも１つ）が選択され、そして第３ドメインを横切る経路が第３ドメインのコントロールエンティティにより決定され（特に選択され及び／又は予約され）、
−サービス要求が第３ドメインのコントロールエンティティにより少なくとも１つのエッジノードを経て第２ドメインの少なくとも１つの第２エッジノードへ搬送され、
−第２ドメインの少なくとも１つの第２エッジノードから第２ドメインのコントロールエンティティへサービス要求が転送され、
−第２ドメインのコントロールエンティティにおいてサービス（広告されたサービスのうちの少なくとも１つ）が選択され、そして第２ドメインを横切る経路が第２ドメインのコントロールエンティティにより決定され（特に選択され及び／又は予約され）、
−サービス要求が第２ドメインのコントロールエンティティにより第２ドメインの少なくとも１つの第１エッジノードを経て第１ドメインの少なくとも１つのエッジノードへ搬送され、
−第１ドメインの少なくとも１つのエッジノードから第１ドメインのコントロールエンティティへサービス要求が転送され、
−第１ドメインのコントロールエンティティが第１ドメインを横切る経路を決定する（特に選択し及び／又は予約する）。
【００３２】
経路要求は、特に、それがＴＥ経路要求である場合には、通常、その経路を必要とする関連サービスの特定要件に関して情報を与える。そのような要件は、帯域巾又はデータスループット、ＱｏＳパラメータ、サービスの信頼性及び／又は利用性レベル、等を含む。従って、その要求に対して起点ドメインの役割を果たすところの第３ドメインのコントロールエンティティは、適当なサービスを選択し、そして関連サービス要求を第２ドメインに向かって搬送することができる。その後の各当該ドメインのコントロールエンティティは、関連サービスを選択しそして各ドメインを横切る経路を決定する。従って、サービス要求段階の後に、ドメインを横切る及びドメイン内の経路が選択される（予約される）。
【００３３】
この場合も、ここに述べる実施形態は、厳密に３つのドメインにわたるシナリオの規範的なケースを網羅するもので、それらの各々は、第１、第２及び第３ドメインの３つの役割の１つを表わす。それなりの当業者であれば、２つのドメインしかもたないシナリオ、即ち第２ドメインがないとき、或いは４つ以上のドメインをもつシナリオ、即ち第２タイプの２つ以上のドメインに及ぶときに、この例を容易に適応させることができよう。これと同じ容易な仕方で、マルチポイントトポロジーサービスを伴うシナリオを採用することができる。
【００３４】
別の実施形態によれば、
−第１ドメインのコントロールエンティティにより第１ドメインの少なくとも１つのエッジノードを経て第２ドメインの少なくとも１つの第１エッジノードへ受け容れサービス要求が搬送され、
−第２ドメインの少なくとも１つの第１エッジノードが受け容れサービス要求を第２ドメインのコントロールエンティティへ転送し、
−第２ドメインのコントロールエンティティにより第２ドメインの少なくとも１つの第２エッジノードを経て第３ドメインの少なくとも１つのエッジノードへ受け容れサービス要求が搬送され、
−第３ドメインの少なくとも１つのエッジノードが受け容れサービス要求を第３ドメインのコントロールエンティティへ転送する。
【００３５】
受け容れサービス要求情報が第３ドメインのコントロールエンティティに到達すると、要求者により使用するために経路が最終的に確立されてコミットされる。
【００３６】
上述したように、この実施形態も、厳密に３つのドメインにわたるシナリオの規範的なケースを網羅するもので、それらの各々は、第１、第２及び第３ドメインの３つの役割の１つを表わす。それなりの当業者であれば、２つのドメインしかもたないシナリオ、即ち第２ドメインがないとき、或いは４つ以上のドメインをもつシナリオ、即ち第２タイプの２つ以上のドメインに及ぶときに、この例を容易に適応させることができよう。これと同じ容易な仕方で、マルチポイントトポロジーサービスを伴うシナリオを採用することができる。
【００３７】
次の実施形態によれば、サービステンプレートは、次の少なくとも１つを含む。
−行先情報、
−価格又はコスト情報、
−チャンネル特性、
−帯域巾情報、
−提供され又は要求されたサービス又はサービス品質に関する情報、
−ドメインに関する情報、
−遅延情報、
−遅延ジッタ情報、
−トラフィック情報。
【００３８】
更に別の実施形態によれば、第１ドメイン、第２ドメイン、及び第３ドメインにおけるドメイン内経路は、各コントロールエンティティを経て又はシグナリングプロトコルを経てセットアップされる。
【００３９】
従って、各コントロールエンティティは、データプレーンをセットアップしそしてそれに応じてドメインのノードを構成することによりドメイン内経路を構成する。又、ドメイン内経路をセットアップするためにシグナリングプロトコルを使用できる（例えば、ＲＳＶＰ−ＴＥ）という選択肢もある。
【００４０】
一実施形態によれば、コントロールエンティティは、次の少なくとも１つである。
−ネットワークマネージメントシステム、
−エレメントマネージメントシステム、
−サービスマネージメントシステム、
−ドメインコントローラ。
【００４１】
ドメインコントローラは、個別のエンティティであるが、例えば、ＰＣＥ、リソースマネージャー及び／又はアドミッションコントローラ、ポリシーコントローラ、ネットワークエレメントのコントロールユニット、又はドメインに関連した他のコントロールエンティティとして、又はその一部分として具現化されてもよいし、或いはそれに合体されてもよい。
【００４２】
又、上述した問題は、少なくとも２つのドメインを横切ってデータを搬送する装置であって、次のように構成された処理ユニットを備えた装置によって解決される。
−少なくとも２つのドメインを横切って少なくとも１つのサービスを広告し、
−特にサービス広告に基づきサービス要求に従って少なくとも２つのドメインを横切って広告される少なくとも１つのサービスを利用する。
【００４３】
特定の実施形態において、処理ユニットは、上述した第１、第２又は第３ドメインの少なくとも１つのコントロールエンティティの方法ステップを実行するように構成される。この場合も、ドメインは、異なるサービスに対して３つのタイプの全てのドメイン、即ち第１、第２及び第３ドメインの役割を同時にとることに注意されたい。従って、処理ユニットは、それに応じて動作するように構成される。
【００４４】
又、上述した問題は、少なくとも２つのドメインを横切ってデータを搬送する装置であって、次のように構成された処理ユニットを備えた装置によって解決される。
−少なくとも２つのドメインを横切って広告された少なくとも１つのサービスを要求し、
−サービス要求に従ってセットアップされた経路を経て少なくとも２つのドメインを横切ってデータを搬送する。
【００４５】
少なくとも２つのドメイン内では、サービス広告ドメインが、通常（必ずしもそうではないが）、サービス要求ドメインとは異なり、且つ潜在的に少なくとも１つの中間ドメインを経て広告を搬送することに注意されたい。従って、サービス要求ドメインは、潜在的に、少なくとも１つの中間ドメインを経てサービス要求を搬送する。
【００４６】
更に、ここに述べる方法のステップは、各処理ユニットにおいて実行されることに注意されたい。
【００４７】
更に、前記処理ユニットは、ここに述べる方法のステップを実行するように構成された手段を少なくとも１つ、特に、複数個、備えていることに注意されたい。この手段は、論理的又は物理的に分離され、特に、複数の論理的に個別の手段を少なくとも１つの物理的ユニットに結合することができる。
【００４８】
前記処理ユニットは、次のもの、即ちプロセッサ、マイクロコントローラ、固定配線回路、ＡＳＩＣ、ＦＰＧＡ、ロジック装置、の少なくとも１つを含む。
【００４９】
ここに提供される解決策は、更に、デジタルコンピュータのメモリに直接ロードできるコンピュータプログラム製品を備え、これは、ここに述べる方法を遂行するためのソフトウェアコード部分を含む。
【００５０】
更に、上述した問題は、メモリにロードされたときに、ここに述べる方法をコンピュータシステムに遂行させるコンピュータ実行可能なインストラクションを有するコンピュータ読み取り可能な媒体、例えば、任意の種類の不揮発性記憶装置により解決される。
【００５１】
又、上述した問題は、第１ドメイン、第２ドメイン及び第３ドメインを備えた次のような通信システムによって解決される。
−少なくとも１つのサービスが第１ドメインにより第２ドメインを経て第３ドメインへ広告され、
−第３ドメインが少なくとも１つのサービス又はその一部分を第１ドメインから第２ドメインを経て要求し、
−要求された少なくとも１つのサービスが第２ドメインを経て第１ドメインにより受け容れられ又は拒絶される。
【００５２】
又、本発明は、３つのドメインを含む最も適した構成を使用してここに述べるが、当業者であれば、ドメインが２つしかない又は４つ以上ある同等の関連構成を容易に具現化できるであろうことも述べておく。従って、第２ドメイン（即ち、上述した「第２ドメイン」タイプのドメインは、必ずしも存在しなくてもよく、或いは任意のタイプの２つ以上のドメインが含まれてもよい。
【００５３】
更に、上述した問題は、ここに述べる少なくとも１つの装置を備えた通信システムにより解決される。本発明の実施形態は、添付図面に示して、以下に詳細に説明する。
【図面の簡単な説明】
【００５４】
【図１】ドメインＡからドメインＢを経てドメインＣへ至るサービスの広告段階を示す概略図である。
【図２】図１に示して説明したステップの後に続くサービス要求段階及び経路計算段階を示す概略図である。
【図３】図２に示して説明したステップの後に続くサービス受け容れ段階及び経路セットアップ段階を示す概略図である。
【図４】３つの相互接続されたドメイン及びそれらのマネージメントハイアラーキーの一例を示す概略図である。
【図５】図１、図２及び図３によるドメインを示す概略メッセージチャートである。
【図６】サービス要求又はサービスオファーの情報を伴う規範的なテンプレートを含むテーブルを示す。
【図７】テンプレートの規範的なフィールドを含むテーブルを示す。
【発明を実施するための形態】
【００５５】
ここに示す解決策は、特に、ボーダーゲートウェイプロトコル（ＢＧＰ）、等に基づくものであるか、或いは相互接続されたドメインに使用できるドメイン間ルーティングプロトコルに基づくものである。
【００５６】
この解決策は、特に、ドメイン間ルーティングプロトコル機能を使用して、少なくとも２つの個別ドメインを相互接続する。各ドメインは、異なるオペレータ又はプロバイダーによって維持され、そして少なくとも１つの接続セグメントを含む。
【００５７】
ドメイン間ルーティングプロトコルを使用して、サービス広告を行うと共に、サービス要求及びサービス受け容れ機能を行うことが示唆される。
【００５８】
良く理解するために、図は、上述した「第１ドメイン」として「ドメインＣ」の名前を、「第２ドメイン」として「ドメインＢ」を、そして「第３ドメイン」として「ドメインＡ」を使用することに注意されたい。
【００５９】
図４は、３つの相互接続されたドメイン４０１から４０３を含む概略図である。
【００６０】
ドメイン４０１は、３つのネットワークエレメント４０４から４０６を備え、ネットワークエレメント４０４は、ネットワークエレメント４０５及び４０６に接続され、そしてネットワークエレメント４０５は、更に、ネットワークエレメント４０６に接続される。ネットワークエレメント４０４及び４０６は、ドメイン４０１のエッジにあるネットワークエレメントであり、ＢＧＰに基づくエッジルータとして実現することができる。ドメイン４０２は、３つのネットワークエレメント４０７から４０９を備え、ネットワークエレメント４０７は、ネットワークエレメント４０８及び４０９に接続され、そしてネットワークエレメント４０８は、更に、ネットワークエレメント４０９に接続される。ネットワークエレメント４０７及び４０９は、ドメイン４０２のエッジにあるネットワークエレメントであり、ＢＧＰに基づくエッジルータとして実現することができる。ドメイン４０３は、３つのネットワークエレメント４１０から４１２を備え、ネットワークエレメント４１０は、ネットワークエレメント４１１及び４１２に接続され、そしてネットワークエレメント４１１は、更に、ネットワークエレメント４１２に接続される。ネットワークエレメント４１０及び４１２は、ドメイン４０３のエッジにあるネットワークエレメントであり、ＢＧＰに基づくエッジルータとして実現することができる。
【００６１】
エレメントマネージメントシステム（ＥＭＳ）４１３から４２１は、ネットワークエレメント４０４から４１２の各々に関連している。ネットワークマネージメントシステム（ＮＭＳ）４２２は、ＥＭＳ４１３から４１５をコントロールし、ＮＭＳ４２３は、ＥＭＳ４１６から４１８をコントロールし、そしてＵＭＳ４２３は、ＥＭＳ４１９から４２１をコントロールする。サービスマネージメントシステム（ＳＭＳ）４２５は、ＮＭＳ４２２から４２４と通信する。
【００６２】
以下、複数のドメイン４０１から４０３を横切ってサービスをどのように利用するかについて説明する。より詳細には、それらのサービスを考慮して、そのようなドメイン４０１から４０３を横切って経路をセットアップすることができる。そのような経路は、ドメインを横切ってデータを搬送するために一時的に又は静的に使用することができる。この解決策は、好都合にも、各ドメイン４０１から４０３がそれらの内部メカニズムを維持し、そして例えば、ドメイン間ルーティングの目的でどの経路を選択すべきか自由に判断するのを許す。ＳＭＳ、ＮＭＳ及びＥＭＳハイアラーキーを含むコントロールプレーンは、各ドメインのボーダーを越えてコントロールの目的で使用することができる（が、使用しなくてもよい）。
【００６３】
図１は、広告段階を示す概略図である。この図は、ドメインＡ１０１、ドメインＢ１０２及びドメインＣ１０３を含み、各ドメインは、その縁に配備された複数のネットワークエレメント及びルータを有する。ドメインＡ１０１は、ＮＭＳ１０４によりコントロールされ、ドメインＢ１０２は、ドメインコントローラ１０５によりコントロールされ、そしてドメインＣ１０３は、ＮＭＳ１０５によりコントロールされる。ドメインＡ１０１及びドメインＣ１０３は、ドメインＢ１０２を経て接続される。
【００６４】
図１は、ドメインＣ１０３がドメインＢ１０２を経てドメインＡ１０１へそのサービスをどのように広告するか示す。これは、次のステップにより行われる（番号は、図１に示された各ステップも指す）。
１．ＮＭＳ１０６は、ドメインＣ１０３のサービスをドメインＣ１０３のエッジノード１０７、１０８へ広告する。
２．エッジノード１０７、１０８は、サービステンプレートを（ＢＧＰ  ＵＰＤＡＴＥメッセージを経て）ドメインＢ１０２のエッジノード１０９、１１０へ搬送する。
３．ドメインＢ１０２のエッジノード１０９、１１０は、ドメインコントローラ１０５においてデータベース更新を開始する。
４．ドメインコントローラ１０５は、ドメインＣ１０３のサービスをドメインＢ１０２のエッジノード１１１に広告する。
５．エッジノード１１１は、ＢＧＰ  ＵＰＤＡＴＥメッセージを経てエッジノード１１２へそしてドメインＡ１０１のエッジノード１１３へサービステンプレートを搬送する。
６．エッジノード１１２、１１３は、ＮＭＳ１０４においてデータベース更新を開始する。
【００６５】
一例として、ＢＧＰ  ＵＰＤＡＴＥメッセージは、「ｅＢＧＰサービス」と称される任意の非推移(non-transitive)属性で拡張され、サービステンプレート、ＴＥ経路要求テンプレート、及び／又は要求受け容れ又は要求拒絶テンプレートを隣接ドメインから搬送できるようにする。これらのテンプレートは、ボーダー（エッジノードとも称される）にある特定のＢＧＰルータを経てオファーされ、要求され、又は受け容れ／拒絶されるサービスに関する詳細な情報を搬送する。行先情報、価格情報のようなエレメント、及び／又は帯域巾、遅延及び／又は遅延ジッタのような１つ以上のＱｏＳ属性をテンプレートに含ませることができる。
【００６６】
図２は、図１に示して説明したステップの後に続くサービス要求段階及び経路計算段階を示す概略図である。図２に示すコンポーネントについては、図１及び前記説明を参照されたい。
【００６７】
従って、少なくとも１つのサービステンプレートが少なくとも１つの隣接ドメインからローカルドメインへ広告されると、次のステップが行われる（番号は、図２に示した各ステップも指す）。
７．ドメインＡ１０１のローカルユーザは、例えば、ＮＭＳ１０４のクライアントインターフェイスを使用するか、或いはドメイン内コントロールプレーンが存在する場合にはユニバーサルネットワークインターフェイス（ＵＮＩ）を使用することにより、ドメイン間ＴＥ経路を要求する。この要求は、中央コントロールエンティティ（ＣＣＥ）、例えば、ＳＭＳ、ＮＭＳ、又はドメインコントローラへ向けられ、これは、ＴＥ制約を伴うローカルトポロジー、現在予約及び利用可能なドメイン間サービスに関する情報を保持する。ＣＣＥは、マルチ制約のＴＥ経路を計算するか、又はＰＣＥから経路を問い合わせる。
８．ローカルに維持される情報に基づいて、ドメイン間経路要求を満足できる（即ち、要求されたサービス及び要求されたリソースが利用できる）場合には、ドメイン内経路が計算され、そしてリソースを予約することができる。
９．適当な（例えば、最適な）エッジノード１１３（ボーダーＢＧＰルータ）及び隣接ドメインＢ１０２が選択され、ドメイン間サービスの要求が前記エッジノード１１３へ搬送される。
１０．例えば、ドメイン間ＴＥ経路のサービス要求がエッジノード１１３からドメインＢ１０２のエッジノード１１１へＢＧＰ  ＵＰＤＡＴＥメッセージを経て搬送される。このＢＧＰ  ＵＰＤＡＴＥメッセージは、ネットワークレイヤ到達性情報フィールドにおける要求者を広告し、そしてこのドメインが以前に広告されたどのサービスを使用したいか指示する別の属性の経路要求を明示する。
１１．エッジノード１１１（例えば、ドメインＢ１０２のエッジにおけるＢＧＰルータ）は、サービス要求を受け取り、そしてそれを更なる処理のためにそのローカルコントロールエンティティ、即ちドメインコントローラ１０５へ転送する。
１２．ドメインコントローラ１０５は、サービス要求に従って最良のサービスを選択し、そしてドメインＢ１０２を横切るドメイン内経路を決定する。リソースは、それに応じて予約される。
１３．ドメイン間サービス要求がドメインコントローラ１０５から適当なエッジノード１０９へ送られる。
１４．サービス要求がＢＧＰ  ＵＰＤＡＴＥメッセージを経てエッジノード１０９からドメインＣ１０３のエッジノード１０７へ搬送され、これは、図２の規範的シナリオでは、行先ドメインである。
１５．エッジノード１０７は、サービス要求を受け取り、そしてそれを更なる処理のためにそのローカルコントロールエンティティ、即ちＮＭＳ１０６へ転送する。
１６．ＮＭＳ１０６は、ドメインＣ１０３を横切るドメイン内経路を計算しそして選択する。
【００６８】
図３は、図２に示して説明したステップの後に続くサービス受け容れ段階及び経路セットアップ段階を示す概略図である。図３に示すコンポーネントについては、図１、図２、及び前記説明を参照されたい。
【００６９】
従って、前記ステップNo.１６の後には、次のステップが行われる（番号は、図３に示した各ステップも指す）。
１７．ＮＭＳ１０６は、ドメインＣ１０３を横切るドメイン内経路を、データプレーンのノードにそれを適用することで、セットアップする。
１８．ＮＭＳ１０６は、要求を受け容れるためのメッセージを発生し、それをエッジノード１０７へ搬送する。
１９．エッジノード１０７は、エッジノード１０９に向けてＢＧＰ  ＵＰＤＡＴＥメッセージを経て受け容れメッセージを搬送する。
２０．エッジノード１０９は、エッジノード１０７から受け取ったメッセージをドメインコントローラ１０５に向けて転送する。
２１．ドメインコントローラ１０５は、要求を受け容れるためのメッセージを発生し、それをエッジノード１１１へ搬送する。
２２．ドメイン内経路がシグナリングされ、そしてドメインＢ１０２内でセットアップされる。
２３．エッジノード１１１は、受け容れメッセージをドメインＡ１０１のエッジノード１１３に向けてＢＧＰ  ＵＰＤＡＴＥメッセージを経て搬送する。
２４．エッジノード１１３は、エッジノード１１１から受け取ったメッセージをＮＭＳ１０４に向けて転送する。
２５．ＮＭＳ１０４は、ドメインＡ１０１を横切るドメイン内経路を、データプレーンのノードにそれを適用することで、セットアップする。
【００７０】
従って、サービス要求（図２に示すように搬送された）に対する受け容れメッセージは、サービス要求が受け取られた同じドメインチェーンを経て返送される。経路に沿って、各ドメインは、そのドメイン内経路、及び各ドメイン間ホップのローカル側をセットアップする。最終的に、要求者のドメインＡ１０１が受け容れメッセージを受け取ると、経路の生成が終了し、経路を使用する準備ができる。従って、ＮＭＳ１０４は、経路を要求したユーザに、セットアップ成功を通知し、経路の使用をイネーブルする（図示せず）。
【００７１】
経路生成中に欠陥が生じた場合、例えば、あるドメインについてドメイン内経路を計算できないか、又はオファーされたサービスが旧式であるか、又はその後のドメインが充分急速に応答しない場合には、受け容れメッセージではなく、拒絶メッセージを送信することができる。次いで、各ドメインは、予約したリソースを解除し、そして必要に応じて、利用できないサービスをデータベースから除去することができる。起点ドメインは、次に最良のルート候補を見つけると、要求側ユーザに相談せずに新たな経路を確立するように試みることができる。選択肢として、オファーされるサービスは、経路を確立する前に、ユーザにより検証することができる（例えば、接続の価格）。
【００７２】
経路は、単一のドメイン間経路に沿って各ドメイン内で異なる仕方でセットアップできることに注意されたい。
【００７３】
図１から図３に示す例では、ドメインＡ及びＣの各々は、ＮＭＳ（マネージメントプレーン）を経てドメイン内経路をセットアップし、そしてドメインＢは、例えば、ＲＳＶＰ−ＴＥのようなシグナリングプロトコルを使用することにより、即ちコントロールプレーンを経て、そのドメイン内経路をセットアップする。ＴＥデータベースと、マルチドメイン多制約ＴＥ経路を計算する能力とをもつＮＭＳ又は同様の単一コントロールエレメントを入手して使用することができるが、ドメインの所有者は、ドメイン内経路を決定するための異なる解決策を追求してもよい。ドメイン所有者は、例えば、拡張型ＯＳＰＦ−ＴＥを使用して、ドメイン内ＴＥ情報と、隣接ドメインが通常のトポロジー情報と共に提供（例えば、販売）しようとするサービスに関する情報とを配布することができる。次いで、経路計算のドメイン内部分を（ドメインのエントリポイントにおいて）進入ドメインルータにより実行することができる。ドメイントポロジーのサイズ及び複雑さに基づき、この進入ドメインルータは、著しい量の計算力を要求する。ドメイン内では、分散型経路選択方法（例えば、Zhenjiang Li、Garcia-Luna-Aceves、J. J.、A distributed approach for multi-constrained path selection and routing optimization. Proceedings of the 3rd international conference on Quality of service in heterogeneous wired/wireless networks、SESSION: Quality of service in wireline networks、論文No.３６、２００６年）を選択肢として使用することができる。
【００７４】
図５は、図１、図２及び図３によるドメイン１０１から１０３を示す概略メッセージチャートである。
【００７５】
広告段階５０１では、サービステンプレートがドメインを横切って搬送され、図示された例では、ドメインＣ１０３からドメインＢ１０２を経てドメインＡ１０１へ搬送される。サービステンプレートは、（変更された）ＢＧＰ  ＵＰＤＡＴＥメッセージを使用して転送することができる。
【００７６】
サービス要求段階５０２では、ドメインＡ１０１は、ドメインＢ１０２を経てドメインＣ１０３へサービス要求（テンプレート）を搬送する。サービス要求テンプレートは、（変更された）ＢＧＰ  ＵＰＤＡＴＥメッセージに埋め込むことができる。
【００７７】
サービス利用又はサービス取り扱い段階５０４では、サービス要求を受け容れて、ドメインＣ１０３からドメインＢ１０２を経てドメインＡ１０１へ受け容れメッセージ（テンプレート）を与える。この受け容れテンプレートは、（変更された）ＢＧＰ  ＵＰＤＡＴＥメッセージを経て搬送される。オファーされたサービスの受け容れは、図５に、サービス受け容れ段階５０３として要約される。しかしながら、サービスは、（種々の理由で）拒絶されることがあって、サービス取り扱い段階５０４に入るが、それに応じて搬送される異なるメッセージ、例えば、拒絶メッセージをトリガーすることに注意されたい。
【００７８】
受け容れメッセージがドメインＡ１０１に首尾良く配送される場合には、セットアップされた経路を経てサービスを利用することができ、これは、ドメインＡ１０１とドメインＣ１０３との間のデータ交換５０５で示される。
【００７９】
ｅＢＧＰサービス属性の設計は、例えば、どんな種類のビジネスモデルが選択されるか及びテンプレートがどのように使用されるかに依存する。
【００８０】
以下、幾つかの例を挙げる。各タイプのテンプレートは、好ましくは、サービス又は要求を詳細に明示するに充分な情報を搬送できると同時に、テンプレートは、ブロックに適合させてＢＧＰ  ＵＰＤＡＴＥメッセージと共に搬送できるに充分な小さいものである。単一のＢＧＰ  ＵＰＤＡＴＥメッセージのサイズは、特に、４０９６オクテットを含む。これが大きな制限と考えられる場合には、テンプレート（１つ又は複数）を複数のメッセージに分割することができる。
【００８１】
それらの例は、一部分は、ＥＴＮＡ（ＢＧＵ、ＢＴ、Ｅｔｈｏｓ、ＮＳＮ、ＴＫＫ、イーサネットトランスポートネットワーク、ネットワークのアーキテクチャー、ＷＰ２ネットワークアーキテクチャー、３１．１２．２００８；http://www.itc-etna.eu/documents/ETNA ＷＰ２ネットワーク及びサービスアーキテクチャーで入手でき、−Ｄ２．１  Ｒ２−Issue 2. pdf）に基づく。
【００８２】
全てのテンプレートは、好ましくは、オファーされるサービスのパラメータを定義する部分を有する。例えば、次のような異なるテンプレートがある。
−トランシットサービス又はアクセスサービスを広告し、
−以前に広告されたサービスを要求し、又は
−要求に応答する（即ち、それを利用し又は取り扱う）。
【００８３】
図６は、サービス要求又はサービスオファーの情報をもつ規範的なテンプレートを含むテーブルを示す。ＴＥ及びサービスパラメータ（例えば、価格）をサービス要求又はオファーに含ませることができ、又、サービス要求又はオファーに関する付加的な情報を含ませることもできる。
【００８４】
単一のテンプレートに多数のサービスオファー又はサービス要求を含ませることができる。テンプレートがＢＧＰ  ＵＰＤＡＴＥメッセージのサイズの限界に到達した場合には、サービスオファー又は要求を個別のテンプレート及び／又はメッセージに分割することができる。
【００８５】
又、テンプレートが、サービス要求又はサービスオファーのトラフィック特性に関する情報を含むという選択肢もある。
−そのようなトラフィック特性は、データソースで発生されるトラフィックに関する情報を搬送するＴＳＰＥＣオブジェクトを含む。このＴＳＰＥＣオブジェクトは、保証型又はコントロール型負荷ＱｏＳコントロールサービスにより使用可能なトラフィック情報を搬送する。そのようなＴＳＰＥＣオブジェクトに関する詳細については、ＲＦＣ２２１０“The Use of RSVP with IETF integrated Services”、第３．１章、を参照されたい。
−又、トラフィック特性は、受信者（１人又は複数）からネットワークへ予約要求をなすのに有用な情報を搬送するＦＬＯＷＳＰＥＣオブジェクトを含む。これは、どのＱｏＳコントロールサービスが要求されるかの指示と、そのサービスに必要なパラメータとを含む。そのようなＦＬＯＷＳＰＥＣオブジェクトの詳細については、ＲＦＣ２２１０、第３．２章を参照されたい。
−トラフィック特性は、帯域巾及び／又はデータレート情報を含む。
【００８６】
搬送、アクセス、要求及び応答テンプレートは、サービステンプレートの識別子（ＩＤ）及び／又は満了時間も含む。搬送テンプレート内では、接続ポイント、例えば、エッジノード又はＢＧＰルータを識別することができる。アクセステンプレートには、エンドホストをどこにマップできるか指示するアイデンティティ情報が与えられる。アグリゲーション情報又は他の種類の情報圧縮メカニズムを適用できることに注意されたい。そのようなアグリゲーション情報は、アグリゲートされた多制約経路に関する情報を含む。ドメインの異なるエリアが、より抽象的なサービスオファーで広告される場合には、ＱｏＳの実際のレベルが受け容れられることを確認するために、ある付加的な通信が要求される。
【００８７】
要求テンプレートは、要求者、要求番号、及び要求された（例えば、購入された）サービス詳細に関する情報を有する。ドメインを横切って要求が搬送される間に、各ドメインがその隣接ドメインに送る特定のサービスオファーに対する要求のように、その形態及び見掛けを変化させる。他の点では、受け容れ又は拒絶テンプレートは、サービス要求テンプレートと同様であるが、判断の理由を指示するある状態コード（例えば、ＨＴＴＰ形式の）にセットされた受け容れ又は拒絶値を有する。
【００８８】
図７は、テンプレートの規範的なフィールドを含むテーブルを示す。あるテンプレートの使用が少なくとも１つのフィールドも要求しない場合には、その値をゼロにセットすることができる。例えば、サービス広告については、要求者、応答、及び要求番号フィールドの値が各々“０”にセットされ、そして要求テンプレートについては、応答フィールドだけが“０”にセットされる。既存のサービスオファーを明確に削除するために、同様のテンプレートを、満了値が“０”にセットされた隣接部へ送ることができる。隣接部によってどんなサービスが現在オファーされているか問合せるために空のテンプレートを送ることができる。そのような問合せに対する返答は、“０”以外の値にセットされた応答値を有し、そして要求者及び要求番号フィールドは、各々、“０”にセットされる。
【００８９】
既存のＢＧＰ定義は、この解決策で示唆されるように、ＢＧＰメッセージにＴＥ属性を使用することにより修正することができる。そのようなＢＧＰ属性は、任意で且つ非推移のものであり、従って、ＢＧＰ仕様によれば、それを使用することは要求されず、そしてそれが認識されない場合には他のドメインへ更に送られることはない。
【００９０】
ＢＧＰルータは、それがＢＧＰ属性を認識すると、経路計算及び割り当てがこのドメインにおいてどのように行われるかに基づいて、それをＣＣＥへ転送するか、又はメッセージそれ自体を取り扱う。ＢＧＰは、その属性を他のＢＧＰルータへ転送せず、それをｉＢＧＰ又はｅＢＧＰとする。というのは、このＢＧＰルータは、それが直接的に販売するサービスしか広告しないからである。ＴＥ経路計算に分散型メカニズムを使用するときでも、テンプレート内の情報だけが他のルータへ配布される。このロジックに続いて、サービステンプレートを受け取る各ドメインは、ドメイン間リンクの（例えば、トラフィック）特性及び経費を考慮に入れる役割を果たす。
【００９１】
ピアｅＢＧＰルータが非デフォールトＢＧＰ機能をサポートするかどうか調べるため、能力ネゴシエーションと称される方法が実行される（ＲＦＣ３３９２“Capabilities Advertisement with BGP-4”を参照）。これは、ルータが最初にピア接続をなすときに遂行されるか、或いは後で遂行されて、ルーティングインフラストラクチャーに障害を生じることなく新たな特徴を使用できるようにする。この特徴を使用することにより、ＴＥＳ−ＢＧＰを徐々に採用して、隣接する初期の適応者だけがそこから利益を得られるようにする。
【００９２】
ここに述べる解決策は、特に、ドメイン間サービスを提供するドメインが非結合のままであり、即ちそれらの内部処理、例えば、ドメイン内経路計算を独立して維持し、及び／又は各ドメインがどのＣＣＥを使用すべきか決定できるという効果を有する。
【００９３】
別の効果は、ここに提示される解決策の柔軟性であって、ネットワークのコンポーネント、例えば、ドメインのエッジルータを更新することにより、既存のネットワークの機能を具現化できることである。
【００９４】
以上の説明は、本発明を例示したもので、本発明をそれに限定するものではないことを理解されたい。特に、３ドメインモデルを使用した規範的な説明は、それに限定されると考えてはならない。２つだけのドメイン又は４つ以上のドメインを種々の構成で使用する種々の変更及び用途が、当業者であれば、特許請求の範囲に規定された本発明の真の精神及び範囲から逸脱せずになし得るであろう。
【００９５】
略語のリスト：
ＢＧＰ：ボーダーゲートウェイプロトコル
ＣＣＥ：中央コントロールエンティティ
ＤＣ：ドメインコントローラ
ｅＢＧＰ：外部ＢＧＰ
ＥＭＳ：エレメントマネージメントシステム
Ｅ−ＮＮＩ：外部ネットワーク対ネットワークインターフェイス
ｉＢＧＰ：内部ＢＧＰ
ＭＴＯＳＩ：マルチテクノロジー・オペレーティングシステム・インターフェイス
ＮＭＳ：ネットワークマネージメントシステム
ＯＳＰＦ−ＴＥ：オープン・ショーテスト・パス・ファースト−トラフィックエンジニアリング
ＰＣＥ：経路計算エレメント
ＱｏＳ：サービス品質
ＲＳＶＰ−ＴＥ：リソース予約プロトコル−トラフィックエンジニアリング
ＳＬＡ：サービスレベルアグリーメント
ＳＭＳ：サービスマネージメントシステム
ＴＥ：トラフィックエンジニアリング
ＴＥＳ−ＢＧＰ：トラフィックエンジニアリングサービスの、ボーダーゲートウェイプロトコルへの拡張
ＵＮＩ：ユーザネットワークインターフェイス
【符号の説明】
【００９６】
１０１：ドメインＡ
１０２：ドメインＢ
１０３：ドメインＣ
１０４、１０６：ＮＭＳ
１０５：ドメインコントローラ
１０７−１１３：エッジノード
４０１、４０２、４０３：ドメイン
４０４−４１２：ネットワークエレメント
４１３−４２１：エレメントマネージメントシステム（ＥＭＳ）
４２２、４２３、４２４：ネットワークマネージメントシステム（ＮＭＳ）
４２５：サービスマネージメントシステム（ＳＭＳ）
【図１】
2015507404.tif 000003
【図２】
2015507404.tif 000004
【図３】
2015507404.tif 000005
【図４】
2015507404.tif 000006
【図５】
2015507404.tif 000007
【図６】
2015507404.tif 000008
【図７】
2015507404.tif 000009
【国際調査報告】
2015507404.tif 000010
2015507404.tif 000011
2015507404.tif 000012