JP3801953B2 - マルチキャストｍｐｌｓ通信方法およびシステムおよびネットワーク - Google Patents
マルチキャストｍｐｌｓ通信方法およびシステムおよびネットワーク Download PDFInfo
- Publication number
- JP3801953B2 JP3801953B2 JP2002182061A JP2002182061A JP3801953B2 JP 3801953 B2 JP3801953 B2 JP 3801953B2 JP 2002182061 A JP2002182061 A JP 2002182061A JP 2002182061 A JP2002182061 A JP 2002182061A JP 3801953 B2 JP3801953 B2 JP 3801953B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- multicast
- path
- message
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、point-to-multipoint、multipoint-to-multipointのＭＰＬＳ(Multi Protocol Label Switching)転送パスを確立するマルチキャストＭＰＬＳ技術に関する。特にマルチキャスト・ユニキャスト混在環境下でＭＰＬＳパスを確立するＭＰＬＳ技術に関する。またマルチキャスト環境下でＱｏＳ保証のマルチキャストＭＰＬＳパスを設定する技術、マルチキャストアプリケーションの視聴状態に応じてマルチキャストＭＰＬＳパスを設定、削除、修正する技術に関する。またマルチキャスト環境下でトラヒックエンジニアリング可能なマルチキャストＭＰＬＳパスを設定する技術に関する。
【０００２】
【従来の技術】
ネットワークの高速化、クライアントＰＣ処理能力の向上に伴いネットワークを用いたコンテンツ配信サービスの実現が注目を集めている。ネットワークを用いたコンテンツ配信サービスとしては、ユーザが自分自身の嗜好にあわせて観たい番組をオンデマンドで視聴するビデオ・オン・デマンド（ＶｏＤ）サービスと、放送サービスのように決められた番組に視聴者がチャネルを合わせることで番組を受信する放送配信サービスが存在する。このような有料コンテンツ配信サービスを同一のネットワークで実現するためには、ユニキャスト、マルチキャスト混在環境下でＱｏＳ保証可能で、トラヒックエンジニアリング可能な転送網が必要になるが、従来のＩＰ転送技術とＩＰ−ＱｏＳ保証技術では対応できない問題点が存在した。
【０００３】
このため、マルチキャストのＭＰＬＳパスを設定可能なマルチキャストＭＰＬＳパス設定技術が注目を集めている。提案されている技術としては、ＩＥＴＦドラフトとして、1)"Extension to RSVP for Multicast LSP Tunnels," draft-cheng-mpls-rsvp-multicast-er-00.txt Oct. 2001、2)"MPLS Multicast Traffic Engineering," Draft-ooms-mpls-multicast-te-00.txt Feb.2001、3)"Using PIM to distribute MPLS Labels for Multicast Routes," draft-fainacci-mpls-multicast-03.txt Nov.2000, 4)"Multicast in BGP/MPLS VPNs," draft-rosen-vpn-mcast-02.txt Jul. 2001などがあげられる。
【０００４】
【発明が解決しようとする課題】
上記１）２）は、それぞれ既存のｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＭＰＬＳ技術であるＲＳＶＰ−ＴＥ、ＣＲ−ＬＤＰをｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔに拡張したもの、３）、４）は既存のＩＰマルチキャストルーティングプロトコルであるＰＩＭにＭＰＬＳパス確立機能を追加したものである。また１）、２）についてはソース起動のマルチキャストＬＳＰ(Label Switching Path)の設定メカニズムは実装されているもののリーフ起動のマルチキャストＬＳＰの設定メカニズムは実装されていない。このためマルチキャストリーフ配下に存在するクライアントの視聴状態に応じてマルチキャストリーフの設定または削除を行うことにより最適なマルチキャスト配信形態を実現する通信形態には適用できない問題点が生じた。また３）、４）についてはリーフ起動のマルチキャストＭＰＬＳパス設定メカニズムは実装しているものの、ソース起動のマルチキャストＬＳＰ設定メカニズムは実装されていないためマルチキャストデータｓｅｎｄｅｒが受信者を指定して、全受信者へのマルチキャスト転送経路が確立されたことを確認した後でデータ送信するような通信形態に適用できない問題点が存在した。
【０００５】
マルチキャスト配信ではこのように、マルチキャストトラヒック配信ソースに連動したマルチキャストＬＳＰの設定メカニズム、マルチキャスト受信者の視聴状態に連動したマルチキャストＬＳＰの設定メカニズムが同一のプロトコル上で互いに矛盾無く相互運用されなくてはいけないが、上記の従来技術では対応できない問題があった。
【０００６】
また上記、１）〜４）のマルチキャストＬＳＰ設定技術はマルチキャストＭＰＬＳパス全体の設定または削除機能を備えるものの、設定されたマルチキャストＬＳＰの部分ツリーの追加、削除、修正する機能は存在しない。このため、一度設定したマルチキャストＬＳＰの部分的な修正を実施しようとすると、パス全体の再設定が生じ、変更の必要の無い部分まで再設定の影響を受けてしまうという問題が生じた。
【０００７】
また有料コンテンツ配信サービスではデータｓｅｎｄｅｒの信頼性をあげるため、ビデオ配信サーバを二重化して、冗長化された配信サーバからマルチキャスト配信するメカニズムが必要になる。このような場合にはｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔの転送経路が必要になるが、従来の技術ではｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰの設定に対応するだけでｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰ設定に対応せず、高信頼のＭＰＬＳパスを設定できない問題が存在した。
【０００８】
さらに上記の提案方式では、設定されたマルチキャストＭＰＬＳに複数のマルチキャストトラヒックを関連付けられないために、例えばＩＰマルチキャストトラヒックの転送の場合にはマルチキャストＬＳＰにｓｅｎｄｅｒが限定されたマルチキャストグループアドレスが一つ（Ｓ，Ｇ）トラヒックのみしか割り当てられなかったため、単一のマルチキャストＬＳＰに複数のｓｅｎｄｅｒを共有した（＊、Ｇ）マルチキャストトラヒック転送、単一のマルチキャストＬＳＰに複数のｓｅｎｄｅｒグループ、複数のマルチキャスト配信アドレス（｛Ｓ｝、｛Ｇ｝）を収容するスケーラブルなマルチキャストトラヒック転送できない問題点が存在した。
【０００９】
本発明はこのような背景をもとに行われたものであり、大規模ＭＰＬＳネットワーク環境で、ソース起動、リーフ起動のマルチキャストパス設定が可能で、両設定メカニズムが相互に矛盾無く相互運用可能なマルチキャストＭＰＬＳパス設定可能な通信システムおよびネットワークを確立することを第一の主要な目的とする。また上記環境下で、ＱｏＳ保証可能なマルチキャスト転送経路を設定可能な通信システムおよびネットワークを確立することを第二の目的とする。さらに、上記環境下で設定したマルチキャストＬＳＰ全体の再設定を伴わず、必要な部分ツリーの追加・削除・修正機能を実現するマルチキャストＭＰＬＳ環境下でトラヒックエンジニアリングが可能な通信システムおよびネットワークを確立することを第三の目的とする。また、上記環境下でｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰだけでなく、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定可能な通信システムおよびネットワークを確立することを第四の目的とする。さらに本発明では、単一のマルチキャストＬＳＰにさまざまなトラヒックを高い自由度で収容可能な通信システムおよびネットワークを確立することを第五の目的とする。
【００１０】
【課題を解決するための手段】
本発明で規定するマルチキャストＭＰＬＳプロトコルはマルチキャスト転送においてＱｏＳ保証、トラヒックエンジニアリング転送を実現するために規定されるものである。本プロトコルを実装したＭＰＬＳノードを用いれば、ユニキャスト、マルチキャスト混在のＭＰＬＳ網を構築することが可能となることを第一の特徴とする。
【００１１】
また、本プロトコルはｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰ、ｍｕｌｔｉ−ｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰ、リングトポロジのＬＳＰ設定機能を有することを第二の特徴とする。
【００１２】
またｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰはＳｅｎｄｅｒ起動のＬＳＰ設定、リーフ起動のＬＳＰ設定により設定・削除・変更することが可能であることを第三の特徴とする。
【００１３】
また、本プロトコルには設定したｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰのダイナミックなトポロジ変更を可能にするために、Ｓｅｎｄｅｒ起動のＧｒａｆｔ、Ｐｒｕｎｅ処理機能、リーフ起動のＪｏｉｎ、Ｌｅａｖｅ処理機能を備えることを第四の特徴とする。
【００１４】
また、本プロトコルで設定されるＬＳＰにはＩＰマルチキャストパケットのみならず、Ｅｔｈｅｒフレーム、ＳＯＮＥＴ／ＳＤＨフレームなど一般的なパケットフレームを収容することが可能であることを第五の特徴とする。
【００１５】
また、本プロトコルはＲＳＶＰ−ＴＥ、ＲＳＶＰをベースに実現することが可能であることを第六の特徴とする。
【００１６】
従来の技術とは、本発明で規定したプロトコルを実装するだけで、ＰＩＭ−ＳＭなどのＩＰマルチキャストルーティングプロトコルの実装無しで、同一ＭＰＬＳネットワークとしてユニキャスト・マルチキャスト混在の転送をサポートできる点が大きく異なる。また、ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔだけでなく、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定できる点が大きく異なる。さらに、上記ＬＳＰをソース起動、リーフ起動（Ｓｅｎｄｅｒ ＬＳＲ(Label Switching Router)、Ｌｅａｆ ＬＳＲが）で設定、削除、修正できる点、つまり同一のプロトコルで両方の起動メカニズムがインターワークする環境で同時動作する点が大きく異なる。特に、ＬＳＰツリー全体の設定、削除だけでなく、部分ツリーの設定、削除、修正機能のためにＧｒａｆｔ、Ｐｒｕｎｅ、Ｊｏｉｎ、Ｌｅａｖｅ機能を備える点が大きく異なる。また、ＩＰトラヒックだけでなく、Ｅｔｈｅｒフレーム、ＳＯＮＥＴ／ＳＤＨフレームなどを収容し、マルチプロトコルのマルチキャスト転送に対応できる点が大きく異なる。
【００１７】
すなわち、本発明の第一の観点はマルチキャストＭＰＬＳ通信方法であって、本発明の特徴とするところは、ソース起動のマルチキャストＭＰＬＳパス設定機能として、マルチキャストＭＰＬＳのパス設定起動ノードは、マルチキャスト転送経路と当該転送経路上に設定すべきパス情報を、パス設定要求メッセージに格納し、当該パス設定要求メッセージを指定されたマルチキャスト転送経路の次ホップのノードに送出し、当該パス設定要求メッセージを受信したノードは、当該ノード上に要求されたマルチキャスト転送経路が設定可能な場合には、当該パス設定要求メッセージ内のパス設定情報を自ノード内に一時保持し、当該パス設定要求メッセージ内の経路指定情報により次のマルチキャスト転送経路を判定し、それらのマルチキャスト転送経路上に存在する複数の次ホップのノードに当該パス設定要求メッセージをコピーして送出し、宛先となるマルチキャストリーフノードは、自身がリーフノードであることを判定し、当該パス設定要求メッセージが転送された経路にＭＰＬＳ転送経路を設定可能な場合には、当該ＭＰＬＳパスで使用するラベルを割当て、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出し、当該パス設定確認メッセージを受信した上流ノードは、前記一時保持してあるパス設定情報を確認し、下流ノードの転送に使用するラベルを確認することにより当該ノードと下流ノードとの間のラベルバインディングを設定し、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを確認し、全経路からパス設定確認メッセージが到達した場合には、当該ノードと下流ノードとの間のＭＰＬＳ転送経路を確定し、当該ノードと上流ノードとの間で使用するラベルを確定し、パス設定確認メッセージに格納し、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出し、前記パス設定起動ノードは、前記パス設定確認メッセージが下流ノードでマージされて自ノードに到達したときに、指定されたマルチキャスト転送路にマルチキャストＭＰＬＳパスを設定するところにある。
【００１８】
また、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを待っているノードは、最初のパス設定確認メッセージが到達してから、タイマを作動させ、全ての転送経路からパス設定確認メッセージが到達した場合にタイマを停止させ、全ての転送経路からパス設定確認メッセージが到達する前にタイマが示す値が前もって設定された値になったならば、パス設定確認メッセージを上流ノードへ送付することが望ましい。
【００１９】
さらに、マルチキャストパスの一部または全体の設定に失敗した際に、当該失敗に関わるエラーの発生した箇所のノードは、当該エラー原因および当該エラー発生箇所を通知するエラー通知メッセージを作成して送出し、前記パス設定起動ノードは、このエラー通知メッセージを受信してエラーが起こった全箇所の情報を収集し、この収集結果をパス設定起動者に通知することが望ましい。
【００２０】
また、リーフ起動のマルチキャストツリー参加機能として、マルチキャスト転送経路のリーフノードは、あるマルチキャストツリーに参加したい場合に、当該マルチキャストツリーのマルチキャストＭＰＬＳパス情報を参加要求メッセージに格納して送出し、当該参加要求メッセージにより参加要請されたマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該参加要求メッセージの情報からパス参加要請をしているパス設定起動者宛にマルチキャストツリーの枝ＬＳＰを設定することが望ましい。
【００２１】
さらに、マルチキャストツリーの枝ＬＳＰの設定に失敗した際に、当該失敗に関わるエラー発生を検出したノードは、前記参加要請されたマルチキャストＬＳＲに対して当該失敗理由を通知し、この通知により当該失敗理由を通知された前記参加要請されたマルチキャストＬＳＲは、前記参加要求メッセージを送出したリーフノードに当該枝ＬＳＰの設定に失敗したことを通知することが望ましい。
【００２２】
また、リーフ起動のパス設定ノードの指定機能として、マルチキャスト転送経路のリーフノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域などの情報を収集し、収集された情報を分析し、この分析結果から当該リーフノードに向けてトラヒックを送出するためのパスの分岐点を決定し、当該リーフノードに向けて設定されるパスの接続要求メッセージを作成し、決定した前記分岐点に対して送出し、
当該パス設定要求メッセージを受信した当該分岐ノードはリーフノードに対してパスを設定することが望ましい。
【００２３】
また、パス設定要求メッセージが経由したノードは、当該パス設定要求メッセージに自ノードの情報を経路履歴として記録し、当該メッセージの宛先ノードは、当該経路履歴に沿ってパスを設定し、ネットワーク内のノードは、当該経路履歴からパスのループを検知することが望ましい。
【００２４】
これにより、ソース起動およびリーフ起動のマルチキャストパス設定が可能で、両設定メカニズムが相互に矛盾無く相互運用可能とすることができる。
【００２５】
また、ソース起動のパス設定における適切な分岐点の選択機能として、マルチキャスト転送経路のリーフノードから分岐点として最適と判断され、パス設定要求を受信したマルチキャスト転送経路を構成するノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域を含む情報を収集し、収集された情報を分析し、この分析結果から、より分岐点として適したマルチキャスト転送経路を構成するノードを検索し、そのようなノードが発見された場合には、リーフノードから分岐点として判断された前記ノードが、分岐するパスを設定することを要求するメッセージを作成し、前記発見されたノードに向けて送出し、メッセージを受信した前記発見されたノードは、最初にパス設定の要求が出されたノードで行われたのと同様の手段で情報収集を行い、この収集した情報を分析し、この分析された結果から、さらに分岐点として適したノードを検索し、そのようなノードに対しパス設定要求を送出することが望ましい。
【００２６】
これにより、ネットワーク環境に応じて最適なマルチキャスト転送経路を動的に設定することができる。
【００２７】
また、マルチキャスト転送経路のリーフノードは、自身が収容するクライアントの当該データの視聴状態を判定し、この判定が当該マルチキャストエッジＬＳＲに到達するマルチキャストＬＳＰを不要と判定した場合には、当該マルチキャストＭＰＬＳパスの不要部分を削除し、この削除する際に、離脱要求メッセージに離脱対象のマルチキャストＬＳＰ情報を格納して送出し、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該離脱要求メッセージの情報からパス離脱要請をしているリーフノードまでのマルチキャストツリーの枝ＬＳＰを削除することが望ましい。
【００２８】
これにより、不要となるマルチキャストＭＰＬＳパスを速やかに削除し、ネットワークリソースを有効に利用することができる。
【００２９】
また、設定されたマルチキャストＬＳＰに部分ツリーを追加するために、部分ツリーを追加する接木ノードを選択し、前記接木ノードに接木する部分ツリー情報を通知して接木処理を要請し、接木処理を要請された前記接木ノードが部分ツリーを構築し、接木された部分ツリーの接木処理結果を、前記接木処理を要請したノードに通知することが望ましい。
【００３０】
さらに、前記部分ツリーを構築する際に、部分ツリーの構築に失敗したときには、前記接木処理を要請された接木ノードが当該失敗箇所の情報を収集して前記接木処理を要請したノードに通知することが望ましい。
【００３１】
また、設定されたマルチキャストＬＳＰの部分ツリーを剪定するために、部分ツリーを剪定する剪定ノードを選択して当該剪定ノードに剪定処理を要請し、この剪定処理を要請したノードに対して前記剪定ノードにより削除する部分ツリー情報を通知し、前記剪定ノードが部分ツリーを剪定し、この剪定された部分ツリーの剪定処理結果を、前記剪定処理を要請したノードに通知することが望ましい。
【００３２】
これにより、ネットワーク環境に応じてマルチキャストＬＳＰのツリー構造を動的に最適な形に変化させることができる。したがって、設定したマルチキャストＬＳＰ全体の再設定を伴わず、必要な部分ツリーの追加または削除または修正機能を実現することができる。
【００３３】
また、ソースおよびリーフの相互運用機能として、マルチキャストＭＰＬＳパス設定時に同一転送サービスに含まれる複数のＬＳＰを１つの束として扱うためのトラヒックエンジニアリングトンネルを識別するための第一の情報と、同一転送サービスを受けるトラヒックグループを識別するための第二の情報と、トラヒックエンジニアリングトンネル内でＬＳＰを識別するための第三の情報とが、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定することが望ましい。
【００３４】
これにより、複数の転送サービスが混在するネットワーク環境下でもマルチキャストセッション識別子を用いて、ソースおよびリーフの双方から特定の転送サービスに関わるマルチキャストＭＰＬＳパスに関する設定または削除または修正を実行することができる。
【００３５】
また、前記第一および第三の情報がマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定することが望ましい。
【００３６】
また、収容トラヒックの自由度の向上を図るために、前記第二の情報により様々な種別のトラヒックをＬＳＰに対して割り当て、１つのＬＳＰに対して複数のトラヒックを割り当てることが望ましい。
【００３７】
これにより、単一のマルチキャストＬＳＰにさまざまなトラヒックを高い自由度で収容可能である。
【００３８】
また、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ設定機能として、既設のマルチキャストＬＳＰツリーに新たにトラヒックを送出したいソースノードは、新たにトラヒックを流すことを要求しかつ当該ツリーのルートノードまでのＬＳＰ設定を行うことを要求する新規参入メッセージを生成し、当該新規参入メッセージを当該ツリーのルートノードへと送付し、前記ツリーのルートノードは、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰと自ノードからリーフノードまでのＬＳＰを関連付け、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップし、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することが望ましい。
【００３９】
これにより、新たにトラヒック送出したいソースノードが既存のマルチキャストＬＳＰツリーに容易に参入することができ、ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰだけでなく、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定することができる。
【００４０】
また、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ解除機能として、トラヒック送出を止めたいソースノードは、トラヒックを止めることを通知しかつツリーのルートノードまでのＬＳＰを解除することを要請する送出解除メッセージを生成し、当該送出解除メッセージを当該ツリーのルートノードへと送付し、前記ツリーのルートノードは、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでの解除要請のあったＬＳＰと自ノードからリーフノードまでのＬＳＰの関連付けを解除し、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップすることを停止し、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することを停止することが望ましい。
【００４１】
これにより、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰが既に設定されているときに、このＬＳＰに対するトラヒック送出を任意に解除することができる。
【００４２】
また、ツリー構造を持つ転送経路の明示的指定機能として、経路指定を要望するツリーの経路上のノードの情報として当該ツリーのルートノードからサブオブジェクトに対応するノードまでの距離を情報として保持し、この保持された当該サブオブジェクトを深さ優先探索で前記ツリーを走査したときに通る順番で並べ、前記保持された情報から前記ツリーの設定経路をネットワーク中のノードに明示的に指定することが望ましい。
【００４３】
これにより、あらかじめツリー構造を持つ転送経路を明示的に指定することができるため、この転送経路を用いるデータ転送のＱｏＳを保証することができる。
【００４４】
また、メッセージの経路履歴の分岐点での情報結合機能として、着目する一つのメッセージが通過したノードの履歴を記録し、マルチキャストツリーの分岐点でこの着目する一つのメッセージ同士の経路履歴情報を統合し、この統合結果にこの分岐点を特定する情報を組み込むことによりこの分岐点を根とする部分ツリーを表現することが望ましい。
【００４５】
すなわち、着目する一つのメッセージが通過したノードの履歴を記録しておき、マルチキャストツリーの分岐点で当該着目する一つのメッセージ同士の経路履歴情報を統合することによって、この分岐点を根とする部分ツリーを構成するノードの情報を取得することができる。さらに、この情報にこの分岐点を特定する情報として、例えば、この分岐点の識別子あるいはこの分岐点の位置情報を組み込むことにより、この分岐点を根とする部分ツリーを表現することができる。
【００４６】
また、パス設定の失敗を検知したノードは、当該失敗箇所を前記マルチキャストＭＰＬＳパス設定起動ノードに通知するメッセージを作成し、この作成された当該メッセージを前記マルチキャストＭＰＬＳパス設定起動ノードに送出し、前記マルチキャストＭＰＬＳパス設定起動ノードは、通知された前記失敗箇所を使わずにリーフノードまでの経路を再計算し、この再計算された経路を接木するＬＳＲをマルチキャストパスを構成するＬＳＲの中から選択し、接木するパスの経路を前記接木するＬＳＲに対して指示し、前記接木するＬＳＲは、前記指示された経路にしたがってパス設定することが望ましい。
【００４７】
これにより、一度、パス設定に失敗した場合でも速やかに再設定を行うことができ、マルチキャストパスを効率よく構築することができる。
【００４８】
本発明の第二の観点はマルチキャストＭＰＬＳ通信システムであって、本発明の特徴とするところは、マルチキャストＭＰＬＳのパス設定起動ノードは、マルチキャスト転送経路と当該転送経路上に設定すべきパス情報を、パス設定要求メッセージに格納し、当該パス設定要求メッセージを指定されたマルチキャスト転送経路の次ホップのノードに送出する手段を備え、当該パス設定要求メッセージを受信したノードは、当該ノード上に要求されたマルチキャスト転送経路が設定可能な場合には、当該パス設定要求メッセージ内のパス設定情報を自ノード内に一時保持し、当該パス設定要求メッセージ内の経路指定情報により次のマルチキャスト転送経路を判定し、それらのマルチキャスト転送経路上に存在する複数の次ホップのノードに当該パス設定要求メッセージをコピーして送出する手段を備え、宛先となるマルチキャストリーフノードは、自身がリーフノードであることを判定し、当該パス設定要求メッセージが転送された経路にＭＰＬＳ転送経路を設定可能な場合には、当該ＭＰＬＳパスで使用するラベルを割当て、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出する手段を備え、当該パス設定確認メッセージを受信した上流ノードは、前記一時保持してあるパス設定情報を確認し、下流ノードの転送に使用するラベルを確認することにより当該ノードと下流ノードとの間のラベルバインディングを設定する手段と、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを確認し、全経路からパス設定確認メッセージが到達した場合には、当該ノードと下流ノードとの間のＭＰＬＳ転送経路を確定する手段と、当該ノードと上流ノードとの間で使用するラベルを確定し、パス設定確認メッセージに格納し、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出する手段とを備え、前記パス設定起動ノードは、前記パス設定確認メッセージが下流ノードでマージされて自ノードに到達したときに、指定されたマルチキャスト転送路にマルチキャストＭＰＬＳパスを設定する手段を備えたところにある。
【００４９】
また、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを待っているノードは、最初のパス設定確認メッセージが到達してから、タイマを作動させる手段と、全ての転送経路からパス設定確認メッセージが到達した場合にタイマを停止させる手段と、全ての転送経路からパス設定確認メッセージが到達する前にタイマが示す値が前もって設定された値になったならば、パス設定確認メッセージを上流ノードへ送付する手段とを備えることが望ましい。
【００５０】
さらに、マルチキャストパスの一部または全体の設定に失敗した際に、当該失敗に関わるエラーの発生した箇所のノードは、当該エラー原因および当該エラー発生箇所を通知するエラー通知メッセージを作成して送出する手段を備え、前記パス設定起動ノードは、このエラー通知メッセージを受信してエラーが起こった全箇所の情報を収集する手段と、この収集結果をパス設定起動者に通知する手段とを備えることが望ましい。
【００５１】
また、マルチキャスト転送経路のリーフノードは、あるマルチキャストツリーに参加したい場合に、当該マルチキャストツリーのマルチキャストＭＰＬＳパス情報を参加要求メッセージに格納して送出する手段を備え、当該参加要求メッセージにより参加要請されたマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該参加要求メッセージの情報からパス参加要請をしているパス設定起動者宛にマルチキャストツリーの枝ＬＳＰを設定する手段を備えることが望ましい。
【００５２】
さらに、マルチキャストツリーの枝ＬＳＰの設定に失敗した際に、当該失敗に関わるエラー発生を検出したノードは、前記参加要請されたマルチキャストＬＳＲに対して当該失敗理由を通知する手段を備え、この通知する手段により当該失敗理由を通知された前記参加要請されたマルチキャストＬＳＲは、前記参加要求メッセージを送出したリーフノードに当該枝ＬＳＰの設定に失敗したことを通知する手段を備えることが望ましい。
【００５３】
また、マルチキャスト転送経路のリーフノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域などの情報を収集する手段と、収集された情報を分析する手段と、この分析結果から当該リーフノードに向けてトラヒックを送出するためのパスの分岐点を決定する手段と、当該リーフノードに向けて設定されるパスの接続要求メッセージを作成し、決定した前記分岐点に対して送出する手段と、当該パス設定要求メッセージを受信した当該分岐ノードはリーフノードに対してパスを設定する手段とを備えることが望ましい。
【００５４】
また、パス設定要求メッセージが経由したノードは、当該パス設定要求メッセージに自ノードの情報を経路履歴として記録する手段を備え、当該メッセージの宛先ノードは、当該経路履歴に沿ってパスを設定する手段を備え、ネットワーク内のノードは、当該経路履歴からパスのループを検知する手段を備えることが望ましい。
【００５５】
また、マルチキャスト転送経路のリーフノードから分岐点として最適と判断され、パス設定要求を受信したマルチキャスト転送経路を構成するノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域を含む情報を収集する手段と、収集された情報を分析する手段と、この分析結果から、より分岐点として適したマルチキャスト転送経路を構成するノードを検索する手段とを備え、そのようなノードが発見された場合には、リーフノードから分岐点として判断された前記ノードが、分岐するパスを設定することを要求するメッセージを作成し、前記発見されたノードに向けて送出する手段を備え、メッセージを受信した前記発見されたノードは、最初にパス設定の要求が出されたノードで行われたのと同様の手段で情報収集を行う手段と、この収集した情報を分析する手段と、この分析された結果から、さらに分岐点として適したノードを検索する手段と、そのようなノードに対しパス設定要求を送出する手段とを備えることが望ましい。
【００５６】
また、マルチキャスト転送経路のリーフノードは、自身が収容するクライアントの当該データの視聴状態を判定する手段と、この判定する手段が当該マルチキャストエッジＬＳＲに到達するマルチキャストＬＳＰを不要と判定した場合には、当該マルチキャストＭＰＬＳパスの不要部分を削除する手段とを備え、この削除する手段は、離脱要求メッセージに離脱対象のマルチキャストＬＳＰ情報を格納して送出する手段を備え、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該離脱要求メッセージの情報からパス離脱要請をしているリーフノードまでのマルチキャストツリーの枝ＬＳＰを削除する手段を備えることが望ましい。
【００５７】
また、設定されたマルチキャストＬＳＰに部分ツリーを追加するために、部分ツリーを追加する接木ノードを選択する手段と、前記接木ノードに接木する部分ツリー情報を通知して接木処理を要請する手段と、接木処理を要請された前記接木ノードが前記マルチキャストＭＰＬＳパスを設定する手段により部分ツリーを構築する手段と、接木された部分ツリーの接木処理結果を、前記接木処理を要請する手段を備えたノードに通知する手段とを備えることが望ましい。
【００５８】
さらに、前記部分ツリーを構築する手段が部分ツリーの構築に失敗したときには、前記接木処理を要請された接木ノードが当該失敗箇所の情報を収集して前記接木処理を要請する手段を備えたノードに通知する手段を備えることが望ましい。
【００５９】
また、設定されたマルチキャストＬＳＰの部分ツリーを剪定するために、部分ツリーを剪定する剪定ノードを選択して当該剪定ノードに剪定処理を要請する手段と、この剪定処理を要請する手段を備えたノードに対して前記剪定ノードにより削除する部分ツリー情報を通知する手段と、前記剪定ノードが前記マルチキャストＭＰＬＳパスを設定する手段により部分ツリーを剪定する手段と、剪定された部分ツリーの剪定処理結果を、前記剪定処理を要請する手段を備えたノードに通知する手段とを備えることが望ましい。
【００６０】
また、マルチキャストＭＰＬＳパス設定時に同一転送サービスに含まれる複数のＬＳＰを１つの束として扱うためのトラヒックエンジニアリングトンネルを識別するための第一の情報と、同一転送サービスを受けるトラヒックグループを識別するための第二の情報と、トラヒックエンジニアリングトンネル内でＬＳＰを識別するための第三の情報とが、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する手段を備えることが望ましい。
【００６１】
また、前記第一および第三の情報がマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する手段を備えることが望ましい。
【００６２】
また、前記第二の情報により様々な種別のトラヒックをＬＳＰに対して割り当てる手段を備え、１つのＬＳＰに対して複数のトラヒックを割り当てる手段を備えることが望ましい。
【００６３】
また、既設のマルチキャストＬＳＰツリーに新たにトラヒックを送出したいソースノードは、新たにトラヒックを流すことを要求しかつ当該ツリーのルートノードまでのＬＳＰ設定を行うことを要求する新規参入メッセージを生成する手段と、当該新規参入メッセージを当該ツリーのルートノードへと送付する手段とを備え、前記ツリーのルートノードは、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰと自ノードからリーフノードまでのＬＳＰを関連付ける手段と、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップする手段と、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付する手段とを備えることが望ましい。
【００６４】
また、トラヒック送出を止めたいソースノードは、トラヒックを止めることを通知しかつツリーのルートノードまでのＬＳＰを解除することを要請する送出解除メッセージを生成する手段と、当該送出解除メッセージを当該ツリーのルートノードへと送付する手段とを備え、前記ツリーのルートノードは、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでの解除要請のあったＬＳＰと自ノードからリーフノードまでのＬＳＰの関連付けを解除する手段と、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップすることを停止する手段と、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することを停止する手段とを備えることが望ましい。
【００６５】
また、経路指定を要望するツリーの経路上のノードの情報として当該ツリーのルートノードからサブオブジェクトに対応するノードまでの距離を情報として保持する手段と、この保持する手段に保持された当該サブオブジェクトを深さ優先探索で前記ツリーを走査したときに通る順番で並べる手段と、前記保持する手段に保持された情報から前記ツリーの設定経路をネットワーク中のノードに明示的に指定する手段とを備えることが望ましい。
【００６６】
また、着目する一つのメッセージが通過したノードの履歴を記録する手段と、マルチキャストツリーの分岐点でこの着目する一つのメッセージ同士の経路履歴情報を統合する手段と、この統合結果にこの分岐点を特定する情報を組み込むことによりこの分岐点を根とする部分ツリーを表現する手段とを備えることが望ましい。
【００６７】
また、パス設定の失敗を検知したノードは、当該失敗箇所を前記マルチキャストＭＰＬＳパス設定起動ノードに通知するメッセージを作成する手段と、この作成する手段により作成された当該メッセージを前記マルチキャストＭＰＬＳパス設定起動ノードに送出する手段とを備え、前記マルチキャストＭＰＬＳパス設定起動ノードは、通知された前記失敗箇所を使わずにリーフノードまでの経路を再計算する手段と、この再計算する手段により再計算された経路を接木するＬＳＲをマルチキャストパスを構成するＬＳＲの中から選択する手段と、接木するパスの経路を前記接木するＬＳＲに対して指示する手段とを備え、前記接木するＬＳＲは、前記指示する手段により指示された経路にしたがってパス設定する手段を備えることが望ましい。
【００６８】
本発明の第三の観点は、本発明のマルチキャストＭＰＬＳ通信システムを備えたことを特徴とするネットワークである。
【００６９】
本発明の第四の観点は、情報処理装置にインストールすることにより、その情報処理装置に、本発明のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、情報処理装置にインストールすることにより、その情報処理装置を、本発明のマルチキャストＭＰＬＳ通信システムに相応する装置として動作させることを特徴とするプログラムである。
【００７０】
本発明の第五の観点は、本発明のプログラムが記録された前記情報処理装置読み取り可能な記録媒体である。本発明のプログラムは本発明の記録媒体に記録されることにより、前記情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記情報処理装置に本発明のプログラムをインストールすることもできる。
【００７１】
これにより、コンピュータ装置等の情報処理装置を用いて、スケーラブルなコンテンツ配信が可能となり大規模コンテンツ配信ネットワーク環境を実現することができる。
【００７２】
【発明の実施の形態】
（サポートするマルチキャストＭＰＬＳ種別）
本発明のマルチキャストＭＰＬＳプロトコルではｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰの設定・削除・更新メカニズムをサポートする。Ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰはコンテンツ配信サービスのような、センターサーバから各クライアントにスター型のトポロジでマルチキャスト配信する場合に適用される。
【００７３】
また本プロトコルで設定されたｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰにはＩＰトラヒック、ＶＬＡＮなどのＥｔｈｅｒトラヒックなどのマルチプロトコルのトラヒックが収容可能である。例えばＩＰマルチキャストトラヒックの場合には、図１に示すように、本プロトコルで規定されるｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ ＬＳＰには１）単一のｓｅｎｄｅｒから送信される単一マルチキャストアドレス宛の（Ｓ，Ｇ）、２）任意のｓｅｎｄｅｒから送信される単一マルチキャストアドレス宛の（＊、Ｇ）、複数のｓｅｎｄｅｒから送信される単一マルチキャストアドレス宛の（｛Ｓ｝、Ｇ）、３）複数のｓｅｎｄｅｒ、複数のマルチキャストアドレス宛の（｛Ｓ｝、｛Ｇ｝）のマルチキャストトラヒックが収容可能である。
【００７４】
このプロトコルではマルチキャスト転送経路トポロジを共有し、同一の転送制御で転送されるトラヒックが同一のＦＥＣとして扱われる。
【００７５】
本プロトコルを用いればｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰも設定可能である。ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰはセンターサーバを冗長化したマルチキャスト配信や、双方向テレビ電話会議などの配信形態に利用される。この配信形態では、図２に示すようにランデブーポイントまで複数のＳｅｎｄｅｒのｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＬＳＰが接続され、ランデブーポイントからスター型のマルチキャスト配信を行う通信形態である。ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰはＲＰを設定し、ＳｅｎｄｅｒからＲＰノードまではｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＬＳＰを設定する。ＲＰからリーフノードまではＲＰノードを起点とするｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定することで実現される。この場合、ＳｅｎｄｅｒからＲＰノードまでのｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＬＳＰはＲＰで終端されず、ＲＰノード起点のｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰに接続される。つまりＳｅｎｄｅｒからリーフノードまでＭＰＬＳ転送される。
【００７６】
（対応するマルチキャスト配信アプリケーション）
本プロトコルで規定されるマルチキャストＭＰＬＳプロトコルは種々のマルチキャスト通信形態を持つアプリケーションに対応することができる。例えば、マルチキャスト配信サーバと連携したマルチキャストＬＳＰを設定したい場合には、マルチキャストトラヒックのｓｅｎｄｅｒがトラヒック受信者までの全リーフ上にマルチキャストＬＳＰが確立されたことを確認した後で、トラヒック送出を行うことが望ましい。このような場合には、マルチキャストＬＳＰはＳｅｎｄｅｒ起動のパス設定メカニズムで設定されることが望ましい。
【００７７】
またＱｏＳ保証を実現するマルチキャストＬＳＰを設定するためには、単一のノードがネットワークのＱｏＳ情報をもとに最適なマルチキャストＬＳＰを設定することが望ましいのでＳｅｎｄｅｒ起動のパス設定メカニズムが有効である。
【００７８】
また、マルチキャストトラヒックを受信するクライアントの視聴状態に応じて最適なマルチキャストＬＳＰを設定したい場合には、リーフ起動のパス設定メカニズムが必要になる。このような例としては、リーフノードがＩＧＭＰを実装し、クライアントのマルチキャストトラヒックの視聴状態を監視しながら、リーフ起動でマルチキャストＬＳＰを設定する場合が想定される。
【００７９】
また両アプリケーションが混在する環境も想定されるため、Ｓｅｎｄｅｒ起動でも、リーフ起動でも同一のマルチキャストＬＳＰが設定可能となるメカニズムがマルチキャストＭＰＬＳプロトコルに求められる。
【００８０】
（実現されるマルチキャストＬＳＰ設定機能と起動メカニズム）
本プロトコルには、このようなマルチキャストアプリケーションに対応するため、Ｓｅｎｄｅｒ起動のパス設定メカニズム、リーフ起動の両方のパス設定メカニズムが実装されている。
【００８１】
Ｓｅｎｄｅｒ起動のマルチキャストＬＳＰ制御メカニズムには、１）マルチキャストパスツリー設定メカニズム、２）マルチキャスト部分ツリー追加メカニズム、３）マルチキャスト部分ツリー削除メカニズムが実装されている。またリーフ起動のマルチキャストＬＳＰ制御メカニズムには４）マルチキャストパスツリー設定メカニズム、５）リーフ設定メカニズム、６）リーフ削除メカニズムが実装されている。図３に本プロトコルで実現されるマルチキャストＬＳＰの設定機能概要を示す。パスの設定・削除、部分ツリーの追加・削除動作に対してＳｅｎｄｅｒ起動、リーフ起動のＬＳＰ制御は同一のマルチキャストＬＳＰツリー状態
（効果）を設定できるように設計されており、プロトコル上、Ｓｅｎｄｅｒ起動とリーフ起動のマルチキャストＬＳＰ制御が相互にインターワーク可能となるアーキテクチャとなっている。
【００８２】
（プロトコル基本動作概要）
次に、本マルチキャストＭＰＬＳプロトコルで実現されるマルチキャストＬＳＰ設定の基本動作を説明する。本マルチキャストＭＰＬＳプロトコルはＲＳＶＰ−ＴＥプロトコルにマルチキャストＬＳＰ設定機能を機能拡張することにより実現される。図４に、Ｓｅｎｄｅｒを起点としたマルチキャストＬＳＰの設定概要を示す。図４に示すようにマルチキャストＬＳＰを設定するＳｅｎｄｅｒは、Ｐａｔｈ ｍｅｓｓａｇｅに設定するツリー情報をＴＥＲＯ情報として格納する。ＥＴＲＯを用いた明示的なマルチキャストＬＳＰの設定概要は図５に示す。図５ではＮ＃１〜Ｎ＃１３のノードでネットワークが構成されている。このとき、図に示したトポロジでｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定する場合を想定する。この場合、ソースノードによって規定されるＴＥＲＯ情報は図５内に示すとおりで、ソースノードを起点としてＤｅｐｔｈ−ｆｉｒｓｔ−ｏｒｄｅｒで規定される。ノード番号に付与された（）内の数値はソースノードからの距離情報としてホップ数を示す。このようにしてＰａｔｈ ｍｅｓｓａｇｅはこのＴＥＲＯ情報をもとにツリー下流ノードでコピー分岐され、リーフノードまで転送される。図４に示すようにＰａｔｈ ｍｅｓｓａｇｅがリーフノードまで到達すると、リーフノードがマルチキャストＬＳＰを設定可能な場合には、リーフノードと１ホップ上流ノード間の転送に使用されるラベル値を付与しＲｅｓｖ ｍｅｓｓａｇｅをＰａｔｈ ｍｅｓｓａｇｅが到達した逆経路に従って、上流に通知する。その後、パスの設定が可能な場合は上流ノードで順々にラベル値が付与される。上流に通知されるＲｅｓｖ ｍｅｓｓａｇｅはツリー分岐点のノードでマージされ上流に通知される。この動作がＳｅｎｄｅｒまで繰り返されることによりマルチキャストＬＳＰのパス設定が完了する。この動作はユニキャストのＲＳＶＰ−ＴＥで使用されるＤｏｗｎｓｔｒｅａｍ Ｏｎ Ｄｅｍａｎｄモードと同一のアーキテクチャによって動作する。
【００８３】
（Ｍ−ＬＳＲに設定されるマルチキャストＬＳＰ情報）
本プロトコルを用いて、このような動作でマルチキャストＬＳＰを設定した場合に、マルチキャストＬＳＰ上のＬＳＲに設定されるＬＳＰ情報について概観する。図６に設定されるマルチキャストＭＰＬＳのＬＳＰ情報とＬＳＲの保持情報を示す。掲載される図は、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、ＧのＬＳＲで構成されるマルチキャストＬＳＰを示している。本プロトコルでマルチキャストＬＳＰが設定されると、ツリー上のＬＳＲには入出力ポートでラベルスワッピングするためのＭＰＬＳフォワーディングテーブルが構成される。掲載される図のＬＳＲ（Ｂ）では、入力インタフェースＩｆ１からラベル値：３０で入力したＭＰＬＳパケットは、出力インタフェースＩｆ２、Ｉｆ３でラベル値１５、６５にラベルスワップされて転送される。このとき、本プロトコルのマルチキャストＬＳＰ設定メッセージには、ＬＳＰ内に収容されるセッション情報が含まれるため、この情報があわせて各ツリー上のＬＳＲに設定されている。図６の例では、ＩＰマルチキャストトラヒック（Ｓ，Ｇ）がマルチキャストＬＳＰで転送されているので、各ＬＳＲには（Ｓ，Ｇ）情報がＦＥＣ情報として登録されている。
【００８４】
（Ｍｕｌｔｉｃａｓｔ Ｓｅｓｓｉｏｎ）
既存のＲＳＶＰ−ＴＥで定義されているＳＥＳＳＩＯＮ Ｏｂｊｅｃｔはマルチキャスト用途ではないため、本発明では新たにマルチキャスト用のＳＥＳＳＩＯＮ Ｏｂｊｅｃｔを定義する。
【００８５】
提案では、マルチキャストのトンネルを一意に識別するために、新しいＣ−ＴｙｐｅとしてＳＥＳＳＩＯＮ Ｏｂｊｅｃｔ ＭＵＬＴＩＣＡＳＴ＿ ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４、ＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６を追加する。 ＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４とＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６はＴｕｎｎｅｌ Ｓｅｎｄｅｒ ＡｄｄｒｅｓｓとＭｕｌｔｉｃａｓｔ Ｔｕｎｎｅｌ ＩＤをもつ。このようにトンネルを一意に識別するためにＴｕｎｎｅｌ Ｓｅｎｄｅｒ Ａｄｄｒｅｓｓを入れることで、ユニキャストと同様にトンネルは複数のマルチキャストＬＳＰをセットとして扱うことが出来るようになる。
【００８６】
ユニキャストのＲＳＶＰ−ＴＥの定義ではＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４またＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６のｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔに終端点アドレスを入れることになっているが、これをマルチキャストに拡張するために、このｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔにマルチキャストアドレスを入れて、ＳＥＳＳＩＯＮを識別することも考えられる。ただし、この場合はｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔの領域が１アドレス分しか定義しない場合には扱うことが出来るマルチキャストグループが１つに限られてしまうため、複数のマルチキャストＬＳＰをセットとして扱うことができない問題点、そもそもＩＰマルチキャストトラフィックしか転送できなくなる問題点が存在するため、本発明では採用しない。マルチキャストトンネルを一意に識別するためにはＴｕｎｎｅｌ ｅｎｄ ｐｏｉｎｔだけではなく、Ｔｕｎｎｅｌ ｓｅｎｄｅｒ ａｄｄｒｅｓｓでも可能であるので、本発明ではＴｕｎｎｅｌ ｓｅｎｄｅｒ ａｄｄｒｅｓｓを用いる。
【００８７】
図７に、新たに定義するＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４とＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６のフォーマットを示す。
【００８８】
（ＦＥＣ）
本プロコトルでは、ＦＥＣ Ｏｂｊｅｃｔという新しいＯｂｊｅｃｔを定義する。ＦＥＣ Ｏｂｊｅｃｔは本プロトコルで、規定されるマルチキャストＭＰＬＳ転送で同一の転送サービスを受けるトラヒックグループを規定するために用いられる。たとえば、ＩＰのマルチキャスト転送を考慮する場合には、同一の転送ＦＥＣ ＯｂｊｅｃｔはＬＳＰに割り当てられたマルチキャストグループを表す。ＦＥＣ Ｏｂｊｅｃｔにはグループアドレス（Ｇ）や、グループアドレスとソースアドレスのセット（Ｓ、Ｇ）、が入れられる。（＊、Ｇ）のＩＰマルチキャストトラヒックを収容する、場合には前者のＴｙｐｅのＦＥＣ Ｏｂｊｅｃｔを使用し、（Ｓ，Ｇ）、（｛Ｓ｝，｛Ｇ｝）のＩＰマルチキャストトラヒックを収容する場合には後者のＴｙｐｅのＦＥＣ Ｏｂｊｅｃｔを使用する。（｛Ｓ｝，｛Ｇ｝）の場合には複数のソースアドレス、グループアドレスが必要になるため、当該ＴｙｐｅのＦＥＣ ｏｂｊｅｃｔが複数含まれることになる。
【００８９】
また従来のｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＲＳＶＰ−ＴＥではｓｅｎｄｅｒのみがＦＥＣ情報をもち、ＦＥＣ情報が途中ノードに伝えられることはなかった。しかしながら、マルチキャストＭＰＬＳ環境下では、先に述べたようにマルチキャストＬＳＰの途中ノードがパス設定・削除・修正起動者となり得るため、途中ノードがＦＥＣ情報を持つことが必要となる。上記の例の一つとしてはＬｅａｆ Ｉｎｉｔｉａｔｅ型のマルチキャストツリー生成・削除・修正があり、この機能をサポートするためには、途中ノードはＦＥＣ情報を持たなければならない。あるマルチキャストグループのＬＳＲである途中ノードはそのマルチキャストグループに対するＬｅａｆからの参加要求パケットを横取りできなければならない。横取りするためにマルチキャストグループの情報を知る必要がある。
【００９０】
ＦＥＣ Ｏｂｊｅｃｔは長さの異なるｓｕｂｏｂｊｅｃｔの集合とする。ｓｕｂｏｂｊｅｃｔとして本バージョンではＩＰｖ４のＳｈａｒｅｄ Ｍｕｌｔｉｃａｓｔ Ｔｒｅｅ、Ｓｏｕｒｃｅ＿Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ ＴｒｅｅとＩＰｖ６のＳｈａｒｅｄ Ｍｕｌｔｉｃａｓｔ Ｔｒｅｅ、Ｓｏｕｒｃｅ＿Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ Ｔｒｅｅを定義する。ＦＥＣ Ｏｂｊｅｃｔに新たなｓｕｂｏｂｊｅｃｔを定義することによって、本プロトコルが、例えばＥｔｈｅｒｎｅｔ（登録商標）のようなトラヒックを扱うことが出来る。しかし、ＩＰ以外のトラヒックについては本バージョンでは定義を行わない。このようにマルチキャストアドレスをＳｅｓｓｉｏｎ Ｏｂｊｅｃｔに含まないことによって、１つのＴｕｎｎｅｌが複数のマルチキャストＬＳＰを扱うことができる。ＦＥＣ Ｏｂｊｅｃｔは長さの異なるｓｕｂｏｂｊｅｃｔの集合なので、１つのＬＳＰに対して複数のマルチキャストグループを持つことができる。ＦＥＣ Ｏｂｊｅｃｔは下記の特徴を持つ。
▲１▼ＦＥＣ ＯｂｊｅｃｔはＥＲＯと似たフォーマットとする。
▲２▼ＦＥＣ Ｏｂｊｅｃｔは長さの異なるｓｕｂｏｂｊｅｃｔの集合からなる。▲３▼ｓｕｂｏｂｊｅｃｔは共通のヘッダを持ちヘッダ内にはｓｕｂｏｂｊｅｃｔの種別を識別するためのＴｙｐｅとｓｕｂｏｂｊｅｃｔのトータルの長さを示すＬｅｎｇｔｈを持つ。
▲４▼Ｔｙｐｅは４つ。 Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４、Ｓｏｕｒｃｅ＿ ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４ 、Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６ 、Ｓｏｕｒｃｅ＿Ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６
【００９１】
ＦＥＣ Ｏｂｊｅｃｔ全体のフォーマット（ｓｕｂｏｂｊｅｃｔの集合）を図８に示す。Ｓｕｂｏｂｊｅｃｔの共通ヘッダ（ＴｙｐｅとＬｅｎｇｔｈと実際の中身）を図９に示す。図９のＴｙｐｅはＳｕｂｏｂｊｅｃｔのタイプであり、
０：Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
１：Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
２：Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
３：Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
である。また、Ｌｅｎｇｔｈは、Ｓｕｂｏｂｊｅｃｔトータルの長さでＢｙｔｅ単位であり、最低４で４の倍数でなければならない。
【００９２】
ＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４を図１０に示す。図１０のＴｙｐｅは、
０×００ Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
である。また、Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ ８．
である。
【００９３】
ＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４を図１１に示す。図１１でＴｙｐｅは、
０×０１ Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
である。Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ １２．
である。
【００９４】
ＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を図１２に示す。図１２でＴｙｐｅは、
０×０２ Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
である。Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ ２０．
である。
【００９５】
ＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を図１３に示す。図１３でＴｙｐｅは、
０×０２ Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
である。Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ ３６．
である。
【００９６】
（明示的なマルチキャスト転送経路指定とＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔ）
ＲＳＶＰ−ＴＥの使用目的として明示的経路設定がある。ＲＦＣ３２０９では明示経路を表すため、Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔ（ＥＲＯ）を定義している。ＥＲＯは経路上のノードを表すＳｕｂｏｂｊｅｃｔのリストである。マルチキャストの場合、パスはツリー状に形成される。このため、ＥＲＯをツリーが表記できるよう拡張する必要がある。ここで、Ｔｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔ（ＴＥＲＯ）を定義する。
【００９７】
ＴＥＲＯはＰａｔｈ ｍｅｓｓａｇｅのように主にパス設定に関わるメッセージ中に存在する。ＴＥＲＯはそのメッセージが転送されるＳｕｂｔｒｅｅ上の全ノードを示す。特にｓｅｎｄｅｒからＰａｔｈ ｍｅｓｓａｇｅのＴＥＲＯは自身を起点とするマルチキャストツリーのトポロジ情報を含んでいる。これらの情報は通常メッセージの作成者以外は削除することができない。このため、ＴＥＲＯはツリーを構成する全ノードにマルチキャストツリーのトポロジを通知するために使用される。
【００９８】
ＴＥＲＯはマルチキャストツリーの構成ノードを示すＳｕｂｏｂｊｅｃｔからなる。ツリー構造を表現するため、ＴＥＲＯにはツリーの接続状況を示す情報が必要となる。この情報は、各Ｓｕｂｏｂｊｅｃｔをｄｅｐｔｈ−ｆｉｒｓｔ−ｏｒｄｅｒに並べ、かつ各Ｓｕｂｏｂｊｅｃｔにｓｅｎｄｅｒから対応するノードまでの距離を記録することで保持される。
【００９９】
図１４にマルチキャストツリーとそれに対応するＴＥＲＯの表記を示す。図１５にＴｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔのフォーマットを示す。図１５のＬは、サブオブジェクト末端となるｅｘｐｌｉｃｉｔ ｒｏｕｔｅの属性を示す。ｓｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅの末端であれば０。ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅの末端であれば１。図１５のＴｙｐｅは、
０ｘ０１ ＩＰｖ４ ａｄｄｒｅｓｓ
０ｘ０２ ＩＰｖ６ ａｄｄｒｅｓｓ
である。Ｌｅｎｇｔｈは、サブオブジェクトの長さ（ｂｙｔｅ表記）である。ＩＰｖ４／６ ａｄｄｒｅｓｓは、サブオブジェクトが示すノードのＩＰｖ４／６アドレスである。ノードが複数のＩＰアドレスを持つ場合、ツリーの入り口インタフェースのＩＰアドレスを記録する。Ｐｒｅｆｉｘ ｌｅｎｇｔｈは、ＩＰｖ４／６ ｐｒｅｆｉｘの長さである。Ｄｉｓｔａｎｃｅは、ｓｅｎｄｅｒからサブオブジェクトが示すノードまでの距離であり、Ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅの区間の距離は１とする。
【０１００】
（明示的なマルチキャスト転送経路の Ｓｔｒｉｃｔ と Ｌｏｏｓｅ指定）明示経路の種類として２つの経路が存在する。Ｓｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅはパスの経路を明示的に設定する方式である。Ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅはパスの両端だけを明示的に指定し、途中経路をメッセージの作成者が決めずに他の経路設定アルゴリズムやノードに計算させる方式である。外部アルゴリズムの例としてはＯＳＰＦ−ＴＥやＩＳ−ＩＳ−ＴＥなどがあげられる。これらの経路指定はリンクごとに指定が可能である。そして、一つのマルチキャストパス中にＳｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅとＬｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅが混在する状況も存在する。
【０１０１】
このため、ＴＥＲＯにはこれらの経路指定法の使用箇所を示す情報が必要となる。この条件を満たす情報としては、Ｓｕｂｏｂｊｅｃｔが示すノードの入力リンクが属するパスの経路指定法に関する情報があげられる。すなわち、ノードの入力リンクがＳｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されたパスの一部であるならば、そのＳｕｂｏｂｊｅｃｔは当該ノードがＳｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅであるという情報を持つ。
【０１０２】
ここで、ｓｅｎｄｅｒ−ノード間の距離についてマルチキャストツリーの一部がＬｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されている場合を想定して考える。この場合、Ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されている区間の正確な距離は、通常測定不能である。このため、ｓｅｎｄｅｒ−ノード間の距離を求めるのは困難になる。そこで、本プロトコルではＬｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されたパスの両端部分のノード間は距離が１であると定義する。この条件を用いることで、前節で挙げたＴＥＲＯの記述法を使用してマルチキャストツリーを表現することが可能となる。
【０１０３】
（マルチキャスト転送経路情報の記録とＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔ）
ＲＳＶＰ−ＴＥで使用されるメッセージは通過した経路を情報として保持する。メッセージを受け取ったノードはこの情報をパスのループ検出や経路の確認に使用する。Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔはこの通過経路情報を保持するＯｂｊｅｃｔである。ＲＲＯは通過ノードを示すＳｕｂｏｂｊｅｃｔのリストである。これらのＳｕｂｏｂｊｅｃｔは通った経路順に整列される。このため、メッセージがパスの両端に到着するとき、ＲＲＯはパスの全トポロジを示す。
【０１０４】
マルチキャスト通信の場合、複数のメッセージを情報統合し、１つのメッセージにまとめることがある。この場合、ＲＲＯはそれらのメッセージが通ってきたすべてのノードを示す。このため、ＲＲＯをツリー構造が表せるように拡張する必要がある。ここでこの拡張されたＲＲＯをＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔ（ＴＲＲＯ）と呼ぶ。
【０１０５】
メッセージが分岐ノードで情報統合されるとき、各メッセージのＴＲＲＯも同時に統合される。これらのＴＲＲＯはそのメッセージが通ってきた下流のサブツリーのトポロジを示す。情報統合されたＴＲＲＯはこれらのＴＲＲＯを線形結合したものである（図１６）。分岐点の情報を結合結果に挿入することで、新しいＴＲＲＯには分岐点を根とするＳｕｂｔｒｅｅのトポロジ情報が書き込まれる。メッセージがＲｅｓｖ ｍｅｓｓａｇｅでかつマルチキャストツリーのｓｅｎｄｅｒに届いたとき、メッセージ中に含まれるＴＲＲＯにはマルチキャストツリー全体の情報が書き込まれる。ツリーの情報を示すために、ＴＲＲＯのＳｕｂｏｂｊｅｃｔはＴＥＲＯのｓｕｂｏｂｊｅｃｔと同様にｄｅｐｔｈ−ｆｉｒｓｔ−ｏｒｄｅｒで並び替えられる。各Ｓｕｂｏｂｊｅｃｔはｓｅｎｄｅｒから当該ノードまでの距離情報を保持する。ＴＲＲＯに書き込まれたツリーのトポロジ情報はＰａｔｈ ｍｅｓｓａｇｅのＲｅｆｒｅｓｈ動作時にツリーを構成する全ノードに配布される。
【０１０６】
図１７にＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔのフォーマットを示す。図１７のＴｙｐｅは、
０×０１ Ｉｐｖ４ ａｄｄｒｅｓｓ
０×０２ Ｉｐｖ６ ａｄｄｒｅｓｓ
である。Ｌｅｎｇｔｈは、サブジェクトの長さ（ｂｙｔｅ表記）である。Ｉｐｖ４／６ ａｄｄｒｅｓｓは、
Ａ ３２／１２８−ｂｉｔ ｕｎｉｃａｓｔ，ｈｏｓｔ，ａｄｄｒｅｓｓ．
である。Ｐｒｅｆｉｘ ｌｅｎｇｔｈは、３２である。Ｆｌａｇｓは、
０×０１ Ｌｏｃａｌ ｐｒｏｔｅｃｔｉｏｎ ａｖａｉｌａｂｌｅ
で、下流ノードがｌｏｃａｌ ｒｅｐａｉｒでないことを示す。また、
０×０２ Ｌｏｃａｌ ｐｒｏｔｅｃｔｉｏｎ ｉｎ ｕｓｅ
で、下流ノードでｌｏｃａｌ ｒｅｐａｉｒできることを示す。Ｄｉｓｔａｎｃｅは、ｓｅｎｄｅｒからサブオブジェクトが示すノードまでの距離であり、Ｌｏｏｓｅ ｅｘｐｌｅｃｉｔ ｒｏｕｔｅの区間の距離は１とする。
【０１０７】
（ソース起動のマルチキャストＬＳＰ設定処理）
ツリールートの決定には２種類の方法が存在し、本プロトコルは２つの方法ともサポートする。１つ目はツリールートの計算はＮＭＳ ｏｒ ソースが行うものであり。２つ目はＬ３のマルチキャストルーティングプロトコルによって計算されるものである。１つ目の方法はＴＥを実現するためには適した方法であるが、ＮＭＳやソースに負荷が集中するという不利点がある。２つ目の方法は既存マルチキャストルーティングプロトコルを利用できるという利点がある。
【０１０８】
簡単のために、１つ目の方法に限定して記述を行う。以下の手順を踏んで、Ｓｅｎｄｅｒ Ｉｎｉｔｉａｔｅｄ型のマルチキャストＬＳＰの設定を行う。
▲１▼ツリーの計算結果に基づきソースがＰａｔｈ Ｍｅｓｓａｇｅを作成し、Ｐａｔｈ Ｍｅｓｓａｇｅを利用してツリーを設定する。ソースは、マルチキャストのＳＥＳＳＩＯＮを識別するためのＳＥＳＳＩＯＮ ＯｂｊｅｃｔやＬＡＢＥＬ＿ＲＥＱＵＥＳＴ、ＴＲＥＥ ＥＸＰＬＩＣＩＴ ＲＯＵＴＥ Ｏｂｊｅｃｔを含んだＲＳＶＰのＰａｔｈ Ｍｅｓｓａｇｅを作成する。その後ソースがＰａｔｈ ＭｅｓｓａｇｅをＬｅａｆに向かって送付する。
▲２▼Ｐａｔｈ ＭｅｓｓａｇｅはＴＥＲＯに記されたノード上を通り、枝ノードではコピーされる。各ノードではＳＥＳＳＩＯＮとそれに対するＳｅｎｄｅｒ Ｔｅｍｐｌａｔｅ、ＦＥＣをそのＭｕｌｔｉｃａｓｔ状態として記録する。
▲３▼ＬｅａｆにＰａｔｈ Ｍｅｓｓａｇｅが届いたらＬＡＢＥＬ Ｏｂｊｅｃｔを含んだＲｅｓｖ Ｍｅｓｓａｇｅをソース側へ送付し、Ｌａｂｅｌをバインドする。
▲４▼最終的にＲｅｓｖ Ｍｅｓｓａｇｅがソースへ到着した時点でツリーの設定が終了し、ソースはトラヒックを流すことが可能となる。
【０１０９】
大規模マルチキャストツリーを構築するためには、ソースへＲｅｓｖ Ｍｅｓｓａｇｅが同時にかつ大量に到着することをさける必要がある。本目的のためにＲｅｓｖ Ｍｅｓｓａｇｅをマージする。図１８にマルチキャストＬＳＰの設定シーケンスを示す。ルータＣ，Ｄ、Ｅにとっての枝ルータであるコアルータＢはＲｅｓｖ Ｍｅｓｓａｇｅをマージする。マージ後Ｒｅｓｖ ｍｅｓｓａｇｅを上流へ送付する。
【０１１０】
Ｐａｔｈ Ｍｅｓｓａｇｅを受信したノードはＳＥＳＳＩＯＮ ｏｂｊｅｃｔとＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥを抜き出し、そのノードが管理している情報と比較し、そのＰａｔｈ Ｍｅｓｓａｇｅが最初のパス設定のためのものなのか、リフレッシュのためのものなのかを調査する。もし受信したＰａｔｈ Ｍｅｓｓａｇｅが最初のパス設定の場合、ＲＳＶＰやＲＳＶＰ−ＴＥで規定されているＰａｔｈ Ｍｅｓｓａｇｅ内の必要な情報と、今回ＦＥＣ ｏｂｊｅｃｔで定義されたＦＥＣ情報を記録する。
【０１１１】
ＴＥＲＯを用いてツリーを作成する場合、ＴＥＲＯを含んだＰａｔｈ Ｍｅｓｓａｇｅを受信したノードはＴＥＲＯで記述されている隣接ルータのアドレスを取り出し、そのアドレスをＰａｔｈ Ｍｅｓｓａｇｅの宛先アドレスとし、Ｐａｔｈ Ｍｅｓｓａｇｅを隣接ルータへ送付する。
【０１１２】
ツリールートの計算を分散的に行うために、途中ノードやリーフノードがルート計算を行うことが必要な場合もある。本発明はこれもサポート可能である。もし途中ノードやリーフノードがマルチキャスト全体のツリー情報を用いずにサブツリー情報だけで、ツリールートを計算しサブツリーを設定すると、同じマルチキャストサブツリーに延ばした枝が交差するかもしれない。従ってツリー上の全ノードが設定しようとしているツリートポロジ全体の情報を持つことが必要となる。全ノードがツリートポロジ全体の情報を持つために、ＴＥＲＯはＲＳＶＰ−ＴＥのＥＲＯと異なり、ＴＥＲＯでＥｘｐｌｉｃｉｔ Ｎｏｄｅを指定するｓｕｂｏｂｊｅｃｔを削除せずに途中ノードはＴＥＲＯをそのまま送らなくてはならない。
【０１１３】
各ノードはＴＥＲＯからツリー情報を記録する。これにより全ノードが設定しようとしているツリーの全トポロジ情報を持つことが出来る。
【０１１４】
Ｐａｔｈ Ｍｅｓｓａｇｅの宛先アドレスはユニキャストアドレス、またはマルチキャストアドレスが設定される。これはツリー計算方法によって決まる。ツリールートの計算はＮＭＳ ｏｒ ソースが行い、ソースがＰａｔｈ ＭｅｓｓａｇｅのＴＥＲＯを用いてツリーを作成する場合は、ユニキャストアドレスを用いる。ソースノードがツリールートの計算を行わず、マルチキャスト配信がＬ３のマルチキャストルーティングプロトコルによって行われる場合にはマルチキャストアドレスを用いる。
【０１１５】
大規模マルチキャストツリーを構築するためには、ソースへＲｅｓｖ Ｍｅｓｓａｇｅが同時にかつ大量に到着することをさける必要がある。本目的のために本発明ではＲｅｓｖ Ｍｅｓｓａｇｅをマージする。複数の下流ノードへＰａｔｈ Ｍｅｓｓａｇｅを送ったノードは、各Ｐａｔｈ Ｍｅｓｓａｇｅに対するＲｅｓｖ ｍｅｓｓａｇｅ返って来た時点でＲｅｓｖ Ｍｅｓｓａｇｅを上流へ送付する。Ｒｅｓｖマージする際、受信したＲｅｓｖ Ｍｅｓｓａｇｅに含まれるＴＲＲＯを使って、新たなＴＲＲＯを作成する。ＴＲＲＯはマルチキャストサブツリーを表現している。そのサブツリーはＴＲＲＯを作成したルートノードを持つ。
【０１１６】
マルチキャストＬＳＰの設定時に様々なエラーが発生するかもしれない。ＲＳＶＰ、ＲＳＶＰ−ＴＥではＰａｔｈＥｒｒ、ＲｅｓｖＥｒｒが定義されている。本発明でもＰａｔｈＥｒｒは帯域確保失敗、ＴＥＲＯが示すＮｅｘｔ Ｈｏｐを知らない、タイマー消滅などの理由により、Ｓｅｔｕｐが失敗したこと、Ｓｔａｔｅが消滅したことをＳｅｎｄｅｒへ知らせるために送付する。
【０１１７】
同様にＲｅｓｖＥｒｒは妥当でないラベルを割り当てられたりした場合、タイマー消滅などの理由により、Ｒｅｓｖが失敗したこと、Ｓｔａｔｅが消滅したことを受信者へ知らせるために送付する。
【０１１８】
図１９にＰａｔｈ Ｍｅｓｓａｇｅのフォーマットを示す。ＦＥＣ ｏｂｊｅｃｔやＴＲＥＥ＿ＥＸＰＬＩＣＩＴ＿ＲＯＵＴＥ ｏｂｊｅｃｔがＰａｔｈ Ｍｅｓｓａｇｅに追加されている。またＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わった。
【０１１９】
図２０にＲｅｓｖ ｍｅｓｓａｇｅのフォーマットを示す。ＴＲＥＥ＿ＲＥＣＯＲＤ＿ＲＯＵＴＥ ｏｂｊｅｃｔがＲｅｓｖ ｍｅｓｓａｇｅに追加されていることに注意されたい。またＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わった。
【０１２０】
図２１にＰａｔｈＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す。ＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わったことに注意されたい。
【０１２１】
図２２にＲｅｓｖＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す。またＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わった。
【０１２２】
（ソース起動のＰｒｕｎｅ処理）
本節ではマルチキャストＬＳＰに部分ツリーを構成するＬＳＰを接木するためのＧｒａｆｔ処理を定義する。本節で規定するＧｒａｆｔ処理はＳｅｎｄｅｒ指定によるマルチキャストツリーの一括追加機能を備えるため、マルチキャストトラヒックの収容替えやリルーティングなどのトラヒックエンジニアリングのアプリケーションに利用可能である。また規定するＧｒａｆｔ処理では部分マルチキャストＬＳＰの接木処理をスケールさせるために、ツリー途中からのマルチキャストＬＳＰ設定処理を可能にする。このため、ツリー途中の任意のノードより部分ツリーの接木処理が実行可能である。Ｇｒａｆｔ処理に当たっては部分ＬＳＰを接木するツリー途中ノードをＧｒａｆｔノードとする。Ｓｅｎｄｅｒが、Ｇｒａｆｔノードに、接木する部分マルチキャストＬＳＰ情報をＧｒａｆｔ メッセージに格納し通知する。Ｇｒａｆｔ処理を高速化するため、メッセージ送出者とＧｒａｆｔノード間のノードは当該メッセージを処理せず、中継するのみである。Ｇｒａｆｔ メッセージを受信した、Ｇｒａｆｔノードはメッセージより、ＴＥＲＯに代表されるＬＳＰ設定情報を抽出し、Ｐａｔｈ／Ｒｅｓｖ ｍｅｓｓａｇｅにより部分マルチキャストＬＳＰのＧｒａｆｔ処理を実行する。このＧｒａｆｔ処理はＳｅｎｄｅｒからだけでなく、ネットワークマネジメントシステム、ポリシーサーバからでも実行できる。
【０１２３】
図２３にｒａｆｔ処理のメッセージシーケンス概要を示す。この例ではＳｅｎｄｅｒ ＡがＧｒａｆｔノードＥにＧｒａｆｔメッセージを送出し、ノードＥ配下に部分マルチキャストツリーを接木している。Ｇｒａｆｔメッセージを受信したＧｒａｆｔノードＥはＧｒａｆｔノードに包含されたＴＥＲＯにより接木する部分ツリー情報を抽出する。抽出した部分ツリーに対してマルチキャストＭＰＬＳパスを設定するため、Ｐａｔｈ ｍｅｓｓａｇｅを送出しツリーを作成する。
【０１２４】
この例ではノードＥ配下のリーフノードＦ、Ｇに部分マルチキャストツリーを構築している。Ｇｒａｆｔノードが部分マルチキャストツリーの設定をＲｅｓｖｍｅｓｓａｇｅにより確認すると、Ｇｒａｆｔ処理による設定ツリー情報をＧｒａｆｔ起動者、この例ではＳｅｎｄｅｒ、に通知する。この通知はＧｒａｆｔノードに到着するＲｅｓｖ ｍｅｓｓａｇｅ内に格納される設定ツリー情報であるＲＲＯをマージして生成された部分ツリー情報を示すＲＲＯに変換し、当該ＲＲＯを含むＧｒａｆｔＮｏｔｉｆｙメッセージ（ＲＲＯ）をＳｅｎｄｅｒに通知することにより実施される。Ｓｅｎｄｅｒへ部分ツリー構築完了を即座に通知するためにＧｒａｆｔＮｏｔｉｆｙメッセージは途中ノードで処理されず、Ｓｅｎｄｅｒへ中継される。
【０１２５】
図２４はＧｒａｆｔ処理の部分マルチキャストツリー生成にエラーが発生した場合のメッセージシーケンスを示す。この場合はＧｒａｆ指示された部分ツリーの全体の設定はできず、ツリーの一部が設定される例を示す。ツリーの設定が不能なリーフからは、ツリー設定が不能となった理由を示すエラーコードを含んだＰａｔｈＥｒｒメッセージがＧｒａｆｔノードに向けて送出される。当該ＰａｔｈＥｒｒメッセージを受けたＧｒａｆｔノードはＥｒｒｏｒ情報をＧｒａｆｔＥｒｒメッセージに格納してＧｒａｆｔ起動者であるＳｅｎｄｅｒに通知する。
【０１２６】
Ｇｒａｆｔ指示されたＧｒａｆｔノードがＧｒａｆｔ処理機能をサポートしていない場合には、Ｇｒａｆｔ処理機能を未サポートであることを示すエラーコードをＧｒａｆｔＥｒｒメッセージに格納し、Ｇｒａｆｔ起動者であるＳｅｎｄｅｒに通知する。ＧｒａｆｔノードがＧｒａｆｔメッセージにより指定されたＴＥＲＯなどのツリー生成パラメータが不正であることを検知すると当該エラーを示すエラーコードをＧｒａｆｔメッセージに格納し、Ｇｒａｆｔ起動者であるＳｅｎｄｅｒに通知する。このような例としては、Ｇｒａｆｔノード配下に既にＴＥＲＯで指定された部分マルチキャストツリーが設定されている場合や、ＴＥＲＯで設定を指示された部分マルチキャストツリーの設定がＧｒａｆｔノード配下に存在せず、原理的に不可能である場合などが含まれる。
【０１２７】
Ｇｒａｆｔ処理を実行するために、１）Ｇｒａｆｔ ｍｅｓｓａｇｅ、２）ＧｒａｆｔＮｏｔｉｆｙ、３）ＧｒａｆｔＥｒｒ ｍｅｓｓａｇｅを追加する。
【０１２８】
Ｇｒａｆｔ メッセージは接木する部分Ｍ−ＬＳＰ情報を含み、Ｇｒａｆｔノードに部分Ｍ−ＬＳＰの設定を実施させるために使用される。Ｇｒａｆｔ メッセージフォーマットは図２５のとおりである。＜ＳＥＳＳＩＯＮ＞オブジェクトによりＧｒａｆｔ対象のマルチキャストセッションを特定し、＜ＴＲＥＥ＿ＥＸＰＬＩＣＩＴ＿ＲＯＵＴＥ＞オブジェクトによりＧｒａｆｔする部分ツリーのトポロジ情報を指定する。
【０１２９】
ＧｒａｆｔＮｏｔｉｆｙ メッセージはＧｒａｆｔノードによって、Ｇｒａｆｔ ｍｅｓｓａｇｅ送出者に部分Ｍ−ＬＳＰの設定結果を通知するために使用される。ＧｒａｆｔＮｏｔｉｆｙメッセージフォーマットは図２６のとおり。＜ＴＲＥＥ＿ＲＥＣＯＲＤ＿ＲＯＵＴＥ＞オブジェクトにより設定された部分ツリー情報を格納する。
【０１３０】
ＧｒａｆｔＥｒｒ メッセージはＧｒａｆｔノードによって、ＰａｔｈＥｒｒ情報が格納され、Ｇｒａｆｔ ｍｅｓｓａｇｅ送出者に部分Ｍ−ＬＳＰの設定エラー情報を通知するために使用される。ＧｒａｆｔＥｒｒメッセージフォーマットは図２７のとおり。＜ＥＲＲＯＲ＿ＳＰＥＣ＞オブジェクトにエラー情報を格納する。図２８、図２９に本Ｇｒａｆｔ処理におけるメッセージフォーマットの変遷を示す。
【０１３１】
（ソース起動のＰｒｕｎｅ処理）
本章ではマルチキャストＬＳＰの部分ツリーを構成するＬＳＰを削除するＰｒｕｎｅ処理を定義する。本章で規定するＰｒｕｎｅ処理はＳｅｎｄｅｒ指定によるマルチキャストツリーの一括削除機能を備えるためマルチキャストトラヒックの収容替えやリルーティングなどのトラヒックエンジニアリングのアプリケーションに利用可能である。規定するＰｒｕｎｅ処理では部分マルチキャストＬＳＰの削除処理をスケールさせるために、ツリー途中からのマルチキャストＬＳＰ削除処理を可能にする。部分ＬＳＰを削除するツリー途中ノードをＰｒｕｎｅノードとし、ＳｅｎｄｅｒがＰｒｕｎｅノードに削除する部分マルチキャストＬＳＰ情報をＰｒｕｎｅ ｍｅｓｓａｇｅに格納し通知する。Ｐｒｕｎｅ処理を高速化するため、メッセージ送出者とＰｒｕｎｅノード間のノードは当該メッセージを処理せず、中継するのみである。Ｐｒｕｎｅ ｍｅｓｓａｇｅを受信したＰｒｕｎｅノードは、メッセージよりＴＥＲＯに代表されるＬＳＰ情報を抽出し、ＰａｔｈＴｅａｒ ｍｅｓｓａｇｅを用いて部分マルチキャストＬＳＰのＰｒｕｎｅ処理を実行する。
【０１３２】
図３０にＰｒｕｎｅ処理のメッセージシーケンス概要を示す。この例ではＳｅｎｄｅｒ ＡがＰｒｕｎｅノードＥにＰｒｕｎｅメッセージを送出し、ノードＥ配下に部分マルチキャストツリーを削除している。Ｐｒｕｎｅメッセージを受信したＰｒｕｎｅノードＥはＰｒｕｎｅノードに包含されたＴＥＲＯにより削除する部分ツリー情報を抽出する。抽出した部分ツリーに対してマルチキャストＭＰＬＳパスを削除するため、ＰａｔｈＴｅａｒメッセージを送出しツリーを削除する。この例ではノードＥ配下のリーフノードＦ、Ｇ、Ｈの部分マルチキャストツリーを削除している。ＰｒｕｎｅノードがＰａｔｈＴｅａｒを送出すると、部分マルチキャストツリーの削除完了をＰｒｕｎｅ起動者であるＳｅｎｄｅｒに通知するためにＰｒｕｎｅＮｏｔｉｆｙメッセージに削除した部分ツリー情報を示すＲＲＯを格納し送信する。Ｓｅｎｄｅｒへ部分ツリー構築完了を即座に通知するためにＰｒｕｎｅＮｏｔｉｆｙメッセージは途中ノードで処理されず、Ｓｅｎｄｅｒへ中継される。
【０１３３】
Ｐｒｕｎｅ指示されたＰｒｕｎｅノードがＰｒｕｎｅ処理機能をサポートしていない場合には、Ｐｒｕｎｅ処理機能を未サポートであることを示すエラーコードをＰｒｕｎｅＥｒｒメッセージに格納し、Ｐｒｕｎｅ起動者であるＳｅｎｄｅｒに通知する。ＰｒｕｎｅノードがＰｒｕｎｅメッセージにより指定されたＴＥＲＯなどのツリー生成パラメータが不正であることを検知すると当該エラーを示すエラーコードをＰｒｕｎｅメッセージに格納し、Ｐｒｕｎｅ起動者であるＳｅｎｄｅｒに通知する。このような例としては、Ｐｒｕｎｅノード配下に既にＰｒｕｎｅで指定された部分マルチキャストツリーが存在していない場合や、ＴＥＲＯで削除を指示された部分マルチキャストツリーの削除がＰｒｕｎｅノード配下に存在せず、原理的に不可能である場合などが含まれる。
【０１３４】
Ｐｒｕｎｅ処理を実行するために、１）Ｐｒｕｎｅ ｍｅｓｓａｇｅ、２）ＰｒｕｎｅＮｏｔｉｆｙ、３）ＰｒｕｎｅＥｒｒ ｍｅｓｓａｇｅを追加する。
【０１３５】
Ｐｒｕｎｅメッセージは削除する部分Ｍ−ＬＳＰ情報を含み、Ｐｒｕｎｅノードに部分Ｍ−ＬＳＰを削除させるために使用される。Ｐｒｕｎｅメッセージフォーマットは図３１のとおりである。＜ＳＥＳＳＩＯＮ＞オブジェクトによりＰｒｕｎｅ対象のマルチキャストセッションを特定し、＜ＴＲＥＥ＿ＥＸＰＬＩＣＩＴ＿ＲＯＵＴＥ＞オブジェクトによりＰｒｕｎｅする部分ツリーのトポロジ情報を指定する。
【０１３６】
ＰｒｕｎｅＮｏｔｉｆｙ メッセージはＰｒｕｎｅノードによって、Ｐｒｕｎｅ ｍｅｓｓａｇｅ送出者に部分Ｍ−ＬＳＰの設定結果を通知するために使用される。ＰｒｕｎｅＮｏｔｉｆｙメッセージフォーマットは図３２のとおり。＜ＴＲＥＥ＿ＲＥＣＯＲＤ＿ＲＯＵＴＥ＞オブジェクトにより設定された部分ツリー情報を格納する。
【０１３７】
ＰｒｕｎｅＥｒｒメッセージはＰｒｕｎｅノードによって、部分マルチキャストＬＳＰの削除エラー情報を通知するために使用される。ＰｒｕｎｅＥｒｒメッセージフォーマットは図３３のとおり。＜ＥＲＲＯＲ＿ＳＰＥＣ＞オブジェクトにエラー情報を格納する。図３４、図３５に本Ｐｒｕｎｅ処理におけるメッセージフォーマットの変遷を示す。
【０１３８】
（リーフ起動のＪｏｉｎ処理）
Ｌｅａｆが、あるマルチキャストグループのデータを受信したい場合Ｊｏｉｎメッセージを送信する。ＪｏｉｎメッセージはＬｅａｆが要求するＱｏＳを満たすパス設定をパス追加動作を行うノードに依頼するために用いられる。Ｊｏｉｎメッセージの送信対象は、２つの場合が存在する。
【０１３９】
１つがグループのｓｅｎｄｅｒへ送る場合である。この場合、Ｊｏｉｎ要求を出したＬｅａｆ（Ｊｏｉｎ Ｌｅａｆ）までの枝は、ｓｅｎｄｅｒまでのパス上に存在する、対象ツリーの情報を持ったノードのうち、最もＬｅａｆに近いノードで分岐する。このノードをＧｒａｆｔノードと呼ぶ（Ｇｒａｆｔの部分参照）。もう１つがＴＥを用いて明示的に追加パスが分岐する点を示す場合である。いずれの場合においても、パスの追加動作は追加パスの分岐点となるノードが行う。分岐点の位置のほかにも分岐点からＪｏｉｎ Ｌｅａｆまでの経路を決定する必要がある。この経路はＪｏｉｎメッセージの経路履歴であるＲｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔが示す経路と同一のものである。またノードはＲｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔを確認することでツリー上のほかのノードとの交差がないか、すなわち追加経路がｌｏｏｐ ｆｒｅｅであるかを検出する。本ドラフトで紹介する方式ではこれらのアルゴリズムを用いて転送経路を決定した後、要求帯域を確保する。
【０１４０】
ここで、パス設定の流れを説明する（図３６，図３７）。まず、グループに参加するＬｅａｆはＳｅｎｄｅｒもしくはＴＥＲＯを用いてｅｘｐｌｉｃｉｔに指定されたＧｒａｆｔノードに対しＪｏｉｎメッセージを送信する。ここで、ＪｏｉｎメッセージがＧｒａｆｔノードに到着するまでの流れについて述べる。
【０１４１】
まず、ＳｅｎｄｅｒがＪｏｉｎメッセージのあて先である場合について説明する。Ｓｅｎｄｅｒへの道筋は外部のプロトコルが決定したもの、もしくはＳｅｎｄｅｒとＪｏｉｎ Ｌｅａｆを結ぶＳｈｏｒｔｅｓｔ Ｐａｔｈである。これらの経路決定ポリシーに従い、ＪｏｉｎメッセージはＳｅｎｄｅｒに向けて送信される。メッセージを受け取った中間ノードは自分のＦＥＣテーブルを参照する。対象のグループに関するエントリが存在しない場合、Ｊｏｉｎメッセージはその内容を変更されることなくＳｅｎｄｅｒに向けて送信される。もしエントリが存在するならば、そのノードがＧｒａｆｔノードとなる。
【０１４２】
次にＪｏｉｎメッセージ中のＴＥＲＯにより明示的に経路、ならびにＧｒａｆｔノードが指定される場合について述べる。明示的にパス経路が指定されるので、Ｊｏｉｎメッセージを受信したノードはＧｒａｆｔノードとして指定されているか判断する。Ｇｒａｆｔノードであることがわかれば、自分のＦＥＣテーブルを検索し、対象のグループに関するエントリの存在を確認する。もし存在しなければ、後述するＪｏｉｎＥｒｒメッセージをＪｏｉｎ Ｌｅａｆに向けて送信し、Ｇｒａｆｔノードにはなれないことを通知する。エントリが存在する場合はそのノードがＧｒａｆｔノードとなる。
【０１４３】
Ｇｒａｆｔノードは設定されたパスの帯域を確保するため、Ｊｏｉｎ Ｌｅａｆとの間でＰａｔｈ／Ｒｅｓｖ ｍｅｓｓａｇｅのやり取りを行う。要求帯域等のＱｏＳパラメータはこのやり取りのさいに使用されるＰａｔｈ／Ｒｅｓｖ ｍｅｓｓａｇｅの中で指定される。
【０１４４】
パス設定が完了するとパスの追加によるツリーのトポロジ変更をＳｅｎｄｅｒに通知する。このとき、ＪｏｉｎＮｏｔｉｆｙメッセージが使用される。このメッセージは途中のノードで、内容を変更されることなくｓｅｎｄｅｒへと送られる。この変更情報を用いてｓｅｎｄｅｒはツリーのトポロジ情報を更新し、Ｐａｔｈ ｒｅｆｒｅｓｈにおいて全ノードに通知する。Ｊｏｉｎ Ｍｅｓｓａｇｅフォーマットは図３８のとおり。
【０１４５】
Ｍｕｌｔｉｃａｓｔ Ｓｅｓｓｉｏｎ ｏｂｊｅｃｔには接続要求を出すマルチキャストフローを指定するためのセッション情報を入れる。これはメッセージを受信した各ノードがセッション管理テーブルの情報と比較するために用いられる。
【０１４６】
Ｔｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ ＯｂｊｅｃｔはＴＥを用いて受信者が転送経路を指定するために用意される。記入される情報は、メッセージを出したＪｏｉｎ ＬｅａｆからＧｒａｆｔ ｎｏｄｅまでの経路である。
【０１４７】
前節で述べたＪｏｉｎ ｐｒｏｃｅｓｓの実行中にエラーが生じることがある。原因としてはメッセージの消失、帯域確保の失敗が挙げられる。これらのエラーは、ＰａｔｈＥｒｒなどのエラーメッセージによってメッセージの作成者に通知される。とくにＰａｔｈＥｒｒメッセージは主だったエラーでは必ず発生し（図３９，図４０）、Ｐａｔｈ ｍｅｓｓａｇｅのｓｅｎｄｅｒにエラーを伝える。これよりパス設定を実行するＧｒａｆｔノードがエラーを検知する。エラーを検知したＧｒａｆｔノードはその原因をＪｏｉｎ Ｌｅａｆに通知する。このときＪｏｉｎＥｒｒメッセージが用いられる。ＪｏｉｎＥｒｒメッセージのフォーマットは図４１のとおり。
【０１４８】
ＪｏｉｎＥｒｒメッセージの役割はエラー通知のみである。そして通知する内容はＰａｔｈＥｒｒ／ＲｅｓｖＥｒｒなどのエラーメッセージが通知した内容と同一である。そして、メッセージは受け取ったＪｏｉｎ Ｌｅａｆにおいてのみ処理される。ＪｏｉｎＥｒｒメッセージには以下に示すオブジェクトが存在する。
【０１４９】
Ｅｒｒｏｒ＿Ｓｐｅｃオブジェクトはエラーの原因やエラーの発生箇所が記録されており、ＪｏｉｎＥｒｒメッセージを作成するきっかけとなったエラーメッセージに記録されているものをコピーする。Ｐｏｌｉｃｙ＿Ｄａｔａはより詳しい情報を提供するために存在する。
【０１５０】
（リーフ起動のＬｅａｖｅ処理）
マルチキャストグループから離脱したいノード（Ｌｅａｖｅ Ｌｅａｆ）はツリーに対しｌｅａｖｅメッセージを送信して、パスの切断を依頼する。このとき切断されるパスの区間はＬｅａｆからツリーをｓｅｎｄｅｒに向けてたどっていくときに最初に遭遇する分岐点（Ｐｒｕｎｅ ｎｏｄｅ）とＬｅａｆを結ぶ区間である。ｌｅａｖｅメッセージはＰｒｕｎｅノードによって受理される。この動作より、ｌｅａｖｅメッセージを受信した分岐点がＰｒｕｎｅノードとなる。メッセージを受け取ったノードがＰｒｕｎｅノードであることを判断するためは自分がツリーにおける分岐点であることを知る必要がある。分岐点となるための条件は下流の枝の数が２以上存在することである。下流の枝の数はＦＥＣテーブルに記載される。よってメッセージを受け取ったノードは自分が持つＦＥＣテーブルから自分がＰｒｕｎｅノードであるのかを知る。メッセージを受信したＰｒｕｎｅノードは枝の切断を行う。枝切断動作はＰａｔｈＴｅａｒメッセージを用いることで実現される。Ｌｅａｖｅ ＬｅａｆはＰａｔｈＴｅａｒメッセージの到着をもって、枝切断の完了を確認し、動作を終了する。送信したｌｅａｖｅメッセージが届かない、もしくはＰａｔｈＴｅａｒメッセージがＬｅａｖｅ Ｌｅａｆに届かない状況は発生するかもしれない。そこで、Ｌｅａｖｅ Ｌｅａｆはｌｅａｖｅ ｍｅｓｓａｇｅ送信時に再送タイマーをセットし、エラーを検知する。
【０１５１】
動作の流れについて述べる。（図４２，図４３）Ｌｅａｖｅ Ｌｅａｆはｌｅａｖｅメッセージをｓｅｎｄｅｒに向けて送信する。このとき、Ｌｅａｖｅ Ｌｅａｆはｌｅａｖｅ ｍｅｓｓａｇｅの再送タイマーを設定する。メッセージはＦＥＣテーブルに記録されているＰｒｅｖｉｏｕｓ ｈｏｐ情報に従って送られる。メッセージを受け取った中間ノードはｌｅａｖｅメッセージに記載されているマルチキャストグループならびにパスの情報を抽出する。そして自身が持つＦＥＣテーブル内の当該グループの下流の枝の数を参照する。枝の数が１つしかない場合、さらに上流にｌｅａｖｅ ｍｅｓｓａｇｅを送信する。２つ以上ある場合、ｌｅａｖｅメッセージを受理する。Ｌｅａｖｅ ＬｅａｆにむけてＰａｔｈＴｅａｒメッセージを送信する。ＰａｔｈＴｅａｒメッセージの到着を確認したＬｅａｖｅ Ｌｅａｆは再送タイマーをストップし、パスの切断が完了する。ＰａｔｈＴｅａｒメッセージ到着前に再送タイマーが満了した場合、再びＬｅａｖｅメッセージをｓｅｎｄｅｒに向けて送信する（図４４）。Ｌｅａｖｅ Ｍｅｓｓａｇｅのフォーマットは図４５のとおり。
【０１５２】
（Ｍｕｌｔｉｐｏｉｎｔ ｔｏ ＭｕｌｔｉｐｏｉｎｔのＬＳＰ設定）
Ｍｕｌｔｉｐｏｉｎｔ ｔｏ Ｍｕｌｔｉｐｏｉｎｔの実現方法について述べる。Ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒックを収容するため、ＭＰＬＳ−Ｒｅｎｄｅｚｖｏｕｓ−Ｐｏｉｎｔ（以下ＭＲＰ）を定義する。ＭＲＰはＰＩＭ−ＳＭのそれと似た役割をする。ＭＲＰは複数のＳｅｎｄｅｒからトラヒックを受信し、配下の共有ツリーへ受信したトラヒックを配布する。ＭＲＰでは複数の入力Ｌａｂｅｌに対して複数の出力Ｌａｂｅｌをバインドする機能、ラベルスワップする機能を保持する。
【０１５３】
本発明はＳｅｎｄｅｒの参加・離脱もダイナミックに行うことを可能とする。図４６にＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒック転送の様子を示す。複数のソースからのパケットをＭＲＰが受信し、ＭＲＰが配下のマルチキャストＬＳＰへ向かって転送を行う。ＭＲＰのラベル転送テーブルには、複数の入力ラベルに対して複数の出力ラベルが割り当てられている。
【０１５４】
以下簡単に説明するためにＭＲＰ配下のツリー管理の責任は、ＮＭＳまたはＭＲＰを想定する。ただし、ＮＭＳ、ＭＲＰに限らず、１つのＳｅｎｄｅｒでもよい。同様にＭＲＰ配下のツリールートの計算、Ｌｅａｆ管理もＮＭＳまたはＭＲＰを想定する。ただし、ＮＭＳ、ＭＲＰに限らず、１つのＳｅｎｄｅｒでも良いし、分散的に行ってもよい。一般的にＳｅｎｄｅｒ−ＭＲＰ間毎、ＭＲＰ−Ｌｅａｆ間では必要な帯域は異なることになるだろう。ＭＲＰ−Ｌｅａｆ間の必要帯域は全Ｓｅｎｄｅｒ−ＭＲＰ間の必要帯域の合計にすることが一般的なアプリケーションでは考えられる。
【０１５５】
本発明ではＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒックを収容するために、Ｓｅｎｄｅｒ−ＭＲＰ間のＬＳＰとＭＲＰ−Ｌｅａｆ間のＬＳＰは異なるＬＳＰとして扱う。別管理を行うため、Ｓｅｎｄｅｒ−ＭＲＰ間とＭＲＰ−Ｌｅａｆ間ではＴｕｎｎｅｌ ＩＤ、ＬＳＰ ＩＤは異なる値を用いる。ＭＲＰがこの異なるＴｕｎｎｅｌ ＩＤ、ＬＳＰ ＩＤの関連づけを行う。これにより Ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストの状態を保持する。ＬＳＰの収容状態を図４７に示す。Ｓｅｎｄｅｒ Ａ−ＭＲＰ間、Ｓｅｎｄｅｒ Ｂ−ＭＲＰ間、ＭＲＰ−Ｌｅａｆ間はすべて異なるＬＳＰとして扱い、Ｐａｔｈ／Ｒｅｓｖ Ｍｅｓｓａｇｅも各々で終端される。
【０１５６】
次にＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのパス設定法を示す。ＡＤＤ Ｍｅｓｓａｇｅを新しいメッセージとして追加する。ＡＤＤ ＭｅｓｓａｇｅはソースからＭＲＰまでのユニキャストのＬＳＰを設定する。以下のプロセスを経て、Ｓｅｎｄｅｒは必要な帯域を確保する。
▲１▼ＳｅｎｄｅｒがＡＤＤ ＭｅｓｓａｇｅをＭＲＰまで送付し、ＡＤＤ ＭｅｓｓａｇｅはソースからＭＲＰまでのＬＳＰを張り、リソースを確保する。
▲２▼ＡＤＤ Ｍｅｓｓａｇｅを受けたＭＲＰは、もし必要ならばＰａｔｈ Ｍｅｓｓａｇｅを作成するかもしれない。Ｐａｔｈ ＭｅｓｓａｇｅをＬｅａｆに向かって送付しなければならない場合は下記のような場合が考えられる。
▲２▼―１）まだｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストツリーが設定されておらず、最初のＳｅｎｄｅｒが追加されたことがＰａｔｈ Ｍｅｓｓａｇｅを出すトリガーになる場合
▲２▼―２）すでにｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストツリーが設定されている時に、新たにＳｅｎｄｅｒが追加されてかつ、リソース追加が必要な場合
▲３▼ＬｅａｆではＭＲＰへＲｅｓｖを返し、ＭＲＰはＲｅｓｖを受信した時点でＳｅｎｄｅｒへＲｅｓｖを返す
▲４▼Ｒｅｓｖを受信したＳｅｎｄｅｒは、それ以降はＰａｔｈ ／Ｒｅｓｖ ＭｅｓｓａｇｅでＳｔａｔｅを更新していく
【０１５７】
図４８は最初のＳｅｎｄｅｒがツリーに参加する概要図で、図４９がその詳細である。特に図４９でＭＲＳがＳｅｓｓｉｏｎ変換テーブルを作成することに注意されたい。Ｓｅｎｄｅｒ Ａ−ＭＲＰ間とＭＲＰ−Ｌｅａｆ間はすべて異なるＬＳＰとして扱うために、これらの異なるＬＳＰの連携を取るために、Ｓｅｓｓｉｏｎ変換テーブルを作成している。図４９を用いて最初のＳｅｎｄｅｒがツリーに参加するプロセスを説明する。下記のプロセスで最初のＳｅｎｄｅｒがツリーに参加する。
▲１▼Ｓｅｎｄｅｒから送付されたＡＤＤ ＭｅｓｓａｇｅはＳｅｎｄｅｒからＭＲＰまでは通常のＰａｔｈ Ｍｅｓｓａｇｅと同じ処理がされる。
▲２▼ＡＤＤ Ｍｅｓｓａｇｅを受信したＭＲＰは、ツリーの帯域予約を行うためにＰａｔｈ Ｍｅｓｓａｇｅを出す。
▲３▼ＭＲＰ はＰａｔｈ Ｍｅｓｓａｇｅ出す前にＳｅｎｄｅｒ−ＭＲＰ間のＬＳＰとＭＲＰ−Ｌｅａｆ間のＬＳＰを関連づけるために、ＳＥＳＳＩＯＮ変換テーブルを作成する。ＳＥＳＳＩＯＮ変換テーブルには、ＳＥＳＳＩＯＮ ＯｂｊｅｃｔやＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥなどの情報をもつ
▲４▼その後ＭＲＰはＰａｔｈ ＭｅｓｓａｇｅをＬｅａｆまで送出し、Ｐａｔｈ ＭｅｓｓａｇｅがＬｅａｆに到着後、ＬｅａｆがＲｅｓｖ Ｍｅｓｓａｇｅを送出する。これによりＭＲＰ−Ｌｅａｆ間のリソースの確保を行う。
【０１５８】
図５０は２つ目のＳｅｎｄｅｒを追加する様子を示す。下記のプロセスで２つ目のＳｅｎｄｅｒがツリーに参加する。
▲１▼追加されるＳｅｎｄｅｒからＡＤＤ Ｍｅｓｓａｇｅを送付する。
▲２▼ＡＤＤ Ｍｅｓｓａｇｅを受信したＭＲＰは、ツリー配下の帯域を増やす必要性について判断する。必要ならばＰａｔｈ Ｍｅｓｓａｇｅを送付する。不要ならばＰａｔｈ Ｍｅｓｓａｇｅを送付せずに、すぐにＲｅｓｖ Ｍｅｓｓａｇｅを返す。
【０１５９】
図５１にパス状態の保持シーケンスを示す。各Ｓｅｎｄｅｒ−ＭＲＰ間とＭＲＰ−Ｌｅａｆ間、Ｓｅｎｄｅｒ Ａ−ＭＲＰ間とＳｅｎｄｅｒ Ａ−ＭＲＰ間は独立にＰａｔｈ／ＲｅｓｖのＳ状態を更新する。もし特定ＳｅｎｄｅｒからＰａｔｈ Ｍｅｓｓａｇｅが来なくなったらば、そのＳｅｎｄｅｒからの帯域は削減するかもしれないことに注意されたい。
【０１６０】
図５２にパス解除シーケンスを示す。トラヒック送信を止めたいＳｅｎｄｅｒはＰａｔｈＴｅａｒ Ｍｅｓｓａｇｅを作成しＭＲＰまで送付する。ＰａｔｈＴｅａｒ Ｍｅｓｓａｇｅを受信したＳｅｎｄｅｒは、解除すべきＳｅｎｄｅｒ−ＭＲＰ間のＬＳＰとＭＲＰ−Ｌｅａｆ間のＬＳＰとの関連付けを止め、予約しているリソースを減らす必要があるかどうか判断を行い、減らす必要があるならばＭＲＰ−Ｌｅａｆ間のＬＳＰの再設定を行う。
【０１６１】
ＡＤＤ Ｍｅｓｓａｇｅのメッセージフォーマットを図５３に示す。ＰａｔｈＭｅｓｓａｇｅと同じフォーマットを持つが、ＭＲＰにＳｅｎｄｅｒが参加することを示すという追加機能を持つ。
【０１６２】
（トラヒックエンジニアリング）
Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇはネットワークの状況に適した経路制御をサポートのため、用いられる。ネットワーク内の情報はＯＳＰＦ−ＴＥのようにＴｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇをサポートしたルーチングプロトコルなどによって収集される。ネットワークの輻輳状況やパスの分布状況などが経路制御の際に使用される有効な情報である。情報の管理方式として２つの方式が考えられる。１つが集中管理型モデルであり、もう１つが分散管理型モデルである。本節ではこれらのモデルについて説明する。
【０１６３】
まず始めに集中管理型モデルについて説明する。トラヒック輻輳などの情報はネットワーク管理のために用意された単一ノードで管理される。例として、Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ（ＮＭＳ）やｓｅｎｄｅｒ ｉｎｉｔｉａｔｅｄ ｔｒｅｅ のｓｅｎｄｅｒなどが上げられる。その他のノードでは通常経路計算は行われない。このモデルでは情報が集中管理されるため、ループなどの検出が容易である。しかし情報が集中することにより、管理ノードの故障は既設、新設のパスの設定管理ができなくなるという重大な問題を引き起こす。このため、通常バックアップ用管理ノードが用意される。また、ネットワークトポロジの変更情報が管理ノードを経由して処理されることで、パストポロジの変更遅延が大きくなる。これらの特徴を考慮すると、集中管理型モデルは静的な、すなわちパストポロジの変更頻度が低いアプリケーションに適用することが望ましい。
【０１６４】
次に分散管理型モデルについて説明する。このモデルではネットワーク管理用のノードはネットワーク中に分散配置される。それぞれのノードはノード周りのネットワークの情報を考慮した経路を計算する。経路計算の局所化により、各ノードで必要となる計算による負荷は比較的軽くなる。このため、大規模な動的マルチキャストツリー、すなわちツリーのトポロジの変更頻度が大きいツリーの構築に適する。パスの設定方針としては２種類存在する。１つはｓｅｎｄｅｒ ｉｎｉｔｉａｔｅｄなツリー設定であり、もう１つはＬｅａｆ ｉｎｉｔｉａｔｅｄなツリー設定である。次節よりそれぞれの設定方針について説明する。
【０１６５】
まず始めにＳｅｎｄｅｒ ｉｎｉｔｉａｔｅｄなパス設定について説明する。通常、ｓｅｎｄｅｒ ｉｎｉｔｉａｔｅｄなツリーの経路は上記で示すようにｓｅｎｄｅｒやＮＭＳで行われる。ここで、複数のドメインを経由するマルチキャストツリーを構築する場合について考える。ｓｅｎｄｅｒは通常自分が属するドメインのトポロジのみを認識している。しかし、ドメイン外の情報はドメインのエッジルータにより隠蔽されている。この場合、ｓｅｎｄｅｒが属するドメイン内の経路をｓｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定し、ドメイン外の経路をｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定する。ドメインのエッジノードが隣接するドメインの経路を計算する。
【０１６６】
ここで、マルチアクセスネットワーク上にパスが設定され、かつ、１つのツリーに対する入り口のエッジルータが２つ以上存在する場合を考える（図５４）。それぞれのエッジルータは独自に経路計算を行う。このため、他方が計算した経路にもう一方が計算した経路が交差することがありうる。これらのノードが経路計算をする時刻はほぼ同じになると考えられるため、互いに通知しあうことは難しくなる。このため、一時的にループが形成される。これらの経路情報はＲｅｓｖ ｍｅｓｓａｇｅのＴＲＲＯメッセージとＰａｔｈ ｍｅｓｓａｇｅのＲｅｆｒｅｓｈ動作を介してツリー上のノードに送られる。この情報を利用してループを解消する。
【０１６７】
次にＬｅａｆ Ｉｎｉｔｉａｔｅｄなツリー設定について説明する。Ｌｅａｆｉｎｉｔｉａｔｅｄなツリーの経路はｓｅｎｄｅｒ以外のノードで行われる。計算するノードとしてはＬｅａｆや中間ノード、そしてＮＭＳが存在する。Ｌｅａｆがグループに参加するときのようにツリーから新規参加ノードへパスを接木する場合、接木されたパスの経路はＴＥＲＯなどで示される。しかし、各ノードがネットワーク全体の情報を持たずに自分が属するネットワークの情報のみを持つ場合、ループの形成を阻止する機能が必要となる。このため、本プロトコルでは局在化しているネットワーク情報を各ノードに配布することで情報を共有する。情報配布にはＰａｔｈ ｍｅｓｓａｇｅのＲｅｆｒｅｓｈ動作が用いられる。これらの特徴より、本プロトコルはＬｅａｆ ｉｎｉｔｉａｔｅｄなパス設定時においても、ループを形成しにくい、データ転送の信頼性が高いパスを提供する。
【０１６８】
【発明の効果】
以上説明したように、本発明のマルチキャストＭＰＬＳプロトコルを用いれば、同一のＭＰＬＳネットワーク上でｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ、ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ混在のＬＳＰを設定できる。このため、コンテンツ配信サービスのようにユニキャストのＶｏＤサービス、マルチキャストの放送サービスが混在する転送網として利用することが可能となる。さらにこの混在環境下でＱｏＳを保証した転送が可能となるので有料コンテンツ配信サービスのネットワークインフラとして利用可能である。また本プロトコルでは、ソース起動、リーフ起動のマルチキャストＬＳＰ設定機能を備えるために、あらゆるマルチキャストアプリケーションに利用可能である。さらに本プロトコルはソース起動のＧｒａｆｔ、Ｐｒｕｎｅ処理、リーフ起動のＪｏｉｎ、Ｌｅａｖｅ処理機能を備えるために設定したマルチキャストツリーの全体の再設定を伴わず、トラヒック変動に応じた木目細かいパスの修正が可能なためスケーラビリティの高いネットワーク運用が可能になる。
【０１６９】
このため本発明方式を用いればスケーラブルなコンテンツ配信が可能となり大規模コンテンツ配信ネットワーク環境が容易に実現できる。
【０１７０】
本実施例のマルチキャストＭＰＬＳ通信方法あるいはシステムは、情報処理装置であるコンピュータ装置を用いて実現することができる。すなわち、コンピュータ装置にインストールすることにより、そのコンピュータ装置に、本実施例のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、コンピュータ装置にインストールすることにより、そのコンピュータ装置を、本実施例のマルチキャストＭＰＬＳ通信システムに相応する装置とするプログラムをコンピュータ装置にインストールすることにより、そのコンピュータ装置に本実施例のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、そのコンピュータ装置を本実施例のマルチキャストＭＰＬＳ通信システムに相応する装置とすることができる。
【０１７１】
本実施例のプログラムは本実施例の記録媒体に記録されることにより、コンピュータ装置は、この記録媒体を用いて本実施例のプログラムをインストールすることができる。あるいは、本実施例のプログラムを保持するサーバからネットワークを介して直接コンピュータ装置に本実施例のプログラムをインストールすることもできる。
【０１７２】
これにより、コンピュータ装置を用いて、スケーラブルなコンテンツ配信が可能となり大規模コンテンツ配信ネットワーク環境を実現することができる。
【図面の簡単な説明】
【図１】本実施例のマルチキャストＬＳＰに収容されるマルチキャストトラックを示す図。
【図２】本実施例のＰｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ ＬＳＰを示す図。
【図３】本実施例のマルチキャストＭＰＬＳプロトコルで実現されるＭ−ＬＳＰ設定機能を示す図。
【図４】本実施例のマルチキャストＭＰＬＳの基本動作メカニズムを示す図。
【図５】本実施例の明示的経路指定情報（ＴＥＲＯ）を用いたマルチキャストＬＳＰ設定を示す図。
【図６】本実施例のマルチキャストＭＰＬＳ−ＬＳＰ設定情報とＬＳＲ保持情報を示す図。
【図７】本実施例の新たに定義するＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４とＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６のフォーマットを示す図。
【図８】本実施例のＦＥＣ Ｏｂｊｅｃｔ全体のフォーマット（ｓｕｂｏｂｊｅｃｔの集合）を示す図。
【図９】本実施例のＳｕｂｏｂｊｅｃｔの共通ヘッダ（ＴｙｐｅとＬｅｎｇｔｈと実際の中身）を示す図。
【図１０】本実施例のＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４を示す図。
【図１１】本実施例のＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４を示す図。
【図１２】本実施例のＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を示す図。
【図１３】本実施例のＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を示す図。
【図１４】本実施例のマルチキャストツリーとそれに対応するＴＥＲＯの表記を示す図。
【図１５】本実施例のＴｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔのフォーマットを示す図。
【図１６】本実施例のＴＲＲＯを線形結合して情報統合されたＴＲＲＯを示す図。
【図１７】本実施例のＴｒｅｅ Ｒｅｃｏｒｄ Ｏｂｊｅｃｔのフォーマットを示す図。
【図１８】本実施例のマルチキャストＬＳＰの設定シーケンスを示す図。
【図１９】本実施例のＰａｔｈ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２０】本実施例のＲｅｓｖ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２１】本実施例のＰａｔｈＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２２】本実施例のＲｅｓｖＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２３】本実施例のＧｒａｆｔ処理メッセージシーケンス概要を示す図。
【図２４】本実施例のＧｒａｆｔ処理でパス確立にエラーが発生した場合のメッセージシーケンス概要を示す図。
【図２５】本実施例のＧｒａｆｔメッセージフォーマットを示す図。
【図２６】本実施例のＧｒａｆｔＮｏｔｉｆｙメッセージフォーマットを示す図。
【図２７】本実施例のＧｒａｆｔＥｒｒメッセージフォーマットを示す図。
【図２８】本実施例のＧｒａｆｔ処理におけるメッセージフォーマット概要（その１）を示す図。
【図２９】本実施例のＧｒａｆｔ処理におけるメッセージフォーマット概要（その２）を示す図。
【図３０】本実施例のＰｒｕｎｅ処理メッセージシーケンス概要を示す図。
【図３１】本実施例のＰｒｕｎｅメッセージフォーマットを示す図。
【図３２】本実施例のＰｒｕｎｅＮｏｔｉｆｙメッセージフォーマットを示す図。
【図３３】本実施例のＰｒｕｎｅＥｒｒメッセージフォーマットを示す図。
【図３４】本実施例のＰｒｕｎｅ処理におけるメッセージフォーマット概要（その１）を示す図。
【図３５】本実施例のＰｒｕｎｅ処理におけるメッセージフォーマット概要（その２）を示す図。
【図３６】本実施例のリーフ起動のＪｏｉｎ処理におけるパス設定の流れを説明する図。
【図３７】本実施例のリーフ起動のＪｏｉｎ処理におけるパス設定の流れを説明する図。
【図３８】本実施例のＪｏｉｎ Ｍｅｓｓａｇｅフォーマットを示す図。
【図３９】本実施例のＪｏｉｎ ｐｒｏｃｅｓｓの実行中にエラーが生じる原因を説明するための図。
【図４０】本実施例のＪｏｉｎ ｐｒｏｃｅｓｓの実行中にエラーが生じる原因を説明するための図。
【図４１】本実施例のＪｏｉｎ Ｅｒｒメッセージのフォーマットを示す図。
【図４２】本実施例のリーフ起動のＬｅａｖｅ処理における動作の流れを説明するための図。
【図４３】本実施例のリーフ起動のＬｅａｖｅ処理における動作の流れを説明するための図。
【図４４】本実施例のＬｅａｖｅメッセージをｓｅｎｄｅｒに向けて送信する状況を示す図。
【図４５】本実施例のＬｅａｖｅメッセージのフォーマットを示す図。
【図４６】本実施例のＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒック転送の様子を示す図。
【図４７】本実施例のＬＳＰの収容状態を示す図。
【図４８】本実施例の最初のＳｅｎｄｅｒがツリーに参加する概要図。
【図４９】本実施例の最初のＳｅｎｄｅｒがツリーに参加する概要図。
【図５０】本実施例の最初のＳｅｎｄｅｒがツリーに参加する詳細図。
【図５１】本実施例のパス状態の保持シーケンスを示す図。
【図５２】本実施例のパス解除シーケンスを示す図。
【図５３】本実施例のＡＤＤ Ｍｅｓｓａｇｅのメッセージフォーマットを示す図。
【図５４】本実施例のマルチアクセスネットワーク上にパスが設定され、かつ、１つのツリーに対する入り口のエッジルータが２つ以上存在する場合を示す図。
【符号の説明】
Ａ〜Ｇ ノード
【発明の属する技術分野】
本発明は、point-to-multipoint、multipoint-to-multipointのＭＰＬＳ(Multi Protocol Label Switching)転送パスを確立するマルチキャストＭＰＬＳ技術に関する。特にマルチキャスト・ユニキャスト混在環境下でＭＰＬＳパスを確立するＭＰＬＳ技術に関する。またマルチキャスト環境下でＱｏＳ保証のマルチキャストＭＰＬＳパスを設定する技術、マルチキャストアプリケーションの視聴状態に応じてマルチキャストＭＰＬＳパスを設定、削除、修正する技術に関する。またマルチキャスト環境下でトラヒックエンジニアリング可能なマルチキャストＭＰＬＳパスを設定する技術に関する。
【０００２】
【従来の技術】
ネットワークの高速化、クライアントＰＣ処理能力の向上に伴いネットワークを用いたコンテンツ配信サービスの実現が注目を集めている。ネットワークを用いたコンテンツ配信サービスとしては、ユーザが自分自身の嗜好にあわせて観たい番組をオンデマンドで視聴するビデオ・オン・デマンド（ＶｏＤ）サービスと、放送サービスのように決められた番組に視聴者がチャネルを合わせることで番組を受信する放送配信サービスが存在する。このような有料コンテンツ配信サービスを同一のネットワークで実現するためには、ユニキャスト、マルチキャスト混在環境下でＱｏＳ保証可能で、トラヒックエンジニアリング可能な転送網が必要になるが、従来のＩＰ転送技術とＩＰ−ＱｏＳ保証技術では対応できない問題点が存在した。
【０００３】
このため、マルチキャストのＭＰＬＳパスを設定可能なマルチキャストＭＰＬＳパス設定技術が注目を集めている。提案されている技術としては、ＩＥＴＦドラフトとして、1)"Extension to RSVP for Multicast LSP Tunnels," draft-cheng-mpls-rsvp-multicast-er-00.txt Oct. 2001、2)"MPLS Multicast Traffic Engineering," Draft-ooms-mpls-multicast-te-00.txt Feb.2001、3)"Using PIM to distribute MPLS Labels for Multicast Routes," draft-fainacci-mpls-multicast-03.txt Nov.2000, 4)"Multicast in BGP/MPLS VPNs," draft-rosen-vpn-mcast-02.txt Jul. 2001などがあげられる。
【０００４】
【発明が解決しようとする課題】
上記１）２）は、それぞれ既存のｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＭＰＬＳ技術であるＲＳＶＰ−ＴＥ、ＣＲ−ＬＤＰをｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔに拡張したもの、３）、４）は既存のＩＰマルチキャストルーティングプロトコルであるＰＩＭにＭＰＬＳパス確立機能を追加したものである。また１）、２）についてはソース起動のマルチキャストＬＳＰ(Label Switching Path)の設定メカニズムは実装されているもののリーフ起動のマルチキャストＬＳＰの設定メカニズムは実装されていない。このためマルチキャストリーフ配下に存在するクライアントの視聴状態に応じてマルチキャストリーフの設定または削除を行うことにより最適なマルチキャスト配信形態を実現する通信形態には適用できない問題点が生じた。また３）、４）についてはリーフ起動のマルチキャストＭＰＬＳパス設定メカニズムは実装しているものの、ソース起動のマルチキャストＬＳＰ設定メカニズムは実装されていないためマルチキャストデータｓｅｎｄｅｒが受信者を指定して、全受信者へのマルチキャスト転送経路が確立されたことを確認した後でデータ送信するような通信形態に適用できない問題点が存在した。
【０００５】
マルチキャスト配信ではこのように、マルチキャストトラヒック配信ソースに連動したマルチキャストＬＳＰの設定メカニズム、マルチキャスト受信者の視聴状態に連動したマルチキャストＬＳＰの設定メカニズムが同一のプロトコル上で互いに矛盾無く相互運用されなくてはいけないが、上記の従来技術では対応できない問題があった。
【０００６】
また上記、１）〜４）のマルチキャストＬＳＰ設定技術はマルチキャストＭＰＬＳパス全体の設定または削除機能を備えるものの、設定されたマルチキャストＬＳＰの部分ツリーの追加、削除、修正する機能は存在しない。このため、一度設定したマルチキャストＬＳＰの部分的な修正を実施しようとすると、パス全体の再設定が生じ、変更の必要の無い部分まで再設定の影響を受けてしまうという問題が生じた。
【０００７】
また有料コンテンツ配信サービスではデータｓｅｎｄｅｒの信頼性をあげるため、ビデオ配信サーバを二重化して、冗長化された配信サーバからマルチキャスト配信するメカニズムが必要になる。このような場合にはｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔの転送経路が必要になるが、従来の技術ではｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰの設定に対応するだけでｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰ設定に対応せず、高信頼のＭＰＬＳパスを設定できない問題が存在した。
【０００８】
さらに上記の提案方式では、設定されたマルチキャストＭＰＬＳに複数のマルチキャストトラヒックを関連付けられないために、例えばＩＰマルチキャストトラヒックの転送の場合にはマルチキャストＬＳＰにｓｅｎｄｅｒが限定されたマルチキャストグループアドレスが一つ（Ｓ，Ｇ）トラヒックのみしか割り当てられなかったため、単一のマルチキャストＬＳＰに複数のｓｅｎｄｅｒを共有した（＊、Ｇ）マルチキャストトラヒック転送、単一のマルチキャストＬＳＰに複数のｓｅｎｄｅｒグループ、複数のマルチキャスト配信アドレス（｛Ｓ｝、｛Ｇ｝）を収容するスケーラブルなマルチキャストトラヒック転送できない問題点が存在した。
【０００９】
本発明はこのような背景をもとに行われたものであり、大規模ＭＰＬＳネットワーク環境で、ソース起動、リーフ起動のマルチキャストパス設定が可能で、両設定メカニズムが相互に矛盾無く相互運用可能なマルチキャストＭＰＬＳパス設定可能な通信システムおよびネットワークを確立することを第一の主要な目的とする。また上記環境下で、ＱｏＳ保証可能なマルチキャスト転送経路を設定可能な通信システムおよびネットワークを確立することを第二の目的とする。さらに、上記環境下で設定したマルチキャストＬＳＰ全体の再設定を伴わず、必要な部分ツリーの追加・削除・修正機能を実現するマルチキャストＭＰＬＳ環境下でトラヒックエンジニアリングが可能な通信システムおよびネットワークを確立することを第三の目的とする。また、上記環境下でｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰだけでなく、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定可能な通信システムおよびネットワークを確立することを第四の目的とする。さらに本発明では、単一のマルチキャストＬＳＰにさまざまなトラヒックを高い自由度で収容可能な通信システムおよびネットワークを確立することを第五の目的とする。
【００１０】
【課題を解決するための手段】
本発明で規定するマルチキャストＭＰＬＳプロトコルはマルチキャスト転送においてＱｏＳ保証、トラヒックエンジニアリング転送を実現するために規定されるものである。本プロトコルを実装したＭＰＬＳノードを用いれば、ユニキャスト、マルチキャスト混在のＭＰＬＳ網を構築することが可能となることを第一の特徴とする。
【００１１】
また、本プロトコルはｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰ、ｍｕｌｔｉ−ｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰ、リングトポロジのＬＳＰ設定機能を有することを第二の特徴とする。
【００１２】
またｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰはＳｅｎｄｅｒ起動のＬＳＰ設定、リーフ起動のＬＳＰ設定により設定・削除・変更することが可能であることを第三の特徴とする。
【００１３】
また、本プロトコルには設定したｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔのＬＳＰのダイナミックなトポロジ変更を可能にするために、Ｓｅｎｄｅｒ起動のＧｒａｆｔ、Ｐｒｕｎｅ処理機能、リーフ起動のＪｏｉｎ、Ｌｅａｖｅ処理機能を備えることを第四の特徴とする。
【００１４】
また、本プロトコルで設定されるＬＳＰにはＩＰマルチキャストパケットのみならず、Ｅｔｈｅｒフレーム、ＳＯＮＥＴ／ＳＤＨフレームなど一般的なパケットフレームを収容することが可能であることを第五の特徴とする。
【００１５】
また、本プロトコルはＲＳＶＰ−ＴＥ、ＲＳＶＰをベースに実現することが可能であることを第六の特徴とする。
【００１６】
従来の技術とは、本発明で規定したプロトコルを実装するだけで、ＰＩＭ−ＳＭなどのＩＰマルチキャストルーティングプロトコルの実装無しで、同一ＭＰＬＳネットワークとしてユニキャスト・マルチキャスト混在の転送をサポートできる点が大きく異なる。また、ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔだけでなく、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定できる点が大きく異なる。さらに、上記ＬＳＰをソース起動、リーフ起動（Ｓｅｎｄｅｒ ＬＳＲ(Label Switching Router)、Ｌｅａｆ ＬＳＲが）で設定、削除、修正できる点、つまり同一のプロトコルで両方の起動メカニズムがインターワークする環境で同時動作する点が大きく異なる。特に、ＬＳＰツリー全体の設定、削除だけでなく、部分ツリーの設定、削除、修正機能のためにＧｒａｆｔ、Ｐｒｕｎｅ、Ｊｏｉｎ、Ｌｅａｖｅ機能を備える点が大きく異なる。また、ＩＰトラヒックだけでなく、Ｅｔｈｅｒフレーム、ＳＯＮＥＴ／ＳＤＨフレームなどを収容し、マルチプロトコルのマルチキャスト転送に対応できる点が大きく異なる。
【００１７】
すなわち、本発明の第一の観点はマルチキャストＭＰＬＳ通信方法であって、本発明の特徴とするところは、ソース起動のマルチキャストＭＰＬＳパス設定機能として、マルチキャストＭＰＬＳのパス設定起動ノードは、マルチキャスト転送経路と当該転送経路上に設定すべきパス情報を、パス設定要求メッセージに格納し、当該パス設定要求メッセージを指定されたマルチキャスト転送経路の次ホップのノードに送出し、当該パス設定要求メッセージを受信したノードは、当該ノード上に要求されたマルチキャスト転送経路が設定可能な場合には、当該パス設定要求メッセージ内のパス設定情報を自ノード内に一時保持し、当該パス設定要求メッセージ内の経路指定情報により次のマルチキャスト転送経路を判定し、それらのマルチキャスト転送経路上に存在する複数の次ホップのノードに当該パス設定要求メッセージをコピーして送出し、宛先となるマルチキャストリーフノードは、自身がリーフノードであることを判定し、当該パス設定要求メッセージが転送された経路にＭＰＬＳ転送経路を設定可能な場合には、当該ＭＰＬＳパスで使用するラベルを割当て、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出し、当該パス設定確認メッセージを受信した上流ノードは、前記一時保持してあるパス設定情報を確認し、下流ノードの転送に使用するラベルを確認することにより当該ノードと下流ノードとの間のラベルバインディングを設定し、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを確認し、全経路からパス設定確認メッセージが到達した場合には、当該ノードと下流ノードとの間のＭＰＬＳ転送経路を確定し、当該ノードと上流ノードとの間で使用するラベルを確定し、パス設定確認メッセージに格納し、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出し、前記パス設定起動ノードは、前記パス設定確認メッセージが下流ノードでマージされて自ノードに到達したときに、指定されたマルチキャスト転送路にマルチキャストＭＰＬＳパスを設定するところにある。
【００１８】
また、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを待っているノードは、最初のパス設定確認メッセージが到達してから、タイマを作動させ、全ての転送経路からパス設定確認メッセージが到達した場合にタイマを停止させ、全ての転送経路からパス設定確認メッセージが到達する前にタイマが示す値が前もって設定された値になったならば、パス設定確認メッセージを上流ノードへ送付することが望ましい。
【００１９】
さらに、マルチキャストパスの一部または全体の設定に失敗した際に、当該失敗に関わるエラーの発生した箇所のノードは、当該エラー原因および当該エラー発生箇所を通知するエラー通知メッセージを作成して送出し、前記パス設定起動ノードは、このエラー通知メッセージを受信してエラーが起こった全箇所の情報を収集し、この収集結果をパス設定起動者に通知することが望ましい。
【００２０】
また、リーフ起動のマルチキャストツリー参加機能として、マルチキャスト転送経路のリーフノードは、あるマルチキャストツリーに参加したい場合に、当該マルチキャストツリーのマルチキャストＭＰＬＳパス情報を参加要求メッセージに格納して送出し、当該参加要求メッセージにより参加要請されたマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該参加要求メッセージの情報からパス参加要請をしているパス設定起動者宛にマルチキャストツリーの枝ＬＳＰを設定することが望ましい。
【００２１】
さらに、マルチキャストツリーの枝ＬＳＰの設定に失敗した際に、当該失敗に関わるエラー発生を検出したノードは、前記参加要請されたマルチキャストＬＳＲに対して当該失敗理由を通知し、この通知により当該失敗理由を通知された前記参加要請されたマルチキャストＬＳＲは、前記参加要求メッセージを送出したリーフノードに当該枝ＬＳＰの設定に失敗したことを通知することが望ましい。
【００２２】
また、リーフ起動のパス設定ノードの指定機能として、マルチキャスト転送経路のリーフノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域などの情報を収集し、収集された情報を分析し、この分析結果から当該リーフノードに向けてトラヒックを送出するためのパスの分岐点を決定し、当該リーフノードに向けて設定されるパスの接続要求メッセージを作成し、決定した前記分岐点に対して送出し、
当該パス設定要求メッセージを受信した当該分岐ノードはリーフノードに対してパスを設定することが望ましい。
【００２３】
また、パス設定要求メッセージが経由したノードは、当該パス設定要求メッセージに自ノードの情報を経路履歴として記録し、当該メッセージの宛先ノードは、当該経路履歴に沿ってパスを設定し、ネットワーク内のノードは、当該経路履歴からパスのループを検知することが望ましい。
【００２４】
これにより、ソース起動およびリーフ起動のマルチキャストパス設定が可能で、両設定メカニズムが相互に矛盾無く相互運用可能とすることができる。
【００２５】
また、ソース起動のパス設定における適切な分岐点の選択機能として、マルチキャスト転送経路のリーフノードから分岐点として最適と判断され、パス設定要求を受信したマルチキャスト転送経路を構成するノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域を含む情報を収集し、収集された情報を分析し、この分析結果から、より分岐点として適したマルチキャスト転送経路を構成するノードを検索し、そのようなノードが発見された場合には、リーフノードから分岐点として判断された前記ノードが、分岐するパスを設定することを要求するメッセージを作成し、前記発見されたノードに向けて送出し、メッセージを受信した前記発見されたノードは、最初にパス設定の要求が出されたノードで行われたのと同様の手段で情報収集を行い、この収集した情報を分析し、この分析された結果から、さらに分岐点として適したノードを検索し、そのようなノードに対しパス設定要求を送出することが望ましい。
【００２６】
これにより、ネットワーク環境に応じて最適なマルチキャスト転送経路を動的に設定することができる。
【００２７】
また、マルチキャスト転送経路のリーフノードは、自身が収容するクライアントの当該データの視聴状態を判定し、この判定が当該マルチキャストエッジＬＳＲに到達するマルチキャストＬＳＰを不要と判定した場合には、当該マルチキャストＭＰＬＳパスの不要部分を削除し、この削除する際に、離脱要求メッセージに離脱対象のマルチキャストＬＳＰ情報を格納して送出し、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該離脱要求メッセージの情報からパス離脱要請をしているリーフノードまでのマルチキャストツリーの枝ＬＳＰを削除することが望ましい。
【００２８】
これにより、不要となるマルチキャストＭＰＬＳパスを速やかに削除し、ネットワークリソースを有効に利用することができる。
【００２９】
また、設定されたマルチキャストＬＳＰに部分ツリーを追加するために、部分ツリーを追加する接木ノードを選択し、前記接木ノードに接木する部分ツリー情報を通知して接木処理を要請し、接木処理を要請された前記接木ノードが部分ツリーを構築し、接木された部分ツリーの接木処理結果を、前記接木処理を要請したノードに通知することが望ましい。
【００３０】
さらに、前記部分ツリーを構築する際に、部分ツリーの構築に失敗したときには、前記接木処理を要請された接木ノードが当該失敗箇所の情報を収集して前記接木処理を要請したノードに通知することが望ましい。
【００３１】
また、設定されたマルチキャストＬＳＰの部分ツリーを剪定するために、部分ツリーを剪定する剪定ノードを選択して当該剪定ノードに剪定処理を要請し、この剪定処理を要請したノードに対して前記剪定ノードにより削除する部分ツリー情報を通知し、前記剪定ノードが部分ツリーを剪定し、この剪定された部分ツリーの剪定処理結果を、前記剪定処理を要請したノードに通知することが望ましい。
【００３２】
これにより、ネットワーク環境に応じてマルチキャストＬＳＰのツリー構造を動的に最適な形に変化させることができる。したがって、設定したマルチキャストＬＳＰ全体の再設定を伴わず、必要な部分ツリーの追加または削除または修正機能を実現することができる。
【００３３】
また、ソースおよびリーフの相互運用機能として、マルチキャストＭＰＬＳパス設定時に同一転送サービスに含まれる複数のＬＳＰを１つの束として扱うためのトラヒックエンジニアリングトンネルを識別するための第一の情報と、同一転送サービスを受けるトラヒックグループを識別するための第二の情報と、トラヒックエンジニアリングトンネル内でＬＳＰを識別するための第三の情報とが、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定することが望ましい。
【００３４】
これにより、複数の転送サービスが混在するネットワーク環境下でもマルチキャストセッション識別子を用いて、ソースおよびリーフの双方から特定の転送サービスに関わるマルチキャストＭＰＬＳパスに関する設定または削除または修正を実行することができる。
【００３５】
また、前記第一および第三の情報がマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定することが望ましい。
【００３６】
また、収容トラヒックの自由度の向上を図るために、前記第二の情報により様々な種別のトラヒックをＬＳＰに対して割り当て、１つのＬＳＰに対して複数のトラヒックを割り当てることが望ましい。
【００３７】
これにより、単一のマルチキャストＬＳＰにさまざまなトラヒックを高い自由度で収容可能である。
【００３８】
また、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ設定機能として、既設のマルチキャストＬＳＰツリーに新たにトラヒックを送出したいソースノードは、新たにトラヒックを流すことを要求しかつ当該ツリーのルートノードまでのＬＳＰ設定を行うことを要求する新規参入メッセージを生成し、当該新規参入メッセージを当該ツリーのルートノードへと送付し、前記ツリーのルートノードは、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰと自ノードからリーフノードまでのＬＳＰを関連付け、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップし、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することが望ましい。
【００３９】
これにより、新たにトラヒック送出したいソースノードが既存のマルチキャストＬＳＰツリーに容易に参入することができ、ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰだけでなく、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定することができる。
【００４０】
また、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ解除機能として、トラヒック送出を止めたいソースノードは、トラヒックを止めることを通知しかつツリーのルートノードまでのＬＳＰを解除することを要請する送出解除メッセージを生成し、当該送出解除メッセージを当該ツリーのルートノードへと送付し、前記ツリーのルートノードは、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでの解除要請のあったＬＳＰと自ノードからリーフノードまでのＬＳＰの関連付けを解除し、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップすることを停止し、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することを停止することが望ましい。
【００４１】
これにより、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰが既に設定されているときに、このＬＳＰに対するトラヒック送出を任意に解除することができる。
【００４２】
また、ツリー構造を持つ転送経路の明示的指定機能として、経路指定を要望するツリーの経路上のノードの情報として当該ツリーのルートノードからサブオブジェクトに対応するノードまでの距離を情報として保持し、この保持された当該サブオブジェクトを深さ優先探索で前記ツリーを走査したときに通る順番で並べ、前記保持された情報から前記ツリーの設定経路をネットワーク中のノードに明示的に指定することが望ましい。
【００４３】
これにより、あらかじめツリー構造を持つ転送経路を明示的に指定することができるため、この転送経路を用いるデータ転送のＱｏＳを保証することができる。
【００４４】
また、メッセージの経路履歴の分岐点での情報結合機能として、着目する一つのメッセージが通過したノードの履歴を記録し、マルチキャストツリーの分岐点でこの着目する一つのメッセージ同士の経路履歴情報を統合し、この統合結果にこの分岐点を特定する情報を組み込むことによりこの分岐点を根とする部分ツリーを表現することが望ましい。
【００４５】
すなわち、着目する一つのメッセージが通過したノードの履歴を記録しておき、マルチキャストツリーの分岐点で当該着目する一つのメッセージ同士の経路履歴情報を統合することによって、この分岐点を根とする部分ツリーを構成するノードの情報を取得することができる。さらに、この情報にこの分岐点を特定する情報として、例えば、この分岐点の識別子あるいはこの分岐点の位置情報を組み込むことにより、この分岐点を根とする部分ツリーを表現することができる。
【００４６】
また、パス設定の失敗を検知したノードは、当該失敗箇所を前記マルチキャストＭＰＬＳパス設定起動ノードに通知するメッセージを作成し、この作成された当該メッセージを前記マルチキャストＭＰＬＳパス設定起動ノードに送出し、前記マルチキャストＭＰＬＳパス設定起動ノードは、通知された前記失敗箇所を使わずにリーフノードまでの経路を再計算し、この再計算された経路を接木するＬＳＲをマルチキャストパスを構成するＬＳＲの中から選択し、接木するパスの経路を前記接木するＬＳＲに対して指示し、前記接木するＬＳＲは、前記指示された経路にしたがってパス設定することが望ましい。
【００４７】
これにより、一度、パス設定に失敗した場合でも速やかに再設定を行うことができ、マルチキャストパスを効率よく構築することができる。
【００４８】
本発明の第二の観点はマルチキャストＭＰＬＳ通信システムであって、本発明の特徴とするところは、マルチキャストＭＰＬＳのパス設定起動ノードは、マルチキャスト転送経路と当該転送経路上に設定すべきパス情報を、パス設定要求メッセージに格納し、当該パス設定要求メッセージを指定されたマルチキャスト転送経路の次ホップのノードに送出する手段を備え、当該パス設定要求メッセージを受信したノードは、当該ノード上に要求されたマルチキャスト転送経路が設定可能な場合には、当該パス設定要求メッセージ内のパス設定情報を自ノード内に一時保持し、当該パス設定要求メッセージ内の経路指定情報により次のマルチキャスト転送経路を判定し、それらのマルチキャスト転送経路上に存在する複数の次ホップのノードに当該パス設定要求メッセージをコピーして送出する手段を備え、宛先となるマルチキャストリーフノードは、自身がリーフノードであることを判定し、当該パス設定要求メッセージが転送された経路にＭＰＬＳ転送経路を設定可能な場合には、当該ＭＰＬＳパスで使用するラベルを割当て、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出する手段を備え、当該パス設定確認メッセージを受信した上流ノードは、前記一時保持してあるパス設定情報を確認し、下流ノードの転送に使用するラベルを確認することにより当該ノードと下流ノードとの間のラベルバインディングを設定する手段と、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを確認し、全経路からパス設定確認メッセージが到達した場合には、当該ノードと下流ノードとの間のＭＰＬＳ転送経路を確定する手段と、当該ノードと上流ノードとの間で使用するラベルを確定し、パス設定確認メッセージに格納し、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出する手段とを備え、前記パス設定起動ノードは、前記パス設定確認メッセージが下流ノードでマージされて自ノードに到達したときに、指定されたマルチキャスト転送路にマルチキャストＭＰＬＳパスを設定する手段を備えたところにある。
【００４９】
また、パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを待っているノードは、最初のパス設定確認メッセージが到達してから、タイマを作動させる手段と、全ての転送経路からパス設定確認メッセージが到達した場合にタイマを停止させる手段と、全ての転送経路からパス設定確認メッセージが到達する前にタイマが示す値が前もって設定された値になったならば、パス設定確認メッセージを上流ノードへ送付する手段とを備えることが望ましい。
【００５０】
さらに、マルチキャストパスの一部または全体の設定に失敗した際に、当該失敗に関わるエラーの発生した箇所のノードは、当該エラー原因および当該エラー発生箇所を通知するエラー通知メッセージを作成して送出する手段を備え、前記パス設定起動ノードは、このエラー通知メッセージを受信してエラーが起こった全箇所の情報を収集する手段と、この収集結果をパス設定起動者に通知する手段とを備えることが望ましい。
【００５１】
また、マルチキャスト転送経路のリーフノードは、あるマルチキャストツリーに参加したい場合に、当該マルチキャストツリーのマルチキャストＭＰＬＳパス情報を参加要求メッセージに格納して送出する手段を備え、当該参加要求メッセージにより参加要請されたマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該参加要求メッセージの情報からパス参加要請をしているパス設定起動者宛にマルチキャストツリーの枝ＬＳＰを設定する手段を備えることが望ましい。
【００５２】
さらに、マルチキャストツリーの枝ＬＳＰの設定に失敗した際に、当該失敗に関わるエラー発生を検出したノードは、前記参加要請されたマルチキャストＬＳＲに対して当該失敗理由を通知する手段を備え、この通知する手段により当該失敗理由を通知された前記参加要請されたマルチキャストＬＳＲは、前記参加要求メッセージを送出したリーフノードに当該枝ＬＳＰの設定に失敗したことを通知する手段を備えることが望ましい。
【００５３】
また、マルチキャスト転送経路のリーフノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域などの情報を収集する手段と、収集された情報を分析する手段と、この分析結果から当該リーフノードに向けてトラヒックを送出するためのパスの分岐点を決定する手段と、当該リーフノードに向けて設定されるパスの接続要求メッセージを作成し、決定した前記分岐点に対して送出する手段と、当該パス設定要求メッセージを受信した当該分岐ノードはリーフノードに対してパスを設定する手段とを備えることが望ましい。
【００５４】
また、パス設定要求メッセージが経由したノードは、当該パス設定要求メッセージに自ノードの情報を経路履歴として記録する手段を備え、当該メッセージの宛先ノードは、当該経路履歴に沿ってパスを設定する手段を備え、ネットワーク内のノードは、当該経路履歴からパスのループを検知する手段を備えることが望ましい。
【００５５】
また、マルチキャスト転送経路のリーフノードから分岐点として最適と判断され、パス設定要求を受信したマルチキャスト転送経路を構成するノードは、ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域を含む情報を収集する手段と、収集された情報を分析する手段と、この分析結果から、より分岐点として適したマルチキャスト転送経路を構成するノードを検索する手段とを備え、そのようなノードが発見された場合には、リーフノードから分岐点として判断された前記ノードが、分岐するパスを設定することを要求するメッセージを作成し、前記発見されたノードに向けて送出する手段を備え、メッセージを受信した前記発見されたノードは、最初にパス設定の要求が出されたノードで行われたのと同様の手段で情報収集を行う手段と、この収集した情報を分析する手段と、この分析された結果から、さらに分岐点として適したノードを検索する手段と、そのようなノードに対しパス設定要求を送出する手段とを備えることが望ましい。
【００５６】
また、マルチキャスト転送経路のリーフノードは、自身が収容するクライアントの当該データの視聴状態を判定する手段と、この判定する手段が当該マルチキャストエッジＬＳＲに到達するマルチキャストＬＳＰを不要と判定した場合には、当該マルチキャストＭＰＬＳパスの不要部分を削除する手段とを備え、この削除する手段は、離脱要求メッセージに離脱対象のマルチキャストＬＳＰ情報を格納して送出する手段を備え、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該離脱要求メッセージの情報からパス離脱要請をしているリーフノードまでのマルチキャストツリーの枝ＬＳＰを削除する手段を備えることが望ましい。
【００５７】
また、設定されたマルチキャストＬＳＰに部分ツリーを追加するために、部分ツリーを追加する接木ノードを選択する手段と、前記接木ノードに接木する部分ツリー情報を通知して接木処理を要請する手段と、接木処理を要請された前記接木ノードが前記マルチキャストＭＰＬＳパスを設定する手段により部分ツリーを構築する手段と、接木された部分ツリーの接木処理結果を、前記接木処理を要請する手段を備えたノードに通知する手段とを備えることが望ましい。
【００５８】
さらに、前記部分ツリーを構築する手段が部分ツリーの構築に失敗したときには、前記接木処理を要請された接木ノードが当該失敗箇所の情報を収集して前記接木処理を要請する手段を備えたノードに通知する手段を備えることが望ましい。
【００５９】
また、設定されたマルチキャストＬＳＰの部分ツリーを剪定するために、部分ツリーを剪定する剪定ノードを選択して当該剪定ノードに剪定処理を要請する手段と、この剪定処理を要請する手段を備えたノードに対して前記剪定ノードにより削除する部分ツリー情報を通知する手段と、前記剪定ノードが前記マルチキャストＭＰＬＳパスを設定する手段により部分ツリーを剪定する手段と、剪定された部分ツリーの剪定処理結果を、前記剪定処理を要請する手段を備えたノードに通知する手段とを備えることが望ましい。
【００６０】
また、マルチキャストＭＰＬＳパス設定時に同一転送サービスに含まれる複数のＬＳＰを１つの束として扱うためのトラヒックエンジニアリングトンネルを識別するための第一の情報と、同一転送サービスを受けるトラヒックグループを識別するための第二の情報と、トラヒックエンジニアリングトンネル内でＬＳＰを識別するための第三の情報とが、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する手段を備えることが望ましい。
【００６１】
また、前記第一および第三の情報がマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する手段を備えることが望ましい。
【００６２】
また、前記第二の情報により様々な種別のトラヒックをＬＳＰに対して割り当てる手段を備え、１つのＬＳＰに対して複数のトラヒックを割り当てる手段を備えることが望ましい。
【００６３】
また、既設のマルチキャストＬＳＰツリーに新たにトラヒックを送出したいソースノードは、新たにトラヒックを流すことを要求しかつ当該ツリーのルートノードまでのＬＳＰ設定を行うことを要求する新規参入メッセージを生成する手段と、当該新規参入メッセージを当該ツリーのルートノードへと送付する手段とを備え、前記ツリーのルートノードは、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰと自ノードからリーフノードまでのＬＳＰを関連付ける手段と、当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップする手段と、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付する手段とを備えることが望ましい。
【００６４】
また、トラヒック送出を止めたいソースノードは、トラヒックを止めることを通知しかつツリーのルートノードまでのＬＳＰを解除することを要請する送出解除メッセージを生成する手段と、当該送出解除メッセージを当該ツリーのルートノードへと送付する手段とを備え、前記ツリーのルートノードは、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでの解除要請のあったＬＳＰと自ノードからリーフノードまでのＬＳＰの関連付けを解除する手段と、当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップすることを停止する手段と、前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することを停止する手段とを備えることが望ましい。
【００６５】
また、経路指定を要望するツリーの経路上のノードの情報として当該ツリーのルートノードからサブオブジェクトに対応するノードまでの距離を情報として保持する手段と、この保持する手段に保持された当該サブオブジェクトを深さ優先探索で前記ツリーを走査したときに通る順番で並べる手段と、前記保持する手段に保持された情報から前記ツリーの設定経路をネットワーク中のノードに明示的に指定する手段とを備えることが望ましい。
【００６６】
また、着目する一つのメッセージが通過したノードの履歴を記録する手段と、マルチキャストツリーの分岐点でこの着目する一つのメッセージ同士の経路履歴情報を統合する手段と、この統合結果にこの分岐点を特定する情報を組み込むことによりこの分岐点を根とする部分ツリーを表現する手段とを備えることが望ましい。
【００６７】
また、パス設定の失敗を検知したノードは、当該失敗箇所を前記マルチキャストＭＰＬＳパス設定起動ノードに通知するメッセージを作成する手段と、この作成する手段により作成された当該メッセージを前記マルチキャストＭＰＬＳパス設定起動ノードに送出する手段とを備え、前記マルチキャストＭＰＬＳパス設定起動ノードは、通知された前記失敗箇所を使わずにリーフノードまでの経路を再計算する手段と、この再計算する手段により再計算された経路を接木するＬＳＲをマルチキャストパスを構成するＬＳＲの中から選択する手段と、接木するパスの経路を前記接木するＬＳＲに対して指示する手段とを備え、前記接木するＬＳＲは、前記指示する手段により指示された経路にしたがってパス設定する手段を備えることが望ましい。
【００６８】
本発明の第三の観点は、本発明のマルチキャストＭＰＬＳ通信システムを備えたことを特徴とするネットワークである。
【００６９】
本発明の第四の観点は、情報処理装置にインストールすることにより、その情報処理装置に、本発明のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、情報処理装置にインストールすることにより、その情報処理装置を、本発明のマルチキャストＭＰＬＳ通信システムに相応する装置として動作させることを特徴とするプログラムである。
【００７０】
本発明の第五の観点は、本発明のプログラムが記録された前記情報処理装置読み取り可能な記録媒体である。本発明のプログラムは本発明の記録媒体に記録されることにより、前記情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記情報処理装置に本発明のプログラムをインストールすることもできる。
【００７１】
これにより、コンピュータ装置等の情報処理装置を用いて、スケーラブルなコンテンツ配信が可能となり大規模コンテンツ配信ネットワーク環境を実現することができる。
【００７２】
【発明の実施の形態】
（サポートするマルチキャストＭＰＬＳ種別）
本発明のマルチキャストＭＰＬＳプロトコルではｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ、ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰの設定・削除・更新メカニズムをサポートする。Ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰはコンテンツ配信サービスのような、センターサーバから各クライアントにスター型のトポロジでマルチキャスト配信する場合に適用される。
【００７３】
また本プロトコルで設定されたｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰにはＩＰトラヒック、ＶＬＡＮなどのＥｔｈｅｒトラヒックなどのマルチプロトコルのトラヒックが収容可能である。例えばＩＰマルチキャストトラヒックの場合には、図１に示すように、本プロトコルで規定されるｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ ＬＳＰには１）単一のｓｅｎｄｅｒから送信される単一マルチキャストアドレス宛の（Ｓ，Ｇ）、２）任意のｓｅｎｄｅｒから送信される単一マルチキャストアドレス宛の（＊、Ｇ）、複数のｓｅｎｄｅｒから送信される単一マルチキャストアドレス宛の（｛Ｓ｝、Ｇ）、３）複数のｓｅｎｄｅｒ、複数のマルチキャストアドレス宛の（｛Ｓ｝、｛Ｇ｝）のマルチキャストトラヒックが収容可能である。
【００７４】
このプロトコルではマルチキャスト転送経路トポロジを共有し、同一の転送制御で転送されるトラヒックが同一のＦＥＣとして扱われる。
【００７５】
本プロトコルを用いればｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰも設定可能である。ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰはセンターサーバを冗長化したマルチキャスト配信や、双方向テレビ電話会議などの配信形態に利用される。この配信形態では、図２に示すようにランデブーポイントまで複数のＳｅｎｄｅｒのｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＬＳＰが接続され、ランデブーポイントからスター型のマルチキャスト配信を行う通信形態である。ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰはＲＰを設定し、ＳｅｎｄｅｒからＲＰノードまではｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＬＳＰを設定する。ＲＰからリーフノードまではＲＰノードを起点とするｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定することで実現される。この場合、ＳｅｎｄｅｒからＲＰノードまでのｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＬＳＰはＲＰで終端されず、ＲＰノード起点のｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストＬＳＰに接続される。つまりＳｅｎｄｅｒからリーフノードまでＭＰＬＳ転送される。
【００７６】
（対応するマルチキャスト配信アプリケーション）
本プロトコルで規定されるマルチキャストＭＰＬＳプロトコルは種々のマルチキャスト通信形態を持つアプリケーションに対応することができる。例えば、マルチキャスト配信サーバと連携したマルチキャストＬＳＰを設定したい場合には、マルチキャストトラヒックのｓｅｎｄｅｒがトラヒック受信者までの全リーフ上にマルチキャストＬＳＰが確立されたことを確認した後で、トラヒック送出を行うことが望ましい。このような場合には、マルチキャストＬＳＰはＳｅｎｄｅｒ起動のパス設定メカニズムで設定されることが望ましい。
【００７７】
またＱｏＳ保証を実現するマルチキャストＬＳＰを設定するためには、単一のノードがネットワークのＱｏＳ情報をもとに最適なマルチキャストＬＳＰを設定することが望ましいのでＳｅｎｄｅｒ起動のパス設定メカニズムが有効である。
【００７８】
また、マルチキャストトラヒックを受信するクライアントの視聴状態に応じて最適なマルチキャストＬＳＰを設定したい場合には、リーフ起動のパス設定メカニズムが必要になる。このような例としては、リーフノードがＩＧＭＰを実装し、クライアントのマルチキャストトラヒックの視聴状態を監視しながら、リーフ起動でマルチキャストＬＳＰを設定する場合が想定される。
【００７９】
また両アプリケーションが混在する環境も想定されるため、Ｓｅｎｄｅｒ起動でも、リーフ起動でも同一のマルチキャストＬＳＰが設定可能となるメカニズムがマルチキャストＭＰＬＳプロトコルに求められる。
【００８０】
（実現されるマルチキャストＬＳＰ設定機能と起動メカニズム）
本プロトコルには、このようなマルチキャストアプリケーションに対応するため、Ｓｅｎｄｅｒ起動のパス設定メカニズム、リーフ起動の両方のパス設定メカニズムが実装されている。
【００８１】
Ｓｅｎｄｅｒ起動のマルチキャストＬＳＰ制御メカニズムには、１）マルチキャストパスツリー設定メカニズム、２）マルチキャスト部分ツリー追加メカニズム、３）マルチキャスト部分ツリー削除メカニズムが実装されている。またリーフ起動のマルチキャストＬＳＰ制御メカニズムには４）マルチキャストパスツリー設定メカニズム、５）リーフ設定メカニズム、６）リーフ削除メカニズムが実装されている。図３に本プロトコルで実現されるマルチキャストＬＳＰの設定機能概要を示す。パスの設定・削除、部分ツリーの追加・削除動作に対してＳｅｎｄｅｒ起動、リーフ起動のＬＳＰ制御は同一のマルチキャストＬＳＰツリー状態
（効果）を設定できるように設計されており、プロトコル上、Ｓｅｎｄｅｒ起動とリーフ起動のマルチキャストＬＳＰ制御が相互にインターワーク可能となるアーキテクチャとなっている。
【００８２】
（プロトコル基本動作概要）
次に、本マルチキャストＭＰＬＳプロトコルで実現されるマルチキャストＬＳＰ設定の基本動作を説明する。本マルチキャストＭＰＬＳプロトコルはＲＳＶＰ−ＴＥプロトコルにマルチキャストＬＳＰ設定機能を機能拡張することにより実現される。図４に、Ｓｅｎｄｅｒを起点としたマルチキャストＬＳＰの設定概要を示す。図４に示すようにマルチキャストＬＳＰを設定するＳｅｎｄｅｒは、Ｐａｔｈ ｍｅｓｓａｇｅに設定するツリー情報をＴＥＲＯ情報として格納する。ＥＴＲＯを用いた明示的なマルチキャストＬＳＰの設定概要は図５に示す。図５ではＮ＃１〜Ｎ＃１３のノードでネットワークが構成されている。このとき、図に示したトポロジでｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのＬＳＰを設定する場合を想定する。この場合、ソースノードによって規定されるＴＥＲＯ情報は図５内に示すとおりで、ソースノードを起点としてＤｅｐｔｈ−ｆｉｒｓｔ−ｏｒｄｅｒで規定される。ノード番号に付与された（）内の数値はソースノードからの距離情報としてホップ数を示す。このようにしてＰａｔｈ ｍｅｓｓａｇｅはこのＴＥＲＯ情報をもとにツリー下流ノードでコピー分岐され、リーフノードまで転送される。図４に示すようにＰａｔｈ ｍｅｓｓａｇｅがリーフノードまで到達すると、リーフノードがマルチキャストＬＳＰを設定可能な場合には、リーフノードと１ホップ上流ノード間の転送に使用されるラベル値を付与しＲｅｓｖ ｍｅｓｓａｇｅをＰａｔｈ ｍｅｓｓａｇｅが到達した逆経路に従って、上流に通知する。その後、パスの設定が可能な場合は上流ノードで順々にラベル値が付与される。上流に通知されるＲｅｓｖ ｍｅｓｓａｇｅはツリー分岐点のノードでマージされ上流に通知される。この動作がＳｅｎｄｅｒまで繰り返されることによりマルチキャストＬＳＰのパス設定が完了する。この動作はユニキャストのＲＳＶＰ−ＴＥで使用されるＤｏｗｎｓｔｒｅａｍ Ｏｎ Ｄｅｍａｎｄモードと同一のアーキテクチャによって動作する。
【００８３】
（Ｍ−ＬＳＲに設定されるマルチキャストＬＳＰ情報）
本プロトコルを用いて、このような動作でマルチキャストＬＳＰを設定した場合に、マルチキャストＬＳＰ上のＬＳＲに設定されるＬＳＰ情報について概観する。図６に設定されるマルチキャストＭＰＬＳのＬＳＰ情報とＬＳＲの保持情報を示す。掲載される図は、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、ＧのＬＳＲで構成されるマルチキャストＬＳＰを示している。本プロトコルでマルチキャストＬＳＰが設定されると、ツリー上のＬＳＲには入出力ポートでラベルスワッピングするためのＭＰＬＳフォワーディングテーブルが構成される。掲載される図のＬＳＲ（Ｂ）では、入力インタフェースＩｆ１からラベル値：３０で入力したＭＰＬＳパケットは、出力インタフェースＩｆ２、Ｉｆ３でラベル値１５、６５にラベルスワップされて転送される。このとき、本プロトコルのマルチキャストＬＳＰ設定メッセージには、ＬＳＰ内に収容されるセッション情報が含まれるため、この情報があわせて各ツリー上のＬＳＲに設定されている。図６の例では、ＩＰマルチキャストトラヒック（Ｓ，Ｇ）がマルチキャストＬＳＰで転送されているので、各ＬＳＲには（Ｓ，Ｇ）情報がＦＥＣ情報として登録されている。
【００８４】
（Ｍｕｌｔｉｃａｓｔ Ｓｅｓｓｉｏｎ）
既存のＲＳＶＰ−ＴＥで定義されているＳＥＳＳＩＯＮ Ｏｂｊｅｃｔはマルチキャスト用途ではないため、本発明では新たにマルチキャスト用のＳＥＳＳＩＯＮ Ｏｂｊｅｃｔを定義する。
【００８５】
提案では、マルチキャストのトンネルを一意に識別するために、新しいＣ−ＴｙｐｅとしてＳＥＳＳＩＯＮ Ｏｂｊｅｃｔ ＭＵＬＴＩＣＡＳＴ＿ ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４、ＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６を追加する。 ＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４とＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６はＴｕｎｎｅｌ Ｓｅｎｄｅｒ ＡｄｄｒｅｓｓとＭｕｌｔｉｃａｓｔ Ｔｕｎｎｅｌ ＩＤをもつ。このようにトンネルを一意に識別するためにＴｕｎｎｅｌ Ｓｅｎｄｅｒ Ａｄｄｒｅｓｓを入れることで、ユニキャストと同様にトンネルは複数のマルチキャストＬＳＰをセットとして扱うことが出来るようになる。
【００８６】
ユニキャストのＲＳＶＰ−ＴＥの定義ではＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４またＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６のｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔに終端点アドレスを入れることになっているが、これをマルチキャストに拡張するために、このｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔにマルチキャストアドレスを入れて、ＳＥＳＳＩＯＮを識別することも考えられる。ただし、この場合はｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔの領域が１アドレス分しか定義しない場合には扱うことが出来るマルチキャストグループが１つに限られてしまうため、複数のマルチキャストＬＳＰをセットとして扱うことができない問題点、そもそもＩＰマルチキャストトラフィックしか転送できなくなる問題点が存在するため、本発明では採用しない。マルチキャストトンネルを一意に識別するためにはＴｕｎｎｅｌ ｅｎｄ ｐｏｉｎｔだけではなく、Ｔｕｎｎｅｌ ｓｅｎｄｅｒ ａｄｄｒｅｓｓでも可能であるので、本発明ではＴｕｎｎｅｌ ｓｅｎｄｅｒ ａｄｄｒｅｓｓを用いる。
【００８７】
図７に、新たに定義するＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４とＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６のフォーマットを示す。
【００８８】
（ＦＥＣ）
本プロコトルでは、ＦＥＣ Ｏｂｊｅｃｔという新しいＯｂｊｅｃｔを定義する。ＦＥＣ Ｏｂｊｅｃｔは本プロトコルで、規定されるマルチキャストＭＰＬＳ転送で同一の転送サービスを受けるトラヒックグループを規定するために用いられる。たとえば、ＩＰのマルチキャスト転送を考慮する場合には、同一の転送ＦＥＣ ＯｂｊｅｃｔはＬＳＰに割り当てられたマルチキャストグループを表す。ＦＥＣ Ｏｂｊｅｃｔにはグループアドレス（Ｇ）や、グループアドレスとソースアドレスのセット（Ｓ、Ｇ）、が入れられる。（＊、Ｇ）のＩＰマルチキャストトラヒックを収容する、場合には前者のＴｙｐｅのＦＥＣ Ｏｂｊｅｃｔを使用し、（Ｓ，Ｇ）、（｛Ｓ｝，｛Ｇ｝）のＩＰマルチキャストトラヒックを収容する場合には後者のＴｙｐｅのＦＥＣ Ｏｂｊｅｃｔを使用する。（｛Ｓ｝，｛Ｇ｝）の場合には複数のソースアドレス、グループアドレスが必要になるため、当該ＴｙｐｅのＦＥＣ ｏｂｊｅｃｔが複数含まれることになる。
【００８９】
また従来のｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔのＲＳＶＰ−ＴＥではｓｅｎｄｅｒのみがＦＥＣ情報をもち、ＦＥＣ情報が途中ノードに伝えられることはなかった。しかしながら、マルチキャストＭＰＬＳ環境下では、先に述べたようにマルチキャストＬＳＰの途中ノードがパス設定・削除・修正起動者となり得るため、途中ノードがＦＥＣ情報を持つことが必要となる。上記の例の一つとしてはＬｅａｆ Ｉｎｉｔｉａｔｅ型のマルチキャストツリー生成・削除・修正があり、この機能をサポートするためには、途中ノードはＦＥＣ情報を持たなければならない。あるマルチキャストグループのＬＳＲである途中ノードはそのマルチキャストグループに対するＬｅａｆからの参加要求パケットを横取りできなければならない。横取りするためにマルチキャストグループの情報を知る必要がある。
【００９０】
ＦＥＣ Ｏｂｊｅｃｔは長さの異なるｓｕｂｏｂｊｅｃｔの集合とする。ｓｕｂｏｂｊｅｃｔとして本バージョンではＩＰｖ４のＳｈａｒｅｄ Ｍｕｌｔｉｃａｓｔ Ｔｒｅｅ、Ｓｏｕｒｃｅ＿Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ ＴｒｅｅとＩＰｖ６のＳｈａｒｅｄ Ｍｕｌｔｉｃａｓｔ Ｔｒｅｅ、Ｓｏｕｒｃｅ＿Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ Ｔｒｅｅを定義する。ＦＥＣ Ｏｂｊｅｃｔに新たなｓｕｂｏｂｊｅｃｔを定義することによって、本プロトコルが、例えばＥｔｈｅｒｎｅｔ（登録商標）のようなトラヒックを扱うことが出来る。しかし、ＩＰ以外のトラヒックについては本バージョンでは定義を行わない。このようにマルチキャストアドレスをＳｅｓｓｉｏｎ Ｏｂｊｅｃｔに含まないことによって、１つのＴｕｎｎｅｌが複数のマルチキャストＬＳＰを扱うことができる。ＦＥＣ Ｏｂｊｅｃｔは長さの異なるｓｕｂｏｂｊｅｃｔの集合なので、１つのＬＳＰに対して複数のマルチキャストグループを持つことができる。ＦＥＣ Ｏｂｊｅｃｔは下記の特徴を持つ。
▲１▼ＦＥＣ ＯｂｊｅｃｔはＥＲＯと似たフォーマットとする。
▲２▼ＦＥＣ Ｏｂｊｅｃｔは長さの異なるｓｕｂｏｂｊｅｃｔの集合からなる。▲３▼ｓｕｂｏｂｊｅｃｔは共通のヘッダを持ちヘッダ内にはｓｕｂｏｂｊｅｃｔの種別を識別するためのＴｙｐｅとｓｕｂｏｂｊｅｃｔのトータルの長さを示すＬｅｎｇｔｈを持つ。
▲４▼Ｔｙｐｅは４つ。 Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４、Ｓｏｕｒｃｅ＿ ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４ 、Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６ 、Ｓｏｕｒｃｅ＿Ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６
【００９１】
ＦＥＣ Ｏｂｊｅｃｔ全体のフォーマット（ｓｕｂｏｂｊｅｃｔの集合）を図８に示す。Ｓｕｂｏｂｊｅｃｔの共通ヘッダ（ＴｙｐｅとＬｅｎｇｔｈと実際の中身）を図９に示す。図９のＴｙｐｅはＳｕｂｏｂｊｅｃｔのタイプであり、
０：Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
１：Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
２：Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
３：Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
である。また、Ｌｅｎｇｔｈは、Ｓｕｂｏｂｊｅｃｔトータルの長さでＢｙｔｅ単位であり、最低４で４の倍数でなければならない。
【００９２】
ＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４を図１０に示す。図１０のＴｙｐｅは、
０×００ Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
である。また、Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ ８．
である。
【００９３】
ＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４を図１１に示す。図１１でＴｙｐｅは、
０×０１ Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４
である。Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ １２．
である。
【００９４】
ＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を図１２に示す。図１２でＴｙｐｅは、
０×０２ Ｓｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
である。Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ ２０．
である。
【００９５】
ＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を図１３に示す。図１３でＴｙｐｅは、
０×０２ Ｓｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ６
である。Ｌｅｎｇｔｈは、
Ｔｈｅ Ｌｅｎｇｔｈ ｉｓ ａｌｗａｙｓ ３６．
である。
【００９６】
（明示的なマルチキャスト転送経路指定とＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔ）
ＲＳＶＰ−ＴＥの使用目的として明示的経路設定がある。ＲＦＣ３２０９では明示経路を表すため、Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔ（ＥＲＯ）を定義している。ＥＲＯは経路上のノードを表すＳｕｂｏｂｊｅｃｔのリストである。マルチキャストの場合、パスはツリー状に形成される。このため、ＥＲＯをツリーが表記できるよう拡張する必要がある。ここで、Ｔｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔ（ＴＥＲＯ）を定義する。
【００９７】
ＴＥＲＯはＰａｔｈ ｍｅｓｓａｇｅのように主にパス設定に関わるメッセージ中に存在する。ＴＥＲＯはそのメッセージが転送されるＳｕｂｔｒｅｅ上の全ノードを示す。特にｓｅｎｄｅｒからＰａｔｈ ｍｅｓｓａｇｅのＴＥＲＯは自身を起点とするマルチキャストツリーのトポロジ情報を含んでいる。これらの情報は通常メッセージの作成者以外は削除することができない。このため、ＴＥＲＯはツリーを構成する全ノードにマルチキャストツリーのトポロジを通知するために使用される。
【００９８】
ＴＥＲＯはマルチキャストツリーの構成ノードを示すＳｕｂｏｂｊｅｃｔからなる。ツリー構造を表現するため、ＴＥＲＯにはツリーの接続状況を示す情報が必要となる。この情報は、各Ｓｕｂｏｂｊｅｃｔをｄｅｐｔｈ−ｆｉｒｓｔ−ｏｒｄｅｒに並べ、かつ各Ｓｕｂｏｂｊｅｃｔにｓｅｎｄｅｒから対応するノードまでの距離を記録することで保持される。
【００９９】
図１４にマルチキャストツリーとそれに対応するＴＥＲＯの表記を示す。図１５にＴｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔのフォーマットを示す。図１５のＬは、サブオブジェクト末端となるｅｘｐｌｉｃｉｔ ｒｏｕｔｅの属性を示す。ｓｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅの末端であれば０。ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅの末端であれば１。図１５のＴｙｐｅは、
０ｘ０１ ＩＰｖ４ ａｄｄｒｅｓｓ
０ｘ０２ ＩＰｖ６ ａｄｄｒｅｓｓ
である。Ｌｅｎｇｔｈは、サブオブジェクトの長さ（ｂｙｔｅ表記）である。ＩＰｖ４／６ ａｄｄｒｅｓｓは、サブオブジェクトが示すノードのＩＰｖ４／６アドレスである。ノードが複数のＩＰアドレスを持つ場合、ツリーの入り口インタフェースのＩＰアドレスを記録する。Ｐｒｅｆｉｘ ｌｅｎｇｔｈは、ＩＰｖ４／６ ｐｒｅｆｉｘの長さである。Ｄｉｓｔａｎｃｅは、ｓｅｎｄｅｒからサブオブジェクトが示すノードまでの距離であり、Ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅの区間の距離は１とする。
【０１００】
（明示的なマルチキャスト転送経路の Ｓｔｒｉｃｔ と Ｌｏｏｓｅ指定）明示経路の種類として２つの経路が存在する。Ｓｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅはパスの経路を明示的に設定する方式である。Ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅはパスの両端だけを明示的に指定し、途中経路をメッセージの作成者が決めずに他の経路設定アルゴリズムやノードに計算させる方式である。外部アルゴリズムの例としてはＯＳＰＦ−ＴＥやＩＳ−ＩＳ−ＴＥなどがあげられる。これらの経路指定はリンクごとに指定が可能である。そして、一つのマルチキャストパス中にＳｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅとＬｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅが混在する状況も存在する。
【０１０１】
このため、ＴＥＲＯにはこれらの経路指定法の使用箇所を示す情報が必要となる。この条件を満たす情報としては、Ｓｕｂｏｂｊｅｃｔが示すノードの入力リンクが属するパスの経路指定法に関する情報があげられる。すなわち、ノードの入力リンクがＳｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されたパスの一部であるならば、そのＳｕｂｏｂｊｅｃｔは当該ノードがＳｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅであるという情報を持つ。
【０１０２】
ここで、ｓｅｎｄｅｒ−ノード間の距離についてマルチキャストツリーの一部がＬｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されている場合を想定して考える。この場合、Ｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されている区間の正確な距離は、通常測定不能である。このため、ｓｅｎｄｅｒ−ノード間の距離を求めるのは困難になる。そこで、本プロトコルではＬｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定されたパスの両端部分のノード間は距離が１であると定義する。この条件を用いることで、前節で挙げたＴＥＲＯの記述法を使用してマルチキャストツリーを表現することが可能となる。
【０１０３】
（マルチキャスト転送経路情報の記録とＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔ）
ＲＳＶＰ−ＴＥで使用されるメッセージは通過した経路を情報として保持する。メッセージを受け取ったノードはこの情報をパスのループ検出や経路の確認に使用する。Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔはこの通過経路情報を保持するＯｂｊｅｃｔである。ＲＲＯは通過ノードを示すＳｕｂｏｂｊｅｃｔのリストである。これらのＳｕｂｏｂｊｅｃｔは通った経路順に整列される。このため、メッセージがパスの両端に到着するとき、ＲＲＯはパスの全トポロジを示す。
【０１０４】
マルチキャスト通信の場合、複数のメッセージを情報統合し、１つのメッセージにまとめることがある。この場合、ＲＲＯはそれらのメッセージが通ってきたすべてのノードを示す。このため、ＲＲＯをツリー構造が表せるように拡張する必要がある。ここでこの拡張されたＲＲＯをＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔ（ＴＲＲＯ）と呼ぶ。
【０１０５】
メッセージが分岐ノードで情報統合されるとき、各メッセージのＴＲＲＯも同時に統合される。これらのＴＲＲＯはそのメッセージが通ってきた下流のサブツリーのトポロジを示す。情報統合されたＴＲＲＯはこれらのＴＲＲＯを線形結合したものである（図１６）。分岐点の情報を結合結果に挿入することで、新しいＴＲＲＯには分岐点を根とするＳｕｂｔｒｅｅのトポロジ情報が書き込まれる。メッセージがＲｅｓｖ ｍｅｓｓａｇｅでかつマルチキャストツリーのｓｅｎｄｅｒに届いたとき、メッセージ中に含まれるＴＲＲＯにはマルチキャストツリー全体の情報が書き込まれる。ツリーの情報を示すために、ＴＲＲＯのＳｕｂｏｂｊｅｃｔはＴＥＲＯのｓｕｂｏｂｊｅｃｔと同様にｄｅｐｔｈ−ｆｉｒｓｔ−ｏｒｄｅｒで並び替えられる。各Ｓｕｂｏｂｊｅｃｔはｓｅｎｄｅｒから当該ノードまでの距離情報を保持する。ＴＲＲＯに書き込まれたツリーのトポロジ情報はＰａｔｈ ｍｅｓｓａｇｅのＲｅｆｒｅｓｈ動作時にツリーを構成する全ノードに配布される。
【０１０６】
図１７にＴｒｅｅ Ｒｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔのフォーマットを示す。図１７のＴｙｐｅは、
０×０１ Ｉｐｖ４ ａｄｄｒｅｓｓ
０×０２ Ｉｐｖ６ ａｄｄｒｅｓｓ
である。Ｌｅｎｇｔｈは、サブジェクトの長さ（ｂｙｔｅ表記）である。Ｉｐｖ４／６ ａｄｄｒｅｓｓは、
Ａ ３２／１２８−ｂｉｔ ｕｎｉｃａｓｔ，ｈｏｓｔ，ａｄｄｒｅｓｓ．
である。Ｐｒｅｆｉｘ ｌｅｎｇｔｈは、３２である。Ｆｌａｇｓは、
０×０１ Ｌｏｃａｌ ｐｒｏｔｅｃｔｉｏｎ ａｖａｉｌａｂｌｅ
で、下流ノードがｌｏｃａｌ ｒｅｐａｉｒでないことを示す。また、
０×０２ Ｌｏｃａｌ ｐｒｏｔｅｃｔｉｏｎ ｉｎ ｕｓｅ
で、下流ノードでｌｏｃａｌ ｒｅｐａｉｒできることを示す。Ｄｉｓｔａｎｃｅは、ｓｅｎｄｅｒからサブオブジェクトが示すノードまでの距離であり、Ｌｏｏｓｅ ｅｘｐｌｅｃｉｔ ｒｏｕｔｅの区間の距離は１とする。
【０１０７】
（ソース起動のマルチキャストＬＳＰ設定処理）
ツリールートの決定には２種類の方法が存在し、本プロトコルは２つの方法ともサポートする。１つ目はツリールートの計算はＮＭＳ ｏｒ ソースが行うものであり。２つ目はＬ３のマルチキャストルーティングプロトコルによって計算されるものである。１つ目の方法はＴＥを実現するためには適した方法であるが、ＮＭＳやソースに負荷が集中するという不利点がある。２つ目の方法は既存マルチキャストルーティングプロトコルを利用できるという利点がある。
【０１０８】
簡単のために、１つ目の方法に限定して記述を行う。以下の手順を踏んで、Ｓｅｎｄｅｒ Ｉｎｉｔｉａｔｅｄ型のマルチキャストＬＳＰの設定を行う。
▲１▼ツリーの計算結果に基づきソースがＰａｔｈ Ｍｅｓｓａｇｅを作成し、Ｐａｔｈ Ｍｅｓｓａｇｅを利用してツリーを設定する。ソースは、マルチキャストのＳＥＳＳＩＯＮを識別するためのＳＥＳＳＩＯＮ ＯｂｊｅｃｔやＬＡＢＥＬ＿ＲＥＱＵＥＳＴ、ＴＲＥＥ ＥＸＰＬＩＣＩＴ ＲＯＵＴＥ Ｏｂｊｅｃｔを含んだＲＳＶＰのＰａｔｈ Ｍｅｓｓａｇｅを作成する。その後ソースがＰａｔｈ ＭｅｓｓａｇｅをＬｅａｆに向かって送付する。
▲２▼Ｐａｔｈ ＭｅｓｓａｇｅはＴＥＲＯに記されたノード上を通り、枝ノードではコピーされる。各ノードではＳＥＳＳＩＯＮとそれに対するＳｅｎｄｅｒ Ｔｅｍｐｌａｔｅ、ＦＥＣをそのＭｕｌｔｉｃａｓｔ状態として記録する。
▲３▼ＬｅａｆにＰａｔｈ Ｍｅｓｓａｇｅが届いたらＬＡＢＥＬ Ｏｂｊｅｃｔを含んだＲｅｓｖ Ｍｅｓｓａｇｅをソース側へ送付し、Ｌａｂｅｌをバインドする。
▲４▼最終的にＲｅｓｖ Ｍｅｓｓａｇｅがソースへ到着した時点でツリーの設定が終了し、ソースはトラヒックを流すことが可能となる。
【０１０９】
大規模マルチキャストツリーを構築するためには、ソースへＲｅｓｖ Ｍｅｓｓａｇｅが同時にかつ大量に到着することをさける必要がある。本目的のためにＲｅｓｖ Ｍｅｓｓａｇｅをマージする。図１８にマルチキャストＬＳＰの設定シーケンスを示す。ルータＣ，Ｄ、Ｅにとっての枝ルータであるコアルータＢはＲｅｓｖ Ｍｅｓｓａｇｅをマージする。マージ後Ｒｅｓｖ ｍｅｓｓａｇｅを上流へ送付する。
【０１１０】
Ｐａｔｈ Ｍｅｓｓａｇｅを受信したノードはＳＥＳＳＩＯＮ ｏｂｊｅｃｔとＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥを抜き出し、そのノードが管理している情報と比較し、そのＰａｔｈ Ｍｅｓｓａｇｅが最初のパス設定のためのものなのか、リフレッシュのためのものなのかを調査する。もし受信したＰａｔｈ Ｍｅｓｓａｇｅが最初のパス設定の場合、ＲＳＶＰやＲＳＶＰ−ＴＥで規定されているＰａｔｈ Ｍｅｓｓａｇｅ内の必要な情報と、今回ＦＥＣ ｏｂｊｅｃｔで定義されたＦＥＣ情報を記録する。
【０１１１】
ＴＥＲＯを用いてツリーを作成する場合、ＴＥＲＯを含んだＰａｔｈ Ｍｅｓｓａｇｅを受信したノードはＴＥＲＯで記述されている隣接ルータのアドレスを取り出し、そのアドレスをＰａｔｈ Ｍｅｓｓａｇｅの宛先アドレスとし、Ｐａｔｈ Ｍｅｓｓａｇｅを隣接ルータへ送付する。
【０１１２】
ツリールートの計算を分散的に行うために、途中ノードやリーフノードがルート計算を行うことが必要な場合もある。本発明はこれもサポート可能である。もし途中ノードやリーフノードがマルチキャスト全体のツリー情報を用いずにサブツリー情報だけで、ツリールートを計算しサブツリーを設定すると、同じマルチキャストサブツリーに延ばした枝が交差するかもしれない。従ってツリー上の全ノードが設定しようとしているツリートポロジ全体の情報を持つことが必要となる。全ノードがツリートポロジ全体の情報を持つために、ＴＥＲＯはＲＳＶＰ−ＴＥのＥＲＯと異なり、ＴＥＲＯでＥｘｐｌｉｃｉｔ Ｎｏｄｅを指定するｓｕｂｏｂｊｅｃｔを削除せずに途中ノードはＴＥＲＯをそのまま送らなくてはならない。
【０１１３】
各ノードはＴＥＲＯからツリー情報を記録する。これにより全ノードが設定しようとしているツリーの全トポロジ情報を持つことが出来る。
【０１１４】
Ｐａｔｈ Ｍｅｓｓａｇｅの宛先アドレスはユニキャストアドレス、またはマルチキャストアドレスが設定される。これはツリー計算方法によって決まる。ツリールートの計算はＮＭＳ ｏｒ ソースが行い、ソースがＰａｔｈ ＭｅｓｓａｇｅのＴＥＲＯを用いてツリーを作成する場合は、ユニキャストアドレスを用いる。ソースノードがツリールートの計算を行わず、マルチキャスト配信がＬ３のマルチキャストルーティングプロトコルによって行われる場合にはマルチキャストアドレスを用いる。
【０１１５】
大規模マルチキャストツリーを構築するためには、ソースへＲｅｓｖ Ｍｅｓｓａｇｅが同時にかつ大量に到着することをさける必要がある。本目的のために本発明ではＲｅｓｖ Ｍｅｓｓａｇｅをマージする。複数の下流ノードへＰａｔｈ Ｍｅｓｓａｇｅを送ったノードは、各Ｐａｔｈ Ｍｅｓｓａｇｅに対するＲｅｓｖ ｍｅｓｓａｇｅ返って来た時点でＲｅｓｖ Ｍｅｓｓａｇｅを上流へ送付する。Ｒｅｓｖマージする際、受信したＲｅｓｖ Ｍｅｓｓａｇｅに含まれるＴＲＲＯを使って、新たなＴＲＲＯを作成する。ＴＲＲＯはマルチキャストサブツリーを表現している。そのサブツリーはＴＲＲＯを作成したルートノードを持つ。
【０１１６】
マルチキャストＬＳＰの設定時に様々なエラーが発生するかもしれない。ＲＳＶＰ、ＲＳＶＰ−ＴＥではＰａｔｈＥｒｒ、ＲｅｓｖＥｒｒが定義されている。本発明でもＰａｔｈＥｒｒは帯域確保失敗、ＴＥＲＯが示すＮｅｘｔ Ｈｏｐを知らない、タイマー消滅などの理由により、Ｓｅｔｕｐが失敗したこと、Ｓｔａｔｅが消滅したことをＳｅｎｄｅｒへ知らせるために送付する。
【０１１７】
同様にＲｅｓｖＥｒｒは妥当でないラベルを割り当てられたりした場合、タイマー消滅などの理由により、Ｒｅｓｖが失敗したこと、Ｓｔａｔｅが消滅したことを受信者へ知らせるために送付する。
【０１１８】
図１９にＰａｔｈ Ｍｅｓｓａｇｅのフォーマットを示す。ＦＥＣ ｏｂｊｅｃｔやＴＲＥＥ＿ＥＸＰＬＩＣＩＴ＿ＲＯＵＴＥ ｏｂｊｅｃｔがＰａｔｈ Ｍｅｓｓａｇｅに追加されている。またＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わった。
【０１１９】
図２０にＲｅｓｖ ｍｅｓｓａｇｅのフォーマットを示す。ＴＲＥＥ＿ＲＥＣＯＲＤ＿ＲＯＵＴＥ ｏｂｊｅｃｔがＲｅｓｖ ｍｅｓｓａｇｅに追加されていることに注意されたい。またＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わった。
【０１２０】
図２１にＰａｔｈＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す。ＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わったことに注意されたい。
【０１２１】
図２２にＲｅｓｖＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す。またＳＥＳＳＩＯＮ ｏｂｊｅｃｔに新しいＣ−Ｔｙｐｅも加わった。
【０１２２】
（ソース起動のＰｒｕｎｅ処理）
本節ではマルチキャストＬＳＰに部分ツリーを構成するＬＳＰを接木するためのＧｒａｆｔ処理を定義する。本節で規定するＧｒａｆｔ処理はＳｅｎｄｅｒ指定によるマルチキャストツリーの一括追加機能を備えるため、マルチキャストトラヒックの収容替えやリルーティングなどのトラヒックエンジニアリングのアプリケーションに利用可能である。また規定するＧｒａｆｔ処理では部分マルチキャストＬＳＰの接木処理をスケールさせるために、ツリー途中からのマルチキャストＬＳＰ設定処理を可能にする。このため、ツリー途中の任意のノードより部分ツリーの接木処理が実行可能である。Ｇｒａｆｔ処理に当たっては部分ＬＳＰを接木するツリー途中ノードをＧｒａｆｔノードとする。Ｓｅｎｄｅｒが、Ｇｒａｆｔノードに、接木する部分マルチキャストＬＳＰ情報をＧｒａｆｔ メッセージに格納し通知する。Ｇｒａｆｔ処理を高速化するため、メッセージ送出者とＧｒａｆｔノード間のノードは当該メッセージを処理せず、中継するのみである。Ｇｒａｆｔ メッセージを受信した、Ｇｒａｆｔノードはメッセージより、ＴＥＲＯに代表されるＬＳＰ設定情報を抽出し、Ｐａｔｈ／Ｒｅｓｖ ｍｅｓｓａｇｅにより部分マルチキャストＬＳＰのＧｒａｆｔ処理を実行する。このＧｒａｆｔ処理はＳｅｎｄｅｒからだけでなく、ネットワークマネジメントシステム、ポリシーサーバからでも実行できる。
【０１２３】
図２３にｒａｆｔ処理のメッセージシーケンス概要を示す。この例ではＳｅｎｄｅｒ ＡがＧｒａｆｔノードＥにＧｒａｆｔメッセージを送出し、ノードＥ配下に部分マルチキャストツリーを接木している。Ｇｒａｆｔメッセージを受信したＧｒａｆｔノードＥはＧｒａｆｔノードに包含されたＴＥＲＯにより接木する部分ツリー情報を抽出する。抽出した部分ツリーに対してマルチキャストＭＰＬＳパスを設定するため、Ｐａｔｈ ｍｅｓｓａｇｅを送出しツリーを作成する。
【０１２４】
この例ではノードＥ配下のリーフノードＦ、Ｇに部分マルチキャストツリーを構築している。Ｇｒａｆｔノードが部分マルチキャストツリーの設定をＲｅｓｖｍｅｓｓａｇｅにより確認すると、Ｇｒａｆｔ処理による設定ツリー情報をＧｒａｆｔ起動者、この例ではＳｅｎｄｅｒ、に通知する。この通知はＧｒａｆｔノードに到着するＲｅｓｖ ｍｅｓｓａｇｅ内に格納される設定ツリー情報であるＲＲＯをマージして生成された部分ツリー情報を示すＲＲＯに変換し、当該ＲＲＯを含むＧｒａｆｔＮｏｔｉｆｙメッセージ（ＲＲＯ）をＳｅｎｄｅｒに通知することにより実施される。Ｓｅｎｄｅｒへ部分ツリー構築完了を即座に通知するためにＧｒａｆｔＮｏｔｉｆｙメッセージは途中ノードで処理されず、Ｓｅｎｄｅｒへ中継される。
【０１２５】
図２４はＧｒａｆｔ処理の部分マルチキャストツリー生成にエラーが発生した場合のメッセージシーケンスを示す。この場合はＧｒａｆ指示された部分ツリーの全体の設定はできず、ツリーの一部が設定される例を示す。ツリーの設定が不能なリーフからは、ツリー設定が不能となった理由を示すエラーコードを含んだＰａｔｈＥｒｒメッセージがＧｒａｆｔノードに向けて送出される。当該ＰａｔｈＥｒｒメッセージを受けたＧｒａｆｔノードはＥｒｒｏｒ情報をＧｒａｆｔＥｒｒメッセージに格納してＧｒａｆｔ起動者であるＳｅｎｄｅｒに通知する。
【０１２６】
Ｇｒａｆｔ指示されたＧｒａｆｔノードがＧｒａｆｔ処理機能をサポートしていない場合には、Ｇｒａｆｔ処理機能を未サポートであることを示すエラーコードをＧｒａｆｔＥｒｒメッセージに格納し、Ｇｒａｆｔ起動者であるＳｅｎｄｅｒに通知する。ＧｒａｆｔノードがＧｒａｆｔメッセージにより指定されたＴＥＲＯなどのツリー生成パラメータが不正であることを検知すると当該エラーを示すエラーコードをＧｒａｆｔメッセージに格納し、Ｇｒａｆｔ起動者であるＳｅｎｄｅｒに通知する。このような例としては、Ｇｒａｆｔノード配下に既にＴＥＲＯで指定された部分マルチキャストツリーが設定されている場合や、ＴＥＲＯで設定を指示された部分マルチキャストツリーの設定がＧｒａｆｔノード配下に存在せず、原理的に不可能である場合などが含まれる。
【０１２７】
Ｇｒａｆｔ処理を実行するために、１）Ｇｒａｆｔ ｍｅｓｓａｇｅ、２）ＧｒａｆｔＮｏｔｉｆｙ、３）ＧｒａｆｔＥｒｒ ｍｅｓｓａｇｅを追加する。
【０１２８】
Ｇｒａｆｔ メッセージは接木する部分Ｍ−ＬＳＰ情報を含み、Ｇｒａｆｔノードに部分Ｍ−ＬＳＰの設定を実施させるために使用される。Ｇｒａｆｔ メッセージフォーマットは図２５のとおりである。＜ＳＥＳＳＩＯＮ＞オブジェクトによりＧｒａｆｔ対象のマルチキャストセッションを特定し、＜ＴＲＥＥ＿ＥＸＰＬＩＣＩＴ＿ＲＯＵＴＥ＞オブジェクトによりＧｒａｆｔする部分ツリーのトポロジ情報を指定する。
【０１２９】
ＧｒａｆｔＮｏｔｉｆｙ メッセージはＧｒａｆｔノードによって、Ｇｒａｆｔ ｍｅｓｓａｇｅ送出者に部分Ｍ−ＬＳＰの設定結果を通知するために使用される。ＧｒａｆｔＮｏｔｉｆｙメッセージフォーマットは図２６のとおり。＜ＴＲＥＥ＿ＲＥＣＯＲＤ＿ＲＯＵＴＥ＞オブジェクトにより設定された部分ツリー情報を格納する。
【０１３０】
ＧｒａｆｔＥｒｒ メッセージはＧｒａｆｔノードによって、ＰａｔｈＥｒｒ情報が格納され、Ｇｒａｆｔ ｍｅｓｓａｇｅ送出者に部分Ｍ−ＬＳＰの設定エラー情報を通知するために使用される。ＧｒａｆｔＥｒｒメッセージフォーマットは図２７のとおり。＜ＥＲＲＯＲ＿ＳＰＥＣ＞オブジェクトにエラー情報を格納する。図２８、図２９に本Ｇｒａｆｔ処理におけるメッセージフォーマットの変遷を示す。
【０１３１】
（ソース起動のＰｒｕｎｅ処理）
本章ではマルチキャストＬＳＰの部分ツリーを構成するＬＳＰを削除するＰｒｕｎｅ処理を定義する。本章で規定するＰｒｕｎｅ処理はＳｅｎｄｅｒ指定によるマルチキャストツリーの一括削除機能を備えるためマルチキャストトラヒックの収容替えやリルーティングなどのトラヒックエンジニアリングのアプリケーションに利用可能である。規定するＰｒｕｎｅ処理では部分マルチキャストＬＳＰの削除処理をスケールさせるために、ツリー途中からのマルチキャストＬＳＰ削除処理を可能にする。部分ＬＳＰを削除するツリー途中ノードをＰｒｕｎｅノードとし、ＳｅｎｄｅｒがＰｒｕｎｅノードに削除する部分マルチキャストＬＳＰ情報をＰｒｕｎｅ ｍｅｓｓａｇｅに格納し通知する。Ｐｒｕｎｅ処理を高速化するため、メッセージ送出者とＰｒｕｎｅノード間のノードは当該メッセージを処理せず、中継するのみである。Ｐｒｕｎｅ ｍｅｓｓａｇｅを受信したＰｒｕｎｅノードは、メッセージよりＴＥＲＯに代表されるＬＳＰ情報を抽出し、ＰａｔｈＴｅａｒ ｍｅｓｓａｇｅを用いて部分マルチキャストＬＳＰのＰｒｕｎｅ処理を実行する。
【０１３２】
図３０にＰｒｕｎｅ処理のメッセージシーケンス概要を示す。この例ではＳｅｎｄｅｒ ＡがＰｒｕｎｅノードＥにＰｒｕｎｅメッセージを送出し、ノードＥ配下に部分マルチキャストツリーを削除している。Ｐｒｕｎｅメッセージを受信したＰｒｕｎｅノードＥはＰｒｕｎｅノードに包含されたＴＥＲＯにより削除する部分ツリー情報を抽出する。抽出した部分ツリーに対してマルチキャストＭＰＬＳパスを削除するため、ＰａｔｈＴｅａｒメッセージを送出しツリーを削除する。この例ではノードＥ配下のリーフノードＦ、Ｇ、Ｈの部分マルチキャストツリーを削除している。ＰｒｕｎｅノードがＰａｔｈＴｅａｒを送出すると、部分マルチキャストツリーの削除完了をＰｒｕｎｅ起動者であるＳｅｎｄｅｒに通知するためにＰｒｕｎｅＮｏｔｉｆｙメッセージに削除した部分ツリー情報を示すＲＲＯを格納し送信する。Ｓｅｎｄｅｒへ部分ツリー構築完了を即座に通知するためにＰｒｕｎｅＮｏｔｉｆｙメッセージは途中ノードで処理されず、Ｓｅｎｄｅｒへ中継される。
【０１３３】
Ｐｒｕｎｅ指示されたＰｒｕｎｅノードがＰｒｕｎｅ処理機能をサポートしていない場合には、Ｐｒｕｎｅ処理機能を未サポートであることを示すエラーコードをＰｒｕｎｅＥｒｒメッセージに格納し、Ｐｒｕｎｅ起動者であるＳｅｎｄｅｒに通知する。ＰｒｕｎｅノードがＰｒｕｎｅメッセージにより指定されたＴＥＲＯなどのツリー生成パラメータが不正であることを検知すると当該エラーを示すエラーコードをＰｒｕｎｅメッセージに格納し、Ｐｒｕｎｅ起動者であるＳｅｎｄｅｒに通知する。このような例としては、Ｐｒｕｎｅノード配下に既にＰｒｕｎｅで指定された部分マルチキャストツリーが存在していない場合や、ＴＥＲＯで削除を指示された部分マルチキャストツリーの削除がＰｒｕｎｅノード配下に存在せず、原理的に不可能である場合などが含まれる。
【０１３４】
Ｐｒｕｎｅ処理を実行するために、１）Ｐｒｕｎｅ ｍｅｓｓａｇｅ、２）ＰｒｕｎｅＮｏｔｉｆｙ、３）ＰｒｕｎｅＥｒｒ ｍｅｓｓａｇｅを追加する。
【０１３５】
Ｐｒｕｎｅメッセージは削除する部分Ｍ−ＬＳＰ情報を含み、Ｐｒｕｎｅノードに部分Ｍ−ＬＳＰを削除させるために使用される。Ｐｒｕｎｅメッセージフォーマットは図３１のとおりである。＜ＳＥＳＳＩＯＮ＞オブジェクトによりＰｒｕｎｅ対象のマルチキャストセッションを特定し、＜ＴＲＥＥ＿ＥＸＰＬＩＣＩＴ＿ＲＯＵＴＥ＞オブジェクトによりＰｒｕｎｅする部分ツリーのトポロジ情報を指定する。
【０１３６】
ＰｒｕｎｅＮｏｔｉｆｙ メッセージはＰｒｕｎｅノードによって、Ｐｒｕｎｅ ｍｅｓｓａｇｅ送出者に部分Ｍ−ＬＳＰの設定結果を通知するために使用される。ＰｒｕｎｅＮｏｔｉｆｙメッセージフォーマットは図３２のとおり。＜ＴＲＥＥ＿ＲＥＣＯＲＤ＿ＲＯＵＴＥ＞オブジェクトにより設定された部分ツリー情報を格納する。
【０１３７】
ＰｒｕｎｅＥｒｒメッセージはＰｒｕｎｅノードによって、部分マルチキャストＬＳＰの削除エラー情報を通知するために使用される。ＰｒｕｎｅＥｒｒメッセージフォーマットは図３３のとおり。＜ＥＲＲＯＲ＿ＳＰＥＣ＞オブジェクトにエラー情報を格納する。図３４、図３５に本Ｐｒｕｎｅ処理におけるメッセージフォーマットの変遷を示す。
【０１３８】
（リーフ起動のＪｏｉｎ処理）
Ｌｅａｆが、あるマルチキャストグループのデータを受信したい場合Ｊｏｉｎメッセージを送信する。ＪｏｉｎメッセージはＬｅａｆが要求するＱｏＳを満たすパス設定をパス追加動作を行うノードに依頼するために用いられる。Ｊｏｉｎメッセージの送信対象は、２つの場合が存在する。
【０１３９】
１つがグループのｓｅｎｄｅｒへ送る場合である。この場合、Ｊｏｉｎ要求を出したＬｅａｆ（Ｊｏｉｎ Ｌｅａｆ）までの枝は、ｓｅｎｄｅｒまでのパス上に存在する、対象ツリーの情報を持ったノードのうち、最もＬｅａｆに近いノードで分岐する。このノードをＧｒａｆｔノードと呼ぶ（Ｇｒａｆｔの部分参照）。もう１つがＴＥを用いて明示的に追加パスが分岐する点を示す場合である。いずれの場合においても、パスの追加動作は追加パスの分岐点となるノードが行う。分岐点の位置のほかにも分岐点からＪｏｉｎ Ｌｅａｆまでの経路を決定する必要がある。この経路はＪｏｉｎメッセージの経路履歴であるＲｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔが示す経路と同一のものである。またノードはＲｅｃｏｒｄ Ｒｏｕｔｅ Ｏｂｊｅｃｔを確認することでツリー上のほかのノードとの交差がないか、すなわち追加経路がｌｏｏｐ ｆｒｅｅであるかを検出する。本ドラフトで紹介する方式ではこれらのアルゴリズムを用いて転送経路を決定した後、要求帯域を確保する。
【０１４０】
ここで、パス設定の流れを説明する（図３６，図３７）。まず、グループに参加するＬｅａｆはＳｅｎｄｅｒもしくはＴＥＲＯを用いてｅｘｐｌｉｃｉｔに指定されたＧｒａｆｔノードに対しＪｏｉｎメッセージを送信する。ここで、ＪｏｉｎメッセージがＧｒａｆｔノードに到着するまでの流れについて述べる。
【０１４１】
まず、ＳｅｎｄｅｒがＪｏｉｎメッセージのあて先である場合について説明する。Ｓｅｎｄｅｒへの道筋は外部のプロトコルが決定したもの、もしくはＳｅｎｄｅｒとＪｏｉｎ Ｌｅａｆを結ぶＳｈｏｒｔｅｓｔ Ｐａｔｈである。これらの経路決定ポリシーに従い、ＪｏｉｎメッセージはＳｅｎｄｅｒに向けて送信される。メッセージを受け取った中間ノードは自分のＦＥＣテーブルを参照する。対象のグループに関するエントリが存在しない場合、Ｊｏｉｎメッセージはその内容を変更されることなくＳｅｎｄｅｒに向けて送信される。もしエントリが存在するならば、そのノードがＧｒａｆｔノードとなる。
【０１４２】
次にＪｏｉｎメッセージ中のＴＥＲＯにより明示的に経路、ならびにＧｒａｆｔノードが指定される場合について述べる。明示的にパス経路が指定されるので、Ｊｏｉｎメッセージを受信したノードはＧｒａｆｔノードとして指定されているか判断する。Ｇｒａｆｔノードであることがわかれば、自分のＦＥＣテーブルを検索し、対象のグループに関するエントリの存在を確認する。もし存在しなければ、後述するＪｏｉｎＥｒｒメッセージをＪｏｉｎ Ｌｅａｆに向けて送信し、Ｇｒａｆｔノードにはなれないことを通知する。エントリが存在する場合はそのノードがＧｒａｆｔノードとなる。
【０１４３】
Ｇｒａｆｔノードは設定されたパスの帯域を確保するため、Ｊｏｉｎ Ｌｅａｆとの間でＰａｔｈ／Ｒｅｓｖ ｍｅｓｓａｇｅのやり取りを行う。要求帯域等のＱｏＳパラメータはこのやり取りのさいに使用されるＰａｔｈ／Ｒｅｓｖ ｍｅｓｓａｇｅの中で指定される。
【０１４４】
パス設定が完了するとパスの追加によるツリーのトポロジ変更をＳｅｎｄｅｒに通知する。このとき、ＪｏｉｎＮｏｔｉｆｙメッセージが使用される。このメッセージは途中のノードで、内容を変更されることなくｓｅｎｄｅｒへと送られる。この変更情報を用いてｓｅｎｄｅｒはツリーのトポロジ情報を更新し、Ｐａｔｈ ｒｅｆｒｅｓｈにおいて全ノードに通知する。Ｊｏｉｎ Ｍｅｓｓａｇｅフォーマットは図３８のとおり。
【０１４５】
Ｍｕｌｔｉｃａｓｔ Ｓｅｓｓｉｏｎ ｏｂｊｅｃｔには接続要求を出すマルチキャストフローを指定するためのセッション情報を入れる。これはメッセージを受信した各ノードがセッション管理テーブルの情報と比較するために用いられる。
【０１４６】
Ｔｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ ＯｂｊｅｃｔはＴＥを用いて受信者が転送経路を指定するために用意される。記入される情報は、メッセージを出したＪｏｉｎ ＬｅａｆからＧｒａｆｔ ｎｏｄｅまでの経路である。
【０１４７】
前節で述べたＪｏｉｎ ｐｒｏｃｅｓｓの実行中にエラーが生じることがある。原因としてはメッセージの消失、帯域確保の失敗が挙げられる。これらのエラーは、ＰａｔｈＥｒｒなどのエラーメッセージによってメッセージの作成者に通知される。とくにＰａｔｈＥｒｒメッセージは主だったエラーでは必ず発生し（図３９，図４０）、Ｐａｔｈ ｍｅｓｓａｇｅのｓｅｎｄｅｒにエラーを伝える。これよりパス設定を実行するＧｒａｆｔノードがエラーを検知する。エラーを検知したＧｒａｆｔノードはその原因をＪｏｉｎ Ｌｅａｆに通知する。このときＪｏｉｎＥｒｒメッセージが用いられる。ＪｏｉｎＥｒｒメッセージのフォーマットは図４１のとおり。
【０１４８】
ＪｏｉｎＥｒｒメッセージの役割はエラー通知のみである。そして通知する内容はＰａｔｈＥｒｒ／ＲｅｓｖＥｒｒなどのエラーメッセージが通知した内容と同一である。そして、メッセージは受け取ったＪｏｉｎ Ｌｅａｆにおいてのみ処理される。ＪｏｉｎＥｒｒメッセージには以下に示すオブジェクトが存在する。
【０１４９】
Ｅｒｒｏｒ＿Ｓｐｅｃオブジェクトはエラーの原因やエラーの発生箇所が記録されており、ＪｏｉｎＥｒｒメッセージを作成するきっかけとなったエラーメッセージに記録されているものをコピーする。Ｐｏｌｉｃｙ＿Ｄａｔａはより詳しい情報を提供するために存在する。
【０１５０】
（リーフ起動のＬｅａｖｅ処理）
マルチキャストグループから離脱したいノード（Ｌｅａｖｅ Ｌｅａｆ）はツリーに対しｌｅａｖｅメッセージを送信して、パスの切断を依頼する。このとき切断されるパスの区間はＬｅａｆからツリーをｓｅｎｄｅｒに向けてたどっていくときに最初に遭遇する分岐点（Ｐｒｕｎｅ ｎｏｄｅ）とＬｅａｆを結ぶ区間である。ｌｅａｖｅメッセージはＰｒｕｎｅノードによって受理される。この動作より、ｌｅａｖｅメッセージを受信した分岐点がＰｒｕｎｅノードとなる。メッセージを受け取ったノードがＰｒｕｎｅノードであることを判断するためは自分がツリーにおける分岐点であることを知る必要がある。分岐点となるための条件は下流の枝の数が２以上存在することである。下流の枝の数はＦＥＣテーブルに記載される。よってメッセージを受け取ったノードは自分が持つＦＥＣテーブルから自分がＰｒｕｎｅノードであるのかを知る。メッセージを受信したＰｒｕｎｅノードは枝の切断を行う。枝切断動作はＰａｔｈＴｅａｒメッセージを用いることで実現される。Ｌｅａｖｅ ＬｅａｆはＰａｔｈＴｅａｒメッセージの到着をもって、枝切断の完了を確認し、動作を終了する。送信したｌｅａｖｅメッセージが届かない、もしくはＰａｔｈＴｅａｒメッセージがＬｅａｖｅ Ｌｅａｆに届かない状況は発生するかもしれない。そこで、Ｌｅａｖｅ Ｌｅａｆはｌｅａｖｅ ｍｅｓｓａｇｅ送信時に再送タイマーをセットし、エラーを検知する。
【０１５１】
動作の流れについて述べる。（図４２，図４３）Ｌｅａｖｅ Ｌｅａｆはｌｅａｖｅメッセージをｓｅｎｄｅｒに向けて送信する。このとき、Ｌｅａｖｅ Ｌｅａｆはｌｅａｖｅ ｍｅｓｓａｇｅの再送タイマーを設定する。メッセージはＦＥＣテーブルに記録されているＰｒｅｖｉｏｕｓ ｈｏｐ情報に従って送られる。メッセージを受け取った中間ノードはｌｅａｖｅメッセージに記載されているマルチキャストグループならびにパスの情報を抽出する。そして自身が持つＦＥＣテーブル内の当該グループの下流の枝の数を参照する。枝の数が１つしかない場合、さらに上流にｌｅａｖｅ ｍｅｓｓａｇｅを送信する。２つ以上ある場合、ｌｅａｖｅメッセージを受理する。Ｌｅａｖｅ ＬｅａｆにむけてＰａｔｈＴｅａｒメッセージを送信する。ＰａｔｈＴｅａｒメッセージの到着を確認したＬｅａｖｅ Ｌｅａｆは再送タイマーをストップし、パスの切断が完了する。ＰａｔｈＴｅａｒメッセージ到着前に再送タイマーが満了した場合、再びＬｅａｖｅメッセージをｓｅｎｄｅｒに向けて送信する（図４４）。Ｌｅａｖｅ Ｍｅｓｓａｇｅのフォーマットは図４５のとおり。
【０１５２】
（Ｍｕｌｔｉｐｏｉｎｔ ｔｏ ＭｕｌｔｉｐｏｉｎｔのＬＳＰ設定）
Ｍｕｌｔｉｐｏｉｎｔ ｔｏ Ｍｕｌｔｉｐｏｉｎｔの実現方法について述べる。Ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒックを収容するため、ＭＰＬＳ−Ｒｅｎｄｅｚｖｏｕｓ−Ｐｏｉｎｔ（以下ＭＲＰ）を定義する。ＭＲＰはＰＩＭ−ＳＭのそれと似た役割をする。ＭＲＰは複数のＳｅｎｄｅｒからトラヒックを受信し、配下の共有ツリーへ受信したトラヒックを配布する。ＭＲＰでは複数の入力Ｌａｂｅｌに対して複数の出力Ｌａｂｅｌをバインドする機能、ラベルスワップする機能を保持する。
【０１５３】
本発明はＳｅｎｄｅｒの参加・離脱もダイナミックに行うことを可能とする。図４６にＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒック転送の様子を示す。複数のソースからのパケットをＭＲＰが受信し、ＭＲＰが配下のマルチキャストＬＳＰへ向かって転送を行う。ＭＲＰのラベル転送テーブルには、複数の入力ラベルに対して複数の出力ラベルが割り当てられている。
【０１５４】
以下簡単に説明するためにＭＲＰ配下のツリー管理の責任は、ＮＭＳまたはＭＲＰを想定する。ただし、ＮＭＳ、ＭＲＰに限らず、１つのＳｅｎｄｅｒでもよい。同様にＭＲＰ配下のツリールートの計算、Ｌｅａｆ管理もＮＭＳまたはＭＲＰを想定する。ただし、ＮＭＳ、ＭＲＰに限らず、１つのＳｅｎｄｅｒでも良いし、分散的に行ってもよい。一般的にＳｅｎｄｅｒ−ＭＲＰ間毎、ＭＲＰ−Ｌｅａｆ間では必要な帯域は異なることになるだろう。ＭＲＰ−Ｌｅａｆ間の必要帯域は全Ｓｅｎｄｅｒ−ＭＲＰ間の必要帯域の合計にすることが一般的なアプリケーションでは考えられる。
【０１５５】
本発明ではＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒックを収容するために、Ｓｅｎｄｅｒ−ＭＲＰ間のＬＳＰとＭＲＰ−Ｌｅａｆ間のＬＳＰは異なるＬＳＰとして扱う。別管理を行うため、Ｓｅｎｄｅｒ−ＭＲＰ間とＭＲＰ−Ｌｅａｆ間ではＴｕｎｎｅｌ ＩＤ、ＬＳＰ ＩＤは異なる値を用いる。ＭＲＰがこの異なるＴｕｎｎｅｌ ＩＤ、ＬＳＰ ＩＤの関連づけを行う。これにより Ｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストの状態を保持する。ＬＳＰの収容状態を図４７に示す。Ｓｅｎｄｅｒ Ａ−ＭＲＰ間、Ｓｅｎｄｅｒ Ｂ−ＭＲＰ間、ＭＲＰ−Ｌｅａｆ間はすべて異なるＬＳＰとして扱い、Ｐａｔｈ／Ｒｅｓｖ Ｍｅｓｓａｇｅも各々で終端される。
【０１５６】
次にＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのパス設定法を示す。ＡＤＤ Ｍｅｓｓａｇｅを新しいメッセージとして追加する。ＡＤＤ ＭｅｓｓａｇｅはソースからＭＲＰまでのユニキャストのＬＳＰを設定する。以下のプロセスを経て、Ｓｅｎｄｅｒは必要な帯域を確保する。
▲１▼ＳｅｎｄｅｒがＡＤＤ ＭｅｓｓａｇｅをＭＲＰまで送付し、ＡＤＤ ＭｅｓｓａｇｅはソースからＭＲＰまでのＬＳＰを張り、リソースを確保する。
▲２▼ＡＤＤ Ｍｅｓｓａｇｅを受けたＭＲＰは、もし必要ならばＰａｔｈ Ｍｅｓｓａｇｅを作成するかもしれない。Ｐａｔｈ ＭｅｓｓａｇｅをＬｅａｆに向かって送付しなければならない場合は下記のような場合が考えられる。
▲２▼―１）まだｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストツリーが設定されておらず、最初のＳｅｎｄｅｒが追加されたことがＰａｔｈ Ｍｅｓｓａｇｅを出すトリガーになる場合
▲２▼―２）すでにｍｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのマルチキャストツリーが設定されている時に、新たにＳｅｎｄｅｒが追加されてかつ、リソース追加が必要な場合
▲３▼ＬｅａｆではＭＲＰへＲｅｓｖを返し、ＭＲＰはＲｅｓｖを受信した時点でＳｅｎｄｅｒへＲｅｓｖを返す
▲４▼Ｒｅｓｖを受信したＳｅｎｄｅｒは、それ以降はＰａｔｈ ／Ｒｅｓｖ ＭｅｓｓａｇｅでＳｔａｔｅを更新していく
【０１５７】
図４８は最初のＳｅｎｄｅｒがツリーに参加する概要図で、図４９がその詳細である。特に図４９でＭＲＳがＳｅｓｓｉｏｎ変換テーブルを作成することに注意されたい。Ｓｅｎｄｅｒ Ａ−ＭＲＰ間とＭＲＰ−Ｌｅａｆ間はすべて異なるＬＳＰとして扱うために、これらの異なるＬＳＰの連携を取るために、Ｓｅｓｓｉｏｎ変換テーブルを作成している。図４９を用いて最初のＳｅｎｄｅｒがツリーに参加するプロセスを説明する。下記のプロセスで最初のＳｅｎｄｅｒがツリーに参加する。
▲１▼Ｓｅｎｄｅｒから送付されたＡＤＤ ＭｅｓｓａｇｅはＳｅｎｄｅｒからＭＲＰまでは通常のＰａｔｈ Ｍｅｓｓａｇｅと同じ処理がされる。
▲２▼ＡＤＤ Ｍｅｓｓａｇｅを受信したＭＲＰは、ツリーの帯域予約を行うためにＰａｔｈ Ｍｅｓｓａｇｅを出す。
▲３▼ＭＲＰ はＰａｔｈ Ｍｅｓｓａｇｅ出す前にＳｅｎｄｅｒ−ＭＲＰ間のＬＳＰとＭＲＰ−Ｌｅａｆ間のＬＳＰを関連づけるために、ＳＥＳＳＩＯＮ変換テーブルを作成する。ＳＥＳＳＩＯＮ変換テーブルには、ＳＥＳＳＩＯＮ ＯｂｊｅｃｔやＳＥＮＤＥＲ＿ＴＥＭＰＬＡＴＥなどの情報をもつ
▲４▼その後ＭＲＰはＰａｔｈ ＭｅｓｓａｇｅをＬｅａｆまで送出し、Ｐａｔｈ ＭｅｓｓａｇｅがＬｅａｆに到着後、ＬｅａｆがＲｅｓｖ Ｍｅｓｓａｇｅを送出する。これによりＭＲＰ−Ｌｅａｆ間のリソースの確保を行う。
【０１５８】
図５０は２つ目のＳｅｎｄｅｒを追加する様子を示す。下記のプロセスで２つ目のＳｅｎｄｅｒがツリーに参加する。
▲１▼追加されるＳｅｎｄｅｒからＡＤＤ Ｍｅｓｓａｇｅを送付する。
▲２▼ＡＤＤ Ｍｅｓｓａｇｅを受信したＭＲＰは、ツリー配下の帯域を増やす必要性について判断する。必要ならばＰａｔｈ Ｍｅｓｓａｇｅを送付する。不要ならばＰａｔｈ Ｍｅｓｓａｇｅを送付せずに、すぐにＲｅｓｖ Ｍｅｓｓａｇｅを返す。
【０１５９】
図５１にパス状態の保持シーケンスを示す。各Ｓｅｎｄｅｒ−ＭＲＰ間とＭＲＰ−Ｌｅａｆ間、Ｓｅｎｄｅｒ Ａ−ＭＲＰ間とＳｅｎｄｅｒ Ａ−ＭＲＰ間は独立にＰａｔｈ／ＲｅｓｖのＳ状態を更新する。もし特定ＳｅｎｄｅｒからＰａｔｈ Ｍｅｓｓａｇｅが来なくなったらば、そのＳｅｎｄｅｒからの帯域は削減するかもしれないことに注意されたい。
【０１６０】
図５２にパス解除シーケンスを示す。トラヒック送信を止めたいＳｅｎｄｅｒはＰａｔｈＴｅａｒ Ｍｅｓｓａｇｅを作成しＭＲＰまで送付する。ＰａｔｈＴｅａｒ Ｍｅｓｓａｇｅを受信したＳｅｎｄｅｒは、解除すべきＳｅｎｄｅｒ−ＭＲＰ間のＬＳＰとＭＲＰ−Ｌｅａｆ間のＬＳＰとの関連付けを止め、予約しているリソースを減らす必要があるかどうか判断を行い、減らす必要があるならばＭＲＰ−Ｌｅａｆ間のＬＳＰの再設定を行う。
【０１６１】
ＡＤＤ Ｍｅｓｓａｇｅのメッセージフォーマットを図５３に示す。ＰａｔｈＭｅｓｓａｇｅと同じフォーマットを持つが、ＭＲＰにＳｅｎｄｅｒが参加することを示すという追加機能を持つ。
【０１６２】
（トラヒックエンジニアリング）
Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇはネットワークの状況に適した経路制御をサポートのため、用いられる。ネットワーク内の情報はＯＳＰＦ−ＴＥのようにＴｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇをサポートしたルーチングプロトコルなどによって収集される。ネットワークの輻輳状況やパスの分布状況などが経路制御の際に使用される有効な情報である。情報の管理方式として２つの方式が考えられる。１つが集中管理型モデルであり、もう１つが分散管理型モデルである。本節ではこれらのモデルについて説明する。
【０１６３】
まず始めに集中管理型モデルについて説明する。トラヒック輻輳などの情報はネットワーク管理のために用意された単一ノードで管理される。例として、Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ（ＮＭＳ）やｓｅｎｄｅｒ ｉｎｉｔｉａｔｅｄ ｔｒｅｅ のｓｅｎｄｅｒなどが上げられる。その他のノードでは通常経路計算は行われない。このモデルでは情報が集中管理されるため、ループなどの検出が容易である。しかし情報が集中することにより、管理ノードの故障は既設、新設のパスの設定管理ができなくなるという重大な問題を引き起こす。このため、通常バックアップ用管理ノードが用意される。また、ネットワークトポロジの変更情報が管理ノードを経由して処理されることで、パストポロジの変更遅延が大きくなる。これらの特徴を考慮すると、集中管理型モデルは静的な、すなわちパストポロジの変更頻度が低いアプリケーションに適用することが望ましい。
【０１６４】
次に分散管理型モデルについて説明する。このモデルではネットワーク管理用のノードはネットワーク中に分散配置される。それぞれのノードはノード周りのネットワークの情報を考慮した経路を計算する。経路計算の局所化により、各ノードで必要となる計算による負荷は比較的軽くなる。このため、大規模な動的マルチキャストツリー、すなわちツリーのトポロジの変更頻度が大きいツリーの構築に適する。パスの設定方針としては２種類存在する。１つはｓｅｎｄｅｒ ｉｎｉｔｉａｔｅｄなツリー設定であり、もう１つはＬｅａｆ ｉｎｉｔｉａｔｅｄなツリー設定である。次節よりそれぞれの設定方針について説明する。
【０１６５】
まず始めにＳｅｎｄｅｒ ｉｎｉｔｉａｔｅｄなパス設定について説明する。通常、ｓｅｎｄｅｒ ｉｎｉｔｉａｔｅｄなツリーの経路は上記で示すようにｓｅｎｄｅｒやＮＭＳで行われる。ここで、複数のドメインを経由するマルチキャストツリーを構築する場合について考える。ｓｅｎｄｅｒは通常自分が属するドメインのトポロジのみを認識している。しかし、ドメイン外の情報はドメインのエッジルータにより隠蔽されている。この場合、ｓｅｎｄｅｒが属するドメイン内の経路をｓｔｒｉｃｔ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定し、ドメイン外の経路をｌｏｏｓｅ ｅｘｐｌｉｃｉｔ ｒｏｕｔｅ指定する。ドメインのエッジノードが隣接するドメインの経路を計算する。
【０１６６】
ここで、マルチアクセスネットワーク上にパスが設定され、かつ、１つのツリーに対する入り口のエッジルータが２つ以上存在する場合を考える（図５４）。それぞれのエッジルータは独自に経路計算を行う。このため、他方が計算した経路にもう一方が計算した経路が交差することがありうる。これらのノードが経路計算をする時刻はほぼ同じになると考えられるため、互いに通知しあうことは難しくなる。このため、一時的にループが形成される。これらの経路情報はＲｅｓｖ ｍｅｓｓａｇｅのＴＲＲＯメッセージとＰａｔｈ ｍｅｓｓａｇｅのＲｅｆｒｅｓｈ動作を介してツリー上のノードに送られる。この情報を利用してループを解消する。
【０１６７】
次にＬｅａｆ Ｉｎｉｔｉａｔｅｄなツリー設定について説明する。Ｌｅａｆｉｎｉｔｉａｔｅｄなツリーの経路はｓｅｎｄｅｒ以外のノードで行われる。計算するノードとしてはＬｅａｆや中間ノード、そしてＮＭＳが存在する。Ｌｅａｆがグループに参加するときのようにツリーから新規参加ノードへパスを接木する場合、接木されたパスの経路はＴＥＲＯなどで示される。しかし、各ノードがネットワーク全体の情報を持たずに自分が属するネットワークの情報のみを持つ場合、ループの形成を阻止する機能が必要となる。このため、本プロトコルでは局在化しているネットワーク情報を各ノードに配布することで情報を共有する。情報配布にはＰａｔｈ ｍｅｓｓａｇｅのＲｅｆｒｅｓｈ動作が用いられる。これらの特徴より、本プロトコルはＬｅａｆ ｉｎｉｔｉａｔｅｄなパス設定時においても、ループを形成しにくい、データ転送の信頼性が高いパスを提供する。
【０１６８】
【発明の効果】
以上説明したように、本発明のマルチキャストＭＰＬＳプロトコルを用いれば、同一のＭＰＬＳネットワーク上でｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ、ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ混在のＬＳＰを設定できる。このため、コンテンツ配信サービスのようにユニキャストのＶｏＤサービス、マルチキャストの放送サービスが混在する転送網として利用することが可能となる。さらにこの混在環境下でＱｏＳを保証した転送が可能となるので有料コンテンツ配信サービスのネットワークインフラとして利用可能である。また本プロトコルでは、ソース起動、リーフ起動のマルチキャストＬＳＰ設定機能を備えるために、あらゆるマルチキャストアプリケーションに利用可能である。さらに本プロトコルはソース起動のＧｒａｆｔ、Ｐｒｕｎｅ処理、リーフ起動のＪｏｉｎ、Ｌｅａｖｅ処理機能を備えるために設定したマルチキャストツリーの全体の再設定を伴わず、トラヒック変動に応じた木目細かいパスの修正が可能なためスケーラビリティの高いネットワーク運用が可能になる。
【０１６９】
このため本発明方式を用いればスケーラブルなコンテンツ配信が可能となり大規模コンテンツ配信ネットワーク環境が容易に実現できる。
【０１７０】
本実施例のマルチキャストＭＰＬＳ通信方法あるいはシステムは、情報処理装置であるコンピュータ装置を用いて実現することができる。すなわち、コンピュータ装置にインストールすることにより、そのコンピュータ装置に、本実施例のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、コンピュータ装置にインストールすることにより、そのコンピュータ装置を、本実施例のマルチキャストＭＰＬＳ通信システムに相応する装置とするプログラムをコンピュータ装置にインストールすることにより、そのコンピュータ装置に本実施例のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、そのコンピュータ装置を本実施例のマルチキャストＭＰＬＳ通信システムに相応する装置とすることができる。
【０１７１】
本実施例のプログラムは本実施例の記録媒体に記録されることにより、コンピュータ装置は、この記録媒体を用いて本実施例のプログラムをインストールすることができる。あるいは、本実施例のプログラムを保持するサーバからネットワークを介して直接コンピュータ装置に本実施例のプログラムをインストールすることもできる。
【０１７２】
これにより、コンピュータ装置を用いて、スケーラブルなコンテンツ配信が可能となり大規模コンテンツ配信ネットワーク環境を実現することができる。
【図面の簡単な説明】
【図１】本実施例のマルチキャストＬＳＰに収容されるマルチキャストトラックを示す図。
【図２】本実施例のＰｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ ＬＳＰを示す図。
【図３】本実施例のマルチキャストＭＰＬＳプロトコルで実現されるＭ−ＬＳＰ設定機能を示す図。
【図４】本実施例のマルチキャストＭＰＬＳの基本動作メカニズムを示す図。
【図５】本実施例の明示的経路指定情報（ＴＥＲＯ）を用いたマルチキャストＬＳＰ設定を示す図。
【図６】本実施例のマルチキャストＭＰＬＳ−ＬＳＰ設定情報とＬＳＲ保持情報を示す図。
【図７】本実施例の新たに定義するＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ４とＭＵＬＴＩＣＡＳＴ＿ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＰｖ６のフォーマットを示す図。
【図８】本実施例のＦＥＣ Ｏｂｊｅｃｔ全体のフォーマット（ｓｕｂｏｂｊｅｃｔの集合）を示す図。
【図９】本実施例のＳｕｂｏｂｊｅｃｔの共通ヘッダ（ＴｙｐｅとＬｅｎｇｔｈと実際の中身）を示す図。
【図１０】本実施例のＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿Ｉｐｖ４を示す図。
【図１１】本実施例のＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ４を示す図。
【図１２】本実施例のＳｕｂｏｂｊｅｃｔであるＳｈａｒｅｄ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を示す図。
【図１３】本実施例のＳｕｂｏｂｊｅｃｔであるＳｏｕｒｃｅ＿ｓｐｅｃｉｆｉｃ＿Ｍｕｌｔｉｃａｓｔ＿Ｔｒｅｅ＿ＩＰｖ６を示す図。
【図１４】本実施例のマルチキャストツリーとそれに対応するＴＥＲＯの表記を示す図。
【図１５】本実施例のＴｒｅｅ Ｅｘｐｌｉｃｉｔ Ｒｏｕｔｅ Ｏｂｊｅｃｔのフォーマットを示す図。
【図１６】本実施例のＴＲＲＯを線形結合して情報統合されたＴＲＲＯを示す図。
【図１７】本実施例のＴｒｅｅ Ｒｅｃｏｒｄ Ｏｂｊｅｃｔのフォーマットを示す図。
【図１８】本実施例のマルチキャストＬＳＰの設定シーケンスを示す図。
【図１９】本実施例のＰａｔｈ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２０】本実施例のＲｅｓｖ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２１】本実施例のＰａｔｈＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２２】本実施例のＲｅｓｖＥｒｒ Ｍｅｓｓａｇｅのフォーマットを示す図。
【図２３】本実施例のＧｒａｆｔ処理メッセージシーケンス概要を示す図。
【図２４】本実施例のＧｒａｆｔ処理でパス確立にエラーが発生した場合のメッセージシーケンス概要を示す図。
【図２５】本実施例のＧｒａｆｔメッセージフォーマットを示す図。
【図２６】本実施例のＧｒａｆｔＮｏｔｉｆｙメッセージフォーマットを示す図。
【図２７】本実施例のＧｒａｆｔＥｒｒメッセージフォーマットを示す図。
【図２８】本実施例のＧｒａｆｔ処理におけるメッセージフォーマット概要（その１）を示す図。
【図２９】本実施例のＧｒａｆｔ処理におけるメッセージフォーマット概要（その２）を示す図。
【図３０】本実施例のＰｒｕｎｅ処理メッセージシーケンス概要を示す図。
【図３１】本実施例のＰｒｕｎｅメッセージフォーマットを示す図。
【図３２】本実施例のＰｒｕｎｅＮｏｔｉｆｙメッセージフォーマットを示す図。
【図３３】本実施例のＰｒｕｎｅＥｒｒメッセージフォーマットを示す図。
【図３４】本実施例のＰｒｕｎｅ処理におけるメッセージフォーマット概要（その１）を示す図。
【図３５】本実施例のＰｒｕｎｅ処理におけるメッセージフォーマット概要（その２）を示す図。
【図３６】本実施例のリーフ起動のＪｏｉｎ処理におけるパス設定の流れを説明する図。
【図３７】本実施例のリーフ起動のＪｏｉｎ処理におけるパス設定の流れを説明する図。
【図３８】本実施例のＪｏｉｎ Ｍｅｓｓａｇｅフォーマットを示す図。
【図３９】本実施例のＪｏｉｎ ｐｒｏｃｅｓｓの実行中にエラーが生じる原因を説明するための図。
【図４０】本実施例のＪｏｉｎ ｐｒｏｃｅｓｓの実行中にエラーが生じる原因を説明するための図。
【図４１】本実施例のＪｏｉｎ Ｅｒｒメッセージのフォーマットを示す図。
【図４２】本実施例のリーフ起動のＬｅａｖｅ処理における動作の流れを説明するための図。
【図４３】本実施例のリーフ起動のＬｅａｖｅ処理における動作の流れを説明するための図。
【図４４】本実施例のＬｅａｖｅメッセージをｓｅｎｄｅｒに向けて送信する状況を示す図。
【図４５】本実施例のＬｅａｖｅメッセージのフォーマットを示す図。
【図４６】本実施例のＭｕｌｔｉｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔのトラヒック転送の様子を示す図。
【図４７】本実施例のＬＳＰの収容状態を示す図。
【図４８】本実施例の最初のＳｅｎｄｅｒがツリーに参加する概要図。
【図４９】本実施例の最初のＳｅｎｄｅｒがツリーに参加する概要図。
【図５０】本実施例の最初のＳｅｎｄｅｒがツリーに参加する詳細図。
【図５１】本実施例のパス状態の保持シーケンスを示す図。
【図５２】本実施例のパス解除シーケンスを示す図。
【図５３】本実施例のＡＤＤ Ｍｅｓｓａｇｅのメッセージフォーマットを示す図。
【図５４】本実施例のマルチアクセスネットワーク上にパスが設定され、かつ、１つのツリーに対する入り口のエッジルータが２つ以上存在する場合を示す図。
【符号の説明】
Ａ〜Ｇ ノード
Claims (43)
- マルチキャストＭＰＬＳ(Multi Protocol Label Switching)のパス設定起動ノードは、マルチキャスト転送経路と当該転送経路上に設定すべきパス情報を、パス設定要求メッセージに格納し、当該パス設定要求メッセージを指定されたマルチキャスト転送経路の次ホップのノードに送出し、
当該パス設定要求メッセージを受信したノードは、当該ノード上に要求されたマルチキャスト転送経路が設定可能な場合には、当該パス設定要求メッセージ内のパス設定情報を自ノード内に一時保持し、当該パス設定要求メッセージ内の経路指定情報により次のマルチキャスト転送経路を判定し、それらのマルチキャスト転送経路上に存在する複数の次ホップのノードに当該パス設定要求メッセージをコピーして送出し、
宛先となるマルチキャストリーフノードは、自身がリーフノードであることを判定し、当該パス設定要求メッセージが転送された経路にＭＰＬＳ転送経路を設定可能な場合には、当該ＭＰＬＳパスで使用するラベルを割当て、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出し、
当該パス設定確認メッセージを受信した上流ノードは、
前記一時保持してあるパス設定情報を確認し、下流ノードの転送に使用するラベルを確認することにより当該ノードと下流ノードとの間のラベルバインディングを設定し、
パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを確認し、全経路からパス設定確認メッセージが到達した場合には、当該ノードと下流ノードとの間のＭＰＬＳ転送経路を確定し、
当該ノードと上流ノードとの間で使用するラベルを確定し、パス設定確認メッセージに格納し、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出し、
前記パス設定起動ノードは、前記パス設定確認メッセージが下流ノードでマージされて自ノードに到達したときに、指定されたマルチキャスト転送路にマルチキャストＭＰＬＳパスを設定する
ことを特徴とするマルチキャストＭＰＬＳ通信方法。 - パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを待っているノードは、最初のパス設定確認メッセージが到達してから、タイマを作動させ、全ての転送経路からパス設定確認メッセージが到達した場合にタイマを停止させ、全ての転送経路からパス設定確認メッセージが到達する前にタイマが示す値が前もって設定された値になったならば、パス設定確認メッセージを上流ノードへ送付する請求項１記載のマルチキャストＭＰＬＳ通信方法。
- マルチキャストパスの一部または全体の設定に失敗した際に、当該失敗に関わるエラーの発生した箇所のノードは、当該エラー原因および当該エラー発生箇所を通知するエラー通知メッセージを作成して送出し、
前記パス設定起動ノードは、
このエラー通知メッセージを受信してエラーが起こった全箇所の情報を収集し、
この収集結果をパス設定起動者に通知する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - マルチキャスト転送経路のリーフノードは、あるマルチキャストツリーに参加したい場合に、当該マルチキャストツリーのマルチキャストＭＰＬＳパス情報を参加要求メッセージに格納して送出し、
当該参加要求メッセージにより参加要請されたマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲ(Label Switching Router) は、当該参加要求メッセージの情報からパス参加要請をしているパス設定起動者宛にマルチキャストツリーの枝ＬＳＰ(Label Switching Path)を設定する
請求項１または３記載のマルチキャストＭＰＬＳ通信方法。 - マルチキャストツリーの枝ＬＳＰの設定に失敗した際に、当該失敗に関わるエラー発生を検出したノードは、前記参加要請されたマルチキャストＬＳＲに対して当該失敗理由を通知し、
この通知により当該失敗理由を通知された前記参加要請されたマルチキャストＬＳＲは、前記参加要求メッセージを送出したリーフノードに当該枝ＬＳＰの設定に失敗したことを通知する
請求項４記載のマルチキャストＭＰＬＳ通信方法。 - マルチキャスト転送経路のリーフノードは、
ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域などの情報を収集し、
収集された情報を分析し、
この分析結果から当該リーフノードに向けてトラヒックを送出するためのパスの分岐点を決定し、
当該リーフノードに向けて設定されるパスの接続要求メッセージを作成し、決定した前記分岐点に対して送出し、
当該パス設定要求メッセージを受信した当該分岐ノードはリーフノードに対してパスを設定する
請求項１ないし４のいずれかに記載のマルチキャストＭＰＬＳ通信方法。 - パス設定要求メッセージが経由したノードは、当該パス設定要求メッセージに自ノードの情報を経路履歴として記録し、
当該メッセージの宛先ノードは、当該経路履歴に沿ってパスを設定し、
ネットワーク内のノードは、当該経路履歴からパスのループを検知する
請求項１ないし４のいずれかに記載のマルチキャストＭＰＳＬ通信方法。 - マルチキャスト転送経路のリーフノードから分岐点として最適と判断され、パス設定要求を受信したマルチキャスト転送経路を構成するノードは、
ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域を含む情報を収集し、
収集された情報を分析し、
この分析結果から、より分岐点として適したマルチキャスト転送経路を構成するノードを検索し、
そのようなノードが発見された場合には、リーフノードから分岐点として判断された前記ノードが、分岐するパスを設定することを要求するメッセージを作成し、前記発見されたノードに向けて送出し、
メッセージを受信した前記発見されたノードは、
最初にパス設定の要求が出されたノードで行われたのと同様の手段で情報収集を行い、
この収集した情報を分析し、
この分析された結果から、さらに分岐点として適したノードを検索し、
そのようなノードに対しパス設定要求を送出する
請求項１ないし４のいずれかに記載のマルチキャストＭＰＬＳ通信方法。 - マルチキャスト転送経路のリーフノードは、
自身が収容するクライアントの当該データの視聴状態を判定し、
この判定が当該マルチキャストエッジＬＳＲに到達するマルチキャストＬＳＰを不要と判定した場合には、当該マルチキャストＭＰＬＳパスの不要部分を削除し、
この削除する際に、離脱要求メッセージに離脱対象のマルチキャストＬＳＰ情報を格納して送出し、
マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該離脱要求メッセージの情報からパス離脱要請をしているリーフノードまでのマルチキャストツリーの枝ＬＳＰを削除する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - 設定されたマルチキャストＬＳＰに部分ツリーを追加するために、部分ツリーを追加する接木ノードを選択し、
前記接木ノードに接木する部分ツリー情報を通知して接木処理を要請し、
接木処理を要請された前記接木ノードが部分ツリーを構築し、
接木された部分ツリーの接木処理結果を、前記接木処理を要請したノードに通知する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - 前記部分ツリーを構築する際に、部分ツリーの構築に失敗したときには、前記接木処理を要請された接木ノードが当該失敗箇所の情報を収集して前記接木処理を要請したノードに通知する
請求項１０記載のマルチキャストＭＰＬＳ通信方法。 - 設定されたマルチキャストＬＳＰの部分ツリーを剪定するために、部分ツリーを剪定する剪定ノードを選択して当該剪定ノードに剪定処理を要請し、
この剪定処理を要請したノードに対して前記剪定ノードにより削除する部分ツリー情報を通知し、
前記剪定ノードが部分ツリーを剪定し、
この剪定された部分ツリーの剪定処理結果を、前記剪定処理を要請したノードに通知する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - マルチキャストＭＰＬＳパス設定時に同一転送サービスに含まれる複数のＬＳＰを１つの束として扱うためのトラヒックエンジニアリングトンネルを識別するための第一の情報と、同一転送サービスを受けるトラヒックグループを識別するための第二の情報と、トラヒックエンジニアリングトンネル内でＬＳＰを識別するための第三の情報とが、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、
前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する
請求項１ないし４あるいは９ないし１２のいずれかに記載のマルチキャストＭＰＬＳ通信方法。 - 前記第一および第三の情報がマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、
前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する
請求項１ないし４あるいは９ないし１２のいずれかに記載のマルチキャストＭＰＬＳ通信方法。 - 前記第二の情報により様々な種別のトラヒックをＬＳＰに対して割り当て、
１つのＬＳＰに対して複数のトラヒックを割り当てる
請求項１３または１４記載のマルチキャストＭＰＬＳ通信方法。 - 既設のマルチキャストＬＳＰツリーに新たにトラヒックを送出したいソースノードは、新たにトラヒックを流すことを要求しかつ当該ツリーのルートノードまでのＬＳＰ設定を行うことを要求する新規参入メッセージを生成し、
当該新規参入メッセージを当該ツリーのルートノードへと送付し、
前記ツリーのルートノードは、
当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰと自ノードからリーフノードまでのＬＳＰを関連付け、
当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップし、
前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - トラヒック送出を止めたいソースノードは、トラヒックを止めることを通知しかつツリーのルートノードまでのＬＳＰを解除することを要請する送出解除メッセージを生成し、
当該送出解除メッセージを当該ツリーのルートノードへと送付し、
前記ツリーのルートノードは、
当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでの解除要請のあったＬＳＰと自ノードからリーフノードまでのＬＳＰの関連付けを解除し、
当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップすることを停止し、
前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することを停止する
請求項１または１６記載のマルチキャストＭＰＬＳ通信方法。 - 経路指定を要望するツリーの経路上のノードの情報として当該ツリーのルートノードからサブオブジェクトに対応するノードまでの距離を情報として保持し、
この保持された当該サブオブジェクトを深さ優先探索で前記ツリーを走査したときに通る順番で並べ、
前記保持された情報から前記ツリーの設定経路をネットワーク中のノードに明示的に指定する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - 着目する一つのメッセージが通過したノードの履歴を記録し、
マルチキャストツリーの分岐点でこの着目する一つのメッセージ同士の経路履歴情報を統合し、
この統合結果にこの分岐点を特定する情報を組み込むことによりこの分岐点を根とする部分ツリーを表現する
請求項１記載のマルチキャストＭＰＬＳ通信方法。 - パス設定の失敗を検知したノードは、
当該失敗箇所を前記マルチキャストＭＰＬＳパス設定起動ノードに通知するメッセージを作成し、
この作成された当該メッセージを前記マルチキャストＭＰＬＳパス設定起動ノードに送出し、
前記マルチキャストＭＰＬＳパス設定起動ノードは、
通知された前記失敗箇所を使わずにリーフノードまでの経路を再計算し、
この再計算された経路を接木するＬＳＲをマルチキャストパスを構成するＬＳＲの中から選択し、
接木するパスの経路を前記接木するＬＳＲに対して指示し、
前記接木するＬＳＲは、前記指示された経路にしたがってパス設定する
請求項１または１０記載のマルチキャストＭＰＬＳ通信方法。 - マルチキャストＭＰＬＳのパス設定起動ノードは、マルチキャスト転送経路と当該転送経路上に設定すべきパス情報を、パス設定要求メッセージに格納し、当該パス設定要求メッセージを指定されたマルチキャスト転送経路の次ホップのノードに送出する手段を備え、
当該パス設定要求メッセージを受信したノードは、当該ノード上に要求されたマルチキャスト転送経路が設定可能な場合には、当該パス設定要求メッセージ内のパス設定情報を自ノード内に一時保持し、当該パス設定要求メッセージ内の経路指定情報により次のマルチキャスト転送経路を判定し、それらのマルチキャスト転送経路上に存在する複数の次ホップのノードに当該パス設定要求メッセージをコピーして送出する手段を備え、
宛先となるマルチキャストリーフノードは、自身がリーフノードであることを判定し、当該パス設定要求メッセージが転送された経路にＭＰＬＳ転送経路を設定可能な場合には、当該ＭＰＬＳパスで使用するラベルを割当て、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出する手段を備え、
当該パス設定確認メッセージを受信した上流ノードは、
前記一時保持してあるパス設定情報を確認し、下流ノードの転送に使用するラベルを確認することにより当該ノードと下流ノードとの間のラベルバインディングを設定する手段と、
パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを確認し、全経路からパス設定確認メッセージが到達した場合には、当該ノードと下流ノードとの間のＭＰＬＳ転送経路を確定する手段と、
当該ノードと上流ノードとの間で使用するラベルを確定し、パス設定確認メッセージに格納し、上流の前ホップノードに当該ラベルを格納したパス設定確認メッセージを送出する手段と
を備え、
前記パス設定起動ノードは、前記パス設定確認メッセージが下流ノードでマージされて自ノードに到達したときに、指定されたマルチキャスト転送路にマルチキャストＭＰＬＳパスを設定する手段を備えた
ことを特徴とするマルチキャストＭＰＬＳ通信システム。 - パス設定要求メッセージを送出した全ての転送経路からパス設定確認メッセージが到達するのを待っているノードは、
最初のパス設定確認メッセージが到達してから、タイマを作動させる手段と、全ての転送経路からパス設定確認メッセージが到達した場合にタイマを停止させる手段と、
全ての転送経路からパス設定確認メッセージが到達する前にタイマが示す値が前もって設定された値になったならば、パス設定確認メッセージを上流ノードへ送付する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - マルチキャストパスの一部または全体の設定に失敗した際に、当該失敗に関わるエラーの発生した箇所のノードは、当該エラー原因および当該エラー発生箇所を通知するエラー通知メッセージを作成して送出する手段を備え、
前記パス設定起動ノードは、
このエラー通知メッセージを受信してエラーが起こった全箇所の情報を収集する手段と、
この収集結果をパス設定起動者に通知する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - マルチキャスト転送経路のリーフノードは、あるマルチキャストツリーに参加したい場合に、当該マルチキャストツリーのマルチキャストＭＰＬＳパス情報を参加要求メッセージに格納して送出する手段を備え、
当該参加要求メッセージにより参加要請されたマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該参加要求メッセージの情報からパス参加要請をしているパス設定起動者宛にマルチキャストツリーの枝ＬＳＰを設定する手段を備えた
請求項２１または２３記載のマルチキャストＭＰＬＳ通信システム。 - マルチキャストツリーの枝ＬＳＰの設定に失敗した際に、当該失敗に関わるエラー発生を検出したノードは、前記参加要請されたマルチキャストＬＳＲに対して当該失敗理由を通知する手段を備え、
この通知する手段により当該失敗理由を通知された前記参加要請されたマルチキャストＬＳＲは、前記参加要求メッセージを送出したリーフノードに当該枝ＬＳＰの設定に失敗したことを通知する手段を備えた
請求項２４記載のマルチキャストＭＰＬＳ通信システム。 - マルチキャスト転送経路のリーフノードは、
ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域などの情報を収集する手段と、
収集された情報を分析する手段と、
この分析結果から当該リーフノードに向けてトラヒックを送出するためのパスの分岐点を決定する手段と、
当該リーフノードに向けて設定されるパスの接続要求メッセージを作成し、決定した前記分岐点に対して送出する手段と、
当該パス設定要求メッセージを受信した当該分岐ノードはリーフノードに対してパスを設定する手段と
を備えた請求項２１ないし２４のいずれかに記載のマルチキャストＭＰＬＳ通信システム。 - パス設定要求メッセージが経由したノードは、当該パス設定要求メッセージに自ノードの情報を経路履歴として記録する手段を備え、
当該メッセージの宛先ノードは、当該経路履歴に沿ってパスを設定する手段を備え、
ネットワーク内のノードは、当該経路履歴からパスのループを検知する手段を備えた
請求項２１ないし２４のいずれかに記載のマルチキャストＭＰＳＬ通信システム。 - マルチキャスト転送経路のリーフノードから分岐点として最適と判断され、パス設定要求を受信したマルチキャスト転送経路を構成するノードは、
ネットワーク中のトラヒック分布、転送経路の距離、経路の遅延情報、リンクの残余帯域を含む情報を収集する手段と、
収集された情報を分析する手段と、
この分析結果から、より分岐点として適したマルチキャスト転送経路を構成するノードを検索する手段と
を備え、
そのようなノードが発見された場合には、リーフノードから分岐点として判断された前記ノードが、分岐するパスを設定することを要求するメッセージを作成し、前記発見されたノードに向けて送出する手段を備え、
メッセージを受信した前記発見されたノードは、
最初にパス設定の要求が出されたノードで行われたのと同様の手段で情報収集を行う手段と、
この収集した情報を分析する手段と、
この分析された結果から、さらに分岐点として適したノードを検索する手段と、
そのようなノードに対しパス設定要求を送出する手段と
を備えた請求項２１ないし２４のいずれかに記載のマルチキャストＭＰＬＳ通信システム。 - マルチキャスト転送経路のリーフノードは、
自身が収容するクライアントの当該データの視聴状態を判定する手段と、
この判定する手段が当該マルチキャストエッジＬＳＲに到達するマルチキャストＬＳＰを不要と判定した場合には、当該マルチキャストＭＰＬＳパスの不要部分を削除する手段と
を備え、
この削除する手段は、離脱要求メッセージに離脱対象のマルチキャストＬＳＰ情報を格納して送出する手段を備え、
マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲは、当該離脱要求メッセージの情報からパス離脱要請をしているリーフノードまでのマルチキャストツリーの枝ＬＳＰを削除する手段を備えた
請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - 設定されたマルチキャストＬＳＰに部分ツリーを追加するために、部分ツリーを追加する接木ノードを選択する手段と、
前記接木ノードに接木する部分ツリー情報を通知して接木処理を要請する手段と、
接木処理を要請された前記接木ノードが前記マルチキャストＭＰＬＳパスを設定する手段により部分ツリーを構築する手段と、
接木された部分ツリーの接木処理結果を、前記接木処理を要請する手段を備えたノードに通知する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - 前記部分ツリーを構築する手段が部分ツリーの構築に失敗したときには、前記接木処理を要請された接木ノードが当該失敗箇所の情報を収集して前記接木処理を要請する手段を備えたノードに通知する手段を備えた請求項３０記載のマルチキャストＭＰＬＳ通信システム。
- 設定されたマルチキャストＬＳＰの部分ツリーを剪定するために、部分ツリーを剪定する剪定ノードを選択して当該剪定ノードに剪定処理を要請する手段と、
この剪定処理を要請する手段を備えたノードに対して前記剪定ノードにより削除する部分ツリー情報を通知する手段と、
前記剪定ノードが前記マルチキャストＭＰＬＳパスを設定する手段により部分ツリーを剪定する手段と、
剪定された部分ツリーの剪定処理結果を、前記剪定処理を要請する手段を備えたノードに通知する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - マルチキャストＭＰＬＳパス設定時に同一転送サービスに含まれる複数のＬＳＰを１つの束として扱うためのトラヒックエンジニアリングトンネルを識別するための第一の情報と、同一転送サービスを受けるトラヒックグループを識別するための第二の情報と、トラヒックエンジニアリングトンネル内でＬＳＰを識別するための第三の情報とが、マルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、
前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する手段を備えた請求項２１ないし２４あるいは２９ないし３２のいずれかに記載のマルチキャストＭＰＬＳ通信システム。 - 前記第一および第三の情報がマルチキャストＭＰＬＳパスを構成するマルチキャストＬＳＲに分散して設定され、
前記第一および第二の情報によりマルチキャストＭＰＬＳパスを特定する手段を備えた請求項２１ないし２４あるいは２９ないし３２のいずれかに記載のマルチキャストＭＰＬＳ通信システム。 - 前記第二の情報により様々な種別のトラヒックをＬＳＰに対して割り当てる手段を備え、
１つのＬＳＰに対して複数のトラヒックを割り当てる手段を備えた
請求項３３または３４記載のマルチキャストＭＰＬＳ通信方式。 - 既設のマルチキャストＬＳＰツリーに新たにトラヒックを送出したいソースノードは、新たにトラヒックを流すことを要求しかつ当該ツリーのルートノードまでのＬＳＰ設定を行うことを要求する新規参入メッセージを生成する手段と、
当該新規参入メッセージを当該ツリーのルートノードへと送付する手段と
を備え、
前記ツリーのルートノードは、
当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰと自ノードからリーフノードまでのＬＳＰを関連付ける手段と、
当該新規参入メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップする手段と、
前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - トラヒック送出を止めたいソースノードは、トラヒックを止めることを通知しかつツリーのルートノードまでのＬＳＰを解除することを要請する送出解除メッセージを生成する手段と、
当該送出解除メッセージを当該ツリーのルートノードへと送付する手段と
を備え、
前記ツリーのルートノードは、
当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでの解除要請のあったＬＳＰと自ノードからリーフノードまでのＬＳＰの関連付けを解除する手段と、
当該送出解除メッセージを受信することにより前記ソースノードから自ノードまでのＬＳＰに割り当てられたラベルを前記ツリーのＬＳＰに割り当てられたラベルへとスワップすることを停止する手段と、
前記ソースノードから自ノードまでのＬＳＰ上のトラヒックを、自ノードからリーフノードまでのＬＳＰへ送付することを停止する手段と
を備えた請求項２１または３６記載のマルチキャストＭＰＬＳ通信システム。 - 経路指定を要望するツリーの経路上のノードの情報として当該ツリーのルートノードからサブオブジェクトに対応するノードまでの距離を情報として保持する手段と、
この保持する手段に保持された当該サブオブジェクトを深さ優先探索で前記ツリーを走査したときに通る順番で並べる手段と、
前記保持する手段に保持された情報から前記ツリーの設定経路をネットワーク中のノードに明示的に指定する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - 着目する一つのメッセージが通過したノードの履歴を記録する手段と、
マルチキャストツリーの分岐点でこの着目する一つのメッセージ同士の経路履歴情報を統合する手段と、
この統合結果にこの分岐点を特定する情報を組み込むことによりこの分岐点を根とする部分ツリーを表現する手段と
を備えた請求項２１記載のマルチキャストＭＰＬＳ通信システム。 - パス設定の失敗を検知したノードは、
当該失敗箇所を前記マルチキャストＭＰＬＳパス設定起動ノードに通知するメッセージを作成する手段と、
この作成する手段により作成された当該メッセージを前記マルチキャストＭＰＬＳパス設定起動ノードに送出する手段と
を備え、
前記マルチキャストＭＰＬＳパス設定起動ノードは、
通知された前記失敗箇所を使わずにリーフノードまでの経路を再計算する手段と、
この再計算する手段により再計算された経路を接木するＬＳＲをマルチキャストパスを構成するＬＳＲの中から選択する手段と、
接木するパスの経路を前記接木するＬＳＲに対して指示する手段と
を備え、
前記接木するＬＳＲは、前記指示する手段により指示された経路にしたがってパス設定する手段を備えた
請求項２１または３０記載のマルチキャストＭＰＬＳ通信システム。 - 請求項２１ないし４０のいずれかに記載のマルチキャストＭＰＬＳ通信システムを備えたことを特徴とするネットワーク。
- 情報処理装置にインストールすることにより、その情報処理装置に、請求項１ないし２０のいずれかに記載のマルチキャストＭＰＬＳ通信方法を実行させる、あるいは、情報処理装置にインストールすることにより、その情報処理装置を、請求項２１ないし４０のいずれかに記載のマルチキャストＭＰＬＳ通信システムに相応する装置として動作させることを特徴とするプログラム。
- 請求項４２記載のプログラムが記録された前記情報処理装置読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002182061A JP3801953B2 (ja) | 2002-06-21 | 2002-06-21 | マルチキャストｍｐｌｓ通信方法およびシステムおよびネットワーク |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002182061A JP3801953B2 (ja) | 2002-06-21 | 2002-06-21 | マルチキャストｍｐｌｓ通信方法およびシステムおよびネットワーク |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004032114A JP2004032114A (ja) | 2004-01-29 |
| JP3801953B2 true JP3801953B2 (ja) | 2006-07-26 |
Family
ID=31178724
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002182061A Expired - Fee Related JP3801953B2 (ja) | 2002-06-21 | 2002-06-21 | マルチキャストｍｐｌｓ通信方法およびシステムおよびネットワーク |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3801953B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4086027B2 (ja) | 2004-09-30 | 2008-05-14 | ブラザー工業株式会社 | 管理システム及びプログラム |
| JP4514648B2 (ja) | 2005-05-18 | 2010-07-28 | 富士通株式会社 | 管理サーバによる情報処理方法及びルータ |
| JP2008118351A (ja) * | 2006-11-02 | 2008-05-22 | National Institute Of Information & Communication Technology | 無線通信システム |
| EP1968251A1 (en) * | 2007-03-09 | 2008-09-10 | NTT DoCoMo, Inc. | Method and apparatus for QoS resource reservation and configuration of multicast network resources |
| CN101060617B (zh) * | 2007-05-22 | 2010-07-28 | 华为技术有限公司 | 一种视频点播控制方法、客户端设备和切换控制装置 |
| FR2920624B1 (fr) * | 2007-09-03 | 2010-03-12 | Alcatel Lucent | Procede d'etablissement d'une connexion bidirectionnelle point a multipoint |
| JP5874253B2 (ja) | 2011-09-08 | 2016-03-02 | 富士通株式会社 | 配信システム、配信方法、及び配信プログラム |
| CN105052098B (zh) | 2013-04-05 | 2019-04-23 | 索尼公司 | 中继管理装置、中继管理方法以及中继管理系统 |
| JP5701963B2 (ja) * | 2013-12-03 | 2015-04-15 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | ネットワーク |
| CN106688212B (zh) | 2014-09-10 | 2020-05-19 | 索尼公司 | 通信控制设备、通信控制方法和通信系统 |
| CN115333974B (zh) * | 2022-08-10 | 2023-08-11 | 杭州云合智网技术有限公司 | Drni网络中基于vsi的环路检测方法及装置 |
-
2002
- 2002-06-21 JP JP2002182061A patent/JP3801953B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004032114A (ja) | 2004-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10833989B2 (en) | Methods, apparatus, and articles of manufacture to provide a multicast virtual private network (MVPN) | |
| US7583601B2 (en) | Multicast transfer route setting method, and multicast label switching method for implementing former method | |
| US7570649B2 (en) | Forwarding state sharing between multiple traffic paths in a communication network | |
| JP4612987B2 (ja) | マルチプロトコルラベルスイッチングベースのポイント対マルチポイント・トラフィックルーチング方法 | |
| USRE47260E1 (en) | System and method for point to multipoint inter-domain MPLS traffic engineering path calculation | |
| US7701940B2 (en) | Inter-domain point-to-multipoint path computation in a computer network | |
| US7477642B2 (en) | MPLS traffic engineering for point-to-multipoint label switched paths | |
| US7304955B2 (en) | Scalable IP multicast with efficient forwarding cache | |
| WO2007054032A1 (en) | Communication network system and leaf-node network element of the multicasting tree signal transmission method and node network element thereof | |
| JP4148099B2 (ja) | ポイントツーマルチポイントｍｐｌｓ通信方法 | |
| US20110286450A1 (en) | Multicast hello on demand | |
| WO2008037198A1 (fr) | Procédés de mise en oeuvre de réacheminement rapide multidiffusion et noeud | |
| US8611346B1 (en) | Multicast sparse-mode source redundancy | |
| WO2007090346A1 (fr) | Système de commande, procédé d'émission de message de données, et dispositif de réseau eternet | |
| JP3801953B2 (ja) | マルチキャストｍｐｌｓ通信方法およびシステムおよびネットワーク | |
| EP2353257A1 (en) | Multicast and bidirectional unicast signaling in single root multipoint services using rsvp-te | |
| Chen et al. | SoMR: A scalable distributed QoS multicast routing protocol | |
| CA2376690A1 (en) | System and method for loop avoidance in multi-protocol label switching | |
| WO2008138236A1 (fr) | Procédé et dispositif de diffusion multidestinataire | |
| JP4231074B2 (ja) | マルチキャストラベルスイッチング方法 | |
| JP4522955B2 (ja) | マルチキャストポイントツーポイント（ｍｐ２ｐ）マルチプロトコルラベルスイッチング（ｍｐｌｓ）トラヒックエンジニアリング（ｔｅ）通信システム | |
| Yasukawa et al. | Scalable multicast MPLS protocol for next generation broadband service convergence network | |
| JP4244891B2 (ja) | ポイントツーマルチポイントＭＰＬＳ（Ｍｕｌｔｉ−ＰｒｏｔｏｃｏｌＬａｂｅｌＳｗｉｔｃｈｉｎｇ）通信方法及びシステム | |
| Chung et al. | Extensions to MPLS networking for enhanced multiplatform multicasting services | |
| Pedersen et al. | A new approach to multicasting and QoS within an MPLS backbone |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040804 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060118 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060425 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060426 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090512 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100512 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100512 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110512 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120512 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130512 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140512 Year of fee payment: 8 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |