(57)【要約】  ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するための方法であって、前記ルート及び前記少なくとも１つのリーフは、ツリー型の構成をとり、前記方法は、ダウンストリームのユニキャストのラベルを生成することと、前記ルートから前記少なくとも１つのリーフへ、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内で、生成された前記ダウンストリームのユニキャストのラベルを配信することと、を含む方法である。そうしたダウンストリームのユニキャストのラベルを含むネットワークノードが、上記方法を実行するために使用される。【選択図】図１
2012507909.tif 000002
【特許請求の範囲】
【請求項１】
ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するための方法であって、
前記ルート及び前記少なくとも１つのリーフは、ツリー型の構成をとり、
前記方法は、
ダウンストリームのユニキャストのラベルを生成することと、
前記ルートから前記少なくとも１つのリーフへ、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内で、生成された前記ダウンストリームのユニキャストのラベルを配信することと、
を含む、方法。
【請求項２】
前記ダウンストリームのユニキャストのラベルを生成することは、前記ルートと前記少なくとも１つのリーフとの間のパス、前記少なくとも１つのリーフのＭＡＣ（Media  Access  Control）アドレス、及びＰＢＢ−ＴＥ（Provider  Backbone  Bridging  with  Traffic  Engineering）ネットワーク内の選択されるＶＬＡＮ  ＩＤ（Virtual  Local  Area  Network  Identity）を特定することを含む、請求項１において定義された方法。
【請求項３】
特定される前記パスは、前記ルート内で決定される、請求項２において定義された方法。
【請求項４】
特定される前記パスは、ネットワークノード内で決定される、請求項２において定義された方法。
【請求項５】
生成された前記ダウンストリームのユニキャストのラベルを配信することは、生成された前記ダウンストリームのユニキャストのラベルをＰＡＴＨメッセージのＴＬＶ（Time-Length-Value）フィールドを使用して伝送することを含む、請求項１において定義された方法。
【請求項６】
生成された前記ダウンストリームのユニキャストのラベルを配信することは、ＰＡＴＨメッセージ内で定義されるＳ２Ｌ（Source  to  Leaf）−ｓｕｂ＿ＬＳＰオブジェクトの拡張を使用すること、をさらに含む、請求項１において定義された方法。
【請求項７】
前記拡張は、ＲＳＶＰメッセージ内に挿入されるべきオブジェクトの新たなクラスを含む、請求項６において定義された方法。
【請求項８】
生成された前記ダウンストリームのユニキャストのラベルを配信することは、ＰＡＴＨメッセージ内にセカンダリラベルを含めるための新たなオブジェクトを使用することをさらに含み、前記セカンダリラベルは、ユニキャストのトラフィックのために使用される、請求項１において定義された方法。
【請求項９】
前記新たなオブジェクトは、前記セカンダリラベルを含めるためのオブジェクトの新たなクラスを含む、請求項８において定義された方法。
【請求項１０】
前記ダウンストリームのユニキャストのラベルを生成することは、前記ルート内で前記ダウンストリームのユニキャストのラベルを生成することを含む、請求項１において定義された方法。
【請求項１１】
前記ダウンストリームのユニキャストのラベルを生成することは、ネットワークノード内で前記ダウンストリームのユニキャストのラベルを生成することを含む、請求項１において定義された方法。
【請求項１２】
ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するためのネットワークノードであって、
前記ルート及び前記少なくとも１つのリーフは、ツリー型の構成をとり、
前記ネットワークノードは、
ダウンストリームのユニキャストのラベルの標識と、
前記標識は、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内に挿入されることと、
を含む、ネットワークノード。
【請求項１３】
ダウンストリームのユニキャストのラベルの前記標識を生成するためのラベルモジュール、をさらに含む、請求項１２において定義されたネットワークノード。
【請求項１４】
前記ダウンストリームのマルチキャストのラベル及び前記アップストリームのユニキャストのラベルと同じシグナリングメッセージ内にダウンストリームのユニキャストのラベルの前記標識を挿入するためのインタフェース、をさらに含む、請求項１２において定義されたネットワークノード。
【請求項１５】
ダウンストリームのラベルの前記標識は、ＰＡＴＨメッセージのＴＬＶ（Time-Length-Value）フィールド内に提供される、請求項１２において定義されたネットワークノード。
【請求項１６】
ダウンストリームのラベルの前記標識は、ＰＡＴＨメッセージ内で定義されるＳ２Ｌ（Source  to  Leaf）−ｓｕｂ＿ＬＳＰオブジェクトの拡張内に提供される、請求項１２において定義されたネットワークノード。
【請求項１７】
前記拡張は、ＲＳＶＰメッセージ内に挿入されるべきオブジェクトの新たなクラスを含む、請求項１６において定義されたネットワークノード。
【請求項１８】
ダウンストリームのラベルの前記標識は、ＰＡＴＨメッセージ内にセカンダリラベルを含めるための新たなオブジェクト内に提供され、前記セカンダリラベルは、ユニキャストのトラフィックのために使用される、請求項１２において定義されたネットワークノード。
【請求項１９】
定義される前記新たなオブジェクトは、前記セカンダリラベルを含めるためのオブジェクトの新たなクラスを含む、請求項１８において定義されたネットワークノード。
【請求項２０】
ダウンストリームのユニキャストのラベルの前記標識は、前記ルートと前記少なくとも１つのリーフとの間のパス、前記少なくとも１つのリーフのＭＡＣアドレス、及びＰＢＢ−ＴＥ（Provider  Backbone  Bridging  with  Traffic  Engineering）ネットワーク内の選択されるＶＬＡＮ  ＩＤ（Virtual  Local  Area  Network  Identity）を含む、請求項１２において定義されたネットワークノード。
【請求項２１】
前記ルートと前記少なくとも１つのリーフとの間の前記パスは、前記ルートにより特定される、請求項２０において定義されたネットワークノード。
【請求項２２】
前記ルートと前記少なくとも１つのリーフとの間の前記パスは、ネットワークノードにより特定される、請求項２０において定義されたネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、通信ネットワークにおけるイーサネットサービスに関する。より具体的には、本発明は、マルチキャスト及び双方向ユニキャストのシグナリングのための方法及びシステムに関する。
【背景技術】
【０００２】
トラフィックエンジニアリングされたポイントツーポイント（ＰｔＰ）のイーサネットサービスはよく理解されており、それらを配備するためのソリューションは十分に文書化されている。しかしながら、マルチポイントサービスを配備するためのソリューションが市場に登場しつつあり、一般の合意に至った完全なソリューションは未だ見出されていない。メトロイーサネットフォーラム（ＭＥＦ）は、サービスを定義したものの（ＭＥＦ１０．１参照）、それらをどのように実装するかについての仕様化はしていない。ＩＥＥＥ  ＰＢＢ−ＴＥ（The  IEEE  Provider  Backbone  Bridging  with  Traffic  Engineering［802.1Qay］）は現在開発中であり、その仕様の暫定版はポイントツーポイント及びポイントツーマルチポイント（ＰｔＭＰ）サービスのための定義を提案している。
【０００３】
マルチポイントサービスの配備は複雑であり、運用においてそれらサービスの管理を円滑に行うためのツールが必要とされる。例えば、ＩＥＴＦ（Internet  Engineering  Task  Force）により定義されたＧＭＰＬＳ（Generalized  Multi-Protocol  label  Switching）（ＩＥＴＦ[RFC3471,RFC3473]）及びイーサネット特有の拡張（ＧＥＬＳ）は、ＰｔＰサービスを配備するためのよい手掛かりを提供するが、イーサネットのマルチポイントサービスをサポートするための全ての必要な拡張を欠いている。
【０００４】
より具体的には、ＭＥＦは、３つの主要なイーサネットのサービスタイプを仕様化している：
１）双方向のポイントツーポイントの接続性（Ｅ−ＬＩＮＥ）
２）ルートが設定される（rooted）マルチポイント（Ｅ−ＴＲＥＥ）
３）マルチポイント接続性（Ｅ−ＬＡＮ）
しかし、ＭＥＦは、これらサービスがプロバイダネットワークによりどのように実装され得るかを定義していない。サービス定義が尊重される限り、いかなる技術を使用することも可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、制御プレーンを用いるＭＥＦ  Ｅ−ＴＲＥＥ及びＥ−ＬＡＮサービスを事業者がプロビジョニングすることを可能にするソリューションは、今のところ存在していない。本発明は、ルートが設定されるマルチポイント接続の確立の問題に焦点を当てる。
【課題を解決するための手段】
【０００６】
より具体的には、本発明によれば、ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するための方法であって、上記ルート及び上記少なくとも１つのリーフがツリー型の構成をとる場合の方法が提供される。上記方法は、ダウンストリームのユニキャストのラベルを生成するステップと、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内で、生成された上記ダウンストリームのユニキャストのラベルを配信するステップと、を含む。
【０００７】
上記ダウンストリームのユニキャストのラベルを生成する上記ステップは、上記ルートと上記少なくとも１つのリーフとの間のパス、上記少なくとも１つのリーフのＭＡＣ（Media  Access  Control）アドレス、及びＰＢＢ−ＴＥ（Provider  Backbone  Bridging  with  Traffic  Engineering）ネットワーク内の選択されるＶＬＡＮ  ＩＤ（Virtual  Local  Area  Network  Identity）を特定することを含む。特定される上記パスは、上記ルート内又はネットワークノード内で決定される。
【０００８】
生成された上記ダウンストリームのユニキャストのラベルを配信する上記ステップは、生成された上記ダウンストリームのユニキャストのラベルをＰＡＴＨメッセージのＴＬＶ（Time-Length-Value）フィールドを使用して伝送することを含む。
【０００９】
生成された上記ダウンストリームのユニキャストのラベルを配信する上記ステップは、ＰＡＴＨメッセージ内で定義されるＳ２Ｌ（Source  to  Leaf）−ｓｕｂ＿ＬＳＰオブジェクトの拡張を使用すること、をさらに含み、上記拡張は、ＲＳＶＰメッセージ内に挿入されるべきオブジェクトの新たなクラスを含む。
【００１０】
生成された上記ダウンストリームのユニキャストのラベルを配信する上記ステップは、ＰＡＴＨメッセージ内にセカンダリラベルを含めるための新たなオブジェクトを使用することをさらに含み、上記セカンダリラベルは、ユニキャストのトラフィックのために使用され、上記新たなオブジェクトは、上記セカンダリラベルを含めるためのオブジェクトの新たなクラスを含む。
【００１１】
上記ダウンストリームのユニキャストのラベルを生成する上記ステップは、上記ルート内で又はネットワークノード内で上記ダウンストリームのユニキャストのラベルを生成することを含む。
【００１２】
また、本発明のある観点は、ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するためのネットワークノードであって、上記ルート及び上記少なくとも１つのリーフがツリー型の構成をとる場合のネットワークノードに関する。上記ネットワークノードは、ダウンストリームのユニキャストのラベルの標識と、上記標識がダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内に挿入されることと、を含む。
【００１３】
上記ネットワークノードは、ダウンストリームのユニキャストのラベルの上記標識を生成するためのラベルモジュールと、上記ダウンストリームのマルチキャストのラベル及び上記アップストリームのユニキャストのラベルと同じシグナリングメッセージ内にダウンストリームのユニキャストのラベルの上記標識を挿入するためのインタフェースとををさらに含む。
【００１４】
ダウンストリームのラベルの上記標識は、ＰＡＴＨメッセージのＴＬＶ（Time-Length-Value）フィールド内に、又はＰＡＴＨメッセージ内で定義されるＳ２Ｌ（Source  to  Leaf）−ｓｕｂ＿ＬＳＰオブジェクトの拡張内に提供され、上記拡張は、ＲＳＶＰメッセージ内に挿入されるべきオブジェクトの新たなクラスを含む。
【００１５】
ダウンストリームのラベルの上記標識は、ＰＡＴＨメッセージ内にセカンダリラベルを含めるための新たなオブジェクト内に提供され、上記セカンダリラベルは、ユニキャストのトラフィックのために使用され、定義される上記新たなオブジェクトは、上記セカンダリラベルを含めるためのオブジェクトの新たなクラスを含む。
【００１６】
さらに、ダウンストリームのユニキャストのラベルの上記標識は、上記ルートと上記少なくとも１つのリーフとの間のパス、上記少なくとも１つのリーフのＭＡＣアドレス、及びＰＢＢ−ＴＥ（Provider  Backbone  Bridging  with  Traffic  Engineering）ネットワーク内の選択されるＶＬＡＮ  ＩＤ（Virtual  Local  Area  Network  Identity）を含み、上記ルートと上記少なくとも１つのリーフとの間の上記パスは、上記ルート又はネットワークノードにより特定される。
【００１７】
本発明の上述の及び他の目的、利点並びに特徴は、添付図面への参照と共に単に例として与えられる、以下の限定ではない例示的なそれらの実施形態の説明を読むことでより明確になるであろう。
【図面の簡単な説明】
【００１８】
【図１】限定ではない本発明の例示的な実施形態に従ったＥ−ＴＲＥＥサービスアーキテクチャの概略図である。
【図２】限定ではない本発明の例示的な実施形態に従って、図１のＥ−ＴＲＥＥサービスアーキテクチャにおいてダウンストリームマルチキャスト並びにアップストリーム及びダウンロストリームユニキャストの接続を確立するための方法を示すフローチャートである。
【図３】限定ではない本発明の例示的な実施形態に従って、図１のＥ−ＴＲＥＥサービスアーキテクチャにおいてダウンストリームマルチキャスト並びにアップストリーム及びダウンロストリームユニキャストの接続を確立するためのネットワークノードの概略図である。
【発明を実施するための形態】
【００１９】
本発明のいくつかの例示的な実施形態について説明する前に、本願において用いられる略語のリストを提供する。
【００２０】
略語リスト：
ＣＥ：Customer  Equipment
ＣＢＰ：Customer  Backbone  Port
Ｅ−ＬＡＮ：Ethernet  LAN  service  −ＭＥＦにより仕様化されたサービス
Ｅ−ＬＩＮＥ：Ethernet  line  service  −ＭＥＦにより仕様化されたサービス
Ｅ−Ｔｒｅｅ：Ethernet  tree  service−ＭＥＦにより仕様化されたサービス
ＥＳＰ：Ethernet  Switched  Path
ＥＶＣ：Ethernet  Virtual  Circuit
ＧＭＰＬＳ：Generalized  Multi-Protocol  Label  Switching
ＩＡＮＡ：Internet  Assigned  Numbers  Authority
ＩＥＴＦ：Internet  Engineering  Task  Force
Ｉ−ＳＩＤ：Instance  Service  Identifier
ＩＳＩＳ−ＴＥ：Intermediate  System  to  Intermediate  System-  Traffic  Engineering
ＬＡＮ：Local  Area  Network
ＬＭＰ：Link  Management  Protocol
ＬＳＰ：Label  Switch  Path
ＭＡＣ：Media  Access  Control（アドレス）
ＭＥＦ：Metro  Ethernet  Forum
ＭＰＬＳ−ＴＰ：Multi-Protocol  Label  Switching-Transport  Profile
ＭＰｔＰ：Multipoint-to-Point（接続）
ＭＰｔＭＰ：Multipoint-to-Multipoint（接続）
ＮＭＳ：Network  Management  System
ＯＡＭ：Operations  Administration  and  Maintenance
ＰＢＢ：Provider  Backbone  Bridging
ＰＢＢ−ＴＥ：Provider  Backbone  Bridging  with  Traffic  Engineering
ＰＣＥ：Path  Computation  Engine
ＰｔＰ：Point-to-Point（接続）
ＰｔＭＰ：Point-to-Multipoint（接続）
ＯＳＰＦ−ＴＥ：Open  Shortest  Path  First-Traffic  Engineering
ＲＥＳＶ：Reserve
ＲＳＶＰ−ＴＥ：Resource  Reservation  Protocol  -  Traffic  Engineering  −（Ｇ）ＭＰＬＳのためのシグナリングプロトコル
ＳＯＮＥＴ：Synchronous  Optical  Network
ＳＤＨ：Synchronous  Digital  Hierarchy
ＴＢＡ：To  Be  Assigned
ＵＮＩ：User  Network  Interface
ＶＬＡＮ：Virtual  Local  Area  Network
【００２１】
ＭＥＦでは、例えば、Ｅ−ＬＩＮＥサービスがまさに２つのユーザネットワークインタフェース（ＵＮＩ）を接続するポイントツーポイントのイーサネット仮想接続（ＥＶＣ）である。Ｅ−ＬＩＮＥは、対称的な帯域幅を伴い双方向であることを前提としている。非対称の帯域幅の予約もサポートされ得る。
【００２２】
Ｅ−ＴＲＥＥサービスあるいはルートが設定されるマルチポイントＥＶＣは、ツリー型の構成を形成する場合のように２つより多くのＵＮＩを接続するマルチポイントＥＶＣであり、各ＵＮＩはルート又はリーフのいずれかとして指定される。Ｅ−ＴＲＥＥ構成内では、複数のルートがあってもよい。例えば、ルートＵＮＩに存在するフレームを１つ以上の他のＵＮＩへ送信することが可能であり、それらＵＮＩは他のルートであってもリーフであってもよい。また、リーフＵＮＩに存在するフレームを、ルートＵＮＩのいくつか又は全てへ転送することができる。しかしながら、本発明の一例としての実施形態では、１つのルートに複数のリーフが接続するというツリー型の構成が説明される。
【００２３】
ルートＵＮＩにおける入力サービスフレーム（Ingress  Service  Frames）は、ＥＶＣ内の他のＵＮＩ（リーフ）の任意の１つ以上へ伝達され得る。リーフＵＮＩにおける入力サービスフレームは、ＥＶＣ内の１つ以上のルートＵＮＩのみへ伝達され得る。これは、ルートＵＮＩにおいて接続されるカスタマ機器（ＣＥ）が１つ以上のＵＮＩ（ルート又はリーフ）に接続されたＣＥへフレームを送信できること、及びリーフＵＮＩにおいて接続されるＣＥが１つ以上のルートＵＮＩにはフレームを送信できるが他のいずれのリーフにもフレームを送信できないことを意味する。
【００２４】
Ｅ−ＬＡＮ（あるいはマルチポイントツーマルチポイントＥＶＣ）は、２つ以上のＵＮＩの間の接続性を定義している。各ＵＮＩは、他のノードの１つ、いくつか又は全てへフレームを送信することができる。
【００２５】
技術用語において、ＰＢＢ−ＴＥをＭＥＦサービスを提供するために使用することのできる技術の１つとして見なすことができる。ＰＢＢ−ＴＥでは、接続は、ポートについての特定のＶＬＡＮメンバーシップを設定し、パスに沿ってノード内に静的フィルタリングエントリを追加することにより確立される。接続の送信元及び宛て先は、エッジノードにおけるカスタマバックボーンポート（ＣＢＰ）である。
【００２６】
標準仕様ＩＥＥＥ８０２．１Ｑａｙは、トラフィックエンジニアリング（ＴＥ）されるサービスの２つのタイプを定義しており、即ち：ＰｔＰ  ＴＥサービス及びＰｔＭＰ  ＴＥサービスである。これらサービスは、トラフィックエンジニアリングされる一方向の接続パスあるいは所謂イーサネットスイッチパス（ＥＳＰ）から構成される。ＥＳＰは、ポイントツーポイント（通常のパス）又はポイントツーマルチポイント（マルチキャストツリー）のいずれかであってよい。
【００２７】
まず、ＩＥＥＥ８０２．１Ｑａｙは、ＰｔＰ  ＴＥサービスインスタンスを、“２つのポイントツーポイントのＥＳＰによりサポートされ、ＥＳＰのエンドポイントが同じＣＢＰ  ＭＡＣアドレスを有するＴＥサービスインスタンス”と定義している。
【００２８】
そして、ＩＥＥＥ８０２．１Ｑａｙは、ＰｔＭＰ  ＴＥサービスインスタンスを、“ルートからｎ個のリーフへの１つのポイントツーマルチポイントＥＳＰと、上記リーフの各々から上記ルートへのｎ個のポイントツーポイントのＥＳＰとを含むＥＳＰのセットによりサポートされるＴＥサービスインスタンス”と定義している。
【００２９】
より具体的には、ＰＢＢ−ＴＥにおけるポイントツーマルチポイント（ＰｔＭＰ）ＴＥサービスは、少なくとも２つのエンドポイントを含む双方向マルチキャストツリーであって、その１つは特別な役割を有し、そのノードが当該ツリーのルートである。他のエンドポイントはリーフに相当する。ルートは全てのリーフへトラフィックをマルチキャストの形で送信することができる一方、各リーフはフレームをルートのみへ送信（ユニキャスト）することができる。これは、ルートとリーフとの間の１：Ｎの関係を表しており、Ｎがリーフの数である。
【００３０】
ＭＥＦは、そのイーサネット仮想接続（ＥＶＣ）サービスを複数のＵＮＩの間の関連付け（association）として仕様化しているが、サービスインスタンスが様々な技術と共にネットワーク内でいかに実装されるべきかを仕様化していない。対照的に、ＰＢＢ−ＴＥでは、仕様化されたサービスはその技術固有のものであって、ＰＢＢ−ＴＥネットワーク内でのみ有効である。さらに、ＩＥＥＥは、ＵＮＩにおけるトラフィックがＴＥサービス内でいかにマッピングされるかを仕様化していない。
【００３１】
留意されるべきは、ＭＥＦのシングルルートマルチポイント（Ｅ−ＴＲＥＥ）サービスとＰｔＭＰ  ＴＥサービスとの間には違いがあるということである。後者の場合、ルートにおいて存在するサービスフレームは常に当該ルートに関連付けられた全てのリーフへ伝達される一方で、ＭＥＦサービスでは必ずしもそうでなく、ルートにおいて存在するサービスフレームは単一のリーフ又はリーフのサブセットへ伝達され得る。
【００３２】
しかしながら、ＭＥＦ  Ｅ−ＴＲＥＥサービスインスタンスを、ＰｔＭＰ  ＴＥサービスインスタンス及び多くのＰｔＰ  ＴＥサービスインスタンスの支援と共に実装することができる。同時に、エッジノードがＩ−ＳＩＤタグと呼ばれる追加的なサービス識別子に基づいてトラフィックフローを区別するため、ＴＥサービスインスタンスは、異なるＭＥＦサービスに属するトラフィックを搬送することができる。従って、ＭＥＦとＰＢＢ−ＴＥのＴＥサービスとの間には多対多の関係がある。
【００３３】
ＴＥサービスタイプの両方向は双方向として定義されることから、リーフからルートへの方向において、リーフとルートとの各ペアの間には２つの並列的なＰｔＰ  ＥＳＰ：即ちＰｔＭＰ  ＴＥサービスインスタンスのための１つ及びＰｔＰ  ＴＥサービスインスタンスのための１つ、が確立されるであろう。デフォルトでは、リーフノードは２つのＥＳＰのうちただ１つ上で転送され、他のＥＳＰは使用されないことになる。代替的に、２つのＴＥサービスインスタンスでそれらのアップストリームＥＳＰをシェアすることができる。
【００３４】
ＰｔＰ及びＰｔＭＰ  ＴＥサービスの定義がＥＳＰに基づいているとしても、ＰＢＢ−ＴＥノード内にはそのような管理されるオブジェクトは存在しない。その代わりに、ＥＳＰは、ポートのＶＬＡＮメンバーシップを変更して、当該ＥＳＰ内に関わるノードのフィルタリングデータベース内に静的エントリを追加し、エッジノード上のメンテナンスエンドポイント（ＭＥＰ）のセットを含むメンテナンスアソシエーションを生成することにより、構築される。
【００３５】
サービスのために要求される接続は、ネットワーク管理システム（ＮＭＳ）により確立され得る。しかしながら、ＮＭＳについての主な課題は、それらが通常は私有であって、そのためマルチベンダからのネットワークノードにとって相互利用できないことである。異なるベンダからの機器を含むネットワーク内のＮＭＳを用いてサービスを確立することは、事業者にとって困難であり得る。
【００３６】
また、サービスは、配信される制御プレーンによっても確立され得る。その場合、ルートへの単一のコマンドがサービスに関わる全てのノードを構成する。ＧＭＰＬＳは、当該ネットワークを制御するための主要な技術として産業界で既に認識されている。それは、例えば、ネットワーク内のリンク（ＬＭＰ）、ネットワークトポロジー（ＯＳＰＦ−ＴＥ又はＩＳＩＳ−ＴＥ）及び接続を確立するためのプロトコル（ＲＳＶＰ−ＴＥ）を発見するためのプロトコル群並びに手続群を提供する。ＲＳＶＰ−ＴＥプロトコルは、ＩＥＴＦにより定義され、多くのＲＦＣが当該プロトコルの様々な側面を記述している。ＧＭＰＬＳは標準プロトコルのセットであり、ベンダ間の相互利用性（interoperability）は大きく高められる。
【００３７】
ＲＳＶＰ−ＴＥは、当初はＰｔＰ接続を確立するために開発された。近年のいくつかの作業では、マルチキャストツリーをサポートするために当該プロトコルは拡張されている。例えば、ＲＦＣ４８７５は、要求されるオブジェクトと一方向のＰｔＭＰサービスを確立するための手続とを記述している。しかしながら、この作業は、ＭＰＬＳのデータプレーンに焦点を当てており、ＰＢＢ−ＴＥのような他の技術の特有の要件を考慮していない。
【００３８】
現在のＲＳＶＰ−ＴＥにおけるソリューションにはいくつかの問題が存在する。例えば、ＲＳＶＰ−ＴＥにおける現在のＬＳＰの構成概念は、ポイントツーポイント及び一方向のポイントツーマルチポイントである。ＭＥＦにおいて定義されるようなＥ−ＴＲＥＥサービスを配備することを望むとすれば、ルートからリーフへのポイントツーマルチポイントのＬＳＰとルートから各リーフへの多数のポイントツーポイントの一方向のＬＳＰとを構築することがソリューションとなるであろう。
【００３９】
［ＲＦＣ４８７５］において定義されているＲＳＶＰ−ＴＥの拡張は、ポイントツーマルチポイントのツリーをシグナリングする仕組みを確立する。１つの前提は、ルートにおいて受信されるサービスフレームのコピーを各リーフが受信するように、データプレーンがフレームを冗長化することである。これは、ＰＢＢ−ＴＥネットワーク内では、マルチキャストアドレスを使用し、バックボーン内で適切な転送エントリを設定して、ルートからリーフへのパスを確立することにより、達成され得る。
【００４０】
ＧＭＰＬＳ（ＲＦＣ３４７１）のために定義されたＲＳＶＰ−ＴＥの拡張を組み合わせれば、ルートノードにより送信されるＰＡＴＨメッセージ内にＵＰＳＴＲＥＡＭ＿ＬＡＢＥＬを追加することにより、容易にマルチキャストツリーを双方向にすることができる。ルートＣＢＰのＭＡＣアドレスは、リーフからルートへのパスを確立するために、アップストリームラベル内で使用される。選択されるノード上にラベルを伝播するために使用される手続は、ルートからリーフまで（及びその逆）において同じラベルが使用されることを保証するために［ＧＥＬＳ］において提案されているものであるべきである。
【００４１】
しかしながら、双方向のツリーを有するだけでは、ＭＥＦにより定義されているようなルートが設定されるマルチポイントのＥＶＣを確立するためには十分ではなく、それはルートＵＮＩノードにおいて受信される全てのサービスフレームが全てのリーフへ転送されるためである。サービス定義により仕様化されているところによれば、あるリーフにカスタマデバイスが接続していることが既知となると、ルートは、全てのリーフにトラフィックを送信するよりもむしろ、当該リーフにトラフィックをユニキャストで送信するべきである。これは、ルートから各リーフまでのユニキャストパスもまた確立され使用されなければならないことを意味する。
【００４２】
効率的なリソース管理を有し、ＯＡＭを緩和するためには、ＰＢＢ−ＴＥネットワーク内の全てのパスは、共にルーティングされる（co-routed）べきである。これら多くのＬＳＰのシグナリングは、ＮＭＳによって連携（coordinate）されることを要する。
【００４３】
現在、同じシグナリングメッセージ内でのユニキャストのパス及びマルチキャストのパスの確立をサポートするためのＲＳＶＰ−ＴＥへの既存の又は提案中の拡張は存在しない。実際、既存のソリューションでは、ダウンストリームのマルチキャストの予約のためのシグナリングメッセージの第１のシリーズと、ダウンストリーム及びアップストリーム（双方向）のユニキャストの予約のためのシグナリングメッセージの第２のシリーズとが送信される。
【００４４】
より具体的には、ルート−マルチポイントＥＶＣを可能とするために、ポイントツーマルチポイントのＬＳＰを用いて、まずルートからリーフへマルチキャストパスをシグナリングし、そして各リーフについてルートと当該リーフとの間の１つの双方向のＬＳＰを生成することになる。ルートノード及び中間ノードについて、これはＮをリーフの数としてＮ＋１個までのＬＳＰを維持することを意味する。また、各リーフは、２つのＬＳＰ、即ちマルチポイントのものと当該ノード上で終端するユニキャストとを維持すべきである。
【００４５】
さらに、ＰｔＰ  ＬＳＰ及びＰｔＭＰ  ＬＳＰの確立には連携が求められる。リーフが追加又は除去されると、ＰｔＭＰ  ＬＳＰはＰｔＰ  ＬＳＰの生成又は削除に応じて修正されなければならない。ＰｔＰ  ＬＳＰについて選択されるパスは、好適には、ＰｔＭＰ  ＬＳＰ内の対応する分岐に適合するべきである。
【００４６】
一般的に言えば、本発明の実施形態は、求められるＰｔＰ接続をＰｔＭＰ接続がシグナリングされると同時にシグナリングするための、例えばＲＳＶＰ−ＴＥへの拡張の形式でのダウンストリームのユニキャストのラベルの標識（indicator）を提案する。これは、排他的にではないが、ＰＢＢ−ＴＥネットワークにおいて特に利益がある。
【００４７】
そうして、ＰＢＢ−ＴＥネットワークが以下の例では考慮されるものの、本発明の実施形態がＳｏｎｅｔ／ＳＤＨ又はＭＰＬＳ−ＴＰなどの他のネットワークにも適用可能であることは留意されるべきである。
【００４８】
より具体的には、本発明の実施形態は、ＰｔＭＰと同じシグナリングセッションにおいてルートとリーフとの間のＰｔＰ接続を生成することを可能とする。また、これら実施形態は、ルートから単一のリーフへのユニキャストのトラフィック又は全てのリーフへのマルチキャストのトラフィックの転送に加えて、リーフからルートに向けてのトラフィックのためのパスの設定にも対処する。
【００４９】
ここで、図１に移ると、例として、ＰＢＢ−ＴＥネットワーク内に配備される概略的なＥ−ＴＲＥＥサービスアーキテクチャ１４が示されている。しかしながら、上述したように、ＧＭＰＬＳなどのような他のネットワークが使用されてもよい。
【００５０】
Ｅ−ＴＲＥＥサービスアーキテクチャ１４は、ツリー型の構成を有し、ルートと呼ばれるノード１０が複数の中間ノード１３に接続し、それらの各々１つはさらに中間ノード１３に接続し得る。よって、中間ノード１３の複数のレベルがあり得る。図示された例では、図１は、中間ノード１３の３つのレベルを示している。最後のレベルの中間ノード１３は、複数のエンドポイントノード１２ｉ〜１２Ｎに接続され、それによりツリー型の構成が形成される。エンドポイントノード１２ｉ〜１２Ｎは、ツリー型の構成のリーフとして識別される。中間ノード１３及びエンドポイントノード１２の数は、個々の通信ネットワークの複雑性とサイズとに依存する。
【００５１】
ルート１０と１２Ｎまでのリーフとの間のラベルスイッチパス（ＬＳＰ）の確立は、ＲＳＶＰ−ＴＥを用いて行われ得る。さらに、ネットワークの制約のパラメータ（例えば、利用可能な帯域幅及び明示的なホップなど）のような他の条件がＲＳＶＰ−ＴＥを用いる際に考慮される。
【００５２】
ＬＳＰの確立のために、ＲＳＶＰ−ＴＥには、パスメッセージ（ＰＡＴＨ）及び予約メッセージ（ＲＥＳＶ）という２つの主要なタイプのメッセージが存在する。
【００５３】
ＰＡＴＨメッセージは、送信者から受信者へ送信される。それらは、ダウンストリームパスに沿ったデータフローの識別状態（identification  state）を確立する。
【００５４】
ＲＥＳＶメッセージは、受信者から送信者へ送信され、予約リクエストを搬送し、ＰＡＴＨメッセージにより確立されるものとは逆方向のパスを辿る。
【００５５】
上で述べたように、ルート１０から全てのリーフ１２ｉから１２ＮへのＬＳＰのダウンストリームのマルチキャストの確立は、ＰＡＴＨメッセージによりダウンストリームのマルチキャストのラベルの配信を通じて可能である。ＬＳＰのダウンストリームのマルチキャストは、図１において矢印１６で示されている。例えば矢印１８で示されたノード１２Ｎからルート１０へのＬＳＰのアップストリームのユニキャストの確立もまた、ＰＡＴＨメッセージによりアップストリームラベルの配信を通じて可能である。ダウンストリームのマルチキャスト１６及びアップストリームのユニキャスト１８の確立は、同じメッセージ内で同時に要求される。
【００５６】
さらに、本発明の実施形態では、ルート１０からリーフ１２ＮへのＬＳＰのダウンストリームのユニキャストの確立もまた可能であり、ＬＳＰのダウンストリームのユニキャストは図１において矢印２０で与えられている。ＬＳＰのユニキャストのダウンストリーム２０の確立は、ＬＳＰのダウンストリームのマルチキャスト１６及びＬＳＰのアップストリームのユニキャスト１８の確立と同時に実行される。そうするための汎用性のあるアイディアは、ダウンストリームのユニキャストのラベルの標識を有し、当該ダウンストリームのユニキャストのラベルをＰＡＴＨメッセージ内で他のラベルとともに配信することである。
【００５７】
ダウンストリームのユニキャストのラベルをダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングにおいて配信するために、様々な仕組み及び手続を実装することが可能であり、そのいくつかの例が以下に説明される。
【００５８】
ここで、図２を参照しながら、ルートと少なくとも１つのリーフとの間でダウンストリームのマルチキャストの接続並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するための方法１００を説明する。上記ルート及び上記少なくとも１つのリーフは、例えば図１に示したようなツリー型の構成をとる。
【００５９】
方法１００は、ステップ１０２において開始し、ルート１０又は他のネットワークノードがダウンストリームのユニキャストのラベルを生成する。ダウンストリームのユニキャストのラベルの生成のための例示的な手続を次の通りに説明する。他のネットワークノードは、例えばマルチキャストアドレスの集中的なリストを使用するネットワーク管理システム（ＮＭＳ）であってよい。当該リストは、例えばツリー型の構成１４のためのパラメータの一部としてルート１０に提供される。なお、通常、ユニキャストのラベルはノードのアドレスを示す一方、マルチキャストのラベルはアドレスの候補のプールから割り当てられる必要がある。
【００６０】
そして、ステップ１０４において、ルート１０は、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内で、生成したダウンストリームのユニキャストのラベルを、少なくとも１つのリーフへ配信する。例えば、ダウンストリームのユニキャストのラベルは、ルート１０から上記少なくとも１つのリーフへ送信されるＰＡＴＨメッセージ内に挿入されてよく、当該ＰＡＴＨメッセージは、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルも含む。
【００６１】
図３に移り、ルートと少なくとも１つのリーフとの間でダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するためのネットワークノード２００を説明する。上記ルート及び上記少なくとも１つのリーフは、ツリー型の構成をとる。
【００６２】
例えばルータ又は（やはりルータであってもよい）ルート１０であり得るネットワークノード２００は、ダウンストリームのユニキャストのラベルの標識２０２を含み、標識２０２は、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内に挿入され、当該シグナリングメッセージは、例えばＰＡＴＨメッセージである。ＰＡＴＨメッセージは、例えばルート１０からリーフ１２ｎの１つへ送信される。ダウンストリームのユニキャストのラベルの標識２０２は、例えば以下に説明するような多くの形式をとることができる。
【００６３】
また、ネットワークノード２００は、ダウンストリームのユニキャストのラベルの標識２０２を生成するためのラベルモジュール２０４、並びに、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内に標識２０２を挿入するためのインタフェース２０６をも含み得る。
【００６４】
当然ながら、ネットワークノード２００は、複数の他のコンポーネント（図示せず）をも含んでよい。他のコンポーネントとは、具体的には、リーフ１２ｎ（ｎ＝１からＮ）からのデータパケットを受信するための受信モジュール、異なるリーフへデータパケットを送信するための出力、並びに、本発明のタスク及び手続と当該技術分野においてよく知られた他の通常のタスク及び手続とを実行するためのプロセッサ及び／又はメモリなどである。
【００６５】
上で言及したように、ダウンストリームのユニキャストのラベルの標識２０２は、多くの形式をとり得る。よって、以下では、本発明に係る標識２０２の限定ではない説明のための例が説明される。
【００６６】
最初の２つの説明のための例では、標識２０２を提供するためのＲＳＶＰ−ＴＥプロトコルの拡張の使用、及び、ルート１０がｎ＝１からＮについてのリーフ１２ｎに向けてダウンストリームのユニキャストのラベルをＰＡＴＨメッセージ内で特定／挿入する仕組みが要求される。
【００６７】
しかしながら、ダウンストリームのラベルの割り当ては、通常、遠隔のエンドノードにより行われる。また、必ずしもルートノードがダウンストリームのラベルを決定できるわけではない。例えば、ＰＢＢ−ＴＥネットワークではダウンストリームのラベルはルートノードにより知り得ないであろうリーフノード上のＣＢＰのＭＡＣアドレスを含み、ＭＰＬＳではノードはその近傍においていかなるラベルが利用可能であるかを知らない。また、既存のＲＳＶＰオブジェクトのいくつかは、（異なるサブオブジェクトタイプを伴う）異なるコンテキストにおいて再使用され、それによりいくつかの後方互換性の課題を生じ得る。
【００６８】
本発明の実施形態に係る標識２０２の第３の説明のための例では、ＰｔＰ接続についての既存のものに類似する、より柔軟なラベル割り当ての仕組みを可能とする新たなオブジェクトが導入される。
【００６９】
本発明の実施形態に係る限定ではない第４の説明のための例は、上記第３の例に端を発しているが、新たなオブジェクトタイプを導入する代わりに、新たなサブオブジェクトタイプを導入する。
【００７０】
例１の実施形態１：ＲＳＶＰ−ＴＥのＬＳＰ＿ＡＴＴＲＩＢＵＴＥ／ＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥオブジェクトの拡張
【００７１】
本実施形態では、標識２０２を提供してダウンストリームのユニキャスト２０についてのラベルを配信し及び伝送するために、新たなＴＬＶ（Type-Length-Value）によってＰＡＴＨメッセージが補強される。より具体的には、ＰＡＴＨメッセージのＬＳＰ＿ＡＴＴＲＩＢＵＴＥ及びＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥオブジェクトのクラスについての新たなクラスのタイプ（Ｃタイプ）が提供される。ユニキャストのトラフィックが要求されるｎ＝１からＮについての各リーフ１２ｎに関し、Ｃタイプを有するＬＳＰ＿ＡＴＴＲＩＢＵＴＥ又はＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥオブジェクト、それぞれＳＵＢ＿ＬＳＰ＿ＡＴＴＲＩＢＵＴＥ及び／又はＳＵＢ＿ＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥが、当該リーフ１２ｎについてのＰＡＴＨメッセージ内のＳ２Ｌ＿ＳＵＢ＿ＬＳＰオブジェクトの後に追加される。また、新たなＴＬＶがダウンストリームのユニキャストのラベルを伝送するために追加される。
【００７２】
さらに、本実施形態によれば、ＰＡＴＨメッセージのシンタックスは次のように変更される：
【００７３】
【表１】
2012507909.tif 000003
【００７４】
新たなＣタイプは次のように定義される：
【００７５】
【表２】
2012507909.tif 000004
【００７６】
新たなＴＬＶは、ＳＵＢ＿ＬＳＰ＿ＡＴＴＲＩＢＵＴＥオブジェクト内でルート１０からリーフ１２ｎへのパスを宣言し又は特定するダウンストリームのユニキャストのラベルを含むために定義される。ＰＢＢ−ＴＥネットワークの場合には、ダウンストリームのユニキャストのラベルは、例えば、当該パスについてのリーフＣＢＰのＭＡＣアドレス及び選択されるＶＬＡＮ−ＩＤを含むであろう。
【００７７】
新たなＴＬＶの一例を以下に示す：
【００７８】
【表３】
2012507909.tif 000005
【００７９】
例２の実施形態２：ＲＳＶＰ−ＴＥのＳ２Ｌ  ＳＵＢ  ＬＳＰオブジェクトの拡張
【００８０】
限定ではない第２の説明のための実施形態では、［ＲＦＣ４８７５］において定義されているＰＡＴＨメッセージのソース−リーフサブＬＳＰ（Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰ）オブジェクトへの新たなＣタイプなどの拡張が、標識２０２を提供するために提供される。当該Ｃタイプは、例えば、クラスタイプである。それらは、ＲＳＶＰメッセージ内に挿入することのできるオブジェクトのクラスを識別する。Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰオブジェクトは、ツリーの一部を記述するために使用される。新たなＣタイプ内に含まれるフィールドは、依然としてサブＬＳＰについてのエンドポイントを識別し、但し今ではダウンストリームのユニキャストのラベルをも含む。ＰＢＢ−ＴＥネットワークの場合には、ダウンストリームのユニキャストのラベルはリーフ１２ｎのＣＢＰ  ＭＡＣアドレス及び選択されるＶＬＡＮ−ＩＤを含む。新たなＣタイプにより与えられる情報は、中間ノードがルート１０からリーフ１２ｎへのダウンストリームのユニキャストのパスについてスイッチングエントリを確立することを可能にする。ＰＡＴＨメッセージのシンタックスは、［ＲＦＣ４８７５］において提案されているシンタックスから変更されない。
【００８１】
ＰＡＴＨメッセージのＳ２Ｌ＿ＳＵＢ＿ＬＳＰオブジェクトについての新たなフォーマットは、以下のように与えられる。例えば、Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰ＿ＩＰｖ４＿Ｕｎｉｃａｓｔ＿ＬａｂｅｌへのＣタイプ３（ＩＡＮＡにより追って割り当てられる）は、次のフィールドを含む：
【００８２】
【表４】
2012507909.tif 000006
【００８３】
Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰ＿ＩＰｖ６＿Ｕｎｉｃａｓｔ＿ＬａｂｅｌへのＣタイプ４（ＩＡＮＡにより追って割り当てられる）は、次のフィールドを含む：
【００８４】
【表５】
2012507909.tif 000007
【００８５】
例３の実施形態３：新たなＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴ、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ及びＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトの定義
【００８６】
本実施形態では、標識２０２の提供のための３つの新たなオブジェクト、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴ、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ及びＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴのセットが定義される。ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトは、ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトと同じフォーマットを有し、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトは、ＬＡＢＥＬ＿ＳＥＴオブジェクトと同じフォーマットを有し、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬは、ＬＡＢＥＬオブジェクトと同じフォーマットを有する。これらオブジェクト及びラベルを、全てのリーフにより使用されるオブジェクト及びラベル、即ち、プライマリのオブジェクト及びラベルから区別するために、“セカンダリ”との語を付する。例えば、各リーフは２つのラベルをサポートする。プライマリラベルはマルチキャストのトラフィックについての全てのリーフにより知られる。セカンダリラベルは、各リーフ固有であり、ユニキャストのトラフィックのために使用される。
【００８７】
ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトの１つのインスタンスが、ダウンストリームのユニキャストのパスを要する各リーフ１２ｎについてのＰＡＴＨメッセージ内に追加される。ルート１０がダウンストリームのラベルを特定し又はいくつかのラベルの値を包含／排除すること望む場合には、ＰＡＴＨメッセージ内に１つ以上のＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトが含まれ得る。これらオブジェクト（ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴ及びＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴ）は、ダウンストリームのユニキャストのラベルを要求するリーフ１２ｎに対応するＳ２Ｌ＿ＳＵＢ＿ＬＳＰに続く。
【００８８】
ＰＡＴＨメッセージ内に含まれる各ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴについて、対応するＲＥＳＶメッセージもまたＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬオブジェクトを含む。ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬオブジェクトは、対応するＳ２Ｌ＿ＳＵＢ＿ＬＳＰに続く。セカンダリラベルを選択する手続は、メインのラベルを選択するための手続に類似する。それは、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトにより課されるラベル選択の候補についての制約を含む。
【００８９】
ＰＢＢ−ＴＥネットワークの場合、割り当てられるダウンストリームのユニキャストのラベルは、リーフノード１２ｎにおけるＣＢＰのＭＡＣアドレス及びマルチキャストのラベル内で使用されるＶＬＡＮ−ＩＤを含むべきである。他のデータプレーンの技術については、ラベルは、各データプレーンの技術に適用可能な手続に従って割り当てられるべきである。
【００９０】
これら３つのオブジェクト及びそれらが識別するクラス番号（Ｃ−ｎｕｍｓ）は、ノードの全てによりそれを理解することができることを示すために、例えば“0bbbbbbb”という形式をとり、それらはＩＡＮＡにより割り当てられる。当該“0bbbbbbb”という値は、クラスタイプが最上位のビットにゼロ（０）を有することを表し、それにより、シグナリングに関わる全てのノードにより認識され処理されるべき標準オブジェクトであることが示される。クラスタイプを識別するためのルールは、例えばＲＦＣ２２０５のセクション３．１０において定義される。
【００９１】
さらに、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクト内で、セカンダリラベルを記録するために、ＳｅｃｏｎｄａｒｙＬａｂｅｌサブオブジェクトもまた定義されている。当該サブオブジェクトは、ラベルのサブオブジェクトと同じフォーマットを有し、但し異なるサブオブジェクトＩＤ（ＩＡＮＡにより追って割り当てられる）を使用する。
【００９２】
第３の実施形態に係るＰＡＴＨメッセージのシンタックスは次のように導かれる：
【００９３】
【表６】
2012507909.tif 000008
【００９４】
ＲＥＳＶメッセージのシンタックスは次のように導かれる：
【００９５】
【表７】
2012507909.tif 000009
【００９６】
ＦＦフローディスクリプタ及びＳＥフィルタ仕様は、それらが対応するＳ２Ｌｓｕｂ−ＬＳＰを識別するために、次のように修正される：
【００９７】
【表８】
2012507909.tif 000010
【００９８】
例４の実施形態４：セカンダリラベルについての新たなオブジェクトタイプに代わる新たなＣタイプ
【００９９】
一般的に述べると、限定ではない第４の説明のための実施形態では、既存のオブジェクトの複数のインスタンスを導入することにより、ＰＡＴＨメッセージ及びＲＥＳＶメッセージのシンタックスを修正することが可能となる。
【０１００】
例えば、上で説明したＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトは、代わりにＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクト内の新たなＣタイプとしてエンコードされてよい。この新たなＣタイプは、要求されるラベルのタイプがプライマリのＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクト内で既に特定されているため、いかなるフィールドも定義しない
【０１０１】
ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトは、代わりにＬＡＢＥＬ＿ＳＥＴオブジェクトについての新たなＣタイプとして実装されてよい。
【０１０２】
ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬオブジェクトは、代わりにＲＳＶＰ＿ＬＡＢＥＬオブジェクトについての新たなＣタイプとしてエンコードされてよい。当該オブジェクトのフォーマットは、ＲＥＳＶメッセージ内に存在するＲＳＶＰ＿ＬＡＢＥＬオブジェクトと同じフォーマットを有する。
【０１０３】
しかしながら、ＰＡＴＨメッセージ及びＲＥＳＶメッセージ内に一度だけ現れるように使用される既存のオブジェクトの複数のインスタンスの導入は、プロトコルの既存の実装に何らかの後方互換性の課題を生じさせ得る点に留意すべきである。
【０１０４】
また、本発明の例示的な実施形態の利点として、マルチキャスト及び双方向のユニキャストのデータパスの確立をより少ないメッセージによって調整された形で可能とする単一のＲＳＶＰセッションとして、Ｅ−ＴＲＥＥサービスをシグナリングするための仕組みが提供される点に注目すべきである。例えば、ＲＳＶＰの拡張により提供される標識２０２は、Ｅ−ＴＲＥＥサービスの確立に要する調整を低減することを可能とする。また、ルート１０及びリーフ１２ｎなどのＥ−ＴＲＥＥに関わるノード間で交換されるメッセージの数も低減される。
【０１０５】
本発明の上述した実施形態のいずれかについて処理し、即ち様々なＰＡＴＨメッセージ及び／又はＲＥＳＶメッセージを処理するように、ネットワークノードのルータを構成することが可能である。
【０１０６】
限定ではない説明のための実施形態の手段によって、ここまで明細書内で本発明について説明してきたが、主題となる発明の範囲、思想及び本質から外れることなく、当該説明のための実施形態を変形することができる。
【図１】
2012507909.tif 000011
【図２】
2012507909.tif 000012
【図３】
2012507909.tif 000013
【国際調査報告】
2012507909.tif 000014
2012507909.tif 000015
2012507909.tif 000016
2012507909.tif 000017