(57)【特許請求の範囲】
【請求項１】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのネットワークノードであって、共通ソースネットワークノードに関連付けられる前記ネットワークノードを動作させる方法であって、
１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第１パスを判定し、かつ、２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスを判定するステップであって、前記第１パス及び前記第２パスは、互いに相手に対して冗長性を示す、ステップと、
前記ネットワークノードが前記共通ソースネットワークノードから前記第１パスを介してマルチキャストデータを受信するステップと、
前記ネットワークノードが前記第１パスの障害を検出すると、前記ネットワークノードが前記共通ソースネットワークノードから前記第２パスを介してのマルチキャストデータの受信をトリガするステップと、
を含み、
前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現され、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とする方法。
【請求項２】
前記第１パス及び前記第２パスは、互いに相手に対して最大限の冗長性を示すことを特徴とする請求項１に記載の方法。
【請求項３】
前記ネットワークノードは、前記１次ネットワークツリー及び前記２次ネットワークツリーをそれぞれ判定する計算処理を実行することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記ネットワークノードが障害を検出すると、障害メッセージが前記ネットワークノードから前記第２パスを介して前記共通ソースネットワークノードに向けて送信されることを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
障害を検出するために、
前記ネットワークノードが前記共通ソースネットワークノードから前記第１パスを介してシグナリングを受信したかをチェックする処理と、
前記ネットワークノードがシグナリングを予想通りに受信しないと、障害を検出する処理と、
を実行することを特徴とする請求項４に記載の方法。
【請求項６】
前記ネットワークノードは、前記１次ネットワークツリーに割り当てられた１次送信元ＩＰアドレスと、前記２次ネットワークツリーに割り当てられた２次送信元ＩＰアドレスと、を保持し、
前記ネットワークノードから他のネットワークノードに前記１次ネットワークツリーを介してＩＰデータパケットを転送する場合、転送前に前記１次送信元ＩＰアドレスを前記ＩＰデータパケットに追加し、
前記ネットワークノードから前記他のネットワークノードに前記２次ネットワークツリーを介してＩＰデータパケットを転送する場合、転送前に前記２次送信元ＩＰアドレスを前記ＩＰデータパケットに追加する、
ことを特徴とする請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより、前記ネットワークノードと前記共通ソースネットワークノードとを関連付けるステップと、
前記共通ソースネットワークノードに該起動メッセージを送信した後に、前記ネットワークノードが、前記共通ソースネットワークノードから前記第１パスを介してマルチキャストデータを受信するステップと、
前記ネットワークノードが前記第１パスの障害を検出すると、前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信するステップと、
前記共通ソースネットワークノードに該起動メッセージを送信した後に、前記ネットワークノードが、前記共通ソースネットワークノードから前記第２パスを介してマルチキャストデータを受信するステップと、
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記共通ソースネットワークノードに前記第２パスを介して前記起動メッセージを送信した後、前記ネットワークノードは、前記第１パス及び前記第２パスを同時に介してマルチキャストデータを受信することを特徴とする請求項７に記載の方法。
【請求項９】
前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介してパス構築メッセージを送信し、かつ、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介してパス構築メッセージを送信することにより、前記ネットワークノードと前記共通ソースネットワークノードとを関連付けるステップと、
前記共通ソースネットワークノードに該パス構築メッセージを送信した後、前記ネットワークノードが、前記共通ソースネットワークノードから前記第１パスを介してマルチキャストデータを受信するステップと、
前記ネットワークノードが前記第１パスの障害を検出すると、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信するステップと、
前記共通ソースネットワークノードに該起動メッセージを送信した後、前記ネットワークノードが前記共通ソースネットワークノードから前記第２パスを介してマルチキャストデータを受信するステップと、
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記共通ソースネットワークノードに前記第２パスを介して前記起動メッセージを送信した後、前記ネットワークノードは、前記共通ソースネットワークノードから前記第１パス及び前記第２パスを同時に介してマルチキャストデータを受信することを特徴とする請求項９に記載の方法。
【請求項１１】
前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して第１の種類のパス構築メッセージを送信し、かつ、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して第２の種類のパス構築メッセージを送信することにより前記ネットワークノードと前記共通ソースネットワークノードとを関連付けるステップと、
前記共通ソースネットワークノードに前記第１の種類の前記パス構築メッセージを送信した後、前記ネットワークノードが前記共通ソースネットワークノードから前記第１パスを介してマルチキャストデータを受信するステップと、
前記ネットワークノードが前記第１パスの障害を検出すると、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信するステップと、
前記共通ソースネットワークノードに前記起動メッセージを送信した後、前記ネットワークノードが前記共通ソースネットワークノードから前記第２パスを介してマルチキャストデータを受信するステップと、
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１の種類の前記パス構築メッセージは前記第１パスを起動し、
前記第２の種類の前記パス構築メッセージは前記第２パスを起動するが、前記共通ソースネットワークノードから前記第２パスを介しての前記ネットワークノードへのデータ送信は事前にブロックされ、
前記事前のブロックは、前記起動メッセージが前記ネットワークノードから前記共通ソースネットワークノードに送信されると停止されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記第１パスの障害を検出した後に、前記マルチキャスト通信ネットワーク内の新規の１次ネットワークツリー及び新規の２次ネットワークツリーを判定するステップであって、前記新規の１次ネットワークツリー及び前記新規の２次ネットワークツリーは、前記共通ソースネットワークノードを共有し、前記新規の１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する新規の第１パス及び前記新規の２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する新規の第２パスが前記ネットワークノードに割り当てられ、前記新規の第１パス及び前記新規の第２パスは、互いに相手に対して冗長性を示す、ステップと、
前記新規の１次ネットワークツリー及び前記新規の２次ネットワークツリーを判定した後、前記ネットワークノードが前記共通ソースネットワークノードから前記新規の第１パスを介してデータを受信するステップと、
をさらに含むことを特徴とする請求項１から１２のいずれか１項に記載の方法。
【請求項１４】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークの共通ソースネットワークノードを動作させる方法であって、
前記マルチキャスト通信ネットワークは、前記共通ソースネットワークノードを共有する１次ネットワークツリー及び２次ネットワークツリーを有し、前記マルチキャスト通信ネットワークの複数のネットワークノードのそれぞれに、前記１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第１パス及び前記２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスがそれぞれ割り当てられ、前記第１パス及び前記第２パスが互いに相手に対して冗長性を示し、前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現され、
前記方法は、
前記共通ソースネットワークノードが前記共通ソースネットワークノードに関連付けられる前記複数のネットワークノードのそれぞれに、対応する前記第１パスを介してマルチキャストデータを送信するステップと、
前記共通ソースネットワークノードがネットワークノードに割り当てられた前記第１パスの障害を示すメッセージを前記ネットワークノードから受信すると、前記共通ソースネットワークノードに関連付けられる前記複数のネットワークノードのうちの少なくとも１つに、対応する前記第２パスを介してデータを送信するステップと、
を含み、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とする方法。
【請求項１５】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークを動作させる方法であって、
前記マルチキャスト通信ネットワーク内の１次ネットワークツリー及び２次ネットワークツリーを判定するステップであって、前記１次ネットワークツリー及び前記２次ネットワークツリーは共通ソースネットワークノードを共有し、前記マルチキャスト通信ネットワークの複数のネットワークノードのそれぞれに、前記１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第１パス及び前記２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスがそれぞれ割り当てられ、前記第１パス及び前記第２パスは、互いに相手に対して冗長性を示し、前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現される、ステップと、
前記共通ソースネットワークノードが、前記共通ソースネットワークノードに関連付けられる前記複数のネットワークノードのそれぞれに、対応する前記第１パスを介してマルチキャストデータを送信するステップと、
ネットワークノードが該ネットワークノードに割り当てられた前記第１パスの障害を検出すると、前記共通ソースネットワークノードが前記ネットワークノードに、対応する前記第２パスを介してデータを送信するステップと、
を含み、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とする方法。
【請求項１６】
１つ以上のコンピュータで実行されると、前記１つ以上のコンピュータに請求項１から１５のいずれか１項に記載の各ステップを実行させることを特徴とするコンピュータプログラム。
【請求項１７】
コンピュータ可読記録媒体に保持されていることを特徴とする請求項１６に記載のコンピュータプログラム。
【請求項１８】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのネットワークノードであり、共通ソースネットワークノードに関連付けられるように構成される前記ネットワークノードであって、
１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第１パスを判定し、かつ、２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスを判定するように構成され、前記第１パス及び前記第２パスは互いに相手に対して冗長性を示し、前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現され、
前記ネットワークノードは、
前記共通ソースネットワークノードから前記第１パスを介してマルチキャストデータを受信するように構成され、
前記第１パスの障害を検出し、かつ、前記第１パスの障害を検出すると、前記共通ソースネットワークノードから前記第２パスを介してのマルチキャストデータの受信をトリガするようにさらに構成され、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とするネットワークノード。
【請求項１９】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークにおいて動作可能な共通ソースネットワークノードであって、前記マルチキャスト通信ネットワークは、前記共通ソースネットワークノードを共有する１次ネットワークツリー及び２次ネットワークツリーを有し、前記マルチキャスト通信ネットワークの複数のネットワークノードのそれぞれに、前記１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第１パス及び前記２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスがそれぞれ割り当てられ、前記第１パス及び前記第２パスが互いに相手に対して冗長性を示し、前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現される、前記共通ソースネットワークノードであって、
前記共通ソースネットワークノードから、前記共通ソースネットワークノードに関連付けられる前記複数のネットワークノードのそれぞれに、対応する前記第１パスを介してマルチキャストデータを送信するように構成され、
ネットワークノードから該ネットワークノードに割り当てられた前記第１パスの障害を示すメッセージを受信したかを判定するように構成され、通信部に、前記共通ソースネットワークノードから、前記共通ソースネットワークノードに関連付けられる前記複数のネットワークノードのそれぞれに、対応する前記第２パスを介してデータを送信させるように構成され、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とする共通ソースネットワークノード。
【請求項２０】
請求項１８に記載のネットワークノードを複数と、
請求項１９に記載の共通ソースネットワークノードと、
を含むことを特徴とするマルチキャスト通信ネットワーク。
【請求項２１】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのネットワークノードであって、共通ソースネットワークノードに関連付けられる前記ネットワークノードを動作させる方法であって、
１次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第１パスを判定し、かつ、２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスを判定するステップであって、前記第１パス及び前記第２パスが互いに相手に対して冗長性を示し、前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現される、ステップと、
前記ネットワークノードが、前記共通ソースネットワークノードから前記第１パス及び前記第２パスを同時に介してマルチキャストデータを受信するステップと、
を含み、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とする方法。
【請求項２２】
通信リンクにより互いに接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのネットワークノードであり、共通ソースネットワークノードに関連付けられるように構成される前記ネットワークノードであって、
１次ネットワークツリーに沿って共通ソースネットワークノードに前記ネットワークノードを接続する第１パスを判定し、かつ、２次ネットワークツリーに沿って前記共通ソースネットワークノードに前記ネットワークノードを接続する第２パスを判定するように構成され、前記第１パス及び前記第２パスが互いに相手に対して冗長性を示し、前記１次ネットワークツリー及び前記２次ネットワークツリーは最大冗長ツリーとして実現され、
前記ネットワークノードは、
前記共通ソースネットワークノードから前記第１パス及び前記第２パスを同時に介してマルチキャストデータを受信するように構成され、
前記第１パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第１パスを介して起動メッセージを送信することにより起動されることと、前記第２パスは、前記ネットワークノードが前記共通ソースネットワークノードに前記第２パスを介して起動メッセージを送信することにより起動されることとの少なくとも１つを含むことを特徴とするネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ネットワークノードを動作させる技術分野に関する。特に、本発明は、マルチキャスト通信ネットワークのネットワークノード、マルチキャスト通信ネットワークの共通ソースネットワークノード及びマルチキャスト通信ネットワーク自体の動作に関する。更に本発明は、ネットワークノード、共通ソースネットワークノード及びマルチキャスト通信ネットワークに関する。
【背景技術】
【０００２】
プロトコル独立マルチキャスト疎モード（ＰＩＭ−ＳＭ）（非特許文献１、参照）は周知であり、インターネットプロトコル（ＩＰ）マルチキャスト通信ネットワークにおけるマルチキャストツリーを構築及び保持するために一般に適用されるプロトコルである。マルチキャスト通信ネットワークのネットワークノード（以下、「宛先」とも呼ぶ）にマルチキャストコンテンツを配信するために、ＰＩＭ−ＳＭは単一のマルチキャストツリーを使用する。
【０００３】
ＰＩＭ−ＳＭにおいて、ネットワークノードは、マルチキャストグループに対して参加又は離脱するためにＪＯＩＮメッセージのユニキャスト転送を使用する。マルチキャストグループに参加するために、ネットワークノードは、共通ソースネットワークノードに向けてマルチキャストツリーの上流方向にＪＯＩＮメッセージを送信する（以下、用語「共通ソースネットワークノード」は、共有ツリーの場合のランデブーポイントを更に含む）。ＪＯＩＮメッセージは、マルチキャストルーティング情報ベース（ＭＲＩＢ）テーブルにより判定されるマルチキャストツリーのパスに沿ってルーティングされる。これらのテーブルにおいて列挙されるパスは、通常、ユニキャストルーティングテーブルから直接導出される（しかし、それらは異なる方法で導出されてもよい）。同様に、マルチキャストグループから離脱するために待機しているネットワークノードは、マルチキャストツリーの上向きにＰＲＵＮＥパケットを共通ソースネットワークノードに送信する。
【０００４】
ＭＲＩＢテーブルは、ＪＯＩＮメッセージが次に送信されるネクストホップネイバを判定するために使用される。ＪＯＩＮメッセージは、マルチキャストコンテンツを既に受信しているネットワークノードに到達するまでホップ単位でルーティング及び処理される。このパスに沿う全てのネットワークノードがＪＯＩＮメッセージを処理し、対応するマルチキャストルーティング状態情報をインストール／更新する（例えば、ＪＯＩＮメッセージを受信した際に介した入力インタフェースを出力インタフェースリストに追加することにより）。マルチキャストコンテンツは、ＪＯＩＮメッセージがルーティングされる経路と逆向きの経路に沿って流れる（下向き）。
【０００５】
上述のように、ＭＲＩＢテーブルが通常はユニキャストルーティングテーブルから導出されるため、ＪＯＩＮメッセージは共通ソースネットワークノードへの最短パス（経路）に沿って転送される。これは、非対称リンクコストの場合の最短下流経路と異なる場合がある。その結果、ＰＩＭ−ＳＩＭを使用して確立されたマルチキャストストリームは下向きに準最適な経路を使用する場合がある。
【０００６】
ＰＩＭ−ＳＭはユニキャストルーティングに非常に依存するため、ネットワーク障害の場合、ユニキャストルーティングが回復するまで待機する必要がある。従って、障害に対する反応は相対的に遅い。その一方で、ＰＩＭ−ＳＭはリアルタイムトラフィックに対する（例えば、ＩＰＴＶに対する）パスを構築するために現在一般に使用される。これは、障害に対する反応が重大な欠点であることを意味する。この欠点を克服するために、非特許文献２は、ネットワークノードの受信マルチキャストストリームに対する第２パスを作成することにより、ネットワークノードが１次上流側隣接ネットワークノードとの接続を失った場合に即座に代替パスを提供することを提案する。しかし、この手法は、全ての可能な障害の例を処理できると保証できない。更に、この手法は「１＋１」保護技術であり、障害がない状況でも「２次」トラフィックが常に存在することを意味する。そのため、この手法は、特にＨＤ  ＩＰＴＶストリーム等の高帯域幅トラフィックの場合にマルチキャストネットワーク内に著しい追加負荷を生じさせる。
【０００７】
別の手法が、非特許文献３において開示される。しかし、この手法では、厳密に選択された非対称リンクコスト及びトンネリングが必要とされる。綿密に割り当てられたリンクコストを変更することをネットワークオペレータが常に許容できるとは限らず、また、トンネルリングにより生じるパケット分割すら問題になるため、この手法は常に適用可能ではない。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】ＲＦＣ４６０１、２００６年８月
【非特許文献２】ＲＦＣ５７１４、２０１０年１月
【非特許文献３】Ｒ．Ｌｕｅｂｂｅｎ、Ｇ．Ｌｉ、Ｄ．Ｗａｎｇ、Ｒ．Ｄｏｖｅｒｓｐｉｋｅ、Ｘ．Ｆｕ、「Ｆａｓｔ  ｒｅｒｏｕｔｉｎｇ  ｆｏｒ  ＩＰ  ｍｕｌｔｉｃａｓｔ  ｉｎ  ｍａｎａｇｅｄ  ＩＰＴＶ  ｎｅｔｗｏｒｋｓ」、１７ｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ、２００９．ＩＷＱｏＳ、１〜５ページ、２００９年７月
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ネットワーク障害に対する柔軟且つ迅速な反応を保証するマルチキャストネットワークのネットワークノードを動作させる方法を提供する必要がある。
【課題を解決するための手段】
【００１０】
第１の態様によると、通信リンクにより互いに相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのネットワークノードであり、共通ソースネットワークノードに関連付けられるネットワークノードを動作させる方法が提供される。方法は、１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パスを判定し且つ２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスを判定することであり、第１パス及び第２パスが互いに対して冗長性を示すことと、ネットワークノードにおいて第１パスを介して共通ソースネットワークノードからマルチキャストデータを受信することと、ネットワークノードが第１パスの障害を検出する場合にネットワークノードにより共通ソースネットワークノードから第２パスを介するマルチキャストデータの受信をトリガすることと、を備える。
【００１１】
第１パスの障害は、マルチキャストデータが現在受信されないか又は今後受信されない場合に検出される。この点に関して、例えばタイマの終了、専用メッセージの受信、並びにマルチキャストデータ（例えば、マルチキャストトラフィックパケット）又はハートビート信号の受信の損失等に基づく種々の検出機構が適用される。
【００１２】
１つの例示的な実現例において、ネットワーク障害が後に生じた場合に効率的な障害管理が可能であるように、第１パス及び第２パスは事前に判定される。
【００１３】
第１パス及び第２パスは、技術的に最大限の冗長性を互いに対して示す。１次ネットワークツリー及び２次ネットワークツリーは、ＭＲＴ（最大冗長ツリー：Ｍａｘｉｍａｌｌｙ  Ｒｅｄｕｎｄａｎｔ  Ｔｒｅｅｓ）として実現される。１次ツリーに沿う第１パス及び２次ツリーに沿う第２パスは、リンクが可能な限り重複しない（例えば、不可避の切断点及び切断辺のみが双方のパスにより共有される）。
【００１４】
最大の冗長性は、何らかの単一リンク／ノード障害の場合に各ネットワークノードが根から１次ツリー及び２次ツリーの少なくとも一方に沿って到達可能であるように実現される。すなわち、ネットワーク障害の場合、いくつかのネットワークノードは１次ネットワークツリー及び２次ネットワークツリーを介して到達可能であり（その場合、当該ネットワークノードは原則としてツリーの一方を廃棄できる）、いくつかのネットワークノードは１次ネットワークツリー及び２次ネットワークツリーのうちの一方のみを介して到達可能である。尚、１次ツリー及び２次ツリーはいずれも必ずしも最短パスツリーである必要はない（例えばＰＩＭ−ＳＭにおいて通常利用されるように）。
【００１５】
計算処理は、１次ネットワークツリー及び２次ネットワークツリーがそれぞれ判定されるネットワークノードにおいて実行される。この場合、マルチキャストネットワークの１つ以上のネットワークノードにおいて１次ネットワークツリー及び２次ネットワークツリーを同時に判定する（例えば、事前に）ことが可能になり、それによりネットワーク障害が後に生じた場合の再ルーティング速度が速くなる。
【００１６】
ネットワークノードが第１パスの障害を検出する場合、障害メッセージが送信される。障害メッセージは、ネットワークノードから第２パスを介して共通ソースネットワークノードに向けて送信される。
【００１７】
障害を検出するために、シグナリング（例えば、ハートビート信号又はマルチキャストトラフィックパケット）が共通ソースネットワークノードから第１パスを介してネットワークノードにおいて受信されたかをチェックする（例えば、ランダムに選択した時間間隔又は規則的な時間間隔で）処理と、ネットワークノードがシグナリングを予想通り受信しなかった（例えば、所定の期間を超えた）場合に障害を検出する処理とが実行される。このように、ネットワーク障害の早期検出が保証される。
【００１８】
マルチキャストツリーは、グループアドレス（これは、共通ソースネットワークノード（又はランデブーポイント）からマルチキャストツリーの下流に送信されるＩＰデータパケットの宛先アドレスであってもよい）及び送信元アドレス（共通ソースネットワークノード（又はランデブーポイント）に割り当てられる）により記述される。２つのマルチキャストツリーを切り替えられるようにするために、２つのアドレスが共通ソースネットワークノード（又はランデブーポイント）に割り当てられ、それにより、マルチキャスト通信ネットワークを以下のように動作できる。ネットワークノードは、１次ネットワークツリーに割り当てられた１次送信元ＩＰアドレス及び２次ネットワークツリーに割り当てられた２次送信元ＩＰアドレスを保持する。ネットワークノードから１次ネットワークツリーを介して更なるネットワークノードにＩＰデータパケットを転送する場合、ＩＰデータパケットを転送する前に１次送信元ＩＰアドレスがそれに追加され、ネットワークノードから２次ツリーを介して更なるネットワークノードにＩＰデータパケットを転送する場合、ＩＰデータパケットを転送する前に２次送信元ＩＰアドレスがそれに追加される。
【００１９】
第１パスは、ネットワークノードから第１パスを介して共通ソースネットワークノードに起動メッセージを送信することにより起動される。それに加えて又はその代わりに、第２パスは、ネットワークノードから第２パスを介して共通ソースネットワークノードに起動メッセージを送信することにより起動される。
【００２０】
例示的な実現例によると、ネットワークノードから第１パスを介して共通ソースネットワークノードに起動メッセージを送信することによりネットワークノードと共通ソースネットワークノードとを関連付ける処理と、共通ソースネットワークノードに起動メッセージを送信した後にネットワークノードにおいて第１パスを介して共通ソースネットワークノードからマルチキャストデータを受信する処理と、ネットワークノードが第１パスの障害を検出する場合にネットワークノードから第２パスを介して共通ソースネットワークノードに起動メッセージを送信する処理と、共通ソースネットワークノードに起動メッセージを送信した後にネットワークノードにおいて第２パスを介して共通ソースネットワークノードからマルチキャストデータを受信する処理とが実行される。
【００２１】
本実現例（「回復モード」）において、第２パスは事前に計算されるだけで、事前に起動されない。第１パスから第２パスへの切り替えは、起動メッセージ（例えば、ＰＩＭ  ＪＯＩＮメッセージ又は他のプロトコルの場合の同様のメッセージ）により開始される。障害を検出したネットワークノードに到達するために必要な２次ネットワークツリーのレグ（例えば、第２パス）のみが起動される。レグは複数のネットワークノードにわたってもよく、それらは１次ネットワークツリーからもトラフィック（マルチキャストコンテンツパケット等）を受信してもしなくてもよい。すなわち、第２パスを介して共通ソースネットワークノードに起動メッセージを送信した後、マルチキャストデータは他のいくつかのネットワークノードにおいて第１パス及び第２パスを同時に介して受信されてもよい。このように、起動メッセージはパスの構築及び起動の双方を開始する。
【００２２】
更なる例示的な実現例によると、ネットワークノードから第１パスを介して共通ソースネットワークノードにパス構築メッセージを送信し且つネットワークノードから第２パスを介して共通ソースネットワークノードにパス構築メッセージを送信することによりネットワークノードと共通ソースネットワークノードとを関連付ける処理と、共通ソースネットワークノードにパス構築メッセージを送信した後にネットワークノードにおいて第１パスを介して共通ソースネットワークノードからマルチキャストデータを受信する処理と、ネットワークノードが第１パスの障害を検出する場合にネットワークノードから第２パスを介して共通ソースネットワークノードに起動メッセージを送信する処理と、共通ソースネットワークノードに起動メッセージを送信した後にネットワークノードにおいて第２パスを介して共通ソースネットワークノードからマルチキャストデータを受信する処理とが実行される。
【００２３】
パスの構築及び起動の双方が１つのメッセージのみで開始される回復モードと異なり、本実現例（「単純な保護モード」）では、第２パスを起動するために２つのメッセージ（パスを構築するためのパス構築メッセージ及びパスを起動するための起動メッセージ）が定義される。本実現例において、共通ソースネットワークノードは、障害メッセージを受信すると、２次ツリー全体におけるマルチキャストコンテンツの送信を更に開始する。すなわち、第２パスを介して共通ソースネットワークノードにネットワーク障害メッセージ（起動メッセージ）を送信した後、共通ソースネットワークノードに関連付けられる（登録される）マルチキャストネットワークの全てのネットワークノードは対応する第１パス及び第２パスを同時に介して共通ソースネットワークノードからマルチキャストデータを受信する。
【００２４】
別の例示的な実現例によると、ネットワークノードから第１パスを介して共通ソースネットワークノードに第１の種類のパス構築メッセージを送信し且つネットワークノードから第２パスを介して共通ソースネットワークノードに第２の種類のパス構築メッセージを送信することによりネットワークノードと共通ソースネットワークノードとを関連付ける処理と、共通ソースネットワークノードに第１の種類のパス構築メッセージを送信した後にネットワークノードにおいて第１パスを介して共通ソースネットワークノードからマルチキャストデータを受信する処理と、ネットワークノードが第１パスの障害を検出する場合にネットワークノードから第２パスを介して共通ソースネットワークノードに起動メッセージを送信する処理と、共通ソースネットワークノードに起動メッセージを送信した後にネットワークノードにおいて第２パスを介して共通ソースネットワークノードからマルチキャストデータを受信する処理とが実行される。第１の種類のパス構築メッセージは、第１パスを構築し且つ起動する。第２の種類のパス構築メッセージは、第２パスの構築のみを行い、共通ソースネットワークノードから第２パスを介するネットワークノードへのデータ送信を事前にブロックする。事前ブロックは、起動メッセージがネットワークノードから第２パスを介して共通ソースネットワークノードに送信され次第除去される。
【００２５】
本実現例（「高度な保護モード」）において、第１パスから第２パスへの切り替えは、第２パスを構築することではなく（第２パスは既に事前に構築されている）、対応する起動メッセージを送信することにより行われる。切り替えは、起動メッセージの受信時に共通ソースネットワークノードにより行われてもよく、障害を検出したネットワークノードと共通ソースネットワークノードとの間の全てのネットワークノード（すなわち、第２パスに沿う全てのネットワークノード）により行われてもよい。本実施形態において、回復モードと同様に、２次ツリーのレグ（すなわち、第２パス）（障害を検出したネットワークノードに到達するために必要である）のみが使用され、他の第２パスは起動されない。レグは複数のネットワークノードにわたってもよく、それらは第１のツリーからもトラフィック（マルチキャストコンテンツパケット等）を受信してもしなくてもよい。すなわち、第２パスを介して共通ソースネットワークノードに起動メッセージを送信した後、マルチキャストデータは他のいくつかのネットワークノードにおいて第１パス及び第２パスを同時に介して受信されてもよい。
【００２６】
単純な保護モードと比較して、高度な保護モードは、ブロックを除去された第２パスのみが２次ツリーにおいて使用されるため、他のノードの第２パスに沿う情報トラフィックを回避するという利点を有する。単純な保護モードにおいて、障害メッセージは第２のツリー全体のブロックを除去する（全てのポートがブロックされない）。
【００２７】
第１パスの障害を検出した後、マルチキャスト通信ネットワーク内の新規の１次ネットワークツリー及び新規の２次ネットワークツリーが判定されてもよい。新規の１次ネットワークツリー及び新規の２次ネットワークツリーは共通ソースネットワークノードを共有する。新規の１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する新規の第１パス及び新規の２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する新規の第２パスがネットワークノードに割り当てられる。新規の第１パス及び新規の第２パスは、互いに対して（例えば、最大）冗長性を示す。新規の１次ネットワークツリー及び新規の２次ネットワークツリーを判定した後、共通送信元ノードから新規の第１パスを介するデータがネットワークノードにおいて受信される。このように、ネットワーク障害後に１次ネットワークツリー及び２次ネットワークツリーは最適化される。
【００２８】
更なる態様によると、通信リンクにより相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークの共通ソースネットワークノードを動作させる方法が提供される。マルチキャスト通信ネットワークは、共通ソースネットワークノードを共有する１次ネットワークツリー及び２次ネットワークツリーを備え、１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パス及び２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスがマルチキャスト通信ネットワークの複数のネットワークノードの各々にそれぞれ割り当てられる。第１パス及び第２パスは、互いに対して冗長性を示す。方法は、共通ソースネットワークノードから共通ソースネットワークノードに関連付けられる複数のネットワークノードの各々に各自の第１パスを介してマルチキャストデータを送信することと、共通ソースネットワークノードがネットワークノードに割り当てられた第１パスの障害を示すメッセージをネットワークノードから受信した場合に共通ソースネットワークノードから共通ソースネットワークノードに関連付けられる複数のネットワークノードのうちの少なくとも１つに各自の第２パスを介してデータを送信することとを備える。
【００２９】
本発明の更なる態様によると、通信リンクにより互いに相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークを動作させる方法が提供される。方法は、１次ネットワークツリー及び２次ネットワークツリーが共通ソースネットワークノードを共有し、１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パス及び２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスがマルチキャスト通信ネットワークの複数のネットワークノードの各々にそれぞれ割り当てられ、第１パス及び第２パスが互いに対して冗長性を示すマルチキャスト通信ネットワーク内の１次ネットワークツリー及び２次ネットワークツリーを判定することと、共通ソースネットワークノードから共通ソースネットワークノードに関連付けられる複数のネットワークノードの各々に各自の第１パスを介してマルチキャストデータを送信することと、ネットワークノードがネットワークノードに割り当てられた第１パスの障害を検出する場合に共通ソースネットワークノードからネットワークノードに各自の第２パスを介してデータを送信することと、を備える。
【００３０】
コンピュータプログラムが１つ以上の演算装置上で実行される場合に本発明のいずれかの実施形態のステップを実行するプログラムコード部分を備えるコンピュータプログラムが提供される。コンピュータプログラムはコンピュータ可読記録媒体に格納されてもよい。
【００３１】
別の態様によると、通信リンクにより互いに相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのマルチキャスト通信ネットワークノードが提供される。ネットワークノードは、共通ソースネットワークノードに関連付けられるように構成される。ネットワークノードは、互いに対して冗長性を示す第１パス及び第２パスであり、１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パスを判定し且つ２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスを判定するように構成され、第１パスを介して共通ソースネットワークノードからマルチキャストデータを受信するように更に構成される。ネットワークノードは、第１パスの障害を検出し且つ処理部が第１パスの障害を検出する場合に共通ソースネットワークノードから第２パスを介するマルチキャストデータの受信をトリガするように更に構成される。
【００３２】
更なる態様によると、通信リンクにより互いに相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークにおいて動作可能な共通ソースネットワークノードが提供される。マルチキャスト通信ネットワークは、共通ソースネットワークノードを共有する１次ネットワークツリー及び２次ネットワークツリーを備える。１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パス及び２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスがマルチキャスト通信ネットワークの複数のネットワークノードの各々にそれぞれ割り当てられ、第１パス及び第２パスは互いに対して冗長性を示す。共通ソースネットワークノードは、共通ソースネットワークノードから共通ソースネットワークノードに関連付けられる複数のネットワークノードの各々に各自の第１パスを介してマルチキャストデータを送信し、通信部がネットワークノードに割り当てられた第１パスの障害を示すメッセージをネットワークノードから受信したかを判定し且つ通信部に共通ソースネットワークノードから共通ソースネットワークノードに関連付けられる複数のネットワークノードのうちの少なくとも１つに各自の第２パスを介してデータを送信させるように構成される。
【００３３】
本明細書において説明する複数のネットワークノードと、本明細書において説明する共通ソースネットワークノードとを備えるマルチキャスト通信ネットワークが更に提供される。
【００３４】
更なる態様によると、通信リンクにより互いに相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのネットワークノードであり、共通ソースネットワークノードに関連付けられるネットワークノードを動作させる方法が提供される。方法は、互いに対して冗長性を示す第１パス及び第２パスであり、１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パスを判定し且つ２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスを判定することと、ネットワークノードにおいて第１パス及び第２パスを同時に介して共通ソースネットワークノードからマルチキャストデータを受信することとを備える。
【００３５】
方法は、本明細書において提示する態様のいずれかと組み合わされてもよい。一例として、第１パス及び第２パスは互いに対して最大限の冗長性を示す（例えば、ＭＲＴの意味で）。また、障害検出及び／又は報告の態様が要望に応じて実現される。
【００３６】
別の態様によると、通信リンクにより互いに相互接続される複数のネットワークノードを備えるマルチキャスト通信ネットワークのマルチキャスト通信ネットワークノードが提供される。ネットワークノードは、共通ソースネットワークノードに関連付けられるように構成される。ネットワークノードは、互いに対して冗長性を示す第１パス及び第２パスであり、１次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第１パスを判定し且つ２次ネットワークツリーに沿って共通ソースネットワークノードにネットワークノードを接続する第２パスを判定するように構成され、第１パス及び第２パスを同時に介して共通ソースネットワークノードからマルチキャストデータを受信するように更に構成される。
【００３７】
以下、図面に示す例示的な実施形態を参照して、本発明を更に詳細に説明する。
【図面の簡単な説明】
【００３８】
【図１】マルチキャスト通信ネットワークのネットワークノードの一実施形態を概略的に示すブロック図である。
【図２】マルチキャスト通信ネットワークの共通ソースネットワークノードの一実施形態を概略的に示すブロック図である。
【図３】マルチキャスト通信ネットワークの一実施形態を概略的に示すブロック図である。
【図４】マルチキャスト通信ネットワークのネットワークノードの動作の一実施形態を示すフローチャートである。
【図５】マルチキャスト通信ネットワークの共通送信元ネットワークの動作の一実施形態を示すフローチャートである。
【図６】マルチキャスト通信ネットワークの動作の一実施形態を示すフローチャートである。
【図７】マルチキャスト通信ネットワークの別の実施形態を概略的に示すブロック図である。
【図８】マルチキャスト通信ネットワークの動作の別の実施形態を示すフローチャートである。
【図９】マルチキャスト通信ネットワークを動作させるために使用される従来のルーティングテーブルを概略的に示すブロック図である。
【図１０】マルチキャスト通信ネットワークを動作させるために使用される変更されたルーティングテーブルの一実施形態を概略的に示すブロック図である。
【図１１】マルチキャスト通信ネットワークの一実施形態を概略的に示すブロック図である。
【図１２】マルチキャスト通信ネットワークの一実施形態を概略的に示すブロック図である。
【発明を実施するための形態】
【００３９】
以下の説明において、本明細書において提示する技術を完全に理解するために、限定せずに説明する便宜上、特定の装置及びシステムの構成、並びに特定の方法、ステップ及び機能等の特定の詳細を記載する。当技術はそれら特定の詳細から逸脱する他の実施形態において実現されてもよいことが理解されるだろう。例えば、以下の実施形態は主にＰＩＭ及びＰＩＭ−ＳＭに関連して説明されるが、本明細書において提示する技術がマルチキャストＭＬＰＳ（ｍＬＤＰ）を含む他の規格及び仕様に関連して実現されてもよいことが容易に理解されるだろう。ｍＬＤＰの場合、ラベルマップメッセージの概念は、上記及び以下の実施形態において例示として説明するＰＩＭ  ＪＯＩＮメッセージに対応する。すなわち、本明細書において提示するＰＩＭに関する技術をｍＬＤＰの例に換言する場合、ＰＩＭ  ＪＯＩＮメッセージに対する何らかの参照はｍＬＤＰのラベルマップメッセージに対する参照に換言される。
【００４０】
本明細書において説明する方法、ステップ及び機能は、個別のハードウェア回路網を使用して、プログラムされたマイクロプロセッサ又は汎用コンピュータと関連して機能するソフトウェアを使用して、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、１つ以上のＤＳＰ及び／又は１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を使用して実現されてもよいことが同業者には更に理解されるだろう。本明細書において開示する技術はプロセッサ及びプロセッサに結合されたメモリにおいて実現されてもよく、その場合、メモリは、プロセッサにより実行される場合に本明細書において説明する方法、ステップ及び機能を実行する１つ以上のプログラムを格納することが更に理解されるだろう。
【００４１】
以下の実施形態に対して、同一の図中符号は同一又は同様の構成要素を示すために使用される。
【００４２】
図１及び図３を参照して、一実施形態に係るマルチキャスト通信ネットワークノード７を説明する。マルチキャスト通信ネットワーク７は、通信リンクにより互いに相互接続される複数のネットワークノード１を備える。ネットワークノード１は、共通ソースネットワークノード４に関連付けられる（例えば、登録される）ように構成される。いくつかの例において、共通ソースネットワークノード４を共通根ネットワークノード又は単に根ノードとも呼ぶ。
【００４３】
ネットワークノード１は、１次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第１パス５を判定し且つ２次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第２パス６を判定するように構成された処理部２を備える。第１パス５及び第２パス６は、互いに対して冗長性を示す。ネットワークノード１は、処理部２に接続され且つ第１パス５を介して共通ソースネットワークノード４からマルチキャストデータを受信するように構成された通信部３を更に備える。処理部２は、第１パスの障害を検出し（例えば、マルチキャストデータが第１パス５を介して通信部３により現在受信されているか（又は今後受信されるか）を判定し）且つ処理部２が障害を検出する（例えば、マルチキャストデータが第１パス５を介して現在受信されていない（又は今後受信されない）と判定する）場合に共通ソースネットワークノード４から第２パス６を介するマルチキャストデータの受信をトリガするように更に構成される。
【００４４】
図２及び図３を参照して、一実施形態に係る共通ソースネットワークノード４を説明する。共通ソースネットワークノード４は、上述のように通信リンクにより互いに相互接続される複数のネットワークノード１を備えるマルチキャスト通信ネットワーク７において動作可能である。マルチキャスト通信ネットワーク７は、共通ソースネットワークノード４を共有する１次ネットワークツリー及び２次ネットワークツリーを備える。
【００４５】
上述のように、マルチキャスト通信ネットワーク７の複数のネットワークノード１の各々に対して、１次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第１パス５及び２次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第２パス６が割り当てられる。この場合、第１パス５及び第２パス６は互いに対して冗長性を示す。
【００４６】
共通ソースネットワークノード４は、共通ソースネットワークノード４から共通ソースネットワークノード４に関連付けられる（例えば、登録される）複数のネットワークノード１の各々に各自の第１パス５を介してマルチキャストデータを送信するように構成された通信部８を備える。共通ソースネットワークノード４は、通信部８に接続され且つ通信部８が第１パスの障害（例えば、ネットワークノード１がネットワークノード１に割り当てられた第１パス５を介して共通ソースネットワークノード４からデータを受信しないこと）を示すメッセージをネットワークノード１から受信したかを判定するように構成された処理部９を更に備える。処理部９は、通信部４に共通ソースネットワークノード４から共通ソースネットワークノード４に関連付けられる複数のネットワークノード１のうちの少なくとも１つに各自の第２パス６を介してデータを送信させるように更に構成される。
【００４７】
図４は、例示的な一実施形態に係る図１及び図３に示すネットワークノード１を動作させる方法を示す。第１のステップＳ１において、１次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第１パス５が判定され、２次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第２パス６が判定される。第１パス５及び第２パス６は、互いに対して冗長性（例えば、最大の冗長性）を示す。
【００４８】
第２のステップＳ２において、ネットワークノード１でマルチキャストデータが第１パス５に沿って共通ソースネットワークノード４から受信される。次に、第３のステップＳ３において、ネットワークノード４が第１パス５の障害を検出する場合、共通ソースネットワークノード４から第２パス６に沿うマルチキャストデータの受信がネットワークノード１によりトリガされる。このトリガは、１つ以上のメッセージ、パケット、あるいは使用中のプロトコルに依存する他の何らかのシグナリングの送信を含む多くの方法で実行される。いくつかのトリガの例を以下に更に詳細に説明する。
【００４９】
本実施形態の利点は、第１パス５及び第２パス６が各ネットワークノード１に対して事前に（例えば、マルチキャストデータの受信に先行する構成段階において）判定されることである。従って、ネットワーク障害の場合に効率的な障害管理が可能になる（第２パス６の起動／構築にのみ時間がかかり、第２パス６の判定には時間がかからない）。
【００５０】
図４の実施形態に基づく変更された一実施形態において、ステップＳ３が省略され、マルチキャストデータ（例えば、マルチキャストパケット）が第１パス及び第２パスを同時に介して受信されるようにステップＳ２が変更される。その場合、受信機（及び／又は出口／エッジ）は、一方のパス（及びツリー）において各マルチキャストパケットの少なくとも１つの複製を受信する。１つの実現例において、複製は単純に削除される。代替のステップＳ３において、第１パス及び第２パスの一方に対して検出された障害は、何らかのメッセージ、パケット又はシグナリングにより（例えば、送信元ノードに向かう専用又は既存のメッセージ、パケット又はシグナリングを使用して）通知される。図１のネットワークノードは、変更された実施形態を実現するように適合される（必要に応じて）。
【００５１】
図５は、例示的な一実施形態に係る図２及び図３に示す共通ソースネットワークノード４を動作させる方法を示す。第１のステップＳ１において、マルチキャストデータは、共通ソースネットワークノード４から共通ソースネットワークノード４に関連付けられる（例えば、登録される）複数のネットワークノード１の各々に各自の第１パス５を介して送信される。第２のステップＳ２において、共通ソースネットワークノード４が第１パス５の障害を示す（例えば、ネットワークノード１がネットワークノード１に割り当てられた第１パス５を介して共通ソースネットワークノード４からデータを受信しないという）メッセージをネットワークノード１から受信すると、データは共通ソースネットワークノード４から共通ソースネットワークノード４に関連付けられる複数のネットワークノード１のうちの少なくとも１つに各自の第２パス６を介して送信される。
【００５２】
図６は、例示的な一実施形態に係る図３に示すマルチキャスト通信ネットワーク７を動作させる方法を示す。第１のステップＳ１において、１次ネットワークツリー及び２次ネットワークツリーがマルチキャスト通信ネットワーク７内で判定される。１次ネットワークツリー及び２次ネットワークツリーは共通ソースネットワークノード４を共有し、１次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第１パス５及び２次ネットワークツリーに沿って共通ソースネットワークノード４にネットワークノード１を接続する第２パス６がマルチキャスト通信ネットワーク７の複数のネットワークノード１の各々にそれぞれ割り当てられる。第１パス５及び第２パス６は、互いに対して冗長性を示す。第２のステップＳ２において、マルチキャストデータは、共通ソースネットワークノード４から共通ソースネットワークノード４に割り当てられる複数のネットワークノード１の各々に各自の第１パス５を介して送信される。その後、第３のステップＳ３において、ネットワークノード１が第１パス５の障害を検出する（例えば、データがネットワークノード１に割り当てられた第１パス５を介して現在受信されないか又は今後受信されないと判定する）場合、データは共通ソースネットワークノード４から共通ソースネットワークノード４に関連付けられる複数のネットワークノード１のうちの少なくとも１つに各自の第２パス６を介して送信される。
【００５３】
以下の説明において、更なる特徴及び実施形態を説明する。以下に説明する特徴及び実施形態は、図１〜図６を参照して上述した特徴及び実施形態と組み合わされてもよい。
【００５４】
図１〜図６を参照して上述した冗長性は、ｍａｘｉｍａｌｌｙ  ｒｅｄｕｎｄａｎｔ  ｔｒｅｅｓを使用して実現される（例えば、本明細書に参考として取り入れられているＧａｂｏｒ  Ｅｎｙｅｄｉ、Ｇａｂｏｒ  Ｒｅｔｖaｒｉ、Ａｎｄｒａｓ  Ｃｓａｓｚａｒ、「Ｏｎ  Ｆｉｎｄｉｎｇ  Ｍａｘｉｍａｌｌｙ  Ｒｅｄｕｎｄａｎｔ  Ｔｒｅｅｓ  ｉｎ  Ｓｔｒｉｃｔｌｙ  Ｌｉｎｅａｒ  Ｔｉｍｅ」、ＩＥＥＥ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｃｏｍｐｕｔｅｒｓ  ａｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、ＩＳＣＣ、Ｓｏｕｓｓｅ、Ｔｕｎｉｓｉａ、２００９年７月を参照）。ＭＲＴは、各ネットワークノードが根ネットワークノード（本例において、「共通ソースネットワークノード」とも呼ぶ）から到達可能であり且つ根ネットワークノードから各ネットワークノードへの２つのツリーに沿う各自の２つのパスが最大限の冗長性を有するように方向付けられた有向スパニングツリーのセット（例えば、対）である（本例において、ネットワークツリー対の一方のツリーを１次ツリーと呼び、他方のツリーをバックアップツリー又は２次ツリーと呼ぶ）。ＭＲＴは、根ネットワークノードが他の全てのネットワークノードから各自の２つのパスを介して到達可能であるように、逆方向にも定義可能である。一般に、不可避のネットワークノード及びネットワークリンク（切断点及び切断辺）のみが双方のパスの一部である。従って、ネットワークを２つのネットワークに分割しない単一障害が存在する場合、根ネットワークノードは、ツリーの少なくとも一方に沿ってネットワーク内の他の各ネットワークノードに依然として到達できる。
【００５５】
一実施形態によると、本明細書において開示する技術は、ネットワーク障害後のネットワークにおけるマルチキャストコンテンツパケットの転送を持続するためにネットワーク内のＭＲＴに依存する。ＭＲＴは、各ネットワークノード（ネットワークノード１等）が２つのパス（一方のパスがネットワークツリー対の一方（１次ネットワークツリー）を通り且つ他方のパスがネットワークツリー対の他方（２次ネットワークツリー）を通る）を介して共通根ノードから到達可能であり且つ２つのネットワークツリーに沿う２つのパスのネットワークノード及びネットワークリンク（ネットワークリンクは、ネットワークノードを互いに結合する）が可能な限り重複しない（不可避な切断点及び切断辺のみが双方のパスに含まれる）ように方向付けられた共通根ノード（例えば、共通ソースネットワークノード４）を有する有向スパニングネットワークツリーのセットである。
【００５６】
ＭＲＴ対の一実施形態を図７に示す。図７において、マルチキャスト通信ネットワークのＭＲＴは、通信リンク７２により互いに結合される複数のネットワークノード１と、本明細書中で「ｒ」で示す共通ソースネットワークノード（「根」）４とを備えると示される。実線矢印は１次ネットワークツリーの部分を示し、破線矢印は２次ネットワークツリーの部分を示す。例えば、１次ネットワークツリーの部分７０は共通ソースネットワークノードｒからネットワークノードｆへの第１パスを形成し、２次ネットワークツリーの部分７１は共通ソースネットワークノードｒからネットワークノードｆへの第２パスを形成する。本例において、共通ソースネットワークノードｒからネットワークノードｆへの２つのパスは、不可避な切断点であるネットワークノードｃ以外のノードが重複しない。
【００５７】
従来の通信システムにおける例示的なＰＩＭ−ＳＭの実現例は最短パスツリーに沿うＪＯＩＮパケット及びＰＲＵＮＥパケットの転送に依存するが、ＰＩＭ−ＳＭに依存する一実施形態によると、最短パスツリーは冗長性ツリー対の一方のツリー、すなわち１次ツリーに置換される。このように、ネットワーク障害時、障害が理論上修復可能である場合、動作が保証される冗長性ツリー対の２次ツリーに迅速にアクセスできる。
【００５８】
障害後の２次ツリーへのアクセスは、好適な障害回復反応時間に依存して、複数の方法で実行可能である。
【００５９】
例えば一実施形態において、ネットワーク７は回復モードで動作される。これは、ネットワークノード１がマルチキャストツリーへの接続の切断（例えば、パス障害）を検出した後、ネットワークノード１が２次ツリーにおいてルーティングされるＰＩＭ  ＪＯＩＮメッセージ又は同様の起動メッセージを送信することにより２次ツリーへの参加を開始することを意味する。従来の手法において、ＰＩＭが最初にユニキャストルーティングの収束を待つ必要があるため、ＰＩＭを用いるマルチキャストストリームの回復は相対的に遅い。それに対して、本実施形態によると、２次ツリーが事前に計算されていて即座に使用可能であるため、待機時間がない。
【００６０】
一実施形態によると、障害回復時間を更に節約するために、ネットワーク７は、標準的なＪＯＩＮパケット処理方法により生じる収束遅延を回避するために単純な保護モードで動作される。保護モードにおいて、各ネットワーク１に対して、対応する１次ツリー及びバックアップツリーの双方が事前に構築され、マルチキャストグループに参加するルータ（又は他の何らかのネットワークノード）は双方のツリーに沿ってＪＯＩＮパケットを送信する。
【００６１】
２次ツリーは、共通ソースネットワークノードにより１次ツリーに沿って送信されたトラフィックが有する送信元アドレス（１次ＩＰ送信元アドレス）と異なる送信元アドレス（２次ＩＰ送信元アドレス）を共通ソースネットワークノード４により２次ツリーに沿って送信されたトラフィックが有するように構成される。そのようなツリーを（Ｓ，Ｇ）ツリーとも呼ぶ。（基本的な）ＰＩＭ（ＩＰマルチキャスト）は、２種類のツリー、すなわち（＊，Ｇ）ツリー及び（Ｓ，Ｇ）ツリーを使用できる。この場合、Ｓは送信元アドレスを意味し、Ｇはグループアドレスを意味する（後者はＩＰパケットの宛先アドレスであるが、マルチキャストの場合は単一の宛先が存在せずにグループが存在するため、この名称が使用される）。ルータ（ネットワークノード１の一実施形態）がマルチキャストパケットを取得する場合、これは自身のデータベースにおいて送信元アドレス及びグループアドレスの双方が一致する（Ｓ，Ｇ）エントリを見つけようとする。そのようなエントリを見つけた場合、ルータは当該エントリに対してパケットを転送する。そのようなエントリが存在しない場合、ルータは（＊，Ｇ）エントリを見つけようとする。この場合、「＊」は全ての残りの送信元に一致することを意味する。そのような（＊，Ｇ）ツリーはランデブーポイントを根とし、当該ツリーに沿って転送されたパケットは、ユニキャスト転送を用いて最初にランデブーポイントに送信される（例えば、基本的なＰＩＭのみが使用可能である場合）。
【００６２】
このように、１次トラフィック及びバックアップトラフィックは互いに容易に区別可能である。障害がない状況において、共通ソースネットワークノード４は１次ツリーのみに沿ってトラフィックを送信する必要がある。しかし、障害が存在する場合、トラフィックを失った宛先はそのことを２次ツリーに沿って即座に示し、２次ツリーに沿うトラフィックを更に起動する。一実施形態によると、共通ソースネットワークノード４の転送プレーンはそのような起動パケットを即座に処理でき、障害迂回時間が短縮される。
【００６３】
単純な保護モードにおいて、１次ツリー及び２次ツリーの双方からトラフィックを取得する複数のネットワークノード１が存在する場合がある。この追加負荷は、復元により新しいトポロジに従ってネットワーク７が再構成される短時間しか存在しないが、特定の実現例ではこの追加負荷を回避することが望まれる。
【００６４】
追加負荷を回避するために、ネットワーク７は高度な保護モードで動作される。高度な保護モードにおいて、２次ツリーはデータプレーンにおいてインストール（構築）されるだけで、有効ではない。障害の場合、２次ツリーを起動することができる（例えば、２次ツリーに沿って上向きに送信される単一パケットを用いて）。各データプレーン要素（ネットワークノード１）は、ＪＯＩＮメッセージの更に複雑な処理による遅延を伴わずに２次ツリーのブロックを即座に除去できる。当然、そのような技術は、送信元ネットワークノード４に加えて、２次パスに沿って分布する全てのネットワークノード１に沿うデータプレーン処理を必要とする。
【００６５】
双方の保護モードにより、高速再ルーティング技術の一般的な条件である５０ｍｓ以下の期間で障害迂回を実行できる。
【００６６】
共通ソースネットワークノード４からマルチキャストコンテンツを受信するマルチキャストグループに参加するために、ネットワークノード１は共通ソースネットワークノード４に登録するか又は関連付けられる必要がある。一実施形態によると、マルチキャストグループへの参加はＰＩＭ−ＳＭと同様に行われる。共通ソースネットワークノードに到達するために最短パスツリーの代わりに冗長性ネットワークツリー対の１次冗長性ツリーが使用される点のみが異なる。すなわち、ＪＯＩＮメッセージは、単純なＰＩＭのように（逆）最短パスに沿ってルーティングされるのではなく、計算された冗長性ツリー（例えば、ＭＲＴ）対の一方である１次ツリーに沿ってルーティングされる。計算されたネットワークツリー対の各ネットワークツリーが１次ツリーとして選択されてもよいが、この選択は、各ネットワークノード１において、計算されたネットワークツリー対のうちの同一のツリーが１次ネットワークツリー及び２次ネットワークツリーとして選択される点において一貫性を有する。
【００６７】
ＪＯＩＮパケットをルーティングするために使用されるＭＲＩＢテーブルは、それに列挙されるルーティングパスが従来の手法において一般的であるように逆ユニキャスト最短パスを反映するのではなく、冗長性ツリー（１次ツリー及び２次ツリー）を反映するように構築される。例えば図７に示す実施形態において、ネットワークノードｆは、パスｆ−ｃ−ｂ−ａ−ｒ（ネットワークノードｆに対する第１パス）を使用することにより、共通ソースネットワークノードｒにより配信されるマルチキャストコンテンツに参加する。
【００６８】
１次／２次冗長性ツリーに沿う一貫性のあるパケット転送を保証するために、一般に、全く同一の２つの１次／２次冗長性ツリーが各ネットワークノードにおいて計算される必要がある。例えば１次／２次冗長性ツリーを計算するために、バックグラウンドで実行中であり且つトポロジ全体を探すリンク状態ルーティング機構（ＯＳＰＦ又はＩＳ−ＩＳ等）を使用することができる（例えばアルゴリズムがタイブレークを必要とする場合、可能なルータＩＤのうちで最小のＩＤを有するノードを常に選択する）。冗長性ツリー対の計算は、最短パスを検索する場合とほぼ同一の複雑さで実行可能である。例えばＧａｂｏｒ  Ｅｎｙｅｄｉ、Ｇａｂｏｒ  Ｒｅｔｖａｒｉ、Ａｎｄｒａｓ  Ｃｓａｓｚａｒ、「Ｏｎ  Ｆｉｎｄｉｎｇ  Ｍａｘｉｍａｌｌｙ  Ｒｅｄｕｎｄａｎｔ  Ｔｒｅｅｓ  ｉｎ  Ｓｔｒｉｃｔｌｙ  Ｌｉｎｅａｒ  Ｔｉｍｅ」、ＩＥＥＥ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｃｏｍｐｕｔｅｒｓ  ａｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、ＩＳＣＣ、Ｓｏｕｓｓｅ、Ｔｕｎｉｓｉａ、２００９年７月を参照。
【００６９】
障害が発生する場合、これは検出される必要があり、再ルーティング処理が実行される必要がある。
【００７０】
共通ソースネットワークノード４から宛先ネットワークノード１へのパスに沿って障害が存在することの検出は、パスの一部であるラストホップルータによりｆａｓｔ  ｈｅｌｌｏ−ｌｉｋｅプロトコルを使用して実現される。例えば小さい「ハートビート」パケット（又は、更に一般的にハートビート信号）が共通ソースネットワークノード４から宛先ネットワークノード１に一定の速度で送信される。これらのパケットは、マルチキャストデータストリーム自体と同一のマルチキャスト宛先アドレスを使用して転送される（マルチキャストツリーに沿って）。そのようなハートビートの損失は、２次ツリーへの変更が必要であることを示す。
【００７１】
通常、ＯＳＰＦ、ＩＳ−ＩＳ又はＢＦＤにおいて使用されるようなＨｅｌｌｏ−ｌｉｋｅプロトコルは、ハートビートパケットが事前に設定された時間間隔内に受信されなかった場合に障害が存在すると判断する。例えばハートビートパケットが共通ソースネットワークノード４から宛先ネットワークノード１に５ｍｓ間隔で送信される場合であってラストホップルータが直近１５ｍｓにハートビートを受信しなかった場合、ラストホップルータは１次ツリーに障害が発生したと判断し、２次ツリーを介する再接続を開始する。ＯＳＰＦ、ＩＳ−ＩＳ又はＢＦＤにより使用される双方向に送信されるハートビートパケットと異なり、一実施形態によると、ハートビートパケットは一方向のみに送信される（通常、送信元ネットワークノード４は障害が発生したことを自身で学習しない）。この場合、ハートビートはマルチキャスト共通ソースネットワークノード４から宛先に送信されるにすぎない。
【００７２】
あるいは、ネットワーク７において常に大量のマルチキャストトラフィックが存在し、これが障害の不在をシグナリングする場合、ハートビートデータパケットは使用されない。その場合、トラフィックのパケットがハートビートとして使用される。ハートビートは、マルチキャストグループに送信された何らかのパケットの受信を意味する。
【００７３】
以下において、回復モードにおける再ルーティング機構を説明する。
【００７４】
回復モードにおいて、ラストホップネットワークノード１（例えば、ルータ）は、ハートビートパケットが予想通り受信されないことを検出するとすぐに、１次ツリーに沿うパスが切断したと仮定する。ネットワーク７を２つのネットワークに分割しない単一障害（ノード、リンク又は単一のＳＲＬＧ）が発生したと仮定すると、冗長性ツリー（ＭＲＴ）対の他方のツリーに沿うパスは正常である。このように、ユニキャストの収束を待つ必要がなく（ＰＩＭ−ＳＭはその必要がある）、宛先ネットワークノード１は事前に計算された２次ツリーに沿ってＪＯＩＮパケットを即座に送信できる。単純なＪＯＩＮパケットは容易に処理可能であるため、最適化された実現例を用いる場合、この再参加には過度に長い時間がかからない。すなわち、迅速な回復が保証される。この機構を図８に示す。ステップＳ１において、通常の動作ではシステムは障害がない状態である。ステップＳ２において、ハートビートが損失した（共通ソースネットワークノードに登録されたネットワークノードにおいてハートビートパケットが受信されない）場合、ＪＯＩＮメッセージが２次ツリーを介して共通ソースネットワークノードに送信される。ステップＳ３において、２次ツリーを介する共通ソースネットワークノード４へのＪＯＩＮメッセージの送信が成功したかが判定される。成功したと判定される場合、ステップＳ５において、ハートビートパケットが２次ツリーを介してネットワークノード４に送信され、ステップＳ６に示す単一障害状態に到達する。成功しなかったと判定される場合、示すようにステップＳ４において多重障害状態に到達する。
【００７５】
以下において、回復モードにおける全体的な障害迂回時間が十分に短縮されない場合に使用される単純な保護モードにおける再ルーティング機構を説明する。
【００７６】
例えば宛先ネットワークノード１から共通ソースネットワークノード４にルーティングされるメッセージ（ＪＯＩＮメッセージ又はＰＲＵＮＥメッセージ等）において新規のフラグを使用するか（例えば、０が１次ツリーを意味し且つ１が２次ツリーを意味するＴｒｅｅＩＤフラグ）、あるいは例えば他の場合ならＪＯＩＮメッセージと同一である新しい種類のＰＩＭメッセージを使用することにより、ネットワークツリー対の２つのネットワークツリーは区別される。
【００７７】
これらの手法はいずれも対応する通信プロトコルの変更を必要とするため、更なる手法が使用されてもよい。すなわち、保護送信元及びランデブーポイントの各々に追加のＩＰアドレスが割り当てられてもよい。保護送信元は、トラフィックが保護される送信元ノード４（マルチキャストツリーを有する）を意味する。マルチキャスト通信ネットワーク７の全てのマルチキャストツリーを保護する必要はないが、マルチキャストツリーが保護される場合、ＪＯＩＮメッセージはＭＲＴの双方に沿って送信される必要がある。そのため、これらのネットワークノードは２つのＩＰアドレスを有する必要があるが（プロトコルの変更が回避される場合）、保護される必要のないマルチキャスト送信元は１つのＩＰアドレスのみを有する。この追加のアドレスにより、メッセージの特別なルーティングが可能になり、すなわち、ツリー対の１次ツリー又は２次ツリーに沿ってツリーの上向きにメッセージを選択転送できる。追加のＩＰアドレスは通常は自律システム（ＡＳ）の外部では不要であるため、共通ソースネットワークノード４又は他のノードの各々にそのようなＩＰアドレスを割り当てることは容易である。そのため、プライベートアドレス空間の要素すら使用できる（例えば、１９２．１６８．０．０／１６又は１０．０．０．０／８）。前述のように、異なるＩＰアドレスを使用することは、ツリー対の１次ツリー又は２次ツリーに沿ってツリーの上向きにメッセージ（ユニキャスト制御メッセージ）を選択転送するために望ましい。共通ソースネットワークノード４から下向きにマルチキャストコンテンツを転送する場合、マルチキャストグループに対して単一のマルチキャストＩＰアドレスで十分である。
【００７８】
図９及び図１０は、宛先ネットワークノード１から共通ソースネットワークノード４までのユニキャスト制御メッセージ（ＪＯＩＮメッセージ又はＰＲＵＮＥメッセージ等）のルーティングがＭＲＩＢテーブルを使用して処理される方法の例を示す。
【００７９】
図９において、従来の手法を示す。ネットワークノードにおいて、テーブル９０が格納される。通常、エントリ９１は逆最短パスを表し、ユニキャストルーティング機構に基づいて導出される。例えばメッセージがネットワークノード１から「Ｓ１」で示す共通ソースネットワークノード４に送信される必要のある場合、ネットワークノード１はエントリ「ＮｅｘｔＨｏｐ１」で示すネットワークノード１にユニキャスト制御メッセージをルーティングする。このパスをブロックするネットワーク障害の場合、即座に反応できない。
【００８０】
それに対して、図１０において一実施形態を示す。宛先ネットワークノード１において、テーブル１００が格納される。エントリ１０１は１次ツリーを介する異なる共通ソースネットワークノード４への第１パスを表し、エントリ１０２は障害の場合に使用される２次ツリーを介する共通ソースネットワークノード４への第２パスを表す。例えば障害がない状態において、宛先ネットワークノード１から「Ｓ１」で示す共通ソースネットワークノード４に送信される必要のあるユニキャスト制御メッセージは、エントリ「ＮｅｘｔＨｏｐ１」で示すネットワークノードにルーティングされる（第１パス）。このパスをブロックするネットワーク障害の場合、ネットワークノード１から「Ｓ１」で示す共通ソースネットワークノード４に送信される必要のあるユニキャスト制御メッセージはエントリ「ＮｅｘｔＨｏｐ２」で示すネットワークノードにルーティングされる（第２パス）。
【００８１】
また、デフォルトツリー（１次ツリー）に沿って送信されるパケットとバックアップツリー（２次ツリー）に沿って転送されるパケットとを区別しないと転送ループが形成されるため、これらのパケットを区別することが望ましい。パケットは送信元ＩＰアドレスフィールドにバックアップＩＰを有する限りバックアップ（２次）ツリーに属するインタフェースを介して送信されるため、上述のように各保護送信元に２つのＩＰアドレスを割り当てる場合、区別は容易に実現される。マルチキャスト転送が通常はグループアドレス及び送信元アドレスの双方に基づくため、この解決策は転送プレーンにおける変更が不要である。また、これはＰＩＭ−ＳＭの自然な挙動である。（Ｓ１，Ｇ１）ツリーへの参加は（Ｓ２，Ｇ１）ツリーと異なるマルチキャストツリーを表すため、異なるマルチキャスト転送エントリが（Ｓ１，Ｇ１）及び（Ｓ１Ｂａｃｋｕｐ，Ｇ１）に対してインストールされる。前述のように、ネットワークノード１におけるマルチキャスト転送データベースは（Ｓ，Ｇ）エントリ及び（＊，Ｇ）エントリを含む。（Ｓ１，Ｇ１）エントリ及び（Ｓ２，Ｇ１）エントリが使用可能である場合、同一の宛先アドレス（グループアドレス）を有するＩＰデータパケットはそれらが含む送信元アドレスに依存して異なる方法で転送される。送信元アドレスがＳ１に一致する場合は第１のエントリが使用され、送信元アドレスがＳ２に一致する場合は第２のエントリが使用される。それらのどちらにも一致しない場合、（＊，Ｇ１）エントリが存在する場合はＩＰデータパケットは（＊，Ｇ１）エントリを使用し、一致するエントリが全く見つからない場合はＩＰデータパケットは削除される。
【００８２】
尚、追加のＩＰアドレスはＩＰネットワークの場合にのみ使用される。一般に、パケットの転送先を記述する「ラベル」が使用され、２つのツリーを記述するために宛先毎に２つのラベルが使用される。
【００８３】
ＩＰネットワークが使用される場合、ラベルは送信元及びグループの（Ｓ，Ｇ）対であり、２つのラベルを取得するために、２つの異なるＩＰアドレスが送信元に割り当てられる（２つの異なるＳが選択される）。あるいは、２つの異なるＧを２つのツリーに割り当てることも可能である。更に、例えばｍＬＤＰが使用される場合、そのようなアドレスは存在せずにラベルのみが存在する。従って、２つのラベルは各ノードにおいてツリーにローカルに割り当てられる（ＭＰＬＳはグローバルラベルを使用しないが、パケットを転送する前にそれらを交換する）。
【００８４】
共通ソースネットワークノード４におけるアドレス変換が使用されてもよい。アドレス変換に関連する追加負荷を回避する場合、データパケットの入力インタフェースが考慮される。入力インタフェースは１つのネットワークツリーのみに属するため、ネットワークツリーを判定できる。入力インタフェースが逆パス転送（ＲＰＦ）チェックのために各マルチキャストルーティングエントリに対して既に考慮されている場合、別のインタフェースＩＤを格納することが可能であり、データパケットが受信されたツリーの識別は単純な比較を用いて実現可能である。更に、インタフェースリストは出力インタフェースに対するエントリ毎に更に提供（例えば、格納）されてもよく、これにより、バックアップツリー（２次ツリー）のインタフェースを当該リストの末尾に単純に追加することができる。バックアップリストの先頭が既知である場合、それらのインタフェースを列挙することは容易である。
【００８５】
本実施形態又は別の実施形態において、切断辺（共通ソースネットワークノードに向かう唯一の接続性を提供するリンク）がネットワーク７内に存在するコーナーケースが存在する場合があり、当該リンクに沿ってパケットを受信するノード１は１次ツリーが使用されたか又は２次ツリーが使用されたかを判定できない。この例を図１２に示す。以下に説明する切断辺の処理の欠点がオペレータにとって許容できないものである場合、ＩＰレベルの切断辺は下層のネットワーク層（イーサネットＶＬＡＮ、２つのＭＰＬＳ  ＳＬＰ又は光学光路）により容易に除去可能である。
【００８６】
図１２に示す実施形態において、切断辺がネットワーク１２００内に存在する。共通ソースネットワークノードｓはネットワークノードｘを有する２つのエッジが接続された構成要素内に存在し、他方の構成要素はネットワークノードｙを介して接続する。
【００８７】
図１２に示す実施形態において、ｓからネットワークノードｘを切り離す障害が存在する場合、他方の構成要素内の全ての宛先がそれを検出し、バックアップツリー（必ずリンクｘ−ｙを再利用する）を使用して再参加する。しかし、他方の構成要素において障害が存在した場合、ノードｘはネットワークツリーに沿って各パケットを受信する。双方のネットワークツリーのトラフィックをリンクｘ−ｙに転送した結果、ネットワークノードｙ（及びネットワークノードｙからトラフィックを受信する全てのネットワークノード）においてパケットが重複する。これは回避されるべきである。この種の重複は各切断辺において繰り返され、それによりトラフィックが切断辺の数に対して指数関数的に増加する。ネットワークノードｘがハートビートの損失を検出せず（中間ネットワークノードであるため）且つ障害が存在する場合でもトラフィックが切断辺を通過する必要があるため、２次ネットワークツリーのトラフィックのみが切断辺を通って送信される。いくつかのネットワークノードが２次ツリーに沿うネットワークノードｙとの接続を失う場合があるため、当然、ネットワークノードｙにおいて受信されたトラフィックは全ての有効リンク（１次ツリー及びバックアップツリーの双方における）に沿って転送される必要がある。従って、いくつかの宛先が一部のパケットを２回受信する場合があり（しかし、３回以上受信しない）、それらはアプリケーションにより処理される（例えば、専用の廃棄動作により）。
【００８８】
ネットワーク７内に切断辺を有する別の影響は、ネットワークツリーのトラフィックのみが転送される場合、障害がネットワークノードｙを含む構成要素内に存在する場合でも全てのネットワークノードがハートビートを損失することを意味することである。しかし、ネットワークノードは最小限のトラフィック中断で即座に保護パスに切り替わるため、これは通常は重大な問題ではない。
【００８９】
前述のように、回復モードにおいて、２次ツリーは事前に計算されるが事前に構築されない。いくつかの宛先ネットワークノード１（ルータ等）に対して、制御プレーンが関係する必要があるため、マルチキャストツリーを構築するＪＯＩＮパケット等のメッセージパケットの処理時間が過度に長い場合がある。このように、マルチキャストルーティングの収束を待つ必要がない場合でも、障害後の再ルーティングは過度に長くなる。この問題を回避するために、１次パスに加えて２次パスが更に事前に構築される。すなわち、この問題を回避する１つの可能な方法は、双方のネットワークツリーを同時に構築することである（単純な保護モード）。例えばマルチキャストグループに参加するために待機している宛先は、双方のツリーにおいて通常のＪＯＩＮメッセージを送信する。１次ツリーに対するＪＯＩＮメッセージは共通ソースネットワークノード４の（「通常」、１次）アドレスに送信され（図１０のＳ１のように）、２次／バックアップツリーに対するＪＯＩＮメッセージは共通ソースネットワークノード４のバックアップ（２次）アドレスに送信される（図１０のＳ１Ｂａｃｋｕｐのように）。
【００９０】
障害が存在しない場合、共通ソースネットワークノード４は自身の１次アドレスのみを使用してトラフィックを送信する。従って、トラフィックは２次ツリー上に存在せず、すなわち、共通ソースネットワークノード４は自身の２次アドレスを使用してトラフィックを送信しない。
【００９１】
しかし、障害が発生する場合、宛先ネットワークノード１の形態であるエンドポイントはハートビートパケットの損失により障害を検出し、バックアップツリーに沿って共通ソースネットワークノード４に起動メッセージを送信する。起動メッセージを受信すると、共通ソースネットワークノード４は双方のツリーにおいて同一トラフィックの送信を開始する。
【００９２】
バックアップツリーのみの使用では不十分であり、トラフィックは双方のツリーに沿って同時に送信される必要がある。ＭＲＴは、各宛先ネットワークノード１がツリーの少なくとも一方に沿って到達可能な状態を維持することのみを保証し、それらが一般に第２のツリーに沿って到達可能な状態を維持することを保証しない。従って、障害により２次ツリーに沿う接続を失う宛先ネットワークノード１が存在する場合がある。その場合、１次ツリーに沿うそれらのパスは正常なままであり、それらのノード１は障害を検出すらしない。
【００９３】
本実施形態の利点は、ネットワークツリーに沿う宛先ネットワークノード１（ルータ等）の転送プレーンを変更する必要がないことである。しかし、共通ソースネットワークノード４の転送プレーンにおける何らかの変更は依然として行われる。共通ソースネットワークノード４は、バックアップツリーも使用される必要があることを示す起動パケットを処理する必要がある（十分に適切な反応時間を保証するために、制御プレーンは関係するべきでない）。
【００９４】
双方のツリーが使用される間、中間ネットワークノード１（ルータ等）は双方のネットワークツリーにおいてパケットを転送する必要がある。これは、ネットワークにおける追加トラフィックを意味する。この追加トラフィックが短時間しか生じない場合でも、グローバルＩＧＰ再構成が行われる間はこれにより輻輳が生じる。
【００９５】
障害中に双方のネットワークツリーに沿ってマルチキャストストリームのパケットを同時に送信することの欠点は、高度な保護モードを使用することにより軽減される。高度な保護モードにおいて、マルチキャストツリーを確立する場合、ネットワークノード１は従来のメッセージ（ＪＯＩＮパケット等）を使用して１次ツリーに参加し、２次ツリーに沿って特別なメッセージ（ＪＯＩＮパケット等）を使用する。２次ツリーに沿って特別なメッセージを使用することにより、その場合に処理するネットワークノード１に対して、パスの作成のみを行い（認証及び同様のタスクを行って）出力インタフェースを「ブロック」する必要があることがシグナリングされる。このブロックが有効である間、マルチキャストグループに属するパケットは当該インタフェースを介して送信されない。
【００９６】
特別なメッセージ（例えば、ＪＯＩＮパケット）は異なる方法で実現可能である。これは、内容はＪＯＩＮパケットと同一であるが違いが種類により反映される例えば「ブロックＪＯＩＮ」パケットである新規の種類のＰＩＭパケットであってもよく、あるいは、出力インタフェースが更なる通知までブロックされる必要があることを示すフラグを含む通常のＪＯＩＮメッセージであってもよい。
【００９７】
高度な保護モードにおいて、ラストホップネットワークノード１が１次ツリーにおけるハートビートの損失を検出する場合、２次ツリー上で上向きに起動パケットを送信し、それにより、起動パケットが送信される際に沿うパスにおいてブロックが除去される。ブロックは、例えばこの起動パケットが例えば図１０に示すＭＲＩＢテーブルのエントリに従って下流のノード（ルータ）から２次ツリーを介して受信される場合に除去される。
【００９８】
適切な反応時間を保証するために、起動メッセージは各ホップ（ネットワークノード１）においてデータプレーンで転送及び処理される。すなわち、データプレーン処理は、各マルチキャストグループに対するＭＦＩＢ内の「ブロック」フラグを「ブロック除去」に設定できる。更に、起動メッセージ（障害指示パケット）の迅速な転送を容易にするために、ユニキャストＦＩＢは２次ツリーに対するルーティング情報を含む必要がある。これを実現する最も容易な方法は、この場合も、保護された共通ソースネットワークノード４及びランデブーポイントの各々に対して追加のＩＰアドレスを使用し、アドレスが２次ツリー上で共通ソースネットワークノード４に向かうネクストホップ情報を反映する転送エントリを使用することである。
【００９９】
共通ソースネットワークノードが２次ＩＰアドレスを有さない場合、起動パケットは、２次ツリーに沿って転送するために認識され、１次ツリーに沿って転送するためにも認識される場合がある。全てのルータのデータプレーンが当該データパケットを処理する必要があるため、これは既に解決済みの問題である。
【０１００】
起動パケットは到達するルータ（ネットワークノード１）により転送及び処理される必要があるため特別なパケットであり、それらのルータは起動パケットのパスに沿ってブロックを除去できる。
【０１０１】
高度な保護モードの例を図１１に示す。図１１において、ネットワークノードｃが共通ソースネットワークノードｒに参加したいと仮定する。ＪＯＩＮパケットは、ＭＲＩＢテーブルに格納される（１次）パスｃ−ｂ−ａ−ｒを介して、ネットワークノードｃから１次ツリーに沿って共通ソースネットワークノードｒに送信される。更に、ブロックＪＯＩＮパケットは、２次ツリー、すなわちパスｃ−ｄ−ｅ−ｒに沿って送信される（例えば、ＰＩＭデーモンを使用して）。このブロックＪＯＩＮパケットは、共通ソースネットワークノードｒからネットワークノードｃにデータパケットを伝送しないように当該パスに沿うインタフェースをブロックさせる点で従来のＪＯＩＮパケットと異なる。
【０１０２】
障害がない状況の場合、共通ソースネットワークノードｒは、図７に示すように、ノードｃにマルチキャストコンテンツを転送するために１次ツリー（セグメント７０）を使用する。障害が存在して１次パスが切断する場合（例えば、ネットワークノードａに障害が発生すると仮定する）、ネットワークノードｃはハートビートの損失（制御データパケットの損失）を検出し、共通ソースネットワークノードｒの２次ＩＰ宛先アドレスを含む特別なユニキャスト起動パケットを送信する。この特別な宛先アドレスは、２次ツリーに沿う上向きのルーティングを反映するＦＩＢエントリに対応する。特別なユニキャスト起動パケットの転送により接続されたルータ（ネットワークノード）は当該パケットを転送した後に自身のインタフェースのブロックを除去し、代替（２次）パスが有効になる。すなわち、特別なユニキャスト起動パケットは、その送信先である共通ソースネットワークノードｒによってのみ処理されるのではなく、パスｃ−ｄ−ｅ−ｒに沿う全てのネットワークノードにより更に処理される。すなわち、パスに沿うルータはパケットを転送及び処理する。
【０１０３】
これらのパケットは、それらの送信先であるマルチキャスト共通ソースネットワークノードにより処理されるだけでなく、パスに沿う全てのネットワークノードにより更に処理される。パスに沿うルータはデータパケットを転送及び処理する。
【０１０４】
２次パスに沿うブロックは制御プレーンが関係せずに除去可能である必要があるため、それらのブロックを除去する特別なユニキャスト起動パケットは容易に認識可能である必要がある。従って、例えば（特別な）既知の宛先ポートアドレスを有するＵＤＰパケットが使用される。
【０１０５】
マルチキャストグループからの離脱は、ＰＲＵＮＥパケットが有効なツリーに沿って転送される点を除いて、従来のＰＩＭ−ＳＭと同一の方法で実行される（ブロックされたツリー及びブロックされていないツリーの双方に沿う）。更に、ＰＩＭと同様に何らかのタイムアウトが適用されることにより、接続を維持するＪＯＩＮパケットが時間内に受信されない場合にネットワークノードはツリーから除去される。
【０１０６】
単一障害の場合、接続を失った宛先は、２次ツリーを使用してマルチキャストグループに即座に再参加する。しかし、遅かれ早かれ、別の障害に備えて、障害により生じた新規のトポロジに対する新規の冗長性ツリー（ＭＲＴ）を計算するのが有利である。当然、この再構成が別のトラフィック停止を引き起こしてはならない。
【０１０７】
単一障害の後に再構成が行われる場合、接続は各宛先において安定する。これは、各宛先がデフォルトツリー又はバックアップツリーのいずれかに沿って送信元に接続されることを意味する。メーク・ビフォア・ブレークの原理が適用可能である。従って、全ての宛先が第１段階において全く問題なく他方のツリーを再構築することが可能である。各ネットワークノード１が第１段階の用意ができている場合（しばらく後に）、それらは新しく構築されたツリーに変更でき、必要に応じて他方のツリーを再構成できる（これは第２段階である）。第２段階の用意ができた場合、２次ツリーに沿ってトラフィックを受信するネットワークノード１は最終的にデフォルトのツリーに切り替え、再構成を終了する。
【０１０８】
リスク共有リンクグループ（ＳＲＬＧ）はリンクのセットであり、通常は共に障害が発生する。何らかの可能なＳＲＬＧに対する保護はＮＰ完全であるため、通常は冗長性ツリーと共に提供できない。しかし、最も一般的な２種類のＳＲＬＧは保護可能である。共通ルータに接続されたリンク（例えば、同一のラインカードに接続されたリンク）により形成される「ローカルＳＲＬＧ」の場合、それらをノード障害として処理できるため、実施形態は適している。
【０１０９】
ＬＡＮはＳＲＬＧの別の重要な送信元である。冗長性ツリー（ＭＲＴ）計算機構がＬＡＮを疑似ノードと見なす場合、それらは同様に容易に処理可能である。当然、ネクストホップが疑似ノードである場合、当該ノードをＩＰ転送テーブルに入力できない。この場合、ネクスト・ネクストホップが必要とされるが、ツリー全体が計算されるため、これは問題でない。
【０１１０】
実施形態から明らかになったように、本明細書において提示する技術は種々の利点を提供する。回復モードを使用する再構成は、ユニキャストルーティングの収束を待つ必要がないため、どんな単一障害の場合も従来のＰＩＭ−ＳＭを使用する場合よりはるかに高速である。保護モードを使用する場合、パスはいずれかの方法で事前に構築され、バックアップツリーの起動は高速再ルーティングの収束限界である５０４ｍｓをはるかに下回ると予想される。単純な保護モードは、中間ネットワークノードが新しい種類の起動パケットをサポートする必要がなく、ラストホップルータ及びファーストホップ（送信元）ルータのみがそれを認識する必要があるという更なる利点を有する。別の利点は、データプレーンにおける提案した機構の実現（低レベルのプログラミングを必要とするため、困難なタスクであると考えられることが多い）が非常に容易であることである。更に、同様の利点により、本明細書において提示する教示がｍＬＤＰにおいて実現されることが理解されるだろう。
【０１１１】
本明細書において提示する教示を例示的な実施形態に関して説明したが、この説明は例示するためのものに過ぎないことが理解されるべきである。従って、本発明は本明細書に添付する特許請求の範囲の範囲によってのみ限定されることが意図される。
【図１】
0005899305.tif 000002
【図２】
0005899305.tif 000003
【図３】
0005899305.tif 000004
【図４】
0005899305.tif 000005
【図５】
0005899305.tif 000006
【図６】
0005899305.tif 000007
【図７】
0005899305.tif 000008
【図８】
0005899305.tif 000009
【図９】
0005899305.tif 000010
【図１０】
0005899305.tif 000011
【図１１】
0005899305.tif 000012
【図１２】
0005899305.tif 000013