以下で、添付図面を参照して本出願の技術的解決策を記載する。
すべての態様、実施形態、または特徴は、複数のデバイス、構成要素、モジュールなどを含むシステムを説明することにより、本出願において提示される。各システムは、別のデバイス、構成要素、モジュールなどを含んでいてもよく、かつ/または添付の図面を参照して説明されるすべてのデバイス、構成要素、モジュールなどを含まなくてもよいことを諒解されたい。加えて、これらの解決策の組み合わせが使用されてもよい。
加えて、本出願の実施形態では、「例えば」、「など」などの用語は、例、例示、または説明を与えることを表すために使用される。本出願において「例」として記載される任意の実施形態または設計方式は、別の実施形態または設計方式よりも好ましいか、または多くの利点を有するものとして説明されるべきではない。正確には、「例えば」は、具体的に概念を提示するために使用される。
本出願の実施形態では、「対応する(corresponding,related)」および「対応する(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)ネットワーク上の複数の受信機に同時に効率よくデータが送信されるデータ伝送モードである。マルチキャストソースは、ネットワーク内のリンクを介してマルチキャストグループ内の各マルチキャストグループメンバにマルチキャストストリームを送信し、マルチキャストグループ内の各マルチキャストグループメンバは、マルチキャストストリームを受信することができる。マルチキャスト伝送モードは、マルチキャストソースとマルチキャストグループメンバとの間のポイントツーマルチポイントデータ接続を実施する。マルチキャストストリームは、各ネットワークリンク上で1回だけ送信される必要があり、マルチキャストストリームは、リンクの分岐が存在する場合にのみ複製される。したがって、マルチキャスト伝送モードは、データ伝送効率を向上させ、バックボーンネットワーク上の輻輳を引き起こす可能性を低減する。
インターネットプロトコル(internet protocol、IP)マルチキャスト技術は、IPネットワークにおいて効率的なポイントツーマルチポイントデータ送信を実施し、それによってネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減する。したがって、インターネットプロトコルマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、双方向プロトコルテレビ(internet protocol television、IPTV)、ゲーム、およびシミュレーションなどの複数の態様で広く使用されている。マルチキャスト技術では、マルチキャストプロトコルが使用されて制御プレーン上でマルチキャストツリーを構築し、次いでマルチキャストツリーが使用されてネットワークプレーン上で論理ツリー状転送を実行して、マルチキャストポイントツーマルチポイントデータ転送を実施する。配信ツリーを構築するコアを有する中間デバイスは、複雑なマルチキャスト転送情報状態を維持する必要がある。ネットワーク規模が大きくなり、マルチキャストデータトラフィックが増加するにつれて、このマルチキャスト技術は、増加するコストならびに運用および保守の課題に直面する。
したがって、マルチキャストデータ転送経路を構築するための新しい技術が業界で提案されており、ビットインデックス明示的複製(bit index explicit replication、BIER)技術と呼ばれている。この技術では、マルチキャスト配信ツリーを構築しないマルチキャスト技術アーキテクチャが提案されている。図1に示されるように、BIER技術をサポートするルータはビット転送ルータ(Bit-forwarding router、BFR)と呼ばれる。ユーザマルチキャストデータパケットに対してBIERカプセル化を実行するBFRは、ビット転送入口ルータ(bit forwarding ingress router、BFIR)と呼ばれる。BIERパケットからユーザマルチキャストデータパケットを取得するためにデカプセル化を実行するBFRは、ビット転送出口ルータ(bit forwarding egress router、BFER)と呼ばれる。1つまたは複数のBFIR、1つまたは複数のBFR、および1つまたは複数のBFERによって形成されるマルチキャスト転送ドメインは、BIERドメイン(BIER domain)と呼ばれる。BFIRは、BIERドメインの入口に位置し、BIERパケットを転送する入口ノードとしてBIERパケットをカプセル化する役割を担う。BFRは、BIERドメインの中央に位置し、BIERパケットを転送する中間ノードとしてBIERパケットを転送する役割を担う。BFERは、BIERドメインの出口に位置し、BIERパケットを転送する出口ノードとしてBIERパケットをデカプセル化する役割を担う。
BIERドメイン内のBFIRおよびBFERはまた、BIERドメイン内のエッジBFRと呼ばれ得ることを理解されたい。
任意選択で、BIERパケット転送をサポートしていないデバイスもまた、BIERドメインの中央に位置してもよい。BIERパケット転送をサポートしていないデバイスは、デバイスがBIERパケット内のBIERヘッダを識別または解析することができず、BIERパケットを共通パケットとして転送するだけであると理解され得る。
理解を容易にするために、以下ではまず、図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つのビット列(bit string)を形成する。
本出願のこの実施形態では、ユーザマルチキャストデータパケットがBIERドメインで送信される場合、特定のBIERヘッダがさらにカプセル化される必要がある。BIERヘッダにおいて、ビット列は、ユーザマルチキャストデータパケットのすべての宛先デバイスをマークするために使用される。BIERドメインのBFRは、ユーザマルチキャストデータパケットがすべての宛先アドレスに送信され得ることを保証するために、ビットインデックス転送テーブル(bit index forwarding table、BIFT)およびBIERヘッダで運ばれるビット列に基づいて転送を実行することができる。
BIERヘッダの後のユーザマルチキャストデータパケットは、インターネットプロトコルバージョン6(internet protocol version 6、IPv6)パケット、インターネットプロトコルバージョン4(internet protocol version4、IPv4)パケット、またはBIER動作、管理、および保守(operation,administration and maintenance、OAM)パケットであってもよいことを理解されたい。これは、本出願では特に限定されない。
複数のBIERカプセル化タイプが存在し得る。これは、本出願では特に限定されない。一例として、BIERパケットは、マルチプロトコルラベルスイッチング(multi-protocol label switching、MPLS)を使用することによってカプセル化されてもよく、そのようなカプセル化は、BIER-MPLSカプセル化と呼ばれてもよい。別の例として、BIERパケットは、インターネットプロトコルバージョン6(internet protocol version 6、IPv6)に基づいてカプセル化されてもよく、そのようなカプセル化は、BIERv6カプセル化と呼ばれてもよい。
以下、図2~図4を参照して、BIER-MPLSカプセル化関連技術について詳細に説明する。
BIERヘッダのフォーマットは、BIERヘッダがビット列(bit string)フィールドを含む限り、本出願のこの実施形態では特に限定されない。
理解を容易にするために、以下ではまず、図2および図3を参照してBIERヘッダのフォーマットを詳細に説明する。
図2は、可能なBIERヘッダフォーマットの概略ブロック図である。図2に示すように、BIERヘッダは、ビットインデックス転送テーブル識別子(bit index forwarding table identifier、BIFT ID)、ビット列長(bit string length、BSL)、および他のフィールドを含むことができるが、これらに限定されない。他のフィールドは、BIERヘッダの後のユーザマルチキャストデータパケットのトラフィッククラス(traffic class、TC)フィールド、スタック(stack、S)フィールド、生存時間(time to live、TTL)フィールド、エントロピ(entropy)フィールド、バージョン(version、Ver)フィールド、ニブル(nibble)フィールド、プロトコル(protocol、proto)フィールド、運用、管理、および保守(operation,administration and maintenance、OAM)フィールド、予約(reserve、Rsv)フィールド、差別化サービスコードポイント(differentiated services code points、DSCP)フィールドなどを含むことができるが、これらに限定されない。
以下、BIERヘッダ内のいくつかのフィールドについて詳細に説明する。
(1)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に分割および構成され得る。各サブドメインSDは、サブドメイン識別子(sub-domain identifier、SD-ID)によって表され得る。例えば、SD-IDの値は0~255までの範囲であり、長さは8ビットである。
2.ビット列長(bit string length、BSL)
BSLは、BIERヘッダに含まれるビット列の長さである。複数の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、BIERパケット内の使用されたBSL、およびパケットが属するBSLのSIを含む組み合わせを決定することができる。
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)ビット列(bit string)フィールド
ビット列内の各ビットは、エッジBFRを識別するために使用される。例えば、ビット列の最下位ビット(右端のビット)は、BFR-IDが1であるBFERを識別するために使用される。ビット列内の右から左への2番目のビットは、BFR-IDが2であるBFERを識別するために使用される。転送プレーンが転送を実行する転送エントリにおいて、BFERにパケットが送信されるべきであることは、パケット内のビット列に基づいて決定される。BIERドメイン内のBFRは、BIERパケットヘッダを含むBIERパケットを受信すると、BIERヘッダで運ばれるビット列と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)プロトコル(protocol、proto)フィールド
プロトコルフィールドは、BIERパケットヘッダの後のペイロード(payload)を識別または区別するために使用される。一例として、protoフィールドは、BIERパケットヘッダの後のペイロードが、インターネットプロトコルバージョン6(internet protocol version 6、IPv6)マルチキャストパケットであるか、インターネットプロトコルバージョン4(internet protocol version4、IPv4)マルチキャストパケットであるか、またはBIER OAMパケットであるかを区別するために使用され得る。
可能な実装では、ペイロードのタイプは、BIERヘッダ内のprotoフィールドの値を使用することによって区別され得る。例えば、protoフィールドの値が5(proto=5)である場合、それは、BIER OAMパケットがBIERパケットヘッダに続くことを示すか、または、protoフィールドの値が5でない場合(proto!=5)、IPv4/IPv6パケットがBIERパケットヘッダに続くことを示す。
図3は、別の可能なBIERヘッダフォーマットの概略ブロック図である。図2に示されるBIERヘッダフォーマットと比較して、図3に示されるBIERヘッダフォーマットは、BIFT-IDフィールドを含まないが、SD/BSL/SIの3つのフィールドを含む。言い換えると、図3に示されるBIERヘッダフォーマットは、SD/BSL/SIの3つのフィールドを直接含み、SD/BSL/SIフィールドの値は、BIFT IDフィールドからマッピングされる必要はない。
以下は図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のBFERに対応する。
本出願のこの実施形態では、各BIERドメイン内のエッジBFRに一意のBFR-IDが割り当てられ得る。例えば、図4では、デバイスA、デバイスD、デバイスE、およびデバイスFに対して構成されたBFR-IDは、それぞれ4、1、3、および2である。BFR-IDは、デバイスBおよびデバイスCなどの中間転送BFRには割り当てられない。
本出願の実施形態では、「ID」および「id」は、交換可能に使用される場合があることに留意されたい。違いが強調されていない場合、用語によって表現された意味は一致していることに留意されたい。本出願におけるBFR-IDは、図4のidを指し得る。
データトラフィックのBIERヘッダにカプセル化されたビット列は、トラフィックのすべての宛先デバイスをマークする。例えば、BFR-IDが1であるデバイスDに対応するビット列は0001であり、BFR-IDが2であるデバイスFに対応するビット列は0010であり、BFR-IDが3であるデバイスEに対応するビット列は0100であり、BFR-IDが4であるデバイスAに対応するビット列は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パケット内のビット列の右から左への第1のビット、第2のビット、および第3のビットのいずれか1つが1である場合、BIERパケットがデバイスAの隣接者(デバイスB)に送信されることを表すために使用される。Nbr=Bは、デバイスAの隣接者がデバイスBであることを表す。
転送エントリ2は、BIERパケット内のビット列の右から左へ4番目のビットが1である場合、BIERパケットがデバイスAに送信されることを表すために使用される。デバイス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は、ビット列をBIERヘッダ内に0111にカプセル化し、カプセル化されたBIERパケットを転送エントリ1に基づいて隣接デバイスBに転送する。BIERパケットを受信した後、デバイスBは、0111であるビット列およびBIFTエントリに基づいて、BIERパケットがデバイスCおよびデバイスEにそれぞれ送信される必要があると決定する。BIERパケットをデバイスCに送信するとき、デバイスBは、BIERヘッダ内のビット列(0111)およびBIFTエントリ内のNbr=Cに対応するFBMフィールドに対してAND演算を実行することができる。本出願のこの実施形態では、AND演算の結果は0011である。したがって、デバイスBは、BIERヘッダ内のビット列を0011に修正し、ビット列(0011)をデバイスCに送信することができる。同様に、BIERパケットをデバイスEに送信するとき、デバイスBは、BIERヘッダ内のビット列を0100に修正することができる。BIERパケットを受信した後、デバイスEは、0100であるビット列に基づいて、BIERパケットが隣接デバイスEへ送信されるべきであると決定する。デバイスEは、転送テーブル内の識別子*に基づいて隣接デバイスEがデバイスE自身であると決定するので、BIERドメインの出口でBFERとして使用されるデバイスEは、BIERパケットからユーザマルチキャストデータパケットをデカプセル化し、内側のユーザマルチキャストデータパケットの情報に基づいてユーザマルチキャストデータパケットを転送することができる。
以下、図5を参照して、BIERv6カプセル化関連技術について詳細に説明する。
図5は、可能なBIERv6カプセル化の概略ブロック図である。図5を参照すると、カプセル化されたIPv6パケットのフォーマットは、外側のIPv6ヘッダ+IPv6拡張ヘッダ(BIERヘッダを含む)+ユーザマルチキャストデータパケットであり得る。このカプセル化の下で、外側のIPv6ヘッダおよびBIERヘッダを含むIPv6拡張ヘッダは、IPv6パケットの外側のパケットヘッダを共に形成し、外側のパケットヘッダは、本出願の実施形態ではBIERv6ヘッダとも呼ばれ得る。
BIERヘッダを含むIPv6拡張ヘッダは、本出願のこの実施形態では特に限定されない。例えば、IPv6拡張ヘッダは、宛先オプションヘッダ(destination option header、DOH)であってもよい。別の例では、IPv6拡張ヘッダは代替としてルーティングヘッダ(routing header、HR)であってもよい。
以下、外側のIPv6ヘッダ内のいくつかのフィールドについて詳細に説明する。
ホップ制限(hop limit、HL)フィールドは、パケットが効果的に転送され得る回数を表す。ホップ値は、パケットがルータを通過するたびに1ずつ減少する。このフィールドの値が1以下である場合、ルータはパケットを下流のデバイスに転送しない。
送信元アドレス(source address、SA)フィールドは、パケットを送信する送信元ノードのアドレスを識別するために使用される。
宛先アドレス(destination address、DA)フィールドは、パケットを受信する宛先ノードのアドレスを識別するために使用される。
DAフィールドは、継続的にネクストホップのIPアドレスに更新される。図4に示されるBIERドメインが一例として使用される。デバイスAは、IPv6ネットワークの入口ノード(ingress device)として使用される。ユーザマルチキャストデータパケットを受信した後、デバイスAは、BIERv6ヘッダの後にパケットをカプセル化する。言い換えると、外側のIPv6ヘッダと、BIERヘッダを含むIPv6拡張ヘッダの後に、カプセル化されたBIERv6パケットが得られる。
IPv6拡張ヘッダに含まれるBIERパケットヘッダは、宛先デバイスのセットを表すビット列を運ぶ。デバイスAは、デバイスAのBIERパケットヘッダおよびビット列情報に基づいて、カプセル化されたBIERv6パケットをデバイスBに送信する。送信中、IPv6パケットヘッダ内の宛先アドレスフィールドは、デバイスBのユニキャストアドレス(例えば、B::100)を使用することができる。デバイスBは、BIERパケットヘッダおよびデバイスBのビット列情報に基づいて、デバイスCおよびデバイスEにパケットを送信する。送信中、IPv6ヘッダ内の宛先アドレスフィールドは、デバイスCのユニキャストアドレス(例えば、C::100)およびデバイスEのユニキャストアドレス(例えば、E::100)を使用することができる。同様に、デバイスCは、BIERパケットヘッダおよびデバイスCのビット列情報に基づいて、デバイスDおよびデバイスFにパケットを送信する。送信中、IPv6ヘッダ内の宛先アドレスフィールドは、デバイスDのユニキャストアドレス(例えば、D::100)およびノードFのユニキャストアドレス(例えば、F::100)を使用することができる。
BIERドメインの中間デバイス(ルータまたはルータ機能を有するスイッチ)がIPv6パケットを転送するプロセスでは、IPv6パケットの外側のIPv6ヘッダ内のホップ制限フィールドの値が1以下である場合、IPv6パケットは下流デバイスに転送されず、中間デバイスは、外側のIPv6ヘッダの送信元アドレスにインターネット制御メッセージプロトコルバージョン6(internet control message protocol version 6、ICMPv6)エラーパケットを送信する。
IPv6パケット転送に対するセキュリティの脅威は、攻撃者がIPv6パケットを偽装し、IPv6パケットの送信元アドレスを攻撃されたデバイス(例えば、コンピュータホストまたはルータ)のIPv6アドレスに設定し、IPv6ヘッダ内のホップ制限フィールドを比較的小さい値に設定する可能性があることである。このようにして、IPv6パケットが中間デバイスの各々に転送されると、これらの中間デバイスは、ホップ制限の値が1以下であるため、ICMPv6エラーパケットを攻撃されたデバイス(ホストまたはルータ)に送信する。
BIERv6パケットは、BIER技術とIPv6との組み合わせであり、1対多送信プロセスに基づく。また、BIERv6パケットは、ユニキャストパケットであってもよい。したがって、BIERv6パケットが偽装されている場合、複数の中間デバイスはICMPv6エラーパケットを攻撃されたデバイスに送信することができる。これにより、攻撃効果が大きくなる。BIERv6転送をサポートしていない共通のIPv6デバイスがネットワークに存在し、デバイスが制御プレーンおよび転送プレーン上のBIERv6パケットヘッダを識別または解析することができない場合、受信したパケットが共通のIPv6パケットであるかBIERv6パケットであるかは決定されることができない。デバイスは、パケットのホップ制限の値が1以下である場合、ICMPv6エラーパケットを送信する。BIERv6転送をサポートしない複数の一般的なIPv6デバイスは、攻撃効果をさらに増幅する。
図6に示すシナリオを例にとる。このシナリオにおける中間デバイスは、BIERv6転送をサポートしないデバイスを含み得る。言い換えれば、中間デバイスは、BIERv6転送をサポートするデバイス(例えば、BFR 2、BFR 3、およびBFR4)と、BIERv6転送をサポートしないデバイス(例えば、R5)とを含む。
BIERv6転送(BFR)をサポートするデバイスは、デバイスがBIERv6パケットの外側のIPv6ヘッダ内のBIERヘッダを識別および解析できることを意味することを理解されたい。BIERv6転送をサポートするデバイス(BFR)は、BIERv6パケットの転送に実際に関与する。受信されたパケットの宛先アドレスは、デバイスがBIERv6パケットの転送に関与するときのデバイス自体である。
BIERv6転送をサポートしないデバイスは、BIERv6転送をサポートしない一般的なIPv6デバイス(非BFR)であってもよく、デバイスは、BIERv6パケットの外側のIPv6ヘッダ内のBIERヘッダを識別および解析することができないことをさらに理解されたい。
BIERv6転送をサポートしないデバイス(非BFR)は、BIERv6パケットの転送に実際には関与せず、デバイスによって受信されたパケットの宛先アドレスはデバイス自体ではないことに留意されたい。また、BIERv6転送をサポートするデバイスが非BFRデバイスとして使用されてもよいこともある。例えば、BIERルートは静的に構成され、転送のためのネクストホップはデバイスを通過またはトラバースする。本出願で説明される非BFRまたはBIERv6転送をサポートしないデバイスは、そのようなデバイスも含む。デバイスはBIERヘッダを識別することができるが、デバイスによって受信されたパケットの宛先アドレスはデバイス自体ではない。したがって、BIERヘッダは明示的複製には使用されない。非BFRまたはBIERv6転送をサポートしていないデバイスはまた、ホップ制限が0以下であるパケットを受信したときにICMPv6エラーパケットを送信し得る。
BFR 1は、BIERv6パケットを受信する。このBIERv6パケットは、攻撃者(例えば、パケットの外側のIPv6ヘッダ内の送信元アドレスは、攻撃されたデバイスのアドレスに設定される)によって構築されたBIERv6パケットであってもよいし、誤った構成または誤った実装のために通常のルータ、例えばBFIRによって送信されてもよい(パケットの外側のIPv6ヘッダ内の送信元アドレスはBFIRのアドレスである)。これは、本出願では特に限定されない。
BFR 1によって受信されたBIERv6パケットの宛先アドレスがユニキャストアドレスであり、外側のIPv6ヘッダ内のホップ制限が3である場合、BIERv6パケット内のBitStringは、BFER 6およびBFER 7に対応する有効ビットを含む。一例では、パケットがパスBFR 1->BFR 2->BFR4に沿ってBFR4に到達するとき、パケットの外側のIPv6ヘッダ内のホップ制限は1である。BFR4が受信するBIERv6パケットは、ユニキャストパケットである。ユニキャストパケットを転送するための要件に従って、BFR4はパケットを転送しないが、BFR4はICMPv6エラーパケットを送信し、ICMPv6エラーパケットはパケットの送信元アドレス(攻撃されたデバイスまたはBFIR)に送信される。別の例では、パケットがパスBFR 1->BFR 3に沿ってBFR 3に到達するとき、パケットの外側のIPv6ヘッダ内のホップ制限は2であり、BFR 3はパスBFR 3->R5->BFER 7に沿ってパケットを送信する。パケットの宛先アドレスはBFER 7であるが、パケットはR5を通過する。R5は、受信したパケットが共通のIPv6パケットであるかBIERv6パケットであるかを決定できず、ユニキャストパケットとみなす。ユニキャストパケットを転送するための要件に従って、R5はパケットを転送しないが、ICMPv6エラーパケットを送信し、ICMPv6エラーパケットはパケットの送信元アドレス(攻撃されたデバイスまたはBFIR)に送信される。
したがって、BIERv6シナリオでは、BIERv6パケットを転送するネットワークデバイスが大量のICMPv6エラーパケットを生成するのを防止し、パケット転送セキュリティを向上させる方法が、現在解決されるべき緊急の問題になっている。
関連する技術的解決策では、BIERv6シナリオでは、大量のICMPv6エラーパケットが生成されるのを防ぐために、各BFRデバイスは、ICMPv6エラーパケットに対してレート制限を実施し、レート制限を超えるパケットを廃棄して、複数の中間デバイスが同じ入口ノード(入口デバイス)に大量のICMPv6エラーパケットを送信するのを防ぐ必要がある。
前述の関連する技術的解決策では、攻撃者がホップ制限の特定の値を有するBIERv6パケットを構築する場合、中間デバイスは、ホップ制限値が1または0であるパケットを受信し、ICMPv6エラーパケットを攻撃されたデバイスに送信することができる。攻撃されたデバイスは、ICMPv6レート制限を実装していないデバイスであるため、攻撃される可能性がある。攻撃されたのがICMPv6レート制限を実施するデバイスであっても、このICMPv6エラーパケットは依然としてネットワーク帯域幅および攻撃されたデバイスの帯域幅を浪費する。
これを考慮して、本出願の一実施形態は、BIERv6パケット転送方法を提供する。2以上の閾値は、BIERv6転送をサポートするデバイス上で構成され得る。BIERv6パケットに対してBIER転送を実行する前に、BIERv6転送をサポートするデバイスは、パケット内のホップ制限が閾値以下であるかどうかを調べた後にBIERv6パケットを転送することを回避する。BIERv6転送をサポートしていないデバイスにBIERv6パケットが送信されるとき、これは、BIERv6パケットのホップ制限の値が1または0であるため、BIERv6転送をサポートしていないデバイス上でICMPv6エラーパケットを生成する確率を低減することができる。これは、BIERv6パケット転送セキュリティを改善し、大量のICMPv6エラーパケットによって引き起こされるネットワーク帯域幅の浪費および攻撃されたデバイスの帯域幅の浪費を防止することができる。
本出願では、BIERv6パケットの転送を回避することは、BIERv6パケットがネクストホップデバイスに送信されるのを防ぐと考えられてもよく、またはBIERv6パケットの転送をスキップすると考えられてもよいことを理解されたい。言い換えれば、BIERv6パケットの転送を回避することは、BIERv6パケットをネクストホップデバイスに送信しないこととして理解され得る。
ホップ制限閾値は、ネットワーク内の1つもしくは複数、またはすべてのBIERv6ルータ上でそれぞれ構成されてもよいことに留意されたい。一例として、ネットワーク管理者は、1つもしくは複数、またはすべてのBIERv6ルータのホップ制限閾値を別々に構成することができる。これらの閾値は同じであっても異なっていてもよい。これについては本出願のこの実施形態では特に限定されない。
以下で、図8を参照して、本出願の一実施形態によるBIERv6パケット転送方法を詳細に説明する。
図8は、本出願の一実施形態によるBIERv6パケット転送方法の概略フローチャートである。図8に示されるように、本方法は、ステップ810~830を含み得る。以下、ステップ810~830を詳細に個別に説明する。
ステップ810:第1のネットワークデバイスがBIERv6パケットを受信する。
本出願のこの実施形態における第1のネットワークデバイスは、図1に示されたBFRまたはBFERであり得る。一例として、第1のネットワークデバイスは、BIERドメイン内のBFRまたはBFERであってもよい。BIERドメインおよびBFRまたはBFERの具体的な説明については、図1の説明を参照されたい。詳細は本明細書では繰り返し説明されない。
ステップ820:第1のネットワークデバイスは、BIERv6パケット内のホップ制限フィールドの値が第1のネットワークデバイスの事前設定閾値以下であるかどうかを決定する。
第1のネットワークデバイス上で構成された事前設定閾値は2以上の値である。事前設定閾値は、第1のネットワークデバイスに接続された1つまたは複数の連続する第2のネットワークデバイスの数に基づいて決定されることができ、第2のネットワークデバイスは、BIER転送をサポートしないデバイスである。事前設定閾値は、ホップ制限閾値とも呼ばれ得ることを理解されたい。
一例として、ホップ制限閾値は、BIER転送をサポートする第1のネットワークデバイス上で構成されてもよく、閾値の値は、1にBIER転送をサポートしない連続デバイスの数を加えたもの以上である。以下で、第1のネットワークデバイス上で構成された事前設定閾値を決定するための具体的な実装を詳細に説明する。
図6に示すシナリオを例にとる。R5は、BIER転送をサポートしないデバイスである。BFR 3およびBFER 7はいずれも、BIER転送をサポートしていないデバイス(R5)に接続されており、BFR 3およびBFER 7に接続され、BIER転送をサポートしていないデバイスの数は1である。したがって、BFR 3およびBFER 7の事前設定閾値は、2以上の値に設定されてもよい。
図7に示すシナリオを例にとる。R5、R 6、およびR 7はすべて、BIER転送をサポートしていないデバイスである。BFR 3およびBFER 7はいずれも、BIER転送をサポートしていないデバイス(R5、R 6、およびR 7)に接続されており、BFR 3およびBFER 7に接続され、BIER転送をサポートしていないデバイスの数は3である。したがって、BFR 3およびBFER 7の事前設定閾値は、4以上の値に設定されてもよい。
ステップ830:BIERv6パケット内のホップ制限フィールドの値が事前設定閾値以下である場合、第1のネットワークデバイスはBIERv6パケットの転送を回避する。
第1のネットワークデバイスがBIERv6パケットの転送を回避することは、BIERv6パケットがネクストホップデバイスに送信されるのを第1のネットワークデバイスが防ぐと考えられてもよく、または第1のネットワークデバイスがBIERv6パケットの転送をスキップすると考えられてもよいことを理解されたい。言い換えれば、第1のネットワークデバイスは、BIERv6パケットを第1のネットワークデバイスのネクストホップデバイスに送信しない。
前述の技術的解決策では、2以上の閾値が、BIERv6転送をサポートするデバイス(第1のネットワークデバイス)上で構成され得る。BIERv6パケットに対してBIERv6転送を実行する前に、BIERv6転送をサポートするデバイスは、パケット内のホップ制限が閾値以下であるかどうかを調べた後にBIERv6パケットを転送することを回避する。BIERv6転送をサポートしていないデバイスにBIERv6パケットが送信されるとき、これは、BIERv6パケットのホップ制限の値が1または0であるため、BIERv6転送をサポートしていないデバイス上でICMPv6エラーパケットを生成する確率を低減することができる。これは、BIERv6パケット転送セキュリティを改善し、大量のICMPv6エラーパケットによって引き起こされるネットワーク帯域幅の浪費および攻撃されたデバイスの帯域幅の浪費を防止することができる。
任意選択で、いくつかの実施形態では、第1のネットワークデバイスがBIERv6パケットの転送を回避した後、第1のネットワークデバイスはBIERv6パケットをさらに廃棄することができる。
任意選択で、いくつかの実施形態では、第1のネットワークデバイスは、BIERv6パケット内のホップ制限フィールドの値が第1のネットワークデバイスの事前設定閾値以上であると決定する。以下では、この場合に第1のネットワークデバイスがBIERv6パケットを処理するプロセスを詳細に説明する。
一例では、BIERv6パケット内のホップ制限フィールドの値は、事前設定閾値に等しい。可能な実装では、第1のネットワークデバイスがBFRまたはBFERであるかどうかにかかわらず、第1のネットワークデバイスはBIERv6パケットの転送を回避する。別の可能な実装では、第1のネットワークデバイスが、第1のネットワークデバイスがBFRであると決定した場合、第1のネットワークデバイスは、BIERv6パケットの転送を回避する。あるいは、第1のネットワークデバイスが第1のネットワークデバイスはBFERであると決定した場合、第1のネットワークデバイスはBIERv6パケットをデカプセル化し、デカプセル化された内側のパケットを転送する。
別の例では、BIERv6パケット内のホップ制限フィールドの値は、事前設定閾値よりも大きい。例えば、第1のネットワークデバイスはBFRであり、第1のネットワークデバイスは、第1のネットワークデバイスのネクストホップデバイスにBIERv6パケットを送信する。別の例では、第1のネットワークデバイスはBFERであり、第1のネットワークデバイスはBIERv6パケットをデカプセル化し、デカプセル化された内側のパケットを転送する。
以下では、本出願のこの実施形態におけるデバイスが、図9を参照してBIERv6パケットを転送する別の具体的な実装プロセスを詳細に説明するために、例として図6に示されたシナリオを使用する。
図9の例は、本出願の実施形態を例に示される特定の値または特定のシナリオに限定するのではなく、当業者が本出願の実施形態を理解するのを助けることが単に意図されることに留意されたい。当業者は、図9に示される例に従って様々な同等の修正または変更を確実に行うことができ、そのような修正または変更もまた、本出願の実施形態の範囲内にある。
図9は、本出願の一実施形態による別のBIERv6パケット転送方法の概略フローチャートである。図9に示されるように、本方法は、ステップ910~970を含み得る。以下、ステップ910~970を詳細に個別に説明する。
ステップ910:ネットワーク内のデバイスがBFIRによって送信されたBIERv6パケットを受信する。
BFIRは、受信したユーザマルチキャストデータパケットに対してBIERv6カプセル化を実行して、BIERv6パケットを取得し、BIERv6パケットをネットワーク内のデバイスに送信することができる。BIERv6パケットは、外側のIPv6ヘッダ、IPv6拡張ヘッダ(拡張ヘッダはBIERヘッダを運ぶ)、およびペイロードを運ぶことができ、ペイロードは、内側のIPv4/IPv6マルチキャストデータパケットまたは内側のBIER OAMパケットであり得る。
IPv4/IPv6マルチキャストデータパケットまたはBIER OAMパケットは、BIERヘッダ内のprotoフィールドの値によって区別され得る。例えば、protoフィールドの値が5(proto=5)である場合、それは、BIER OAMパケットがBIERパケットヘッダに続くことを示すか、または、protoフィールドの値が5でない場合(proto!=5)、IPv4/IPv6パケットがBIERパケットヘッダに続くことを示す。詳細については、図2の説明を参照されたく、ここでは詳細を繰り返さない。
前述のネットワーク内のデバイスはBIERv6ルータであることに留意されたい。一例として、デバイスは、BIERドメイン内のBFR(例えば、図6のBFR 2、BFR 3、またはBFR4)であってもよいし、BFER(例えば、図6のBFER 6またはBFER 7)であってもよい。これは、本出願では特に限定されない。
ステップ920:デバイスは、受信したパケットがBIERv6パケットであり、パケット内の宛先アドレスがデバイスのアドレスであると決定する。
パケットを受信した後で、デバイスは、パケットの宛先アドレスがデバイスのアドレスであることを知るために、受信されたパケットの宛先アドレスに対して転送情報データベース(forward information database、FIB)検索を実行し得る。
受信したパケットがBIERv6パケットであるとデバイスが決定する複数の実装形態がある。可能な実装では、デバイスは、パケットの宛先アドレスがデバイスのアドレスであることを知り、宛先アドレスがビットインデックス明示的複製(endpoint for bit index explicit replication、End.BIER)のためのエンドポイントのアドレスであることを示す指示情報を知ることができる。したがって、受信したパケットがBIERv6パケットであると決定されることができる。別の可能な実装では、IPv6拡張ヘッダがBIERヘッダを含むかどうかは、指示情報に基づいてさらに決定されてもよい。IPv6拡張ヘッダがBIERヘッダを含む場合、受信したパケットはBIERv6パケットであると決定されることができる。別の可能な実装では、IPv6拡張ヘッダがBIERヘッダを含むかどうかは、指示情報に基づいて直接チェックされなくてもよい。IPv6拡張ヘッダがBIERヘッダを含む場合、受信したパケットはBIERv6パケットであると決定されることができる。
ステップ930:デバイスは、外側のIPv6ヘッダ内のホップ制限が事前設定閾値未満であるかどうかを調べる。
外側のIPv6ヘッダ内のホップ制限が事前設定閾値未満である場合、ステップ940が実行され得る。
外側のIPv6ヘッダ内のホップ制限が事前設定閾値以上である場合、ステップ950が実行され得る。
本出願のこの実施形態では、デバイスに設定された事前設定閾値は同じであっても異なっていてもよいことを理解されたい。事前設定閾値は、構成されてもよく、またはデフォルト値であってもよい。一例として、BFRデバイスでは、事前設定閾値はデフォルトで2であってもよく、BFERデバイスでは、事前設定閾値はデフォルトで1であってもよい。
ステップ940:デバイスは受信したパケットを破棄し、処理を終了する。
ステップ950:デバイスは、パケットのBIERヘッダ内のTTLフィールドの値が1未満であるかどうかを決定する。
BIERヘッダ内のTTLフィールドの値が1未満であり、例えば、TTLフィールドの値が0である場合、ステップ960が実行される。
BIERヘッダ内のTTLフィールドの値が1以上である場合、ステップ970が実行される。
ステップ960:デバイスは、処理のために制御プレーンにパケットを送信する。
ルータまたはスイッチは、通常、「転送プレーン」および「制御プレーン」を有することを理解されたい。転送プレーンプロセスは、パケットがルータのインタフェースから受信され、1つまたは複数のインタフェースに送信されるプロセスである。転送プレーンプロセスは、通常、専用の転送チップまたはチップの組み合わせによって実施される。「制御プレーン」は、「汎用中央処理装置(central processing unit、CPU)」チップまたはチップセットを含む。転送プレーンが、パケットのTTLフィールドの値が1未満であることを発見したとき、転送プレーンは、処理のために制御プレーンにパケットを送信し得る。
一例として、制御プレーンは、パケットのタイプを決定し、異なる処理を実行し得る。例えば、制御プレーンは、BIERヘッダ内のprotoフィールドを使用することによってパケットのタイプを決定し、パケットのタイプに基づいて対応する処理を実行することができる。以下では、いくつかの可能な実装態様を詳細に説明する。
可能な実装では、パケットがBIER OAMパケットでない場合、またはパケットがマルチキャストデータパケットであると決定された場合、パケットは廃棄され、処理は終了する。
別の可能な実装では、パケットがBIER OAMパケットである場合、パケットは続いて制御プレーンによって処理され、パケットの処理モードはBIER OAMプロトコルに従って実行され得る。例えば、BIER OAMパケットがエコー要求パケットであるかどうかがチェックされる。BIER OAMパケットがエコー要求パケットである場合、BIER OAMパケットのエコー応答は、それに対応して、パケットの外側のIPv6ヘッダ内の送信元アドレスに送信される。
ステップ970:デバイスは、BIERv6パケットのBIERヘッダ内のBitStringをトラバースする。
この実施形態では、ホップ制限が事前設定閾値以上であるか、またはTTLフィールドの値が1以上であるとき、デバイスがBFRであるかBFERであるかがさらに決定される必要があることを理解されたい。
具体的には、一例として、デバイスは、BIERv6パケットのBIERヘッダ内のBitStringをトラバースすることができる。BIERヘッダ内のBitStringをトラバースされたビットが有効であり(例えば、ビットの値は1である)、ビットが現在のノードを表す場合、デバイスは、デバイスがBFERであると決定することができる。
別の例では、BIERヘッダ内のBitStringをトラバースされたビットが有効であり(例えば、ビットの値は1である)、そのビットが現在のノード以外の別のノードを表す場合、デバイスは、デバイスがBFRであると決定することができる。
以下では、詳細な説明のためにデバイスがBFERである例を使用する。
外側のIPv6ヘッダ内のホップ制限が事前設定閾値以上であるBIERv6パケット、またはBIERヘッダ内のTTLフィールドの値が1以上であるBIERv6パケットについて、BIERv6パケットの内側のデータパケットのタイプがさらに決定されることができる。例えば、デバイスは、データプレーン上のパケットのタイプを決定することができる。例えば、デバイスは、BIERヘッダ内のprotoフィールドを使用することによってパケットのタイプを決定することができる。具体的な決定については、前述の説明を参照されたい。詳細は本明細書では繰り返し説明されない。
可能な実装では、パケットがBIER OAMパケットでない場合、外側のIPv6ヘッダおよびIPv6拡張ヘッダがポップアウトされ、後続の転送が内側のマルチキャストデータパケットに基づいて実行される。ホップ制限が閾値に等しいBIERv6パケットが転送されるとき、BFERは「パイプ」モードで動作し得ることを理解されたい。この「パイプ」モードでは、外側のIPv6ヘッダ内のホップ制限の値は、内側のIPv6ユーザマルチキャストパケット内のホップ制限フィールドまたは内側のIPv4マルチキャストパケット内のTTLフィールドに複製されず、さらに1つ減少する。
別の可能な実装では、パケットがBIER OAMパケットではなく、外側のIPv6ヘッダのホップ制限が事前設定閾値より大きい場合、外側のIPv6ヘッダおよびIPv6拡張ヘッダがポップアウトされる。パケットがBIER OAMパケットではなく、外側のIPv6ヘッダ内のホップ制限が事前設定閾値と等しい場合、受信したパケットは廃棄され、処理は終了する。この閾値に等しいホップ制限のBIERv6パケットが廃棄されるケースは、BFERノードが「ユニフォーム」モードで動作するケースであり得る。この「ユニフォーム」モードでは、外側のIPv6ヘッダ内のホップ制限の値は、内側のIPv6ユーザマルチキャストパケット内のホップ制限フィールドまたは内側のIPv4マルチキャストパケット内のTTLフィールドに複製され、さらに1だけ減少する。
別の可能な実装では、パケットがBIER OAMパケットである場合、パケットは続いて制御プレーンによって処理され、パケットの処理モードはBIER OAMプロトコルに従って実行され得る。例えば、BIER OAMパケットがエコー要求パケットであるかどうかがチェックされる。BIER OAMパケットがエコー要求パケットである場合、BIER OAMパケットのエコー応答は、それに対応して、パケットの外側のIPv6ヘッダ内の送信元アドレスに送信される。
以下では、詳細な説明のためにデバイスがBFRである例を使用する。
デバイスがBFRであるとき、デバイスは、別のノードへのネクストホップに関する情報、例えば、ネクストホップのアウトバウンドインタフェースまたはMACアドレスを取得することができる。ホップ制限が事前設定閾値より大きいBIERv6パケットまたはTTLフィールドの値が1より大きいBIERv6パケットの場合、デバイスは、BIERv6パケットの複製を作成し、複製されたBIERv6パケットの外側のIPv6ヘッダのホップ制限の値から1を減算し、BIERヘッダのTTL値から1を減算し、別のノードへのネクストホップに関する取得された情報に基づいて、複製されたBIERv6パケットをネクストホップに送信することができる。
BIERv6パケットのホップ制限が事前設定閾値に等しい場合、デバイスはBIERv6パケットを廃棄し、処理を終了することができる。
TTLフィールドの値が1に等しいBIERv6パケットについては、パケットのタイプが決定されてもよく、異なる処理が実行されてもよい。例えば、パケットのタイプは、BIERヘッダのprotoフィールドを用いて決定されてもよく、対応する処理は、パケットのタイプに基づいて実行される。可能な実装では、パケットがBIER OAMパケットでない場合、またはパケットがマルチキャストデータパケットであると決定された場合、パケットは廃棄され、処理は終了する。別の可能な実装では、パケットがBIER OAMパケットである場合、パケットは続いて制御プレーンによって処理され、パケットの処理モードはBIER OAMプロトコルに従って実行され得る。例えば、BIER OAMパケットがエコー要求パケットであるかどうかがチェックされる。BIER OAMパケットがエコー要求パケットである場合、BIER OAMパケットのエコー応答は、それに対応して、パケットの外側のIPv6ヘッダ内の送信元アドレスに送信される。
以下では、一例として図6に示すシナリオを使用して、ネットワーク内のBIERv6ルータ(例えば、BFRまたはBFER)が図9に示す方法に従ってパケットをどのように処理するかを、BIERv6パケットの内側のデータパケットがIPv4/IPv6パケットである例を使用して説明する。以下の実施形態では、BFRのホップ制限閾値は2であり、BFERのホップ制限閾値は1であると仮定されることを理解されたい。
一例では、BFR 3がBIERv6パケットにカプセル化されたマルチキャストデータパケットを受信すると、外側のIPv6ヘッダ内のホップ制限の値は2であり、BIERヘッダ内のTTL値は1であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がパケットを破棄することである。
別の例では、BFR 3がBIERv6にカプセル化されたマルチキャストデータパケットを受信すると、外側のIPv6ヘッダ内のホップ制限の値は3であり、BIERヘッダ内のTTL値は1であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がBIERv6パケットをR5に転送することである。BIERv6パケットの外側のIPv6ヘッダ内の宛先アドレスはBFER 7のIPアドレスであり、外側のIPv6ヘッダ内のホップ制限は2であり、BIERヘッダ内のTTLは0である。R5は、BIERv6パケットを受信した後、BIERv6パケットをBFER 7に転送する。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は1であり、TTLは0である。BFER 7は、BIERv6パケットを受信すると、前述のパケット転送方法に従ってパケットを破棄し、処理を終了する。
別の例では、BFR 3がBIERv6にカプセル化されたマルチキャストデータパケットを受信するとき、ホップ制限の値は3であり、TTL値は2であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がBIERv6パケットをR5に転送することである。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は2であり、TTLは1である。R5は、パケットを受信した後、パケットをBFER 7に転送する。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は1であり、TTLは1である。BFER 7は、BIERv6パケットを受信した後、前述のパケット転送方法に従ってBIERv6ヘッダのデカプセル化し、内側のマルチキャストデータパケットに基づいてBIERv6パケットを転送する。
したがって、比較的大きいホップ制限値および比較的大きいTTL値が通常使用される場合、データパケットは、出口ノード(例えば、BFER 7)に通常通り転送され、転送され得る。しかしながら、比較的小さいホップ制限値が使用される場合、パケットはBFR 3上で廃棄され得る。これにより、パケットがR5に送信されることを防止し、ホップ制限=1のときに生成されたICMPv6エラーパケットによって引き起こされる攻撃リスクを回避する。TTL値が不適切である場合、パケットは最終BFERに到達できないか、またはBFER上で正常に転送されることができない。
したがって、通常のマルチキャストデータパケットに対してBIERv6カプセル化が実行され、カプセル化されたBIERv6パケットが送信されるとき、適切なホップ制限値および適切なTTL値が選択されることができる。例えば、図6に示すネットワークトポロジでは、ホップ制限とTTLの両方が32であることが選択されてもよく、その結果、データパケットはBFERに正常に転送され、転送され得る。しかしながら、ホップ制限が3であり、TTLが3であり、図6のネットワーク攻撃者によって特に構築されたBIERv6パケットの場合、この方法によれば、BIERv6パケットは、BIERv6パケットがR5に到達する前に廃棄され得る。これにより、パケットがR5に送信されるときにR5上で生成されるICMPv6エラーパケットによって引き起こされる攻撃を回避する。
以下では、一例として図6に示すシナリオを使用して、ネットワーク内のBIERv6ルータ(例えば、BFRまたはBFER)が図9に示す方法に従ってパケットをどのように処理するかを、BIERv6パケットの内側のデータパケットがBIER OAMパケットである例を使用して説明する。以下の実施形態では、BFRのホップ制限閾値は2であり、BFERのホップ制限閾値は1であると仮定されることを理解されたい。
可能な実装では、一例としてBIERトレース検出が使用される。BFIRからTTL=1/2/3のBIERパケットが順次送信され、各パケットはホップ制限=127を使用するものと仮定される。処理プロセスは以下の通りである。
一例では、第1のOAMパケットについて、BFIRによって送信されたパケットは、TTL=1およびホップ制限=127を搬送する。パケットを受信した後、BFR 1はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の例では、第2のOAMパケットについて、BFIRによって送信されたパケットは、TTL=2およびホップ制限=127を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは1であり、BFR 3が受信するパケットのホップ制限は126である。パケットを受信した後、BFR 3はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の例では、第3のOAMパケットについて、BFIRによって送信されたパケットは、TTL=3およびホップ制限=127を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは2であり、BFR 3が受信するパケットのホップ制限は126である。パケットを受信した後、BFR 3はパケットをR5に送信する。R5が受信するパケットのTTLは1であり、R5が受信するパケットのホップ制限は125である。パケットを受信した後、R5はパケットをBFER 7に送信し、BFER 7が受信したパケットのTTLは1であり、BFER 7が受信したパケットのホップ制限は124である。BFER 7はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
BIERトレース検出は、ネットワーク内の各デバイスに対してホップバイホップ検出を実行するために使用される。BIERトレース検出中に比較的大きなホップ制限値が使用され、各BFR/BFERが検出されることができることが分かる。
別の可能な実装では、一例としてBIERトレース検出が使用される。BFIRからTTL=1/2/3のBIERパケットが順次送られてくるものとし、各パケットはホップ制限=3を使用するものと仮定される。処理プロセスは以下の通りである。
一例では、第1のOAMパケットについて、BFIRによって送信されたパケットは、TTL=1およびホップ制限=3を搬送する。パケットを受信した後、BFR 1はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の例では、第2のOAMパケットについて、BFIRによって送信されたパケットはTTL=2およびホップ制限=3を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは1であり、BFR 3が受信するパケットのホップ制限は2である。BFR 3は、パケットを受信した後、パケットを破棄し、エコー応答パケットを送信しない。
別の例では、第3のOAMパケットについて、BFIRによって送信されたパケットは、TTL=3およびホップ制限=3を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは2であり、BFR 3が受信するパケットのホップ制限は2である。BFR 3は、パケットを受信した後、パケットを破棄し、エコー応答パケットを送信しない。
BIERトレース検出中に比較的小さいホップ制限値が使用され、いくつかのBFR/BFERが検出されることができないことが分かる。
したがって、各BFR/BFERを検出することができるように、BIERトレース検出中に適切なホップ制限値が選択されることができる。
いくつかの実施形態では、ホップ制限閾値が2であることが一例として使用される。ホップ制限の値が閾値に等しいか、またはTTLフィールドの値が1に等しい場合、BFERの処理モードはBFRの処理モードとは異なるため、ホップ制限の値またはTTLフィールドの値は、BIERv6パケットを受信したときに1回決定される。BitStringがトラバースされた後、ホップ制限の値またはTTLフィールドの値が再び決定される必要がある。前述の状況を回避するために、(BFRの処理をBFERの処理と区別するために)BitStringがトラバースされるときにホップ制限およびTTLは繰り返し決定されない。代わりに、ホップ制限およびTTLは、BitStringがトラバースされる前に統一された方法で決定される。以下、図10を参照してこの実装形態を詳細に説明する。
図10は、本出願の一実施形態によるさらに別のBIERv6パケット転送方法の概略フローチャートである。図10に示されるように、本方法は、ステップ1010~1070を含み得る。以下、ステップ1010~1070を詳細に個別に説明する。
ステップ1010:ネットワーク内のデバイスがBFIRによって送信されたBIERv6パケットを受信する。
ステップ1010は、ステップ910に対応する。詳細については、ステップ910の説明を参照されたく、ここでは詳細を繰り返さない。
ステップ1020:デバイスは、受信したパケットがBIERv6パケットであり、パケット内の宛先アドレスがデバイスのアドレスであると決定する。
ステップ1020は、ステップ920に対応する。詳細については、ステップ920の説明を参照されたく、ここでは詳細を繰り返さない。
ステップ1030:デバイスは、外側のIPv6ヘッダ内のホップ制限が事前設定閾値以下であるかどうかをチェックする。
外側のIPv6ヘッダ内のホップ制限が事前設定閾値以下である場合、ステップ1040が実行され得る。
外側のIPv6ヘッダ内のホップ制限が事前設定閾値より大きい場合、ステップ1050が実行され得る。
ステップ1040:デバイスは受信したパケットを破棄し、処理を終了する。
ステップ1040において、デバイスがBFRまたはBFERであると決定される前に、受信されたパケットは廃棄され、処理は終了することを理解されたい。すなわち、ステップ1040では、受信したパケットが予め破棄される。ステップ970で、デバイスがBFERであると決定された後、パケットがBIER OAMパケットではなく、外側のIPv6ヘッダ内のホップ制限が事前設定閾値と等しい場合、受信したパケットは廃棄され、処理は終了する。
ステップ1050:デバイスは、パケットのBIERヘッダ内のTTLフィールドの値が1以下であるかどうかを決定する。
BIERヘッダ内のTTLフィールドの値が1以下である場合、ステップ1060が実行される。
BIERヘッダ内のTTLフィールドの値が1より大きい場合、ステップ1070が実行される。
ステップ1060:デバイスは、処理のために制御プレーンにパケットを送信する。
ステップ1060は、ステップ960に対応する。詳細については、ステップ960の説明を参照されたく、ここでは詳細を繰り返さない。
ステップ1070:デバイスは、BIERv6パケットのBIERヘッダ内のBitStringをトラバースする。
一例では、BIERヘッダ内のBitStringのビットが有効(例えば、ビットの値は1である)であり、そのビットが現在のノードを表す場合、BIERv6パケットの内側のデータパケットのタイプがさらに決定されることができる。パケットがBIER OAMパケットでない場合、外側のIPv6ヘッダおよびIPv6拡張ヘッダがポップアウトされ、後続の転送が内側のマルチキャストデータパケットに基づいて実行される。パケットがBIER OAMパケットである場合、パケットは続いて制御プレーンによって処理され、パケットの処理モードはBIER OAMプロトコルに従って実行され得る。例えば、BIER OAMパケットがエコー要求パケットであるかどうかがチェックされる。BIER OAMパケットがエコー要求パケットである場合、BIER OAMパケットのエコー応答は、それに対応して、パケットの外側のIPv6ヘッダ内の送信元アドレスに送信される。
別の例として、BIERヘッダ内のBitStringをトラバースされたビットが有効であり(例えば、ビットの値は1である)、そのビットが現在のノード以外の別のノードを表す場合、その別のノードへのネクストホップに関する情報、例えば、アウトバウンドインタフェースまたはネクストホップのMACアドレスが取得されることができる。BIERv6パケットは複製され、複製されたBIERv6パケットの外側のIPv6ヘッダのホップ制限の値から1が減算され、BIERヘッダのTTL値から1が減算され、複製されたBIERv6パケットは、別のノードへのネクストホップに関する取得された情報に基づいてネクストホップに送信される。
ステップ1070において、ホップ制限およびTTLの値は決定される必要がないことに留意されたい。
以下では、一例として図6に示すシナリオを使用して、ネットワーク内のBIERv6ルータ(例えば、BFRまたはBFER)が図10に示す方法に従ってパケットをどのように処理するかを、BIERv6パケットの内側のデータパケットがIPv4/IPv6パケットである例を使用して説明する。以下の実施形態では、BFRのホップ制限閾値は2であり、BFERのホップ制限閾値は1であると仮定されることを理解されたい。
一例では、BFR 3がBIERv6パケットにカプセル化されたマルチキャストデータパケットを受信すると、外側のIPv6ヘッダ内のホップ制限の値は2であり、BIERヘッダ内のTTL値は1であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がパケットを破棄することである。
別の例では、BFR 3がBIERv6にカプセル化されたマルチキャストデータパケットを受信するとき、ホップ制限の値は3であり、TTL値は1であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がBIERv6パケットをR5に転送することである。BIERv6パケットの外側のIPv6ヘッダ内の宛先アドレスはBFER 7のIPアドレスであり、外側のIPv6ヘッダ内のホップ制限は2であり、BIERヘッダ内のTTLは0である。R5は、BIERv6パケットを受信した後、パケットをBFER 7に転送する。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は1であり、TTLは0である。BFER 7は、BIERv6パケットを受信すると、前述のパケット転送方法に従ってパケットを破棄し、処理を終了する。
別の例では、BFR 3がBIERv6にカプセル化されたマルチキャストデータパケットを受信するとき、ホップ制限の値は3であり、TTL値は2であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がBIERv6パケットをR5に転送することである。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は2であり、TTLは1である。R5は、パケットを受信した後、パケットをBFER 7に転送する。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は1であり、TTLは1である。BFER 7は、BIERv6パケットを受信した後、パケットを破棄して処理を終了する。
別の例では、BFR 3がBIERv6にカプセル化されたマルチキャストデータパケットを受信するとき、ホップ制限の値は3であり、TTL値は3であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がBIERv6パケットをR5に転送することである。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は2であり、TTLは2である。R5は、パケットを受信した後、パケットをBFER 7に転送する。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は1であり、TTLは2である。BFER 7は、BIERv6パケットを受信した後、パケットを破棄して処理を終了する。
別の例では、BFR 3がBIERv6にカプセル化されたマルチキャストデータパケットを受信するとき、ホップ制限の値は4であり、TTL値は3であり、BitStringはBFER 7ノードを含む。処理結果は、BFR 3がBIERv6パケットをR5に転送することである。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は3であり、TTLは2である。R5は、パケットを受信した後、パケットをBFER 7に転送する。BIERv6パケットの宛先アドレスはBFER 7のIPアドレスであり、ホップ制限は2であり、TTLは2である。BFER 7は、BIERv6パケットを受信した後、前述のパケット転送方法に従ってBIERv6ヘッダのデカプセル化し、内側のマルチキャストデータパケットに基づいてBIERv6パケットを転送する。
以下では、一例として図6に示すシナリオを使用して、ネットワーク内のBIERv6ルータ(例えば、BFRまたはBFER)が図10に示す方法に従ってパケットをどのように処理するかを、BIERv6パケットの内側のデータパケットがBIER OAMパケットである例を使用して説明する。以下の実施形態では、BFRのホップ制限閾値は2であり、BFERのホップ制限閾値は1であると仮定されることを理解されたい。
可能な実装では、一例としてBIERトレース検出が使用される。BFIRからTTL=1/2/3のBIERパケットが順次送信され、各パケットはホップ制限=127を使用するものと仮定される。処理プロセスは以下の通りである。
一例では、第1のOAMパケットについて、BFIRによって送信されたパケットは、TTL=1およびホップ制限=127を搬送する。パケットを受信した後、BFR 1はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の例では、第2のOAMパケットについて、BFIRによって送信されたパケットは、TTL=2およびホップ制限=127を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは1であり、BFR 3が受信するパケットのホップ制限は126である。パケットを受信した後、BFR 3はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の例では、第3のOAMパケットについて、BFIRによって送信されたパケットは、TTL=3およびホップ制限=127を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは2であり、BFR 3が受信するパケットのホップ制限は126である。パケットを受信した後、BFR 3はパケットをR5に送信する。R5が受信するパケットのTTLは1であり、R5が受信するパケットのホップ制限は125である。パケットを受信した後、R5はパケットをBFER 7に送信し、BFER 7が受信したパケットのTTLは1であり、BFER 7が受信したパケットのホップ制限は124である。BFER 7はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の可能な実装では、一例としてBIERトレース検出が使用される。BFIRからTTL=1/2/3のBIERパケットが順次送られてくるものとし、各パケットはホップ制限=3を使用するものと仮定される。処理プロセスは以下の通りである。
一例では、第1のOAMパケットについて、BFIRによって送信されたパケットは、TTL=1およびホップ制限=3を搬送する。パケットを受信した後、BFR 1はパケットを制御プレーンに送信し、制御プレーンはエコー応答OAMパケットを送信する。
別の例では、第2のOAMパケットについて、BFIRによって送信されたパケットはTTL=2およびホップ制限=3を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは1であり、BFR 3が受信するパケットのホップ制限は2である。BFR 3は、パケットを受信した後、パケットを破棄し、エコー応答パケットを送信しない。
別の例では、第3のOAMパケットについて、BFIRによって送信されたパケットは、TTL=3およびホップ制限=3を搬送する。BFR 1は、パケットを受信した後、パケットをBFR 3へ転送する。BFR 3が受信するパケットのTTLは2であり、BFR 3が受信するパケットのホップ制限は2である。BFR 3は、パケットを受信した後、パケットを破棄し、エコー応答パケットを送信しない。
以上は、図1~図10を参照して、本出願の実施形態で提供されるBIERパケット転送方法について詳細に説明している。以下で、図11~図13を参照して、本出願の装置の実施形態を詳細に説明する。方法の実施形態の説明は、装置の実施形態の説明に対応することを理解されたい。したがって、詳細に説明されていない部分については、前述の方法の実施形態を参照されたい。
図11は、本出願の一実施形態による第1のネットワークデバイス1100の概略構造図である。図11に示される第1のネットワークデバイス1100は、ビット転送ルータBFRまたはビット転送出口ルータBFERであり、前述の実施形態の方法で第1のネットワークデバイスによって実行される対応するステップを実行してもよい。図11に示されるように、第1のネットワークデバイス1100は、受信モジュール1110および処理モジュール1120を含む。
受信モジュール1110は、ビットインデックス明示的複製インターネットプロトコルバージョン6 BIERv6パケットを受信するように構成され、BIERv6パケットはホップ制限フィールドを含む。
処理モジュール1120は、BIERv6パケット内のホップ制限フィールドの値が第1のネットワークデバイスの事前設定閾値以下であるかどうかを決定するように構成され、事前設定閾値は2以上の値であり、事前設定閾値は第1のネットワークデバイスに接続された1つまたは複数の連続する第2のネットワークデバイスの数に基づいて決定され、第2のネットワークデバイスはBIER転送をサポートしないデバイスである。
処理モジュール1120は、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値以下であるときに、BIERv6パケットの転送を回避するようにさらに構成される。
任意選択で、処理モジュール1120は、BIERv6パケットを廃棄するようにさらに構成される。
任意選択で、処理モジュール1120は、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値に等しい場合に、BIERv6パケットの転送を回避するようにさらに構成される。
任意選択で、処理モジュール1120は、第1のネットワークデバイスがBFRである場合、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値と等しいときにBIERv6パケットを転送することを回避するか、または、第1のネットワークデバイスがBFERである場合、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値に等しいときに、BIERv6パケットをデカプセル化し、デカプセル化された内側のパケットを転送するようにさらに構成される。
任意選択で、BIERv6パケットはビット列BitStringを含み、処理モジュール1120は、BitString内の1つのビットが有効であり、ビットが第1のネットワークデバイスを表すとき、第1のネットワークデバイスはBFERであると決定する、またはBitString内の1つのビットが有効であり、ビットが第1のネットワークデバイス以外のデバイスを表すとき、第1のネットワークデバイスはBFRであると決定するようにさらに構成される。
任意選択で、処理モジュール1120は、第1のネットワークデバイスがBFRである場合、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値より大きいとき、BIERv6パケットを第1のネットワークデバイスのネクストホップデバイスに送信する、または第1のネットワークデバイスがBFERである場合、BIERv6パケットをデカプセル化し、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値より大きいときに、デカプセル化された内側のパケットを転送するようにさらに構成される。
任意選択で、第1のネットワークデバイスはBIERドメイン内のBFRまたはBFERである。
図12は、本出願の一実施形態による第1のネットワークデバイス2000のハードウェア構造の概略図である。図12に示される第1のネットワークデバイス2000は、前述の実施形態の方法で第1のネットワークデバイスによって実行される対応するステップを実行してもよい。
図12に示されるように、第1のネットワークデバイス2000は、プロセッサ2001、メモリ2002、インタフェース2003、およびバス2004を含む。インタフェース2003は、無線または有線方式で実装されてもよく、具体的にはネットワークアダプタであってもよい。プロセッサ2001、メモリ2002、およびインタフェース2003は、バス2004を介して接続される。
インタフェース2003は、具体的には、送信機および受信機を含むことができ、第1のネットワークデバイスが上記の受信および送信を実施するように構成される。例えば、インタフェース2003は、ビットインデックス明示的複製インターネットプロトコルバージョン6 BIERv6パケットを受信するように構成される。
プロセッサ2001は、前述の実施形態において第1のネットワークデバイスによって行われる処理を行うように構成されており、例えば、BIERv6パケット内のホップ制限フィールドの値が第1のネットワークデバイスの事前設定閾値以下であるかどうかを決定するように構成されており、BIERv6パケット内のホップ制限フィールドの値が事前設定閾値以下である場合にBIERv6パケットを転送することを回避するようにさらに構成されている、および/または本明細書に記載の技術に使用される別のプロセスを実行するように構成されている。メモリ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の処理プロセスを完了する。
図12は、単に第1のネットワークデバイス2000の簡略化した設計を示していることが理解されよう。実際の適用では、第1のネットワークデバイスは、任意の数のインタフェース、プロセッサ、またはメモリを含み得る。
図13は、本出願の一実施形態による別の第1のネットワークデバイス2100のハードウェア構造の概略図である。図13に示される第1のネットワークデバイス2100は、前述の実施形態の方法で第1のネットワークデバイスによって実行される対応するステップを実行してもよい。
図13に示されるように、第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)、フラッシュメモリ、電気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)、磁気ディスク、光ディスクといった、プログラムコードを格納することができる任意の媒体を含む。
以上の説明は、この出願の単なる特定の実装にすぎず、この出願の保護範囲を限定しようとするものではない。この出願に開示される技術的範囲内で当業者により容易く考え出される任意の変形または置換は、この出願の保護範囲内に入るものとする。したがって、本願の保護範囲は請求項の保護範囲に従うものとする。