JP7273125B2

JP7273125B2 - ＢＩＥＲｖ６パケットを送信するための方法および第１のネットワークデバイス

Info

Publication number: JP7273125B2
Application number: JP2021177794A
Authority: JP
Inventors: リンシュアイ・リ; ジンロン・シエ
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-10-30
Filing date: 2021-10-29
Publication date: 2023-05-12
Anticipated expiration: 2041-10-29
Also published as: CN114520762A; US11784919B2; EP3993357A1; CN114520762B; JP2022074129A; US20220141127A1

Description

本出願は、ネットワーク通信分野に関し、より具体的には、インターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するための方法および第1のネットワークデバイスに関する。

インターネットプロトコル（internet protocol、IP）マルチキャスト技術は、ネットワーク帯域幅を効果的に低減し、ネットワーク負荷を低減するために、IPネットワークにおいて高効率ポイントツーマルチポイントデータ送信を実現し、したがって、リアルタイムデータ送信、マルチメディア会議、データコピー、インターネットプロトコルテレビジョン（internet protocol television、IPTV）、ゲーム、およびシミュレーションなどの複数の態様で広く適用される。マルチキャスト技術では、マルチキャストプロトコルを使用して制御プレーン上にマルチキャストツリーが構築され、次いで、マルチキャストツリーを使用してネットワークプレーン上のロジックがツリー状にされて、マルチキャストポイントツーマルチポイントデータ転送を実現する。分散ツリーの構造物をコアとして使用する各中間デバイスは、複雑なマルチキャスト転送情報ステータスを維持する必要がある。ネットワーク規模がますます大きくなり、マルチキャストデータトラフィックが時間とともに増加するにつれて、このマルチキャスト技術は、コストならびに動作および保守の点でますます大きな課題に直面している。

したがって、マルチキャストデータ転送経路を構築するための新しい技術が業界で提案されており、それはビットインデックス明示的複製（bit index explicit replication、BIER）技術と呼ばれている。この技術は、マルチキャスト分散ツリーが構築される必要がないマルチキャスト技術アーキテクチャを提案する。BIERドメインは、異なるエリアに分割されてもよく、異なるプロトコルがエリア内に配備される。BIERドメインが第1のエリアおよび第2のエリアを含み、第1のエリア内の第1のネットワークデバイスがそれを介して第2のエリアに到達するアクティブネクストホップデバイスが故障している場合、BIERドメイン内の第1のエリア内のトラフィックをBIERドメイン内の第2のエリアに送信することができず、トラフィックの中断が発生する。第2のエリア内のアクティブネクストホップデバイスは、第1のエリアに接続するように構成された第2のエリア内の境界デバイスである。

したがって、BIERドメイン内の第2のエリア内のアクティブネクストホップデバイスが故障しているときに、BIERドメイン内の第1のエリアからBIERドメイン内の第2のエリアへのトラフィックの中断をどのように回避するかは、緊急に解決される必要がある技術的問題になる。

本出願は、インターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するための方法および第1のネットワークデバイスを提供する。BIERドメイン内の第2のエリア内のアクティブネクストホップデバイスが故障しているとき、BIERドメイン内の第1のエリア内のトラフィックはBIERドメイン内の第2のエリアに転送され、それにより、BIERドメイン内の第1のエリアからBIERドメイン内の第2のエリアへのトラフィックの中断が回避される。

第1の態様によれば、インターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するための方法が提供され、方法は、第1のネットワークデバイスにより、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断するステップであって、第1のネットワークデバイスがBIERドメイン内の入口デバイスであり、第2のネットワークデバイスがBIERドメイン内の出口デバイスであり、第1のネットワークデバイスがBIERドメイン内の第1のエリアに属し、第2のネットワークデバイスおよびアクティブネクストホップデバイスがBIERドメイン内の第2のエリアに属し、アクティブネクストホップデバイスが第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成され、第1のエリアと第2のエリアが異なるプロトコルを有する、ステップと、第1のネットワークデバイスにより、第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにBIERv6パケットを送信するステップであって、バックアップネクストホップデバイスが第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成される、ステップとを含む。

前述の技術的解決策では、BIERドメイン内の第1のエリア内の第1のネットワークデバイスがそれを介してBIERドメインの第2のエリアに到達するアクティブネクストホップデバイスが故障しているとき、第2のエリアを介して第1のエリアに接続する境界デバイスは、第1のネットワークデバイスのバックアップネクストホップデバイスとして設定されてもよい。このようにして、第1のエリア内の第1のネットワークデバイスは、バックアップネクストホップデバイスを使用して第1のエリアから第2のエリアにBIERv6パケットを転送することができ、その結果、BIERドメイン内の第2のエリア内のアクティブネクストホップデバイスが故障しているとき、BIERドメイン内の第1のエリア内のトラフィックはBIERドメイン内の第2のエリアに転送され、それにより、BIERドメイン内の第1のエリアからBIERドメイン内の第2のエリアへのトラフィックの中断が回避される。

可能な実装形態では、方法は、第1のネットワークデバイスにより、BIERドメインのネットワークトポロジーに基づいて、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスおよびバックアップネクストホップデバイスを決定するステップをさらに含む。

別の可能な実装形態では、第1のネットワークデバイスは、双方向転送検出BFD制御パケットをアクティブネクストホップデバイスに送信し、BFD制御パケットの宛先アドレスはアクティブネクストホップデバイスの第1のアドレスであり、第1のアドレスは、BIERv6パケットに対してBIER転送を実行するようにアクティブネクストホップデバイスに指示するために使用される。第1のネットワークデバイスが、事前設定された時間間隔内に、アクティブネクストホップデバイスによって送信されたBFD制御パケットを受信しない場合、第1のネットワークデバイスは、アクティブネクストホップデバイスが故障していると判断する。

前述の技術的解決策では、アクティブネクストホップデバイスにBFD制御パケットを送信するとき、第1のネットワークデバイスは、BIERv6パケットに対してBIER転送を実行するように指示するために使用される、アクティブネクストホップデバイスの特殊アドレスを使用することができる。このようにして、アクティブネクストホップデバイスがBIER転送をサポートしていないとき、第1のネットワークデバイスもこのケースを迅速に認識することができ、それにより、デバイス間の故障検出の精度がさらに向上する。

別の可能な実装形態では、アクティブネクストホップデバイスが故障していることは、以下のケース、すなわち、アクティブネクストホップデバイス自体が故障しているケース、アクティブネクストホップデバイスと第1のネットワークデバイスとの間の通信リンクが故障しているケース、またはアクティブネクストホップデバイスがBIERv6パケットに対するBIER転送をサポートしていないケースのうちの1つまたは複数を含む。

第2の態様によれば、第1のネットワークデバイスが提供され、第1のネットワークデバイスは、
第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断するように構成された処理モジュールであって、第1のネットワークデバイスがBIERドメイン内の入口デバイスであり、第2のネットワークデバイスがBIERドメイン内の出口デバイスであり、第1のネットワークデバイスがBIERドメイン内の第1のエリアに属し、第2のネットワークデバイスおよびアクティブネクストホップデバイスがBIERドメイン内の第2のエリアに属し、アクティブネクストホップデバイスが第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成され、第1のエリアと第2のエリアが異なるプロトコルを有する、処理モジュールと、
第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにインターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するように構成された送信モジュールであって、バックアップネクストホップデバイスが第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成される、送信モジュールと
を含む。

可能な実装形態では、処理モジュールは、BIERドメインのネットワークトポロジーに基づいて、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスおよびバックアップネクストホップデバイスを決定するようにさらに構成される。

別の可能な実装形態では、送信モジュールは、双方向転送検出BFD制御パケットをアクティブネクストホップデバイスに送信するようにさらに構成され、BFD制御パケットの宛先アドレスはアクティブネクストホップデバイスの第1のアドレスであり、第1のアドレスは、BIERv6パケットに対してBIER転送を実行するようにアクティブネクストホップデバイスに指示するために使用され、
処理モジュールは、アクティブネクストホップデバイスによって送信されたBFD制御パケットが、事前設定された時間間隔内に受信されない場合、アクティブネクストホップデバイスが故障していると判断するようにさらに構成される。

第2の態様および第2の態様の任意の可能な実装形態の有利な効果は、第1の態様および第1の態様の任意の可能な実装形態の有利な効果に対応し、詳細は本明細書では再び記載されない。

第3の態様によれは、第1のネットワークデバイスが提供され、第1のネットワークデバイスは、前述の方法における第1のネットワークデバイスの挙動を実装する機能を有する。機能は、ハードウェアに基づいて実装されてもよく、対応するソフトウェアを実行するハードウェアに基づいて実装されてもよい。ハードウェアまたはソフトウェアは、前述の機能に対応する1つまたは複数のモジュールを含む。

可能な設計では、第1のネットワークデバイスの構造はプロセッサおよびインターフェースを含み、プロセッサは、前述の方法における対応する機能を実行する際に第1のネットワークデバイスをサポートするように構成される。インターフェースは、BIERv6パケットを受信する際に第1のネットワークデバイスをサポートするように構成されるか、または第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにBIERv6パケットを送信する際に第1のネットワークデバイスをサポートするように構成される。

第1のネットワークデバイスは、メモリをさらに含んでもよい。メモリは、プロセッサに接続され、第1のネットワークデバイスに必要なプログラム命令およびデータを記憶するように構成される。

別の可能な設計では、第1のネットワークデバイスは、プロセッサ、送信機、受信機、ランダムアクセスメモリ、読取り専用メモリ、およびバスを含む。プロセッサは、バスを介して、送信機、受信機、ランダムアクセスメモリ、および読取り専用メモリに別々に接続される。第1のネットワークデバイスが実行される必要があるとき、基本入出力システムまたは読取り専用メモリ内に固定された組込み型システム内のブートローダは、起動されるべきシステムを誘導し、通常の動作状態に入るように第1のネットワークデバイスを誘導するために使用される。通常の動作状態に入った後、第1のネットワークデバイスは、ランダムアクセスメモリ内でアプリケーションプログラムおよびオペレーティングシステムを実行し、その結果、プロセッサは、第1の態様または第1の態様の任意の可能な実装形態における方法を実行する。

第4の態様によれば、第1のネットワークデバイスが提供される。第1のネットワークデバイスは、主制御ボードおよびインターフェースボードを含み、スイッチングボードをさらに含んでもよい。第1のネットワークデバイスは、第1の態様または第1の態様の任意の可能な実装形態における方法を実行するように構成される。具体的には、第1のネットワークデバイスは、第1の態様または第1の態様の任意の可能な実装形態における方法を実行するように構成されたモジュールを含む。

第5の態様によれば、第1のネットワークデバイスが提供される。第1のネットワークデバイスは、制御モジュールおよび第1の転送サブデバイスを含む。第1の転送サブデバイスはインターフェースボードを含み、スイッチングボードをさらに含んでもよい。第1の転送サブデバイスは、第4の態様におけるインターフェースボードの機能を実行するように構成され、第4の態様におけるスイッチングボードの機能をさらに実行することができる。制御モジュールは、受信機、プロセッサ、送信機、ランダムアクセスメモリ、読取り専用メモリ、およびバスを含む。プロセッサは、バスを介して、受信機、送信機、ランダムアクセスメモリ、および読取り専用メモリに別々に結合される。制御モジュールが実行される必要があるとき、基本入出力システムまたは読取り専用メモリ内に固定された組込み型システム内のブートローダは、起動されるシステムを誘導し、通常の動作状態に入るように制御モジュールを誘導するために使用される。通常の動作状態に入った後、制御モジュールは、ランダムアクセスメモリ内でアプリケーションプログラムおよびオペレーティングシステムを実行し、その結果、プロセッサは、第4の態様における主制御ボードの機能を実行する。

実際の適用例では、第1のネットワークデバイスは、任意の数のインターフェース、プロセッサ、またはメモリを含んでもよいことが理解されよう。

第6の態様によれば、コンピュータプログラム製品が提供される。コンピュータプログラム製品はコンピュータプログラムコードを含み、コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第1の態様または第1の態様の任意の可能な実装形態において実行される方法を実行することが可能になる。

第7の態様によれば、コンピュータ可読媒体が提供される。コンピュータ可読媒体はプログラムコードを記憶し、コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第1の態様または第1の態様の任意の可能な実装形態において実行される方法を実行することが可能になる。コンピュータ可読記憶媒体には、以下のもの、すなわち、読取り専用メモリ（read-only memory、ROM）、プログラマブルROM（programmable ROM、PROM）、消去可能PROM（erasable PROM、EPROM）、Flashメモリ、電気的EPROM（electrically EPROM、EEPROM）、またはハードドライブ（hard drive）のうちの1つまたは複数が含まれるが、それらに限定されない。

第8の態様によれば、チップが提供される。チップはプロセッサおよびデータインターフェースを含み、プロセッサは、第1の態様または第1の態様の任意の可能な実装形態における方法を実行するために、データインターフェースを介して、メモリに記憶された命令を読み取る。具体的な実装プロセスでは、チップは、中央処理装置（central processing unit、CPU）、マイクロコントローラユニット（micro controller unit、MCU）、マイクロ処理装置（micro processing unit、MPU）、デジタル信号プロセッサ（digital signal processor、DSP）、システムオンチップ（system on chip、SoC）、特定用途向け集積回路（application-specific integrated circuit、ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）、またはプログラマブルロジックデバイス（programmable logic device、PLD）の形態で実装されてもよい。

本出願の一実施形態による、BIER技術の概略ネットワーク図である。本出願の一実施形態による、可能なBIERヘッダ形式の概略図である。別の可能なBIERヘッダフォーマットの概略ブロック図である。 BIER技術に基づいてBIER転送テーブルを確立し、BIER技術に基づいてBIERパケットを転送するプロセスの図である。本出願の一実施形態による、BIERv6カプセル化の可能なパケットフォーマットの概略図である。本出願の一実施形態に適用可能なマルチエリアの概略シナリオ図である。本出願の一実施形態による、BIERv6パケットを転送するための方法の概略フローチャートである。本出願の一実施形態による、BIERv6パケットを転送するための別の方法の概略フローチャートである。本出願の一実施形態による、別のマルチエリアのネットワークトポロジーの概略図である。本出願の一実施形態による、第1のネットワークデバイス1000の概略構造図である。本出願の一実施形態による、第1のネットワークデバイス2000のハードウェア構造の概略図である。本出願の一実施形態による、別の第1のネットワークデバイス2100のハードウェア構造の概略図である。

以下では、添付図面を参照して本出願の技術的解決策を記載する。

複数のデバイス、構成要素、モジュールなどを含んでもよいシステムを記載することにより、本出願においてすべての態様、実施形態、または特徴が提示される。各システムは、別のデバイス、構成要素、モジュールなどを含んでもよく、かつ／または添付図面を参照して説明されるすべてのデバイス、構成要素、モジュールなどを含まなくてもよいことを諒解されたい。加えて、これらの解決策の組合せが使用されてもよい。

加えて、本出願の実施形態における「例」、「など」という単語は、例、例示、または説明を与えることを表すために使用される。本出願において「例」として記載される任意の実施形態または設計方式は、別の実施形態または設計方式よりも好ましい、またはより多くの利点を有するものとして説明されるべきではない。正確には、「たとえば」は、具体的に概念を提示するために使用される。

本出願の実施形態では、「該当する（corresponding、relevant）」および「対応する（corresponding）」は、時々混在して使用されてもよい。差違が強調されないとき、それらによって表現される意味は同じであることに留意されたい。

本出願の実施形態に記載されるネットワークアーキテクチャおよびサービスシナリオは、本出願の実施形態における技術的解決策をより明確に記載するものであり、本出願の実施形態で提供される技術的解決策に対する制限を構成するものではない。当業者なら、ネットワークアーキテクチャの進化および新しいサービスシナリオの出現に伴い、本出願の実施形態で提供される技術的解決策が同様の技術的問題にも適用可能であることを知ることができる。

本明細書に記載された「一実施形態」、「いくつかの実施形態」などへの言及は、実施形態を参照して記載された具体的な特徴、構造、または特徴が、本出願の1つまたは複数の実施形態に含まれることを意味する。したがって、本明細書の異なる部分に現れる「一実施形態では」、「いくつかの実施形態では」、「いくつかの他の実施形態では」、「いくつかの他の実施形態では」などの記述は、別の方式で別途具体的に強調されない限り、必ずしも同じ実施形態への言及を意味せず、「すべての実施形態ではないが1つまたは複数の実施形態」を意味する。「含む」、「備える」、「有する」という用語、およびそれらの変形形態はすべて、別の方式で別途具体的に強調されない限り、「含むが限定はされない」を意味する。

本出願では、「少なくとも1つ」は1つまたは複数を意味し、「複数の」は2つ以上を意味する。「および／または」という用語は、関連付けられた対象を記述するための関連付け関係を記載し、3つの関係が存在してもよいことを表す。たとえば、Aおよび／またはBは、Aのみが存在するケース、AとBの両方が存在するケース、およびBのみが存在するケースを示すことができ、AおよびBは単数形であっても複数形であってもよい。文字「／」は、一般に、関連付けられた対象間の「または」関係を示す。「以下の項目のうちの少なくとも1つ」または同様の表現は、単一の項目または複数の項目の任意の組合せを含む、それらの項目の任意の組合せを意味する。たとえば、a、b、またはcのうちの少なくとも1つは、a、b、c、a－b、a－c、b－c、またはa－b－cを表すことができ、a、b、およびcは、単一であってもよく、複数であってもよい。

マルチキャスト（multicast）は、1つのマルチキャストアドレスを使用して同時に、送信制御プロトコル（transmission control protocol、TCP）／インターネットプロトコル（internet protocol、IP）ネットワーク内の複数の受信側に効率よくデータを送信するデータ送信方式である。マルチキャストソースは、ネットワーク内のリンクを介してマルチキャストグループ内のマルチキャストグループメンバにマルチキャストフローを送信する。マルチキャストグループ内のすべてのマルチキャストグループメンバは、マルチキャストフローを受信することができる。マルチキャスト送信方式は、マルチキャストソースとマルチキャストグループメンバとの間のポイントツーマルチポイントデータ接続を実現する。マルチキャストフローは、各ネットワークリンク上で一度だけ送信される必要があり、マルチキャストフローは、リンクが支流を有するときのみ複製される。したがって、マルチキャスト送信方式は、データ送信効率を改善し、バックボーンネットワーク内で輻輳が発生する可能性を低減する。

したがって、マルチキャストデータ転送経路を構築するための新しい技術が業界で提案されており、それはビットインデックス明示的複製（bit index explicit replication、BIER）技術と呼ばれている。この技術は、マルチキャスト分散ツリーが構築される必要がないマルチキャスト技術アーキテクチャを提案する。図1に示されたように、BIER技術をサポートするルータはビット転送ルータ（Bit-forwarding router、BFR）と呼ばれ、BFRはBIERパケットを受信し転送することができる。1つまたは複数のBFRを含むマルチキャスト転送ドメインは、BIERドメイン（BIER domain）と呼ばれる。BIERドメインの入口において、元のマルチキャストパケットに対してBIERカプセル化を実行するBFRは、ビット転送入口ルータ（bit forwarding ingress router、BFIR）と呼ばれる。BIERドメインの出口において、BIERパケットをカプセル化解除することによって元のマルチキャストパケットを取得するBFRは、ビット転送出口ルータ（bit forwarding egress router、BFER）と呼ばれる。BIERドメイン内のBFIRおよびBFERは、BIERドメイン内のエッジBFRと呼ばれる場合があることを理解されたい。

理解を容易にするために、最初に図2～図5を参照してBIER関連技術が下記に詳細に記載される。

BIERドメインでは、BIERサブドメイン（sub-domain、SD）全体におけるグローバルに一意のビット位置（bit position）識別子が、エッジBFRに対して構成されてもよい。一例として、値は、BFR識別子（BFR identifier、BFR ID）としてエッジBFRごとに構成される。たとえば、BFR IDは、1～256の範囲の値であってもよい。BIERドメイン内のすべてのBFR IDは、ビット列（bit string）を形成する。

本出願のこの実施形態では、元のマルチキャストパケットがBIERドメイン内で送信される必要があるとき、特定のBIERヘッダがさらにカプセル化される必要がある。元のマルチキャストパケットのすべての宛先デバイスは、bit stringを使用してBIERヘッダ内でマークされる。BIERドメイン内のBFRは、元のマルチキャストパケットがすべての宛先アドレスに送信され得ることを保証するために、ビットインデックス転送テーブル（bit index forwarding table、BIFT）およびBIERヘッダ内で搬送されるbit stringに基づいて転送を実行することができる。

本出願における元のマルチキャストパケットの宛先デバイスは、複数のBFERのセットであってもよいことに留意されたい。説明を容易にするために、元のマルチキャストパケットが送信される必要がある複数のBFERのセットは、以下で宛先デバイスと呼ばれる。

BIERヘッダの後の元のマルチキャストパケットは、インターネットプロトコルバージョン6（internet protocol version 6、IPv6）マルチキャストパケットであってもよく、インターネットプロトコルバージョン4（internet protocol version 4、IPv4）マルチキャストパケットであってもよいことを理解されたい。これは本出願では特に限定されない。

BIERカプセル化は様々なタイプであってもよい。これは本出願では特に限定されない。一例では、BIERパケットは、マルチプロトコルラベルスイッチング（multiprotocol label switching、MPLS）を介してカプセル化されてもよく、このカプセル化は、BIER-MPLSカプセル化と呼ばれる場合がある。別の例では、BIERパケットは、インターネットプロトコルバージョン6（internet protocol version 6、IPv6）に基づいてカプセル化されてもよく、このカプセル化は、BIERv6カプセル化と呼ばれる場合がある。

BIER-MPLSカプセル化に関連する技術は、図2～図4を参照して以下で詳細に記載される。

BIERヘッダフォーマットは、BIERヘッダがビット列（bit string）フィールドを含む限り、本出願のこの実施形態では特に限定されない。2つの可能なBIERヘッダフォーマットは、それぞれ、図2および図3を参照して以下で詳細に記載される。

図2は、可能なBIERヘッダフォーマットの概略ブロック図である。図2に示されたように、BIERヘッダは、BIERヘッダの後の元のマルチキャストパケットのフィールドである、20ビットの長さを有するビットインデックス転送テーブル識別子（bit index forwarding table identifier、BIFT ID）、ビット列長（bit string length、BSL）、および64ビット（8バイト）の他のフィールド、たとえば、トラフィッククラス（traffic class、TC）、スタック（stack、S）、生存時間（time to live、TTL）フィールド、エントロピー（entropy）フィールド、バージョン番号（version、Ver）フィールド、ニブル（nibble）フィールド、プロトコル（protocol、proto）フィールド、運用、管理、および保守（operation, administration and maintenance、OAM）フィールド、リザーブ（reserve、Rsv）フィールド、ならびに差分サービスコードポイント（differential service code point、DSCP）フィールドを含んでもよいが、それらに限定されない。

BIERヘッダ内のフィールドは、以下で詳細に個別に記載される。

（1）BIFT IDフィールド
BIFT IDフィールドは、20ビットの長さを有し、BIER－マルチプロトコルラベルスイッチング（multiprotocol label switching、MPLS）カプセル化におけるMPLSラベル（label、L）である。MPLSラベルは、BIERラベルと呼ばれる場合がある。BIERラベルに続くTC／S／TTLなどのフィールドは、標準的なラベルコーディングフォーマットである。TC／S／TTLなどのフィールドは、以下で個別に記載され、詳細は本明細書では記載されない。

BIFT IDは、BIFT-idであってもよく、サブドメイン（sub-domain、SD）／ビット列長（bit string length、BSL）／セット識別子（set identifier、SI）の組合せを含んでもよい。異なるBIFT IDは、異なるSD／BSL／SIの組合せに対応してもよい。

異なるBIFT IDは、異なるSD／BSL／SIの組合せを策定できることを理解されたい。図2に示されたBIERヘッダフォーマットは、フィールドSD／BSL／SIを直接含まず、SD／BSL／SIは3つの暗黙のフィールドであり、SD／BSL／SIの値は、BIFT IDフィールドに基づいて策定される必要がある。

1．サブドメイン（sub-domain、SD）
1つのBIERドメインは、内部ゲートウェイプロトコル（interior gateway protocol、IGP）のマルチトポロジー機能などをサポートするために、実際のサービスシナリオの要件に基づいて異なるサブドメインSDに分割され構成されてもよい。各BIERドメインは、少なくとも1つのsub-domain、すなわち、デフォルトのsub-domain 0を含む必要がある。複数のサブドメインが分割を介して取得されたとき、BIERドメイン内のBFRごとにすべてのサブドメインが構成される必要がある。たとえば、sub-domain 0はBIERドメイン内の各BFR上に構成されてもよく、システム内のデフォルトトポロジーが使用され、sub-domain 1はBFR上にさらに構成されてもよく、マルチキャストトポロジーが使用される。

各サブドメインSDは、サブドメイン識別子（sub-domain identifier、SD-ID）によって表される。たとえば、SD-IDの値は［0-255］であり、SD-IDの長さは8ビットである。一例では、BIERドメインは、異なる仮想プライベートネットワーク（virtual private network、VPN）に基づいて、異なるSDに構成されてもよく、異なるVPNは異なるSDを使用するように構成される。たとえば、VPN1はSD0を使用し、VPN2はSD1を使用する。

複数のVPNが代替として同じSDを使用してもよいことに留意されたい。BIERドメイン内の異なるSDは、1つの内部ゲートウェイプロトコル（interior gateway protocol、IGP）プロセスまたはトポロジー内にあってもよく、1つのIGPプロセスまたはトポロジー内になくてもよい。これは本出願のこの実施形態では特に限定されない。

2．ビット列長（bit string length、BSL）
BSLは、BIERヘッダに含まれるbit stringの長さである。BSLは、様々なタイプであってもよい。これは本出願のこの実施形態では特に限定されない。最小のBSLは64ビットを有し、BSLは、順次128ビット、256ビット、512ビット、1024ビット、および2048ビットをさらに有してもよく、最大のBSLは4096ビットを有する。具体的には、BSLは、パケット内で4ビットによって識別される。たとえば、BSLが64ビットを有するとき、BSLはパケット内で0001によって識別され、BSLが128ビットを有するとき、BSLはパケット内で0010によって識別され、BSLが512ビットを有するとき、BSLはパケット内で0100によって識別され、BSLが1024ビットを有するとき、BSLはパケット内で0101によって識別され、以下同様である。

3．セット識別子（set identifier、SI）
ネットワーク内のBFERデバイスの数が256より大きい場合、このケースに適応するために、BIERカプセル化は、Bitstringだけでなく、セット識別子（set identifier、SI）も含む。SIは、より大規模なネットワークアドレス指定をサポートするために、BIERデバイスの数を複数の異なる間隔に分割することが意図される。

SIは、ネットワーク内の複数のエッジBFRを含むか、または構成されたBFR IDを含むセットとして理解されてもよい。一例では、BSLは256ビットを有するが、ネットワーク内に256を超えるエッジBFRが存在するか、または256を超える構成されたBFR IDが存在する。この場合、これらのエッジBFRまたはBFR IDは、異なるセットに分割される必要がある。たとえば、BFR IDが1から256の範囲の256個のエッジBFRは、セット0（set index 0、またはSI＝0）を形成し、BFR IDが257から512の範囲の256個のエッジBFRは、セット1（set index 1、またはSI＝1）を形成する。

BIERパケットを受信した後、BIERドメイン内のBFRは、BIERヘッダ内のBIFT IDに基づいて、BIERパケットが属する特定のSD、使用されたBSL、およびパケットが属するBSLの特定のSIのセットを特定することができる。

いくつかの可能なBIFT IDによって表された対応するSD／BSL／SIの組合せが以下に列挙される。
BIFT ID＝1：corresponding to SD0、BSL256、SI0 //SD0／BSL256／SI0に相当する
BIFT ID＝2：corresponding to SD0、BSL256、SI1 //SD0／BSL256／SI1に相当する
BIFT ID＝3：corresponding to SD0、BSL256、SI2 //SD0／BSL256／SI2に相当する
BIFT ID＝4：corresponding to SD0、BSL256、SI3 //SD0／BSL256／SI3に相当する
BIFT ID＝5：corresponding to SD0、BSL512、SI0 //SD0／BSL512／SI0に相当する
BIFT ID＝6：corresponding to SD0、BSL512、SI1 //SD0／BSL512／SI1に相当する
BIFT ID＝7：corresponding to SD1、BSL256、SI0 //SD1／BSL256／SI0に相当する
BIFT ID＝8：corresponding to SD1、BSL256、SI1 //SD1／BSL256／SI1に相当する
BIFT ID＝9：corresponding to SD1、BSL256、SI2 //SD1／BSL256／SI2に相当する
BIFT ID＝10：corresponding to SD1、BSL256、SI3 //SD1／BSL256／SI3に相当する
BIFT ID＝11：corresponding to SD1、BSL512、SI0 //SD1／BSL512／SI0に相当する
BIFT ID＝12：corresponding to SD1、BSL512、SI1 //SD1／BSL512／SI1に相当する

BIFT IDフィールドの値は、トリプレット＜SD，BSL，SI＞に対応することに留意されたい。一意の＜SD，BSL，SI＞情報は、BIFT-idフィールドを使用して取得することができる。＜SD，BSL，SI＞情報は、以下の機能を有する：BIERパケットヘッダ内のBitStringの長さはBSLを使用して取得されて、BIERパケットヘッダ全体の長さを知る。BitStringが1から256の範囲のBFR-IDを表すか、または257から512の範囲のBFR-IDを表すかは、BSLおよびSI情報を使用して知ることができる。対応する転送テーブルは、SD情報を使用して見つけることができる。

（2）ビット列（bit string）フィールド
bit string内の各bitは、エッジBFRを識別するために使用され、たとえば、bit string内の下位（右端）のbitは、BFR-IDが1に等しいBFERを識別するために使用される。bit string内の右から左へ第2のBitは、BFR-IDが2に等しいBFERを識別する。それに基づいて転送プレーンが転送を実行する転送エントリは、パケット内のbit stringに基づいて、パケットが送信されるべきいくつかの特定のBFERを特定する。BIERヘッダを含むパケットヘッダを受信すると、BIERドメイン内のBFRは、BIERヘッダ内で搬送されるbit stringおよびBIFT IDに基づいて、BIERパケットを転送する。

bitの値1は、BFR-IDによって表されるBFERデバイスにパケットが送信される必要があることを示し、bitの値0は、BFR-IDによって表されるBFERデバイスにパケットが送信される必要がないことを示すことに留意されたい。

たとえば、BIFT ID＝2である。BIERパケットを受信した後、BFRは、BIERヘッダ内のBIFT IDに基づいて、BIERパケットがSD0に属し、BIERヘッダ内で使用されるBSLが256 bitを有し、BFR IDがセット1（BFR IDが257から512の範囲の256個のエッジBFRを含むセット）に属することを知ることができる。

（3）送信クラス（traffic class、TC）フィールド
トラフィッククラスフィールドは、パケットの優先度を識別するために使用される。

（4）スタック（stack、S）
Sは一番下のラベルである。ラベルの値は、BIERパケットヘッダでは1である。言い換えれば、MPLSラベルは、ラベルスタック全体の一番下のラベルである。

（5）バージョン番号（version、Ver）フィールド
バージョン番号フィールドは、4 bitの長さを有し、IPのバージョン番号である。バージョン番号フィールドの値4はIPv4を表し、バージョン番号フィールドの値6はIPv6を表す。

（6）エントロピー（entropy）フィールド
エントロピーフィールドは、負荷共有に使用される。均等な負荷共有は、BIER転送中に実行されてもよい。この場合、負荷共有中、同じEntropyおよび同じBitstringを有する2つのBIERパケットに対して同じ経路が選択される必要がある。具体的には、同じトラフィックに属する複数のパケットは同じエントロピーを有し、異なるトラフィックを有する複数のパケットは異なるエントロピーを有する。パケットが転送されるとき、エントロピーに基づいて異なるトラフィックが異なるリンク上で共有されてもよく、同じトラフィックを有する複数のパケットは同じリンクを通過する。

異なるentropyが異なるフローを識別することを保証するために、BFIRデバイスがentropyを割り当てるとき、異なるエントロピーラベルが異なるフローに基づいて割り当てられることが必要であり、entropyは繰り返すことができない。

（7）プロトコル（protocol、proto）フィールド
プロトコルフィールドは、BIERパケットヘッダの後のペイロード（payload）フォーマットを識別するために使用される。たとえば、値4および値6は、それぞれ、IPv4パケットおよびIPv6パケットを表す。値2は、アップストリームに割り当てられたラベルを有するMPLSパケットを表し、値2は、マルチキャスト仮想プライベートネットワーク（multicast virtual private network、MVPN）over BIERで使用されるproto値である。アップストリームラベルを使用する理由は以下の通りである：マルチキャストはポイントツーマルチポイント送信である。送信端のプロバイダエッジ（provider edge、PE）デバイスは、固有のラベルを割り当て、制御プレーンを使用して受信端のPEデバイスに固有のラベルを送信することができる。送信端のPEデバイスによって割り当てられたラベルは、データパケット内で使用され、受信端のPEデバイスによって識別される。ラベルは、受信端のPEデバイスによって割り当てられないが、送信端のPEデバイスによって割り当てられるので、アップストリームラベルと呼ばれる。

（8）ニブル（nibble）
ニブルフィールドは、固定4ビット値0101を有する。このフィールドは、MPLSによって搬送されるサービスを区別し、BIER、IPv4、およびIPv6を区別するために使用される。MPLSのカプセル化および転送において、ラベルスタックの後のIPv4またはIPv6ヘッダは、ECMPをサポートするために時々チェックされる。

（9）BFIR-id
BFIR-idはBFIRのBFR-IDである。BFIRデバイスがsub-domainを使用してBIERパケットをカプセル化し送信する場合、BFIR-idフィールドは、sub-domain内のデバイスのBFR-IDで満たされる必要がある。BFIR-idは、マルチキャストフローを一意に決定するために、マルチキャストフローが送信される特定のBFIRを識別することができる。

（10）bit string
bit stringは、BIERパケットの宛先デバイスセットの文字列である。

図3は、別の可能なBIERヘッダフォーマットの概略ブロック図である。図2に示されたBIERヘッダフォーマットと比較して、図3に示されたBIERヘッダフォーマットは、BIFT-IDフィールドを含まないが、3つのフィールドSD／BSL／SIを明示的に含む。言い換えれば、図3に示されたBIERヘッダフォーマットは、3つのフィールドSD／BSL／SIを直接含み、SD／BSL／SIの値は、BIFT IDフィールドによって策定される必要がない。

図3に示されたBIERヘッダフォーマットに含まれるフィールドは、図2に示されたBIERヘッダフォーマットに含まれるフィールドと同様であることに留意されたい。図3に示されたBIERヘッダフォーマット内のフィールドに関する具体的な説明については、図2の説明を参照されたい。本明細書では詳細は再び記載されない。

BIER技術に基づいてBIER転送テーブルを確立し、BIER技術に基づいてBIERパケットを転送するプロセスは、一例として図4を使用して以下で詳細に記載される。

図4に示されたBIERドメインは、デバイスA～デバイスFを含んでもよい。デバイスA、デバイスD、デバイスE、およびデバイスFは、BIERドメイン内のエッジBFRであり、デバイスBおよびデバイスCは、BIER内の中間転送デバイスである。具体的には、デバイスAは、BIERドメインの入口に位置し、元のマルチキャストパケットに対してBIERカプセル化を実行することに関与し、図1のBFIRに対応する。デバイスD、デバイスE、およびデバイスFは、BIERドメインの出口に位置し、BIERパケットをカプセル化解除することによって元のマルチキャストパケットを取得することに関与し、図1のBFERに対応する。

本出願のこの実施形態では、BIERドメイン内の各エッジBFRに一意のBFR-IDが割り当てられてもよい。たとえば、図4では、デバイスA、デバイスD、デバイスE、およびデバイスFのために構成されたBFR-IDは、それぞれ、4、1、3、および2である。中間転送BFR、たとえば、デバイスBおよびデバイスCには、BFR-IDが割り当てられていない。

本出願のこの実施形態では、「ID」と「id」が時々混在して使用される場合があることに留意されたい。差違が強調されないとき、それらによって表現される意味は同じであることに留意されたい。本出願におけるBFR-IDは、図4のidを指すことができる。

データトラフィックのBIERヘッダ内でカプセル化されたbit stringは、トラフィックのすべての宛先デバイスをマークする。たとえば、BFR-IDが1であるデバイスDに対応するbit stringは0001であり、BFR-IDが2であるデバイスFに対応するbit stringは0010であり、BFR-IDが3であるデバイスEに対応するbit stringは0100であり、BFR-IDが4であるデバイスAに対応するbit stringは1000である。

BIERドメイン内の各エッジBFRに割り当てられたBFR-ID値は、ルーティングプロトコルを使用してBIERドメイン内の別のBFRにフラッディングされてもよいことを理解されたい。フラッディングされたBIER情報は、エッジBFRのIPアドレスおよびカプセル化情報をさらに含む。たとえば、デバイスAのフラッディングされたBIER情報は、デバイスAのIPアドレスおよびBIFT-idを搬送する。BIERドメイン内のBFR（たとえば、図4のデバイスF）は、フラッディングされたBIER情報に基づいてBIFTエントリを確立することができ、その結果、BIERパケットを受信した後、図4のデバイスFは、確立されたBIFTエントリに基づいて宛先デバイスにBIERパケットを転送する。

デバイスAが、BFR-IDがそれぞれ1、2、および3であるBFERにBIERパケットを送信する必要がある場合、デバイスAは、最初に、デバイスAの隣接者（デバイスB）にBIERパケットを送信する必要があり、BFR-IDが4であるエッジBFRがデバイスAである。したがって、デバイスAによって確立されるBIFTエントリは以下の通りである。

転送エントリ1：隣接者（neighbor、Nbr）＝B、および転送ビットマスク（forwarding bit mask、FBM）＝0111

転送エントリ2：Nbr＊＝A、およびFBM＝1000

転送エントリ1は、BIERパケット内のbit stringの右から左に1番目のビット、2番目のビット、または3番目のビットのいずれか1つが1であるとき、BIERパケットがデバイスAの隣接者（デバイスB）に送信されることを示すために使用され、Nbr＝Bは、デバイスAの隣接者がデバイスBであることを示す。

転送エントリ2は、BIERパケット内のbit stringの右から左に4番目のビットが1であるとき、BIERパケットがデバイスAに送信されることを示すために使用される。デバイスAはデバイスAであるので、デバイスAはBIERヘッダを取り除き、元のマルチキャストパケット内の情報に基づいてBIERパケットを転送する。前述の転送エントリ2において、＊は、Nbrがデバイス自体であることを識別するために使用されることに留意されたい。たとえば、デバイスAの場合、Nbr＊＝Aは、デバイスAの隣接デバイスがデバイスAであることを示す。同様に、図4の別のデバイスも、別のデバイスの隣接デバイスに基づいてBIFTエントリを確立することができる。別のデバイスによって確立されるBIFTエントリについては、図4を参照されたい。本明細書では詳細は記載されない。

BIERドメイン内の入口BFIRとして機能して元のマルチキャストパケットを受信した後、デバイスAは、元のマルチキャストパケットの前にBIERヘッダをカプセル化する。説明を容易にするために、デバイスAは以下で入口デバイスAと呼ばれることを理解されたい。一例では、元のマルチキャストパケットを受信した後、入口デバイスAは、境界ゲートウェイプロトコルBGPメッセージを使用することにより、フラッディングされたBFR-IDに基づいて、元のマルチキャストパケットの宛先ノデバイスを知ることができる。たとえば、元のマルチキャストパケットの受信側は以下の通りである：BFR-IDが3である宛先デバイスはEであり、BFR-IDが2である宛先デバイスはFであり、BFR-IDが1である宛先デバイスはDである。BIERヘッダをカプセル化するために入口デバイスAによって使用されるbit stringは0111であり、入口デバイスAは、転送エントリ1に基づいて、カプセル化後に取得されたBIERパケットを隣接デバイスBに転送する。BIERパケットを受信した後、デバイスBは、bit string 0111およびBIFTエントリに基づいて、BIERパケットがデバイスCおよびデバイスEにそれぞれ送信される必要があると判断する。デバイスCにBIERパケットを送信するとき、デバイスBは、BIERヘッダ内のbit string（0111）とBIFTエントリ内のNbr＝Cに対応するFBMフィールドとの間にAND演算を実行することができる。本出願のこの実施形態におけるAND結果は0011である。したがって、デバイスBは、BIERヘッダ内のbit stringを0011に修正し、デバイスCにBIERパケットを送信することができる。同様に、デバイスEにBIERパケットを送信するとき、デバイスBは、BIERヘッダ内のbit stringを0100に修正することができる。BIERパケットを受信した後、デバイスEは、bit string 0100に基づいて、BIERパケットが隣接デバイスEに送信される必要があると判断する。デバイスEは、転送エンティティ内の識別子＊に基づいて、隣接デバイスEがデバイスEであると判断する。したがって、BIERドメイン内の出口BFERとして機能するデバイスEは、BIERパケットをカプセル化解除することによって元のマルチキャストパケットを取得し、内層の元のマルチキャストパケット内で元のマルチキャストパケットを転送することができる。

BIER-MPLSカプセル化では、BIERヘッダ内の最初の32bitはMPLSラベルコードであり、最初の32bit内の最初の20bitはMPLSラベル値である。MPLSラベル値は、転送プロセスにおいて変化する。たとえば、入口デバイスAがデバイスBにパケットを送信するとき、デバイスBのMPLSラベル値はカプセル化される必要がある。デバイスBがデバイスCにパケットを送信するとき、デバイスCのMPLSラベル値はカプセル化される必要がある。本出願のこの実施形態では、デバイスA／デバイスB／デバイスC／デバイスD／デバイスE／デバイスFに割り当てられたMPLSラベル値は、それぞれ、100／200／300／400／500／600である。これらのMPLSラベル値は、デバイスAがデバイスBのMPLSラベル値を知ることができるように、前述のBIER情報に追加され、ルーティングプロトコルを使用してBIERドメイン内の別のBFRにフラッディングされる必要がある。BIER情報を識別するMPLSラベルは、BIERラベルとも呼ばれる。

BIERv6カプセル化に関連する技術は、図5を参照して以下で詳細に記載される。

BIERv6カプセル化は、Native IPv6およびBIERの利点を組み合わせることによって形成される解決策であることを理解されたい。BIERv6カプセル化におけるパケットフォーマットは、IPv6ヘッダ＋BIERヘッダ＋元のマルチキャストパケットである。BIERヘッダはIPv6拡張ヘッダに含まれてもよく、元のマルチキャストパケットは、外層IPv6ヘッダのペイロード（payload）として使用される。

このカプセル化では、IPv6ヘッダ、およびBIERヘッダを含むIPv6拡張ヘッダが一緒に、内層の元のマルチキャストパケットの外層パケットヘッダを構成し、外層パケットヘッダは、本出願のこの実施形態ではBIERv6ヘッダと呼ばれる場合もある。

BIERヘッダを含むIPv6拡張ヘッダは、本出願のこの実施形態では特に限定されない。たとえば、IPv6拡張ヘッダは、宛先オプションヘッダ（destination option header、DOH）であってもよい。別の例では、IPv6拡張ヘッダは、ルーティングヘッダ（routing header、RH）であってもよい。

図5は、可能なBIERv6カプセル化の概略ブロック図である。図5を参照すると、BIERヘッダは、IPv6拡張ヘッダ内に配置されてもよく、たとえば、DOH内に配置されてもよい。

DOH内のオプションは、型長値（Type-Length-Value、TLV）フォーマットであることを理解されたい。BIERヘッダはDOHのOption TLV内のOption dataとして使用され、Option TLV内のOption typeはBIERヘッダのフォーマットを識別し、Option TLV内のOption lengthはBIERヘッダの長さを識別する。

BIERv6カプセル化において、DOH内のBIERヘッダフォーマットは、BIERヘッダがbit stringフィールドを含む限り、本出願のこの実施形態では特に限定されないことに留意されたい。BIERヘッダフォーマットは、図2に示されたフォーマット、図3に示されたフォーマット、または別のフォーマットであってもよい。たとえば、BIERv6カプセル化において、BIERヘッダがビットインデックスの明示的な複製に使用されるビット列（bit string）を含む限り、BIERヘッダからProtoフィールド、DSCPフィールドなどがさらに削除されてもよい。BIERヘッダフォーマットに関する具体的な詳細説明については、図2または図3の説明を参照されたい。本明細書では詳細は再び記載されない。

外層IPv6ヘッダに含まれるフィールドが以下で詳細に記載される。

バージョン番号（version、Ver）：バージョン番号はIPのバージョン番号であり、バージョン番号の値6はIPv6を表す。

トラフィッククラス（traffic class、TC）フィールド：トラフィッククラスフィールドはパケットの優先度を識別する。

フローラベル（flow label、FL）フィールド：同じトラフィックに属する複数のパケットにラベル付けするために同じフローラベルが使用されてもよく、異なるトラフィックを有する複数のパケットにラベル付けするために別のフローラベル値が使用される。パケットが転送されるとき、フローラベルに基づいて異なるトラフィックが異なるリンク上で共有されてもよく、同じトラフィックを有する複数のパケットは同じリンクを通過する。具体的には、フローラベルは、リアルタイムのトラフィックを区別するために使用され、異なるフローラベルは、異なるデータフローを特定することができる。このようにして、BIERドメイン内のネットワークデバイスは、フローラベルフィールドに基づいて異なるデータフローをより効率的に区別することができる。

ペイロード長（payload length、PL）フィールド：ペイロード長フィールドはパケットの長さを示す。

次のヘッダ（Next Header、NH）フィールド：次のヘッダフィールドは、パケットの次のヘッダのタイプを示し、たとえば、IPv6拡張ヘッダを表すことができる。

ホップ制限（Hop Limit、HL）フィールド：ホップ制限フィールドはパケットの数を示す。

ソースアドレス（source address、SA）フィールド：ソースアドレスフィールドはパケットのソースアドレスを識別する。

宛先アドレス（destination address、DA）フィールド：宛先アドレスフィールドはパケットの宛先アドレスを識別する。

一例として図4に示されたBIERドメインが使用される。IPv6ネットワークにおいてヘッダノード（入口デバイス）として機能して、ユーザマルチキャストパケットを受信した後、デバイスAは、BIERv6ヘッダの後、すなわち、外層のIPv6ヘッダ、およびBIERヘッダを含むIPv6拡張ヘッダの後にパケットをカプセル化して、カプセル化されたBIERv6パケットを取得する。IPv6拡張ヘッダに含まれるBIERv6パケットヘッダは、宛先デバイスセットを示すbit stringを搬送する。

デバイスAは、BIERv6パケットヘッダおよびBIERv6パケットヘッダのbit string情報に基づいて、カプセル化されたBIERv6パケットをBに送信する。カプセル化されたBIERv6パケットを送信するとき、デバイスAは、IPv6ヘッダ内の宛先アドレスフィールド内のBのユニキャストアドレス（たとえば、B::100）を使用することができる。デバイスBは、BIERv6パケットヘッダおよびBIERv6パケットヘッダのbit string情報に基づいて、パケットをCおよびEに送信する。パケットを送信するとき、デバイスBは、IPv6ヘッダ内の宛先アドレスフィールド内のCのユニキャストアドレス（たとえば、C::100）およびEのユニキャストアドレス（たとえば、E::100）を使用することができる。同様に、デバイスCは、BIERv6パケットヘッダおよびBIERv6パケットヘッダのbit string情報に基づいて、パケットをDおよびFに送信する。パケットを送信するとき、デバイスCは、IPv6ヘッダ内の宛先アドレスフィールド内のDのユニキャストアドレス（たとえば、D::100）およびFのユニキャストアドレス（たとえば、F::100）を使用することができる。

本出願のこの実施形態では、エッジBFR用に構成されたビット位置は、内部ゲートウェイプロトコル（interior gateway protocol、IGP）または境界ゲートウェイプロトコル（border gateway protocol、BGP）を使用してBIERドメイン内で事前にフラッディングされ、その結果、BIERドメイン内の各BFRは、BIERドメイン内の元のマルチキャストパケットの転送を誘導するために使用されるビットインデックス転送テーブル（bit index forwarding table、BIFT）を形成する。IGPまたはBGPを使用してBIERドメイン内でフラッディングされる情報は、BIER情報と呼ばれる場合がある。BIERヘッダでカプセル化されたBIERv6パケットを受信すると、BFRは、BIFTエントリに基づいてBIERv6パケットを宛先ノードに転送する。

本出願のこの実施形態では、内部ゲートウェイプロトコルIGPは、オープン最短経路優先（open shortest path first、OSPF）プロトコル、中間システム間（intermediate system to intermediate system、IS-IS）プロトコルなどを含んでもよいが、それらに限定されない。

BIERドメイン（BIER domain）は、BIER情報がIGPまたはBGPを使用してフラッディングされ得、BIFTエントリが確立され得るネットワークエリアを指し、BIERドメインはBFIRおよびBFERを含むことを理解されたい。BIER情報は、前述のエッジBFRの各々のBFR IDを含んでもよいが、それに限定されない。一例では、自律システム（autonomous system、AS）ドメイン内で、IGPが配備され、BIER情報がフラッディングされる場合、ASドメインはBIERドメイン（BIER domain）である。BIER情報は、複数のASドメイン間でフラッディングされない。

一般に、ネットワークが比較的大規模であるとき、1つのBIERドメインは複数のASドメインに分割され、ASドメイン内に異なるプロトコルが配備される。たとえば、1つのBIERドメインは2つのASドメインに分割され、一方のASドメインにIGPが配備され、他方のASドメインにBGPが配備される。

図6は、本出願の一実施形態に適用可能なマルチエリアの概略シナリオ図である。

デバイスEは、元のマルチキャストパケットに対してBIERカプセル化を実行してBIERv6パケットを取得するために、BIERドメイン内の（図1のBFIRに対応する）入口デバイスとして機能する。デバイスF、デバイスB1、デバイスB2、デバイスC、およびデバイスDは、BIERドメイン内のBFRとして機能し、BIERv6パケット内のBIERヘッダ情報に基づいてBIERv6パケットを転送する。デバイスR1、R2、R3、R4、およびR5は、BIERドメイン内の（図1のBFERに対応する）出口デバイスとして機能して、BIERv6パケットをカプセル化解除し、カプセル化解除後に取得されたマルチキャストパケットを転送する。

説明を容易にするために、説明のための図6の一例として、BIERドメインが2つのエリア（第1のエリアおよび第2のエリア）を含むことが使用される。第1のエリアはBIERドメイン内の入口デバイスを含み、第2のエリアはBIERドメイン内の出口デバイスを含む。たとえば、第1のエリアはデバイスEおよびデバイスFを含み、第2のエリアは、デバイスB1、デバイスB2、デバイスC、デバイスD、ならびにデバイスR1、R2、R3、R4、およびR5を含む。

BIERドメイン内の第1のエリアおよび第2のエリアは、第1のエリアおよび第2のエリアが異なるプロトコルを有する限り、本出願のこの実施形態では特に限定されない。一例では、IGPはBIERドメイン内の第1のエリア内に配備され、BGPはBIERドメイン内の第2のエリア内に配備される。

図6では、デバイスFは、第1のエリア内の境界デバイスとして機能することができ、第1のエリアと第2のエリアを接続するように構成されることを理解されたい。デバイスB1またはデバイスB2は、第2のエリア内の境界デバイスとして機能することができ、第2のエリアと第1のエリアを接続するように構成される。

デバイスFは、デバイスB1およびデバイスB2とは異なってもよく、同じデバイスであってもよいことに留意されたい。これは本出願では特に限定されない。デバイスFがデバイスB1およびデバイスB2と同じデバイスである場合、デバイスは、BIERドメイン内の第1のエリアとBIERドメイン内の第2のエリアの両方に属する。

図6に示されたように、デバイスR1～R5の（BFR IDを含む）BIER情報は、IGPルーティングプロトコルまたはBGPルーティングプロトコルを使用して第2のエリア内に事前にフラッディングされ、その結果、第2のエリア内のデバイスは、BIER情報に基づいて、第2のエリア内のBIERv6パケットの転送を誘導するために使用されるビットインデックス転送テーブル（bit index forwarding table、BIFT）を形成する。BIERヘッダでカプセル化されたBIERv6パケットを受信すると、第2のエリア内のデバイスは、BIFTエントリに基づいてデバイスR1～R5にBIERv6パケットを転送する。

第1のエリアおよび第2のエリアは異なるASドメインに属し、BIER情報は異なるASドメイン間でフラッディングされないので、第1のエリア内のデバイスEは、デバイスR1～R5によってフラッディングされた（BFR IDを含む）BIER情報を受信することができず、デバイスEは、BIER情報に基づいて、第1のエリア内のBIERv6パケットの転送を誘導するために使用されるBIFTを形成することができない。したがって、第2のエリア内のデバイスR1～R5に到達するためのネクストホップは、第1のエリア内のデバイスE上に静的に構成される必要がある。ネクストホップは、第1のエリアに接続するように構成された第2のエリア内の境界デバイスである。第1のエリア内のデバイスEは、デバイスR1～R5に到達するための構成されたネクストホップに基づいて、第2のエリア内のネクストホップにBIERv6パケットを送信し、次いで、第2のエリア内のネクストホップは、確立されたBIFTに基づいてBIERv6パケットに対してBIER転送を実行する。

たとえば、デバイスR1～R5に到達するためのデバイスE上のネクストホップは、第2のエリア内のデバイスB1である。第2のエリア内のデバイスB1が故障している場合、第1のエリア内のデバイスEは構成に基づいてデバイスB1にBIERv6パケットを送信することができず、第1のエリア内のBIERv6パケットは第2のエリアに転送することができず、BIERドメイン内の第1のエリアと第2のエリアとの間のトラフィックの中断が発生する。

これを考慮して、本出願の実施形態は、BIERv6パケットを転送するための方法を提供し、その結果、デバイスB1が故障したときにBIERv6パケットを転送して、第1のエリア内のBIERv6パケットを第2のエリアに転送することができ、それにより、BIERドメイン内の第1のエリアと第2のエリアとの間のトラフィックの中断が回避される。

図7は、本出願の一実施形態による、BIERv6パケットを転送するための方法の概略フローチャートである。図7を参照すると、方法はステップ710および720を含んでもよい。ステップ710および720は、以下で別々に詳細に記載される。

ステップ710：第1のネットワークデバイスが、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断し、第1のネットワークデバイスはBIERドメイン内の入口デバイスであり、第2のネットワークデバイスはBIERドメイン内の出口デバイスであり、第1のネットワークデバイスはBIERドメイン内の第1のエリアに属し、第2のネットワークデバイスおよびアクティブネクストホップデバイスはBIERドメイン内の第2のエリアに属し、アクティブネクストホップデバイスは第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成される。

第1のネットワークデバイスは、BIERドメイン内の入口デバイスであり、図6のデバイスEに対応し、BIERドメイン内の第1のエリアに属する。第2のネットワークデバイスは、BIERドメイン内の出口デバイスであり、図6のデバイスR1～R5に対応し、BIERドメイン内の第2のエリアに属する。

アクティブネクストホップデバイスは、BIERドメイン内の第2のエリアに属し、第2のエリア内のBIERv6転送をサポートし、第1のエリアに接続するように構成された境界デバイスである。たとえば、アクティブネクストホップデバイスは、図6のデバイスB1に対応してもよい。

本出願のこの実施形態では、BIERドメイン内の第1のエリアおよび第2のエリアは異なるプロトコルを有することを理解されたい。詳細については、図6の第1のエリアおよび第2のエリアの説明を参照されたい。本明細書では詳細は再び記載されない。

本出願のこの実施形態では、第1のネットワークデバイスが、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断する複数の実装形態が存在する。実装形態は、具体的な実施形態を参照して以下で詳細に記載される。本明細書では詳細は記載されない。

本出願のこの実施形態では、アクティブネクストホップデバイスが故障していることは、アクティブネクストホップデバイス自体が故障している、アクティブネクストホップデバイスがBIERv6転送を実行することができない、またはアクティブネクストホップデバイスと第1のネットワークデバイスとの間のリンクが故障していることとして理解されてもよいことを理解されたい。

ステップ720：第1のネットワークデバイスが第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにBIERv6パケットを送信し、バックアップネクストホップデバイスは第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成される。

第1のネットワークデバイスがそれを介して第2のネットワークデバイスに到達するアクティブネクストホップデバイスが故障しているシナリオでは、第1のネットワークデバイスは、第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにBIERv6パケットを送信することができる。バックアップネクストホップデバイスも、BIERドメイン内の第2のエリアに属し、第2のエリア内のBIERv6転送をサポートし、第1のエリアに接続するように構成された境界デバイスである。たとえば、バックアップネクストホップデバイスは、図6のデバイスB2に対応してもよい。

バックアップネクストホップデバイスは、アクティブネクストホップデバイスの保護デバイスとして機能することを理解されたい。アクティブネクストホップデバイスが正常であるとき、第1のネットワークデバイスは、アクティブネクストホップデバイスを使用して第2のネットワークデバイスにBIERv6パケットを送信する。アクティブネクストホップデバイスが故障しているとき、第1のネットワークデバイスは、バックアップネクストホップデバイスを使用して第2のネットワークデバイスにBIERv6パケットを送信することができる。

本出願の実施形態で提供されるBIERv6パケットを転送するための方法は、一例として図6に示されたシナリオを使用することにより、図8を参照して以下で詳細に記載される。

図8の例は、単に当業者が本出願の実施形態を理解するのを助けるものであり、例の特定の値または特定のシナリオに本出願の実施形態を限定するものではないことに留意されたい。当業者は、明らかに図8に示された例に従って様々な均等な修正または変更を行うことができ、そのような修正または変更も本出願の実施形態の範囲内にある。

図8は、本出願の一実施形態による、BIERv6パケット転送するための別の方法の概略フローチャートである。図8に示されたように、方法はステップ810～850を含んでもよい。ステップ810～850は、以下で別々に詳細に記載される。

ステップ810：デバイスE上に、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのアクティブネクストホップおよびバックアップネクストホップを構成する。

本出願のこの実施形態では、トラフィックの中断の発生を回避するために、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのアクティブネクストホップおよびバックアップネクストホップがデバイスE上に構成される。アクティブネクストホップが故障していないとき、デバイスEは、アクティブネクストホップの経路を介して、BFR IDがそれぞれ1～5であるデバイスR1～R5にBIERv6パケットを送信する。アクティブネクストホップが故障しているとき、デバイスEは、バックアップネクストホップの経路を介して、BFR IDがそれぞれ1～5であるデバイスR1～R5にBIERv6パケットを送信する。

デバイスEがデバイスR1～R5に到達するためのアクティブネクストホップおよびバックアップネクストホップを決定する複数の具体的な実装形態が存在する。可能な実装形態では、デバイスEは、ネットワークトポロジーに基づいて、マルチキャスト転送経路を適切に計画し、最適な転送を実現するために、デバイスR1～R5に到達するためのアクティブネクストホップおよびバックアップネクストホップを決定することができる。

一例では、図6に示されたネットワークトポロジーが一例として使用される。デバイスE上で最適な転送を実現するために、デバイスB1はデバイスR1～R5に到達するためのアクティブネクストホップとして構成されてもよく、デバイスB2はデバイスR1～R5に到達するためのバックアップネクストホップとして構成されてもよい。

この実装形態におけるデバイスEの可能な構成が以下に列挙される。
bfd BierE_B1 bind peer-ipv6 200:B1:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 2
bfd BierE_B2 bind peer-ipv6 200:B2:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 3
bier
bfr-neighbor end-bier 200:B1:1::1 bfr-id 1 to 5 track bfd BierE_B1
bfr-neighbor end-bier 200:B2:1::1 bfr-id 1 to 5 backup track bfd BierE_B2

前述の構成では、「bfd BierE_B1 bind peer-ipv6 200:B1:1::1 source-ipv6 100:E:1::」は、デバイスEのネクストホップがデバイスB1であり、アドレス200:B1:1::1がデバイスB1のEnd.BIERアドレスであり、アドレス100:E:1::がデバイスEのEnd.BIERアドレスであることを示し、
「bfd BierE_B2 bind peer-ipv6 200:B2:1::1 source-ipv6 100:E:1::」は、デバイスEのネクストホップがデバイスB2であり、アドレス200:B2:1::1がデバイスB2のEnd.BIERアドレスであり、アドレス100:E:1::がデバイスEのEnd.BIERアドレスであることを示す。

End.BIERアドレスは、共通のIPv6アドレスではないが、BIERv6パケットを処理するために使用されるデバイス上の特定のIPv6アドレスであることを理解されたい。一例としてデバイスBが使用される。End.BIERアドレスがデバイスB上に構成された後、転送情報ベース（forwarding information base、FIB）内のアドレスに対して128ビットマスクを有する転送エントリが形成され、転送エントリはアドレスがEnd.BIERであることを識別する。IPv6パケットを受信すると、デバイスBは、最初に、宛先アドレスを求めてFIBを探索する。FIBを探索した結果、宛先アドレスがEnd.BIERアドレスであったとき、デバイスBは、End.BIER固有の動作を実行する、すなわち、IPv6拡張パケットヘッダ内のBIERヘッダを処理し続ける。あるいは、宛先アドレスが共通のIPv6宛先アドレスである場合、FIBの探索結果は、パケットが、現在のルータに送信され、宛先オプション拡張パケットヘッダを含むIPv6パケットであることを示す。この場合、パケットは、処理のためにCPUに送信されてもよく、データプレーン上で処理することはできない。

End.BIERは、単にBIERv6パケットを処理するようにデバイスに指示するために使用され、BIER転送は、拡張パケットヘッダ内のBIERv6パケットヘッダに依存し、BIERv6パケットヘッダ内のBIFT-idフィールドに基づいて、パケットが属する特定の＜SD，BSL，SI＞を決定することと、次いで、bit stringに基づいて、どのSIの特定のBFERノードであり、どれにパケットが送信されるべきかを決定することとを含むことに留意されたい。

上記の構成では、「bfr-neighbor end-bier 200:B1:1::1 bfr-id 1 to 5 track bfd BierE_B1」は、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するための、デバイスE上にあるアクティブネクストホップがデバイスB1であることを示し、
「bfr-neighbor end-bier 200:B2:1::1 bfr-id 1 to 5 backup track bfd BierE_B2」は、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するための、デバイスE上にあるバックアップネクストホップがデバイスB2であることを示す。

別の例では、図6に示されたネットワークトポロジーが一例として使用される。第2のエリア内のデバイスB1およびデバイスCのみがBIERv6転送をサポートすると仮定する。最適な転送を実現するために、デバイスE上に、デバイスB1は、デバイスR1～R5に到達するためのアクティブネクストホップとして構成されてもよく、デバイスCは、デバイスR1～R3に到達するためのバックアップネクストホップとして構成されてもよく、デバイスR4は、デバイスR4に到達するためのバックアップネクストホップとして構成されてもよく、デバイスR5は、デバイスR5に到達するためのバックアップネクスホップトとして構成されてもよい。言い換えれば、リーフノード（たとえば、デバイスR4およびデバイスR5）は、デバイスEのバックアップネクストホップとして機能することができる。

この実装形態におけるデバイスEの可能な構成が以下に列挙される。
bfd BierE_B bind peer-ipv6 200:B1:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 2
bfd BierE_C bind peer-ipv6 200:C:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 3
bier
bfr-neighbor end-bier 200:B1:1::1 BFR-id 1 to 5 track bfd BierE_B1
bfr-neighbor end-bier 200:C:1::1 BFR-id 1 to 3 backup track bfd BierE_C
bfr-neighbor end-bier 200:D4:1::1 BFR-id 4 backup
bfr-neighbor end-bier 200:D5:1::1 BFR-id 5 backup

上記構成において、bfr-neighbor end-bier 200:D4:1::1 BFR-id 4 backup」は、BFR IDが4であるデバイスR4に到達するための、デバイスE上にあるバックアップネクストホップがデバイスR4（デバイスR4）であることを示し、「bfr-neighbor end-bier 200:D5:1::1 BFR-id 5 backup」は、BFR IDが5であるデバイスR5に到達するための、デバイスE上にあるバックアップネクストホップがデバイスR5（デバイスR5）であることを示す。

別の例では、図9に示されたネットワークトポロジーが一例として使用される。第1のエリアは、複数のASBR、たとえば、デバイスB1、デバイスB2、およびデバイスB3を含んでもよい。デバイスE上に、ネットワークトポロジーに基づいて最適な転送を実現するために、デバイスB2およびデバイスB3は、デバイスR1～R3に到達するためのプライマリネクストホップおよびバックアップネクストホップとしてそれぞれ構成されてもよく、デバイスB1およびデバイスB2は、デバイスR4およびデバイスR5に到達するためのプライマリネクストホップおよびバックアップネクストホップとしてそれぞれ構成されてもよい。

この実装形態におけるデバイスEの可能な構成が以下に列挙される。
bfd BierE_B1 bind peer-ipv6 200:B1:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 2
bfd BierE_B2 bind peer-ipv6 200:B2:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 3
bfd BierE_B3 bind peer-ipv6 200:B3:1::1 source-ipv6 100:E:1::
discriminator local 1
discriminator remote 4
bier
bfr-neighbor end-bier 200:B1:1::1 BFR-id 1 to 3 track bfd BierE_B3
bfr-neighbor end-bier 200:B2:1::1 BFR-id 1 to 3 backup track bfd BierE_B2
bfr-neighbor end-bier 200:B2:1::1 BFR-id 4 to 5 track bfd BierE_B2
bfr-neighbor end-bier 200:B3:1::1 BFR-id 4 to 5 backup track bfd BierE_B1

上記の構成では、「bfr-neighbor end-bier 200:B1:1::1 BFR-id 1 to 3 track bfd BierE_B3」は、デバイスR1～R3に到達するための、デバイスE上にあるアクティブネクストホップがデバイスB3であることを示し、「bfr-neighbor end-bier 200:B2:1::1 BFR-id 1 to 3 backup track bfd BierE_B2」は、デバイスR1～R3に到達するための、デバイスE上にあるバックアップネクストホップがデバイスB2であることを示し、「bfr-neighbor end-bier 200:B2:1::1 BFR-id 4 to 5 track bfd BierE_B2」は、デバイスR4およびデバイスR5に到達するための、デバイスE上にあるアクティブネクストホップがデバイスB2であることを示し、「bfr-neighbor end-bier 200:B3:1::1 BFR-id 4 to 5 backup track bfd BierE_B1」は、デバイスR4およびデバイスR5に到達するための、デバイスE上にあるバックアップネクストホップがデバイスB1であることを示す。

前述の技術的解決策では、マルチキャスト転送経路を適切に計画し、最適な転送を実現するために、ネットワークトポロジーに基づいて異なるBFR IDに対して、異なるプライマリネクストホップおよびバックアップネクストホップがデバイスE上に柔軟に配備されてもよい。

ステップ820：デバイスEが、デバイスR1～R5に到達するためのアクティブネクストホップが故障していると判断する。

説明を容易にするために、以下の例として図6に示されたシナリオが使用される。デバイスE上に構成され、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのアクティブネクストホップは、デバイスB1である。

本出願のこの実施形態では、デバイスB1が故障していることは、デバイスB1自体が故障している、デバイスB1とデバイスEとの間のリンクが故障している、またはデバイスB1がBIERv6パケットを転送することができないこととして理解されてもよい。

デバイスB1が故障しているとデバイスEが判断する複数の具体的な方式が存在する。これは本出願では特に限定されない。いくつかの可能な実装形態が以下に列挙される。

1つの可能な実装形態では、デバイスEは、PIMプロトコルを有効にし、PIM HELLOパケットなどのパケットをデバイスB1に送信する。同様に、デバイスB1は、PIMプロトコルを有効にし、PIM HELLOパケットなどのパケットをデバイスEに送信する。デバイスEがデバイスB1によって送信されたメッセージを受信することができる場合、デバイスB1は故障していないか、またはデバイスB1とデバイスEとの間のリンクは故障していないと理解することができる。デバイスEがデバイスB1によって送信されたメッセージを受信することができない場合、デバイスEは、デバイスB1が故障しているか、またはデバイスB1とデバイスEとの間のリンクが故障していると理解することができる。

別の可能な実装形態では、双方向転送検出（bidirectional forwarding detection、BFD）が、デバイスEとデバイスB1との間にさらに配備されてもよい。BFDセッションが作成された後、BFD制御パケットが周期的に送信される。一方の当事者が事前設定された時間間隔内にBFD制御パケットを受信しない場合、経路または一方の当事者が故障していると見なされる。たとえば、BFD制御パケットは、特定の時間間隔でデバイスEとデバイスB1との間で送信される。デバイスEが、時間間隔内に、デバイスB1によって送信されたBFD制御パケットを受信することができる場合、デバイスB1が故障していないか、またはデバイスB1とデバイスEとの間のリンクが故障していないと理解することができる。デバイスEが、時間間隔内に、デバイスB1によって送信されたBFD制御パケットを受信しない場合、デバイスB1が故障しているか、またはデバイスB1とデバイスEとの間のリンクが故障していると理解することができる。

場合によっては、本出願のこの実施形態では、デバイスB1にBFD制御パケットを送信するとき、デバイスEはデバイスB1のEnd.BIERアドレスを使用することができる。

デバイスB1のEnd.BIERアドレスは、共通のIPv6アドレスではないが、BIERv6パケットを処理するために使用されるデバイスB1上の特定のIPv6アドレスであることを理解されたい。End.BIERアドレスがデバイスB1上に構成された後、転送情報ベース（forwarding information base、FIB）内のアドレスに対して128ビットマスクを有する転送エントリが形成され、転送エントリはアドレスがEnd.BIERであることを識別する。IPv6パケットを受信すると、デバイスB1は、最初に、宛先アドレスを求めてFIBを探索する。FIBを探索した結果、宛先アドレスがEnd.BIERアドレスであったとき、デバイスB1は、End.BIER固有の動作を実行する、すなわち、IPv6拡張パケットヘッダ内のBIERヘッダを処理し続ける。あるいは、宛先アドレスが共通のIPv6宛先アドレスである場合、FIBの探索結果は、パケットが、現在のルータに送信され、宛先オプション拡張パケットヘッダを含むIPv6パケットであることを示す。この場合、パケットは、処理のためにCPUに送信されてもよく、データプレーン上で処理することはできない。

デバイスB1のEnd.BIERは、単にBIERv6パケットを処理するようにデバイスB1に指示するために使用され、BIER転送は、拡張パケットヘッダ内のBIERv6パケットヘッダに依存し、BIERv6パケットヘッダ内のBIFT-idフィールドに基づいて、パケットが属する特定の＜SD，BSL，SI＞を決定することと、次いで、bit stringに基づいて、どのSIの特定のBFERノードであり、どれにパケットが送信されるべきかを決定することとを含むことをさらに理解されたい。

デバイスEは、デバイスB1のEnd.BIERアドレスを使用してデバイスB1にBFD制御パケットを送信する。デバイスEが、事前設定された時間間隔内に、デバイスB1によって送信されたBFD制御パケットを受信することができない場合、デバイスB1はBIERv6パケットを転送することができないと判断することができる。具体的には、デバイスB1がEnd.BIERアドレスの構成を修正するか、またはデバイスB1のBIERプロセスが故障しているとき、デバイスEがデバイスB1のEnd.BIERアドレスを使用してデバイスB1にBFD制御パケットを送信する場合、デバイスB1は、現在の時間間隔内にデバイスEにBFD制御パケットを送信しない。このようにして、デバイスEは、デバイスB1がBIERv6パケットを転送できないことを認識することもでき、それによって検出精度がさらに向上する。

ステップ830：デバイスEが、デバイスR1～R5に到達するためのバックアップネクストホップが存在するかどうかを判定する。

デバイスEが、探索を介して、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのバックアップネクストホップが存在すると判定した場合、デバイスEはステップ840を実行する。

BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのバックアップネクストホップが存在しない場合、デバイスEはステップ850を実行する。

ステップ840：デバイスEがバックアップネクストホップにBIERv6パケットを送信する。

説明を簡単にするために、デバイスEがそれを介してBFR IDがそれぞれ1～5であるデバイスR1～R5に到達するアクティブネクストホップがデバイスB1であり、デバイスEがそれを介してBFR IDがそれぞれ1～5であるデバイスR1～R5に到達するバックアップネクストホップがデバイスB2である例が以下で説明に使用される。

具体的には、デバイスB1が故障しているとき、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのバックアップネクストホップがデバイスE上に構成された場合、デバイスEは、ネクストホップデバイスがデバイスB1であるルーティングテーブルを非アクティブ（inactive）に設定する。デバイスEは、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのバックアップネクストホップのルーティングテーブルをアクティブ（active）に設定し、アクティブ状態の新しいルーティングテーブルを転送テーブルとして選択する。たとえば、デバイスEは、BFR IDがそれぞれ1～5であるデバイスR1～R5に到達するためのネクストホップをデバイスB2に切り替え、次いで、デバイスB2は、BIERv6パケットを複製し転送する。

デバイスE上の可能なBIERv6ルーティングテーブルは、R1がリーフノードであり、デバイスE上の静的ネクストホップがデバイスBである例を使用して以下に記載される。
BIER Sub-Domain 0 Routing Table
Route Entry For BitStringLength 256, SetIdentifier 0
BFR Neighbor：--(static)
BIFT-ID ：1
BFR End.BIER：200:B1:1::1
Relay NextHop：FE80::1234:5678:90AB:CDEF
Out Interface：Ethernet1/0/1
F-BM(Hex)：0000000000000000000000000000000000000000000000000000000000001
Bfd Enble ：Yes
Bfd Name ：BierE_B1
Bfd Status ：up
Route Status：Active backup（バックアップ状態ではないとき転送テーブルは選択されない）
BFR End.BIER：200:B2:1::1
Relay NextHop：FE80::1234:5678:90AB:CDEE
Out Interface：Ethernet1/0/2
F-BM(Hex)：0000000000000000000000000000000000000000000000000000000000001
Bfd Enble ：Yes
Track Bfd ：BierE_B2
Bfd Status ：up
Route Status：backup

前述のルーティングテーブルにおいて、「BFR Neighbor：--(static)」は、すべてのBFR Neighborが動的に生成されることを示す。BIERの静的ネクストホップについては、本明細書では「Static」のみがマークされる。「BIFT-ID：1」は、リーフノードのBFR-idが1であることを示す。「BFR End.BIER：200:B1:1::1」は、その静的ネクストホップがデバイスB1であるEnd.bierを示す。「Relay NextHop：FE80::1234:5678:90AB:CDEF」は、デバイスB1のEnd.bierルータのネクストホップIPを示す。「Out Interface：Ethernet1/0/1」は、デバイスB1のEnd.bierルータのネクストホップアウトインターフェースを示す。「F-BM(Hex)：0000000000000000000000000000000000000000000000000000000000000001」は、BIERのbit string情報を示す。「Bfd Enble：Yes」は、Bierの静的転送テーブルを有効にする関連付けられたbfdを示す。「Bfd Name：BierE_B1」は、BIERの静的転送テーブルの関連付けられたbfdの名称情報を示す。「Bfd Status：up」は、BIERの静的転送テーブルの関連付けられたbfdがUPであることを示す。「Route Status：Active」は、BIERの静的転送テーブルのステータスがActiveである、すなわち、転送テーブルが選択されていることを示す。BIERの静的転送テーブルのステータスがInactiveである場合、転送テーブルは選択されていない（たとえば、関連付けられたbfdはdownである）。「BFR End.BIER：200:B2:1::1」は、そのネクストホップがデバイスB2であるEnd.bierを示す。「Relay NextHop：FE80::1234:5678:90AB:CDEE」は、デバイスB2のEnd.bierルータのネクストホップIPを示す。「Out Interface：Ethernet1/0/2」は、デバイスB2のEnd.bierルータのネクストホップアウトインターフェースを示す。「Route Status：backup」は、バックアップ状態でないときに転送テーブルが選択されず、バックアップ状態であるときに転送テーブルが選択されることを示す。

ステップ850：デバイスEがデバイスR1～R5に到達するためのバックアップネクストホップを見つけられず、トラフィックが中断される。

前述の技術的解決策では、ネクストホップBIERデバイスの到達可能性を迅速に認識することができる。ネクストホップBIERデバイスが故障しているとき、マルチキャストトラフィックはバックアップネクストホップBIERデバイスに切り替えられる。このようにして、既存のBIERv6解決策が十分に拡張されるだけでなく、ノードが故障した後にBIERマルチキャストサービスを迅速に切り替えることもできる。

本出願の実施形態で提供されるBIERv6パケットを転送するための方法は、図1～図9を参照して詳細に上述されている。本出願の装置実施形態は、図10～図12を参照して以下で詳細に記載される。方法実施形態の説明は、装置実施形態の説明に対応することを理解されたい。したがって、詳細に記載されていない部分については、前述の方法実施形態を参照されたい。

図10は、本出願の一実施形態による、第1のネットワークデバイス1000の概略構造図である。図10に示された第1のネットワークデバイス1000は、前述の実施形態の方法において第1のネットワークデバイスによって実行される対応するステップを実行することができる。図10に示されたように、第1のネットワークデバイス1000は、処理モジュール1010および送信モジュール1020を含む。

処理モジュール1010は、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断するように構成される。第1のネットワークデバイスはBIERドメイン内の入口デバイスであり、第2のネットワークデバイスはBIERドメイン内の出口デバイスであり、第1のネットワークデバイスはBIERドメイン内の第1のエリアに属し、第2のネットワークデバイスおよびアクティブネクストホップデバイスはBIERドメイン内の第2のエリアに属し、アクティブネクストホップデバイスは第2のエリア内の境界デバイスであり、第1のエリアに接続するように構成され、第1のエリアと第2のエリアは異なるプロトコルを有する。

送信モジュール1020は、第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにインターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するように構成される。バックアップネクストホップデバイスは、第1のエリアに接続するように構成された第2のエリア内の境界デバイスである。

場合によっては、処理モジュール1010は、BIERドメインのネットワークトポロジーに基づいて、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスおよびバックアップネクストホップデバイスを決定するようにさらに構成される。

場合によっては、送信モジュール1020は、アクティブネクストホップデバイスに双方向転送検出BFD制御パケットを送信するようにさらに構成される。BFD制御パケットの宛先アドレスは、アクティブネクストホップデバイスの第1のアドレスであり、第1のアドレスは、BIERv6パケットに対してBIER転送を実行するようにアクティブネクストホップデバイスに指示するために使用される。

処理モジュール1010は、アクティブネクストホップデバイスによって送信されたBFD制御パケットが事前設定された時間間隔内に受信されない場合、アクティブネクストホップデバイスが故障していると判断するようにさらに構成される。

場合によっては、アクティブネクストホップデバイスが故障していることは、以下のケース、すなわち、アクティブネクストホップデバイス自体が故障しているケース、アクティブネクストホップデバイスと第1のネットワークデバイスとの間の通信リンクが故障しているケース、またはアクティブネクストホップデバイスがBIERv6パケットに対するBIER転送をサポートしていないケースのうちの1つまたは複数を含む。

図11は、本出願の一実施形態による、第1のネットワークデバイス2000のハードウェア構造の概略図である。図11に示された第1のネットワークデバイス2000は、前述の実施形態の方法において第1のネットワークデバイスによって実行される対応するステップを実行することができる。

図11に示されたように、第1のネットワークデバイス2000は、プロセッサ2001、メモリ2002、インターフェース2003、およびバス2004を含む。インターフェース2003は、ワイヤレスまたは有線方式で実装されてもよく、具体的には、ネットワークインターフェースカードであってもよい。プロセッサ2001、メモリ2002、およびインターフェース2003は、バス2004を介して接続される。

インターフェース2003は、具体的に、送信機および受信機を含んでもよく、第1のネットワークデバイスによる前述の送信および受信を実現するように構成される。たとえば、インターフェース2003は、BIERv6パケットを受信するように構成されるか、または第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにBIERv6パケットを送信するように構成される。

プロセッサ2001は、前述の実施形態において第1のネットワークデバイスによって実行される処理を実行するように構成される。たとえば、プロセッサ2001は、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断するように構成され、かつ／または本明細書に記載された技術に記載された別のプロセスを実行するように構成される。メモリ2002は、オペレーティングシステム20021およびアプリケーションプログラム20022を含み、プログラム、コード、または命令を記憶するように構成される。プロセッサまたはハードウェアデバイスがプログラム、コード、または命令を実行すると、方法実施形態における第1のネットワークデバイスの処理プロセスを完了することができる。場合によっては、メモリ2002は、読取り専用メモリ（read-only memory、ROM）およびランダムアクセスメモリ（random access memory、RAM）を含んでもよい。ROMは、基本入出力システム（basic input／output system、BIOS）または組込み型システムを含み、RAMは、アプリケーションプログラムおよびオペレーティングシステムを含む。第1のネットワークデバイス2000が実行される必要があるとき、起動されるべきシステムを誘導し、通常の動作状態に入るように第1のネットワークデバイス2000を誘導するために、BIOS内のブートローダまたはROM内に固定された組込み型システムが使用される。通常の動作状態に入った後、第1のネットワークデバイス2000は、RAM内のアプリケーションプログラムおよびオペレーティングシステムを実行して、方法実施形態における第1のネットワークデバイス2000の処理プロセスを完了する。

図11は、単に第1のネットワークデバイス2000の簡略化された設計を示すことが理解されよう。実際の適用例では、第1のネットワークデバイスは、任意の数のインターフェース、プロセッサ、またはメモリを含んでもよい。

図12は、本出願の一実施形態による、別の第1のネットワークデバイス2100のハードウェア構造の概略図である。図12に示された第1のネットワークデバイス2100は、前述の実施形態の方法において第1のネットワークデバイスによって実行される対応するステップを実行することができる。

図12に示されたように、第1のネットワークデバイス2100は、主制御ボード2110、インターフェースボード2130、スイッチングボード2120、およびインターフェースボード2140を含む。主制御ボード2110、インターフェースボード2130および2140、ならびにスイッチングボード2120は、相互通信を実現するためにシステムバスを介してシステムバックプレーンに接続される。主制御ボード2110は、システム管理、デバイスメンテナンス、およびプロトコル処理などの機能を完了するように構成される。スイッチングボード2120は、インターフェースボード（インターフェースボードはラインカードまたはサービスボードとも呼ばれる）間でデータを交換するように構成される。インターフェースボード2130および2140は、（POSインターフェース、GEインターフェース、およびATMインターフェースなどの）様々なサービスインターフェースを提供し、パケット転送を実現するように構成される。

インターフェースボード2130は、中央処理装置2131、転送エントリメモリ2134、物理インターフェースカード2133、およびネットワークプロセッサ2132を含んでもよい。中央処理装置2131は、インターフェースボードを制御および管理し、主制御ボード上の中央処理装置と通信するように構成される。転送エントリメモリ2134は、エントリ、たとえば、前述のBIFTを記憶するように構成される。物理インターフェースカード2133は、トラフィックを受信および送信するように構成される。

本出願のこの実施形態では、インターフェースボード2140上の動作は、インターフェースボード2130上の動作と同じであることを理解されたい。簡潔にするために、詳細は再び記載されない。

この実施形態における第1のネットワークデバイス2100は、前述の方法実施形態において実現される機能および／またはステップに対応してもよく、本明細書では詳細は再び記載されないことを理解されたい。

加えて、1つまたは複数の主制御ボードが存在してもよいことに留意されたい。複数の主制御ボードが存在するとき、主制御ボードは、アクティブ主制御ボードおよびバックアップ主制御ボードを含んでもよい。1つまたは複数のインターフェースボードが存在してもよい。第1のネットワークデバイスのより強いデータ処理能力は、提供されるインターフェースボードの数がより多いことを示す。また、インターフェースボード上に1つまたは複数の物理インターフェースカードが存在してもよい。スイッチングボードが存在しなくてもよく、1つまたは複数のスイッチングボードが存在してもよい。複数のスイッチングボードが存在するとき、スイッチングボードは、負荷共有および冗長バックアップを一緒に実現することができる。集中転送アーキテクチャでは、第1のネットワークデバイスはスイッチングボードを必要としない場合があり、インターフェースボードがシステム全体のサービスデータ処理機能を引き受ける。分散転送アーキテクチャでは、第1のネットワークデバイスは少なくとも1つのスイッチングボードを有する場合があり、大容量のデータを交換および処理する能力を提供するために、スイッチングボードを使用して複数のインターフェースボード間でデータが交換される。したがって、分散アーキテクチャにおける第1のネットワークデバイスのデータアクセスおよび処理能力は、集中アーキテクチャにおけるデバイスのデータアクセスおよび処理能力よりも優れている。使用される特定のアーキテクチャは特定のネットワーキング展開シナリオに依存し、本明細書では限定されない。

本出願の一実施形態は、コンピュータ可読媒体をさらに提供する。コンピュータ可読媒体はプログラムコードを記憶し、コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第1のネットワークデバイスによって実行される方法を実行することが可能になる。コンピュータ可読記憶媒体には、以下のもの、すなわち、読取り専用メモリ（read-only memory、ROM）、プログラマブルROM（programmable ROM、PROM）、消去可能PROM（erasable PROM、EPROM）、Flashメモリ、電気的EPROM（electrically EPROM、EEPROM）、またはハードドライブ（hard drive）のうちの1つまたは複数が含まれるが、それらに限定されない。

本出願の一実施形態は、第1のネットワークデバイスに適用されるチップシステムをさらに提供する。チップシステムは、少なくとも1つのプロセッサ、少なくとも1つのメモリ、およびインターフェース回路を含む。インターフェース回路は、チップシステムと外部との間の情報交換に関与する。少なくとも1つのメモリ、インターフェース回路、および少なくとも1つのプロセッサは、ラインを介して相互接続される。少なくとも1つのメモリは命令を記憶し、命令は、前述の態様の方法における第1のネットワークデバイスの動作を実行するために、少なくとも1つのプロセッサによって実行される。

具体的な実装プロセスでは、チップは、中央処理装置（central processing unit、CPU）、マイクロコントローラユニット（micro controller unit、MCU）、マイクロ処理装置（micro processing unit、MPU）、デジタル信号プロセッサ（digital signal processor、DSP）、システムオンチップ（system on chip、SoC）、特定用途向け集積回路（application-specific integrated circuit、ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）、またはプログラマブルロジックデバイス（programmable logic device、PLD）の形態で実装されてもよい。

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

前述のプロセスのシーケンス番号は、本出願の様々な実施形態における実行順序を意味しないことを理解されたい。プロセスの実行順序は、プロセスの機能および内部ロジックに従って決定されるべきであり、本出願の実施形態の実装プロセスに対するいかなる制限としても解釈されるべきではない。

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

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

本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、および方法は、他の方式で実装されてもよいことを理解されたい。たとえば、記載された装置実施形態は一例にすぎない。たとえば、ユニット分割は、単なる論理的な機能分割であり、実際の実装形態では他の分割であってもよい。たとえば、複数のユニットまたは構成要素は組み合わされるか、または別のシステムに統合されてもよく、いくつかの機能は無視されるか、または実行されなくてもよい。加えて、表示または説明された相互結合または直接結合または通信接続は、いくつかのインターフェースを使用して実現されてもよい。装置間またはユニット間の間接結合または通信接続は、電気、機械、または他の形態で実現されてもよい。

別々の部分として記載されたユニットは、物理的に分離されていてもいなくてもよく、ユニットとして表示された部分は物理ユニットであってもなくてもよく、1つの場所に配置されてもよく、複数のネットワークユニットに分散されてもよい。ユニットの一部またはすべては、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されてもよい。

加えて、本出願の実施形態における機能ユニットは1つの処理ユニットに統合されてもよく、またはユニットの各々は物理的に単独で存在してもよく、または2つ以上のユニットが1つのユニットに統合される。

機能が、ソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用されるとき、機能は、コンピュータ可読記憶媒体に格納されてもよい。そのような理解に基づいて、本出願の技術的解決策は本質的に、または従来技術に寄与する部分、または技術的解決策の一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体に格納され、（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであってもよい）コンピュータデバイスに、本出願の実施形態に記載された方法のステップの全部または一部を実行するように指示するためのいくつかの命令を含む。上記の記憶媒体には、USBフラッシュドライブ、リムーバブルハードディスク、読取り専用メモリ（read-only memory、ROM）、ランダムアクセスメモリ（random access memory、RAM）、磁気ディスク、または光ディスクなどの、プログラムコードを格納することができる任意の媒体が含まれる。

上記の説明は、本出願の単なる特定の実装形態にすぎず、本出願の保護範囲を限定するものではない。本出願で開示された技術的範囲内で当業者によって容易に考え出されるいかなる変形または置換も、本出願の保護範囲内に入るべきである。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うべきである。

1000 第1のネットワークデバイス
1010 処理モジュール
1020 送信モジュール
2000 第1のネットワークデバイス
2001 プロセッサ
2002 メモリ
20021 オペレーティングシステム
20022 アプリケーションプログラム
2003 インターフェース
2004 バス
2100 第1のネットワークデバイス
2110 主制御ボード
2111 中央処理装置
2120 スイッチングボード
2130 インターフェースボード
2131 中央処理装置
2132 ネットワークプロセッサ
2133 物理インターフェースカード
2134 転送エントリメモリ
2140 インターフェースボード
2141 中央処理装置
2142 ネットワークプロセッサ
2143 物理インターフェースカード
2144 転送エントリメモリ

Claims

インターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するための方法であって、
第1のネットワークデバイスにより、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断するステップであって、前記第1のネットワークデバイスがBIERドメイン内の入口デバイスであり、前記第2のネットワークデバイスが前記BIERドメイン内の出口デバイスであり、前記第1のネットワークデバイスが前記BIERドメイン内の第1のエリアに属し、前記第2のネットワークデバイスおよび前記アクティブネクストホップデバイスが前記BIERドメイン内の第2のエリアに属し、前記アクティブネクストホップデバイスが、前記第2のエリア内の境界デバイスであり、前記第1のエリアに接続するように構成され、前記第1のエリアと前記第2のエリアが異なるプロトコルを有する、ステップと、
前記第1のネットワークデバイスにより、前記第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにBIERv6パケットを送信するステップであって、前記バックアップネクストホップデバイスが、前記第2のエリア内の境界デバイスであり、前記第1のエリアに接続するように構成される、ステップと
を有し、
第1のネットワークデバイスにより、第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断する前記ステップが、
前記第1のネットワークデバイスにより、双方向転送検出（BFD）制御パケットを前記アクティブネクストホップデバイスに送信するステップであって、前記BFD制御パケットの宛先アドレスが前記アクティブネクストホップデバイスの第1のアドレスであり、前記第1のアドレスが、前記BIERv6パケットに対してBIER転送を実行するように前記アクティブネクストホップデバイスに指示するために使用される、ステップと、
前記第1のネットワークデバイスが、前記アクティブネクストホップデバイスによって送信されたBFD制御パケットを事前設定された時間間隔内に受信しない場合、前記第1のネットワークデバイスにより、前記アクティブネクストホップデバイスが故障していると判断するステップと
を含む、方法。
前記第1のネットワークデバイスにより、前記BIERドメインのネットワークトポロジーに基づいて、前記第2のネットワークデバイスに到達するための前記アクティブネクストホップデバイスおよび前記バックアップネクストホップデバイスを決定するステップ
をさらに有する、請求項1に記載の方法。
前記アクティブネクストホップデバイスが故障していることが、前記アクティブネクストホップデバイス自体が故障しているケース、前記アクティブネクストホップデバイスと前記第1のネットワークデバイスとの間の通信リンクが故障しているケース、または前記アクティブネクストホップデバイスが前記BIERv6パケットに対するBIER転送をサポートしていないケースのうちの1つまたは複数を含む、請求項1または2に記載の方法。
第1のネットワークデバイスであって、
第2のネットワークデバイスに到達するためのアクティブネクストホップデバイスが故障していると判断するように構成された処理モジュールであって、前記第1のネットワークデバイスがBIERドメイン内の入口デバイスであり、前記第2のネットワークデバイスが前記BIERドメイン内の出口デバイスであり、前記第1のネットワークデバイスが前記BIERドメイン内の第1のエリアに属し、前記第2のネットワークデバイスおよび前記アクティブネクストホップデバイスが前記BIERドメイン内の第2のエリアに属し、前記アクティブネクストホップデバイスが、前記第2のエリア内の境界デバイスであり、前記第1のエリアに接続するように構成され、前記第1のエリアと前記第2のエリアが異なるプロトコルを有する、処理モジュールと、
前記第2のネットワークデバイスに到達するためのバックアップネクストホップデバイスにインターネットプロトコルバージョン6ベースのビットインデックス明示的複製（BIERv6）パケットを送信するように構成された送信モジュールであって、前記バックアップネクストホップデバイスが、前記第2のエリア内の境界デバイスであり、前記第1のエリアに接続するように構成される、送信モジュールと
を備え、
前記送信モジュールが、双方向転送検出（BFD）制御パケットを前記アクティブネクストホップデバイスに送信するようにさらに構成され、前記BFD制御パケットの宛先アドレスが前記アクティブネクストホップデバイスの第1のアドレスであり、前記第1のアドレスが、前記BIERv6パケットに対してBIER転送を実行するように前記アクティブネクストホップデバイスに指示するために使用され、
前記処理モジュールが、前記アクティブネクストホップデバイスによって送信されたBFD制御パケットが事前設定された時間間隔内に受信されない場合、前記アクティブネクストホップデバイスが故障していると判断するようにさらに構成される、第1のネットワークデバイス。
前記処理モジュールが、前記BIERドメインのネットワークトポロジーに基づいて、前記第2のネットワークデバイスに到達するための前記アクティブネクストホップデバイスおよび前記バックアップネクストホップデバイスを決定するようにさらに構成される、請求項4に記載の第1のネットワークデバイス。
前記アクティブネクストホップデバイスが故障していることが、前記アクティブネクストホップデバイス自体が故障しているケース、前記アクティブネクストホップデバイスと前記第1のネットワークデバイスとの間の通信リンクが故障しているケース、または前記アクティブネクストホップデバイスが前記BIERv6パケットに対するBIER転送をサポートしていないケースのうちの1つまたは複数を含む、請求項4または5に記載の第1のネットワークデバイス。
プロセッサおよびメモリを備え、前記メモリがプログラムを記憶するように構成され、前記プロセッサが、前記メモリから前記プログラムを呼び出し、前記プログラムを実行して、請求項1から3のいずれか一項に記載の方法を実行するように構成される、第1のネットワークデバイス。
コンピュータプログラムまたはコードを記憶しており、前記コンピュータプログラムまたはコードがコンピュータ上で実行されると、前記コンピュータが、請求項1から3のいずれか一項に記載の方法を実行可能となる、コンピュータ可読記憶媒体。