JP2015526033A - 電気通信ネットワークにおいてリンク多様なトラフィック経路を確立するための方法および関連装置 - Google Patents

Abstract

オーバーレイモードにおいて動作する、ＧＭＰＬＳ制御プレーン対応のトランスポートネットワークに接続された、デュアルホームＵＮＩクライアントのための経路ダイバーシティを実現するために、光トランスポートネットワークにおける経路ダイバーシティのための共有制約情報を追加することによって、オーバーレイ拡張サービスモデルが強化される。とりわけ、プロバイダネットワーク内で、第１のトラフィック経路（ＬＳＰ１）の共有制約情報が決定され、共有制約情報を示すデータ要素が、第１のプロバイダエッジノード（ＰＥ１）によって、ユーザ−ネットワークインターフェースを介して、顧客エッジデバイス（ＣＥ１）に返信される。プロバイダネットワークを通る第２のトラフィック経路（ＬＳＰ２）が、第２のプロバイダエッジノード（ＰＥ２）から確立されるように、かつ前記第１のトラフィック経路（ＬＳＰ１）からディスジョイントであるように、顧客エッジデバイス（ＣＥ１）が要求するとき、共有制約情報を除外リストとして使用して第２のトラフィック経路の経路計算を可能にするために、顧客エッジデバイスは、データ要素を第２のプロバイダエッジノード（ＰＥ２）に転送する。

Description

本発明は、電気通信の分野に関し、より詳細には、電気通信ネットワークにおいてリンク多様なトラフィック経路を確立するための方法および関連装置に関する。

標準的なレイヤ１のトランスポートネットワークでは、すなわち、光トランスポートネットワーク（ＯＴＮ）または同期デジタルハイアラーキ（ＳＤＨ）などの、時分割多重化（ｔｉｍｅ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ：ＴＤＭ）および／または波長分割多重化（ｗａｖｅｌｅｎｇｔｈ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ：ＷＤＭ）を用いるネットワークでは、動的なリソース配分およびトラフィック経路のセットアップをサポートするための技術が確立されている。トラフィック経路が交換ネットワークを通して自動的にセットアップされるよう可能にするトランスポートネットワークは、自動交換転送ネットワーク（Ａｕｔｏｍａｔｉｃａｌｌｙ Ｓｗｉｔｃｈｅｄ Ｔｒａｎｓｐｏｒｔ Ｎｅｔｗｏｒｋ：ＡＳＴＮ）、または自動交換光ネットワーク（Ａｕｔｏｍａｔｉｃａｌｌｙ Ｓｗｉｔｃｈｅｄ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ：ＡＳＯＮ）と称される。ＷＤＭレイヤは、しばしばレイヤ０とも呼ばれる。

従来、一連のネットワーク要素を通るトラフィック経路の作成は、各ネットワーク要素上での個々の交差接続の構成を伴ってきた。ＡＳＴＮ／ＡＳＯＮにより、ユーザは、開始ポイント、エンドポイント、および必要な帯域幅を指定することが可能になり、ネットワーク要素上のＡＳＴＮ／ＡＳＯＮエージェントが、ネットワークを通る経路を配分し、トラフィック経路を供給し、交差接続をセットアップし、ユーザが要求したサービスのために経路から帯域幅を配分することになる。ネットワークを通してトラフィックが取ることになる実際の経路は、ユーザによって指定されるわけではない。

ＧＭＰＬＳ（Ｇｅｎｅｒａｌｉｚｅｄ Ｍｕｌｔｉｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）として知られるプロトコルスイートは、動的にリソースを供給し、保護および修復技法を使用してネットワーク生存性を提供するために開発されてきた。ＧＭＰＬＳは、３つの主要なプロトコルを含む：トラフィックエンジニアリング拡張を備えたリソースリザベーションプロトコル（ＲＳＶＰ−ＴＥ）として知られるシグナリングプロトコル、トラフィックエンジニアリング拡張を備えたオープンショーテストパスファースト（ＯＳＰＦ−ＴＥ）として知られるルーティングプロトコル、およびリンク管理プロトコル（ＬＭＰ）。

ＡＳＴＮ／ＡＳＯＮの基礎となるアーキテクチャは、転送（またはデータ）プレーンおよび分離された制御プレーンを想定し、ここでは、ネットワークレイヤの各々が、物理的に多様なデータプレーンまたは転送プレーンを使用することができる。ＧＭＰＬＳの焦点は、制御プレーンに置かれる。

さらに、仮想プライベートネットワーク（ＶＰＮ）の概念が、近年、レイヤ１ネットワークに拡張されている。レイヤ１ＶＰＮ（Ｌ１ＶＰＮ）は、２つ以上の顧客のサイトの間にレイヤ１の接続性を提供するために、コアレイヤ１ネットワークによって差し出されるサービスであり、ここで顧客は、接続性の確立およびそのタイプに対してなんらかの制御を有する（ＩＥＴＦ ＲＦＣ４８４７を参照されたい）。

ＧＭＰＬＳは、ラベルスイッチパス（Ｌａｂｅｌ Ｓｗｉｔｃｈｅｄ Ｐａｔｈ：ＬＳＰ）の作成のために、ルーティングプロトコルとシグナリングプロトコルの両方を定義している。ピアモデルでは、エッジノードは、ルーティングプロトコルとシグナリングプロトコルの両方をサポートする。エッジノードとコアノードとのプロトコルインタラクションは、２つのコアノード間と同じである。しかしながら、オーバーレイモデルでは、コアノードは、むしろ閉システムとしての働きをする。エッジノードは、コアノード同士の間で動くルーティングプロトコルのインスタンスに関与しない。とりわけ、エッジノードは、コアノードのトポロジには気付かない（ＩＥＴＦ ＲＦＣ４２０８を参照されたい）。

オーバーレイモデルでは、顧客エッジ（ＣＥ）デバイスが、ユーザ−ネットワークインターフェース（ＵＮＩ）上で、プロバイダエッジ（ＰＥ）デバイスに接続される。ＰＥエバイスは、ネットワーク−ネットワークインターフェース（ＮＮＩ）を介して、他のプロバイダ（Ｐ）デバイスに接続される。

現在のＵＮＩは、帯域幅要件、保護ニーズ、および（当然ながら）宛先などの制約の指定を含んだ、エンドツーエンド（すなわち、ＣＥツーＣＥ）サービスへの要求を容易にするための特徴を含む。他方で、現在のＮＮＩは、ルーティング情報をやり取りするための、ならびにエンドツーエンドサービスへの要求を容易にするための特徴を含む。

１つのＣＥデバイスが２つのＰＥデバイスに接続される場合、この構成は、デュアルホーミングと呼ばれる。デュアルホーミングは、一般に、単一点障害（たとえば、ＵＮＩリンクもしくはＰＥ）を回避するのに使用され、すなわち、２つがディスジョイントな接続であれば、保護グループを形成することになる。デュアルホームＣＥからの、ＬＳＰのためのルートダイバーシティは、光トランスポートネットワークにおいてよくある要件である。

欧州特許出願公開第２２６７９５４号明細書 米国特許出願公開第２００９／０１０３４４２号明細書 欧州特許第１４４３７１６号明細書

ＩＥＴＦ ＲＦＣ４８４７ ＩＥＴＦ ＲＦＣ４２０８ ＩＥＴＦ ＲＦＣ４２０２ ＩＥＴＦ寄稿、「ＲＳＶＰ−ＴＥ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｃｏｌｌｅｃｔｉｎｇ ＳＲＬＧ Ｉｎｆｏｒｍａｔｉｏｎ」、Ｆ．Ｚｈａｎｇら、ｄｒａｆｔ−ｚｈａｎｇ−ｃｃａｍｐ−ｓｒｌｇ−ｆａ−ｃｏｎｆｉｇｕｒａｔｉｏｎ−０５．ｔｘｔ、２０１２年３月 ＲＦＣ５２５１

本発明の課題は、オーバーレイモードにおいて動作する、ＧＭＰＬＳ制御プレーン対応のトランスポートネットワークに接続された、デュアルホームＵＮＩクライアントのための経路ダイバーシティを実現することである。

欧州特許出願公開第２２６７９５４号Ａ１は、あるソリューションを説明しており、そこでは、第１の接続が第１のリソースの組からのリソースのみを使用し、一方第２の接続が第２のリソースの組からのリソースのみを使用する場合に、ダイバーシティが実現されるようなやり方で、ネットワークリソースが異なる組のリソースに割り当てられる。これらの組は、２つの接続が異なるリソースの組を使用するという条件で、経路ダイバーシティが実現されるようなやり方で構築されなければならない。このソリューションは、ともかく限定的である。さらに、このソリューションは、より多くのネットワークリソースを必要とし、ネットワーク動作のみならず、ネットワーク立案プロセスにも追加的なペナルティを加える。

米国特許出願公開第２００９／０１０３４４２号Ａ１は、マルチドメインネットワークにおける制約ベースのルーティングを説明している。ドメイン内の接続経路について、経路によって使用されるリソースに関連付けられた共有リスクグループ（ｓｈａｒｅｄ ｒｉｓｋ ｇｒｏｕｐｓ：ＳＲＧ）の組が、収集され、そのドメインに関連付けられた共有リスクグループ管理デバイス内に格納される。共有リスクグループの組には、共有リスク識別コードが割り当てられる。共有リスク識別コードおよび共有リスクグループ管理デバイス識別子を収容しているリスク情報は、近接するドメインに伝達される。これにより、近接するドメインが、同じＳＧＲを共有することになるリソースを除外するために、リスク情報を使用することによって、経路がＳＲＧディスジョイントにルーティングされるよう要求することが可能になる。

以下で説明される実施形態では、デュアルホーミングを考慮したオーバーレイ拡張サービスモデル内で、ＬＳＰダイバーシティをサポートするために使用され得る、シグナリングのバリエーションを紹介する。

ＲＦＣ４８４７におけるＬ１ＶＰＮフレームワークは、ＣＥデバイスとＰＥノードとの間のインターフェースとして働くＵＮＩオーバーレイ（ＲＦＣ４２０８）に基づく、オーバーレイ拡張サービスモデルを説明している。このサービスモデルにおいて、ＣＥは、それがＬ１ＶＰＮ接続を要求することができる先の、ＣＥ−ＰＥ ＴＥリンクアドレスのリスト（すなわち、メンバーシップ情報）を受信し、これらのＴＥリンクに関する追加的な情報を含めることができる。説明される実施形態はさらに、光トランスポートネットワークにおける経路ダイバーシティのための共有制約情報を追加することによる、オーバーレイ拡張サービスモデルに基づく。これにより、異なるネットワークのエントリポイントは、異なるネットワークエントリポイントを有するネットワークを通る既存の経路に対して、多様な経路を計算することが可能になる。

とりわけ、プロバイダネットワーク内で、第１のトラフィック経路の共有制約情報が決定され、共有制約情報を示すデータ要素が、第１のプロバイダエッジノードによって、ユーザ−ネットワークインターフェースを介して、顧客エッジデバイスに返信される。共有制約情報は、第１のトラフィック経路によって使用されるすべてのプロバイダネットワークリンクの共有リスクリンクグループ識別子を収容し、データ要素は、第１のトラフィック経路の共有リスクリンクグループ識別子の非順序リストを収容している。プロバイダネットワークを通る第２のトラフィック経路が、第２のプロバイダエッジノードから確立されるように、かつ前記第１のトラフィック経路からディスジョイントであるように、顧客エッジデバイスが要求するとき、共有制約情報を除外リストとして使用して第２のトラフィック経路の経路計算を可能にするために、顧客エッジデバイスは、データ要素を第２のプロバイダエッジノードに転送する。

次に、本発明の好ましい実施形態が、添付の図面を参照して説明される。

例示的なネットワークトポロジを示す図である。 共有制約情報をやり取りするための第１のシグナリングバリアントを示す図である。 顧客エッジデバイスに、および顧客エッジデバイスから、共有制約情報をシグナルするために使用される、新しいＬ１ＶＰＮのＤｉｖｅｒｓｅ ＬＳＰ ＬＡＢＥＬオブジェクトを示す図である。 共有制約情報をやり取りするための第２のシグナリングバリアントを示す図である。 プロバイダエッジノードのブロック図である。 顧客エッジデバイスのブロック図である。

簡略化されたネットワークの例が、図１に示されている。第１の顧客エッジデバイスＣＥ１が、デュアルホーム構成において、第１のプロバイドエッジノードＰＥ１、および第２のプロバイドエッジノードＰＥ２に接続される。第２の顧客エッジデバイスＣＥ２が、プロバイダエッジノードＰＥ３、ＰＥ４に接続される。プロバイダネットワークは、プロバイダコアノードＰ１−Ｐ４を収容している。プロバイダエッジノードＰＥ１−ＰＥ４およびプロバイダコアノードＰ１−Ｐ４は、簡略化のために示されていないメッシュトポロジにおいて、相互接続されている。ＰＥ１、Ｐ１、Ｐ２、およびＰＥ３を介したＣＥ１とＣＥ２との接続は、ラベルスイッチパスＬＳＰ１上で、ならびにＰＥ２、Ｐ３、Ｐ４、およびＰＥ４を介したＣＥ１とＣＥ２との接続は、ラベルスイッチパスＬＳＰ２上で確立される。ラベルスイッチパスＬＳＰ１およびＬＳＰ２は、リンク多様であり、その結果、２つの接続についての単一点障害は存在しない。

顧客エッジデバイスＣＥ１、ＣＥ２と、プロバイダエッジノードＰＥ１、ＰＥ２、ＰＥ３、ＰＥ４との間のインターフェースは、それぞれ、ユーザ−ネットワークインターフェースＵＮＩであり、一方、プロバイダエッジノードＰＥ１−ＰＥ４と、プロバイダコアノードＰ１−Ｐ４との間のインターフェースは、ネットワーク−ネットワークインターフェースＮＮＩである。

ＮＮＩ上で、すべてのプロバイダノードＰＥ１−ＰＥ４、Ｐ１−Ｐ４は、ＯＳＰＦ−ＴＥなどのルーティングプロトコルを使用してルーティングプロトコルメッセージをやり取りして、トポロジ情報およびリンク状態情報をアドバタイズし、情報は、各プロバイダノードＰＥ１−ＰＥ４、Ｐ１−Ｐ４において、ローカルルーティングデータベースをポピュレートするために使用される。そのようなルーティングメッセージは、すべての他のプロバイダノードにブロードキャストされ、その結果、ルーティングメッセージをリスンすることによって、すべてのプロバイダノードは、プロバイダネットワーク全体について同じトポロジ情報およびリンク状態情報を共有する。用語、ルーティングデータベースは、本明細書で使用されるとき、ＰＥノードに格納されたすべてのルーティング情報の総和を指し、隣接データベース、リンク状態データベース、およびトラフィックエンジニアリングデータベースを含むことができる。

しかしながら、ＵＮＩ上では、そのようなルーティング情報はやり取りされず、その結果、ＣＥデバイスＣＥ１、ＣＥ２は、プロバイダネットワークについてのいかなるトポロジ情報およびリンク状態情報も受信しない。これは、意図的であり、その理由は、プロバイダはその顧客に対して、トポロジおよびリソース使用についての情報を利用可能にさせたくないからである。オーバーレイモデルでは、ＣＥとＰＥとの間でやり取りされる情報は、最小限に保たれる。

例として、図１において、ＬＳＰ１が最初にセットアップされると想定される。したがって、ＣＥ１は、ＣＥ２への接続のための要求をＰＥ１に送信している。ＰＥ１は、そのローカルルーティングデータベースを使用してラベルスイッチパスを計算し、次いで、たとえばＲＳＶＰ−ＴＥを使用してシグナリングメッセージを送出し、計算された経路、すなわち、本例におけるＬＳＰ１を作成する。

第２のステップで、ＣＥ１は、第２のＬＳＰ、すなわちＬＳＰ２をセットアップするよう意図することがさらに想定され、ＬＳＰ２は、両方のＬＳＰについて単一点障害を除外するために、ディスジョイントであるものとする。ＣＥ１は、したがって、第２の接続要求をＰＥ２に送信することになる。

しかしながら、ＣＥ１は、ＮＮＩ上でのルーティングプロトコルに関与しないので、ＬＳＰ１によって使用されるリソースについての知識を有することはできない。他方で、ＰＥ２は、ＣＥ１がＰＥ１を介してデュアルホームであるという事実についての知識を有さない。したがって、ＣＥ１がＰＥ２に、リンクディスジョイントな接続を単に要求する場合、ＰＥ２は、ＰＥ１におけるＬＳＰ１の存在について知ることができず、確立されるべきＬＳＰ２が、ＬＳＰ１からリソースディスジョイントである必要があることを知ることができない。

１つのオプションは、ＣＥ１が、ＰＥ２への接続要求において、新しい接続が、ＰＥ１から確立されている既存の接続からディスジョイントであるとすることを指し示すことだろう。ＰＥ２はその場合、どのリソースがＬＳＰ１によって使用されているか、およびしたがって、どのリソースがＬＳＰ２のための経路計算から除外される必要があるかを習得するために、ＰＥ１と直接通信することができる。そのような直接通信が、欧州特許第１４４３７１６号Ｂ１で言及されている。しかしながら、これは、現在存在していない、ＰＥ−ＰＥ通信用の新しいプロトコルの定義および実装を必要とすることになる。

本発明者は、したがって、デュアルホーミングを考慮したオーバーレイ拡張サービスモデル内でのＬＳＰダイバーシティをサポートするための、改善されたメカニズムを考え、それは、既存のプロトコルに基づき、ＣＥが、共有制約情報を示すデータをＰＥに提供することを可能にするものである。

より詳細には、好ましい実施形態は、引用により本明細書に組み込まれているＩＥＴＦ ＲＦＣ４２０２で定義される、共有リスクリンクグループ（ＳＲＬＧ）情報を使用する。

リンクの組が、その障害がその組のすべてのリンクに影響し得るリソースを共有する場合に、共有リスクリンクグループ（ＳＲＬＧ）を構成することができる。たとえば、同じコンジットにおける２つのファイバは、同じＳＲＬＧにあることになる。リンクは、複数のＳＲＬＧに属してもよい。したがって、ＳＲＬＧ情報は、そのリンクが属するＳＲＬＧのリストを記述する。ＳＲＬＧは、内部ゲートウェイプロトコル（Ｉｎｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ：ＩＧＰ）ドメイン内で一意である３２ビット識別子によって識別される。ＳＲＬＧ情報は、そのリンクが属するＳＲＬＧの非順序リストである。ＬＳＰのＳＲＬＧは、ＬＳＰにおけるリンクのＳＲＬＧの結合体である。束ねられたリンクのＳＲＬＧは、すべてのコンポーネントリンクのＳＲＬＧの結合体である。

リンクＳＲＬＧは、ルーティングプロトコルにおいてアドバタイズされ、したがって、各ＰＥノードのルーティングデータベースにおいて利用可能である。経路要求を処理し、経路計算を実施するＰＥノードは、したがって、そのローカルな情報から、計算されたＬＳＰのＳＲＬＧを決定することができる。ＳＲＬＧ情報は、通常、トランスポートネットワークと顧客ネットワークとの間で共有されず、すなわち、Ｌ１ＶＰＮコンテキストにおけるＬ１ＶＰＮのＣＥと共有されない。

以下では、ＧＭＰＬＳ制御されたトランスポートネットワークにおいて、ＧＭＰＬＳが、経路ダイバーシティを提供するのを可能にするために使用され得る、２つの異なるシグナリングのバリエーションが説明される。

２つの接続が異なるＰＥデバイスにおいてプロバイダネットワークに入っていくとき、異なるＰＥデバイスにおいてネットワークに入る既に確立された第１の接続に対して、第２のＬＳＰの経路がディスジョイントであるように、第２の接続を求める接続要求を受信するＰＥデバイスは、追加的な経路計算制約を決定することができる必要がある。好ましい実施形態による方法は、ＰＥデバイスが、異なるＰＥデバイスでネットワークに入っていく、プロバイダネットワークにおける接続のためのＳＲＬＧ情報を決定するのを可能にする。

説明される方法は、ダイバーシティを実現するためにＰＥネットワークにおいて共通のメカニズムを利用する点では類似しているが、それらの方法は、ＣＥが、ＬＳＰのためのプロバイダＳＲＬＧダイバーシティ情報をＰＥ１から取り出して、それをＰＥ２に伝えることを許可される（すなわち、ＳＲＬＧ情報はＣＥと共有される）か、または新しい属性が使用されて、それにより、この属性を受信するＰＥが、この新しい属性値に基づいてＬＳＰのためのＳＲＬＧ情報を導出することを可能にするかの、いずれかによって区別される。これらの方法の選択は、ＰＥネットワーク固有のポリシーと、取られるアプローチの両方（すなわち、プロバイダが、自身のネットワークの内側でのルーティングをどのように選んで実施するかという点で）によって左右される。

第１の実施形態において、プロバイダ共有リソースリンクグループ（ＳＲＬＧ）識別子情報が、ＣＥに利用可能であると共に共有可能であると想定されることになる。これは、プロバイダのポリシー決定であるとする。第１の実施形態において、ＳＲＬＧ ＩＤは、したがって、ＵＮＩメッセージ上でシグナルされた情報として使用され、デュアルホームＣＥを介して、ＰＥ同士の間に透過的に渡されることになる。

第２の実施形態において、プロバイダＳＲＬＧ ＩＤは、（プロバイダネットワークオペレータポリシーに基づいて）ＣＥに利用可能でもなく、共有可能でもないと想定される。このケースについては、ＵＮＩメッセージ上でＰＥにシグナルされた情報が、オーバーレイ拡張モデルのためのＬＳＰダイバーシティをサポートするためにプロバイダＳＲＬＧ ＩＤの共有知識を必要としない、メカニズムが説明される。両方のアプローチは、引用により本明細書に組み込まれているＲＦＣ４８４７で定義されているＬ１ＶＰＮフレームワークに従う。両方の方法は、同じＰＥネットワークにおいて実装され得るが、Ｌ１ＶＰＮ ＣＥネットワークは、一度には１つのメカニズムのみを使用するものと思われる。

ＰＥ ＳＲＬＧ情報は、ＣＥがそのコンテキストを理解する場合に、ＣＥによって直接使用されてよく、ＣＥの観点は、そのＬ１ＶＰＮのコンテキストに限定される。このケースでは、プロバイダ情報への依存性が存在し、したがって、プロバイダネットワークにおいてＳＲＬＧを照会することができることが好ましい。

他方で、この依存性を回避し、かつ、プロバイダネットワークで使用されるＳＲＬＧ識別子空間を、顧客ネットワークで使用されるＳＲＬＧ空間から切り離すことが好ましいことがある。これは、以下で詳述される両方の方法で可能である。プロバイダＳＲＬＧ情報がＣＥデバイスを通過している場合の方法についてでさえ、２つのＳＲＬＧ識別子空間は完全に切り離されたままであってよく、顧客ネットワークのオペレータは、顧客ＳＲＬＧ識別子空間から、プロバイダネットワークを通過しているＣＥツーＣＥ接続に、ＳＲＬＧ識別子を割り当てることが自由である。ＣＥデバイスが、ＳＲＬＧ情報を処理することも復号することも必要ないことは、言及に値する。

説明されるメカニズムはまた、２つのＣＥデバイスが２つの異なるＰＥデバイスに接続されるシナリオに適用されてもよい。このケースでは、プロバイダネットワークにおいて所望のダイバーシティを実現するために、ＵＮＩインターフェースをまたいでやり取りされる追加的な情報もまた、２つのＣＥデバイスの間でやり取りされる必要がある。

この情報は、この文書の範囲を超える、たとえば、リンク状態データベースまたはネットワーク管理の、なんらかの自動化メカニズムによって構成される、またはやり取りされてもよいが、これらは、必要以上に実験することなく、以下の説明に基づいて当業者によって実装されてよい。

次に、ＣＥデバイスを介して、ＰＥの間でＳＲＬＧ情報のやり取りを用いる第１の実施形態が、より詳細に説明される。

ＳＲＬＧ情報は、ＲＦＣ４２０２で定義されており、ＬＳＰのＳＲＬＧ情報が知られている場合、情報は、既存のＬＳＰに対してＳＲＬＧ多様な別のＬＳＰのための経路を計算するために使用されてよい。

たとえば、図１のＣＥ１は、ＰＥ１およびＰＥ３を介した、ＣＥ１からＣＥ２へのＬＳＰ１を要求していてよい。ＣＥ１は続いて、ＰＥ２およびＰＥ３を介した、ＣＥ２へのＬＳＰ２を、ＬＳＰ２がＬＳＰ１に対して最大限ＳＲＬＧディスジョイントであるべきであるという要件を付けて、要求することができる。ＰＥ２は、ＬＳＰ１についてなんの情報も有さないので、ＰＥ２は、ＬＳＰ１に関連付けられたＳＲＬＧ情報を知る必要があることになる。本実施形態によれば、ＣＥ１は、ＬＳＰ１のＳＲＬＧ情報を、ＰＥ１に要求することになり、次いでこの情報を、ＬＳＰ２セットアップ要求の一部として、ＰＥ２に透過的に渡す。ＰＥ２はしたがって、ＬＳＰ１に対してＳＲＬＧディスジョイントであるＬＳＰ２のための経路を計算することが可能である。

ＳＲＬＧ情報のやり取りは、既存のＲＳＶＰ−ＴＥシグナリング手順を使用して、Ｌ１ＶＰＮ ＬＳＰごとに実現される。ＳＲＬＧ情報は、元の要求においてＰＡＴＨメッセージ（除外情報）もしくはＲＥＳＶメッセージでやり取りされてもよいし、または、経路がアクティブである任意の時間にＣＥによって要求されてもよい。

ＳＲＬＧ情報は、ＳＲＬＧ識別子の非順序リストであり、ＲＳＶＰシグナリングのためのＳＲＬＧ情報の符号化は、引用により本明細書に組み込まれている、Ｆ．ＺｈａｎｇらによるＩＥＴＦ寄稿、「ＲＳＶＰ−ＴＥ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｃｏｌｌｅｃｔｉｎｇ ＳＲＬＧ Ｉｎｆｏｒｍａｔｉｏｎ」、ｄｒａｆｔ−ｚｈａｎｇ−ｃｃａｍｐ−ｓｒｌｇ−ｆａ−ｃｏｎｆｉｇｕｒａｔｉｏｎ−０５．ｔｘｔ、２０１２年３月で定義されていることに留意されたい。しかしながら、たとえＳＲＬＧ情報がいくつかのＬＳＰのために知られていたとしても、この情報からは、プロバイダネットワークトポロジの非常に限定された観点しか利用可能でない。

第１の実施形態において、以下のルールがＣＥ−ＰＥ挙動に適用されることになる。

デュアルホームＵＮＩ−Ｃが、別のＰＥノードを介して、同じ宛先ＵＮＩ−ＣへのＬＳＰを確立することを意図するとき、デュアルホームＵＮＩ−Ｃは、ＲＳＶＰ ＰＡＴＨメッセージのＬＳＰ属性サブオブジェクトにおいて、ＳＲＬＧ情報フラグを設定することによって、既に確立されたＬＳＰのためのＳＲＬＧ情報を要求することができる。

ＳＲＬＧ情報フラグがＰＡＴＨメッセージにおいて設定される限り、ＰＥノードは、ｄｒａｆｔ−ｚｈａｎｇ−ｃｃａｍｐ−ｓｒｌｇ−ｆａ−ｃｏｎｆｉｇｕｒａｔｉｏｎ−０５．ｔｘｔにおいて定義されるようなＳＲＬＧサブオブジェクトを、ＬＳＰのための現在のＳＲＬＧ情報を収容しているＲＳＶＰ ＲＥＳＶメッセージに挿入する。ＰＥは、ＬＳＰのためのＳＲＬＧ情報を伝える。

プロバイダネットワークのポリシーが、ＳＲＬＧ情報を顧客ネットワークと共有しないように構成されている場合、ＳＲＬＧ情報フラグが設定されていたとしても、ＳＲＬＧサブオブジェクトはＰＡＴＨメッセージに挿入されない。

別のＰＥデバイスを介してネットワークに入っていく既存のＬＳＰに対して、ＳＲＬＧ多様であるよう要求される新しいＬＳＰのために、デュアルホームＣＥデバイスがＬＳＰセットアップ要求をＰＥデバイスに送信するとき、ＵＮＩ−Ｃは、この新しいＬＳＰのセットアップを開始する、ＰＡＴＨメッセージのＬＳＰ属性サブオブジェクトにおけるＳＲＬＧダイバーシティフラグを設定する。ＰＥデバイスがこの要求を受信するとき、ＰＥデバイスは、所与の宛先までの経路を計算し、受信されたＳＲＬＧ情報を経路計算制約として使用する。ディスジョイントＬＳＰが見つからない場合、ＰＥは、エラーメッセージを返信することになる。

ＳＲＬＧ情報ダイバーシティフラグは、ＲＳＶＰプロトコルに対して新規であり、適宜に定義される必要がある。

次に図２を見てみると、図１の特定の例における通信は以下となる。

ＣＥ１は、ＳＲＬＧ情報フラグが設定された、ＬＳＰ１のためのＲＳＶＰ ＰＡＴＨメッセージ（図示せず）を、ＰＥ１に送信している。ＰＥ１は、ＬＳＰ１のＳＲＬＧサブオブジェクトを収容するＲＥＳＶメッセージＲＭ１で返答する。

次のステップで、ＣＥ１は、ディスジョイントな経路ＬＳＰ２のセットアップを要求するために、ＰＡＴＨメッセージＰＭ２をＰＥ２に送信する。ＣＥ１は、ＰＡＴＨメッセージＰＭ２のＬＳＰ属性サブオブジェクトにおいてＳＲＬＧダイバーシティフラグを設定し、受信されたＳＲＬＧサブオブジェクトを追加する。ＰＥ２は次いで、受信されたＳＲＬＧを除外リストとして使用してＬＳＰ２を計算する。

ＰＥ２がＬＳＰ２を確立したとき、ＰＥ２は、ＬＳＰ２のＳＲＬＧサブオブジェクトを含むＲＥＳＶメッセージＲＭ２を、ＣＥ１に返信する。ＣＥ１は、ＰＡＴＨメッセージＰＭ１においてこの情報をＰＥ１に伝える。

ＰＥ１およびＰＥ２はそのとき、ＬＳＰ１、ＬＳＰ２の両方のＬＳＰのＳＲＬＧリストについて知ることになり、その結果、たとえば、障害の場合の修復シナリオにおいて、ＬＳＰのうちの１つがリダイレクトされなければならない場合、もう一方のＬＳＰのＳＲＬＧリストが、リダイレクトされたＬＳＰの経路計算のための除外リストとして使用されてよい。

第１の実施形態は、経路ＬＳＰ１のためのＳＲＬＧリストをＵＮＩ上でＣＥに直接渡すが、以下で説明される第２の実施形態は、経路アフィニティ設定識別子と呼ばれる新しい識別子を導入しており、経路アフィニティ設定識別子はＳＲＬＧリストを参照し、ＳＲＬＧリストの代わりに通信される。

経路アフィニティ設定（Ｐａｔｈ Ａｆｆｉｎｉｔｙ Ｓｅｔ：ＰＡＳ）は、ＳＲＬＧ情報を抽出することによって、純粋なＣＥコンテキストにおけるダイバーシティをシグナルするために使用される。ＰＡＳにおいては２つのタイプのダイバーシティ情報が存在する。第１のタイプの情報は、単一のＰＡＳ識別子である。オプションで、除外される経路または経路の組のより詳細なＰＡＴＨ情報が指定されてもよい。ＰＡＳ情報の裏にある動機は、Ｌ１ＶＰＮ ＣＥ要素とＰＥ要素との間で、可能な限り少ないダイバーシティ情報のやり取りしか持たないことである。

詳細なＣＥまたはＰＥのＳＲＬＧリストよりもむしろ、経路アフィニティ設定は、所与の経路を多様であるように関連付ける抽象的なＳＲＬＧ識別子を収容している。論理的に、識別子はＬ１ＶＰＮのコンテキストにあり、したがって、特定のＬ１ＶＰＮに対して一意であるにすぎない。

ＣＥがどのようにしてＰＡＳ識別子を決定するかは、ＣＥアドミニストレータにとってのローカルな問題である。ＣＥは、ＰＡＴＨメッセージにおいて、ダイバーシティオブジェクトとしてＰＡＳをシグナルすることができる。この識別子は、示唆された識別子であり、いくつかの条件下では、ＰＥによって無効にされてもよい。

たとえば、ＰＡＳは、ＣＥとＰＥとの間で事前のＰＡＳ情報のやり取りなしに使用されてよい。ＰＡＳ情報が受信されると、ＰＥは、ＣＥ要件を推測することができる。使用される実際のＰＡＳ識別子は、ＲＥＳＶメッセージにおいて返信されることになる。オプションで、空のＰＡＳ識別子により、ＰＥは、ＰＡＳ識別子を選ぶことが可能になる。ＳＲＬＧ情報を使用する第１の実施形態と同様に、ＰＥは、柔軟性を可能にする照会に対する応答として、ＰＡＳ識別子を返信することができる。

ＰＥは、特定のＰＡＳ識別子、たとえば「１２３」が、その識別子、および関連付けにより、Ｌ１ＶＰＮに割り当てられたリソースに関連付けられたあらゆるＬＳＰのためのあらゆるＰＥ関連ＳＲＬＧ情報を、除外することを意味するように解釈する。たとえば、識別子「１２３」を有するＬＳＰのための経路が存在する場合、ＰＥは、「１２３」ＬＳＰに関連付けられたＰＥ ＳＲＬＧのローカルな知識を使用し、経路要求におけるそれらのＳＲＬＧを除外することになる。言い換えれば、多様である必要がある２つのＬＳＰがどちらも「１２３」をシグナルし、ＰＥは、これを、共有リソースを使用しないことを意味するように解釈する。代替として、ＰＥは、ＰＡＳ識別子を使用して、既に確立されたＬＳＰから選択することができる。経路が確立されると、それは、「１２３」識別子に、またはオプションで、そのＬ１ＶＰＮのための別のＰＡＳ識別子に関連付けられるようになる。

ＰＡＳ送信元および宛先アドレスタプルは、ＣＥ経路アフィニティ設定識別子に関連付けられた、１つまたは複数の送信元アドレスおよび宛先アドレスを表す。これらの関連付けられたアドレスタプルは、現在のＬＳＰの確立のために除外されるべきリソースを使用する経路を表す。アドレスタプル情報は、経路ダイバーシティ要求についてよりきめの細かい詳細を与えると共に、ＰＡＳ識別子がＰＥによって知られていないときの場合に、代替の識別子として働く。シグナリングに使用されるアドレスタプルは、ＣＥコンテキスト内にあり、その解釈は、ＣＥから経路要求を受信するＰＥにローカルである。ＰＥは、アドレス情報を使用して、ＰＥアドレスとＰＥ ＳＲＬＧ情報とを関連させることができる。ＰＥが、（ＳＲＬＧ）多様なシグナルされた経路のための接続セットアップを満たすとき、ＰＥは、オプションで、ＰＥベースのパラメータの点においてその接続のためのＰＥ ＳＲＬＧ情報を記録し、それをＰａｔｈメッセージのＣＥアドレスに関連付けることができる。

ＲＦＣ５２５１で定義されているＬ１ＶＰＮポート情報テーブル（Ｐｏｒｔ Ｉｎｆｏｒｍａｔｉｏｎ ｔａｂｌｅ：ＰＩＴ）は、ＣＥベースのアドレスとＰＥベースのアドレスとを変換するために活用されてよい。ＰＥ ＳＲＬＧ情報を含む経路アフィニティ設定および関連付けられたＰＥアドレスは、プロバイダトランスポートネットワークにおけるＩＧＰを介して配布されても、または構成などの他の手段によって配布されてもよい。それらは、経路／接続ダイバーシティを要求することになる他のＣＥ経路がセットアップされるときに、他のＰＥによって利用されてよい。この情報は、Ｌ１ＶＰＮベースで配布され、ＰＡＳ識別子、ＰＥアドレス、およびＳＲＬＧ情報を収容している。

ＣＥ経路アフィニティ設定は、ＣＥ送信元および宛先アドレスなしで、経路をシグナルするために使用されてよい。しかしながら、ＰＥは、好ましくは、ＣＥ ＳＲＬＧグループを、このＬＳＰに関連付けられたＰＥアドレスに加えて、ＰＥ ＳＲＬＧのリストに関連付けることになる。

ダイバーシティがシグナルされない場合、要求されるダイバーシティはないと想定され、プロバイダネットワークは自由にＬＳＰをルーティングして、トラフィックを最適化する。これらのＬＳＰのために記録されることが必要な経路アフィニティ設定情報はない。ダイバーシティオブジェクトが接続要求に含まれている場合、プロバイダネットワークのＰＥは、プロバイダネットワークから既存のプロバイダＳＲＬＧ情報をルックアップし、他のＬＳＰから最大限に多様であるＬＳＰを選ぶことが可能なはずである。

図３は、ＣＥとＰＥとの間のＵＮＩ上の通信に使用されてよい、Ｄｉｖｅｒｓｅ ＬＳＰ情報オブジェクトを示す。オブジェクトは、以下のフィールドを収容している。

１．アドレス長フィールド（８ビット）は、送信元アドレスおよび宛先アドレス両方のためのバイトの数である。アドレスは、１から３２バイトまでの任意のフォーマットであってよいが、重要な点は、顧客がこれらの既存のアドレスを維持することができることである。０の値は、含まれるアドレスがないことを指し示す。

２．経路アフィニティ（８ビット）設定の数がオブジェクトに含まれる。この数は、通常１である。それは、リンク多様にルーティングされる必要がある、１よりも多い他のＬＳＰがあることを指し示すために使用されてもよい。

３．経路アフィニティ設定識別子（４バイト）は、この経路のための総和されたＳＲＬＧを表す単一の数である。その同じ経路アフィニティ設定を有する経路は、多様な経路でセットアップされ、経路アフィニティ設定に関連付けられるべきである。すべて０の値は、ＰＥが、返信するためのＰＡＳ識別子を選ぶのを可能にする。確立された経路のＰＡＳ識別子は、要求された経路識別子とは異なることがある。

４．ダイバーシティビット（Ｄ）（１ビット）は、１として設定されるとき、ダイバーシティが満たされなければならないかどうかを指し示す。ＰＥが、シグナルされた経路アフィニティ設定またはシグナルされたアドレスタプルに適合する経路アフィニティ設定により確立される経路を見つけた場合、ＰＥは、多様な経路を見つけるように試みるべきである。

５．Ｄｉｖｅｒｓｅ Ｐａｔｈ送信元アドレス／宛先アドレスタプルは、同じ経路アフィニティ設定識別子に属する、ＰＥネットワークにおいて確立されるＬＳＰのアドレスタプルである。これらのアドレスについての経路が、セットアップされていない、またはＵＮＩを処理するＰＥエッジによって決定され得ない場合、経路は、経路アフィニティ設定制約のみによる。これらのアドレスタプルについての経路が、ＰＥによって知られている場合、ＰＥは、これらのアドレスに関連付けられたＳＲＬＧ情報を使用する。いずれのケースでも多様な経路がセットアップされ得ない場合、Ｄｉｖｅｒｓｅビットは、なんらかのやり方で経路が確立されるかどうかを制御する。ＰＥは、プロバイダＳＲＬＧ情報と相関させるとき、ＣＥアドレスをプロバイダアドレスに変換するためのメカニズムを使用しなければならない。

他の意味規則についての他の制御ビットが、必要に応じて追加されてもよい。たとえば、純粋に多様な経路が利用可能でない場合、最小限に交差する経路を見つける。あるいは、ＰＡＳ識別子が無効にされることを許可しない。後者は、ＣＥが構成される場合に有益であってよい。

第２の実施形態において、以下のルールがＣＥ−ＰＥ挙動に適用されることになる。

ＵＮＩ−ＣがＰＡＴＨメッセージを構築するとき、ＵＮＩ−Ｃは、オプションで、経路アフィニティ設定を指定し、ＰＡＴＨメッセージに挿入することができる。この経路アフィニティ設定は、オプションで、同じ経路アフィニティ設定に属することができるＬＳＰのアドレスを含むことができる。経路アフィニティ設定識別子は、ＣＥまたはＰＥがダイバーシティのために使用するメカニズムから独立している、値（１から２^３２−２５５）である。経路アフィニティ設定は、ダイバーシティを要求し、ダイバーシティを関連付けるために使用され得る単一の識別子を収容している。０の値は、ＰＥが値を割り当てることができることを意味する特殊な値である。

Ｌ１ＶＰＮオーバーレイにおいてＣＥ ＰＡＴＨメッセージを処理するとき、ＰＥは、最初にプロバイダインデックステーブル（Ｐｒｏｖｉｄｅｒ Ｉｎｄｅｘ Ｔａｂｌｅ：ＰＩＴ）において、ＰＥベースのアドレスをルックアップする。経路アフィニティ設定がＰＡＴＨメッセージに含まれる場合、ＰＥは、経路アフィニティ設定に関連付けられたＬＳＰによって配分されているＰＥネットワークにおいてＳＲＬＧ情報（または同等のもの）をルックアップして、それが新しい経路であれば、このＬＳＰについての経路計算から、それらのリソースを除外しなければならない。ＰＥは代替として、リソースのディスジョイントな組を有する既存の経路から選ぶことができる。ディスジョイントである経路が見つけられない場合、ＰＡＳダイバーシティビットの値が、経路がなんらかのやり方でセットアップされるべきかどうかを判定する。ＰＡＳダイバーシティビットがクリアであれば、依然ＬＳＰをセットアップするよう試みることができる。ＰＥはなお、共有リソースを最小限にするよう試みるべきである。他方で、ＰＡＳダイバーシティビットが設定されている場合、ＰＥはエラーコードを返信することになる。

オプションで、ＣＥは、ＰＡＳ識別子においてすべて０の値を使用して、ＰＥが、適切なＰＡＳ識別子を選択するのを可能にすることができる。また、ＰＥは、ＰＡＳ識別子を無効にすることを選んで、必要であれば、ＰＥが識別子を再割り当てするのを可能にすることができる。ＣＥは、セットアップに使用されるＰＡＳ識別子が、実際のＰＡＳ識別子であることは想定すべきではない。ＰＡＳオブジェクトは、ＰＥデバイスによって理解されなければならない。そうでない場合、ＣＥは、ＰＡＳオブジェクトを使用すべきでない。ＰＡＳオブジェクトのＰａｔｈメッセージ処理は、ＣＴＹＰＥ０（あらかじめ決められたデフォルト手順）に従うべきである。別の特定のエラーコードは、ＰＡＳオブジェクトが理解されないことを指し示すために使用されることになる。

ＰＡＳ識別子がＰＥによって認識されないとき、ＰＥは、このＬＳＰがそのＰＡＳ識別子を定義していると想定することになる。しかしながら、一定の条件下では、ＰＥはＰＡＳ識別子を無効にすることができる。

識別子は認識されるが、送信元アドレス−宛先アドレスのペアが認識されない場合、このＬＳＰは、ＰＡＳ識別子のみを使用してセットアップされるべきである。

識別子が認識され、送信元アドレス−宛先アドレスのペアもまた認識される場合、ＰＥは、このアドレスのペアによって識別されたＬＳＰに関連付けられたＰＥ ＳＲＬＧ情報を使用して、ディスジョイントな経路を選択することになる。

経路アフィニティ設定情報は、ルーティングプロトコルを使用して、プロバイダネットワークにおいて配布されることになる。ＳＲＬＧについての情報は既にＩＧＰトラフィックエンジニアリングデータベースにおいて利用可能である。ＰＥネットワークは、Ｌ１ＶＰＮベースでＰＥ経路およびＳＲＬＧを配布する、プロバイダ経路についての追加的な曖昧な記録を有するように設計されてもよい。ＰＥ経路がセットアップされるとき、以下の情報により、ＰＥが、ＰＥダイバーシティ情報をルックアップすることが可能になる：
− Ｌ１ＶＰＮ識別子８バイト
− 経路アフィニティ設定識別子
− 送信元ＰＥアドレス
− 宛先ＰＥアドレス
− ＰＥ ＳＲＬＧのリスト（変数）

送信元ＰＥアドレスおよび宛先ＰＥアドレスは、Ｌ１ＶＰＮ ＰＩＴにおいて同じアドレスであり、それぞれのＣＤアドレス識別子に対応する。

情報のすべてはＰＥコンテキストにローカルであり、ＣＥとは共有されないことに留意されたい。Ｌ１ＶＰＮ識別子は、ＣＥに関連付けられている。ＣＥからシグナルされる唯一の値が、経路アフィニティ設定であり、オプションでは、既存のＬＳＰのアドレスである。ＰＥは、ＳＲＬＧ情報と共に、そのネイティブなフォーマットで、ＬＳＰの送信元ＰＥアドレスおよび宛先ＰＥアドレスを格納する。この情報は、ＰＥネットワークの内部にあり、常に知られている。この情報は、いくつかのメカニズムを通して、他のＰＥまたはＰＣＥデバイスと共有されてもよい。

ＰＥ経路は、オンデマンドでセットアップされてもよいし、または事前に確立されていてもよい。経路が事前に確立されている場合、経路アフィニティ設定は、割り当てられない０ｘ００００に設定されて、無視される。ＣＥが事前に確立されている経路を使用するとき、ＣＥが１つをシグナルすると、ＰＥは、経路ＳＲＬＧ経路アフィニティ設定値を設定することができ、そうでない場合、経路アフィニティ設定は、割り当てられない０ｘ００００のままである。

次に図４を見てみると、第２の実施形態による通信は、以下の通りとなる。最初に、ＣＥ１が、１に設定されたダイバーシティフラグを含むＰＡＴＨメッセージＰＭ１’を、ＰＥ１に送信することになる。オプションで、ＰＡＴＨメッセージＰＭ１’はまた、ＰＡＳ識別子について提案される値を含むことができる。ＰＥ１は、計算し、ＬＳＰ１を確立することになる。経路計算およびセットアップは、よく知られているメカニズムおよびＧＭＰＬＳプロトコルを使用することになる。ＰＡＴＨメッセージＰＭ１’はまた、ＬＳＰ１が既にアクティブである場合に送信されてよく、その理由は、ＲＳＶＰに従って、ＰＡＴＨメッセージおよびＲＥＳＶメッセージが、定期的にＬＳＰのリフレッシュされたステータスに再送信されるからであることを理解されたい。

アクティブにされたダイバーシティフラグを含むＰＡＴＨメッセージＰＭ１’を受信するとき、ＰＥ１は、ＬＳＰ１のＳＲＬＧを決定し、このＳＲＬＧにＰＡＳ識別子を割り当てることになる。ＰＡＴＨメッセージＰＭ１’が既にＰＡＳ識別子についての値を収容していた場合、ＰＥ１は、好ましくはこの値を使用することになる。しかしながら、たとえば、ＰＥがよりよい値を使用することから、この値が使用に最善ではないことがある。そのようなケースでは、ＰＥ１は、新しい値を選んで、ＣＥ１によって提供された値を上書きすることになる。いずれのケースでも、ＰＥ１は、ＰＡＳ識別子のために選ばれた値を収容しているＰＡＳオブジェクトを含むＲＥＳＶメッセージＲＭ１’を、ＣＥ１に返信することになる。

ＰＥ１は次いで、それ以前に決定されたＳＲＬＧリスト、および対応するＰＡＳオブジェクトを、ＯＳＰＦ−ＴＥルーティングプロトコルを使用して、プロバイダネットワークにおけるＮＮＩを介して、アドバタイズすることになる。より詳細には、ＰＥ１は、すべてそのＮＮＩにおいて、ＯＳＰＦメッセージＲＴＭ１を送信して、ＳＬＲＧ／ＰＡＳ情報を共有することになる。プロバイダネットワークにおける各ノードＰ１−Ｐ４、ＰＥ１−ＰＥ４は、ＯＳＰＦメッセージＲＴＭ１を、直接的にまたは間接的に（すなわち転送されて）受信し、ＰＡＳオブジェクトおよび対応するＳＲＬＧリストを、そのルーティングデータベースに格納することになる。

次のステップで、ＣＥ１は、新しい経路ＬＳＰ２を要求する経路要求ＰＭ２’を、ＰＥ２に送信することになる。この経路要求ＰＭ２’は、ＰＡＳオブジェクトを収容するＲＳＶＰ ＰＡＴＨメッセージである。ＰＡＳオブジェクトは、ＰＥ１から受信された通りの識別子、ならびに１に設定されたダイバーシティフラグＤを収容している。

ＰＥ２は、そのルーティングデータベースにおいて、受信されたＰＡＳ識別子に対応したＳＲＬＧリストをルックアップし、このＳＲＬＧリストを経路計算のための除外リストとして使用することになる。経路計算は、このようにして、ＰＥ２のローカルな知識のみによって実施されてよい。ＰＥ２は、したがって、ＬＳＰ２を計算し、標準ＲＳＶＰシグナリングを使用して経路セットアップを開始することになる。

次のステップとして、ダイバーシティフラグが有効にされたので、ＰＥ２は、ＬＳＰ２のＳＲＬＧを決定し、そこに同じＰＡＳオブジェクトを割り当てることになる。ＰＥ２は次いで、ＯＳＰＦルーティングメッセージＲＴＭ２を送出して、更新されたＳＬＲＧ情報を有するＰＡＳオブジェクトをアドバタイズすることになる。ＰＥ１は、ルーティングメッセージＲＴＭ２を受信して、そのルーティングデータベースを更新することになる。したがって、ＬＳＰ１に沿った障害の場合、ＰＥ１は、除外リストとしてＬＳＰ２のＳＲＬＧを使用して、ＬＳＰ１を修復することができる。

ＰＥ２はまた、ＲＥＳＶメッセージＲＭ２’をＣＥ１に返信して、ＬＳＰ２の作成の成功をシグナルすることになる。ＲＥＳＶメッセージＲＭ２’はまた、ＰＡＳ識別子を確認するためのＰＡＳオブジェクトを収容することになり、このＰＡＳ識別子は、ＬＳＰ１のＰＡＳ識別子と同じであることになる。

プロバイダエッジノードＰＥの簡略化されたブロック図が、図５に示されている。プロバイダエッジノードは、たとえば、ＴＤＭスイッチ、光クロスコネクト（Ｏｐｔｉｃａｌ ＣｒｏｓｓＣｏｎｎｅｃｔ：ＯＸＣ）、またはフォトニッククロスコネクト（Ｐｈｏｔｏｎｉｃ Ｃｒｏｓｓ−Ｃｏｎｎｅｃｔ：ＰＸＣ）であってよい。代替として、ＰＥデバイスは、イーサネット（登録商標）プライベートライン（Ｅｔｈｅｒｎｅｔ（登録商標） Ｐｒｉｖａｔｅ Ｌｉｎｅ：ＥＰＬ）タイプのデバイスであってもよく、このデバイスは、Ｅｔｈｅｒｎｅｔ ｏｖｅｒ ＴＤＭを用いて、イーサネットフレームをレイヤ１接続上にマップする。

図５に示すようなプロバイダエッジノードＰＥは、１つまたは複数のユーザ−ネットワークインターフェースＵＮＩ、１つまたは複数のネットワーク−ネットワークインターフェースＮＮＩ、およびＵＮＩからのユーザトラフィックをＮＮＩでのネットワーク接続に相互接続するスイッチデバイスを有する。スイッチデバイスは、たとえば、たとえば、ＴＤＭスイッチ、空間スイッチ、波長スイッチ、またはセルベースのスイッチであってよい。

プロバイダエッジノードＰＥは、関連付けられたコントローラＣＴＲをさらに有し、ＣＴＲは、ＵＮＩおよびＮＮＩからの制御トラフィックを処理し、適切なスイッチ機能を実施するようにスイッチデバイスを制御する。コントローラＣＴＲは、プロセッサＣＰＵと、ルーティングデータベースＤＢを収容するストレージデバイスとを有する。

コントローラＣＴＲは、ＧＭＰＬＳルーティングエージェントおよび対応するＧＭＰＬＳプロトコルスタックを動かし、ＵＮＩを介して付属する顧客エッジノードと通信し、ＮＮＩを介して他のプロバイダノードと通信する。コントローラは、上で指定されたようなシグナリングおよびルーティングプロトコルメッセージを送受信するようにプログラムされている。

顧客エッジデバイスＣＥの簡略化されたブロック図が、図６に示されている。ＣＥデバイスは、さまざまなデバイス、たとえば、時分割多重（ＴＤＭ）スイッチ、ルータ、およびレイヤ２スイッチなどであってよい。顧客エッジデバイスＣＥは、少なくとも２つのユーザ−ネットワークインターフェースを有して、デュアルホーミングをサポートする。示された実施形態において、顧客エッジデバイスＣＥは、顧客ネットワーク内のデータ接続のための１つまたは複数のイーサネットインターフェースＥＴＨと、イーサネットインターフェースＥＴＨからＵＮＩで終端されるトラフィック経路までのユーザパケットデータを選択的に相互接続するパケットスイッチＰＳＷとを有する。パケットスイッチは、たとえば、共有メモリスイッチ、およびヘッダ処理のためのネットワークプロセッサを使用して実装されてよく、ネットワークプロセッサは、パケットヘッダから読み取られる宛先アドレスに依存して、メモリスイッチへの読み取りおよび書き込みを決める。

図５のプロバイダエッジノードＰＥと同様に、顧客エッジノードＣＥは、関連付けられたコントローラＣＴＲ’有し、ＣＴＲ’は、ＵＮＩからの制御トラフィックを処理し、適切なスイッチ機能を実施するようにパケットスイッチＳＷを制御する。コントローラＣＴＲ’は、プロセッサＣＰＵ’と、ルーティングテーブルＤＢ’を格納するストレージデバイスとを有する。ルーティングテーブルＤＢ’は、クライアントネットワークルーティングデータベースを表し、これは、クライアントネットワークが可視性を持たないプロバイダネットワークのルーティングデータベースとは、別個であることを理解されたい。

コントローラＣＴＲは、ＵＮＩエージェントおよび対応するＲＳＶＰプロトコルスタックを動かし、ＵＮＩを介して付属するプロバイダエッジノードと通信する。コントローラは、上で指定されたようなシグナリングプロトコルメッセージを送受信するようにプログラムされている。

上の実施形態は、分散された制御プレーン、および各プロバイダ（エッジ）ノード上で動くローカルＧＭＰＬＳルーティングエージェントを利用する。同様のメカニズムおよびプロトコル拡張はまた、経路計算要素（Ｐａｔｈ Ｃｏｍｐｕｔｉｎｇ Ｅｌｅｍｅｎｔ：ＰＣＥ）、および経路計算クライアント（Ｐａｔｈ Ｃｏｍｐｕｔｉｎｇ Ｃｌｉｅｎｔ：ＰＣＣ）としてのプロバイダエッジノードＰＥ１、ＰＥ２を備えた、集中型アーキテクチャにおいて使用されてもよいことを理解されたい。

一般に、様々なＰＣＥ／ＰＣＣアプローチが提案されており、これらはＩＥＴＦで現在議論中である。１つのアプローチでは、ＰＣＥは、ステートフルＰＣＥであってよく、すなわち、ネットワークにおけるすべてのＬＳＰの知識を有する。しかしながら、別のアプローチでは、ＰＣＥは、ステートレスであってもよい。ステートレスＰＣＥが使用される場合、ＰＥ１およびＰＥ２は独立して、それらの経路計算要求にダイバーシティ属性を含んで、経路計算をＰＣＥに要求することになる。ＰＣＥは次いで、ＰＥのための経路計算を１つずつ実施することになり、ＳＲＬＧ情報を追加的に決定し、返信し、リンク多様なＬＳＰを実現するために、ＳＲＬＧ情報を除外リストとして考慮することになる。

より詳細には、第１の実施形態において、ＰＣＥが関わるとき、ＰＥ１は、ＬＳＰ１のＳＲＬＧをＰＣＥから受信し、それを返信メッセージＲＭ１においてＣＥ１に転送することになる。ＰＥ２は、ＬＳＰ１に対応したＳＲＬＧリストを含む経路要求メッセージＰＭ２を受信すると、ＳＲＬＧ情報をＰＣＥに転送することになり、その結果、ＰＣＥは、ＬＳＰ２の計算のための除外リストとして、これができる。これにより、ステートレスＰＣＥでさえも、デュアルホーミングネットワークトポロジにおいて、リンク多様な経路計算を実施することが可能になることになる。同様のやり方で、第２の実施形態がまた、ステートレスＰＣＥによるコンテキストで用いられてよい。

当業者は、さまざまな上述された方法のステップが、プログラムされたコンピュータによって実施され得ることを容易に認識するであろう。本明細書では、いくつかの実施形態はまた、プログラムストレージデバイス、たとえば、デジタルデータストレージ媒体を含むよう意図され、これらは、マシン可読もしくはコンピュータ可読であり、マシン実行可能な、もしくはコンピュータ実行可能なプログラムの命令を符号化し、ここで、前記命令は、前記上述された方法のステップのうちのいくつか、または全部を実施する。プログラムストレージデバイスは、たとえば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハードドライブ、または、光学的に可読なデジタルデータストレージ媒体であってよい。実施形態はまた、上述された方法の前記ステップを実施するようにプログラムされたコンピュータを含むよう意図される。

本説明および図面は、本発明の原理を例証するにすぎない。したがって、当業者は、たとえ本明細書に明示的に説明されない、または示されなくても、本発明の原理を具体化し、本発明の趣旨および範囲内に含まれる、さまざまな仕組みを考案できることが認識されるだろう。さらに、本明細書に列挙されるすべての例は、主に、本発明の原理およびさらなる技術に対して本発明者によって貢献される概念を読者が理解するのを支援するための、教育的な目的のためのみであることがはっきりと意図されており、それらの例は、そのような特に列挙された例および条件に限定されないものとして解釈されるべきである。さらに、本明細書において、本発明の原理、態様、および実施形態、ならびにその特定の例を列挙するすべての記述は、その均等物を包含することが意図される。

「プロセッサ」または「ＣＰＵ」とラベル付けされた任意の機能ブロックを含む、図に示されたさまざまな要素の機能は、専用ハードウェア、ならびに適切なソフトウェアに関連してソフトウェアを実行することができるハードウェアの使用を通して提供されてよい。プロセッサにより提供されるとき、機能は、単一の専用プロセッサにより、単一の共有プロセッサにより、または、そのうちのいくつかが共有され得る複数の個々のプロセッサにより提供されてもよい。さらに、用語「プロセッサ」または「コントローラ」の明示的な使用は、ソフトウェアを実行することができるハードウェアを排他的に指すよう解釈されるべきでなく、限定はせずに、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性ストレージを暗黙的に含むことができる。従来の、および／またはカスタムの、他のハードウェアがまた含まれてもよい。同様に、図に示された任意のスイッチは、概念上にすぎない。スイッチの機能は、プログラム論理の演算を通して、専用論理を通して、またはプログラム制御と専用論理との相互作用を通して実行されてよく、特定の技法は、コンテキストからより具体的に理解されるように、実装者によって選択可能である。

Claims (9)

1. プロバイダネットワークを通るトラフィック経路を確立する方法であって、顧客エッジデバイス（ＣＥ１）が、ユーザ−ネットワークインターフェース（ＵＮＩ）を介して、第１のプロバイダエッジノード（ＰＥ１）および第２のプロバイダエッジノード（ＰＥ２）に接続され、前記プロバイダエッジノード（ＰＥ１、ＰＥ２）が、ネットワーク−ネットワークインターフェース（ＮＮＩ）を介して、プロバイダコアノード（Ｐ１−Ｐ４）、およびさらなるプロバイダエッジノード（ＰＥ３、ＰＥ４）と直接的にまたは間接的に相互接続されて、前記プロバイダネットワークを形成し、前記プロバイダエッジノード（ＰＥ１−ＰＥ４）および前記プロバイダコアノード（Ｐ１−Ｐ４）が、ルーティングプロトコルを使用して、前記ネットワーク−ネットワークインターフェース（ＮＮＩ）上でルーティング情報をやり取りし、方法が、
   前記プロバイダネットワークを通る第１のトラフィック経路が、前記第１のプロバイダエッジノード（ＰＥ１）から確立されるように、前記顧客エッジデバイス（ＣＥ１）が要求するステップと、
   前記プロバイダネットワーク内で、前記ルーティング情報を使用して前記第１のトラフィック経路（ＬＳＰ１）を計算するステップ、および、シグナリングプロトコルを使用して前記第１のトラフィック経路（ＬＳＰ１）のセットアップを開始するステップと、
   前記プロバイダネットワークを通る第２のトラフィック経路（ＬＳＰ２）が、前記第２のプロバイダエッジノード（ＰＥ２）から確立されるように、かつ前記第１のトラフィック経路（ＬＳＰ１）からディスジョイントであるように、前記顧客エッジデバイス（ＣＥ１）が要求するステップと、
   前記プロバイダネットワーク内で、前記ルーティング情報、および前記第１のトラフィック経路（ＬＳＰ１）からディスジョイントであるとする制約を使用して前記第２のトラフィック経路（ＬＳＰ２）を計算するステップ、および、前記シグナリングプロトコルを使用して前記第２のトラフィック経路（ＬＳＰ２）のセットアップを開始するステップと
   を含み、さらに、
   前記第１のトラフィック経路（ＬＳＰ１）の共有制約情報を決定するステップ、および、前記第１のプロバイダエッジノード（ＰＥ１）から、前記ユーザ−ネットワークインターフェースを介して、前記共有制約情報を示すデータ要素を前記顧客エッジデバイス（ＣＥ１）に返信するステップと、
   前記共有制約情報を除外リストとして使用して前記第２のトラフィック経路の経路計算を可能にするために、前記顧客エッジデバイス（ＣＥ１）から、前記データ要素を、前記第２のプロバイダエッジノード（ＰＥ２）に転送するステップと
   を含む方法であって、
   前記共有制約情報が、前記第１のトラフィック経路（ＬＳＰ１）によって使用されるすべてのプロバイダネットワークリンクの共有リスクリンクグループ識別子を含み、前記データ要素が、前記第１のトラフィック経路の共有リスクリンクグループ識別子の非順序リストを含む、
   方法。
2. 前記共有制約情報を決定する前記ステップが、ダイバーシティフラグを設定させる前記第１のプロバイダエッジノード（ＰＥ１）に対し、前記顧客エッジデバイス（ＣＥ１）によって送信されたメッセージを受信すると実行される、請求項１に記載の方法。
3. 前記メッセージが、トラフィックエンジニアリング拡張を備えたリソースリザベーションプロトコルによるＰＡＴＨメッセージである、請求項２に記載の方法。
4. 前記データ要素を前記第１の顧客エッジデバイス（ＣＥ１）に返信する前記ステップが、前記データ要素をＬＳＰ属性サブオブジェクトとして含む、トラフィックエンジニアリング拡張を備えたリソースリザベーションプロトコルによるＲＥＳＶメッセージを送信するステップを含む、請求項１に記載の方法。
5. 前記第２のトラフィック経路（ＬＳＰ２）を計算するステップの後で、前記第２のプロバイダエッジノード（ＰＥ２）において、前記第２のトラフィック経路（ＬＳＰ２）の共有制約情報を決定するステップ、および、前記ユーザ−ネットワークインターフェースを介して、前記顧客エッジデバイス（ＣＥ１）に、前記第２のトラフィック経路（ＬＳＰ２）の前記共有制約情報を示す第２のデータ要素を返信するステップと、
   前記第２のデータ要素を、前記顧客エッジデバイス（ＣＥ１）から、前記第１のプロバイダエッジノード（ＰＥ１）に転送するステップと
   を含む、請求項１に記載の方法。
6. 前記ネットワークが、前記プロバイダエッジノード（ＰＥ１−ＰＥ４）と通信する１つまたは複数の経路計算要素をさらに含み、トラフィック経路を計算する前記ステップ、および前記トラフィック経路の共有制約情報を決定する前記ステップが、前記経路計算要素のうちのいずれかによって実行される、請求項１に記載の方法。
7. 顧客エッジデバイス（ＣＥ１）に接続するための少なくとも１つのユーザ−ネットワークインターフェース（ＵＮＩ）と、他のプロバイダノードに接続するための少なくとも１つのネットワーク−ネットワークインターフェース（ＮＮＩ）と、ユーザ−ネットワークインターフェース（ＵＮＩ）から、ネットワーク−ネットワークインターフェース（ＮＮＩ）におけるネットワーク接続までのユーザトラフィックを相互接続するスイッチデバイス（ＳＷ）と、コントローラ（ＣＴＲ）とを含む、プロバイダエッジノードであって、
   プログラマブルプロセッサ（ＣＰＵ）およびルーティングデータベース（ＤＢ）を含む前記コントローラ（ＣＴＲ）が、
   ルーティングプロトコルを使用して前記ネットワーク−ネットワークインターフェース（ＮＮＩ）上でルーティング情報をやり取りし、前記ネットワーク−ネットワークインターフェース（ＮＮＩ）で受信されたルーティング情報を前記ルーティングデータベース（ＤＢ）に格納し、
   前記プロバイダネットワークを通るトラフィック経路を確立するための要求を、前記ユーザ−ネットワークインターフェース（ＵＮＩ）を介して受信し、
   前記ルーティング情報を使用して前記トラフィック経路（ＬＳＰ１）を計算し、
   シグナリングプロトコルを使用して前記トラフィック経路（ＬＳＰ１）のセットアップを開始し、
   前記トラフィック経路（ＬＳＰ１）の共有制約情報を決定し、前記共有制約情報を示すデータ要素を、前記ユーザ−ネットワークインターフェースを介して前記顧客エッジデバイス（ＣＥ１）に返信するように
   プログラムされており、
   前記共有制約情報が、前記第１のトラフィック経路（ＬＳＰ１）によって使用されるすべてのプロバイダネットワークリンクの共有リスクリンクグループ識別子を含み、前記データ要素が、前記第１のトラフィック経路の共有リスクリンクグループ識別子の非順序リストを含む、
   プロバイダエッジノード。
8. 前記コントローラが、トラフィック経路を確立するための要求と共に前記共有制約情報を示すデータ要素を受信し、前記共有制約情報を除外リストとして使用して経路計算を実施するように、さらにプログラムされている、請求項１３に記載のプロバイダエッジノード。
9. ２つの異なるプロバイダエッジノード（ＰＥ１、ＰＥ２）に接続するための少なくとも２つのユーザ−ネットワークインターフェース（ＵＮＩ）と、コントローラ（ＣＴＲ’）とを含む、顧客エッジデバイスであって、前記コントローラが、
   前記ユーザ−ネットワークインターフェース（ＵＮＩ）のうちの第１のユーザ−ネットワークインターフェースを介して、前記プロバイダネットワークを通る第１のトラフィック経路（ＬＳＰ１）を要求し、
   前記第１のユーザ−ネットワークインターフェース（ＵＮＩ）において、前記第１のトラフィック経路（ＬＳＰ１）の共有制約情報を示すデータ要素を受信し、
   前記ユーザ−ネットワークインターフェース（ＵＮＩ）のうちの第２のユーザ−ネットワークインターフェースを介して、前記第１のトラフィック経路（ＬＳＰ１）からディスジョイントであるべき、前記プロバイダネットワークを通る第２のトラフィック経路（ＬＳＰ２）を要求し、
   前記共有制約情報を除外リストとして使用して前記第２のトラフィック経路（ＬＳＰ）の経路計算を可能にするために、前記第２のユーザ−ネットワークインターフェース（ＵＮＩ）において、前記第１のユーザ−ネットワークインターフェース（ＵＮＩ）を介して受信された前記データ要素を転送するように
   プログラムされており、
   前記共有制約情報が、前記第１のトラフィック経路（ＬＳＰ１）によって使用されるすべてのプロバイダネットワークリンクの共有リスクリンクグループ識別子を含み、前記データ要素が、前記第１のトラフィック経路の共有リスクリンクグループ識別子の非順序リストを含む、
   顧客エッジデバイス。

Images