JP2012507909A

JP2012507909A - Ｒｓｖｐ−ｔｅを用いるシングルルートマルチポイントサービスにおけるマルチキャスト及び双方向ユニキャストのシグナリング

Info

Publication number: JP2012507909A
Application number: JP2011533922A
Authority: JP
Inventors: トレンブレー、ベノワ; ケルン、アンドラス; タカクス、アッティラ
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2008-11-05
Filing date: 2009-11-03
Publication date: 2012-03-29
Also published as: WO2010052644A1; EP2353257A1; CA2742608A1; AU2009312446A1; US20100111086A1

Abstract

ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するための方法であって、前記ルート及び前記少なくとも１つのリーフは、ツリー型の構成をとり、前記方法は、ダウンストリームのユニキャストのラベルを生成することと、前記ルートから前記少なくとも１つのリーフへ、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内で、生成された前記ダウンストリームのユニキャストのラベルを配信することと、を含む方法である。そうしたダウンストリームのユニキャストのラベルを含むネットワークノードが、上記方法を実行するために使用される。
【選択図】図１

Description

本発明は、一般的に、通信ネットワークにおけるイーサネットサービスに関する。より具体的には、本発明は、マルチキャスト及び双方向ユニキャストのシグナリングのための方法及びシステムに関する。

トラフィックエンジニアリングされたポイントツーポイント（ＰｔＰ）のイーサネットサービスはよく理解されており、それらを配備するためのソリューションは十分に文書化されている。しかしながら、マルチポイントサービスを配備するためのソリューションが市場に登場しつつあり、一般の合意に至った完全なソリューションは未だ見出されていない。メトロイーサネットフォーラム（ＭＥＦ）は、サービスを定義したものの（ＭＥＦ１０．１参照）、それらをどのように実装するかについての仕様化はしていない。ＩＥＥＥＰＢＢ−ＴＥ（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）によってＰＡＴＨメッセージが補強される。より具体的には、ＰＡＴＨメッセージのＬＳＰ＿ＡＴＴＲＩＢＵＴＥ及びＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥオブジェクトのクラスについての新たなクラスのタイプ（Ｃタイプ）が提供される。ユニキャストのトラフィックが要求されるｎ＝１からＮについての各リーフ１２_ｎに関し、Ｃタイプを有するＬＳＰ＿ＡＴＴＲＩＢＵＴＥ又はＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥオブジェクト、それぞれＳＵＢ＿ＬＳＰ＿ＡＴＴＲＩＢＵＴＥ及び／又はＳＵＢ＿ＬＳＰ＿ＲＥＱＵＩＲＥＤ＿ＡＴＴＲＩＢＵＴＥが、当該リーフ１２_ｎについてのＰＡＴＨメッセージ内のＳ２Ｌ＿ＳＵＢ＿ＬＳＰオブジェクトの後に追加される。また、新たなＴＬＶがダウンストリームのユニキャストのラベルを伝送するために追加される。

さらに、本実施形態によれば、ＰＡＴＨメッセージのシンタックスは次のように変更される：

新たなＣタイプは次のように定義される：

新たなＴＬＶは、ＳＵＢ＿ＬＳＰ＿ＡＴＴＲＩＢＵＴＥオブジェクト内でルート１０からリーフ１２_ｎへのパスを宣言し又は特定するダウンストリームのユニキャストのラベルを含むために定義される。ＰＢＢ−ＴＥネットワークの場合には、ダウンストリームのユニキャストのラベルは、例えば、当該パスについてのリーフＣＢＰのＭＡＣアドレス及び選択されるＶＬＡＮ−ＩＤを含むであろう。

新たなＴＬＶの一例を以下に示す：

例２の実施形態２：ＲＳＶＰ−ＴＥのＳ２ＬＳＵＢＬＳＰオブジェクトの拡張

限定ではない第２の説明のための実施形態では、［ＲＦＣ４８７５］において定義されているＰＡＴＨメッセージのソース−リーフサブＬＳＰ（Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰ）オブジェクトへの新たなＣタイプなどの拡張が、標識２０２を提供するために提供される。当該Ｃタイプは、例えば、クラスタイプである。それらは、ＲＳＶＰメッセージ内に挿入することのできるオブジェクトのクラスを識別する。Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰオブジェクトは、ツリーの一部を記述するために使用される。新たなＣタイプ内に含まれるフィールドは、依然としてサブＬＳＰについてのエンドポイントを識別し、但し今ではダウンストリームのユニキャストのラベルをも含む。ＰＢＢ−ＴＥネットワークの場合には、ダウンストリームのユニキャストのラベルはリーフ１２_ｎのＣＢＰＭＡＣアドレス及び選択されるＶＬＡＮ−ＩＤを含む。新たなＣタイプにより与えられる情報は、中間ノードがルート１０からリーフ１２_ｎへのダウンストリームのユニキャストのパスについてスイッチングエントリを確立することを可能にする。ＰＡＴＨメッセージのシンタックスは、［ＲＦＣ４８７５］において提案されているシンタックスから変更されない。

ＰＡＴＨメッセージのＳ２Ｌ＿ＳＵＢ＿ＬＳＰオブジェクトについての新たなフォーマットは、以下のように与えられる。例えば、Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰ＿ＩＰｖ４＿Ｕｎｉｃａｓｔ＿ＬａｂｅｌへのＣタイプ３（ＩＡＮＡにより追って割り当てられる）は、次のフィールドを含む：

Ｓ２Ｌ＿ＳＵＢ＿ＬＳＰ＿ＩＰｖ６＿Ｕｎｉｃａｓｔ＿ＬａｂｅｌへのＣタイプ４（ＩＡＮＡにより追って割り当てられる）は、次のフィールドを含む：

例３の実施形態３：新たなＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴ、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ及びＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトの定義

本実施形態では、標識２０２の提供のための３つの新たなオブジェクト、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴ、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ及びＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴのセットが定義される。ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトは、ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトと同じフォーマットを有し、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトは、ＬＡＢＥＬ＿ＳＥＴオブジェクトと同じフォーマットを有し、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬは、ＬＡＢＥＬオブジェクトと同じフォーマットを有する。これらオブジェクト及びラベルを、全てのリーフにより使用されるオブジェクト及びラベル、即ち、プライマリのオブジェクト及びラベルから区別するために、“セカンダリ”との語を付する。例えば、各リーフは２つのラベルをサポートする。プライマリラベルはマルチキャストのトラフィックについての全てのリーフにより知られる。セカンダリラベルは、各リーフ固有であり、ユニキャストのトラフィックのために使用される。

ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトの１つのインスタンスが、ダウンストリームのユニキャストのパスを要する各リーフ１２_ｎについてのＰＡＴＨメッセージ内に追加される。ルート１０がダウンストリームのラベルを特定し又はいくつかのラベルの値を包含／排除すること望む場合には、ＰＡＴＨメッセージ内に１つ以上のＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトが含まれ得る。これらオブジェクト（ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴ及びＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴ）は、ダウンストリームのユニキャストのラベルを要求するリーフ１２_ｎに対応するＳ２Ｌ＿ＳＵＢ＿ＬＳＰに続く。

ＰＡＴＨメッセージ内に含まれる各ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴについて、対応するＲＥＳＶメッセージもまたＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬオブジェクトを含む。ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬオブジェクトは、対応するＳ２Ｌ＿ＳＵＢ＿ＬＳＰに続く。セカンダリラベルを選択する手続は、メインのラベルを選択するための手続に類似する。それは、ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトにより課されるラベル選択の候補についての制約を含む。

ＰＢＢ−ＴＥネットワークの場合、割り当てられるダウンストリームのユニキャストのラベルは、リーフノード１２_ｎにおけるＣＢＰのＭＡＣアドレス及びマルチキャストのラベル内で使用されるＶＬＡＮ−ＩＤを含むべきである。他のデータプレーンの技術については、ラベルは、各データプレーンの技術に適用可能な手続に従って割り当てられるべきである。

これら３つのオブジェクト及びそれらが識別するクラス番号（Ｃ−ｎｕｍｓ）は、ノードの全てによりそれを理解することができることを示すために、例えば“0bbbbbbb”という形式をとり、それらはＩＡＮＡにより割り当てられる。当該“0bbbbbbb”という値は、クラスタイプが最上位のビットにゼロ（０）を有することを表し、それにより、シグナリングに関わる全てのノードにより認識され処理されるべき標準オブジェクトであることが示される。クラスタイプを識別するためのルールは、例えばＲＦＣ２２０５のセクション３．１０において定義される。

さらに、ＲＥＣＯＲＤ＿ＲＯＵＴＥオブジェクト内で、セカンダリラベルを記録するために、ＳｅｃｏｎｄａｒｙＬａｂｅｌサブオブジェクトもまた定義されている。当該サブオブジェクトは、ラベルのサブオブジェクトと同じフォーマットを有し、但し異なるサブオブジェクトＩＤ（ＩＡＮＡにより追って割り当てられる）を使用する。

第３の実施形態に係るＰＡＴＨメッセージのシンタックスは次のように導かれる：

ＲＥＳＶメッセージのシンタックスは次のように導かれる：

ＦＦフローディスクリプタ及びＳＥフィルタ仕様は、それらが対応するＳ２Ｌｓｕｂ−ＬＳＰを識別するために、次のように修正される：

例４の実施形態４：セカンダリラベルについての新たなオブジェクトタイプに代わる新たなＣタイプ

一般的に述べると、限定ではない第４の説明のための実施形態では、既存のオブジェクトの複数のインスタンスを導入することにより、ＰＡＴＨメッセージ及びＲＥＳＶメッセージのシンタックスを修正することが可能となる。

例えば、上で説明したＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクトは、代わりにＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクト内の新たなＣタイプとしてエンコードされてよい。この新たなＣタイプは、要求されるラベルのタイプがプライマリのＬＡＢＥＬ＿ＲＥＱＵＥＳＴオブジェクト内で既に特定されているため、いかなるフィールドも定義しない

ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬ＿ＳＥＴオブジェクトは、代わりにＬＡＢＥＬ＿ＳＥＴオブジェクトについての新たなＣタイプとして実装されてよい。

ＳＥＣＯＮＤＡＲＹ＿ＬＡＢＥＬオブジェクトは、代わりにＲＳＶＰ＿ＬＡＢＥＬオブジェクトについての新たなＣタイプとしてエンコードされてよい。当該オブジェクトのフォーマットは、ＲＥＳＶメッセージ内に存在するＲＳＶＰ＿ＬＡＢＥＬオブジェクトと同じフォーマットを有する。

しかしながら、ＰＡＴＨメッセージ及びＲＥＳＶメッセージ内に一度だけ現れるように使用される既存のオブジェクトの複数のインスタンスの導入は、プロトコルの既存の実装に何らかの後方互換性の課題を生じさせ得る点に留意すべきである。

また、本発明の例示的な実施形態の利点として、マルチキャスト及び双方向のユニキャストのデータパスの確立をより少ないメッセージによって調整された形で可能とする単一のＲＳＶＰセッションとして、Ｅ−ＴＲＥＥサービスをシグナリングするための仕組みが提供される点に注目すべきである。例えば、ＲＳＶＰの拡張により提供される標識２０２は、Ｅ−ＴＲＥＥサービスの確立に要する調整を低減することを可能とする。また、ルート１０及びリーフ１２_ｎなどのＥ−ＴＲＥＥに関わるノード間で交換されるメッセージの数も低減される。

本発明の上述した実施形態のいずれかについて処理し、即ち様々なＰＡＴＨメッセージ及び／又はＲＥＳＶメッセージを処理するように、ネットワークノードのルータを構成することが可能である。

限定ではない説明のための実施形態の手段によって、ここまで明細書内で本発明について説明してきたが、主題となる発明の範囲、思想及び本質から外れることなく、当該説明のための実施形態を変形することができる。

Claims

ルートと少なくとも１つのリーフとの間のダウンストリームのマルチキャスト並びにアップストリーム及びダウンストリームのユニキャストの接続を確立するための方法であって、
前記ルート及び前記少なくとも１つのリーフは、ツリー型の構成をとり、
前記方法は、
ダウンストリームのユニキャストのラベルを生成することと、
前記ルートから前記少なくとも１つのリーフへ、ダウンストリームのマルチキャストのラベル及びアップストリームのユニキャストのラベルと同じシグナリングメッセージ内で、生成された前記ダウンストリームのユニキャストのラベルを配信することと、
を含む、方法。
前記ダウンストリームのユニキャストのラベルを生成することは、前記ルートと前記少なくとも１つのリーフとの間のパス、前記少なくとも１つのリーフのＭＡＣ（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）を含む、請求項１２において定義されたネットワークノード。
前記ルートと前記少なくとも１つのリーフとの間の前記パスは、前記ルートにより特定される、請求項２０において定義されたネットワークノード。
前記ルートと前記少なくとも１つのリーフとの間の前記パスは、ネットワークノードにより特定される、請求項２０において定義されたネットワークノード。