JP7536093B2

JP7536093B2 - パケット転送方法、第１のネットワークデバイス、および第１のデバイスグループ

Info

Publication number: JP7536093B2
Application number: JP2022527897A
Authority: JP
Inventors: ▲経▼▲栄▼ ▲謝▼
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-11-15
Filing date: 2020-09-23
Publication date: 2024-08-19
Anticipated expiration: 2040-09-23
Also published as: EP4044523B1; JP2023503825A; KR20220093155A; CN112822097B; EP4044523A4; US20220272028A1; WO2021093463A1; EP4044523A1; US12184536B2; CN112822097A

Description

本願は、参照によりその全体が本明細書に組み込まれている、２０１９年１１月１５日に出願された「ＭＵＬＴＩＣＡＳＴＰＡＣＫＥＴＦＯＲＷＡＲＤＩＮＧＭＥＴＨＯＤ，ＤＥＶＩＣＥ，ＡＮＤＳＹＳＴＥＭ」と題する中国特許出願第２０１９１１１１５９９８．９号の優先権を主張し、また２０２０年２月１１日に出願された「ＰＡＣＫＥＴＦＯＲＷＡＲＤＩＮＧＭＥＴＨＯＤ，ＦＩＲＳＴＮＥＴＷＯＲＫＤＥＶＩＣＥ，ＡＮＤＦＩＲＳＴＤＥＶＩＣＥＧＲＯＵＰ」と題する中国特許出願第２０２０１００８６６６６．９号の優先権を主張するものである。

本願は、ネットワーク通信分野に関し、さらに詳細には、パケット転送方法、第１のネットワークデバイス、および第１のデバイスグループに関する。

マルチキャスト（ｍｕｌｔｉｃａｓｔ）は、伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ、ＴＣＰ）／インターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）ネットワークにおいて、１つのマルチキャストアドレスを使用してデータが複数の受信側に同時に効率的に送信されるデータ伝送モードである。

マルチキャスト受信側は、ネットワークデバイスにマルチキャスト参加メッセージを送信することがあり、ネットワークデバイスは、ネットワークデバイスに接続されたルータを用いてそのマルチキャスト参加メッセージをマルチキャストソースに送信することがある。マルチキャストソースは、マルチキャストソースに接続されたルータを用いてマルチキャストトラフィックをそのネットワークデバイスに送信し、そのネットワークデバイスを用いてそのマルチキャストトラフィックをマルチキャスト受信側に転送する。従来の技術的解決策では、マルチキャストソースとマルチキャストソースに接続されたルータとの間の通信リンクが故障しているときには、マルチキャスト受信側に接続されたネットワークデバイスは、マルチキャスト参加メッセージを別のルータに送信する必要がある。これが、長いサービス回復時間につながる。

本願は、第１のデバイスグループ内の任意のネットワークデバイスが故障しているとき、またはそのネットワークデバイスに対応するリンクが故障しているときのサービス回復時間を短縮するために、パケット転送方法を提供する。

第１の態様によれば、パケット転送方法が提供される。この方法は、第１のネットワークデバイスが、マルチキャストソースデバイスによって送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信することを含み、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第１のマルチキャストパケットは、第１のデバイスグループ中の１つのネットワークデバイスによって第１のネットワークデバイスに転送される。第１のネットワークデバイスは、リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定し、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、第１のサブエントリは、第１のネットワークデバイスに第２のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示し、第２のサブエントリは、第１のネットワークデバイスに第３のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示する。第１のネットワークデバイスは、ＲＰＦエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信する。

この技術的解決策では、ネットワークデバイスは、ＲＰＦエントリに従って、第１のデバイスグループ内の任意のデバイスによって送信されたマルチキャストパケットを転送することがある。第１のデバイスグループ内の１つのネットワークデバイスが故障している、またはそのネットワークデバイスに対応するリンクが故障しているときには、ネットワークデバイスは、ＲＰＦエントリに従って、第１のデバイスグループ内の正常なリンクに対応する別のネットワークデバイスによって送達されたマルチキャストパケットを転送し得る。これにより、第１のデバイスグループ内の１つのネットワークデバイスが故障している、またはそのネットワークデバイスに対応するリンクが故障しているときに、サービス回復時間を短縮する。

可能な実装では、第１の通信リンクが正常な状態であるとき、第１のネットワークデバイスは、第１のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信する。

第１の通信リンクは、マルチキャストソースデバイスから第２のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。

別の可能な実装では、第２の通信リンクが正常な状態であるときには、第１のネットワークデバイスは、第１の通信リンクを介して転送された第１のマルチキャストパケットを受信し、ここで、第１の通信リンクのメトリックは、第２の通信リンクのメトリック未満である。

本願におけるリンクのメトリックは、リンクの品質またはリンクの帯域幅などであることがある。第２の通信リンクは、マルチキャストソースデバイスから第３のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。

別の可能な実装では、マルチキャストソースから第２のネットワークデバイスへのリンクのメトリックがマルチキャストソースから第３のネットワークデバイスへのリンクのメトリック未満であるときには、第２のネットワークデバイスが、マルチキャストソースから送信された第１のマルチキャストパケットを第１のネットワークデバイスに転送する。

別の可能な実装では、第１の通信リンクの優先度が第２の通信リンクの優先度より高いときには、第２のネットワークデバイスが、マルチキャストソースから送信された第１のマルチキャストパケットを第１のネットワークデバイスに転送する。

別の可能な実装では、第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときには、第１のネットワークデバイスは、第２のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信する。

別の可能な実装では、第１のネットワークデバイスがリバースパス転送ＲＰＦエントリに従って第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定する前に、この方法は、第１のネットワークデバイスが、第２のネットワークデバイスによって送信された第１の制御情報を受信することを含み、第１の制御情報は、第２の識別子を含み、第２の識別子は、第２のネットワークデバイスの識別子である。第１のネットワークデバイスは、第２の識別子に基づいて第１のサブエントリを生成し、第１のサブエントリは、第２の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応である。

第１のネットワークデバイスは、第３のネットワークデバイスによって送信された第２の制御情報を受信し、第２の制御情報は、第３の識別子を含み、第３の識別子は、第３のネットワークデバイスの識別子である。第１のネットワークデバイスは、第３の識別子に基づいて第２のサブエントリを生成し、第２のサブエントリは、第３の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応である。

別の可能な実装では、第２の識別子および第３の識別子は、インターネットプロトコルＩＰアドレス、またはインターネットプロトコルバージョン６ＩＰｖ６アドレスである。

別の可能な実装では、第１の制御情報は、第１デバイスグループ識別子をさらに含む。第２の制御情報は、第１デバイスグループ識別子をさらに含む。第１デバイスグループ識別子は、第１のデバイスグループの識別子である。この方法は、第１のネットワークデバイスが、第１デバイスグループ識別子に基づいてＲＰＦエントリを決定することをさらに含む。

具体的には、第１のネットワークデバイスは、第１デバイスグループ識別子に基づいて第１のサブエントリおよび第２のサブエントリをＲＰＦエントリであると決定する。

別の可能な実装では、第１デバイスグループ識別子は、ＩＰアドレス、ＩＰｖ６アドレス、または整数である。

別の可能な実装では、第１デバイスグループ識別子は、第２のネットワークデバイスおよび第３のネットワークデバイス上で構成される同じＩＰアドレスまたはエニーキャストＩＰアドレスであることがある。

別の可能な実装では、第２のネットワークデバイスが第１の制御メッセージを第１のネットワークデバイスに送信する、または第３のネットワークデバイスが第２の制御メッセージを第１のネットワークデバイスに送信する前に、この方法は、第１デバイスグループ識別子が第１のデバイスグループ内の第２のネットワークデバイスおよび第３のネットワークデバイス上で構成されることをさらに含む。

第２の態様によれば、パケット転送方法が提供される。この方法は、第１のデバイスグループ内の第２のネットワークデバイスが、第２の識別子および第１デバイスグループ識別子を第１のネットワークデバイスに送信することを含み、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第２の識別子は、第２のネットワークデバイスの識別子であり、第１デバイスグループ識別子は、第１のデバイスグループの識別子である。第１のデバイスグループ内の第３のネットワークデバイスは、第３の識別子および第１デバイスグループ識別子を第１のネットワークデバイスに送信する。

第３の識別子は、第３のネットワークデバイスの識別子であり、第２の識別子、第３の識別子、および第１デバイスグループ識別子は、第１のネットワークデバイスが第２の識別子、第３の識別子、および第１デバイスグループ識別子に基づいてリバースパス転送ＲＰＦエントリを生成するのをトリガするために使用され、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、第１のサブエントリは、第１のネットワークデバイスに第１のデバイスグループ内の第２のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示し、第２のサブエントリは、第１のネットワークデバイスに第１のデバイスグループ内の第３のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示する。

この方法は、第１のデバイスグループ内のネットワークデバイスが、マルチキャストソースデバイスによって送信された第１のマルチキャストパケットを受信することをさらに含む。第１のデバイスグループ内のネットワークデバイスは、第１のマルチキャストパケットを第１のネットワークデバイスに転送する。

別の可能な実装では、第１のデバイスグループ内のネットワークデバイスは、マルチキャストソースによって送信されたユニキャストパケットを受信し、第１のマルチキャストパケットは、ユニキャストパケットにカプセル化される。

別の可能な実装では、ユニキャストパケットの宛先アドレスは、第１デバイスグループ識別子もしくはエニーキャストＩＰアドレスであり、あるいは整数であることもある。

別の可能な実装では、第１の通信リンクは正常な状態である。第１の通信リンクは、マルチキャストソースデバイスから第２のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。第１のデバイスグループ内の第２のネットワークデバイスは、マルチキャストソースデバイスから受信された第１のマルチキャストパケットを第１のネットワークデバイスに転送する。

別の可能な実装では、第２の通信リンクは正常な状態である。第２の通信リンクは、マルチキャストソースデバイスから第３のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。第１の通信リンクのメトリックは、第２の通信リンクのメトリック未満である。

別の可能な実装では、第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときには、第１のデバイスグループ内の第３のネットワークデバイスは、マルチキャストソースデバイスから受信された第１のマルチキャストパケットを第１のネットワークデバイスに転送する。

第２の態様および第２の態様の任意の可能な実装の有利な効果は、第１の態様および第１の態様の任意の可能な実装の有利な効果に対応する。本明細書では、詳細について重ねて述べることはしない。

第３の態様によれば、第１のネットワークデバイスが提供される。この第１のネットワークデバイスは、
マルチキャストソースデバイスによって送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信するように構成された受信モジュールであって、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第１のマルチキャストパケットは、第１のデバイスグループ中の１つのネットワークデバイスによって第１のネットワークデバイスに転送される、受信モジュールと、
リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定するように構成された決定モジュールであって、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、第１のサブエントリは、第１のネットワークデバイスに第２のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示し、第２のサブエントリは、第１のネットワークデバイスに第３のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示する、決定モジュールと、
ＲＰＦエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成された送信モジュールと
を含む。

第１の通信リンクが正常な状態である。第１の通信リンクは、マルチキャストソースデバイスから第２のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。送信モジュールは、具体的には、第１のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成される。

第２の通信リンクが正常な状態である。第２の通信リンクは、マルチキャストソースデバイスから第３のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。受信モジュールは、具体的には、第１の通信リンクを介して転送された第１のマルチキャストパケットを受信するように構成される。第１の通信リンクのメトリックは、第２の通信リンクのメトリック未満である。

別の可能な実装では、第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときには、送信モジュールは、具体的には、第２のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成される。

別の可能な実装では、受信モジュールは、第２のネットワークデバイスによって送信された第１の制御情報を受信するようにさらに構成され、第１の制御情報は、第２の識別子を含み、第２の識別子は、第２のネットワークデバイスの識別子である。第１のネットワークデバイスは、第２の識別子に基づいて第１のサブエントリを生成するように構成された生成モジュールをさらに含み、第１のサブエントリは、第２の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応である。受信モジュールは、第３のネットワークデバイスによって送信された第２の制御情報を受信するようにさらに構成され、第２の制御情報は、第３の識別子を含み、第３の識別子は、第３のネットワークデバイスの識別子である。生成モジュールは、第３の識別子に基づいて第２のサブエントリを生成するようにさらに構成され、第２のサブエントリは、第３の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応である。

別の可能な実装では、第１の制御情報は、第１デバイスグループ識別子をさらに含む。第２の制御情報は、第１デバイスグループ識別子をさらに含む。第１デバイスグループ識別子は、第１のデバイスグループの識別子である。決定モジュールは、具体的には、第１デバイスグループ識別子に基づいてＲＰＦエントリを決定するように構成される。

第４の態様によれば、第１のデバイスグループが提供される。第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含む。第１のデバイスグループは、
第１のデバイスグループ内の第２のネットワークデバイスを用いて、第２の識別子および第１デバイスグループ識別子を第１のネットワークデバイスに送信するように構成された送信モジュールであって、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第２の識別子は、第２のネットワークデバイスの識別子であり、第１デバイスグループ識別子は、第１のデバイスグループの識別子である、送信モジュールを含み、
送信モジュールは、第１のデバイスグループ内の第３のネットワークデバイスを用いて、第３の識別子および第１デバイスグループ識別子を第１のネットワークデバイスに送信するようにさらに構成され、第３の識別子は、第３のネットワークデバイスの識別子であり、第２の識別子、第３の識別子、および第１デバイスグループ識別子は、第１のネットワークデバイスが第２の識別子、第３の識別子、および第１デバイスグループ識別子に基づいてリバースパス転送ＲＰＦエントリを生成するのをトリガするために使用され、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、第１のサブエントリは、第１のネットワークデバイスに第１のデバイスグループ内の第２のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示し、第２のサブエントリは、第１のネットワークデバイスに第１のデバイスグループ内の第３のネットワークデバイスによって送信された第１のマルチキャストパケットを転送するように指示する。

可能な実装では、第１のデバイスグループは、第１のデバイスグループ内のネットワークデバイスを用いて、マルチキャストソースデバイスによって送信された第１のマルチキャストパケットを受信するように構成された受信モジュールをさらに含み、送信モジュールは、第１のデバイスグループ内のネットワークデバイスを用いて、第１のマルチキャストパケットを第１のネットワークデバイスに転送するようにさらに構成される。

別の可能な実装では、送信モジュールは、具体的には、第１のデバイスグループ内のネットワークデバイスを用いて、マルチキャストソースによって送信されたユニキャストパケットを受信するように構成され、第１のマルチキャストパケットは、ユニキャストパケットにカプセル化される。

別の可能な実装では、第１の通信リンクは正常な状態である。第１の通信リンクは、マルチキャストソースデバイスから第２のネットワークデバイスへの、またそこから第１のネットワークデバイスへの通信リンクである。送信モジュールは、具体的には、第１のデバイスグループ内の第２のネットワークデバイスを用いて、マルチキャストソースデバイスから受信された第１のマルチキャストパケットを第１のネットワークデバイスに転送するように構成される。

別の可能な実装では、第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときには、送信モジュールは、具体的には、第１のデバイスグループ内の第３のネットワークデバイスを用いて、マルチキャストソースデバイスから受信された第１のマルチキャストパケットを第１のネットワークデバイスに転送するように構成される。

第５の態様によれば、第１のネットワークデバイスが提供される。第１のネットワークデバイスは、プロセッサ、メモリ、インタフェース、およびバスを含む。インタフェースは、ワイヤレスまたは有線で実装され得、具体的にはネットワークアダプタであることがある。プロセッサと、メモリと、インタフェースとは、バスを介して接続される。

インタフェースは、具体的には、伝送器および受信器を含むことがあり、第１のネットワークデバイスが前述の受信および送信を実施するように構成される。例えば、インタフェースは、マルチキャストソースデバイスから送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信することをサポートするように構成される。別の例では、インタフェースは、ＲＰＦエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信することをサポートするように構成される。別の例では、インタフェースは、第２のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信することをサポートするように構成される。

プロセッサは、前述の実施形態において第１のネットワークデバイスによって実行される処理を実行するように構成される。例えば、プロセッサは、リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定し、第２の識別子に基づいて第１のサブエントリを生成し、第３の識別子に基づいて第２のサブエントリを生成し、かつ／または本明細書に記載される技術のためのその他のプロセスを実行するように構成される。メモリは、オペレーティングシステムおよびアプリケーションを含み、プログラム、コード、または命令を記憶するように構成される。プログラム、コード、または命令を実行するときには、プロセッサまたはハードウェアデバイスは、方法の実施形態における第１のネットワークデバイスの処理プロセスを完了することがある。任意選択で、メモリは、読取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）およびランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）を含むことがある。ＲＯＭは、基本入出力システム（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ、ＢＩＯＳ）または埋込み型システムを含み、ＲＡＭは、アプリケーションおよびオペレーティングシステムを含む。第１のネットワークデバイスがランする必要があるときには、ＲＯＭに組み込まれたＢＩＯＳまたは埋込み型システムのブートローダが使用されて、システムをブートして始動させ、第１のネットワークデバイスをブートして通常のラン状態に入らせる。通常のラン状態に入った後で、第１のネットワークデバイスは、ＲＡＭ中のアプリケーションおよびオペレーティングシステムをランして、方法の実施形態における第１のネットワークデバイスの処理プロセスを完了する。

実際の適用では、第１のネットワークデバイスは、任意の数量のインタフェース、プロセッサ、またはメモリを含み得る。

第６の態様によれば、コンピュータ可読媒体が提供される。このコンピュータ可読媒体は、プログラムコードを記憶する。このコンピュータプログラムコードがコンピュータ上でランされたときに、コンピュータは、第１の態様または第１の態様の可能な実装のいずれか１つによる方法を実行することができるようになる。コンピュータ可読ストレージは、限定されるわけではないが、読取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブル読取り専用メモリ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）、およびハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つまたは複数を含む。

第７の態様によれば、コンピュータ可読媒体が提供される。このコンピュータ可読媒体は、プログラムコードを記憶する。このコンピュータプログラムコードがコンピュータ上でランされたときに、コンピュータは、第２の態様または第２の態様の可能な実装のいずれか１つによる方法を実行することができるようになる。コンピュータ可読媒体は、限定されるわけではないが、読取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブル読取り専用メモリ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）、およびハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つまたは複数を含む。

第８の態様によれば、コンピュータプログラム製品が提供される。このコンピュータプログラム製品は、コンピュータプログラムコードを含む。このコンピュータプログラムコードがコンピュータ上でランされたときに、コンピュータは、第１の態様または第１の態様の可能な実装のいずれか１つによる方法を実行することができるようになる。

第９の態様によれば、コンピュータプログラム製品が提供される。このコンピュータプログラム製品は、コンピュータプログラムコードを含む。このコンピュータプログラムコードがコンピュータ上でランされたときに、コンピュータは、第１の態様または第１の態様の可能な実装のいずれか１つによる方法を実行することができるようになる。

第１０の態様によれば、チップが提供される。このチップは、プロセッサおよびデータインタフェースを含む。プロセッサは、データインタフェースを用いてメモリに記憶された命令を読み取って、第１の態様または第１の態様の可能な実装のいずれか１つによる方法を実行する。具体的な実装プロセスでは、チップは、中央処理装置（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＣＰＵ）、マイクロコントローラユニット（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒｕｎｉｔ、ＭＣＵ）、マイクロプロセシングユニット（ｍｉｃｒｏｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＭＰＵ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、システムオンチップ（ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ、ＳｏＣ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ、ＦＰＧＡ）、またはプログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＰＬＤ）の形態で実装されることがある。

第１１の態様によれば、チップが提供される。このチップは、プロセッサおよびデータインタフェースを含む。プロセッサは、データインタフェースを用いてメモリに記憶された命令を読み取って、第２の態様または第２の態様の可能な実装のいずれか１つによる方法を実行する。具体的な実装プロセスでは、チップは、中央処理装置（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＣＰＵ）、マイクロコントローラユニット（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒｕｎｉｔ、ＭＣＵ）、マイクロプロセシングユニット（ｍｉｃｒｏｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＭＰＵ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、システムオンチップ（ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ、ＳｏＣ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ、ＦＰＧＡ）、またはプログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＰＬＤ）の形態で実装されることがある。

第１２の態様によれば、システムが提供される。このシステムは、第１のネットワークデバイスおよび第１のデバイスグループを含む。

図１は、本願が適用される可能な適用シナリオを示す概略図である。図２は、本願が適用される別の可能な適用シナリオを示す概略図である。図３は、本願の実施形態によるパケット転送方法を示す概略流れ図である。図４Ａは、本願の実施形態による別のパケット転送方法を示す概略流れ図である。図４Ｂは、本願の実施形態による別のパケット転送方法を示す概略流れ図である。図５Ａは、本願の実施形態による別のパケット転送方法を示す概略流れ図である。図５Ｂは、本願の実施形態による別のパケット転送方法を示す概略流れ図である。図６は、本願の実施形態による第１のネットワークデバイス６００の構造を示す概略図である。図７は、本願の実施形態による第１のデバイスグループ７００の構造を示す概略図である。図８は、本願の実施形態による第１のネットワークデバイス２０００のハードウェア構造を示す概略図である。図９は、本願の実施形態による別の第１のネットワークデバイス２１００のハードウェア構造を示す概略図である。

以下、添付の図面を参照して本願の技術的解決策について述べる。

マルチキャスト（ｍｕｌｔｉｃａｓｔ）は、伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ、ＴＣＰ）／インターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）ネットワークにおいて、１つのマルチキャストアドレスを使用してデータが複数の受信側に同時に効率的に送信されるデータ伝送モードである。マルチキャストソースは、ネットワーク内のリンクを通してマルチキャストグループ内のマルチキャストグループメンバにマルチキャストトラフィックを送信し、マルチキャストグループ内の各マルチキャストグループメンバは、マルチキャストトラフィックを受信することができる。マルチキャスト伝送モードは、マルチキャストソースとマルチキャストグループメンバとの間でポイントツーマルチポイントデータ接続を実施する。マルチキャストトラフィックは、各ネットワークリンク上で１回だけ伝送されればよく、マルチキャストトラフィックは、リンク上に分岐があるときのみ複製される。したがって、マルチキャスト伝送モードは、データ伝送効率を向上させ、バックボーンネットワーク上の輻輳の可能性を低減させる。

説明を容易にするために、以下、図１および図２を参照して、本願の実施形態が適用される適用シナリオについて詳細に述べる。

図１は、本願の実施形態が適用される可能性があるマルチキャストシナリオを示す概略図である。図１に示すように、このシナリオは、マルチキャスト受信側（ｒｅｃｅｉｖｅ、ＲＣＶ）およびマルチキャストソース（ｓｏｕｒｃｅ、ＳＲＣ）を含むことがある。

可能な実装では、マルチキャストソースは、少なくとも２つのルータ（ｒｏｕｔｅｒ、Ｒ）に直接接続される可能性があり、これは、マルチキャストソースのその少なくとも２つのルータに対するデュアルホーミング（ｄｕａｌｈｏｍｉｎｇ）と呼ばれることがある。マルチキャストソースは、２つのルータに直接接続されることもあるし、３つ以上のルータに直接接続されることもある。これは、本願では特に限定されない。

別の可能な実装では、任意選択で、カスタマエッジ（ｃｕｓｔｏｍｅｒｅｄｇｅ、ＣＥ）スイッチが図１に含まれることもあり、マルチキャストソースは、少なくとも２つのＣＥスイッチを使用して上記の少なくとも２つのルータに別々に接続されることもある。

説明を容易にするために、図１における説明のための例として、２つのルータ（例えばＲ１およびＲ２）が使用されている。

図２は、本願の実施形態において提供される別の可能なマルチキャストシナリオを示す概略図である。図２に示すように、このシナリオでは、マルチキャストソースは、スイッチ（ｓｗｉｔｃｈ、ＳＷ）、ＣＥ１、およびＣＥ２を使用して少なくとも２つのルータに別々に接続される。

２つのルータ（例えばＲ１およびＲ２）は、図２では例として使用されている。マルチキャストソースは、ＳＷおよびＣＥ１を使用してＲ１に接続され、ＳＷおよびＣＥ２を使用してＲ２に接続される。

本願の本実施形態では、マルチキャスト受信側は、マルチキャスト宛先デバイスと呼ばれることもあり、複数のマルチキャスト受信側があることもある。説明を容易にするために、図１または図２のシナリオでは、２つのマルチキャスト受信側、例えばＨ１およびＨ２がある。Ｈ１／Ｈ２は、ルータＬ１／Ｌ２にそれぞれ接続され、ルータＬ１／Ｌ２は、Ｐ１／Ｐ２を使用してＲ１およびＲ２にそれぞれ接続される。

Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークは、コア（Ｃｏｒｅ）ネットワークとも呼ばれ、例えばオペレータによって提供されるネットワークである。ネットワークは、本願の本実施形態では特に限定されず、マルチキャスト仮想プライベートネットワーク（ｍｕｌｔｉｃａｓｔｖｉｒｔｕａｌｐｒｉｖａｔｅｎｅｔｗｏｒｋ、ＭＶＰＮ）であってもよいし、イーサネット仮想プライベートネットワーク（Ｅｔｈｅｒｎｅｔｖｉｒｔｕａｌｐｒｉｖａｔｅｎｅｔｗｏｒｋ、ＥＶＰＮ）であってもよい。Ｌ１／Ｌ２をＨ１／Ｈ２に接続するために使用されるインタフェース、およびＲ１／Ｒ２をマルチキャストソースに接続するために使用されるインタフェースは、ネットワークにおけるユーザ側インタフェース（プライベートネットワーク側インタフェースまたはプライベートネットワークインタフェースとも呼ばれる）である。Ｒ１／Ｒ２をＰ１／Ｐ２に接続するために使用されるインタフェース、およびＬ１／Ｌ２をＰ１／Ｐ２に接続するために使用されるインタフェースは、ネットワークにおけるネットワーク側インタフェース（パブリックネットワーク側インタフェースまたはパブリックネットワークインタフェースとも呼ばれる）である。

マルチキャスト受信側（例えばＨ１／Ｈ２）は、マルチキャスト受信側に接続されたＬ１／Ｌ２にマルチキャスト参加メッセージを送信することがある。マルチキャスト参加メッセージは、本願では特に限定されず、インターネットグループ管理プロトコル（Ｉｎｔｅｒｎｅｔｇｒｏｕｐｍａｎａｇｅｍｅｎｔｐｒｏｔｏｃｏｌ、ＩＧＭＰ）メッセージであってもよいし、マルチキャストリスナ発見（ｍｕｌｔｉｃａｓｔｌｉｓｔｅｎｅｒｄｉｓｃｏｖｅｒｙ、ＭＬＤ）メッセージであってもよい。マルチキャストメッセージを受信した後で、Ｌ１／Ｌ２は、ボーダゲートウェイプロトコル（ｂｏｒｄｅｒｇａｔｅｗａｙｐｒｏｔｏｃｏｌ、ＢＧＰ）メッセージを使用して、マルチキャストソース側のＲ１／Ｒ２にマルチキャスト参加メッセージを送信することがある。ＢＧＰメッセージは、ＢＧＰＭＶＰＮルートメッセージであることもあるし、ＢＧＰＥＶＰＮルートメッセージであることもある。例えば、ＢＧＰＭＶＰＮルートメッセージは、Ｃマルチキャストルートメッセージであることもあるし、リーフＡ－Ｄルートメッセージであることもある。マルチキャスト参加メッセージを受信した後で、マルチキャストソースは、マルチキャストパケットをマルチキャスト受信側に送信することがある。

本願では、マルチキャスト受信側によって送信されるマルチキャスト参加メッセージは、Ｓ１Ｇ１を含むことがあることを理解されたい。ここで、Ｓ１は、要求されたマルチキャストパケットのマルチキャストソース（ｓｏｕｒｃｅ、Ｓ）を示し、Ｇ１は、要求されたマルチキャストパケットのマルチキャストグループ（ｇｒｏｕｐ、Ｇ）を示す。マルチキャスト参加メッセージを受信した後で、マルチキャストソースは、マルチキャスト参加メッセージ中のマルチキャストパケットのＳ１Ｇ１に基づいてマルチキャスト受信側にマルチキャストパケットを送信することがある。

従来の技術的解決策では、Ｌ１が例として使用される。Ｓ１Ｇ１に関係するマルチキャスト参加をＨ１から受信した後で、Ｌ１は、マルチキャスト参加メッセージをＲ１に送信し、「バックアップ」表示情報を搬送するマルチキャスト参加をＲ２に送信する。Ｒ１およびＲ２がマルチキャストソースからマルチキャストパケットを受信した後で、Ｒ１は、マルチキャストパケットをＬ１に転送する。Ｒ１が故障しているときには、Ｌ１は「バックアップ」表示情報を搬送しないマルチキャスト参加をＲ２に送信するので、Ｒ２がマルチキャストパケットをＬ１に転送する。この解決策では、Ｒ１が故障しているときには、Ｌ１は依然としてマルチキャスト参加メッセージをＲ２に送信する必要がある。これが、長いサービス回復時間につながる。

本願の実施形態は、マルチキャストパケットを転送するデバイスグループ内のネットワークデバイスが故障しているときのサービス回復時間を短縮するための、パケット転送方法を提供する。以下、図３を参照して、このパケット転送方法について述べる。

図３は、本願の実施形態によるパケット転送方法を示す概略流れ図である。図３に示すように、この方法は、ステップ３１０から３３０を含むことがある。以下、ステップ３１０から３３０について別個に詳細に述べる。

ステップ３１０：第１のネットワークデバイスが、マルチキャストソースデバイスから送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信する。ここで、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第１のマルチキャストパケットは、第１のマルチキャストグループ中の１つのネットワークデバイスによって第１のネットワークデバイスに転送される。

本願の本実施形態では、第１のネットワークデバイスは、図１のＬ１／Ｌ２に対応し、第２のネットワークデバイスおよび第３のネットワークデバイスは、それぞれＲ１およびＲ２に対応する。Ｌ１／Ｌ２は、マルチキャストソースデバイスによって送信され、Ｒ１／Ｒ２の任意のネットワークデバイスを用いて送信された第１のマルチキャストパケットを受信することがある。

ステップ３２０：第１のネットワークデバイスが、リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定する。

リバースパス転送（ｒｅｖｅｒｓｅｐａｔｈｆｏｒｗａｒｄｉｎｇ、ＲＰＦ）は、マルチキャストデータパケットの複数回の転送を防止する技術であることを理解されたい。ネットワークデバイスは、ＲＰＦエントリに従って、アップストリームマルチキャストホップ（ｕｐｓｔｒｅａｍｍｕｌｔｉｃａｓｔｈｏｐ、ＵＭＨ）から受信されたマルチキャストパケットを転送することがある。

本願の本実施形態では、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含む。第１のサブエントリは、第１のネットワークデバイスに、第２のネットワークデバイスから送信された第１のマルチキャストパケットを転送するように指示する。第２のサブエントリは、第１のネットワークデバイスに、第３のネットワークデバイスから送信された第１のマルチキャストパケットを転送するように指示する。

ステップ３３０：第１のネットワークデバイスが、ＲＰＦエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信する。

第１のネットワークデバイスは、ＲＰＦエントリに従って、第１のデバイスグループ内の任意のデバイスを使用して送信されたマルチキャストパケットを転送し得る。

この技術的解決策では、ネットワークデバイスは、ＲＰＦエントリに従って、第１のデバイスグループ内の任意のデバイスによって送信されたマルチキャストパケットを転送し得る。第１のデバイスグループ内の１つのネットワークデバイスが故障している、またはそのネットワークデバイスに対応するリンクが故障しているときには、そのネットワークデバイスは、ＲＰＦエントリに従って、第１のデバイスグループ内の正常なリンクに対応する別のネットワークデバイスによって送達されたマルチキャストパケットを転送し得る。これにより、マルチキャストパケットを転送するデバイスグループ内の１つのネットワークデバイスが故障しているとき、サービス回復時間を短縮する。

ＲＰＦエントリは、本願の本実施形態では特に限定されない。可能な実装では、ＲＰＦエントリ中の第１のサブエントリは、第２のネットワークデバイスの識別子（例えば第２のネットワークデバイスのＩＰアドレス）と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応であることがある。ＲＰＦエントリ中の第２のサブエントリは、第３のネットワークデバイスの識別子（例えば第３のネットワークデバイスのＩＰアドレス）と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応であることがある。別の可能な実装では、ＲＰＦエントリは、第１のデバイスグループの識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応、第２のデバイスグループの識別子と第１のデバイスグループの識別子との間の対応（第１のサブエントリ）、および第３のネットワークデバイスの識別子と第１のデバイスグループの識別子との間の対応（第２のサブエントリ）をさらに含むことがある。第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含む。

以下、図１に示す適用シナリオを使用して、図４Ａおよび図４Ｂの実施形態を参照して、本願の本実施形態で提供されるパケット転送方法の具体的な実装について詳細に述べる。

図４Ａおよび図４Ｂは、本願の実施形態による別のパケット転送方法を示す概略流れ図である。図４Ａおよび図４Ｂに示すように、この方法は、ステップ４１０から４７８を含むことがある。ステップ４１０から４７８について別個に詳細に述べる。

説明を容易にするために、図４Ａおよび図４Ｂでは、Ｌ１がＳ１Ｇ１マルチキャスト参加メッセージを受信する例を用いて説明が提供されることを理解されたい。

ステップ４１０：Ｒ１が、デバイス識別子をＬ１に送信する。

ステップ４１５：Ｒ２が、デバイス識別子をＬ１に送信する。

可能な実装では、本願の本実施形態では、Ｒ１／Ｒ２のデバイス識別子（例えばインターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）アドレス）が構成されることがある。Ｒ１／Ｒ２は、第１のデバイスグループとして使用されることがある。

例えば、Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークは、インターネットプロトコルバージョン４（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎ４、ＩＰｖ４）ネットワークである。Ｒ１およびＲ２上の構成は、以下の通りである。

Ｒ１上の構成では、「Ｉｐａｄｄｒ１９２．１６８．１．１０１」は、Ｒ１のインタフェースのＩＰアドレス１を示し、「Ｍｕｌｔｉｃａｓｔｍｖｐｎ－ｉｄ１９２．１６８．１．１０１」は、ＢＧＰＭＶＰＮにおけるｍｖｐｎ－ｉｄに基づいて指定されるＩＰアドレスが、ＭＶＰＮメッセージルートにおけるＲ１のＩＰアドレス１として使用されることを示す。Ｒ２上の構成では、「Ｉｐａｄｄｒ１９２．１６８．１．１０２３２」は、Ｒ２のインタフェースのＩＰアドレス２を示し、「Ｍｕｌｔｉｃａｓｔｍｖｐｎ－ｉｄ１９２．１６８．１．１０２」は、ＢＧＰＭＶＰＮにおけるｍｖｐｎ－ｉｄに基づいて指定されるＩＰアドレスが、ＭＶＰＮメッセージルートにおけるＲ２のＩＰアドレス２として使用されることを示す。

Ｒ１およびＲ２上で構成される「Ｉｐａｄｄｒ１９２．１６８．１．１００」は、第１のデバイスグループの識別子、すなわちＩＰアドレス０を示し、「Ａｎｙｃａｓｔ－ｒｐｆ１９２．１６８．１．１００」は、ＩＰアドレス０が、ＲＰＦチェック中に複数のアドレスのうちのいずれか１つを識別するために使用されることを示す。

「Ｉｐａｄｄｒ１９２．１６８．１．１００」は任意選択であることに留意されたい。換言すれば、ＲＰＦエントリがマルチキャストパケットと第１のデバイスグループの識別子との間の対応である場合に、「Ｉｐａｄｄｒ１９２．１６８．１．１００」はＲ１およびＲ２上で構成されることがある。

別の例では、Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークは、インターネットプロトコルバージョン６（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎ６、ＩＰｖ６）ネットワークである。Ｒ１およびＲ２上の構成は、以下の通りである。

Ｒ１上の構成では、「Ｉｐｖ６ａｄｄｒ２００１：ＤＢ１：：１０１」は、Ｒ１のインタフェースのＩＰｖ６アドレス１を示し、「Ｍｕｌｔｉｃａｓｔｍｖｐｎ－ｉｄ２００１：ＤＢ１：：１０１」は、ＢＧＰＭＶＰＮにおけるｍｖｐｎ－ｉｄに基づいて指定されるＩＰアドレスが、ＭＶＰＮメッセージルートにおけるＲ１のＩＰｖ６アドレス１として使用されることを示す。Ｒ２上の構成では、「Ｉｐｖ６ａｄｄｒ２００１：ＤＢ１：：１０２」は、Ｒ２のインタフェースのＩＰｖ６アドレス２を示し、「Ｍｕｌｔｉｃａｓｔｍｖｐｎ－ｉｄ２００１：ＤＢ１：：１０２」は、ＢＧＰＭＶＰＮにおけるｍｖｐｎ－ｉｄに基づいて指定されるＩＰアドレスが、ＭＶＰＮメッセージルートにおけるＲ２のＩＰｖ６アドレス２として使用されることを示す。

Ｒ１およびＲ２上で構成される「ＩＰｖ６ａｄｄｒ２００１：ＤＢ１：：１００」は、第１のデバイスグループの識別子、すなわちＩＰｖ６アドレス０を示し、「Ａｎｙｃａｓｔ－ｒｐｆ２００１：ＤＢ１：：１００」は、ＩＰｖ６アドレス０が、ＲＰＦチェック中に複数のアドレスのうちのいずれか１つを識別するために使用されることを示す。

「Ｉｐｖ６ａｄｄｒ２００１：ＤＢ１：：１００」は任意選択であることに留意されたい。換言すれば、ＲＰＦエントリがマルチキャストパケットと第１のデバイスグループの識別子との間の対応である場合に、「Ｉｐｖ６ａｄｄｒ２００１：ＤＢ１：：１００」はＲ１およびＲ２上で構成されることがある。

Ｒ１およびＲ２がデバイス識別子をＬ１に送信するための具体的な実装は複数ある。以下では、例としてＲ１を用いて、Ｒ１がＩＰアドレスをＬ１に送信するためのいくつかの可能な実装について詳細に述べる。

可能な実装では、Ｒ１は、アドバタイズされたＢＧＰ－ＭＶＰＮルートにおけるＩＰアドレス１を含むことがある。例えば、Ｒ１は、ＢＧＰ－ＭＶＰＮの包括的なプロバイダマルチキャストサービスインタフェースの自動発見（ｉｎｃｌｕｓｉｖｅｐｒｏｖｉｄｅｒｍｕｌｔｉｃａｓｔｓｅｒｖｉｃｅｉｎｔｅｒｆａｃｅａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、Ｉ－ＰＭＳＩＡ－Ｄ）ルートにおけるＩＰアドレス１を含むことがある。別の例では、Ｒ１は、ＢＧＰ－ＭＶＰＮの選択的なプロバイダマルチキャストサービスインタフェースの自動発見（ｓｅｌｅｃｔｉｖｅｐｒｏｖｉｄｅｒｍｕｌｔｉｃａｓｔｓｅｒｖｉｃｅｉｎｔｅｒｆａｃｅａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、Ｓ－ＰＭＳＩＡ－Ｄ）ルートにおけるＩＰアドレス１を含むことがある。任意選択で、Ｒ１は、アドバタイズされたＢＧＰ－ＭＶＰＮルートにおけるＩＰアドレス０を含むこともある。

具体的には、一例では、Ｒ１は、メッセージ１を用いてＩＰアドレス１およびＩＰアドレス０をＬ１に送信する。メッセージ１の可能な構造は、以下の通りである。
ｍｅｓｓａｇｅ１＝｛ＭＰ＿ＲＥＡＣＨ＿ＮＬＲＩａｔｔｒｉｂｕｔｅ＜Ｔｙｐｅ１，ＲＤ，ＩＰａｄｄｒｅｓｓ１＞，Ｅｘｔｅｎｄｅｄ＿Ｃｏｍｍｕｎｉｔｙａｔｔｒｉｂｕｔｅ＜Ｔｙｐｅ２，ＩＰａｄｄｒｅｓｓ０＞｝

Ｔｙｐｅ１は、Ｉ－ＰＭＳＩＡ－ＤルートのタイプまたはＳ－ＰＭＳＩＡ－Ｄルートのタイプを識別する。ＲＤは、異なるＶＰＮインスタンスを区別するルート識別子ｒｏｕｔｅ－ｄｉｓｔｉｎｇｕｉｓｈｅｒである。ＩＰアドレス１は、本実施形態では「１９２．１６８．１．１０１」である。Ｔｙｐｅ２は、ａｎｙｃａｓｔ－ｒｐｆアドレスオブジェクトを識別する。ＩＰアドレス０は、本実施形態では「１９２．１６８．１．１００」である。

同様に、Ｒ２は、ＢＧＰ－ＭＶＰＮＩ－ＰＭＳＩＡ－ＤルートまたはＢＧＰ－ＭＶＰＮＳ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス２を含むこともある。任意選択で、Ｒ２は、ＢＧＰ－ＭＶＰＮＩ－ＰＭＳＩＡ－ＤルートまたはＢＧＰ－ＭＶＰＮＳ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス０を含むこともある。詳細については、上記の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

別の可能な実装では、Ｒ１は、アドバタイズされたＢＧＰ－ＥＶＰＮルートにおけるＩＰアドレス１を含むことがある。例えば、Ｒ１は、ＢＧＰ－ＥＶＰＮの包括的なマルチキャストイーサネットタグルート（ｉｎｃｌｕｓｉｖｅｍｕｌｔｉｃａｓｔＥｔｈｅｒｎｅｔｔａｇｒｏｕｔｅ、ＩＭＥＴ）におけるＩＰアドレス１を含むことがある。別の例では、Ｒ１は、ＢＧＰ－ＥＶＰＮの選択的なプロバイダマルチキャストサービスインタフェースの自動発見（ｓｅｌｅｃｔｉｖｅｐｒｏｖｉｄｅｒｍｕｌｔｉｃａｓｔｓｅｒｖｉｃｅｉｎｔｅｒｆａｃｅａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、Ｓ－ＰＭＳＩＡ－Ｄ）ルートにおけるＩＰアドレス１を含むことがある。任意選択で、Ｒ１は、アドバタイズされたＢＧＰ－ＥＶＰＮルートにおけるＩＰアドレス０を含むこともある。

具体的には、一例では、メッセージ１の別の可能な構造は、以下の通りである。
ｍｅｓｓａｇｅ１＝｛ＭＰ＿ＲＥＡＣＨ＿ＮＬＲＩａｔｔｒｉｂｕｔｅ＜Ｔｙｐｅ１，ＲＤ，ＩＰａｄｄｒｅｓｓ１＞，Ｅｘｔｅｎｄｅｄ＿Ｃｏｍｍｕｎｉｔｙａｔｔｒｉｂｕｔｅ＜Ｔｙｐｅ２，ＩＰａｄｄｒｅｓｓ０＞｝

Ｔｙｐｅ１は、ＩＭＥＴルートのタイプまたはＳ－ＰＭＳＩＡ－Ｄルートのタイプを識別する。ＲＤは、異なるＶＰＮインスタンスを区別するルート識別子ｒｏｕｔｅ－ｄｉｓｔｉｎｇｕｉｓｈｅｒである。ＩＰアドレス１は、本実施形態では「１９２．１６８．１．１０１」である。Ｔｙｐｅ２は、ａｎｙｃａｓｔ－ｒｐｆアドレスオブジェクトを識別する。ＩＰアドレス０は、本実施形態では「１９２．１６８．１．１００」である。

同様に、Ｒ２は、ＢＧＰ－ＥＶＰＮＩＭＥＴルートまたはＢＧＰ－ＭＶＰＮＳ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス２を含むこともある。任意選択で、Ｒ２は、ＢＧＰ－ＥＶＰＮＩＭＥＴルートまたはＢＧＰ－ＭＶＰＮＳ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス０を含むこともある。詳細については、上記の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

ステップ４２０：Ｌ１が、Ｒ１／Ｒ２のデバイス識別子情報を記憶する。

Ｌ１は、Ｒ１およびＲ２からそれぞれ送信されたメッセージ１およびメッセージ２を受信することがある。メッセージは、ＢＧＰ－ＭＶＰＮルートメッセージ、例えばＩ－ＰＭＳＩＡ－ＤルートメッセージまたはＳ－ＰＭＳＩＡ－Ｄルートメッセージであってもよいし、ＢＧＰ－ＥＶＰＮルートメッセージ、例えばＩＭＥＴルートメッセージまたはＳ－ＰＭＳＩＡ－Ｄルートメッセージまたはであってもよい。

可能な実装では、Ｌ１によって受信されたメッセージ１がＩＰアドレス１を含み、メッセージ２がＩＰアドレス２を含む場合には、Ｌ１は、ＩＰアドレス１およびＩＰアドレス２を記憶することがある。

別の可能な実装では、Ｌ１によって受信されたメッセージ１がＩＰアドレス１およびＩＰアドレス０を含み、メッセージ２がＩＰアドレス２およびＩＰアドレス０を含む場合には、Ｌ１は、以下のマッピング関係を確立することがある。
マッピング関係１（ＩＰａｄｄｒｅｓｓ１，ＩＰａｄｄｒｅｓｓ０）、および
マッピング関係２（ＩＰａｄｄｒｅｓｓ２，ＩＰａｄｄｒｅｓｓ０）。

別の可能な実装では、Ｌ１によって受信されたメッセージ１がＩＰｖ６アドレス１およびＩＰｖ６アドレス０を含み、メッセージ２がＩＰｖ６アドレス２およびＩＰｖ６アドレス０を含む場合には、Ｌ１は、以下のマッピング関係を確立することがある。
マッピング関係３（ＩＰｖ６ａｄｄｒｅｓｓ１，ＩＰｖ６ａｄｄｒｅｓｓ０）、および
マッピング関係４（ＩＰｖ６ａｄｄｒｅｓｓ２，ＩＰｖ６ａｄｄｒｅｓｓ０）。

ステップ４３０：Ｌ１が、Ｈ１から送信されたＳ１Ｇ１マルチキャスト参加メッセージを受信する。

Ｌ１によって受信されるＳ１Ｇ１マルチキャスト参加メッセージは、ＩＧＭＰメッセージであってもよいし、ＭＬＤメッセージであってもよい。これは、本願では限定されない。詳細については、上記の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

ステップ４４０：Ｌ１が、ＲＰＦエントリを確立する。

Ｌ１がＨ１からＳ１Ｇ１マルチキャスト参加メッセージを受信した後で、Ｌ１は、Ｓ１Ｇ１に対応するＵＭＨノードを選択する。ＵＭＨノードは、Ｌ１ノードがＳ１Ｇ１マルチキャストトラフィックをそこから受信すると予想するノードである。具体的には、Ｌ１は、Ｓ１までのユニキャストルートに従ってＵＭＨ情報を取得し得る。例えば、Ｌ１は、Ｓ１までのユニキャストルートの次のホップがプライマリなネクストホップのＩＰアドレス１またはセカンダリなネクストホップのＩＰアドレス２であることを学習することがある。この場合には、Ｌ１は、Ｓ１Ｇ１マルチキャストトラフィックがＩＰアドレス１から来ると予想する。

Ｌ１は、本願の本実施形態では、ＩＰアドレス１またはＩＰアドレス２のいずれかから送信されたマルチキャストパケットを転送することがある。具体的には、一例では、Ｌ１は、Ｌ１がＩＰアドレス１またはＩＰアドレス２のいずれかから送信されたマルチキャストパケットを転送し得るように構成されることがある。

例えば、Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークがＩＰｖ４ネットワークである場合には、Ｌ１上の構成は、以下の通りである。

別の例で、Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークがＩＰｖ６ネットワークである場合には、Ｌ１上の構成は、以下の通りである。

「ｉｐｖｐｎｖｐｎ１」は、ＶＰＮインスタンスが構成されていることを示し、「ｉｐｖ４－ｆａｍｉｌｙ」は、ＶＰＮｖ４とも呼ばれるＶＰＮＩＰｖ４アドレスファミリが構成されていることを示す。あるいは、「ｉｐｖ６－ｆａｍｉｌｙ」は、ＶＰＮｖ６とも呼ばれるＶＰＮＩＰｖ６アドレスファミリが構成され得ることを示す。「Ｍｖｐｎ」は、ｍｖｐｎがＶＰＮインスタンスに対してイネーブルにされていることを示し、ＶＰＮインスタンスは、ＭＶＰＮインスタンスとも呼ばれる。「Ａｎｙｃａｓｔ－ｒｐｆｅｎａｂｌｅ」は、ａｎｙｃａｓｔ－ｒｐｆがイネーブルにされていることを示す。換言すれば、複数のＩＰアドレスのうちのいずれか１つを識別するために、Ｒ１／Ｒ２から送信されるメッセージに含まれるａｎｙｃａｓｔ－ｒｐｆ情報が処理されることがある、またはオブジェクト（例えば本願の本実施形態では第１のデバイスグループの識別子すなわちＩＰアドレス０）がＲＰＦチェック中に使用されることがある。

「Ａｎｙｃａｓｔ－ｒｐｆｅｎａｂｌｅ」は任意選択であることに留意されたい。換言すれば、この構成は、設定されないこともある。デフォルトでは、システムは、Ｒ１／Ｒ２から送信された受信されたメッセージに含まれるａｎｙｃａｓｔ－ｒｐｆ情報を処理する。

本願では、構成「Ａｎｙｃａｓｔ－ｒｐｆｅｎａｂｌｅ」に基づいて、Ｌ１がプライマリネクストホップのＩＰアドレス１およびセカンダリネクストホップのＩＰアドレス２を取得した後で、Ｌ１は、Ｓ１Ｇ１マルチキャストトラフィックがＩＰアドレス１またはＩＰアドレス２のいずれかから来ると予想する。したがって、Ｌ１はＲＰＦエントリを確立する。

以下では、Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークがＩＰｖ４ネットワークである例を用いる。

可能なＲＰＦエントリは、（Ｓ１，ＵＭＨ＜ＩＰａｄｄｒｅｓｓ１，ＩＰａｄｄｒｅｓｓ２＞）である。このＲＰＦエントリは、ＩＰアドレス１に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送すること、またはＩＰアドレス２に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送することを示す。

別の可能なＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含む。第１のサブエントリは、ＩＰアドレス１に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送することを示す、（Ｓ１，ＵＭＨ＜ＩＰａｄｄｒｅｓｓ１＞）である。第２のサブエントリは、ＩＰアドレス２に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送することを示す、（Ｓ１，ＵＭＨ＜ＩＰａｄｄｒｅｓｓ２＞）である。

任意選択で、Ｌ１によって受信されたメッセージ１がＩＰアドレス１およびＩＰアドレス０を含み、メッセージ２がＩＰアドレス２およびＩＰアドレス０を含む場合には、Ｌ１は、マルチキャストトラフィック（Ｓ１，Ｇ１）がエニーキャストＩＰアドレス０によって識別されるデバイスグループから来るとＬ１が予想することを示すために、マッピング関係１およびマッピング関係２に基づいてＲＰＦエントリ（Ｓ１，Ａｎｙｃａｓｔ－ＵＭＨ＜ＩＰａｄｄｒｅｓｓ０＞）、（ＩＰａｄｄｒｅｓｓ１，ＩＰａｄｄｒｅｓｓ０）、および（ＩＰａｄｄｒｅｓｓ２，ＩＰａｄｄｒｅｓｓ０）をさらに確立することがある。エニーキャストＩＰアドレス０は、ＩＰアドレス１を用いて表されるデバイスＲ１、およびＩＰアドレス２を用いて表されるデバイスＲ２を含む。ＩＰアドレス０は、ＩＰアドレス１またはＩＰアドレス０のいずれかを識別するために使用されることもある。

以下では、Ｒ１／Ｒ２、Ｐ１／Ｐ２、およびＬ１／Ｌ２を含むネットワークがＩＰｖ６ネットワークである例を用いる。

可能なＲＰＦエントリは、（Ｓ１，ＵＭＨ＜ＩＰｖ６ａｄｄｒｅｓｓ１，ＩＰｖ６ａｄｄｒｅｓｓ２＞）である。このＲＰＦエントリは、ＩＰｖ６アドレス１に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送すること、またはＩＰｖ６アドレス２に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送することを示す。

別の可能なＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含む。第１のサブエントリは、ＩＰｖ６アドレス１に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送することを示す、（Ｓ１，ＵＭＨ＜ＩＰｖ６ａｄｄｒｅｓｓ１＞）である。第２のサブエントリは、ＩＰｖ６アドレス２に対応するデバイスから送信されたＳ１Ｇ１マルチキャストパケットを転送することを示す、（Ｓ１，ＵＭＨ＜ＩＰｖ６ａｄｄｒｅｓｓ２＞）である。

任意選択で、Ｌ１によって受信されたメッセージ１がＩＰｖ６アドレス１およびＩＰｖ６アドレス０を含み、メッセージ２がＩＰｖ６アドレス２およびＩＰｖ６アドレス０を含む場合には、Ｌ１は、マッピング関係３およびマッピング関係４に基づいてＲＰＦエントリ（Ｓ１，Ａｎｙｃａｓｔ－ＵＭＨ＜ＩＰｖ６ａｄｄｒｅｓｓ０＞）、（ＩＰｖ６ａｄｄｒｅｓｓ１，ＩＰｖ６ａｄｄｒｅｓｓ０）、および（ＩＰｖ６ａｄｄｒｅｓｓ２，ＩＰｖ６ａｄｄｒｅｓｓ０）をさらに確立することがある。ＩＰｖ６アドレス０は、ＩＰｖ６アドレス１またはＩＰｖ６アドレス０のいずれかを識別するために使用されることもある。

ステップ４５０：Ｌ１が、マルチキャスト参加メッセージをＲ１に送信する。

ステップ４５１：Ｌ１が、マルチキャスト参加メッセージをＲ２に送信する。

Ｌ１は、メッセージ３を用いてマルチキャスト参加メッセージをＲ１に送信し、メッセージ４を用いてマルチキャスト参加メッセージをＲ２に送信することがある。メッセージ３およびメッセージ４は、ＢＧＰ－ＭＶＰＮメッセージであることもあるし、ＢＧＰ－ＥＶＰＮメッセージであることもある。

任意選択で、Ｌ１からＲ１に送信されるメッセージ３がＲ１のＩＰアドレス１をさらに搬送して、Ｒ１がマルチキャスト参加メッセージがＲ１に送信されたと決定し、マルチキャスト参加をマルチキャストソースに送信するようになっていることもある。同様に、Ｌ１からＲ２に送信されるメッセージ４がＲ２のＩＰアドレス２をさらに搬送して、Ｒ２がマルチキャスト参加メッセージがＲ２に送信されたと決定し、マルチキャスト参加をマルチキャストソースに送信するようになっていることもある。

ステップ４５５：Ｒ１が、マルチキャスト参加メッセージをマルチキャストソースに送信する。

ステップ４５６：Ｒ２が、マルチキャスト参加メッセージをマルチキャストソースに送信する。

本願の本実施形態では、Ｒ１またはＲ２がマルチキャスト参加メッセージをマルチキャストソースに送信することもあるし、Ｒ１およびＲ２の両方がマルチキャスト参加メッセージをマルチキャストソースに送信することもある。換言すれば、本実施形態では、ステップ４５５のみが実行されることもあるし、ステップ４５６のみが実行されることもあるし、ステップ４５５およびステップ４５６の両方が実行されることもある。

ステップ４６０：マルチキャストソースが、Ｓ１Ｇ１マルチキャストデータパケットをＲ１に送信する。

マルチキャストソースは、本願では、Ｓ１Ｇ１マルチキャストデータパケットをＲ１およびＲ２の両方に送信することがある。あるいは、マルチキャストソースは、Ｓ１Ｇ１マルチキャストデータパケットをＲ１／Ｒ２の一方のノードに送信することもある。換言すれば、マルチキャストソースは、Ｓ１Ｇ１マルチキャストデータパケットをＲ１に送信することもあるし、Ｓ１Ｇ１マルチキャストデータパケットをＲ２に送信することもある。

説明を容易にするために、図４Ａおよび図４Ｂでは、マルチキャストソースがＳ１Ｇ１マルチキャストデータパケットをＲ１に送信する例を用いて説明が提供される。

可能な実装では、マルチキャストソースのインタフェースは、Ｅｔｈ－ｔｒｕｎｋインタフェースとして構成されることもあり、マルチキャストソースのマルチキャストトラフィックは、Ｒ１またはＲ２のいずれかに送信される。具体的には、マルチキャストソースをＲ１／Ｒ２に接続するために使用される２つのインタフェースは、Ｅｔｈ－ｔｒｕｎｋインタフェースとして構成されることがある。任意選択で、Ｒ１／Ｒ２のインタフェースも、いくつかのシステムではＥｔｈ－ｔｒｕｎｋインタフェースとして構成される必要がある。マルチキャストソースは、Ｓ１Ｇ１マルチキャストデータパケットをＲ１／Ｒ２に接続されたインタフェースのうちの一方のみに送信する。

別の可能な実装では、Ｒ１およびＲ２の両方が、マルチキャスト参加メッセージをマルチキャストソースに送信して、マルチキャストパケットをＲ１およびＲ２にインジェストすることがある。この場合、Ｒ１／Ｒ２は、デバイス間の相互メッセージに基づいて、それらのデバイスのうちのいずれかがマルチキャストパケットを転送すると決定する。

別の可能な実装では、Ｒ１／Ｒ２は、１つのエニーキャストＩＰアドレスを使用して、マルチキャストソースからマルチキャストパケットを受信することがある。例えば、マルチキャストパケットは、ユニキャストパケットにカプセル化され、このユニキャストパケットの宛先アドレスが、そのエニーキャストＩＰアドレスである。このようにして、マルチキャストパケットは、複数のデバイスではなく、Ｒ１またはＲ２のいずれかに到達する。この実装では、Ｒ１またはＲ２のいずれかによって受信されるユニキャストパケットが外部ＩＰヘッダを含むことを理解されたい。Ｒ１またはＲ２は、ユニキャストパケット中の外部ＩＰヘッダ中の宛先アドレスがＲ１またはＲ２であるときにパケットをカプセル化解除し、内部Ｓ１Ｇ１マルチキャストデータパケットを取得する。

このエニーキャストＩＰアドレスは、上述のエニーキャストＲＰＦに使用されたエニーキャストＩＰアドレス０と同じであることも、異なることもあることに留意されたい。これは、本願では特に限定されない。

説明を容易にするために、図４Ａおよび図４Ｂでは、マルチキャストソースがＳ１Ｇ１マルチキャストデータパケットをＲ１に送信する例を用いて説明が提供されることに留意されたい。

ステップ４７０：Ｒ１が、Ｓ１Ｇ１マルチキャストデータパケットをＬ１に送信する。

任意選択で、一例では、Ｒ１は、以下の構成を有することがある。

「ｉｐｖｐｎｖｐｎ１」は、ＶＰＮインスタンスが構成されていることを示し、「ｉｐｖ４－ｆａｍｉｌｙ」は、ＶＰＮｖ４とも呼ばれるＶＰＮＩＰｖ４アドレスファミリが構成されていることを示す。「ｉｐｖ６－ｆａｍｉｌｙ」は、ＶＰＮｖ６とも呼ばれるＶＰＮＩＰｖ６アドレスファミリが構成されていることを示す。「Ｍｖｐｎ」は、ｍｖｐｎがＶＰＮインスタンスに対してイネーブルにされていることを示し、ＶＰＮインスタンスは、ＭＶＰＮインスタンスとも呼ばれる。「ｓｅｎｄｅｒｅｎａｂｌｅ」は、ＭＶＰＮマルチキャストの送信側として使用されるノードが、マルチキャストソースから送信されたマルチキャストパケットを転送することがあることを示す。「Ａｎｙｃａｓｔ－ｒｐｆｅｎａｂｌｅ」は、ａｎｙｃａｓｔ－ｒｐｆがイネーブルにされていることを示す。「ｓｅｎｄｅｒ－ｅｎａｂｌｅ」が構成されている場合には、ノードからリーフノードに送信されるメッセージは、ａｎｙｃａｓｔ－ｒｐｆ情報を搬送することがあることは理解され得る。

Ｒ１は、複数の方法でコアネットワークを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信する。可能な実装では、Ｒ１は、ポイントツーマルチポイント（ｐｏｉｎｔ－ｔｏ－ｍｕｌｔｉｐｏｉｎｔ、Ｐ２ＭＰ）トンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。別の可能な実装では、Ｒ１は、ビットインデックスエクスプリシットレプリケーション（ｂｉｔｉｎｄｅｘｅｘｐｌｉｃｉｔｒｅｐｌｉｃａｔｉｏｎ、ＢＩＥＲ）マルチプロトコルラベルスイッチング（ｍｕｌｔｉ－ｐｒｏｔｏｃｏｌｌａｂｅｌｓｗｉｔｃｈｉｎｇ、ＭＰＬＳ）トンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。別の可能な実装では、Ｒ１は、ＢＩＥＲインターネットプロトコルバージョン６（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎ６、ＢＩＥＲｖ６）トンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。

例えば、Ｒ１は、Ｐ２ＭＰトンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。Ｓ１Ｇ１マルチキャストデータパケットは、以下のフォーマットでカプセル化されることがある。
（Ｐ２ＭＰｌａｂｅｌ，ＩＰｐａｃｋｅｔ＜Ｓ１Ｇ１＞）

Ｒ１がＬ１に送信されるＳ１Ｇ１マルチキャストデータパケットをネクストホップノードに送信するときにカプセル化されるＰ２ＭＰラベル（ｌａｂｅｌ）は、Ｒ１ノードとＬ１ノードの間のネクストホップノードによってＰ２ＭＰトンネルに割り当てられるラベルである。例えば、Ｒ１がＳ１Ｇ１マルチキャストデータパケットをＰ１に送信するときにカプセル化されるＰ１ノードは、Ｐ１によってＰ２ＭＰトンネルに割り当てられるラベルである。Ｐ１がＬ１に送信されるＳ１Ｇ１マルチキャストデータパケットをネクストホップノードに送信するときにカプセル化されるＰ２ＭＰラベルは、Ｐ１ノードとＬ１ノードの間のネクストホップノードによってＰ２ＭＰトンネルに割り当てられるラベルである。例えば、Ｐ１がＳ１Ｇ１マルチキャストデータパケットをＬ１に送信するときにカプセル化されるＬ１ノードは、Ｌ１によってＰ２ＭＰトンネルに割り当てられるラベルである。Ｐ２ＭＰトンネルは、転送等価クラス（ｆｏｒｗａｒｄｉｎｇｅｑｕiｖａｌｅｎｃｅｃｌａｓｓ、ＦＥＣ）を用いて識別されることがある。Ｐ２ＭＰトンネルのＦＥＣは、ヘッドノードのＩＰアドレスおよびトンネルＩＤを含む。例えば、（ｈｅａｄｎｏｄｅＲ１，ｔｕｎｎｅｌＩＤ＝１）はＦＥＣであり、（ｈｅａｄｎｏｄｅＲ１，ｔｕｎｎｅｌＩＤ＝２）も別のＦＥＣである。ノードはラベルをＰ２ＭＰトンネルに割り当てるが、これは、ノードが例えばＦＥＣに対応するラベルを生成し、ラベルＬａｂｅｌ１を（ｈｅａｄｎｏｄｅＲ１，ｔｕｎｎｅｌＩＤ＝１）に割り当て、ラベルＬａｂｅｌ２を（ｈｅａｄｎｏｄｅＲ１，ｔｕｎｎｅｌＩＤ＝２）に割り当てることを意味する。

例えば、Ｒ１は、ＢＩＥＲ－ＭＰＬＳトンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。Ｓ１Ｇ１マルチキャストデータパケットは、以下のフォーマットでカプセル化されることがある。
（ＢＩＥＲＨｅａｄｅｒ，ＯｐｔｉｏｎａｌＶｐｎＬａｂｅｌ，ＩＰｐａｃｋｅｔ＜Ｓ１Ｇ１＞）

Ｒ１がＬ１に送信されるマルチキャストデータパケットをネクストホップノードに送信するときにカプセル化されるＢＩＥＲヘッダ中のＢＩＥＲラベルは、Ｒ１ノードとＬ１ノードの間のネクストホップノードによってＢＩＥＲトンネルに割り当てられるラベルである。例えば、Ｒ１がＳ１Ｇ１マルチキャストデータパケットをＰ１に送信するときにカプセル化されるＰ１ノードは、Ｐ１によってＢＩＥＲトンネルに割り当てられるＢＩＥＲラベルである。Ｐ１がＬ１に送信されるＳ１Ｇ１マルチキャストデータパケットをネクストホップノードに送信するときにカプセル化されるＢＩＥＲラベルは、Ｐ１ノードとＬ１ノードの間のネクストホップノードによってＢＩＥＲトンネルに割り当てられるラベルである。例えば、Ｐ１がＳ１Ｇ１マルチキャストデータパケットをＬ１に送信するときにカプセル化されるＬ１ノードは、Ｌ１によってＢＩＥＲトンネルに割り当てられるＢＩＥＲラベルである。ＢＩＥＲトンネルまたはＢＩＥＲラベルは、トリプレットに対応することがあり、トリプレット（サブドメイン識別子（ｓｕｂ－ｄｏｍａｉｎ－ｉｄ）、ビット列長（ｂｉｔｓｔｒｉｎｇｌｅｎｇｔｈ、ＢＳＬ）、およびセット識別子（ｓｅｔｉｄｅｎｔｉｆｉｅｒ、ＳＩ））によって識別されることがある。例えば、Ｌ１は、ラベルＬａｂｅｌ１をトリプレット（０，２５６，０）に割り当て、Ｐ１は、ラベルＬａｂｅｌ２をトリプレット（０，２５６，０）に割り当てる。Ｒ１は、トリプレット（０，２５６，０）を用いてパケットをＰ１に送信するときに、ラベルＬａｂｅｌ２をＢＩＥＲラベルとしてＢＩＥＲヘッダにカプセル化する。Ｐ１は、Ｌａｂｅｌ２に基づいてパケットに対応するトリプレット（０，２５６，０）を学習し、ＢＩＥＲに基づいてパケットをＬ１に転送するときに、ラベルＬａｂｅｌ１をＢＩＥＲＬａｂｅｌとしてＢＩＥＲヘッダにカプセル化する。

例えば、Ｒ１は、ＢＩＥＲｖ６トンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。Ｓ１Ｇ１マルチキャストデータパケットは、以下のフォーマットでカプセル化されることがある。
（ｏｕｔｅｒＩＰｖ６，ｏｕｔｅｒＩＰｖ６ｅｘｔｅｎｓｉｏｎｈｅａｄｅｒ＜ｗｉｔｈＢＩＥＲｈｅａｄｅｒ＞，ＩＰｐａｃｋｅｔ＜Ｓ１Ｇ１＞）

Ｒ１によってカプセル化される外部ＩＰｖ６中のソースアドレスは、Ｒ１ノードのＩＰｖ６アドレスであり、ＢＩＥＲヘッダ中のＢｉｔＳｔｒｉｎｇ中のＬ１ノードに対応するビット位置は１であり、Ｒ１によって送信されるパケットは、Ｐ１を用いてＬ１に送信される。

ステップ４７５：Ｌ１が、ＲＰＦエントリに従って、Ｒ１から送達されたＳ１Ｇ１マルチキャストデータパケットを転送するかどうかを決定する。

具体的には、Ｌ１は、Ｓ１Ｇ１マルチキャストデータパケットを受信した後でエニーキャストＲＰＦチェックを実行する。

可能な実装では、Ｌ１は、Ｐ２ＭＰトンネルからマルチキャストデータパケットを受信し、Ｌ１は、Ｐ２ＭＰラベルに基づいて、そのパケットの実際の出所であるＩＰアドレスを学習する。例えば、Ｌ１によって受信されるパケット中のＰ２ＭＰラベルはＬａｂｅｌ１であり、Ｌ１は、対応（ＦＥＣ＜ＩＰａｄｄｒｅｓｓｏｆｈｅａｄｎｏｄｅＲ１＝ＩＰａｄｄｒｅｓｓ１，ｔｕｎｎｅｌＩＤ＝１＞，Ｐ２ＭＰＬａｂｅｌ＝Ｌａｂｅｌ１）を記憶する。この場合には、Ｌ１は、Ｌａｂｅｌ１に基づいて、パケットが実際にはＩＰアドレス１から来ることを知り得る。Ｌ１は、マッピング関係１に従って、パケットの実際の出所であるＩＰアドレスが、ＩＰアドレス０、すなわちパケットの実際の出所であるデバイスグループにマッピングされ得ることを学習する。Ｌ１は、ＲＰＦエントリ中の予想されるＡｎｙｃａｓｔ－ＵＭＨに基づいて、パケットについての予想されるＵＭＨがＩＰアドレス０であることを学習する。２つのＵＭＨが同じである場合には、ＲＰＦチェックは成功し、Ｌ１は、マルチキャストデータパケットをＨ１に転送することがある。

別の可能な実装では、Ｌ１は、ＢＩＥＲトンネルからマルチキャストデータパケットを受信し、Ｌ１は、ＢＩＥＲヘッダに基づいて、そのパケットの実際の出所であるＩＰアドレスを学習する。例えば、Ｌ１によって受信されるパケットのＢＩＥＲヘッダ中のＢＩＥＲラベルはＬａｂｅｌ１であり、Ｌ１は、対応（＜０，２５６，０＞，ＢＩＥＲＬａｂｅｌ＝Ｌａｂｅｌ１）を記憶する。この場合には、Ｌ１は、Ｌａｂｅｌ１に基づいて、パケットがトリプレット＜０，２５６，０＞に対応することを知り得る。Ｌ１は、ＢＩＥＲヘッダ中のＢＦＩＲ－ｉｄ＝Ｘ、パケットに対応するＳｕｂ－ｄｏｍａｉｎ－ｉｄ＝０、およびＬ１に記憶される対応＜Ｓｕｂ－ｄｏｍａｉｎ－ｉｄ＝０，ＢＦＩＲ－ｉｄ＝Ｘ，ＢＦＩＲ－ｐｒｅｆｉｘ＝ＩＰａｄｄｒｅｓｓ１＞に基づいて、パケットが実際にはＩＰアドレス１から来ることを取得し得る。Ｌ１は、マッピング関係１に従って、パケットの実際の出所であるＩＰアドレスが、ＩＰアドレス０にマッピングされ得ることを学習する。Ｌ１は、ＲＰＦエントリ中の予想されるＡｎｙｃａｓｔ－ＵＭＨに基づいて、パケットについての予想されるＵＭＨがＩＰアドレス０であることを学習する。２つのＵＭＨが同じである場合には、ＲＰＦチェックは成功し、Ｌ１は、マルチキャストデータパケットをＨ１に転送することがある。

別の可能な実装では、Ｌ１は、ＢＩＥＲｖ６トンネルからマルチキャストデータパケットを受信し、Ｌ１は、外部ＩＰｖ６ヘッダ中のソースアドレスに基づいて、そのパケットの実際の出所であるＩＰアドレスを学習する。例えば、Ｌ１によって受信されるパケットの外部ＩＰｖ６ヘッダ中のソースアドレスは、ＩＰｖ６アドレス１である。Ｌ１は、マッピング関係３に従って、パケットの実際の出所であるＩＰアドレスが、ＩＰｖ６アドレス０にマッピングされ得ることを学習する。Ｌ１は、ＲＰＦエントリ中の予想されるＡｎｙｃａｓｔ－ＵＭＨに基づいて、パケットについての予想されるＵＭＨがＩＰｖ６アドレス０であることを学習する。２つのＵＭＨが同じである場合には、ＲＰＦチェックは成功し、Ｌ１は、マルチキャストデータパケットをＨ１に転送することがある。

ステップ４７８：Ｌ１が、マルチキャストデータパケットをＨ１に転送する。

任意選択で、いくつかの実施形態では、Ｌ１とマルチキャストソースの間の通信リンクが故障することが、ノードＲ１が故障すること、ノードＲ１とマルチキャストソースの間のリンクが故障すること、またはＲ１とＰ１／Ｐ２の間のリンクが故障することとして理解されることもある。図４Ｂに示すように、この方法は、ステップ４８０から４９７をさらに含むことがある。以下、ステップ４８０から４９７について別個に詳細に述べる。

ステップ４８０：マルチキャストソースが、Ｓ１Ｇ１マルチキャストデータパケットをＲ２に送信する。

Ｒ１とマルチキャストソースの間の通信リンクが故障している場合、例えば、図１に示すように、デバイスＣＥ１が故障している、またはＣＥ１とマルチキャストソースの間の通信リンクが故障している場合には、マルチキャストソースは、マルチキャストデータパケットをＲ２に送信することがあり、Ｒ２は、このマルチキャストデータパケットをＬ１に送信することを理解されたい。以下、上記の障害を決定する具体的な実装について詳細に述べる。

例えば、Ｒ１ノードが故障していると決定される。本願では、Ｒ１に接続されたインタフェースの状態がダウンであることをマルチキャストソースが検出した場合に、Ｒ１ノードが故障していると決定されることがある。マルチキャストソースは、これ以上Ｒ１ノードにマルチキャストデータパケットを送信する必要はない。任意選択で、Ｒ２に接続されたインタフェースの状態がアップであることをマルチキャストソースが検出した場合に、マルチキャストソースはＲ２にマルチキャストデータパケットを送信することもある。

例えば、Ｒ１とＰ１の間のリンクまたはＲ１とＰ２の間のリンクが故障していると決定される。Ｒ１がＲ１のインタフェースの状態がダウンであることを検出した後で、Ｒ１は、Ｒ１とマルチキャストソースの間のリンクを無効にして、Ｒ１に接続されたインタフェースの状態がダウンであり、Ｒ２に接続されたインタフェースの状態がアップであることをマルチキャストソースが検出するようにし得る。この場合には、マルチキャストソースは、Ｒ２にマルチキャストデータパケットを送信する。

任意選択で、いくつかの実施形態では、Ｒ１のインタフェースの状態がダウンであることをＲ１が検出した後、Ｒ１とマルチキャストソースの間のリンクをＲ１が無効にする前に、以下の構成がさらに実行されることもある。

ステップ４９０：Ｒ２が、Ｓ１Ｇ１マルチキャストデータパケットをＬ１に送信する。

任意選択で、一例では、Ｒ２は、以下の構成を有することもある。

これらの構成は、ステップ４７０のＲ１上の構成と同様である。詳細については、ステップ４７０の設定情報の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

Ｓ１Ｇ１マルチキャストデータパケットを受信した後で、Ｒ２は、Ｒ２上のＭＶＰＮ構成に基づいてマルチキャストデータパケットをカプセル化し、そのパケットをコアネットワークを介してＬ１に送信する。Ｒ２は、複数の方法でコアネットワークを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信する。可能な実装では、Ｒ２は、Ｐ２ＭＰトンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信する。別の可能な実装では、Ｒ２は、ＢＩＥＲ－ＭＰＬＳトンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。別の可能な実装では、Ｒ２は、ＢＩＥＲｖ６トンネルを介してＳ１Ｇ１マルチキャストデータパケットをＬ１に送信することがある。具体的な実装はステップ４７０における実装と同様である。詳細については、ステップ４７０の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

ステップ４９５：Ｌ１が、ＲＰＦエントリに従って、Ｒ２から送達されたＳ１Ｇ１マルチキャストデータパケットを転送するかどうかを決定する。

可能な実装では、Ｌ１は、Ｐ２ＭＰトンネルからマルチキャストデータパケットを受信し、Ｌ１は、Ｐ２ＭＰラベルに基づいて、そのパケットの実際の出所であるＩＰアドレスを学習する。例えば、Ｌ１によって受信されるパケット中のＰ２ＭＰラベルはＬａｂｅｌ２であり、Ｌ１は、対応（ＦＥＣ＜ＩＰａｄｄｒｅｓｓｏｆｈｅａｄｎｏｄｅＲ１＝ＩＰａｄｄｒｅｓｓ２，ｔｕｎｎｅｌＩＤ＝１＞，Ｐ２ＭＰＬａｂｅｌ＝Ｌａｂｅｌ２）を記憶する。この場合には、Ｌ１は、Ｌａｂｅｌ２に基づいて、パケットが実際にはＩＰアドレス２から来ることを知り得る。Ｌ１は、ＲＰＦエントリ中の予想されるＡｎｙｃａｓｔ－ＵＭＨに基づいて、パケットについての予想されるＵＭＨがＩＰアドレス０であることを学習する。２つのＵＭＨが同じである場合には、ＲＰＦチェックは成功し、Ｌ１は、マルチキャストデータパケットをＨ１に転送することがある。

別の可能な実装では、Ｌ１は、ＢＩＥＲトンネルからマルチキャストデータパケットを受信し、Ｌ１は、ＢＩＥＲヘッダに基づいて、そのパケットの実際の出所であるＩＰアドレスを学習する。例えば、Ｌ１によって受信されるパケットのＢＩＥＲヘッダ中のＢＩＥＲラベルはＬａｂｅｌ１であり、Ｌ１は、対応（＜０，２５６，０＞，ＢＩＥＲＬａｂｅｌ＝Ｌａｂｅｌ１）を記憶する。この場合には、Ｌ１は、Ｌａｂｅｌ１に基づいて、パケットがトリプレット＜０，２５６，０＞に対応することを知り得る。Ｌ１は、ＢＩＥＲヘッダ中のＢＦＩＲ－ｉｄ＝Ｙ、パケットに対応するＳｕｂ－ｄｏｍａｉｎ－ｉｄ＝０、およびＬ１に記憶される対応＜Ｓｕｂ－ｄｏｍａｉｎ－ｉｄ＝０，ＢＦＩＲ－ｉｄ＝Ｙ，ＢＦＩＲ－ｐｒｅｆｉｘ＝ＩＰａｄｄｒｅｓｓ２＞に基づいて、パケットが実際にはＩＰアドレス２から来ることを取得し得る。Ｌ１は、マッピング関係２に従って、パケットの実際の出所であるＩＰアドレスが、ＩＰアドレス０にマッピングされ得ることを学習する。Ｌ１は、ＲＰＦエントリ中の予想されるＡｎｙｃａｓｔ－ＵＭＨに基づいて、パケットについての予想されるＵＭＨがＩＰアドレス０であることを学習する。２つのＵＭＨが同じである場合には、ＲＰＦチェックは成功し、Ｌ１は、マルチキャストデータパケットをＨ１に転送することがある。

別の可能な実装では、Ｌ１は、ＢＩＥＲｖ６トンネルからマルチキャストデータパケットを受信し、Ｌ１は、外部ＩＰｖ６ヘッダに基づいて、そのパケットの実際の出所であるＩＰｖ６アドレス、例えばソースアドレス、すなわちＬ１によって受信されるパケットの外部ＩＰｖ６ヘッダ中のＩＰｖ６アドレス２を学習する。Ｌ１は、マッピング関係４に従って、パケットの実際の出所であるＩＰアドレスが、ＩＰｖ６アドレス０にマッピングされ得ることを学習する。Ｌ１は、ＲＰＦエントリ中の予想されるＡｎｙｃａｓｔ－ＵＭＨに基づいて、パケットについての予想されるＵＭＨがＩＰｖ６アドレス０であることを学習する。２つのＵＭＨが同じである場合には、ＲＰＦチェックは成功し、Ｌ１は、マルチキャストデータパケットをＨ１に転送することがある。

ステップ４９７：Ｌ１が、マルチキャストデータパケットをＨ１に転送する。

上述の技術的解決策では、一方で、障害がないときには、マルチキャストソースから送信されるトラフィックはＲ１のみに送信され、Ｒ１のみが、そのトラフィックをコアネットワークを介してＬ１に送信する。したがって、コアネットワーク中にはマルチキャストトラフィックのコピーが１つしかなく、さらにもう１つのマルチキャストトラフィックのコピーを使用する必要はない。一方、Ｒ１ノードとマルチキャストソースの間のリンクが故障しているときには、マルチキャストソースから送信されたトラフィックはＲ２のみに送信され、Ｒ２のみが、そのトラフィックをコアネットワークを介してＬ１に送信し、Ｒ２は、Ｌ１がマルチキャスト参加メッセージを送信するのを待機する必要がない。これにより、より高速なサービス回復を実施することができる。

以下、図２に示すシナリオを例として用い、図５Ａおよび図５Ｂの実施形態を参照して、本願の実施形態で提供されるパケット転送方法の具体的な実装について詳細に述べる。

図５Ａおよび図５Ｂは、本願の実施形態による別のパケット転送方法を示す概略流れ図である。図５Ａおよび図５Ｂに示すように、この方法は、ステップ５１０から５９５を含むことがある。以下、ステップ５１０から５９５について別個に詳細に述べる。

ステップ５１０：Ｒ１が、デバイス識別子をＬ１に送信する。

ステップ５１１：Ｒ２が、デバイス識別子をＬ１に送信する。

ステップ５２０：Ｌ１が、Ｒ１／Ｒ２のデバイス識別子情報を記憶する。

ステップ５３０：Ｌ１が、Ｈ１から送信されるＳ１Ｇ１マルチキャスト参加メッセージを受信する。

ステップ５４０：Ｌ１が、ＲＰＦエントリを確立する。

ステップ５５０：Ｌ１が、マルチキャスト参加メッセージをＲ１に送信する。

ステップ５５１：Ｌ１が、マルチキャスト参加メッセージをＲ２に送信する。

ステップ５５５：Ｒ１が、マルチキャスト参加メッセージをマルチキャストソースに送信する。

ステップ５５６：Ｒ２が、マルチキャスト参加メッセージをマルチキャストソースに送信する。

ステップ５６０：Ｒ１が、Ｒ１／Ｒ２の共通のＩＰアドレス識別子をＳＷに送信する。

ステップ５６１：Ｒ２が、Ｒ１／Ｒ２の共通のＩＰアドレス識別子をＳＷに送信する。

ステップ５６０およびステップ５６１は任意選択であることに留意されたい。Ｒ１／Ｒ２の共通のＩＰアドレス識別子は、本願の本実施形態でもＳＷ上で構成されることがある。

いくつかの実施形態では、例えば、セグメント化されたＭＶＰＮ内のＲ１／Ｒ２は、さらにＲ１／Ｒ２の共通のＩＰアドレス識別子をＳＷに送信する。ＳＷは、Ｒ１およびＲ２の共通のＩＰアドレス識別子を静的に構成することがある。本願では、共通のＩＰアドレス識別子は、例えばＩＰアドレス０であることもあるし、別の共通の識別子であることもある（例えば整数であることもある）。説明を容易にするために、以下は、前述の構成例におけるＩＰアドレス０（１９２．１６８．１．１００）がＲ１／Ｒ２の共通のＩＰアドレス識別子として使用される例を用いて説明する。

可能な実装では、Ｒ１／Ｒ２は、アドバタイズされたＢＧＰ－ＭＶＰＮルートにおけるＩＰアドレス０を含むことがある。例えば、Ｒ１／Ｒ２は、ＢＧＰ－ＭＶＰＮＩ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス０を含むことがある。別の例では、Ｒ１／Ｒ２は、ＢＧＰ－ＭＶＰＮＳ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス０をさらに含むこともある。

別の可能な実装では、Ｒ１／Ｒ２は、アドバタイズされたＢＧＰ－ＥＶＰＮルートにおけるＩＰアドレス０を含むことがある。例えば、Ｒ１／Ｒ２は、ＢＧＰ－ＭＶＰＮＩＭＥＴルートにおけるＩＰアドレス０を含むことがある。別の例では、Ｒ１／Ｒ２は、ＢＧＰ－ＥＶＰＮＳ－ＰＭＳＩＡ－ＤルートにおけるＩＰアドレス０をさらに含むこともある。

メッセージのフォーマットは、ステップ４１０のメッセージ１またはメッセージ２の構造と同様である。詳細については、ステップ４１０の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

別の可能な実装では、Ｒ１およびＲ２の共通のＩＰアドレスまたはエニーキャストアドレスは、ＳＷ上で静的に構成され、ＳＷがＲ１およびＲ２を含むデバイスグループにパケットを送信するための宛先アドレスとして使用されることがある。例えば、ＳＷは、Ｒ１およびＲ２の共通のＩＰアドレスとして汎用ルーティングカプセル化（ｇｅｎｅｒｉｃｒｏｕｔｉｎｇｅｎｃａｐｓｕｌａｔｉｏｎ、ＧＲＥ）トンネルの宛先アドレスを構成することがあり、この場合、ＳＷは、マルチキャストデータパケットをＧＲＥトンネルにカプセル化する、すなわち外部ＩＰヘッダおよびＧＲＥヘッダをマルチキャストデータパケットにカプセル化する。ここで、外部ＩＰヘッダ内の宛先アドレスは、Ｒ１およびＲ２のエニーキャストアドレスである。

説明を容易にするために、図５Ａおよび図５Ｂでは、Ｒ１がＲ１／Ｒ２の共通のＩＰアドレス識別子ＳＷに送信する例を用いて説明が提供されることを理解されたい。

ステップ５７０：マルチキャストソースが、Ｓ１Ｇ１マルチキャストデータパケットをＳＷに送信する。

ステップ５８０：ＳＷが、Ｓ１Ｇ１マルチキャストデータパケットをＲ１に送信する。

図２のシナリオでは、マルチキャストソースは、最初にＳ１Ｇ１マルチキャストデータパケットをＳＷに送信することがあり、ＳＷは、外部ユニキャストＩＰヘッダをＳ１Ｇ１マルチキャストデータパケットにカプセル化し、ここで、外部ユニキャストＩＰヘッダ中の宛先アドレスは、Ｒ１／Ｒ２の共通のＩＰアドレス識別子である。例えば、ＳＷは、外部ユニキャストＩＰヘッダをＳ１Ｇ１マルチキャストデータパケットにカプセル化し、ここで、外部ユニキャストＩＰヘッダ中の宛先アドレスは、ＩＰアドレス０（１９２．１６８．１．１００）である。ＳＷから送信されたパケットを受信した後で、Ｒ１／Ｒ２のいずれか一方は、パケットの外部ＩＰヘッダ中の宛先アドレスがＲ１／Ｒ２のいずれか一方である場合に基づいてパケットをカプセル化解除して、内部のＳ１Ｇ１マルチキャストデータパケットを取得する。Ｒ１／Ｒ２のいずれか一方は、Ｓ１Ｇ１マルチキャストデータパケットをコアネットワークを介してＬ１に送信する。

説明を容易にするために、図５Ａおよび図５Ｂでは、ＳＷがＳ１Ｇ１マルチキャストデータパケットをＲ１に送信する例を用いて説明が提供される。

ステップ５８５：Ｒ１が、Ｓ１Ｇ１マルチキャストデータパケットをＬ１に送信する。

このステップは、ステップ４７０に対応する。詳細については、ステップ４７０の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

ステップ５９０：Ｌ１が、ＲＰＦエントリに従って、Ｒ１から送達されたＳ１Ｇ１マルチキャストデータパケットを転送するかどうかを決定する。

ステップ５９５：Ｌ１が、マルチキャストデータパケットをＨ１に転送する。

このステップは、ステップ４７８に対応する。詳細については、ステップ４７８の説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

図２のシナリオでは、Ｌ１とマルチキャストソースの間の通信リンクが故障している場合、ここで、この通信リンクの故障は、Ｒ１が故障している、デバイスＣＥ１が故障している、ＳＷデバイスが故障している、またはＲ１とＰ１／Ｐ２の間のリンクが故障しているものとして理解され得るが、その場合には、マルチキャストソースは、マルチキャストデータパケットをＲ２に送信することがあり、Ｒ２は、そのマルチキャストデータパケットをＬ１に送信する。具体的な実装方法は、図４Ａおよび図４Ｂのステップ４８０からステップ４９７に対応する。詳細については、図４Ａおよび図４Ｂの説明を参照されたい。本明細書では、詳細について重ねて述べることはしない。

以上、図１から図５Ａおよび図５Ｂを参照して本願の実施形態で提供されるパケット転送方法について詳細に述べた。以下、図６から図８を参照して、本願における装置の実施形態について詳細に述べる。方法の実施形態の説明は装置の実施形態の説明に対応することを理解されたい。したがって、詳細に述べられていない部分については、方法の実施形態を参照されたい。

図６は、本願の実施形態による第１のネットワークデバイス６００の構造を示す概略図である。図６に示す第１のネットワークデバイス６００は、前述の実施形態の方法において第１のネットワークデバイスによって実行される対応するステップを実行し得る。図６に示すように、第１のネットワークデバイス６００は、受信モジュール６１０、決定モジュール６２０、および送信モジュール６３０を含む。

受信モジュール６１０は、マルチキャストソースデバイスから送信され、第１のデバイスグループによって転送される第１のマルチキャストパケットを受信するように構成され、ここで、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第１のマルチキャストパケットは、第１のマルチキャストグループ中の１つのネットワークデバイスによって第１のネットワークデバイスに転送される。

決定モジュール６２０は、リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定する。ここで、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、第１のサブエントリは、第１のネットワークデバイスに、第２のネットワークデバイスから送信された第１のマルチキャストパケットを転送するように指示する。第２のサブエントリは、第１のネットワークデバイスに、第３のネットワークデバイスから送信された第１のマルチキャストパケットを転送するように指示する。

送信モジュール６３０は、ＲＰＦエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成される。

可能な実装では、第１の通信リンクが、正常な状態である。第１の通信リンクは、マルチキャストソースデバイスから第２のネットワークデバイスへ、そこから第１のネットワークデバイスへの通信リンクである。送信モジュール６３０は、具体的には、第１のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成される。

別の可能な実装では、第２の通信リンクが、正常な状態である。第２の通信リンクは、マルチキャストソースデバイスから第３のネットワークデバイスへ、そこから第１のネットワークデバイスへの通信リンクである。受信モジュール６１０は、具体的には、第１の通信リンクを介して転送された第１のマルチキャストパケットを受信するように構成される。第１の通信リンクのメトリックは、第２の通信リンクのメトリック未満である。

別の可能な実装では、第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときには、送信モジュール６３０は、具体的には、第２のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成される。

別の可能な実装では、受信モジュール６１０は、第２のネットワークデバイスから送信される第１の制御情報を受信するようにさらに構成され、ここで、第１の制御情報は、第２の識別子を含み、第２の識別子は、第２のネットワークデバイスの識別子である。第１のネットワークデバイスは、第２の識別子に基づいて第１のサブエントリを生成するように構成された生成モジュールをさらに含み、ここで、第１のサブエントリは、第２の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応である。受信モジュールは、第３のネットワークデバイスから送信された第２の制御情報を受信するようにさらに構成され、ここで、第２の制御情報は、第３の識別子を含み、第３の識別子は、第３のネットワークデバイスの識別子である。生成モジュールは、第３の識別子に基づいて第２のサブエントリを生成するようにさらに構成され、ここで、第２のサブエントリは、第３の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）との間の対応である。

別の可能な実装では、第２の識別子および第３の識別子は、インターネットプロトコルＩＰアドレスまたはインターネットプロトコルバージョン６ＩＰｖ６アドレスである。

別の可能な実装では、第１の制御情報は、第１デバイスグループ識別子をさらに含む。第２の制御情報は、第１デバイスグループ識別子をさらに含む。第１デバイスグループ識別子は、第１のデバイスグループの識別子である。決定モジュール６２０は、具体的には、第１デバイスグループ識別子に基づいてＲＰＦエントリを決定するように構成される。

図７は、本願の実施形態による第１のデバイスグループ７００の構造を示す概略図である。図７に示す第１のデバイスグループ７００は、前述の実施形態の方法において第１のデバイスグループによって実行される対応するステップを実行し得る。図７に示すように、第１のデバイスグループ７００は、送信モジュール７１０を含む。

送信モジュール７１０は、第１のデバイスグループ内の第２のネットワークデバイスを用いて、第２の識別子および第１デバイスグループ識別子を第１のネットワークデバイスに送信するように構成され、ここで、第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、第２の識別子は、第２のネットワークデバイスの識別子であり、第１デバイスグループ識別子は、第１のデバイスグループの識別子である。

送信モジュール７１０は、第１のデバイスグループ内の第３のネットワークデバイスを用いて、第３の識別子および第１デバイスグループ識別子を第１のネットワークデバイスに送信するようにさらに構成され、ここで、第３の識別子は、第３のネットワークデバイスの識別子であり、第２の識別子、第３の識別子、および第１デバイスグループ識別子は、第１のネットワークデバイスが第２の識別子、第３の識別子、および第１デバイスグループ識別子に基づいてリバースパス転送ＲＰＦエントリを生成するのをトリガするために使用され、ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、第１のサブエントリは、第１のネットワークデバイスに、第１のデバイスグループ内の第２のネットワークデバイスから送信された第１のマルチキャストパケットを転送するように指示し、第２のサブエントリは、第１のネットワークデバイスに、第１のデバイスグループ内の第３のネットワークデバイスから送信された第１のマルチキャストパケットを転送するように指示する。

可能な実装では、第１のデバイスグループ７００は、マルチキャストソースデバイスから送信された第１のマルチキャストパケットを第１のデバイスグループ内のネットワークデバイスを用いて受信するように構成された受信モジュール７２０をさらに含む。送信モジュールは、第１のデバイスグループ内のネットワークデバイスを用いて第１のマルチキャストパケットを第１のネットワークデバイスに転送するようにさらに構成される。

別の可能な実装では、送信モジュール７１０は、具体的には、マルチキャストソースから送信されたユニキャストパケットを、第１のデバイスグループ内のネットワークデバイスを用いて受信するように構成され、ここで、第１のマルチキャストパケットは、ユニキャストパケットにカプセル化される。

別の可能な実装では、ユニキャストパケットの宛先アドレスは、第１デバイスグループ識別子である。

別の可能な実装では、第１の通信リンクが、正常な状態である。第１の通信リンクは、マルチキャストソースデバイスから第２のネットワークデバイスへ、そこから第１のネットワークデバイスへの通信リンクである。送信モジュール７１０は、具体的には、第１のデバイスグループ内の第２のネットワークデバイスを用いて、マルチキャストソースデバイスから受信された第１のマルチキャストパケットを第１のネットワークデバイスに転送するように構成される。

別の可能な実装では、第２の通信リンクが、正常な状態である。第２の通信リンクは、マルチキャストソースデバイスから第３のネットワークデバイスへ、そこから第１のネットワークデバイスへの通信リンクである。第１の通信リンクのメトリックは、第２の通信リンクのメトリック未満である。

別の可能な実装では、第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときには、送信モジュール７１０は、具体的には、第１のデバイスグループ内の第３のネットワークデバイスを用いて、マルチキャストソースデバイスから受信された第１のマルチキャストパケットを第１のネットワークデバイスに転送するように構成される。

図８は、本願の実施形態による第１のネットワークデバイス２０００のハードウェア構造を示す概略図である。図８に示す第１のネットワークデバイス２０００は、前述の実施形態の方法において第１のネットワークデバイスによって実行される対応するステップを実行し得る。

図８に示すように、第１のネットワークデバイス２０００は、プロセッサ２００１、メモリ２００２、インタフェース２００３、およびバス２００４を含む。インタフェース２００３は、ワイヤレスまたは有線で実装され得、具体的にはネットワークアダプタであることがある。プロセッサ２００１と、メモリ２００２と、インタフェース２００３とは、バス２００４を介して接続される。

インタフェース２００３は、具体的には、伝送器および受信器を含むことがあり、第１のネットワークデバイスが前述の受信および送信を実施するように構成される。例えば、インタフェース２００３は、マルチキャストソースデバイスから送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信することをサポートするように構成される。別の例では、インタフェースは、ＲＰＦエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信することをサポートするように構成される。別の例では、インタフェースは、第２のサブエントリに従って第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信することをサポートするように構成される。

プロセッサ２００１は、前述の実施形態において第１のネットワークデバイスによって実行される処理を実行するように構成される。例えば、プロセッサは、リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定し、第２の識別子に基づいて第１のサブエントリを生成し、第３の識別子に基づいて第２のサブエントリを生成し、かつ／または本明細書に記載される技術のためのその他のプロセスを実行するように構成される。

例えば、プロセッサ２００１は、図４Ａおよび図４Ｂのステップ４１０から４９５をサポートするように構成される。メモリ２００２は、オペレーティングシステム２００２１およびアプリケーション２００２２を含み、プログラム、コード、または命令を記憶するように構成される。プログラム、コード、または命令を実行するときには、プロセッサまたはハードウェアデバイスは、方法の実施形態における第１のネットワークデバイスの処理プロセスを完了することがある。任意選択で、メモリ２００２は、読取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）およびランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）を含むことがある。ＲＯＭは、基本入出力システム（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ、ＢＩＯＳ）または埋込み型システムを含み、ＲＡＭは、アプリケーションおよびオペレーティングシステムを含む。第１のネットワークデバイス２０００がランする必要があるときには、ＲＯＭに組み込まれたＢＩＯＳまたは埋込み型システムのブートローダが使用されて、システムをブートして始動させ、第１のネットワークデバイス２０００をブートして通常のラン状態に入らせる。通常のラン状態に入った後で、第１のネットワークデバイス２０００は、ＲＡＭ中のアプリケーションおよびオペレーティングシステムをランして、方法の実施形態における第１のネットワークデバイス２０００の処理プロセスを完了する。

図８は、第１のネットワークデバイス２０００の簡略化された設計しか示していないことは理解され得る。実際の適用では、第１のネットワークデバイスは、任意の数量のインタフェース、プロセッサ、またはメモリを含み得る。

図９は、本願の実施形態による別の第１のネットワークデバイス２１００のハードウェア構造を示す概略図である。図９に示す第１のネットワークデバイス２１００は、前述の実施形態の方法において第１のネットワークデバイスによって実行される対応するステップを実行し得る。

図９に示すように、第１のネットワークデバイス２１００は、主制御ボード２１１０、インタフェースボード２１３０、スイッチングボード２１２０およびインタフェースボード２１４０を含む。主制御ボード２１１０と、インタフェースボード２１３０および２１４０と、スイッチングボード２１２０とは、システムバスを介してシステムバックボードに接続されて、相互動作する。主制御ボード２１１０は、システム管理、デバイス保守、およびプロトコル処理などの機能を完了するように構成される。スイッチングボード２１２０は、インタフェースボードの間でデータを交換するように構成される（インタフェースボードは、ラインカードまたはサービスボードとも呼ばれる）。インタフェースボード２１３０および２１４０は、様々なサービスインタフェース（例えばＰＯＳインタフェース、ＧＥインタフェース、およびＡＴＭインタフェース）を提供し、データパケットを転送するように構成される。

インタフェースボード２１３０は、中央処理装置２１３１、転送エントリメモリ２１３４、物理インタフェースカード２１３３、およびネットワークプロセッサ２１３２を含むことがある。中央処理装置２１３１は、インタフェースボードを制御および管理し、主制御ボード上の中央処理装置と通信するように構成される。転送エントリメモリ２１３４は、ＲＰＦエントリを記憶するように構成される。物理インタフェースカード２１３３は、トラフィックを受信および送信するように構成される。ネットワークプロセッサ２１３２は、エントリに基づいて、トラフィックを受信および送信するように物理インタフェースカード２１３３を制御するように構成される。

具体的には、物理インタフェースカード２１３３は、マルチキャストソースデバイスから送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信するように構成される。第１のマルチキャストパケットを受信した後で、物理インタフェースカード２１３３は、中央処理装置２１３１を使用して、第１のマルチキャストパケットを中央処理装置２１１１に送信する。中央処理装置２１１１は、第１のマルチキャストパケットを処理する。

中央処理装置２１１１は、リバースパス転送ＲＰＦエントリに従って、第１のマルチキャストパケットが第１のデバイスグループによって転送されたマルチキャストパケットであると決定し、かつ／または本明細書に記載される技術のためのその他のプロセスを実行するようにさらに構成される。

本願の本実施形態では、インタフェースボード２１４０上の動作は、インタフェースボード２１３０上の動作と矛盾しないことを理解されたい。簡潔にするために、詳細は説明しない。本実施形態の第１のネットワークデバイス２１００は、方法の実施形態における機能および／または様々な実施されるステップに対応することがあることを理解されたい。本明細書では、詳細について重ねて述べることはしない。

さらに、１つまたは複数の主制御ボードがあることもあり、複数の主制御ボードがあるときには、それらの主制御ボードは、アクティブな主制御ボードと、待機中の主制御ボードとを含むことがあることに留意されたい。１つまたは複数のインタフェースボードがあることもある。より強いデータ処理能力を有する第１のネットワークデバイスは、より多くのインタフェースボードを提供する。インタフェースボード上に、１つまたは複数の物理インタフェースカードがあることもある。スイッチングボードがないこともあるし、１つまたは複数のスイッチングボードがあることもある。複数のスイッチングボードがあるときには、負荷分担および冗長バックアップがともに実施されることもある。集中型の転送アーキテクチャでは、第１のネットワークデバイスは、スイッチングボードを必要としないこともあり、インタフェースボードが、システム全体のサービスデータを処理する機能を提供する。分散型の転送アーキテクチャでは、第１のネットワークデバイスは、少なくとも１つのスイッチングボードを有することがあり、複数のインタフェースボードの間のデータ交換がスイッチングボードを使用して実施されて、大容量のデータの交換および処理能力を提供する。したがって、分散型のアーキテクチャにおける第１のネットワークデバイスのデータアクセスおよび処理能力は、集中型のアーキテクチャにおけるデバイスより良好である。使用される具体的なアーキテクチャは、特定のネットワーキング展開シナリオによって決まる。これは、本明細書では限定されない。

本願の実施形態は、コンピュータプログラムを記憶するように構成されたコンピュータ可読媒体をさらに提供する。コンピュータプログラムは、前述の態様のうちのいずれか１つの任意の可能な実装における方法を実行するために使用される命令を含む。可読媒体は、読取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）およびランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）であることがある。これは、本願の実施形態では限定されない。

本願の実施形態は、コンピュータプログラム製品をさらに提供する。このコンピュータプログラム製品は、第１のネットワークデバイスに適用され、このコンピュータプログラム製品は、命令のシリーズを含む。命令が実行されたときに、前述の態様による方法における第１のネットワークデバイスの動作が実行される。

本願の実施形態は、コンピュータプログラム製品をさらに提供する。このコンピュータプログラム製品は、第１のデバイスグループに適用され、このコンピュータプログラム製品は、命令のシリーズを含む。命令が実行されたときに、前述の態様による方法における第１のデバイスグループの動作が実行される。

前述のプロセスの一連番号は、本願の様々な実施形態における実行順序を意味しているわけではないことを理解されたい。プロセスの実行順序は、それらのプロセスの機能および内部論理に従って決定されるものとし、本願の実施形態の実施プロセスに対するいかなる限定であるとも解釈されるべきではない。

当業者なら、本明細書に開示される実施形態において記載される例と組み合わせて、電子ハードウェア、またはコンピュータソフトウェアと電子ハードウェアの組合せによってユニットおよびアルゴリズムステップが実装され得ることに気づき得る。機能がハードウェアによって実行されるかソフトウェアによって実行されるかは、技術的解決策の特定の適用分野および設計制約条件によって決まる。当業者なら、様々な方法を使用して、記載される機能をそれぞれの特定の適用分野のために実装し得るが、その実装が本願の範囲を超えるものと考えるべきではない。

便利かつ簡潔な説明にするために、前述のシステム、装置、およびユニットの詳細な動作プロセスについては、方法の実施形態における対応するプロセスを参照することは、当業者には明確に理解され得る。本明細書では、詳細について重ねて述べることはしない。

本願で提供されるいくつかの実施形態では、開示されるシステム、装置、および方法は、他のやり方で実装されることもあることを理解されたい。例えば、記載される装置の実施形態は、単なる例である。例えば、ユニットへの分割は、単に論理機能の分割であり、実際の実装ではほかの分割もあり得る。例えば、複数のユニットまたは構成要素が、別のシステムに結合または統合されることもあるし、いくつかの特徴が無視される、または実行されないこともある。さらに、表示または記載される相互の結合または直接的な結合もしくは通信接続は、いくつかのインタフェースを介して実装され得る。装置またはユニットの間の間接的な結合または通信接続は、電子的形態、機械的形態、またはその他の形態で実装され得る。

別個の部分として記載されるユニットは、物理的に分離していることも分離していないこともあり、ユニットとして表示される部分は、物理ユニットであることも物理ユニットでないこともあり、１つの位置に位置していることもあり、または複数のネットワークユニット上に分散されていることもある。これらのユニットの一部または全てが実際の要件に従って選択されて、実施形態の解決策の目的を達成し得る。

さらに、本願の実施形態における機能ユニットは、１つの処理ユニットに統合されることもあるし、それらのユニットのそれぞれが物理的に単独で存在することもあるし、２つ以上のユニットが１つのユニットに統合されることもある。

機能がソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用されるときには、これらの機能は、コンピュータ可読記憶媒体に記憶されることがある。このような理解に基づいて、本願の技術的解決策、従来の技術に寄与する部分、またはこれらの技術的解決策の一部は、ソフトウェア製品の形態で実装されることがある。コンピュータソフトウェア製品は、記憶媒体に記憶され、コンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスであり得る）に本願の実施形態において記載される方法のステップの全てまたは一部を実行するように命令するいくつかの命令を含む。前述の記憶媒体は、プログラムコードを記憶することができる任意の媒体、ＵＳＢフラッシュドライブ、取外し可能ハードディスク、読取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク、または光ディスクを含む。

以上の説明は、単に本願の具体的な実装であり、本願の保護範囲を限定することが意図されているわけではない。本願に開示される技術的範囲内の当業者には容易に分かる任意の変形または置換は、本願の保護範囲に含まれるものとする。したがって、本願の保護範囲は、特許請求の範囲の保護範囲によって決まるものとする。

Claims

パケット転送方法であって、前記方法は、
第１のネットワークデバイスが、第２のネットワークデバイスによって送信された第１の制御情報を受信するステップであって、前記第１の制御情報は、第２の識別子を含み、前記第２の識別子は、前記第２のネットワークデバイスの識別子である、ステップと、
前記第１のネットワークデバイスが、前記第２の識別子に基づいて第１のサブエントリを生成するステップであって、前記第１のサブエントリは、前記第２の識別子と第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）情報との間の対応である、ステップと、
前記第１のネットワークデバイスが、第３のネットワークデバイスによって送信された第２の制御情報を受信するステップであって、前記第２の制御情報は、第３の識別子を含み、前記第３の識別子は、前記第３のネットワークデバイスの識別子である、ステップと、
前記第１のネットワークデバイスが、前記第３の識別子に基づいて第２のサブエントリを生成するステップであって、前記第２のサブエントリは、前記第３の識別子と前記第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）情報との間の対応である、ステップと、
第１のネットワークデバイスが、マルチキャストソースデバイスによって送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信するステップであって、前記第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、前記第１のマルチキャストパケットは、前記第１のデバイスグループ中の１つのネットワークデバイスによって前記第１のネットワークデバイスに転送される、ステップと、
前記第１のネットワークデバイスが、前記第１のマルチキャストパケットに含まれるマルチキャストソースグループ（Ｓ、Ｇ）情報およびリバースパス転送（ＲＰＦ）エントリに従って、前記第１のマルチキャストパケットが前記第１のデバイスグループによって転送されたマルチキャストパケットであると決定するステップであって、前記ＲＰＦエントリは、前記第１のデバイスグループ内のネットワークデバイスによって送信された前記第１のマルチキャストパケットを転送するように、前記第１のネットワークデバイスに指示し、前記ＲＰＦエントリは、前記第１のサブエントリおよび前記第２のサブエントリを含み、前記第１のサブエントリは、前記第１のネットワークデバイスに前記第２のネットワークデバイスによって送信された前記第１のマルチキャストパケットを転送するように指示し、前記第２のサブエントリは、前記第１のネットワークデバイスに前記第３のネットワークデバイスによって送信された前記第１のマルチキャストパケットを転送するように指示する、ステップと、
前記第１のネットワークデバイスが、前記ＲＰＦエントリに従って前記第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するステップと
を備える、パケット転送方法。
第１の通信リンクが正常な状態であり、前記第１の通信リンクは、前記マルチキャストソースデバイスから前記第２のネットワークデバイスへの、またそこから前記第１のネットワークデバイスへの通信リンクであり、
前記第１のネットワークデバイスが前記ＲＰＦエントリに従って前記第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信する前記ステップは、
前記第１のネットワークデバイスが、前記第１のサブエントリに従って前記第１のマルチキャストパケットを前記マルチキャスト宛先デバイスに送信するステップを備える請求項１に記載の方法。
第２の通信リンクが正常な状態であり、前記第２の通信リンクは、前記マルチキャストソースデバイスから前記第３のネットワークデバイスへの、またそこから前記第１のネットワークデバイスへの通信リンクであり、
前記第１のネットワークデバイスがマルチキャストソースデバイスによって送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信する前記ステップは、
前記第１のネットワークデバイスが、前記第１の通信リンクを介して転送された前記第１のマルチキャストパケットを受信するステップを備え、前記第１の通信リンクのメトリックは、前記第２の通信リンクのメトリック未満である請求項２に記載の方法。
第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときに、
前記第１のネットワークデバイスが前記ＲＰＦエントリに従って前記第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信する前記ステップは、
前記第１のネットワークデバイスが、前記第２のサブエントリに従って前記第１のマルチキャストパケットを前記マルチキャスト宛先デバイスに送信するステップを備える請求項１に記載の方法。
前記第２の識別子および前記第３の識別子は、インターネットプロトコル（ＩＰ）アドレス、またはインターネットプロトコルバージョン６（ＩＰｖ６）アドレスである請求項４に記載の方法。
前記第１の制御情報は、第１デバイスグループ識別子をさらに含み、前記第２の制御情報は、前記第１デバイスグループ識別子をさらに含み、前記第１デバイスグループ識別子は、前記第１のデバイスグループの識別子であり、前記方法は、
前記ＲＰＦエントリが確立されるとき、前記第１のネットワークデバイスが、前記第１デバイスグループ識別子に基づいて前記ＲＰＦエントリを識別するステップをさらに備える請求項４または５に記載の方法。
前記第１デバイスグループ識別子は、ＩＰアドレス、ＩＰｖ６アドレス、または整数である請求項６に記載の方法。
記載の方法。
第１のネットワークデバイスであって、
マルチキャストソースデバイスによって送信され、第１のデバイスグループによって転送された第１のマルチキャストパケットを受信するように構成された受信モジュールであって、前記第１のデバイスグループは、第２のネットワークデバイスおよび第３のネットワークデバイスを含み、前記第１のマルチキャストパケットは、前記第１のデバイスグループ中の１つのネットワークデバイスによって前記第１のネットワークデバイスに転送される、受信モジュールと、
前記第１のマルチキャストパケットに含まれるマルチキャストソースグループ（Ｓ、Ｇ）情報およびリバースパス転送（ＲＰＦ）エントリに従って、前記第１のマルチキャストパケットが前記第１のデバイスグループによって転送されたマルチキャストパケットであると決定するように構成された決定モジュールであって、前記ＲＰＦエントリは、前記第１のデバイスグループ内のネットワークデバイスによって送信された前記第１のマルチキャストパケットを転送するように、前記第１のネットワークデバイスに指示し、前記ＲＰＦエントリは、第１のサブエントリおよび第２のサブエントリを含み、前記第１のサブエントリは、前記第１のネットワークデバイスに前記第２のネットワークデバイスによって送信された前記第１のマルチキャストパケットを転送するように指示し、前記第２のサブエントリは、前記第１のネットワークデバイスに前記第３のネットワークデバイスによって送信された前記第１のマルチキャストパケットを転送するように指示する、決定モジュールと、
前記ＲＰＦエントリに従って前記第１のマルチキャストパケットをマルチキャスト宛先デバイスに送信するように構成された送信モジュールと
を備え、
前記受信モジュールは、前記第２のネットワークデバイスによって送信された第１の制御情報を受信するようにさらに構成され、前記第１の制御情報は、第２の識別子を含み、前記第２の識別子は、前記第２のネットワークデバイスの識別子であり、
生成モジュールは、前記第２の識別子に基づいて前記第１のサブエントリを生成するように構成され、前記第１のサブエントリは、前記第２の識別子と前記第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）情報との間の対応であり、
前記受信モジュールは、前記第３のネットワークデバイスによって送信された第２の制御情報を受信するようにさらに構成され、前記第２の制御情報は、第３の識別子を含み、前記第３の識別子は、前記第３のネットワークデバイスの識別子であり、
前記生成モジュールは、前記第３の識別子に基づいて前記第２のサブエントリを生成するようにさらに構成され、前記第２のサブエントリは、前記第３の識別子と前記第１のマルチキャストパケットに対応するマルチキャストソースグループ（Ｓ、Ｇ）情報との間の対応である
第１のネットワークデバイス。
第１の通信リンクが正常な状態であり、前記第１の通信リンクは、前記マルチキャストソースデバイスから前記第２のネットワークデバイスへの、またそこから前記第１のネットワークデバイスへの通信リンクであり、
前記送信モジュールは、具体的には、前記第１のサブエントリに従って前記第１のマルチキャストパケットを前記マルチキャスト宛先デバイスに送信するように構成される請求項８に記載の第１のネットワークデバイス。
第２の通信リンクが正常な状態であり、前記第２の通信リンクは、前記マルチキャストソースデバイスから前記第３のネットワークデバイスへの、またそこから前記第１のネットワークデバイスへの通信リンクであり、
前記受信モジュールは、具体的には、前記第１の通信リンクを介して転送された前記第１のマルチキャストパケットを受信するように構成され、前記第１の通信リンクのメトリックは、前記第２の通信リンクのメトリック未満である請求項９に記載の第１のネットワークデバイス。
第１の通信リンクが障害状態であり、第２の通信リンクが正常な状態であるときに、
前記送信モジュールは、具体的には、前記第２のサブエントリに従って前記第１のマルチキャストパケットを前記マルチキャスト宛先デバイスに送信するように構成される請求項８に記載の第１のネットワークデバイス。
前記第２の識別子および前記第３の識別子は、インターネットプロトコル（ＩＰ）アドレス、またはインターネットプロトコルバージョン６（ＩＰｖ６）アドレスである請求項１１に記載の第１のネットワークデバイス。
前記第１の制御情報は、第１デバイスグループ識別子をさらに含み、前記第２の制御情報は、前記第１デバイスグループ識別子をさらに含み、前記第１デバイスグループ識別子は、前記第１のデバイスグループの識別子であり、
前記決定モジュールは、具体的には、前記ＲＰＦエントリが確立されるとき、前記第１デバイスグループ識別子に基づいて前記ＲＰＦエントリを識別するように構成される請求項１１または１２に記載の第１のネットワークデバイス。
前記第１デバイスグループ識別子は、ＩＰアドレス、ＩＰｖ６アドレス、または整数である請求項１３に記載の第１のネットワークデバイス。
プロセッサおよびメモリを備える第１のネットワークデバイスであって、前記メモリは、プログラムを記憶するように構成され、前記プロセッサは、前記メモリから前記プログラムを呼び出し、前記プログラムをランして請求項１乃至７のいずれか一項に記載の方法を実行するように構成される、第１のネットワークデバイス。
コンピュータプログラムを備えるコンピュータ可読記憶媒体であって、前記コンピュータプログラムがコンピュータ上でランされたときに、前記コンピュータが請求項１乃至７のいずれか一項に記載の方法を実行することができるようになる、コンピュータ可読記憶媒体。