JP2021170772A - パケット検出方法および第１のネットワーク機器 - Google Patents

Abstract

【課題】パケット検出方法および第1のネットワーク機器を提供すること。【解決手段】本出願は、パケット検出方法を提供する。本方法は、第1のネットワーク機器によって、ビットインデックス明示的複製BIERパケットを取得するステップであって、BIERパケットはトラップ情報を含み、トラップ情報は、BIERパケットが有効なBIERパケットであるかどうか指示するのに使用される、ステップと、第1のネットワーク機器によって、トラップ情報が有効であるかどうかを判定するステップと、第1のネットワーク機器がトラップ情報が有効であると判定したときに、第1のネットワーク機器によって、BIERパケットが無効なBIERパケットであると判定するステップと、を含む。本出願で提供される技術的解決策によれば、無効なBIERパケットを検出して、BIERパケット転送プロセスにおけるセキュリティまたはBIERパケットカプセル化の精度を向上させることができる。【選択図】図6

Description

本出願は、ネットワーク通信の分野に関し、より具体的には、パケット検出方法および第1のネットワーク機器に関する。

インターネットプロトコル（internet protocol、IP）マルチキャスト技術は、IPネットワーク上で効率的なポイントツーマルチポイントデータ送信を実施し、それによってネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減する。したがって、マルチキャストデータ転送経路を構築するための新しい技術が業界で提案されており、ビットインデックス明示的複製（bit index explicit replication、BIER）技術と呼ばれている。この技術は、マルチキャスト配信ツリーを構築する必要のない新しいマルチキャスト技術アーキテクチャを提案する。

関連する技術的解決策では、BIERパケットはいくつかのセキュリティ機構を欠いている。その結果、無効なBIERパケットが、BIERドメインで大量に複製され、マルチキャストトラフィックを受信する必要がないデバイスに送信されうる。これは、リンク帯域幅の浪費を引き起こし、さらには、リンクにおけるサービス妨害（denial of service、DoS）を引き起こす。

本出願で提供されるパケット検出方法および第1のネットワーク機器によれば、BIERパケット転送プロセスにおけるセキュリティまたはBIERパケットカプセル化の精度を高めるために、無効なBIERパケットを検出することができる。

第1の態様によれば、パケット検出方法が提供される。本方法は、第1のネットワーク機器が、ビットインデックス明示的複製BIERパケットを取得することを含み、BIERパケットはトラップ情報を含み、トラップ情報は、BIERパケットが有効なBIERパケットであるかどうかを示すために使用される。第1のネットワーク機器は、トラップ情報が有効であるかどうかを判定する。第1のネットワーク機器は、第1のネットワーク機器がトラップ情報が有効であると判定した場合、BIERパケットが無効なBIERパケットであると判定する。

前述の技術的解決策において、BIERパケットを取得した後で、第1のネットワーク機器は、BIERパケット内のトラップ情報が有効であるかどうかに基づいて、BIERパケットが有効なBIERパケットであるかどうか判定することができる。このようにして、一方では、攻撃者がBIERパケットを改ざんした場合、BIERパケット内のトラップ情報は有効である。第1のネットワーク機器は、BIERパケットが悪意をもって改ざんされた挙動を検出してもよく、またはBIERパケットが悪意をもって改ざんされた挙動を検出する確率を高めてもよく、それによってBIERパケット転送プロセスにおけるセキュリティを強化する。一方、BIERドメインのネットワーク機器がBIERパケットのパケットヘッダ情報をカプセル化するときに障害またはエラーが発生した場合、このケースは、本出願で提供される方法を使用することによってさらに検出することができ、それによってBIERパケットカプセル化の精度が向上する。

さらに、前述の技術的解決策において、無効なBIERパケットが識別され、無効なデバイスがさらにロックされてもよく、またはBIERパケットを転送および処理するネットワーク機器に障害が存在するかどうかが判定されてもよい。

1つの可能な実施態様では、BIERパケットはビット列BitStringを含み、BitStringはトラップ情報を含む。

別の可能な実施態様では、トラップ情報は1ビットである。

別の可能な実施態様では、トラップ情報は複数のビットを含む。

1つの可能な実施態様では、複数のビットのうちの少なくとも2つは互いに隣接していない。

前述の技術的解決策では、複数のビットのうちの少なくとも2つは互いに隣接しないように設定され、その結果、複数のトラップがBIERパケットに設定される。これは、BIERパケットカプセル化の精度を向上させるか、またはBIERパケットが悪意をもって改ざんされた挙動を検出する確率を高める。

別の可能な実施態様では、複数のビットのうちの少なくとも2つが互いに隣接している。

別の可能な実施態様では、第1のネットワーク機器がトラップ情報が有効であると判定した場合に、第1のネットワーク機器がBIERパケットが無効なBIERパケットであると判定することは、第1のネットワーク機器が複数のビットのうちのいずれか1つが有効であると判定した場合に、第1のネットワーク機器がBIERパケットが無効なBIERパケットであると判定することを含む。

別の可能な実施態様では、本方法は、第1のネットワーク機器が複数のビットのすべてが無効であると判定した場合に、第1のネットワーク機器がBIERパケットが有効なBIERパケットであると判定することをさらに含む。

別の可能な実施態様では、本方法は、第1のネットワーク機器が、第2のネットワーク機器によってフラッディングされたBIER情報を受信し、第2のネットワーク機器はBIERドメインの中間転送デバイスであり、BIERドメインは第1のネットワーク機器を含み、BIER情報は第2のネットワーク機器のビット転送ルータ識別子BFR−IDを含み、BFR−IDは、第2のネットワーク機器がBIERドメインのエッジ転送デバイスであることを示すために使用される、ことをさらに含む。

別の可能な実施態様では、第1のネットワーク機器がトラップ情報が有効であるかどうかを判定する前に、本方法は、第1のネットワーク機器が制御メッセージを受信し、制御メッセージはBIERパケット内のトラップ情報を示す、ことをさらに含む。第1のネットワーク機器は、制御メッセージに基づいてBIERパケット内のトラップ情報を取得する。

別の可能な実施態様では、本方法は、第1のネットワーク機器が第1のエントリを作成することであって、第1のエントリがトラップ情報を含み、第1のエントリが、トラップ情報が有効であるときにアラームを送信するかまたはログ情報を記録することを示す、ことと、第1のネットワーク機器がトラップ情報が有効であると判定したときに、アラームを送信することまたはログ情報を記録することと、をさらに含む。

第2の態様によれば、第1のネットワーク機器が提供される。第1のネットワーク機器は、
ビットインデックス明示的複製BIERパケットを取得するように構成された取得モジュールであって、BIERパケットはトラップ情報を含み、トラップ情報はBIERパケットが有効なBIERパケットであるかどうか指示するために使用される、取得モジュールと、
トラップ情報が有効であるかどうかを判定するように構成された判定モジュールと、
を含み、
判定モジュールは、トラップ情報が有効であると判定された場合に、BIERパケットが無効なBIERパケットであると判定するようにさらに構成される。

1つの可能な実施態様では、BIERパケットはビット列BitStringを含み、ビット列はトラップ情報を含む。

別の可能な実施態様では、トラップ情報は複数のビットを含む。

1つの可能な実施態様では、複数のビットのうちの少なくとも2つは互いに隣接していない。

別の可能な実施態様では、判定モジュールは、複数のビットのいずれか1つが有効であると判定された場合に、BIERパケットが無効なBIERパケットであると判定するように特に構成される。

別の可能な実施態様では、判定モジュールは、複数のビットのすべてが有効であると判定された場合に、BIERパケットが有効なBIERパケットであると判定するようにさらに構成される。

別の可能な実施態様では、取得モジュールは、第2のネットワーク機器によってフラッディングされたBIER情報を受信し、第2のネットワーク機器はBIERドメインの中間転送デバイスであり、BIERドメインは第1のネットワーク機器を含み、BIER情報は第2のネットワーク機器のビット転送ルータ識別子BFR−IDを含み、BFR−IDは、第2のネットワーク機器がBIERドメインのエッジ転送デバイスであることを示すために使用される、ようにさらに構成される。

別の可能な実施態様では、取得モジュールは、制御メッセージを受信し、制御メッセージはBIERパケット内のトラップ情報を示し、制御メッセージに基づいてBIERパケット内のトラップ情報を取得する、ようにさらに構成される。

別の可能な実施態様では、第1のネットワーク機器は、第1のエントリを作成するように構成された作成モジュールであって、第1のエントリはトラップ情報を含み、第1のエントリは、トラップ情報が有効であるときにアラームを送信するかまたはログ情報を記録することを示す、作成モジュールをさらに含み、
判定モジュールは、トラップ情報が有効であると判定されたときに、アラームを送信するかまたはログ情報を記録するようにさらに構成される。

第2の態様および第2の態様の任意の可能な実施態様の有利な効果は、第1の態様および第1の態様の任意の可能な実施態様の有利な効果に対応する。詳細は本明細書では繰り返し説明されない。

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

1つの可能な設計では、第1のネットワーク機器の構造は、プロセッサおよびインターフェースを含む。プロセッサは、前述の方法における対応する機能を実行する際に第1のネットワーク機器をサポートするように構成される。インターフェースは、BIERパケットを取得する際に第1のネットワーク機器をサポートするように構成されるか、または第1のネットワーク機器と第2のネットワーク機器との間の通信をサポートし、第2のネットワーク機器によってフラッディングされたBIER情報を受信するように構成されるか、または制御メッセージを受信する際にサポートするように構成される。第1のネットワーク機器は、メモリをさらに含んでいてもよい。メモリは、プロセッサに結合されるように構成され、メモリは、第1のネットワーク機器に必要なプログラム命令およびデータを格納する。

別の可能な設計では、第1のネットワーク機器は、プロセッサ、送信機、受信機、ランダムアクセスメモリ、読み出し専用メモリ、およびバスを含む。プロセッサは、バスを介して送信機、受信機、ランダムアクセスメモリ、および読み出し専用メモリに別々に結合されている。第1のネットワーク機器が動作する必要がある場合、基本入出力システムまたは読み取り専用メモリに組み込まれた組み込みシステムのブートローダが、起動するシステムをブートし、通常の動作状態に入るように第1のネットワーク機器をブートするために使用される。通常の動作状態に入った後、第1のネットワーク機器は、ランダムアクセスメモリ内でアプリケーションプログラムおよびオペレーティングシステムを実行し、これにより、プロセッサは、第1の態様または第1の態様の可能な実施態様のいずれか1つの方法を実行する。

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

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

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

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

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

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

第9の態様によれば、システムが提供される。システムは、前述の第1のネットワーク機器を含む。

本出願の一実施形態によるBIER技術の概略ネットワーク図である。 本出願の一実施形態による可能なBIERヘッダフォーマットの概略図である。 別の可能なBIERヘッダフォーマットの概略ブロック図である。 BIER技術に基づいてBIER転送テーブルを作成し、BIERパケットを転送するプロセスを示す。 本出願の一実施形態による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つの物品（piece）」またはその同様の表現は、単一の物品（piece）または複数の物品（pieces）の任意の組み合わせを含む、これらの物品の任意の組み合わせを指す。例えば、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）ネットワーク上の複数の受信機に同時に効率よくデータが送信されるデータ伝送モードである。マルチキャストソースは、ネットワーク内のリンクを介してマルチキャストグループ内のマルチキャストグループメンバにマルチキャストストリームを送信し、マルチキャストグループ内の各マルチキャストグループメンバは、マルチキャストストリームを受信することができる。マルチキャスト伝送モードは、マルチキャストソースとマルチキャストグループメンバとの間のポイントツーマルチポイントデータ接続を実装する。マルチキャストストリームは、各ネットワークリンク上で1回だけ送信される必要があり、マルチキャストストリームは、リンクの分岐が存在する場合にのみ複製される。したがって、マルチキャスト伝送モードは、データ伝送効率を改善し、バックボーンネットワーク上の輻輳の可能性を低減する。

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

したがって、マルチキャストデータ転送経路を構築するための新しい技術が業界で提案されており、ビットインデックス明示的複製（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ドメインでは、グローバルに一意のビット位置（bit position）識別子が、BIERサブドメイン全体（sub domain、SD）のエッジBFRに対して構成されうる。一例として、各エッジBFRにBFR識別子（BFR identifier、BFR ID）として値が設定される。例えば、BFR IDは、1〜256の範囲の値であってもよい。BIERドメイン内のすべてのBFR IDは、1つのビット列（BitString）を形成する。

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

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

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

複数のBIERカプセル化タイプが存在しうる。これは、本出願では特に限定されない。一例として、BIERパケットは、マルチプロトコルラベルスイッチング（multi−protocol label switching、MPLS）を使用することによってカプセル化されてもよく、そのようなカプセル化は、BIER−MPLSカプセル化と呼ばれてもよい。別の例として、BIERパケットは、インターネットプロトコルバージョン6（internet protocol version 6、IPv6）に基づいてカプセル化されてもよく、そのようなカプセル化は、BIERv6カプセル化と呼ばれてもよい。

以下、図2〜図4を参照して、BIER−MPLSカプセル化関連技術について詳細に説明する。

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

図2は、可能なBIERヘッダフォーマットの概略ブロック図である。図2に示されるように、BIERヘッダは、20ビットの長さを有するビットインデックス転送テーブル識別子（bit index forwarding table identifier、BIFT ID）フィールド、ビット列長（BitString length、BSL）フィールド、および64ビット（8バイト）の長さを有する別のフィールド、例えば、BIERヘッダの後の元のマルチキャストデータパケットのものである、トラフィッククラス（traffic class、TC）フィールド、スタック（stack、S）フィールド、有効時間（time to live、TTL）フィールド、エントロピー（entropy）フィールド、バージョン（version、Ver）フィールド、protoフィールドなどを含んでいてもよいが、これらに限定されない。

以下、BIERヘッダ内のフィールドについて詳細に説明する。

（1）BIFT IDフィールド
BIFT IDフィールドの長さは20ビットである。BIER−マルチプロトコルラベルスイッチング（multi protocol label switching、MPLS）カプセル化の下では、BIFT IDフィールドはMPLSラベル（label、L）である。MPLSラベルはBIERラベルと呼ばれてもよく、TC／S／TTLフィールドなどのBIFT IDフィールドの後のフィールドは、標準的なラベル符号化フォーマット内にある。以下、TC／S／TTLフィールドなどのフィールドについて個別に説明し、ここでは一時的に詳細を説明しない。

BIFT IDは、BIFT−idであってもよく、サブドメイン（sub−domain、SD）／ビット列長（BitString 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つのサブドメイン、すなわちデフォルトサブドメイン0を含む必要がある。BIERドメインが複数のサブドメインに分割される場合、BIERドメイン内の各BFRは、すべてのサブドメインで構成される必要がある。例えば、BIERドメイン内の各BFR上に1つのサブドメイン0を構成することができ、システムデフォルトトポロジが使用される。次いで、1つのサブドメイン1を構成することができ、マルチキャストトポロジが使用される。

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

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

2．ビット列長（BitString length、BSL）
BSLは、BIERヘッダに含まれるBitStringの長さである。複数のBSLタイプが存在してもよい。これについては本出願のこの実施形態では特に限定されない。BSLの最小長は64ビットである。BSLの長さは、連続して128ビット、256ビット、512ビット、1024ビット、または2048ビットであってもよい。BSLの最大長は4096ビットである。具体的には、パケット内の識別に4ビットが使用される。例えば、BSLの長さが64ビットである場合、パケット内の識別に0001が使用され、BSLの長さが128ビットである場合、パケット内の識別に0010が使用され、BSLの長さが512ビットである場合、パケット内の識別に0100が使用され、BSLの長さが1024ビットである場合、パケット内の識別に0101が使用され、以下同様である。

3．セット識別子（set identifier、SI）
ネットワーク内のBFERノードの数が256より大きい場合、この状況に適応するために、BIERカプセル化は、1つのBitStringを含むだけでなく、1つのセット識別子（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：SD 0に対応、BSL 256、SI 0／／SD 0／BSL 256／SI 0相当、
BIFT ID＝2：SD 0に対応、BSL 256、SI 1／／SD 0／BSL 256／SI 1相当、
BIFT ID＝3：SD 0に対応、BSL 256、SI 2／／SD 0／BSL 256／SI 2相当、
BIFT ID＝4：SD 0に対応、BSL 256、SI 3／／SD 0／BSL 256／SI 3相当、
BIFT ID＝5：SD 0、BSL 512、SI 0／／SD 0／BSL 512／SI 0相当、
BIFT ID＝6：SD 0に対応、BSL 512、SI 1／／SD 0／BSL 512／SI 1相当、
BIFT ID＝7：SD 1に対応、BSL 256、SI 0／／SD 1／BSL 256／SI 0相当、
BIFT ID＝8：SD 1に対応、BSL 256、SI 1／／SD 1／BSL 256／SI 1相当、
BIFT ID＝9：SD 1に対応、BSL 256、SI 2／／SD 1／BSL 256／SI 2相当、
BIFT ID＝10：SD 1、BSL 256、SI 3／／SD 1／BSL 256／SI 3相当、
BIFT ID＝11：SD 1に対応、BSL 512、SI 0／／SD 1／BSL 512／SI 0相当、および、
BIFT ID＝12：SD 1に対応、BSL 512、SI 1／／SD 1／BSL 512／SI 1相当

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

（2）ビット列（BitString）フィールド
BitString内の各ビットは、エッジBFRを識別するために使用される。例えば、BitStringの最下位ビット（右端のビット）は、BFR−IDが1であるBFERを識別するために使用される。BitString内の右から左への2番目のビットは、BFR−IDが2であるBFERを識別するために使用される。転送プレーンによる転送に依存する転送エントリにおいて、パケットがBFERに送信されるべきであることは、パケット内のBitStringに基づいて決定される。BIERドメイン内のBFRがBIERを含むパケットヘッダを受信すると、BFRは、BIERヘッダで運ばれるBitStringおよびBIFT IDに基づいてBIERパケットを転送する。

ビットの値が1である場合、それは、BFR−IDによって表されるBFERノードにパケットが送信される必要があることを表し、またはビットの値が0である場合、それは、BFR−IDによって表されるBFERノードにパケットが送信される必要がないことを表すことに留意されたい。

BIFT ID＝2が例として使用される。BIERパケットを受信した後、BFRは、BIERヘッダ内のBIFT IDに基づいて、BIERパケットがSD 0に属すると判定することができる。BIERヘッダで使用されるBSLの長さは256ビットであり、BIFT IDはセット1に属する（BFR IDが257〜512である256個のエッジBFRのセットを含む）。

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

（4）スタック（stack、S）フィールド
Sは、スタックの底部のマークである。BIERパケットヘッダでは、マークの値は1である。言い換えると、MPLSラベルは、ラベルスタック全体の最底部のラベルである。

（5）バージョン（version、Ver）フィールド
バージョンフィールドの長さは4ビットであり、バージョンフィールドは、IPバージョン番号を識別するために使用される。値4はIPv4を示し、値6はIPv6を示す。

（6）エントロピー（entropy）フィールド
1つのトラフィックに属する複数のパケットのエントロピーは同一であり、異なるトラフィックに属する複数のパケットのエントロピーは異なる。パケットが転送されるとき、エントロピーに基づいて異なるトラフィックが異なるリンクに分配されてもよく、同じトラフィックの複数のパケットは同じリンクを介して転送される。

（7）Protoフィールド
protoフィールドは、BIERパケットヘッダの後のペイロードフォーマットを識別するために使用される。例えば、値4および6は、それぞれIPv4パケットおよびIPv6パケットを表す。値2は、アップストリーム割り当てラベルのMPLSパケットを表し、BIERを介したマルチキャスト仮想プライベートネットワーク（multicast virtual private network、MVPN）で使用されるproto値である。アップストリーム割り当てラベルを使用するのは、マルチキャストがポイントツーマルチポイント送信であり、送信側プロバイダエッジ（provider edge、PE）デバイスは、一意のラベルを割り当て、制御プレーンを介して受信側PEデバイスに一意のラベルを送信することができ、データパケットは、送信側PEデバイスによって割り当てられ、かつ受信側PEデバイスで識別されたラベルを使用するからである。受信側PEデバイスの場合、ラベルは、受信側PEデバイスによって割り当てられず、送信側PEデバイスによって割り当てられ、アップストリーム割り当てラベルと呼ばれる。

（8）Nibberフィールド
nibberフィールドの長さは4ビットであり、固定値は0101である。このフィールドは、BIER、IPv4、およびIPv6などのMPLSによって運ばれるサービスを区別するために使用される。MPLSカプセル化および転送中、ラベルスタック後のIPv4またはIPv6ヘッダは、ECMPをサポートするためにチェックされる。

（9）BFIR−idフィールド
BFIR−idフィールドは、BFIRのBFR−IDを識別するために使用される。BFIRノードは、サブドメインを使用してBIERパケットをカプセル化して送信し、BFIR−idフィールドは、サブドメイン内のノードのBFR−IDを書き込むために使用される。

（10）BitStringフィールド
ビット列フィールドは、BIERパケットの宛先ノードセットの文字列である。

図3は、別の可能なBIERヘッダフォーマットの概略ブロック図である。図2に示されるBIERヘッダフォーマットと比較して、図3に示されるBIERヘッダフォーマットは、BIFT−IDフィールドを含まないが、SDフィールド、BSLフィールド、およびSIフィールドの3つのフィールドを含む。言い換えると、図3に示されるBIERヘッダフォーマットは、SDフィールド、BSLフィールド、およびSIフィールドの3つのフィールドを直接含み、SD／BSL／SIフィールドの値は、BIFT IDフィールドからマッピングされる必要はない。

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

以下、図4において、BIER技術に基づいてBIER転送テーブルを作成し、BIERパケットを転送するプロセスを詳細に説明する。

図4に示されるBIERドメインは、ノードAからノードFを含むことができる。ノードA、ノードD、ノードE、およびノードFは、BIERドメインのエッジBFRであり、ノードBおよびノードCは、BIER中間転送ノードである。具体的には、ノードAは、BIERドメインの入口に位置し、元のマルチキャストデータパケットに対してBIERカプセル化を実行する役割を担う。ノードAは、図1のBFIRに対応する。ノードD、ノードE、およびノードFは、BIERドメインの出口に位置し、BIERパケットから元のマルチキャストデータパケットを取得するためにデカプセル化を実行する役割を担う。ノードD、ノードE、およびノードFは、図1のBFIRに対応する。

本出願のこの実施形態では、各BIERドメイン内のエッジBFRに一意のBFR−IDが割り当てられうる。例えば、図4では、ノードA、ノードD、ノードE、およびノードFに対して構成されたBFR−IDは、それぞれ4、1、2、および3である。BFR−IDは、ノードBおよびノードCなどの中間転送を行うBFRには割り当てられない。

本出願の実施形態では、「ID」および「id」は、交換可能に使用される場合があることに留意されたい。違いが強調されていない場合、用語によって表現された意味は一致していることに留意されたい。本出願におけるBFR−IDは、図4のidに対応する。

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

各BIERドメインのエッジBFRに割り当てられたBFR−IDの値は、ルーティングプロトコルに従ってBIERドメインの別のBFRにフラッディングされてもよく、フラッディングされたBIER情報は、エッジBFRのIPアドレスおよびカプセル化情報をさらに含むことを理解されたい。例えば、ノードAのフラッディングされたBIER情報は、ノードAのIPアドレスおよびBIFT−idを運ぶ。BIERドメインのBFR（例えば、図4のノードF）は、図4のノードFがBIERパケットを受信した後、作成されたBIFTエントリに基づいてBIERパケットが宛先ノードに転送されるように、フラッディングされたBIER情報に基づいてBIFTエントリを作成してもよい。

ノードAの場合、BIERパケットが、BFR−IDがそれぞれ1、2、および3であるBFERに送信される必要がある場合、BIERパケットは、まず、ノードAの隣接者（ノードB）に送信される必要があり、BFR−IDが4であるエッジBFRは、ノードA自体である。したがって、ノードAによって作成されたBIFTエントリは、以下のように示される。
転送エントリ1：neighbor（Nbr）＝B、かつ転送ビットマスク（forwarding bit mask、FBM）＝0111、および、
転送エントリ2：Nbr＊＝A、およびFBM＝1000

転送エントリ1は、BIERパケット内のBitStringの右から左への第1のビット、第2のビット、および第3のビットのいずれか1つが1である場合、BIERパケットがノードAの隣接者（ノードB）に送信されることを表すために使用される。Nbr＝Bは、ノードAの隣接者がノードBであることを表す。

転送エントリ2は、BIERパケット内のBitStringの右から左へ4番目のビットが1である場合、BIERパケットがノードAに送信されることを表すために使用される。ノードA自体については、ノードAはBIERヘッダを除去し、元のマルチキャストデータパケット内の情報に基づいて転送を実行する。前述の転送エントリ2において、＊は、Nbrをノード自体として識別するために使用されることに留意されたい。例えば、ノードAの場合、Nbr＊＝Aは、ノードAの隣接ノードがノードA自体であることを表す。同様に、図4の別のノードも、別のノード自体の隣接ノードに基づいてBIFTエントリを作成することができる。別のノードによって作成されたBIFTエントリについては、図4を参照されたい。詳細は本明細書では繰り返し説明されない。

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

BIER−MPLSカプセル化中、BIERヘッダの最初の32ビットはMPLSラベルコードであり、最初の32ビットの最初の20ビットは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ラベルとも呼ばれる。

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

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

BIERドメイン（BIER domain）は、IGPまたはBGPを使用することによってBIER情報をフラッディングすることができ、BIFTエントリを作成できるネットワークエリアを指すことを理解されたい。BIERドメインは、BFIRおよびBFERを含む。BIER情報は、各エッジBFRのBFR IDを含みうるが、これに限定されない。一例として、IGPが採用され、BIER情報が自律システム（autonomous system、AS）ドメイン内でフラッディングされる。ASドメインは、BIERドメイン（BIER domain）である。

一般に、大規模なネットワークは、複数のドメインに分割される。例えば、ネットワークは、異なる管理ドメインに基づいて異なるASに分割することができる。ASの境界は、自律システム境界ルータ（autonomous system border router、ASBR）とすることができる。IGPが採用されてもよく、BIER情報が異なるASでフラッディングされる。BGPが複数のAS間で採用されるが、BIER情報がフラッディングされない場合、複数のASは異なるBIERドメイン（BIER domain）でありうる。

以下、図5を参照して、BIERv6カプセル化関連技術について詳細に説明する。

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

このカプセル化の下で、IPv6ヘッダおよびBIERヘッダを含むIPv6拡張ヘッダは、一緒に、内側の元のマルチキャストデータパケットの外部パケットヘッダを形成する。内側の元のマルチキャストデータパケットの外部パケットヘッダは、本出願の本実施形態ではBIERv6ヘッダとも呼ばれうる。

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

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

DOHは、タイプ、長さ、および値（type length value、TLV）フォーマットであり、BIERヘッダは、DOHのオプションTLV内のオプションデータとして使用されることを理解されたい。オプションTLV内のオプションタイプは、オプションデータのフォーマットを識別する。オプションTLVにおけるオプションの長さは、オプションデータの長さを識別する。

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

以下、外部IPv6ヘッダ内のフィールドについて詳細に説明する。

バージョン（version、Ver）フィールドは、IPバージョン番号を識別し、値6はIPv6を表す。

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

フローラベル（flow label、FL）フィールドは、1つのトラフィックに属する複数のパケットに同じフローラベル値をラベル付けし、異なるトラフィックに属する複数のパケットに別のフローラベル値をラベル付けするために使用されうる。パケットが転送されるとき、フローラベルに基づいて異なるトラフィックが異なるリンクに分配されてもよく、同じトラフィックの複数のパケットは同じリンクを介して転送される。

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

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

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

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

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

図4に示されるBIERドメインが一例として使用される。ノードAは、IPv6ネットワークの入口ノードとして使用される。マルチキャストデータパケットを受信した後、ノードAは、BIERv6ヘッダの後にパケットをカプセル化する。言い換えると、外側のIPv6ヘッダと、BIERヘッダを含むIPv6拡張ヘッダの後に、カプセル化されたBIERv6パケットが得られる。Ipv6拡張ヘッダに含まれるBIERパケットヘッダは、宛先ノードのセットを表すBitStringを運ぶ。

ノードAは、BIERパケットヘッダおよびBIERパケットヘッダのBitString情報に基づいて、カプセル化されたBIERv6パケットをノードBに送信する。送信中、IPv6パケットヘッダ内の宛先アドレスフィールドは、ノードBのユニキャストアドレス（例えば、B：：100）を使用する。ノードBは、BIERパケットヘッダおよびBIERパケットヘッダのBitString情報に基づいて、パケットをノードCおよびノードEに送信する。送信中、IPv6ヘッダ内の宛先アドレスフィールドは、ノードCのユニキャストアドレス（例えば、C：：100）およびノードEのユニキャストアドレス（例えば、E：：100）を使用する。同様に、ノードCは、BIERパケットヘッダおよびBIERパケットヘッダのBitString情報に基づいて、パケットをノードDおよびノードFに送信する。送信中、IPv6ヘッダ内の宛先アドレスフィールドは、ノードDのユニキャストアドレス（例えば、D：：100）およびノードFのユニキャストアドレス（例えば、D：：100）を使用する。

ネットワークセキュリティがますます重要になるにつれて、無効なパケットの検出がますます重要になる。可能な場合、BIERパケットを転送する過程で、BIERパケットは、攻撃者からの攻撃に対して脆弱となり、BIERパケットが無効なBIERパケットとなる可能性がある。図1に示されるネットワークアーキテクチャが例として使用される。BIERパケットを転送する過程で、BIERパケットのパケットヘッダ情報のBitStringフィールドが変化する。一例として、攻撃者は、BFIR1とBFRとの間のリンクを攻撃者のデバイスに接続することによって、そのリンクを攻撃することができる。例えば、BFIR1によって送信されたBIERパケットを受信した後、攻撃者は、BIERパケットの転送プロセスにおけるすべての変数フィールド（BitString）を1に設定し、次いで、改ざんされたBIERパケットをBFRに送信する。別の例として、攻撃者は、BFIR1ノードを攻撃する。例えば、BFIR1ノードで構成が変更される。結果として、マルチキャストパケットをカプセル化するとき、BFIR1ノードは、すべてのBitStringフィールドを1に設定し、次いで、改ざんされたBIERパケットをBFRに送信する。別の例として、BFIR1ノードがBitStringをカプセル化するときにエラーが発生する。BIERパケットは無効パケットと呼ばれることがあり、無効なBIERパケットは、BIERドメインでマルチキャストトラフィックを大量に複製させる可能性があり、マルチキャストトラフィックは、マルチキャストトラフィックを受信する必要のないデバイスに送信される。これは、リンク帯域幅の浪費を引き起こし、さらには、リンクにおけるサービス妨害（denial of service、DoS）を引き起こす。

本出願の実施形態で提供されるパケット検出方法によれば、BIERパケット転送プロセスにおけるセキュリティまたはBIERパケットカプセル化の精度を高めるために、無効なBIERパケットを検出することができる。

図6は、本出願の一実施形態によるパケット検出方法の概略フローチャートである。図6を参照すると、本方法は、ステップ610〜630を含むことができる。以下、ステップ610〜630を詳細に個別に説明する。

ステップ610：第1のネットワーク機器はBIERパケットを取得し、BIERパケットはトラップ情報を含む。

本出願の本実施形態では、第1のネットワーク機器は、BIERドメイン内の入口ノード、例えば、図1に示されるBFIR 1またはBFIR 2であってもよく、またはBIERドメイン内の別の転送ノード、例えば、図1に示されるBFR、BFER 1、またはBFER 2であってもよい。

第1のネットワーク機器がBIERドメインの入口ノードである例が使用される。第1のネットワーク機器がBIERパケットを取得することは、第1のネットワーク機器が第1のネットワーク機器によって生成されたBIERパケットを取得することとして理解されうる。具体的には、入口ノードとして、第1のネットワーク機器は、マルチキャストデータパケットを受信し、マルチキャストデータパケットをカプセル化してBIERパケットを取得し、第1のネットワーク機器によって生成されたBIERパケットを取得することができる。

第1のネットワーク機器がBIERドメインの別の転送ノードである例が使用される。第1のネットワーク機器がBIERパケットを取得することは、第1のネットワーク機器が別のノードによって送信されたBIERパケットを受信することとして理解されうる。

本出願のこの実施形態では、BIERパケットはトラップ情報を含んでいてもよく、トラップ情報は、BIERパケットが有効なBIERパケットであるかどうかを示すために使用される。1つの可能な実施態様では、BIERパケット内のBitStringフィールドはトラップ情報を含む。例えば、トラップ情報は、1以上のビットを含む。

本出願のこの実施形態では、トラップ情報は、例えば、BIERパケットの転送プロセスで使用されない情報であってもよいことを理解されたい。例えば、BitStringで使用されないビットがトラップ情報として使用される。このようにして、トラップ情報がBIERパケットに設定される。一実施態様では、攻撃者がトラップ情報を変更すると、攻撃者がBIERパケットを悪意をもって改ざんする挙動は監視されうる。別の実施態様では、BIERパケットがネットワーク機器によって誤ってカプセル化されている場合、トラップ情報が修正されているかどうかをチェックすることは、BIERドメインのネットワーク機器がBIERパケットのパケットヘッダ情報をカプセル化するときに発生する、誤ったまたは間違った挙動をさらに検出することができる。

具体的には、例えば、トラップ情報は、1以上のビットを含む。本出願のこの実施形態では、BIERパケットのパケットヘッダ情報内のBitStringで使用されないビットは、トラップまたはハニーポットとして選択されてもよい。ビットはBFR−idに対応する。例えば、1つのBIERドメインまたは1つのBIERv6ドメインでは、100個のルータがBFERノードとして使用され、受信したBIERパケットをデカプセル化し、デカプセル化されたBIERパケットを100個のルータに接続されたマルチキャスト受信機に送信する必要がある。これらのルータは、（サブドメイン＝0、BSL＝256、SI＝0）のBFR−id範囲で計画されている。BFR−idは1〜100である。この場合、BFR−id＝101がトラップBFR−idとして構成されてもよい。あるいは、BFR−id＝101〜256がすべてトラップBFR−idとされてもよい。あるいは、BIERドメイン内で（サブドメイン＝0、BSL＝256、SI＝0）および（サブドメイン＝0、BSL＝256、SI＝1）が設定されてもよく、BFR−id＝101〜512がすべてトラップBFR−idとして設定されてもよい。これらのトラップBFR−idは、上述したトラップ情報に対応しうる。

トラップ情報が複数のビットを含む例が使用されることに留意されたい。複数のビットのうちの少なくとも2つは、互いに隣接していてもよいし、互いに隣接していなくてもよい。これは、本出願では特に限定されない。複数のビットのうちの少なくとも2つが互いに隣接しないように設定される場合、複数のトラップがBIERパケットに設定され、BIERパケットカプセル化の精度を向上させるか、またはBIERパケットが悪意をもって改ざんされた挙動を検出する確率を高める。

本出願のこの実施形態では、トラップBFR−idは、第1のネットワーク機器を保護するために、第1のネットワーク機器に構成されうる。任意選択で、トラップBFR−idは、複数またはさらにはすべてのネットワーク機器を保護するために、複数またはさらにはすべてのネットワーク機器にさらに構成されてもよい。

複数の特定の構成モードが存在し、これは本出願では特に限定されない。1つの可能な実施態様では、特定の構成モードは、管理者による手動構成であってもよい。別の可能な実装形態では、特定の構成モードは、ネットワーク管理機器による統一構成配信であってもよい。例えば、第1のネットワーク機器は、安全なチャネルを介して、ネットワーク管理機器によって統一的に配信される制御メッセージを受信する。セキュアチャネルは、セキュアシェル（Secure shell、SSH）チャネルまたはトランスポート層セキュア（transport layer secure、TLS）チャネルであってもよい。制御メッセージは、コマンドラインメッセージまたはネットワーク構成（network configuration、Netconf）プロトコルメッセージであってもよい。少なくとも1つの構成済みトラップビットは、制御メッセージ内の1つのビット転送ルータ識別子BFR−id値によって識別することができ、BFR−idはトラップBFR−idとも呼ばれる。

SSHはネットワークプロトコルであり、主にデバイス間のセキュアな接続および相互作用に使用され、主にデバイス間の暗号化された送信に使用されることを理解されたい。

ステップ620：第1のネットワーク機器は、トラップ情報が有効であるかどうかを判定する。

BIERパケットを取得した後、第1のネットワーク機器は、BIERパケット内のトラップ情報が有効であるかどうかを判定することができる。具体的には、例えば、トラップ情報は、1以上のビットを含む。ビットの値が1である場合、そのビットは有効であると理解することができる。ビットの値が0である場合、そのビットは無効であると理解することができる。

具体的には、ステップ610の例を参照すると、構成されたトラップBFR−idがBFR−id 101〜BFR−id 256である例が使用される。第1のネットワーク機器は、BitStringフィールド内のBFR−id 101〜BFR−id 256までのビットが有効であるかどうかを判定してもよい。

任意選択で、ステップ620の前に、第1のネットワーク機器は制御メッセージをさらに受信してもよく、制御メッセージは、第1のネットワーク機器によってBIERパケット内のトラップ情報を判定または検証するために使用される。

ステップ630：第1のネットワーク機器は、第1のネットワーク機器がトラップ情報が有効であると判定した場合、BIERパケットが無効なBIERパケットであると判定する。

本出願のこの実施形態では、例えば、トラップ情報は複数のビットを含む。複数のビットのうちのいずれか1つが有効である場合、BIERパケットは無効なBIERパケットであると判定されてもよい。言い換えると、複数のビットのいずれかの値が1である場合、それは、BIERパケットが悪意をもって改ざんされているか、または誤ってカプセル化されており、BIERパケットが無効なBIERパケットであることを示す。

具体的には、ステップ610の例を参照すると、構成されたトラップBFR−idがBFR−id 101〜BFR−id 256である例が使用される。第1のネットワーク機器が、BitStringフィールド内のBFR−id 101〜BFR−id 256までのいずれかのビットの値が1であると判定した場合、それは、BIERパケットが悪意をもって改ざんされているか、または誤ってカプセル化されており、BIERパケットが無効なBIERパケットであることを示す。

任意選択で、BIERパケットが無効なBIERパケットであると判定した後、第1のネットワーク機器は、無効なBIERパケットをさらに処理することができ、例えばログ情報を記録し、またはアラームを送信することができ、その結果、管理者は、転送されたBIERパケットが無効なパケットであることが分かり、それによってBIERパケット転送プロセスにおけるセキュリティまたはBIERパケットカプセル化の精度が向上する。具体的には、1つの可能な実施態様において、第1のネットワーク機器は第1のエントリを作成することができ、第1のエントリはトラップ情報を含み、第1のエントリは、BIERパケットを処理するように、例えば、トラップ情報が有効であるときにアラームを送信するかまたはログ情報を記録するように指示する。

任意選択で、いくつかの実施形態では、例えば、トラップ情報は複数のビットを含む。複数のビットがすべて無効である場合、第1のネットワーク機器は、BIERパケットが有効なBIERパケットであると判定することができる。言い換えると、複数のビットの値がそれぞれ0である場合、それは、BIERパケットが悪意をもって改ざんされていないか、または誤ってカプセル化されておらず、BIERパケットが有効なBIERパケットであることを示す。

具体的には、ステップ610の例を参照すると、構成されたトラップBFR−idがBFR−id 101〜BFR−id 256である例が使用される。第1のネットワーク機器が、BitStringフィールド内のBFR−id 101〜BFR−id 256までのすべてのビットの値がそれぞれ0であると判定した場合、それは、BIERパケットが悪意をもって改ざんされていないか、または誤ってカプセル化されておらず、BIERパケットが有効なBIERパケットであることを示す。

本出願のこの実施形態では、BIERパケットが有効なBIERパケットであると判定した場合、第1のネットワーク機器はBIERパケットを転送することができる。具体的には、ステップ610の例を参照すると、BIERパケットのパケットヘッダ情報内のBitStringは、複数の元のビットを含む。例えば、BFR−idはそれぞれ1〜100であり、これらのビットはトラフィックのすべての宛先ノードをマークする。BIERドメイン内のBFRは、例えば、それぞれ1〜100であるBFR−idが有効であるかどうかなど、BitString内の複数の元のビットに基づいてBIERパケットを転送することができる。BIERパケット転送プロセスの詳細については、図4の説明を参照されたい。詳細は本明細書では繰り返し説明されない。

前述の技術的解決策では、トラップ情報を設定することができ、トラップ情報が有効であるかどうかを判定することによって、BIERパケットが有効なBIERパケットであるかどうかが判定される。このようにして、一方では、攻撃者がBIERパケットを改ざんした場合、BIERパケット内のトラップ情報は有効である。第1のネットワーク機器は、BIERパケットが悪意をもって改ざんされた挙動を検出してもよく、またはBIERパケットが悪意をもって改ざんされた挙動を検出する確率を高めてもよく、それによってBIERパケット転送プロセスにおけるセキュリティを強化する。一方、BIERドメインのネットワーク機器がBIERパケットのパケットヘッダ情報をカプセル化するときに障害またはエラーが発生した場合、このケースは、本出願で提供される方法を使用することによってさらに検出することができ、それによってBIERパケットカプセル化の精度が向上する。

さらに、本出願のこの実施形態で提供される解決策では、無効なBIERパケットが識別され、その結果、無効なデバイスがさらにロックされてもよく、またはBIERパケットを転送および処理するネットワーク機器に障害が存在するかどうかが判定されてもよい。

任意選択で、いくつかの実施形態では、攻撃者が前述の設定されたトラップ情報を回避し、その結果、BIERパケットが悪意をもって改ざんされた挙動を検出することができないか、またはBIERパケットが悪意をもって改ざんされた挙動を検出する確率が低減されるのを防止するために、本出願では、前述の設定されたトラップ情報（例えば、トラップBFR−id）は、代替としてBIERドメイン内でフラッディングされうる。

具体的には、1つの有効なBFR−idが1つまたは複数の中間転送デバイス上で構成されうる（例えば、デバイスは実際にはBFIRとしてもBFERとしても使用されない）。有効なBFR−idは、中間転送デバイスがBIERドメインのBFIRまたはBFERであることを示す。有効なBFR−idは、IGPまたはBGPを介してBIERドメイン内でフラッディングされる。加えて、有効なBFR−idはトラップBFR−idとして構成される。一部の高度な攻撃者（例えば、攻撃者はBFIRノードを危険にさらし、BIERルーティングテーブルを確認している）の場合、攻撃者は、どのBFR−idがIGPまたはBGPによってフラッディングされたBFR−idであるかを確認し、フラッディングされたBFR−idに基づいて改ざんを実行することができる。例えば、トラップを回避するために、すべてのフラッディングされたBFR−idに対応するパケットのビット列内のビットは1に改ざんされ、フラッディングされていない他のBFR−idに対応するビットは改ざんされない。しかしながら、トラップBFR−idが1つまたは複数の中間転送デバイスに対してそれぞれ構成され、フラッディングされる場合、たとえ攻撃者がフラッディングされたBFR−idを改ざんしたとしても挙動を検出することができ、それによって、BIERパケットが悪意をもって改ざんされた挙動を検出する確率が高まる。

1つ以上の中間転送デバイスが有効なBFR−idをフラッディングするプロセスは、エッジBFRが図4のルーティングプロトコルに従ってBIERドメイン内の別のBFRにフラッディングするプロセスと同様であることを理解されたい。詳細については、図4の説明を参照されたい。詳細は本明細書では繰り返し説明されない。

図7〜図9を参照して、以下で、1つまたは複数の中間転送デバイスによってフラッディングされるトラップBFR−idの具体的な実施態様について詳細に説明する。図7〜図9の例は、本出願の実施形態を例に示される特定の値または特定のシナリオに限定するのではなく、当業者が本出願の実施形態を理解するのを助けることが単に意図されることを理解されたい。当業者は、明らかに、図7〜図9に示される例に従って様々な同等の修正または変更を行うことができ、そのような修正および変更もまた、本出願の実施形態の範囲内にある。

図7は、本出願の一実施形態によるパケット検出シナリオの概略図である。図7を参照すると、BIERドメイン（例えば、エリア（area）0）内のBFERノードはPE1〜PE30を含み、PE1〜PE30のBFR−idはそれぞれ1〜30である。BFIRノードはPE256を含み、PE256のBFR−idは256である。

BIERドメインは1つまたは複数のエリア（area）に分割されてもよく、本明細書におけるエリア0はBIERドメイン内の1つのエリアであってもよいことを理解されたい。

一例として、BFR−id 31〜BFR−id 255はすべてトラップBFR−idとして設定されてもよく、BFR−id 31〜BFR−id 255はすべて、BIERドメイン（例えば、エリア0）内の各デバイス上でトラップBFR−idとして構成される。構成は、攻撃者がそれを見ることができないように暗号化方式で保存されうることを理解されたい。言い換えると、本明細書において暗号化方式で記憶されているBFR−idはトラップBFR−idである。例えば、暗号化方式で記憶されたBFR−id 31〜BFR−id 255は、トラップBFR−idである。

図7を参照すると、P31ノードおよびP32ノードは中間転送ノードである。本出願のこの実施形態では、BFR−id 31は、P31ノードに対してさらに構成されてもよく、BFR−id 32は、P32ノードに対してさらに構成されてもよく、BFR−id 31およびBFR−id 32は、ネットワーク内でフラッディングされる。P31ノードに対して構成されたBFR−id 31およびP32ノードに対して構成されたBFR−id 32は、暗号化方式で記憶される必要はないことに留意されたい。言い換えると、本出願のこの実施形態では、本明細書の暗号化方式で格納されたBFR−idがトラップBFR−idであることに基づいて、トラップBFR−idおよび通常のBFR−idの一部またはすべては、BIERドメイン内でフラッディングされるように区別されない場合がある。

一部の高度な攻撃者（例えば、攻撃者はBFIRノードを危険にさらし、BIERルーティングテーブルを確認している）の場合、攻撃者は、どのBFR−idがIGPまたはBGPによってフラッディングされたBFR−idであるかを確認し、フラッディングされたBFR−idに基づいて改ざんを実行することができる。例えば、トラップを回避するために、すべてのフラッディングされたBFR−idに対応するパケットのビット列内のビットは1に改ざんされ、フラッディングされていない他のBFR−idに対応するビットは改ざんされない。しかしながら、トラップBFR−idが1つまたは複数の中間転送デバイスに対してそれぞれ構成され、フラッディングされる場合、たとえ攻撃者がフラッディングされたBFR−idを改ざんしたとしても挙動を検出することができ、それによって、BIERパケットが悪意をもって改ざんされた挙動を検出する確率が高まる。

図8は、本出願の一実施形態による別のパケット検出シナリオの概略図である。図8を参照すると、BIERドメインは、複数のエリア、例えば、エリア0、エリア1、およびエリア2を含みうる。エリア1内のBFERノードはPE1〜PE30を含み、PE1〜PE30のBFR−idはそれぞれ1〜30である。エリア2内のBFERノードはPE1〜PE30を含み、PE1〜PE30のBFR−IDはそれぞれ1〜30である。異なるエリアの境界はエリア境界ルータ（area border router、ABR）であり、ABRはエリア0、エリア1、およびエリア2に属する。

本明細書におけるエリア0、エリア1、およびエリア2は、BIERドメイン内の3つのエリアでありうることを理解されたい。図8に示されるBIERドメインは、複数のエリア（area）を含みうることに留意されたい。説明を容易にするために、BIERドメインが3つのエリアを含む例が説明のために使用される。

一例として、BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120はすべてトラップBFR−idとして設定されてもよく、BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120はすべて、BIERドメイン（例えば、エリア0、エリア1、およびエリア2）内の各デバイス上でトラップBFR−idとして構成される。構成は、攻撃者がそれを見ることができないように暗号化方式で保存されうることを理解されたい。言い換えると、本明細書において暗号化方式で記憶されているBFR−idはトラップBFR−idである。例えば、暗号化方式で記憶されたBFR−id 31〜BFR−id 60、およびBFR−id 91〜BFR−id 120は、トラップBFR−idである。

図8に示されるように、IGPに複数のエリアがある場合、ABRは、1〜30のBFR−idの範囲、および61〜90のBFR−idの別の範囲をエリア0にアドバタイズすることができる。本出願のこの実施形態では、BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120はすべてトラップBFR−idに設定され、ABRはBFR−id 1〜BFR−id 120の範囲をエリア0にアドバタイズすることができる。言い換えると、本出願のこの実施形態では、本明細書の暗号化方式で格納されたBFR−idがトラップBFR−idであることに基づいて、トラップBFR−idおよび通常のBFR−idの一部またはすべては、BIERドメイン内でフラッディングされるように区別されない場合がある。

一部の高度な攻撃者（例えば、攻撃者はBFIRノードを危険にさらし、BIERルーティングテーブルを確認している）の場合、攻撃者は、どのBFR−idがIGPまたはBGPによってフラッディングされたBFR−idであるかを確認し、フラッディングされたBFR−idに基づいて改ざんを実行することができる。例えば、トラップを回避するために、すべてのフラッディングされたBFR−idに対応するパケットのビット列内のビットは1に改ざんされ、フラッディングされていない他のBFR−idに対応するビットは改ざんされない。しかしながら、トラップBFR−idが1つまたは複数の中間転送デバイスに対してそれぞれ構成され、フラッディングされる場合、たとえ攻撃者がフラッディングされたBFR−idを改ざんしたとしても挙動を検出することができ、それによって、BIERパケットが悪意をもって改ざんされた挙動を検出する確率が高まる。

図9は、本出願の一実施形態による別のパケット検出シナリオの概略図である。一般に、大規模なネットワークは、複数のドメインに分割される。例えば、BIERドメインは、異なる管理ドメインに基づいて異なる自律システム（autonomous system、AS）ドメインに分割される。例えば、図9は、AS0、AS1、およびAS2を含む。AS1内のBFERノードはPE1〜PE30を含み、PE1〜PE30のBFR−idはそれぞれ1〜30である。AS2内のBFERノードはPE61〜PE90を含み、PE61〜PE90のBFR−idはそれぞれ61〜90である。

本出願のこの実施形態では、BIERドメインは複数のASドメインに分割されうることに留意されたい。説明を容易にするために、図9では、BIERドメインが3つのASドメイン（例えば、AS0、AS1、およびAS2）を含む例が説明に使用されている。

ASドメインの境界は、自律システム境界ルータ（autonomous system border router、ASBR）でありうることを理解されたい。例えば、図9では、AS0の境界ノードはASBR1であり、AS1の境界ノードはASBR2であり、AS2の境界ノードはASBR3である。ASBR1、ASBR2、およびASBR3は互いに接続されている。

本出願のこの実施形態では、複数のASドメインは、1つのBIERドメインとして構成されうることをさらに理解されたい。例えば、複数のASドメインは、静的構成により1つのBIERドメインとして構成される。IGPが採用されてもよく、BIER情報は、BIERドメイン内の異なるASでフラッディングされる。

図9を参照すると、クロスASドメインシナリオでは、各ASドメインの境界ノードが静的に構成されうる。例えば、ASBR1上のBFR−id 1〜BFR−id 30のネクストホップは、ASBR2として構成される（BFR−id 1〜BFR−id 30のネクストホップASBR2）。ASBR1上のBFR−id 61〜BFR−id 90のネクストホップは、ASBR3として構成される（BFR−id 61〜BFR−id 90のネクストホップASBR3）。PE256上のBFR−id 1〜BFR−id 30およびBFR−id 61〜BFR−id 90のネクストホップは、ASBR1として構成される（BFR−id 1〜BFR−id 30およびBFR−id 61〜BFR−id 90のネクストホップASBR1）。

一例として、BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120はすべてトラップBFR−idとして設定されてもよく、BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120はすべて、BIERドメイン（例えば、AS0、AS1、およびAS2）内の各デバイス上でトラップBFR−idとして構成される。

具体的には、図9を参照すると、トラップBFR−idを設定するために、一方では、以下の構成を実行することができる。PE256およびASBR1上のトラップBFR−idは、BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120として構成される。この構成は、攻撃者がそれを見ることができないように暗号化方式で保存することができる。構成は、攻撃者がそれを見ることができないように暗号化方式で保存されうることを理解されたい。言い換えると、本明細書において暗号化方式で記憶されているBFR−idはトラップBFR−idである。例えば、暗号化方式で記憶されたBFR−id 31〜BFR−id 255は、トラップBFR−idである。一方、これらのトラップBFR−idおよび通常のBFR−idは、区別せずに構成することができ、非暗号化方式で保存することができるため、攻撃者はそれを見ることができる。例えば、これらのトラップBFR−idおよび通常のBFR−idは、1つのBFR−idの範囲に設定することができる。例えば、ASBR1上のBFR−id 1〜BFR−id 60のネクストホップは、ASBR2として構成される（BFR−id 1〜BFR−id 60のネクストホップASBR2）。BFR−id 31〜BFR−id 60は、トラップBFR−idである。ASBR1上のBFR−id 61〜BFR−id 120のネクストホップは、ASBR3として構成される（BFR−id 61〜BFR−id 120のネクストホップASBR3）。BFR−id 91〜BFR−id 120は、トラップBFR−idである。PE256上のBFR−id 1〜BFR−id 120のネクストホップは、ASBR1として構成される（BFR−id 1〜BFR−id 120のネクストホップASBR1）。BFR−id 31〜BFR−id 60およびBFR−id 91〜BFR−id 120は、トラップBFR−idである。

2、3、および4の構成に基づいて、攻撃者は、BFR−id 31〜BFR−id 60、またはBFR−id 91〜BFR−id 120のビット1に対してDoS攻撃を行う可能性がある。しかしながら、トラップBFR−idの処理がトリガされて攻撃が明らかになる。これにより、BIERパケットが悪意をもって改ざんされた挙動を検出したり、BIERパケットが悪意をもって改ざんされた挙動を検出する確率を高めたりすることができる。

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

図10は、本出願の一実施形態による第1のネットワーク機器1000の概略構造図である。図10に示される第1のネットワーク機器1000は、前述の実施形態の方法で第1のネットワーク機器によって実行される対応するステップを実行してもよい。図10に示されるように、第1のネットワーク機器1000は、取得モジュール1010および判定モジュール1020を含む。

取得モジュール1010は、ビットインデックス明示的複製BIERパケットを取得するように構成され、BIERパケットはトラップ情報を含み、トラップ情報は、BIERパケットが有効なBIERパケットであるかどうかを示すために使用される。

判定モジュール1020は、トラップ情報が有効であるかどうかを判定するように構成される。

判定モジュール1020は、トラップ情報が有効であると判定された場合に、BIERパケットが無効なBIERパケットであると判定するようにさらに構成される。

任意選択で、BIERパケットはビット列BitStringを含み、ビット列はトラップ情報を含む。

任意選択で、トラップ情報は複数のビットを含む。

任意選択で、複数のビットのうちの少なくとも2つは互いに隣接していない。

任意選択で、判定モジュール1020は、複数のビットのいずれか1つが有効であると判定された場合に、BIERパケットが無効なBIERパケットであると判定するように特に構成される。

任意選択で、判定モジュール1020は、複数のビットのすべてが無効であると判定された場合に、BIERパケットが有効なBIERパケットであると判定するようにさらに構成される。

任意選択で、取得モジュール1010は、第2のネットワーク機器によってフラッディングされたBIER情報を受信し、第2のネットワーク機器はBIERドメインの中間転送デバイスであり、BIERドメインは第1のネットワーク機器を含み、BIER情報は第2のネットワーク機器のビット転送ルータ識別子BFR−IDを含み、BFR−IDは、第2のネットワーク機器がBIERドメインのエッジ転送デバイスであることを示すために使用される、ようにさらに構成される。

任意選択で、取得モジュール1010は、制御メッセージを受信し、制御メッセージはBIERパケット内のトラップ情報を示し、制御メッセージに基づいてBIERパケット内のトラップ情報を取得または判定または検証する、ようにさらに構成される。

任意選択で、第1のネットワーク機器1000は、第1のエントリを作成するように構成された作成モジュール1030をさらに含み、第1のエントリはトラップ情報を含み、第1のエントリはトラップ情報が有効であるときにアラームを送信するかログ情報を記録するように指示する。

判定モジュール1020は、トラップ情報が有効であると判定されたときにアラームを送信するか、またはログ情報を記録するようにさらに構成される。

図11は、本出願の一実施形態による第1のネットワーク機器2000のハードウェアの概略構成図である。図11に示される第1のネットワーク機器2000は、前述の実施形態の方法で第1のネットワーク機器によって実行される対応するステップを実行してもよい。

図11に示されるように、第1のネットワーク機器2000は、プロセッサ2001、メモリ2002、インターフェース2003、およびバス2004を含む。インターフェース2003は、無線または有線方式で実装されてもよく、具体的にはネットワークアダプタであってもよい。プロセッサ2001、メモリ2002、およびインターフェース2003は、バス2004を使用することによって接続される。

インターフェース2003は、具体的には、送信機および受信機を含むことができ、第1のネットワーク機器が上記の受信および送信を実施するように構成される。例えば、インターフェース2003は、ビットインデックス明示的複製BIERパケットを取得するように構成される。

プロセッサ2001は、前述の実施形態において第1のネットワーク機器によって行われる処理を行うように構成される。例えば、プロセッサは、トラップ情報が有効であるかどうかを判定するように構成され、トラップ情報が有効であると判定された場合にBIERパケットが無効なBIERパケットであると判定するようにさらに構成され、本明細書に記載の技術の別のプロセスで使用される。メモリ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は、エントリ、例えば、前述の転送エントリを記憶するように構成される。物理インターフェースカード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）、フラッシュメモリ、電気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 processing、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 判定モジュール
1030 作成モジュール
2000 第1のネットワーク機器
2001 プロセッサ
2002 メモリ
2003 インターフェース
2004 バス
2100 第1のネットワーク機器
2110 主制御ボード
2111 中央処理装置
2120 スイッチングボード
2130 インターフェースボード
2131 中央処理装置
2132 ネットワークプロセッサ
2133 物理インターフェースカード
2134 転送エントリメモリ
2140 インターフェースボード
2141 中央処理装置
2142 ネットワークプロセッサ
2143 物理インターフェースカード
2144 転送エントリメモリ
20021 オペレーティングシステム
20022 アプリケーションプログラム

Claims (20)

1. パケット検出方法であって、前記方法は、
   第1のネットワーク機器によって、ビットインデックス明示的複製（BIER）パケットを取得するステップであって、前記BIERパケットはトラップ情報を含み、前記トラップ情報は、前記BIERパケットが有効なBIERパケットであるかどうか指示するのに使用される、ステップと、
   前記第1のネットワーク機器によって、前記トラップ情報が有効であるかどうかを判定するステップと
   前記第1のネットワーク機器が前記トラップ情報が有効であると判定したときに、前記第1のネットワーク機器によって、前記BIERパケットが無効なBIERパケットであると判定するステップと、
   を含む、方法。
2. 前記BIERパケットはビット列（BitString）を含み、前記BitStringは前記トラップ情報を含む、請求項1に記載の方法。
3. 前記トラップ情報は複数のビットを含む、請求項2に記載の方法。
4. 前記複数のビットのうちの少なくとも2つは互いに隣接していない、請求項3に記載の方法。
5. 前記第1のネットワーク機器が前記トラップ情報が有効であると判定したときに、前記第1のネットワーク機器によって前記BIERパケットが無効なBIERパケットであると判定する前記ステップは、具体的には、
   前記第1のネットワーク機器が前記複数のビットのうちのいずれか1つが有効であると判定した場合に、前記第1のネットワーク機器によって前記BIERパケットが前記無効なBIERパケットであると判定するステップを含む、
   請求項3または4に記載の方法。
6. 前記方法が、
   前記第1のネットワーク機器が前記複数のビットのすべてが無効であると判定したときに、前記第1のネットワーク機器によって前記BIERパケットが前記有効なBIERパケットであると判定するステップ
   をさらに含む、請求項3または4に記載の方法。
7. 前記方法が、
   前記第1のネットワーク機器によって、第2のネットワーク機器によってフラッディングされたBIER情報を受信するステップであって、前記第2のネットワーク機器はBIERドメインの中間転送デバイスであり、前記BIERドメインは前記第1のネットワーク機器を含み、前記BIER情報は前記第2のネットワーク機器のビット転送ルータ識別子（BFR−ID）を含み、前記BFR−IDは、前記第2のネットワーク機器が前記BIERドメインのエッジ転送デバイスであることを示すために使用される、ステップ
   をさらに含む、請求項1から6のいずれか一項に記載の方法。
8. 前記第1のネットワーク機器によって、前記トラップ情報が有効であるかどうかを判定する前記ステップの前に、前記方法が、
   前記第1のネットワーク機器によって、制御メッセージを受信するステップであって、前記制御メッセージは、前記BIERパケット内の前記トラップ情報を示す、ステップと、
   前記第1のネットワーク機器によって、前記制御メッセージに基づいて前記BIERパケット内の前記トラップ情報を取得するステップと、
   をさらに含む、請求項1から7のいずれか一項に記載の方法。
9. 前記方法が、
   前記第1のネットワーク機器によって、第1のエントリを作成するステップであって、前記第1のエントリは前記トラップ情報を含み、前記第1のエントリは、前記トラップ情報が有効であるときにアラームを送信するかまたはログ情報を記録することを示す、ステップと、
   前記第1のネットワーク機器が前記トラップ情報が有効であると判定したときに、前記アラームを送信するかまたは前記ログ情報を記録するステップと、
   をさらに含む、請求項1から8のいずれか一項に記載の方法。
10. ビットインデックス明示的複製（BIER）パケットを取得するように構成された取得モジュールであって、前記BIERパケットはトラップ情報を含み、前記トラップ情報は前記BIERパケットが有効なBIERパケットであるかどうか指示するために使用される、取得モジュールと、
    前記トラップ情報が有効であるかどうかを判定するように構成された判定モジュールと、
    を含み、
    前記判定モジュールは、前記トラップ情報が有効であると判定された場合に、前記BIERパケットが無効なBIERパケットであると判定するようにさらに構成される、
    第1のネットワーク機器。
11. 前記BIERパケットはビット列（BitString）を含み、前記ビット列は前記トラップ情報を含む、請求項10に記載の第1のネットワーク機器。
12. 前記トラップ情報は複数のビットを含む、請求項11に記載の第1のネットワーク機器。
13. 前記複数のビットのうちの少なくとも2つは互いに隣接していない、請求項12に記載の第1のネットワーク機器。
14. 前記判定モジュールは、
    前記複数のビットのいずれか1つが有効であると判定された場合に、前記BIERパケットが前記無効なBIERパケットであると判定する
    ように特に構成される、請求項12または13に記載の第1のネットワーク機器。
15. 前記判定モジュールは、
    前記複数のビットのすべてが無効であると判定された場合に、前記BIERパケットが前記有効なBIERパケットであると判定する
    ようにさらに構成される、請求項12または13に記載の第1のネットワーク機器。
16. 前記取得モジュールは、
    第2のネットワーク機器によってフラッディングされたBIER情報を受信し、前記第2のネットワーク機器はBIERドメインの中間転送デバイスであり、前記BIERドメインは前記第1のネットワーク機器を含み、前記BIER情報は前記第2のネットワーク機器のビット転送ルータ識別子BFR−IDを含み、前記BFR−IDは、前記第2のネットワーク機器が前記BIERドメインのエッジ転送デバイスであることを示すために使用される、
    ようにさらに構成される、請求項10から15のいずれか一項に記載の第1のネットワーク機器。
17. 前記取得モジュールは、
    制御メッセージを受信し、前記制御メッセージは前記BIERパケット内の前記トラップ情報を示し、
    前記制御メッセージに基づいて前記BIERパケット内の前記トラップ情報を取得する、
    ようにさらに構成される、請求項10から15のいずれか一項に記載の第1のネットワーク機器。
18. 第1のエントリを作成するように構成された作成モジュールであって、前記第1のエントリは前記トラップ情報を含み、前記第1のエントリは、前記トラップ情報が有効であるときにアラームを送信するかまたはログ情報を記録することを示す、作成モジュール
    をさらに含み、
    前記判定モジュールは、前記トラップ情報が有効であると判定されたときに、前記アラームを送信するかまたは前記ログ情報を記録するようにさらに構成される、
    請求項10から17のいずれか一項に記載の第1のネットワーク機器。
19. プロセッサおよびメモリを備え、前記メモリはプログラムを記憶するように構成され、前記プロセッサは、前記メモリから前記プログラムを呼び出し、前記プログラムを実行して、請求項1から9のいずれか一項に記載の前記方法を実行するように構成される、第1のネットワーク機器。
20. コンピュータプログラムを備え、前記コンピュータプログラムがコンピュータ上で実行されると、前記コンピュータが請求項1から9のいずれか一項に記載の前記方法を実行することが可能になる、コンピュータ可読記憶媒体。

Images