JP2022506679A - パケット転送方法、パケット送信装置、およびパケット受信装置 - Google Patents

Abstract

本出願は、パケット転送方法、パケット送信装置、およびパケット受信装置を提供する。方法は、第1のノードが、制御プレーン上で第1のVPNの第1の識別子および第1のIPv6アドレスを構成することを含み、第1の識別子は、第1のIPv6アドレスに対応する。第1のノードは、第1の指示メッセージを第2のノードに送信し、第1の指示メッセージは、第1の識別子および第1のIPv6アドレスを搬送する。第2のノードは、まず、第1のVPNに関するローカルで構成された情報および第1の指示メッセージ内の第1の識別子に基づいて、第2のノードのものであって第1の識別子との事前設定対応を満たす第2の識別子を決定し、次いで、第1のIPv6アドレスと第2の識別子との間の対応を確立する。第1のノードは、転送予定BIERパケットを取得するために、転送プレーン上で第1のIPv6アドレスに基づいて、第1のVPNに属するマルチキャストデータパケットをカプセル化し、転送予定BIERパケットを送信する。このようにして、パケットカプセル化性能およびパケット転送性能が改善され得る。

Description

本出願は、2018年11月2日に中国特許庁に提出された、「パケット転送方法、パケット送信装置、およびパケット受信装置」と題された中国特許出願第201811301263．0号の優先権を主張し、その全体は、参照により本明細書に組み込まれる。

本出願は通信分野に関し、より具体的には、パケット転送方法、パケット送信装置、およびパケット受信装置に関する。

IPネットワークにおける効率的なポイントツーマルチポイントデータ伝送は、ネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減するために、インターネットプロトコル（Internet protocol、IP）マルチキャスト技術を使用して実施される。したがって、IPマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビ（Internet protocol television、IPTV）、ゲーム、シミュレーションなどで広く使用されている。現在、マルチキャスト技術は通常、プロトコル独立マルチキャスト（protocol independent multicast、PIM）プロトコル、マルチキャストソースディスカバリプロトコル（multicast source discovery protocol、MSDP）プロトコルなどを使用して実施される。これらのマルチキャストプロトコルの共通の特徴は制御プレーンマルチキャストツリーが構築される必要があることである。ネットワークプレーンは、マルチキャスト転送中に、ポイントツーマルチポイントデータ転送、ループ回避などを実施するために、マルチキャストツリーを使用することによって論理的に処理されてツリーになる。配信ツリーがコアとして構築されるマルチキャストルーティングプロトコルにおけるこのような中間ノードは、マルチキャスト転送情報の複雑な状態を維持する必要がある。ネットワーク規模が拡大し、マルチキャストデータトラフィックが増加するに連れて、マルチキャスト技術は、増加するコスト、ならびに運用および保守の大きな課題に直面する。

これを考慮して、マルチキャスト転送経路を構築するための新しい技術が業界で提案され、ビットインデックス明示的レプリケーション（bit indexed explicit replication、BIER）技術と呼ばれている。マルチキャスト配信ツリーが構築される必要のない、新しいマルチキャスト技術アーキテクチャが、業界で提案されている。BIER技術をサポートするルータは、ビット転送ルータ（bit－forwarding router、BFR）と呼ばれる。BFRを含むマルチキャスト転送ドメインは、BIERドメインと呼ばれる（BIER domainとも呼ばれ得る）。BIERドメインのエッジにおいて、ユーザのマルチキャストデータをカプセル化および転送するルータは、ビット転送入口ルータ（bit－forwarding ingress router、BFIR）と呼ばれ、BIERパケットを脱カプセル化するエッジBFRデバイスは、ビット転送出口ルータ（bit－forwarding egress router、BFER）と呼ばれる。マルチキャストデータは、BFIRによってカプセル化されてBIERドメインに入り、BIERドメイン内のBIERパケットのヘッダに基づいて転送され、1つ以上のBFERデバイスを通過した後にBIERドメインを離れる。BIERドメインにおいて、BIERパケットを受信および転送するデバイスは、マルチキャストデータに対応する遷移ビットインデックス転送ルータ（BIER Forwarding Router、BFR）と呼ばれる。BFRは、パケットがカプセル化されているか脱カプセル化されているかに応じて、BFIRまたはBFERであり得る。

従来技術では、ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワーク（virtual private network、VPN）に、既存のメカニズムが依然として使用されている。具体的には、BIERパケットは、仮想プライベートネットワークラベル（virtual private network label、VpnLabel）フィールドに基づいて、カプセル化または脱カプセル化される必要がある。これは、BIERパケットカプセル化または脱カプセル化性能を低下させる。したがって、BIERパケットカプセル化または脱カプセル化性能を改善し、BIERパケット転送性能をさらに改善する方法は、解決されるべき緊急の問題となる。

本出願は、BIERパケットカプセル化または脱カプセル化性能およびBIERパケット転送性能を改善するための、パケット転送方法およびノードを提供する。

第1の態様によれば、パケット転送方法が提供され、ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワークVPNに適用される。方法は、第1のノードが、第1の仮想プライベートネットワークVPNの第1の識別子および第1のインターネットプロトコルバージョン6 IPv6アドレスを構成し、第1のIPv6アドレスは第1の識別子に対応する、ことを含む。第1のノードは第1の指示メッセージを第2のノードに送信し、第1の指示メッセージは、第1のIPv6アドレスと第2の識別子との間の対応を確立するように第2のノードに指示するために使用され、第1の指示メッセージは第1の識別子および第1のIPv6アドレスを含み、第2の識別子は、第2のノードのものであって第1の識別子との事前設定対応を満たす識別子である。第1のノードは、第1のVPNに属するマルチキャストデータパケットを受信する。第1のノードは、マルチキャストデータパケットが属する第1のVPNに基づいて第1のIPv6アドレスを取得し、第1のIPv6アドレスは第1の識別子に対応する。第1のノードは、転送予定BIERパケットを取得するために第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化して転送予定BIERパケットを送信し、転送予定BIERパケットは第1のIPv6アドレスを含む。

本出願で提供されるパケット転送方法によれば、制御プレーン上で、第1のノードは、第1のVPNのために第1の識別子および第1のIPv6アドレスを構成し、第1の指示メッセージを使用して第1の識別子および第1のIPv6アドレスを第2のノードに送信し、第1の識別子は第1のIPv6アドレスに対応する。このようにして、第2のノードは、第1のVPN向けにローカルで構成され、第2の識別子と第1の識別子との間で満たされる事前設定対応に基づいて、第1のIPv6アドレスと第2の識別子との間の対応をさらに決定することができる。転送プレーンにおいて、第1のVPNに対応するインターフェースを通じて、第1のVPNに属するパケットマルチキャストデータパケットを受信するとき、第1のノードは、第1の識別子および第1のIPv6アドレスを使用して第1のIPv6アドレスを相応に取得し、転送予定BIERパケットを取得するために第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化し、BIERパケットを第2のノードに送信するが、第1のノードのBIERパケットカプセル化性能およびBIERパケット送信性能を改善するために、仮想プライベートネットワークラベルVpnLabelに基づいてパケットをカプセル化する必要はない。

「第1」および「第2」は、単に異なるノードを区別することを意図しており、本出願の保護範囲に対するいかなる限定も構成しないことが、理解されるべきである。第1のノードは、パケット転送リンク上でパケットをカプセル化するノードであり、第2のノードは、パケット転送リンク上でパケットを脱カプセル化するノードである。第1のノードは、ヘッドノード、ヘッドデバイス、またはパケットをカプセル化するルーティングデバイスとも呼ばれ得る。第2のノードは、テールノード、テールデバイス、またはパケットをカプセル化するルーティングデバイスとも呼ばれ得る。

マルチキャストデータパケットはマルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットのグループアドレスを搬送し、第2のノードは第1のノードの送信元アドレスおよびグループアドレスを送信し、マルチキャストデータパケットの送信元アドレスは第2のノードによって送信された送信元アドレスと同じであり、マルチキャストデータパケットのグループアドレスは第2のノードによって送信されたグループアドレスと同じであるため、第1のノードは、マルチキャストデータパケットが第2のノードに送信される必要があると判定することが、さらに理解されるべきである。第1のノードは、第2のノードがマルチキャストデータパケットに関与するノードであることを知り、したがって、マルチキャストパケットが第2のノードに送信される必要があると判定する。

本出願のこの実施形態では、パケット転送および脱カプセル化が第2のノードの観点から記載されていることが、さらに理解されるべきである。実際、第1のノードは、マルチキャストデータパケットを複数の第2のノードに送信し得る。言い換えると、複数の第2のノードは、マルチキャストデータパケットに関与し得る。しかしながら、第2のノードによって実行される動作は、先の第2のノードによって実行されるものと同様である。したがって、詳細は本明細書では再度説明されない。

第1の態様を参照すると、第1の態様のいくつかの実装形態では、第1のノードが第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化する前に、方法は、第1のノードが、第2のノードによって送信された第2の指示メッセージを受信し、第2の指示メッセージは第2のノードのIPv6アドレスを含むことを、さらに含む。第1のノードは、第2の指示メッセージおよび事前設定構成情報に基づいてプロキシノードのIPv6アドレスを取得し、事前設定構成情報は、第2のノードのIPv6アドレスとプロキシノードのIPv6アドレスとの間の対応を含む。第1のノードが転送予定BIERパケットを取得するために第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化し、転送予定BIERパケットを送信することは、第1のノードが転送予定BIERパケットを取得するためにマルチキャストデータパケットの外層でIPv6ヘッダをカプセル化し、IPv6アドレスの送信元アドレスが第1のIPv6アドレスであり、IPv6ヘッダの送信先アドレスがプロキシノードのIPv6アドレスであることを含む。第1のノードは、プロキシノードを通じてIPv6ヘッダに基づいて転送予定BIERパケットを第2のノードに送信する。本出願で提供されるパケット転送方法によれば、第1のノードがマルチキャストデータパケットをカプセル化する前に、第1のノードは、第2のノードによって送信された第2の指示メッセージをさらに受信し、第2の指示メッセージおよびローカル事前設定構成情報に基づいてパケット転送経路を決定する。事前設定構成情報が第2のノードのIPv6アドレスとプロキシノードのIPv6アドレスとの間の対応を含むとき、第1のノードはマルチキャストデータパケットをカプセル化し、マルチキャストデータパケットの外層でIPv6ヘッダをカプセル化する。本出願では、パケットの外層でカプセル化されたIPv6ヘッダは外部IPv6ヘッダと呼ばれてもよく、外部IPv6ヘッダで搬送される送信元アドレスは第1のIPv6アドレスであり、外部IPv6ヘッダで搬送される送信先アドレスはプロキシノードのIPv6アドレスである。第1のノードは、第1のノードが第2のノードに到着するためのプロキシノードのアドレスを構成し、構成に基づいてカプセル化を実行することができる。

第2のノードのIPv6アドレスとプロキシノードのIPv6アドレスとの間の先の対応は、対応に基づいて、BIERパケットがプロキシノードを通じて第2のノードに転送されると知ることであることが、理解されるべきである。プロキシノードについては、BIERパケットが、プロキシノードを通じて複数の第2のノードに転送され得る。言い換えると、事前設定構成情報は、プロキシノードを通じてBIERパケットを第2のノードに転送するように指示することができる。しかしながら、BIERパケットがプロキシノードを通じて第2のノードにのみ転送されることが可能なケースは限定されない。

第1の態様を参照すると、第1の態様のいくつかの実装形態では、第1のノードが第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化する前に、方法は、第1のノードが、第2のノードによって送信された第2の指示メッセージを受信し、第2の指示メッセージは第2のノードのIPv6アドレスを含むことを、さらに含む。第1のノードは、第2の指示メッセージおよび事前設定構成情報に基づいて指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレスを取得し、事前設定構成情報は、第2のノードのIPv6アドレス、指定ノードのIPv6アドレス、およびプロキシノードのIPv6アドレスの間の対応を含む。第1のノードが転送予定BIERパケットを取得するために第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化し、転送予定BIERパケットを送信することは、第1のノードがマルチキャストデータパケットの外層でセグメントルーティングヘッダSRHをカプセル化し、SRHがアドレスリストを搬送し、アドレスリストが指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレスを含むことを含む。第1のノードは、転送予定BIERパケットを取得するためにSRHの外層でIPv6ヘッダをカプセル化し、IPv6ヘッダの送信元アドレスは第1のIPv6アドレスであり、IPv6ヘッダの送信先アドレスは指定ノードのIPv6アドレスである。第1のノードは、指定ノードおよびプロキシノードを通じてSRHおよびIPv6ヘッダに基づいて転送予定BIERパケットを第2のノードに送信する。

本出願で提供されるパケット転送方法によれば、第1のノードは、プロキシノードに到着する指定ノードのアドレスをさらに構成し、構成に基づいてパケットをカプセル化し、柔軟な構成ソリューションを提供し得る。

第1の態様を参照すると、第1の態様のいくつかの実装形態では、第2の指示メッセージは、ボーダーゲートウェイプロトコルマルチキャスト仮想プライベートネットワークBGP－MVPNメッセージを含む。

第1の態様を参照すると、第1の態様のいくつかの実装形態では、方法は、第1のノードが、第2のノードを示す事前設定情報をカプセル化することを、さらに含む。第1のノードが第2のノードを示す事前設定情報をカプセル化することは、第1のノードがIPv6拡張ヘッダDestination Option Headerをカプセル化し、IPv6拡張ヘッダDestination Option HeaderがBIERヘッダを含み、BIERヘッダが第2のノードを示す事前設定情報を搬送すること、または第1のノードがBIER拡張ヘッダをカプセル化し、BIER拡張ヘッダが第2のノードを示す事前設定情報を搬送し、BIER拡張ヘッダが新たに追加されたIPv6拡張ヘッダであることを含む。

本出願で提供されるパケット転送方法によれば、第1のノードは、第2のノードを示す事前設定情報をカプセル化するために既存のIPv6拡張ヘッダをさらに拡張するか、または第2のノードを示す事前設定情報をカプセル化するために新しいIPv6拡張ヘッダを定義し、パケットカプセル化の柔軟性を改善するために、第2のノードを示す事前設定情報をカプセル化するための複数の選択ソリューションを提供し得る。

第1の態様によれば、第1の態様のいくつかの実装形態では、第1の指示メッセージは、以下のメッセージのうちの少なくとも1つを含む：BGP－MVPNルートBGP－MVPN routeメッセージ、BGP－VPNルートBGP－VPN routeメッセージ、またはBGPイーサネット仮想プライベートネットワークルートBGP－EVPN routeメッセージ。

第2の態様によれば、パケット転送方法が提供され、ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワークVPNに適用される。方法は、第2のノードが第1のノードから第1の指示メッセージを受信し、第1の指示メッセージが第1のVPNの第1の識別子および第1のIPv6アドレスを含み、第1の識別子が第1のIPv6アドレスに対応することを含む。第2のノードは、第1のIPv6アドレスおよび第1の識別子に基づいて第1のIPv6アドレスと第2の識別子との間の対応を確立し、第2の識別子は、第2のノードの識別子であり、第1の識別子との事前設定対応を満たす識別子である。第2のノードは、第1のノードからBIERパケットを受信し、BIERパケットは、第1のIPv6アドレスおよびマルチキャストデータパケットを含む。第2のノードは、第1のIPv6アドレスおよび第1のIPv6アドレスと第2の識別子との間の対応に基づいて、第2の識別子に対応するインターフェースにマルチキャストデータパケットを送信する。

本出願で提供されるパケット転送方法によれば、第2のノードは、第1のVPNのローカルで構成された第2の識別子と、受信した第1の指示メッセージで搬送された第1の識別子および第1のIPv6アドレスに基づいて、制御プレーン上の第1のIPv6アドレスと第2の識別子との間の対応を判定する。転送プレーンでは、BIERパケットを受信した後に、第2のノードは、BIERパケットで搬送された第1のIPv6アドレスに基づいて、BIERパケットで搬送されたマルチキャストデータパケットを第2の識別子に対応するインターフェースに送信することを決定する。パケット脱カプセル化プロセスでは、第2のノードは、パケット脱カプセル化性能を改善するために、VpnLabelに基づいて、マルチキャストデータパケットを第2の識別子に対応するインターフェースに送信することを決定する必要がない。

第2の態様を参照すると、第2の態様のいくつかの実装形態では、第2のノードが第1のノードからBIERパケットを受信する前に、方法は、第2のノードが第2の指示情報を第1のノードに送信し、第2の指示情報が第2のノードのIPv6アドレスを含むことを、さらに含む。

本出願で提供されるパケット転送方法によれば、第2のノードは、第2のノードが関与するマルチキャストデータパケットを第1のノードが知ることができるように、マルチキャスト参加パケットを第1のノードに送信する必要がある。

第2の態様を参照すると、第2の態様のいくつかの実装形態では、第2のノードが、第1のIPv6アドレスおよび対応に基づいて、マルチキャストデータパケットを第2の識別子に対応するインターフェースに送信することは、第2のノードが、第1のIPv6アドレスおよび対応に基づいて第2の識別子を取得することを含む。マルチキャストデータパケットがマルチキャスト送信元のアドレスおよびマルチキャストグループのアドレスを含むと判定した後、第2のノードは、第2の識別子に対応する少なくとも1つのインターフェースを取得し、少なくとも1つのインターフェースを通じてマルチキャストデータパケットを送信し、マルチキャスト送信元のアドレスは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、マルチキャストグループのアドレスは、第2のノードが参加するマルチキャストグループのアドレスである。

本出願で提供されるパケット転送方法によれば、受信したBIERパケットを脱カプセル化するとき、第2のノードは、第2のノードを示し、BIERパケットで搬送される事前設定情報に基づいて、BIERパケットが第2のノードによって脱カプセル化されることをまず決定する。具体的には、第2のノードは、第1のIPv6アドレスと第2の識別子との間の、制御プレーン上で確立された対応、およびBIERパケットで搬送される第1のIPv6アドレスに基づいて、BIERパケットで搬送されるマルチキャストデータパケットが、第2の識別子に対応するインターフェースに送信される必要があると、さらに決定する。次いで、マルチキャストデータパケットを第2の識別子に対応するインターフェースに送信すると決定した後、第2のノードは、BIERパケットの内部IPv6またはIPv4ヘッダで搬送される送信元アドレスおよび送信先アドレスに基づいて、第2の識別子に対応するインターフェース内にあり、マルチキャストデータパケットが送信されるべき特定のインターフェースをさらに決定する必要がある。本出願で提供されるパケット転送方法によれば、第2のノードが、ローカル識別子に対応し、マルチキャストデータパケットが送信される、特定のインターフェースを決定するプロセスにおいて、第2のノードは、第1のIPv6アドレスと第2の識別子との間の、制御プレーン上に確立される対応、およびBIERパケットで搬送される第1のIPv6アドレスに基づいて、決定プロセスを簡略化し、パケット脱カプセル化性能を改善する決定を実行するだけでよい。

第2の態様を参照すると、第2の態様のいくつかの実装形態では、第2の指示メッセージはBGP－MVPNメッセージを含む。

第2の態様を参照すると、第2の態様のいくつかの実装形態では、第1の指示メッセージは、以下のメッセージのうちの少なくとも1つを含む：BGP－MVPN routeメッセージ、BGP－VPN routeメッセージ、またはBGP－EVPN routeメッセージ。

第3の態様によれば、パケット送信装置が提供される。パケット送信装置は、第1の態様のいずれか1つ、または第1の態様の可能な実装形態による第1のノードの動作を実行するように構成され得る。具体的には、パケット送信装置は、第1の態様で記載されたステップまたは機能を実行するように構成され、第1の態様における第1のノードであり得る、対応するコンポーネント（means）を含む。ステップまたは機能は、ソフトウェア、ハードウェア、またはハードウェアとソフトウェアとの組合せを使用して実施されてもよい。

第4の態様によれば、パケット受信装置が提供される。パケット受信装置は、第2の態様のいずれか1つ、または第2の態様の可能な実装形態による第2のノードの動作を実行するように構成され得る。具体的には、パケット受信装置は、第2の態様で記載されたステップまたは機能を実行するように構成され、第2の態様における第2のノードであり得る、対応するコンポーネント（means）を含む。ステップまたは機能は、ソフトウェア、ハードウェア、またはハードウェアとソフトウェアとの組合せを使用して実施されてもよい。

第5の態様によれば、パケット転送デバイスが提供される。パケット転送デバイスの構造は、プロセッサを含む。プロセッサは、第1の態様および第2の態様、または第1の態様および第2の態様の実装形態のいずれか1つによる機能を実行する際に、パケット転送デバイスをサポートするように構成されている。可能な設計では、パケット転送デバイスは、情報を受信または送信する際にマルチキャスト転送デバイスをサポートするように構成された、通信インターフェースをさらに含み得る。

可能な設計では、パケット転送デバイスは、メモリをさらに含み得る。メモリは、プロセッサに結合され、パケット転送デバイスに必要なプログラム命令およびデータを記憶するように構成されている。

あるいは、パケット転送デバイスは、メモリおよびプロセッサを含む。メモリはコンピュータプログラムを記憶するように構成され、プロセッサは、パケット転送デバイスが、第1の態様および第2の態様または第1の態様および第2の態様の実装形態のいずれか1つによるパケット転送方法を実行するように、メモリからコンピュータプログラムを呼び出し、コンピュータプログラムを実行するように構成されている。

第6の態様によれば、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータプログラム（コードまたは命令とも呼ばれ得る）を含む。コンピュータプログラムが実行されると、コンピュータは、第1の態様および第2の態様または第1の態様および第2の態様の可能な実装形態のいずれか1つによるパケット転送方法を実行できるようになる。

第7の態様によれば、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体はプログラムを記憶し、プログラムは、コンピュータ内のサーバが第1の態様および第2の態様または第1の態様および第2の態様の可能な実装形態のいずれか1つによるパケット転送方法を実行することを可能にする。

あるいは、コンピュータ可読記憶媒体は、先のサーバによって使用されるコンピュータソフトウェア命令を記憶するように構成され、コンピュータソフトウェア命令は、第1の態様および第2の態様または第1の態様および第2の態様の可能な実装形態のいずれか1つによるパケット転送方法を実行するように設計されたプログラムを含む。

第8の態様によれば、チップシステムが提供される。チップシステムは、第1の態様および第2の態様または第1の態様および第2の態様の実装形態のいずれか1つによる機能を実施する際に、コンピュータ内のサーバをサポートするように構成された、プロセッサを含む。

本出願の実施形態のパケット転送方法およびノードによれば、第2のノードは、制御プレーン上で第1のIPv6アドレスと第2の識別子との間の対応を確立し、転送プレーン上で、BIERパケットをカプセル化するときに、第1のノードは、VpnLabelを最初に使用する必要はないが、BIERパケットの外部IPv6ヘッダの送信元アドレスとして第1のIPv6アドレスを使用するだけでよく、第2のノードは、第1のIPv6アドレスと第2の識別子との間であって、制御プレーンおよび受信したBIERパケットで搬送された第1のIPv6アドレス上で確立された対応に基づいて、BIERパケットで搬送されたマルチキャストデータパケットが、第1のIPv6アドレスとの対応を有する第2の識別子に対応するインターフェースに送信される必要があると判定することができる。このようにして、BIERパケットカプセル化または脱カプセル化性能が改善される。

BIERパケット転送アーキテクチャの概略図である。 本出願の一実施形態によるBIERパケットのヘッダフォーマットの概略図である。 本出願の一実施形態によるIPv6拡張ヘッダのフォーマットの概略図である。 本出願の一実施形態によるパケット転送方法の概略図である。 本出願の一実施形態による第1のノードによってカプセル化されたBIERパケットのフォーマットの概略図である。 本出願の一実施形態による第1のノードによってカプセル化されたBIERパケットのフォーマットの概略図である。 本出願の一実施形態による第1のノードによってカプセル化されたBIERパケットのフォーマットの概略図である。 本出願の一実施形態による特定の実施形態1の概略図である。 本出願の一実施形態による特定の実施形態1の概略図である。 本出願の一実施形態による特定の実施形態2の概略図である。 本出願の一実施形態によるパケット送信装置の概略構造図である。 本出願の一実施形態による別のパケット送信装置の概略構造図である。 本出願の一実施形態によるパケット受信装置の概略構造図である。 本出願の一実施形態による別のパケット受信装置の概略構造図である。

以下、添付の図面を参照しながら本願における技術的ソリューションについて説明する。

本出願の実施形態の技術的ソリューションは、マルチキャスト仮想プライベートネットワーク（仮想プライベートネットワークVPN）におけるインターネットプロトコルバージョン6（internet protocol version 6、IPv6）機能、セグメントルーティングバージョン6（segment routing version 6、SRv6）機能、またはBIER IPv6転送機能のうちの1つ以上をサポートするノードに適用され得る。SRv6機能はIPv6 functionを含み、BIER IPv6転送機能はBIER IPv6パケットのカプセル化、BIER IPv6パケットの転送、ならびにBIER IPv6パケットの脱カプセル化および送信を含む。本出願では、BIER IPv6パケットは、BIERパケットとも呼ばれ得る。

具体的には、先のノードは、BIERパケットカプセル化、BIERパケット転送、およびBIERパケット脱カプセル化を実施することができるルータまたはスイッチなどのノードであり得る。先のノードは、ネットワーク要素、デバイス、またはその他の名前でも呼ばれ得る。

VPNは、multicast VPNであってもよいことは留意されるべきである。具体的には、multicast VPNは、マルチキャストが展開される仮想プライベートネットワークを指す。仮想プライベートネットワークは、レイヤ3仮想プライベートネットワーク（layer 3 virtual private network、L3VPN）またはイーサネット仮想プライベートネットワーク（Ethernet virtual private network、EVPN）であり得る。あるいは、公衆網のいくつかのサイトは、マルチキャストを展開し得る。プライベートネットワークL3VPN／EVPN／公衆網でマルチキャストを展開するための、いくつかの共通のプロトコルおよび方法がある。たとえば、ボーダーゲートウェイプロトコルマルチキャスト仮想プライベートネットワーク（border gateway protocol－multicast virtual private network、BGP－MVPN）アドレスファミリメッセージは、マルチキャストがL3VPN上で展開されるときに使用される。ボーダーゲートウェイプロトコルイーサネット仮想プライベートネットワーク（border gateway protocol－Ethernet virtual private network、BGP－EVPN）アドレスファミリは、マルチキャストがEVPN上で展開されるときに使用される。BGP－MVPNアドレスファミリメッセージはまた、公衆網を識別するために特殊な識別子が使用される場合、マルチキャストが公衆網上で展開されるときにも使用される。この場合、公衆網は、特殊なL3VPNまたは仮想ルーティングおよび転送（virtual routing forwarding、VRF）と見なされる。

図1は、BIERパケット転送アーキテクチャの概略図である。概略図は、2つの異なるBIERドメイン（図1に示されるBIERドメイン1およびBIERドメイン2）を含む。BIERドメイン1およびBIERドメイン2のエッジにおいて、マルチキャストデータをカプセル化するエッジBFRノードはBFIR（図1に示されるBFIR 1からBFIR 4）であり、BIERパケットを脱カプセル化するエッジBFRノードはBFER（図1に示されるBFER 1からBFER 4）である。

BFIRは、ビット転送入口ルータ、ヘッドノード、転送デバイスなどと呼ばれ得る。BFERは、ビット転送出口ルータ、テールノード、葉ノード、受信デバイスなどと呼ばれ得る。

具体的には、マルチキャストデータパケットは、転送予定BIERパケットを取得するために、BFIRを使用してカプセル化される。BIERパケットはBIERドメインに入り、BIERパケットは、BIERドメイン内のBIERパケットのヘッダに基づいて転送される。BIERパケットは、1つ以上のBFERデバイスを通過した後にBIERドメインを離れる。BIERドメインにおいて、BIERパケットを受信および転送するデバイスは、BIERパケットに対応する遷移ビットインデックス転送ルータ（すなわち、transit BFR）と呼ばれる。BFRは、パケットがカプセル化されているか脱カプセル化されているかに応じて、BFIRまたはBFERであり得る。

たとえば、図1のBFR 1がマルチキャストデータパケットを受信し、転送予定BIERパケットを取得するためにマルチキャストデータパケットをカプセル化するとき、BFR 1はBFIRである。図1のBFR 1がBIERパケットを受信し、BIERパケットを脱カプセル化するとき、BFR 1はBFERである。

本出願の実施形態で提供されるパケット転送方法、パケット送信装置、およびパケット受信装置をより良く理解するために、以下で本出願の実施形態におけるいくつかの基本概念を最初に説明する。

1．BIER技術

BIER技術は、2014年末からインターネット技術特別調査委員会（the Internet Engineering Task Force、IETF）での議論を通じて生み出されたマルチキャスト技術である。BIER技術は、以下のように簡単に説明される。

まず、BIERドメイン（BIER domain）の概念が提案される。BIERドメインは、BIER制御プレーンプロトコルが動作するドメインである。

たとえば、内部ゲートウェイプロトコル（interior gateway protocol、IGP）が動作する1つのドメインは1つのBIERドメインであり得るが、IGPが動作する複数のドメインは1つのBIERドメインであり得ない。本出願では、IGPが動作するドメインは、IGPドメインと呼ばれる。たとえば、図1に示されるBIERドメイン1はIGPドメイン1であり得、図1に示されるBIERドメイン2はIGPドメイン2であり得る。

具体的には、1つのBIERドメインが複数のサブドメイン（Sub－domain）に分割され得る。

たとえば、1つのBIERドメインが3つのSub－domain（それぞれSub－domain＃1、Sub－domain＃2、およびSub－domain＃3）に分割される。Sub－domain＃1は、BIERドメイン内の全てのノードおよび全てのリンクを含み、Sub－domain＃2は、BIERドメイン内の全てのノードおよびリンクの第1の部分を含み、Sub－domain＃3は、BIERドメイン内のいくつかのノードおよびリンクの第2の部分を含み、リンクの第1の部分およびリンクの第2の部分は、BIERドメイン内の全てのリンクの第1の部分および第2の部分である。

BIERドメイン内の関連情報構成およびその範囲は、通常、Sub－domainの粒度でSub－domainに対する効果を生じることが、理解されるべきである。

値は、Sub－domain内の各エッジノード向けに構成され、BIER転送ルータ識別子（BIER forwarding router identify、BFR－ID）として使用される。

たとえば、1から256までの範囲の値は、Sub－domain＃1の各エッジノード向けに構成され、Sub－domain＃1の各エッジノードのBFR－IDとして使用され、そして1から256までの範囲の値は、Sub－domain＃2の各エッジノード向けに構成され、Sub－domain＃2の各エッジノードのBFR－IDとして使用される。

Sub－domainの各ノードの構成情報は、IGPフラッディング方式でIGPドメイン内にフラッディングされる。具体的には、各ノードの構成情報は、ノードのIPアドレス、ノードが属するSub－domain、ノードが属するSub－domainに対応するビットベースの転送テーブル識別子（Bit Index Forwarding Table identify、BIFT－ID）、およびノードのBFR－IDを含む。

エッジノードはBFR－IDを有するが、中間ノードはBFR－IDを有さないことが、理解されるべきである。しかしながら、中間ノードは、ノードのIPアドレス、ノードが属するSub－domain、およびノードが属するSub－domainに対応するBIFT－ID情報を有する。

IGPフラッディング方式では、IGPドメイン内の各ノードは、ノードが属するIGPドメインの構成情報をブロードキャストし、IGPドメイン内の全てのノードは、別のノードの構成情報を受信および記憶する。さらに、IGPドメイン内の各ノードは、従来技術のIGPにおける一般的なアルゴリズムに基づく計算を通じて、BIERパケットがエッジノードに到着した後の次ホップノードに関する情報を取得する。IGPドメイン内の各ノードは、特定のSub－domain内にあって各BFR－IDが対応する、特定のノードを知っている。IGPドメイン内の各ノードは、制御プレーン上で転送テーブルを確立する。転送テーブルを確立するプロセスは、制御プレーン上で転送テーブルを確立する先行技術のプロセスと同様である。詳細は本明細書には記載されない。

IGPドメイン内の各ノードが制御プレーン上で転送テーブルを確立した後、IGPドメイン内の各ノードは、転送テーブル内の対応に基づいて、転送プレーン上でBIERパケットを転送し得る。BIERパケット内のビット列（BitString）の各ビットの値は、BIERパケットに対応する次ホップノードを識別するために使用される。

たとえば、BIERパケットに対応する次ホップノードがBFR－ID 1に対応するノードであることを示すために、BitString内の最下位ビット（右端のビット）が使用される。BitString内の右から左へ2番目のビットは、BIERパケットに対応する次ホップノードがBFR－ID 2に対応するノードであることを示すために使用される。

BitStringがBIERパケットに対応する次ホップノードをどのように示すかを簡単に説明するために、具体例が以下で使用される。

BitStringは合計4ビットを有すると仮定され、BitString内のビットの値が1であるとき、これはBIERパケットが転送されることを示し、BitString内のビットの値が0であるとき、これはBIERパケットが転送されないことを示すと規定される。

BitStringが0001であるとき、BIERパケット内のBitStringに基づく転送プレーン上で、BIERパケットは、BFR－ID 1に対応するノードに送信される必要があると判定される。BitStringが0011であるとき、BIERパケット内のBitStringに基づく転送プレーン上で、BIERパケットは、BFR－ID 1に対応するノードおよびBFR－ID 2に対応するノードに送信される必要があると判定される。

さらに、BIERパケット内のBitStringの複数のビットが同じ次ホップノードに対応するとき、1つのBIERパケットのみが次ホップノードに送信される必要がある。

たとえば、BIERパケットの次ホップノードがBFR－ID 1に対応するノードであることを示すために、BitString内の2つの最下位ビットが使用される。BitStringは合計4ビットを有すると仮定され、BitString内のビットの値が1であるとき、これはBIERパケットが転送されることを示し、BitString内のビットの値が0であるとき、これはBIERパケットが転送されないことを示すと規定される。

BitStringが0011であるとき、BIERパケット内のBitStringに基づく転送プレーン上で、BIERパケットはBFR－ID 1に対応するノードに送信される必要があり、1つのBIERパケットのみがBFR－ID 1に対応するノードに送信される必要があると判定される。理由は以下の通りである。0011の最下位ビットがトラバースされるとき、BIERパケットがBFR－ID 1に対応するノードに送信されるべきであると判定され、最下位ビットの右隣のビットがクリアされ、その後トラバースされない。代わりに、右から左へ3番目のビットが直接トラバースされる。

BIERパケット内のBitStringに基づいてBIERパケットに対応する次ホップノードおよびBitString内のビット数を決定する方法は、単なる例にすぎず、本出願に対する限定を構成しないことが、理解されるべきである。具体的には、BitStringの機能は、従来技術のBitStringの機能と同様である。詳細は本明細書には記載されない。

上述のように、パケット転送は、BIERパケット内のBitStringに基づいて、転送プレーン上で決定される。この場合、転送プレーン上でBIERパケット転送を実施するための鍵は、BIERパケットのヘッダフォーマットである。以下、添付図面を参照して、BIERパケットのヘッダフォーマットについて簡単に説明する。

図2は、本出願の一実施形態によるBIERパケットのヘッダフォーマットの概略図である。概略図は、32－bit（4バイト）BIERラベル（BIER label）またはBIFT識別子（BIFT－ID）値を含む。32 bitの最初の20 bitは、BIER label値またはBIFT－ID値であり、32 bitの最後の12 bitは、BIER labelまたはBIFT－IDを有する別の情報（図2の最初の行に示される）である。

具体的には、BIER labelまたはBIFT－IDを有する別の情報は、図2の最初の行に示されるネットワーク上の1つのパケットのトラフィッククラス（traffic class、TC）、スタック底部（bottom of stack、S）、および生存時間（time to live、TTL）などの情報を含む。

BIER labelまたはBIFT－IDは、異なるシナリオにおいてBIERパケットのヘッダフォーマットの20 bitの2つの異なる名前であることが、理解されるべきである。BIERパケット転送中に、BIERヘッダは拡張ヘッダに続き、データパケットはBIERヘッダの後にカプセル化される。

以下の2つのケースについて個別に説明する。

1．BIERヘッダは、MPLSラベルスタックにカプセル化されるか、またはイーサネットの後にカプセル化される。たとえば、イーサネットリンク上で、イーサネットタイプが0x8847である場合、これは、イーサネットの後のカプセル化がMPLSカプセル化であることを示す。ラベルスタックの最初のラベルがBIER labelである場合、BIFT－IDは、実際にはMPLS labelであり、BIER labelと呼ばれる。

2．BIERヘッダは、MPLSラベルスタックにカプセル化されない。たとえば、イーサネットリンク上で、イーサネットタイプが0xAB37である場合、これは、イーサネットの後のカプセル化が非MPLS BIERカプセル化であることを示す。この場合、BIFT－IDはMPLS labelではないが、直接的にBIFT－IDである。

結論として、BIFT－IDは非MPLSシナリオで使用され、BIFT labelはMPLSシナリオで使用される。

概略図に示されるBIERパケットのヘッダフォーマットは、（図2の第2行および第3行に示されるように）64 bits（8バイト）を有する他のフィールドをさらに含む。具体的には、他のフィールドは、図2の第2行および第3行に示される、ニブル（Nibble）、バージョン（version、Ver）、ビット列長（BitString length、BSL）、情報エントロピー（Entropy）、運用、管理、および保守（operation administration and maintenance、OAM）、改訂標準バージョン（revised standard version、Rsv）、差別化サービスコードポイント（differentiated services code point、DSCP）、プロトコル（protocol、Proto）、およびビット転送入口ルータ識別子（bit－forwarding ingress router identify、BFIR－ID）などのフィールドを含む。

概略図に示されるBIERパケットのヘッダフォーマットは、BitStringをさらに含む。具体的には、BitStringは、64 bit、128 bit、または256 bitなどの長さを有し得る（図2のnの値はBitStringの長さとともに変化し、BitStringの長さが64 bitであるとき、n＝1、つまりBitStringは図2の第4行および第5行にある）。図2の最初の行に示されているBIER labelまたはBIFT－IDの値は、BitStringの長さを判定するために使用され得る。

2．IPv6技術

IPv6は、インターネットプロトコルバージョン6である。以前に広く使用されていたインターネットプロトコルは、インターネットプロトコルバージョン4（internet protocol version 4、IPv4）である。IPv6とIPv4とのより大きな違いは、以下の通りである。

IPv6ヘッダは、IPv6において基本的なIPv6ヘッダ（IPv6 Header）およびIPv6拡張ヘッダ（IPv6 Extension Header）に分割される。いくつかのIPv6拡張ヘッダはIPv6で定義され、拡張ヘッダはさらに拡張されてもよい。

たとえば、IPv6で定義された既存のIPv6拡張ヘッダは、タイプ・長さ・値（type length value、TLV）方式でさらに拡張される。場合により、拡張を通じて新しいIPv6拡張ヘッダが追加を許可される。しかしながら、IPv6プロトコルでは、既存のIPv6拡張ヘッダを拡張することが推奨されるが、新しいIPv6拡張ヘッダを追加することは推奨されない。

別の例として、セグメントルーティングバージョン6（Segment Routing version 6）は、既存のIPv6拡張ヘッダ上で拡張されたサブタイプであるが（タイプはルーティングヘッダ（Routing Header）である）、IPv6拡張ヘッダおよびルーティングヘッダと並列である新たに定義されたIPv6拡張ヘッダのタイプではない。

IPv6プロトコルでは、新しいIPv6拡張ヘッダを追加することは推奨されないが、既存のIPv6拡張ヘッダをさらに拡張することは推奨されることが、理解されるべきである。しかしながら、十分な理由があれば、新しいIPv6拡張ヘッダは依然として追加されることが可能である。

具体的には、様々なIPv6拡張ヘッダは、一般に、図3に示されるフォーマットである。図3に示されるフォーマットは、現在のIPv6で既に定義された複数の拡張ヘッダ、および将来定義され得る新たに追加されたIPv6拡張ヘッダのフォーマットを示し得る。

図3は、本出願の一実施形態によるIPv6拡張ヘッダのフォーマットの概略図である。概略図は、次のヘッダ（Next Header）のフォーマットを含む。IPv6拡張ヘッダにおけるNext Headerは、IPv6拡張ヘッダの後に特定のタイプの拡張ヘッダがあることを示している。このようにして、複数の拡張ヘッダがサポートされることが可能である。加えて、IPv6拡張ヘッダにおけるNext Headerはまた、上位層プロトコル（upper layer protocol、ULP）を指定することもできる。

たとえば、Next Headerは、ULPが伝送制御プロトコル（transmission control protocol、TCP）またはユーザデータグラムプロトコル（user datagram protocol、UDP）であることを指定し、TCPまたはUDPヘッダおよびパケットがNext Headerに続くことを示している。

基本的なIPv6ヘッダはNext Headerも含み得ることが、理解されるべきである。Next Headerは、基本的なIPv6ヘッダの後に特定のタイプのIPv6拡張ヘッダがあることを示し、上位層プロトコルを指定し、IPv6拡張ヘッダにおけるNext Headerと同様である。詳細は本明細書では繰り返し説明されない。

概略図は、IPv6拡張ヘッダの長さを示すために使用されるヘッダ拡張長（header extension length、Hdr Ext Len）をさらに含む。

概略図は、ヘッダ固有データ（header－specific data）をさらに含む。

以下、図1を参照して、従来技術のBIERパケット転送プロセスについて簡単に説明する。

従来技術におけるBIERパケット転送方法は、新たに追加されたIPv6拡張ヘッダを定義するステップを含み、新たに追加されたIPv6拡張ヘッダは、BIER拡張ヘッダ（BIER extension header）と呼ばれる。BIER拡張ヘッダは、BIERパケットを転送するために必要とされる情報、たとえば先のBitString情報を搬送する。

具体的には、ヘッドノードはマルチキャストデータパケットを受信し、マルチキャストデータパケットは、マルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットのグループアドレスを搬送する。ヘッドノードは、転送予定BIERパケットを生成するために、基本的なIPv6ヘッダおよびBIER拡張ヘッダにマルチキャストデータパケットをカプセル化する。

転送予定BIERパケットの基本的なIPv6ヘッダ内のIPv6送信先アドレス（（IPv6 destination address）は、マルチキャストデータパケットのグループアドレスであり、グループアドレスは、複数のテールノードがグループアドレスに関与することを示すために使用される。具体的には、ヘッドノードは、その送信先アドレスがグループアドレスであるBIERパケットを複製し、複数のテールノードに転送する必要がある。

たとえば、テールノード＃1、テールノード＃2、およびテールノード＃3は各々、テールノード＃1、テールノード＃2、およびテールノード＃3がグループアドレス＃1に関与することを示すために、ヘッドノード＃1にメッセージを送信する。この場合、ヘッドノード＃1は、その送信先アドレスがグループアドレス＃1であるBIERパケットを複製し、テールノード＃1、テールノード＃2、およびテールノード＃3に転送する。

さらに、ヘッドノードは、BIERパケットの最後のBIER拡張ヘッダ内のBitStringなどの情報を問い合わせることにより、BIERパケットが送信される特定のテールノードを決定し、BitString情報およびヘッドノード内に確立されたBIER転送テーブルを問い合わせることにより、これらのテールノードにBIERパケットを送信する方法を決定する。

たとえば、ヘッドノード＃1は、BIERパケットの最後のBIER拡張ヘッダ内のBitStringなどの情報を問い合わせることにより、BIERパケットをテールノード＃1およびテールノード＃2に送信することを決定し、BIER転送テーブルを問い合わせることにより、転送経路を決定する。

具体的には、図1のBIERドメイン1において、BFIR 1およびBFIR 2はビット転送入口ルータであり、BFER 1およびBFER 2はビット転送出口ルータである。BIERドメイン2では、BFIR 3およびBFIR 4はビット転送入口ルータであり、BFER 3およびBFER 4はビット転送出口ルータである。

BIERドメイン1は、IGPドメイン1に属するSub－domain＃1にのみ分割され、BIERドメイン2はIGPドメイン2に属するSub－domain＃2にのみ分割されると仮定される。加えて、Sub－domain＃1におけるBFER 1およびthe BFER 2のBFR－IDはそれぞれBFR－ID 1およびBFR－ID 2であり、Sub－domain＃2におけるBFER 3およびBFER 4のBFR－IDはそれぞれBFR－ID 1およびBFR－ID 2である。

BFIR 1がヘッドノード＃1であり、BFER 1、BFER 2、およびBFER 3がそれぞれテールノード＃1、テールノード＃2、およびテールノード＃3であるとき、BFIR 1は、BFER 1、BFER 2、およびBFER 3から受信したメッセージに基づいて、BFER 1、BFER 2、およびBFER 3が全てグループアドレス＃1に関与すると判定する。この場合、グループアドレス＃1を搬送するマルチキャストデータパケットを受信すると、BFIR 1は、転送予定BIERパケットを取得するためにマルチキャストデータパケット上でパケットカプセル化を実行し、転送予定BIERパケットの基本的なIPv6ヘッダ内のIPv6送信先アドレスはグループアドレス＃1である。

さらに、BFIR 1は、BIERパケットの最後のBIER拡張ヘッダ内のBitString、BIFT－ID、およびSub－domainなどの情報を問い合わせることにより、BIERパケットが、Sub－domain＃1内のBFR－ID 1に対応するBFER 1およびSub－domain＃2内のBFR－ID 1に対応するBFER 3に転送される必要があると判定する。具体的には、BFIR 1は、BIER転送テーブルに基づいて、BIERパケットが、Sub－domain＃1内の中間ノードを通じてBFER 1に転送されると決定する。Sub－domain＃1内の中間ノードおよびエッジノード（BFER 1またはBFER 2）は、BIERパケットをBFER 3に転送する。具体的には、転送経路は転送テーブルに基づいて決定される。

先のBIERパケット転送方式で、BIERパケットを転送するために必要とされるBitStringは、BIER拡張ヘッダ内のIPv6拡張ヘッダにカプセル化される必要があり、IPv6拡張ヘッダは、新たに追加されたIPv6拡張ヘッダであるが、既存のIPv6拡張ヘッダをさらに拡張することを通じて取得されるヘッダではない。RFC 8200には、新たに追加されたIPv6拡張ヘッダは推奨されないが、既存のIPv6拡張ヘッダの使用は推奨されることが、明確に述べられている。IPv6送信先オプションヘッダ（Destination Option Header）をさらに拡張することが推奨され、IPv6 Destination Option HeaderがIPv6拡張ヘッダであることは、具体的に述べられている。

言い換えると、プロトコルによれば、BIERパケット転送方法は、IPv6プロトコルにおいて推奨されない。

IPv6プロトコルの仕様に適合するために、従来技術において、別のBIERパケット転送方法がさらに提案されている。新たに追加されたタイプ・長さ・値（type length value、TLV）は、既存のIPv6拡張ヘッダDestination Option Headerで定義され、BIERタイプ・長さ・値（BIER type length value、BIER TLV）と呼ばれる。BitString情報を含む、BIERパケットを転送するために必要とされる情報は、BIER TLVに記憶される。

さらに、SRv6トンネルを通じてBIERパケットをどのように転送するかが、BIERパケット転送方法においてさらに提案される。以下、ヘッドノード、テールノード、および中間ノードの観点から、BIERパケット転送方法においてSRv6トンネルを通じてBIERパケットをどのように転送するかを簡単に説明する。

まず、ヘッドノードは、セグメントルーティングヘッダ（segment routing header、SRH）の後に、BIERヘッダを含むIPv6 Destination Option Headerを配置する。SRHおよびIPv6 Destination Option Headerはいずれも既存のIPv6拡張ヘッダであり、SRHはIPv6 Destination Option Headerの前に配置される。

次に、SRHトンネルエンドポイントでは、IPv6ヘッダ内の特定のIPv6送信先アドレスおよび所定の動作に基づいて、エンドポイントは、IPヘッダからSRHを削除し、SRHに含まれるマルチキャストIPv6アドレスをIPv6ヘッダ内のIPv6送信先アドレスにコピーする役割を果たす。SRHトンネルエンドポイントは、中間ノードと呼ばれてもよく、パケットを転送するためのルータである。

ユニキャストSRv6技術では、パケットは、SRHを搬送してもよく、またはSRv6トンネルを通じて転送されるときにはSRHを搬送しなくてもよいことが、理解されるべきである。しかしながら、BIERパケット転送方法では、パケットは、SRv6トンネルを通じて転送されるときにSRHを確実に搬送し、グループアドレスがSRH内に配置される。これに基づいて、利点は以下の通りである。

SRv6トンネルエンドポイントは、マルチキャストグループアドレスに1つずつマッピングされる必要はないかも知れない。具体的には、トンネルエンドポイントがIPv6送信先アドレスおよび所定の動作に対応するとき、特定のマルチキャストグループアドレスを考慮する必要はないが、グループアドレスは、パケットが受信された後にIPv6ヘッダ内のIPv6送信先アドレスにコピーされる。

次に、ヘッドノードは、IPv6送信先アドレスに基づいてBIER IPv6パケットを転送する。具体的には、ヘッドノードは、IPv6ヘッダの後にDestination Option Header内のBIERヘッダを読み取り、BIERヘッダ内のBitStringなどの情報に基づいて、BIERパケットを複製して1つ以上のインターフェースに送信する。

BIERパケット転送方法がビットインデックス明示的レプリケーションBIER（multicast virtual private network over BIER、multicast VPN over BIER）を介してマルチキャスト仮想プライベートネットワークに適用されるとき、既存のメカニズムが依然として使用される。既存のメカニズムの鍵は、テールノードが、VpnLabelに基づいて、テールノードに対応し、受信したパケットが属する、特定の仮想ルーティングおよび転送（virtual routing forwarding、VRF）を決定する必要があるということである。VRFの概念は仮想プライベートネットワーク（virtual private network、VPN）の概念に対応し、各VPNは1つのVRFに対応する。MVPNはマルチキャスト向けのVPNを意味する。したがって、既存のメカニズムは、MVPN over BIERシナリオで使用される必要がある。既存のメカニズムは、実際には、パケットに基づいて、パケットが属する特定のVRFを知る。

たとえば、BIERヘッダプロトコルフィールド2（Proto 2）は、BIERヘッダの後のパケットが仮想プライベートネットワークラベル＋インターネットプロトコル（virtual private network＋internet protocol、VpnLabel＋IP）パケットであることを示すために使用される。

これは、BIERパケットのIPv6ヘッダ全体およびDestination Option Headerの後のパケットが、最初に全長4バイトのフィールドであり、4バイトは20－bit仮想プライベートネットワークラベル（virtual private network label、VpnLabel）フィールドを含み、IPv4またはIPv6パケットが4バイトに続くことを意味する。

これはまた、パケットを受信した後、テールノードが、パケットのBIERヘッダ内のVpnLabel値および他のフィールド（具体的には、2つのフィールド：図2に示されるBIERヘッダ内のBIFT－IDおよびBFIR－ID）に基づいて、テールノードに対応し、パケットが属する特定の仮想ルーティングおよび転送（virtual routing and forwarding、VRF）を判定する必要があり、その後、VpnLabelフィールドおよびVRFの後のIPv4またはIPv6ヘッダ内の送信元IPまたは送信先IPに基づいて、VRFに対応し、パケットが複製および送信される必要がある、特定のインターフェースを決定することができる。

パケット転送方法では、テールノードに対応し、パケットが属する特定のVRFは、BIERヘッダの後のVpnLabelに基づいて決定され、その後、MVPN over BIER転送が実行される。パケット転送方法の特徴は、以下の通りである。

VpnLabelがBIERヘッダに続くことを示すために、BIERヘッダ内でProto値（たとえば、2）が使用され、その後、VpnLabelに基づいて、パケットが属する特定のVRFが決定される。具体的には、VpnLabelはBIERヘッダに続き、プライベートIPパケットはVpnLabelに続く。テールノードがパケットを受信した後、テールノードはまず、BIERヘッダ内のBIFT－IDに基づいて、パケットが属する特定のSub－domainを知り、その後、Sub－domainおよびBIERヘッダ内のBFIR－IDに基づいて、パケットがもたらされた特定のヘッドノードを知り、最後に、VpnLabel情報に基づいて、テールノードに対応し、パケットが対応する、特定のVRFを決定する。

パケット内のVpnLabelは、ヘッドノードによって割り当てられる。ヘッドノードは、VpnLabel情報を割り当て、制御プレーンを通じてVpnLabel情報をテールノードに伝送して、テールノードが、ヘッドノードおよびヘッドノードによって割り当てられたVpnLabelに基づいて、テールノードに対応し、パケットが対応するVRFを知ることができるようにする。この場合、ヘッドノードはVpnLabelを割り当てる必要があり、ヘッドノードによってカプセル化されたパケットは、ヘッドノードに関する情報およびヘッドノードによって割り当てられたVpnLabel情報を確実に含む必要がある。

結論として、制御プレーン上では、ヘッドノードはテールノードに、VpnLabel、BFIR－ID、およびSub－domainの間の対応を通知する必要があり、テールノードは対応を記憶する。次いで、転送プレーン上で、ヘッドノードはデータパケットを送信し、テールノードは、対応に基づいて、テールノードに対応し、パケットが対応する、特定のVRFを決定する。

具体的な原理は、以下の通りである。制御プレーン上で、同じSub－domainおよび異なるBFR－ID（ヘッドノードのBFR－IDはBFIR－IDと呼ばれる）が、multicast VPNのヘッドノードおよびmulticast VPNのテールノード向けに構成される必要がある。

ヘッドノードは、VpnLabel値を生成する必要があり、次いで3つの情報（Sub－domain、BFR－ID、およびVpnLabel）およびVPN識別子情報をテールノードに送信する。次いで、テールノードは、メッセージ内のVPN識別子上にテールノード内のVRFをマッピングし、テールノード内のSub－domain、BFIR－ID、VpnLabel、およびVRFの間の対応を確立して、パケットがテールノードに到着したときに、テールノードがパケット内のBIFT－IDに基づいてSub－domainを取得し、次いでパケット内のBFIR－IDおよびVpnLabelに基づいてパケットが属する特定のVRFを決定することができるようにする。

Sub－domain、BFR－ID、およびVpnLabelの3つのフィールドに基づいてパケットが属する特定のVRFを決定することの欠点は、以下の通りである。multicast VPN内のヘッドノードの構成およびこれに関する情報を生成するプロセスが複雑であり、multicast VPN内のテールノードによって転送テーブルを確立するプロセスが複雑であり、パケットはVpnLabelを搬送する必要があり、結果的に、パケット転送性能が低下する。

BIERパケット転送方法では、後続のBIERペイロードのタイプを識別し、BIERペイロードが属するVRFインスタンスを区別するために、既存のBIERヘッダ内のProtoフィールドが、最初に使用される必要がある。

たとえば、Proto 2は、BIERペイロードのタイプが、上流ノードによって割り当てられたVpnLabelで始まるパケットであることを示している。VpnLabelは、IPv4パケットまたはIPv6パケットが属する特定のVRFをさらに区別するために使用される。VpnLabelは、区別を完了するために、BIERヘッダ内の他のフィールドとともに使用される必要がある。たとえば、BIERヘッダ内のBIFT－IDおよびBFIR－IDならびにVpnLabelは、区別を完了するために一緒に使用される。理由は以下の通りである。

VpnLabelは上流ノードによって割り当てられ、ヘッドノードに関する情報は、BFIR－IDおよびSub－domainを使用して完了される必要がある（BFIR－IDは、特定のSub－domainでのみ意味がある）。

たとえば、ヘッドノードは、ボーダーゲートウェイプロトコル（border gateway protocol、BGP）を使用してテールノードにメッセージを送信し、メッセージは、ヘッドノードのVRF識別子、ヘッドノードのBFIR－ID、Sub－domain、およびヘッドノードによって割り当てられ、VRFに対応するVpnLabelを含む。具体的には、ヘッドノードのVRF識別子は、BGP－MVPNアドレスファミリ内のルーティングテーブル（Route Target）識別子である。

テールノードは、テールノードであってSub－domain、BFIR－ID、およびVpnLabelが対応する特定のVRFを知るために、ヘッドノードによって送信されたメッセージ内のVRF識別子を、メッセージが属する特定のVRFを判定するようにテールノード上で構成されたVRF識別子と照合し、次いで受信したパケットのBIERヘッダ内のBIFT－IDに基づいてSub－domainを知り、パケットのBIERヘッダ内のBFIR－IDおよびパケット内のVpnLabelフィールドに基づいて、パケットが属する特定のVRFを判定する。

この方法では、パケットが属する特定のVRFは、同じBIER Sub－domain内になるようにヘッドノードおよびテールノードを構成し、ヘッドノード上のSub－domain内の一意のBFIR－IDを構成し、ヘッドノードによってVpnLabelを割り当てることによって、知られる必要がある。加えて、パケットのVRFを識別するための転送テーブルがテールノード上で確率されることが可能なように、3つの情報およびVRF識別子（たとえば、BGP－MVPNプロトコルにおけるroute target拡張コミュニティ属性）が各テールノードに送信される。

方法の欠点は、以下の通りである。

1．ヘッドノードは、VpnLabelを割り当て、パケット内のVpnLabelをカプセル化する必要があり、VpnLabelは4バイトを占有する。SRv6－VPNはMPLSラベルを含まないので、IPv6／SRv6ラベルとマルチプロトコルラベル切り換え（multiple protocol label switching、MPLS）ラベルとの組合せのカプセル化形態は、既存のSRv6－VPN技術的ソリューションのカプセル化形態とは大きく異なる。

2．BFIR－IDは、ヘッドノード上で構成される必要がある。ヘッドノードおよびテールノードは同じBIER Sub－domain内で構成される必要があり、Sub－domain内の一意のBFIR－IDはヘッドノード上で構成される必要があるので、ドメイン間BIER IPv6マルチキャストを内部で展開することは特に困難である。BIER Sub－domainは通常、ドメイン内の一意のBFIR－IDが容易に構成されることが可能なように、IGPドメイン内にある。同じSub－domain内にあり、IGPドメイン間で異なるBRF－IDを有するようにヘッドノードおよびテールノードを構成する際の困難の1つは、構成の矛盾の発生をどのようにして回避するかである。

先のBIERパケット転送方法に存在する問題を解決するために、本出願は、パケット送信性能を改善するための、パケット転送方法、パケット送信装置、およびパケット受信装置を提供する。

図4を参照して、以下で、本出願の一実施形態で提供されるパケット転送方法を詳細に説明する。

本出願のこの実施形態で提供されるパケット転送方法は、図1に示されるシナリオに適用可能である。具体的には、パケット転送方法は、ビットインデックス明示的レプリケーションBIERにおけるマルチキャスト仮想プライベートネットワークmulticast VPNに適用される。

以下、ノード間の相互作用の観点から、本出願のこの実施形態で提供されるパケット転送方法について詳細に説明する。

図4は、本出願の一実施形態によるパケット転送方法の概略図である。概略図は、S110からS180の8つのステップを含む。8つのステップは、以下で詳細に記載される。

S110：第1のノードがVPN情報を構成する。

第1のノードは、第1の仮想プライベートネットワークVPNの第1の識別子および第1のインターネットプロトコルバージョン6 IPv6アドレスを構成し、第1のVPNは複数のVPNのうちのいずれか1つであり、第1のIPv6アドレスは第1の識別子に対応する。

第1のノードが、マルチキャストデータパケットを受信し、マルチキャストデータパケットをカプセル化するノードであることは、理解されるべきである。たとえば、図1に示されるBFIR 1からBFIR 4は各々、本出願では、第1のノード、ヘッドノード、第1のデバイス、ヘッドデバイス、第1のネットワーク要素、送信ネットワーク要素などと呼ばれ得る。

multicast VPNは、マルチキャストが展開されるVPNを指し、VPNはVRFと一対一対応していることは、留意されるべきである。具体的には、第1のノードが第1のVPNの第1の識別子を構成することはまた、第1のノードが第1のVPNに対応する第1のVRFの識別子を構成することも意味し得る。以下の説明では、第1のVRFの識別子は第1の識別子である。この場合、第1のノードは第1のIPv6アドレスを構成し、第1のVPNに対応する第1のVRFの識別子は、第1のノードが複数のVPNのために異なるVRF識別子および異なるIPv6アドレスを構成する必要があることを意味する。

本出願のこの実施形態では、第1のノードによって、任意のVPNのVRF識別子、およびIPv6アドレスを構成する観点から、説明が提供される。これは一般的に重要である。加えて、第1のVPNのために第1のノードによって構成された第1のIPv6アドレスは、第1のノードの第1のIPv6アドレスと呼ばれ、ネットワーク全体で一意のIPv6アドレスである。

たとえば、事業者のネットワーク上に3つのサイトA、B、およびCが確立され、複数の顧客をサポートすることができる場合、各顧客は、3つのサイトの各々に顧客のネットワークを有する。2人の顧客がおり、具体的には1人の顧客が3つのサイトA、B、およびCの各々に顧客のネットワークを有し、他方の顧客もまた3つのサイトA、B、およびCの各々に顧客のネットワークを有すると仮定すると、2つのVPNがあり、各VPNは3つのサイトA、B、およびCを有する。次に、サイトAにおいて、VRF 1およびIPv6 Addr 1の識別子がVPN 1に割り当てられる必要があり、VRF 2およびIPv6 Addr 2の識別子がVPN 2に割り当てられる必要がある。IPv6 AddrはIPv6アドレスである。

第1のIPv6アドレスが第1のVRFの識別子に対応するということは、複数のIPv6アドレスが複数のVRF識別子と一対一対応にあることを意味することが、留意されるべきである。VRFを識別するためにVRF識別子が使用されるので、複数のIPv6アドレスが複数のVRF識別子と一対一対応しているということはまた、複数のIPv6アドレスが複数のVRFと一対一対応しており、異なるVRFが異なるIPv6アドレスと一対一対応していることも意味し得る。言い換えると第1のノードは、第1のノードの異なるVRFに対応するIPv6アドレスを決定している。

第1のノードは、事前設定構成情報をさらに構成し得る。たとえば、第1のノードはパケット転送経路を構成し得る。具体的には、詳細は以下の通りである。

事前設定構成情報は、プロキシノードのIPv6アドレスと第2のノードのIPv6アドレスとの間の対応を含み、パケットがプロキシノードを通じて第2のノードに転送されることを示す。プロキシノードのIPv6アドレスと第2のノードのIPv6アドレスとの間の対応は、プロキシノードのIPv6アドレスと第2のノードのIPv6アドレスとの間の一対一対応、またはプロキシノードのIPv6アドレスと第2のノードのIPv6アドレスとの間の一対多対応であり得る。プロキシノードがBIERパケットを第2のノードに転送し得ることは、理解され得る。

第2のノードがBIERパケットを受信するノードであることは、理解されるべきである。たとえば、図1に示されるBFER 1からBFER 4は、各々、本出願では、第2のノード、テールノード、葉ノード、第2のデバイス、テールデバイス、第2のネットワーク要素、受信ネットワーク要素などと呼ばれ得る。

あるいは、事前設定構成情報は、第2のノードのIPv6アドレス、指定ノードのIPv6アドレス、およびプロキシノードのIPv6アドレスの間の対応を含み、BIERパケットが、指定ノードを通じてプロキシノードに転送され、次いでプロキシノードを通じて第2のノードに転送されることを示す。

言い換えると、本出願では、第1のノードは、パケット転送経路を示すために、制御プレーン上で関連する事前設定構成情報を構成し得る。

S120：第2のノードがVPN情報を構成する。

第2のノードは、第1の仮想プライベートネットワークVPNの第2の識別子、第2のインターネットプロトコルバージョン6 IPv6アドレス、および第2のノードの識別子を構成し、第1のVPNは、複数のVPNのうちのいずれか1つである。

上述のように、VPNはVRFと一対一対応していることは留意されるべきである。具体的には、第2のノードが第1のVPNの第2の識別子を構成することはまた、第2のノードが第1のVPNに対応する第2のVRFの識別子を構成することも意味し得る。以下の説明では、第2のVRFの識別子は第2の識別子である。

第1のVPNに関する、S110で第1のノードによって構成された情報を参照すると、パケット転送の前に、第1のノードおよび第2のノードはそれぞれ、複数のVPNについて、複数のVPNに対応するVRF識別子およびIPv6アドレスを構成することが、理解され得る。

たとえば、合計で2つのVPN（VPN＃1およびVPN＃2）がある。第1のノードは、VRF＃1の識別子、およびVPN＃1のIPv6アドレス＃1を構成し、IPv6アドレス＃1はVRF＃1の識別子に対応する。第2のノードは、VRF＃1’の識別子、およびVPN＃1のIPv6アドレス＃1’を構成し、IPv6アドレス＃1’は、任意選択的にVRF＃1’の識別子に対応する。第1のノードは、VRF＃2の識別子、およびVPN＃2のIPv6アドレス＃2を構成し、IPv6アドレス＃2はVRF＃2に対応する。第2のノードは、VRF＃2’の識別子、およびVPN＃2のIPv6アドレス＃2’を構成し、IPv6アドレス＃2’は、任意選択的にVRF＃2’の識別子に対応する。

任意選択的に、いくつかの実施形態では、第2のノードの識別子は、先のBFR－ID、すなわち第2のノードが属するIGP内で第2のノード向けに構成されたBFR－IDであってもよい。さらに、第2のノードはパケットを脱カプセル化するノードであるので、第2のノード向けに構成されたBFR－IDはBFER－IDである。

任意選択的に、いくつかの実施形態では、第2のノードの識別子は、BFR－IDとの一対一対応を満たす情報であってもよい。言い換えると、BFR－IDは、情報および対応に基づいて、一意に決定されることが可能である。あるいは、第2のノードの識別子は、第2のノードを識別することが可能なその他の情報であってもよい。詳細は本明細書には記載されない。

S130：第1のノードが第1の指示メッセージを第2のノードに送信する。

第1の指示メッセージは、第1のIPv6アドレスと第2の識別子との間の対応を確立するように第2のノードに指示するために使用され、第1の指示メッセージは第1のVPNの第1の識別子および第1のIPv6アドレスを含み、第2の識別子は、第2のノードのものであって第1の識別子との事前設定対応を満たす識別子である。

第2のノードは、パケットが受信された後、VRFに対応し、パケットが送信されるローカルインターフェースを決定するために、第1のIPv6アドレスと第2の識別子との間の対応を確立することが、理解されるべきである。したがって、第1のIPv6アドレスと第2のVRFの識別子との間の一対一対応は第1のIPv6アドレスと第2のVRFとの間の一対一対応として理解され得る。加えて、第1のIPv6アドレスと第2の識別子との間の対応は、一対一対応である。具体的には、一意の第2の識別子は、第1のIPv6アドレスに基づいて知られることが可能である。

第2の識別子および第1の識別子は、以下の可能なケースのいずれか1つにおいて事前設定対応を満たすことができる。

可能なケース1：第2のVRFは、第2のノードに対応し、第1のVRFと同じ識別子を有するVRFである。たとえば、第1のVRFの識別子が「1：1」である場合、第2のVRFは、第2のノードに対応し、その識別子が「1：1」であるVRFである。

可能なケース2：第2のVRFは、第2のノードに対応し、第1のVRFの識別子と包含関係にあるVRFである。たとえば、第1のVRFの識別子が「1：1」である場合、第2のVRFは、第2のノードに対応し、その識別子が「1：1および1：2」であるVRFである。識別子が包含関係を満たすということは、第2のVRFの識別子が複数の識別子を含む識別子リストであり、第1のVRFの識別子が第2のVRFに対応する識別子リストに属する識別子であるか、または第1のVRFの識別子が別の識別子リストであり、識別子リストが第2のVRFの識別子リストの一部または全てであることを意味する。

あるいは、第2のVRFの識別子および第1のVRFの識別子は、別の事前設定対応を有する。

本出願のこの実施形態では、第1の指示メッセージで搬送される第1の識別子は、第2の識別子を決定するために使用され得ることが、理解されるべきである。具体的には、第2の識別子は、事前設定対応を使用して決定される。これは本出願では限定されない。

具体的には、第1の指示メッセージを受信した後、第2のノードが、第1の指示メッセージおよびローカルで構成された情報に基づいて第1のIPv6アドレスと第2のVRFとの間の対応を決定することは、以下を含む。

まず、第2のノードは、第1のVRFであって第1の指示メッセージで搬送される識別子、および第1のVRFの識別子と第2のVRFの識別子との間のローカルで記憶された事前設定対応に基づいて、第2のVRFを決定する。たとえば、第2のノードは、第2のVRFとして、第2のノードに対応し、第1のVRFと同じ識別子を有するVRFを決定するか、または第2のVRFとして、第2のノードに対応し、そのVRF識別子が第1のVRFの識別子を含むVRFを決定し得る。第1のVRFの識別子と第2のVRFの識別子との間の事前設定対応は、システムによって事前設定されてもよく、または第1のノードおよび第2のノードによって合意されてもよいことが、理解されるべきである。これは本出願では限定されない。本出願では、第1のVRFの識別子を知った後に、第2のノードが第2のノードからの第2のVRFを決定できるケースのみが保証される必要がある。

次に、第1の指示メッセージは第1のIPv6アドレスをさらに搬送し、第1のIPv6アドレスは、第1のノード側の第1のVRFの識別子に対応する。第2のVRFを決定した後、第2のノードは、第1のIPv6アドレスと第2のVRFとの間の対応をさらに決定することができる。

任意選択的に、いくつかの実施形態では、第1の指示メッセージは、BGP－MVPNルート（BGP－MVPN route）メッセージである。第1のIPv6アドレスおよび第1の識別子は、BGP－MVPN routeメッセージにカプセル化される。

具体的には、第1のIPv6アドレスおよび第1の識別子がBGP－MVPN routeメッセージにカプセル化されることは、第1の識別子が＜route target拡張コミュニティ属性＞であり、第1のIPv6アドレスが＜第1のノードAddr 1＞であることであり得る。ここで、＜第1のノードAddr 1＞は、BGP－MVPN routeメッセージのMP＿REACH＿NLRI属性、PTA属性、または新たに追加された別の属性で搬送され得る。

任意選択的に、他のいくつかの実施形態では、第1の指示メッセージは、BGP－VPNルート（BGP－VPN route）メッセージであり得る。第1のIPv6アドレスおよび第1の識別子は、BGP－VPN routeメッセージにカプセル化される。

具体的には、第1のIPv6アドレスおよび第1のVRFに関する情報がBGP－VPN routeメッセージにカプセル化されることは、第1の識別子が＜route target拡張コミュニティ属性＞であり、第1のIPv6アドレスが＜第1のノードAddr 1＞であることであり得る。ここで、＜第1のノードAddr 1＞は、BGP－VPN routeメッセージのBGP－prefix SID属性内のSRv6－VPN SID TLVで搬送され得る。

任意選択的に、他のいくつかの実施形態では、第1の指示メッセージは、BGP イーサネット仮想プライベートネットワークルート（BGP－Ethernet virtual private network route、BGP－EVPN route）メッセージである。第1のIPv6アドレスおよび第1の識別子は、BGP－EVPN routeメッセージにカプセル化される。

具体的には、第1のIPv6アドレスおよび第1の識別子がBGP－EVPN routeメッセージにカプセル化されることは、第1の識別子が＜route target拡張コミュニティ属性＞であり、第1のIPv6アドレスが＜第1のノードAddr 1＞であることであり得る。ここで、＜第1のノードAddr 1＞は、BGP－EVPN routeメッセージの属性で搬送され得る。

あるいは、第1の指示メッセージは別のメッセージであってもよい。詳細は本明細書には記載されない。

図4がS140をさらに含む必要があることは、理解されるべきである。具体的には、第2のノードが第2の指示メッセージを第1のノードに送信する。

第2の指示メッセージは、第2のノードがマルチキャストデータパケットの受信機であることを示すために使用され、第2の指示メッセージは、マルチキャスト参加パケットとして理解され得る。第2の指示メッセージは、第2のノードのIPv6アドレスを含み、第2のノードのIPv6アドレスおよび第1のノードのローカル事前設定構成情報は、パケット転送経路を決定するために使用されることが可能である。

第2の指示メッセージは、送信元アドレス、グループアドレス、および第2のノードの識別子をさらに含む。送信元アドレスは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、グループアドレスは、第2のノードが参加するマルチキャストグループのアドレスである。

任意選択的に、いくつかの実施形態では、第1のノードが第1のIGPドメインに属し、第2のノードが第2のIGPドメインに属し、第1のIGPドメインが第2のIGPドメインとは異なるとき、第2の指示メッセージは、プロキシノードのIPv6アドレスをさらに含んでもよい。たとえば、プロキシノードは、第2のIGPドメインに属する。

プロキシノードが、第2のIGPドメイン内のエッジノードまたは中間ノードであり得るか、またはプロキシデバイス、パケット転送ノードなどと呼ばれ得ることは、理解されるべきである。

この場合、第2の指示メッセージは、転送予定BIERパケットがプロキシノードを通じて第2のノードに転送されることを示すことができる。

任意選択的に、いくつかの実施形態では、第1のノードが第1のIGPドメインに属し、第2のノードが第2のIGPドメインに属し、第1のIGPドメインが第2のIGPドメインとは異なるとき、第2の指示メッセージは、S120で説明された第2のIPv6アドレスをさらに含む。

この場合、第2の指示メッセージおよび第1のノード上で構成された事前設定構成情報は、転送予定BIERパケットがプロキシノードを通じてテールノードに転送されることを示すことができ、事前設定構成情報は、第2のIPv6アドレスとプロキシノードのIPv6アドレスとの間の対応を含む。

任意選択的に、いくつかの実施形態では、事前設定構成情報は、転送予定BIERパケットが、指定ノードを通過した後にプロキシノードに到着する必要があることを、さらに示し得る。指定ノードは、BIERパケットがプロキシノードに到着する前に通過する必要があるノードである。たとえば、指定ノードは、第1のIGPドメインのエッジノードまたは中間ノードであり得る。

本出願における第1のノード、第2のノード、プロキシノード、および指定ノードなどの名前は、区別を容易にするために定義されており、本出願に対するいかなる限定も構成しないことは、理解されるべきである。既存のプロトコルまたは将来のプロトコルにおいて先の名前に置き換わるために他の名前が使用される可能性は、本出願において排除されない。

任意選択的に、いくつかの実施形態では、第2の指示メッセージがBGP－MVPNメッセージである。

S110からS140は主に、第1のノードと第2のノードとの間の情報交換、ならびに制御プレーン上で第2のノードによって確立された対応について記載している。以下では、図4のS150からS180を参照して詳細に、BIERパケットをカプセル化し、BIERパケットを転送し、BIERパケットを脱カプセル化するプロセスについて説明する。

S150：第1のノードがマルチキャストデータパケットを受信する。

マルチキャストデータパケットは、マルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットのグループアドレスを搬送する。具体的には、第1のノードは、マルチキャストデータパケットが受信されるインターフェースに基づいて、マルチキャストデータパケットが属するVRFを決定することができる。明確な説明のため、および制御プレーンの先の制御プレーンとの整合性を維持するために、マルチキャストデータパケットは、第1のVRFに属すると仮定される。言い換えると、マルチキャストデータパケットは第1のVPNに属する。

S160：第1のノードがマルチキャストデータパケットをカプセル化する。

まず、第1のノードは、マルチキャストデータパケットが第1のVPNに属するS150ならびに第1のVPNの第1の識別子および第1のIPv6アドレスが構成されるS110に基づいて、マルチキャストデータパケットが第1のIPv6アドレスに対応すると判定する。第1の識別子は第1のIPv6アドレスに対応するので、第1のノードは第1のIPv6アドレスを取得することができる。

次いで、第1のノードは、転送予定BIERパケットを取得するために、取得した第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化する。転送予定BIERパケットは、外部IPv6ヘッダ、第2のノードを示す事前設定情報、内部IPv6またはIPv4ヘッダ、およびペイロードを含む。第2のノードを示す事前設定情報は、先のBitString情報であってもよく、第2のノードは、BitString情報に基づいて決定されることが可能である。

以下では、図5（a）から図5（c）を参照して詳細に、第1のノードがどのようにしてマルチキャストデータパケットをカプセル化するかを説明する。図5（a）から図5（c）は各々、本出願の一実施形態によるパケットフォーマットの概略図である。

第1のノードが、S140で第2のノードによって送信された受信した第2の指示メッセージに基づいて、マルチキャストパケットが第2のノードに送信される必要があると判定できることは、理解されるべきである。マルチキャスト送信元のものであってマルチキャストデータパケットに含まれるアドレスは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、マルチキャストグループのものであってマルチキャストデータパケットに含まれるアドレスは、第2のノードが参加するマルチキャストグループのアドレスであり、第2のノードによって送信される第2の指示メッセージは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスと、第2のノードが参加するマルチキャストグループのアドレスとを含む。したがって、第1のノードは、マルチキャストパケットが第2のノードに送信される必要があると判定し、受信したマルチキャストパケットをさらにカプセル化する。

具体的には、第1のノードがマルチキャストデータパケットをカプセル化することは、以下のいくつかのケースを含む。

ケース1：

第1のノードおよび第2のノードは、異なるIGPドメインに属する。たとえば、図4のS140で説明されたように、第1のノードは第1のIGPドメインに属し、第2のノードは第2のIGPドメインに属し、第1のIGPドメインは第2のIGPドメインとは異なる。第1のノードによってマルチキャストデータパケットをカプセル化することによって取得されたBIERパケットは、プロキシノードを通じて第2のノードに転送される必要がある。

この場合、カプセル化を通じて第1のノードによって取得されたBIERパケットの特定のパケットフォーマットが図5（a）に示されている。概略図は、2つの部分（図5（a）に示されるノード部分およびパケットフォーマット部分）を含む。以下では、図5（a）を参照して詳細に、転送予定BIERパケットを取得するために第1のノードがどのようにしてマルチキャストデータパケットをカプセル化するかを説明する。

まず、第1のノードは、マルチキャスト送信元からマルチキャストデータパケットを受信する。マルチキャストデータパケットのフォーマット（図5（a）のフォーマット1として示される）は、IPv6またはIPv4ヘッダ（マルチキャストデータパケットがIPv6パケットである場合、フォーマットはIPv6ヘッダを含むか、またはマルチキャストデータパケットがIPv4パケットである場合、フォーマットはIPv4ヘッダを含む）、マルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットの送信先アドレス、そして最後にパケットペイロードを含み、マルチキャストデータパケットの送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、マルチキャストデータパケットの送信先アドレスはマルチキャストデータパケットのグループアドレスである。

次に、第1のノードが転送予定BIERパケットを取得するためにマルチキャストデータパケットをカプセル化することは、具体的には以下を含む。

第1のノードは、マルチキャストデータパケットの外層でIPv6ヘッダをカプセル化し、IPv6ヘッダは、BIERパケットの最も外側のIPv6ヘッダであり、外部IPv6ヘッダと呼ばれ得る。以下の説明では、第1のノードがマルチキャストデータパケットの外層でIPv6ヘッダをカプセル化することは、第1のノードが外部IPv6ヘッダをカプセル化することを意味する。

外部IPv6ヘッダで搬送される送信元アドレスは、S110における第1のIPv6アドレスであり、送信先アドレスは、プロキシノードのIPv6アドレスである。プロキシノードのIPv6アドレスは、第2のノードによって第1のノードに送信される第2の指示メッセージで搬送されてもよく、または第1のノードによってローカルで構成されてもよい。詳細はS140に記載されており、したがって本明細書では再度記載されない。

第1のノードは、マルチキャストデータパケットの外層でIPv6拡張ヘッダDestination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダは第2のノードを示す事前設定情報を搬送する。あるいは、第1のノードは、マルチキャストデータパケットの外層でBIER拡張ヘッダをカプセル化し、BIER拡張ヘッダは、第2のノードを示す事前設定情報を搬送する。

第1のノードがIPv6拡張ヘッダDestination Option Headerをカプセル化し、IPv6 Destination Option HeaderがBIERヘッダを含むということは、新しいIPv6拡張ヘッダが定義されず、IPv6 Destination Option Headerがさらに拡張されることを意味し得る。BIER拡張ヘッダをカプセル化することは、新しいIPv6拡張ヘッダを定義し、BIERパケットによって必要とされる情報を搬送するために新しいIPv6拡張ヘッダを使用することとして理解され得る。言い換えると、本出願のこの実施形態では、BitString情報などをどのようにしてカプセル化するかは限定されない。既存の拡張ヘッダがさらに拡張されてもよく、または新しい拡張ヘッダが定義されてもよい。

第1のノードは内部IPv6またはIPv4ヘッダをカプセル化し、内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスアドレスであり、内部IPv6またはIPv4ヘッダで搬送される送信先アドレスはマルチキャストデータパケットのグループアドレスである。

最後に、第1のノードは、転送予定BIERパケットのペイロードとしてマルチキャストデータパケットのペイロードを使用し、言い換えると、外部IPv6パケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。

具体的には、第1のノードは、マルチキャストデータパケットをカプセル化するプロセスにおいて、仮想プライベートネットワークラベルVpnLabelをカプセル化する必要がない。具体的には、従来技術のBIERパケット転送方法と比較すると、本出願では、制御プレーン上で、第1のノードは、VpnLabelフィールドを構成または生成する必要がなく、VpnLabelフィールドに関する情報を第2のノードに送信する。さらに、第1のノードは、転送プレーン上でVpnLabelフィールドをカプセル化する必要がない。

ケース1のマルチキャストデータパケットをカプセル化するプロセスにおいて、第1のノードが、内部IPv6またはIPv4ヘッダおよび外部IPv6パケットのペイロードをカプセル化することは、理解されるべきである。図5（a）のフォーマット1および図5（a）のフォーマット2を比較することにより、カプセル化は実際に、受信したマルチキャストデータパケットを転送予定BIERパケットにカプセル化していることがわかる。さらに、第1のノードは、マルチキャストデータパケットの外層で、外部IPv6ヘッダおよびIPv6拡張ヘッダまたはBIER拡張ヘッダをカプセル化する。

具体的には、第1のノードは、マルチキャストデータパケットをカプセル化し、あるフォーマット（図5（a）のフォーマット2として示される）の転送予定BIERパケットを取得する。プロキシノードに到着する前に、転送予定BIERパケットは、第1のIGPドメイン内の別のノードを通じてさらに転送され得る。しかしながら、ケース1では、転送予定BIERパケットが第1のIGPドメイン内の中間ノードまたはエッジノードを通じて転送されるとき、パケットフォーマットは変化しない。図5（a）の第1のノード、中間ノード、およびエッジノードの間の破線で示されるように、パケットが中間ノードおよびエッジノードを通じて転送されるとき、パケットフォーマットは、第1のノードによって実行されるカプセル化の後に得られるパケットフォーマットである（図5（a）のパケットのフォーマット2を指す破線は、パケットフォーマットがフォーマット2として示される形態のままであることを示す）。

さらに、ケース1では、BIERパケットを受信した後、プロキシノードは、BIERパケットの外部IPv6ヘッダの送信先アドレスを、ユニキャストアドレス（図5（a）に示されるフォーマット2におけるプロキシノードのIPv6アドレス）からマルチキャストグループアドレスに変更する必要がある。マルチキャストグループアドレスの概念は、マルチキャストデータパケットのグループアドレスとは異なっており、以下で簡単に説明される。

マルチキャストグループアドレスは、事業者のネットワーク向けに計画されており、マルチキャストデータパケットのグループアドレスは、顧客専用である。具体的には、マルチキャストグループアドレスはIPv6アドレスであり、マルチキャストデータパケットのグループアドレスは、IPv6またはIPv4アドレスであり得る。

ケース2：

第1のノードおよび第2のノードは、異なるIGPドメインに属する。たとえば、図4のS140で説明されたように、第1のノードは第1のIGPドメインに属し、第2のノードは第2のIGPドメインに属し、第1のIGPドメインは第2のIGPドメインとは異なる。第1のノードによってマルチキャストデータパケットをカプセル化することによって取得されたBIERパケットは、プロキシノードおよび指定ノードを通じて第2のノードに転送される必要がある。図4のS140における指定ノードは、第1のIGPドメインに属する。

この場合、カプセル化を通じて第1のノードによって取得されたBIERパケットの特定のパケットフォーマットが図5（b）に示されている。概略図は、2つの部分（図5（b）に示されるノード部分およびパケットフォーマット部分）を含む。以下では、図5（b）を参照して詳細に、転送予定BIERパケットを取得するために第1のノードがどのようにしてマルチキャストデータパケットをカプセル化するかを説明する。

まず、第1のノードは、マルチキャスト送信元からマルチキャストデータパケットを受信する。マルチキャストデータパケットのフォーマット（図5（b）のフォーマット1として示される）は、IPv6またはIPv4ヘッダ（マルチキャストデータパケットがIPv6パケットである場合、フォーマットはIPv6ヘッダを含むか、またはマルチキャストデータパケットがIPv4パケットである場合、フォーマットはIPv4ヘッダを含む）、マルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットの送信先アドレス、そして最後にパケットペイロードを含み、マルチキャストデータパケットの送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、マルチキャストデータパケットの送信先アドレスはマルチキャストデータパケットのグループアドレスである。

次に、第1のノードが転送予定BIERパケットを取得するためにマルチキャストデータパケットをカプセル化することは、具体的には以下を含む。

第1のノードは、SRHの外層で外部IPv6ヘッダをカプセル化し、外部IPv6ヘッダで搬送される送信元アドレスはS110の第1のIPv6アドレスであり、外部IPv6ヘッダで搬送される送信先アドレスは指定ノードのIPv6アドレスである。指定ノードのIPv6アドレス情報は、第1のノードによって構成された事前設定構成情報によって示される。

第1のノードは、マルチキャストデータパケットの外層でSRHをカプセル化し、SRHで搬送されるアドレスリスト（SID list、SL）は、指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレスを含む。

SRHで搬送されるアドレスリストは、指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレス以外のアドレスをさらに含み得ることが、理解されるべきである。これは、本出願のこの実施形態では限定されない。

第1のノードは、IPv6拡張ヘッダDestination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダは第2のノードを示す事前設定情報を搬送する。あるいは、第1のノードは、BIER拡張ヘッダをカプセル化し、BIER拡張ヘッダは、第2のノードを示す事前設定情報を搬送する。

第1のノードは内部IPv6またはIPv4ヘッダをカプセル化し、内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスアドレスであり、内部IPv6またはIPv4ヘッダで搬送される送信先アドレスはマルチキャストデータパケットのグループアドレスである。

最後に、第1のノードは、転送予定BIERパケットのペイロードとしてマルチキャストデータパケットのペイロードを使用し、言い換えると、外部IPv6パケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。

ケース2のマルチキャストデータパケットをカプセル化するプロセスにおいて、第1のノードが、内部IPv6またはIPv4ヘッダおよび外部IPv6パケットのペイロードをカプセル化することは、理解されるべきである。図5（b）のフォーマット1および図5（b）のフォーマット2を比較することにより、カプセル化は実際に、受信したマルチキャストデータパケットを転送予定BIERパケットにカプセル化していることがわかる。さらに、第1のノードは、マルチキャストデータパケットの外層でIPv6拡張ヘッダまたはBIER拡張ヘッダをカプセル化し、次いでIPv6 Destination Option HeaderまたはBIER拡張ヘッダの外側でSRHをカプセル化し、最後にSRHの外層で外部IPv6ヘッダをカプセル化する。

具体的には、第1のノードは、マルチキャストデータパケットをカプセル化し、あるフォーマット（図5（b）のフォーマット2として示される）の転送予定BIERパケットを取得する。指定ノードに到着する前に、転送予定BIERパケットは、第1のIGPドメイン内の別のノードを通じてさらに転送され得る。しかしながら、ケース2では、転送予定BIERパケットが第1のIGPドメイン内の中間ノードまたはエッジノードを通じて指定ノードに転送されるとき、パケットフォーマットは変化しない。図5（b）の第1のノードと中間ノードとの間の破線で示されるように、パケットが中間ノードを通じて転送されるとき、パケットフォーマットは、第1のノードによって実行されるカプセル化の後に得られるパケットフォーマットである（図5（b）のパケットのフォーマット2を指す破線は、パケットフォーマットがフォーマット2として示される形態のままであることを示す）。

さらに、ケース2では、指定ノードがBIERパケットを受信した後、指定ノードは、SRHで搬送されたアドレスリストに基づいて、外部IPv6ヘッダの送信先アドレスを指定ノードのIPv6アドレスからプロキシノードのIPv6アドレスに変更する。指定ノードからBIERパケットを受信した後、プロキシノードは、BIERパケットの外部IPv6ヘッダの送信先アドレスを、ユニキャストアドレス（図5（b）に示されるフォーマット3のプロキシノードのIPv6アドレス）からマルチキャストグループアドレスに変更する必要がある。

ケース2では、BIERパケットを受信した後、プロキシノードまたは指定ノードは、SRHを削除する必要がある。具体的には、SRHを削除することは、以下を含む。

SRHは、順番に配置されたアドレスリストを含み、アドレスリスト内のどのアドレスまで現在到達しているかを示すためにポインタが使用される。パケットがノードに到着すると、ポインタが移動する（これはポインタ値から1を減算すると理解される）。たとえば、指定ノードのIPv6アドレスは転送予定BIERパケットのIPv6ヘッダにカプセル化され、SRHにカプセル化されたアドレスリストは指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレスを含み、ポインタ値は1である。この場合、パケットが指定ノードに到着すると、ポインタは0に移動し、指定ノードはSRHをポップアップしない可能性がある。パケットがプロキシノードに到着すると、ポインタは0であり、SRHは削除される。あるいは、パケットが指定ノードに到着すると、ポインタが0に移動した後、指定ノードはSRHを削除する。この場合、プロキシノードはもはやSRHを削除する必要がない。

ケース3：

第1のノードおよび第2のノードは、同じIGPドメインに属する。

この場合、カプセル化を通じて第1のノードによって取得されたBIERパケットの特定のパケットフォーマットが図5（c）に示されている。概略図は、2つの部分（図5（c）に示されるノード部分およびパケットフォーマット部分）を含む。以下では、図5（c）を参照して詳細に、転送予定BIERパケットを取得するために第1のノードがどのようにしてマルチキャストデータパケットをカプセル化するかを説明する。

まず、第1のノードは、マルチキャスト送信元からマルチキャストデータパケットを受信する。マルチキャストデータパケットのフォーマット（図5（c）のフォーマット1として示される）は、IPv6またはIPv4ヘッダ（マルチキャストデータパケットがIPv6パケットである場合、フォーマットはIPv6ヘッダを含むか、またはマルチキャストデータパケットがIPv4パケットである場合、フォーマットはIPv4ヘッダを含む）、マルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットの送信先アドレス、そして最後にパケットペイロードを含み、マルチキャストデータパケットの送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、マルチキャストデータパケットの送信先アドレスはマルチキャストデータパケットのグループアドレスである。

次に、第1のノードが転送予定BIERパケットを取得するためにマルチキャストデータパケットをカプセル化することは、具体的には以下を含む。

第1のノードは、外部IPv6ヘッダをカプセル化し、外部IPv6ヘッダで搬送される送信元アドレスはS110の第1のIPv6アドレスであり、外部IPv6ヘッダで搬送される送信先アドレスはグループアドレスである。

第1のノードは、IPv6拡張ヘッダDestination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダは第2のノードを示す事前設定情報を搬送する。あるいは、第1のノードは、BIER拡張ヘッダをカプセル化し、BIER拡張ヘッダは、第2のノードを示す事前設定情報を搬送する。

第1のノードは内部IPv6またはIPv4ヘッダをカプセル化し、内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスアドレスであり、内部IPv6またはIPv4ヘッダで搬送される送信先アドレスはマルチキャストデータパケットのグループアドレスである。

最後に、第1のノードは、転送予定BIERパケットのペイロードとしてマルチキャストデータパケットのペイロードを使用し、言い換えると、外部IPv6パケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。

具体的には、第1のノードは、マルチキャストデータパケットをカプセル化し、あるフォーマット（図5（c）のフォーマット2として示される）の転送予定BIERパケットを取得する。第2のノードに到着する前に、転送予定BIERパケットは、第1のIGPドメイン内の別のノードを通じてさらに転送され得る。しかしながら、ケース3では、転送予定BIERパケットが第1のIGPドメイン内の別のノードを通じて転送されるとき、パケットフォーマットは変化しない。図5（c）の第1のノード、中間ノード、およびエッジノードの間の破線で示されるように、パケットが中間ノードおよびエッジノードを通じて転送されるとき、パケットフォーマットは、第1のノードによって実行されるカプセル化の後に得られるパケットフォーマットである（図5（c）のパケットのフォーマット2を指す破線は、パケットフォーマットがフォーマット2として示される形態のままであることを示す）。

S170：第1のノードがBIERパケットを第2のノードに送信する。

具体的には、以下の3つのケースが含まれる。

ケース1：

S160のケース1に対応して、第1のノードは、プロキシノードを通じて外部IPv6ヘッダに基づいて転送予定BIERパケットを第2のノードに送信する。IGPドメイン内の中間ノードは本出願では詳細に記載されず、実際のパケット転送手順は任意選択的に、中間ノードを通じての転送をさらに含むことが、理解されるべきである。

ケース2：

S160のケース2に対応して、第1のノードは、指定ノードおよびプロキシノードを通じてSRHおよび外部IPv6ヘッダに基づいて転送予定BIERパケットを第2のノードに送信する。転送予定BIERパケットは、指定ノードを通じてプロキシノードに転送され、次いでプロキシノードを通じて第2のノードに転送される。

ケース3：

S160のケース3に対応して、転送予定BIERパケットは、プロキシノードおよび指定ノードを通過することなく、第1のノードによって第2のノードに直接送信される。

S180：第2のノードがBIERパケットを脱カプセル化する。

第2のノードは、BIERヘッダで搬送される事前設定情報を取得し、事前設定情報は第2のノードを示す。言い換えると、第2のノードは、パケットが第2のノードに送信されることを知る。

第2のノードは、事前設定情報に基づいて、BIERパケットを脱カプセル化することを決定する。

第2のノードは、BIERパケットの外部IPv6ヘッダで搬送される第1のIPv6アドレス、および第1のIPv6アドレスと第2の識別子との間の、S110で決定された対応に基づいて、BIERパケットで搬送されるマルチキャストデータパケットが第2のVRFに対応するインターフェースに送信される必要があると判定する。

第2のノードは、BIERパケットの内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、BIERパケットの内部IPv6またはIPv4ヘッダで搬送される送信先アドレスはマルチキャストデータパケットのグループアドレスであるという事実に基づいて、マルチキャストデータパケットが第2のVRFに対応する少なくとも1つのインターフェースで送信されると判定する。

具体的には、マルチキャストデータパケットがマルチキャスト送信元のアドレスおよびマルチキャストグループのアドレスを含むと判定した後、第2のノードは、第2の識別子に対応する少なくとも1つのインターフェースを取得し、少なくとも1つのインターフェースを通じてマルチキャストデータパケットを送信し、マルチキャスト送信元のアドレスは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、マルチキャストグループのアドレスは、第2のノードが参加するマルチキャストグループのアドレスである。マルチキャスト送信元のアドレスは送信元アドレスと呼ばれてもよく、マルチキャストグループのアドレスはグループアドレスと呼ばれてもよい。

マルチキャストデータパケットが第2のVRFに対応する少なくとも1つのインターフェースで送信されると判定することは、マルチキャストデータパケットが第2の識別子に対応する少なくとも1つのインターフェースで送信されると判定することを含むことは、理解されるべきである。第2の識別子は実際には第2のVRFの識別子として理解され得るので、マルチキャストデータパケットは第2のVRFに対応する少なくとも1つのインターフェースで送信されるとさらに判定され得る。

図4および図5を参照して、制御プレーンおよび転送プレーン上の本出願で提供されたパケット転送方法の実装形態を上記で詳細に説明している。特定の実施形態を参照して、以下では、実際のBIERパケット転送中の本出願で提供されるパケット転送方法の使い方を説明する。

特定の実施形態のノードおよびこれらのノードの機能は、以下の表に示される。

図6（a）および図6（b）は各々、本出願の一実施形態による特定の実施形態1の概略図である。概略図は、IGPドメイン1に属する3つのノード（たとえば、図6（a）および図6（b）に示されるPE 1、P10、およびBR 1）と、IGPドメイン2に属する3つのノード（たとえば、図6（a）および図6（b）に示されるPE 2、P20、およびBR 2）と、IGPドメイン1の外側にあってIGPドメイン1内のPE 1に接続されているノードCE 1と、IGPドメイン2の外側にあってIGPドメイン2内のPE 2に接続されているノードCE 2とを含む。

具体的には、図6（a）および図6（b）では、CE 1は、マルチキャストデータパケットを送信する必要があり、マルチキャストデータパケット送信元ノードと呼ばれるノードであり、たとえば、端末デバイスまたはネットワークデバイスであり得る。PE 1は、BIER IPv6カプセル化をサポートするルータである。たとえば、PE 1がCE 1からマルチキャストデータパケットを受信すると、PE 1は、マルチキャストデータパケット向けの外部IPv6ヘッダおよびBIER IPv6ヘッダ（すなわち、IPv6 Destination Option Header）をカプセル化し、場合により、任意選択的に、マルチキャストデータパケット向けのSRHをカプセル化することができる。

図6では、BR 2は、SRv6およびBIER IPv6転送をサポートするルータである。たとえば、カプセル化後に取得されたBIERパケットで搬送される送信先ユニキャストアドレスはBR 2であり、送信先ユニキャストアドレスはローカルセグメント識別子（segment identifier、SID）である。BR 2は、SIDに基づいてSRHを削除することができ、IPv6ヘッダの送信先アドレスをマルチキャストグループアドレスに変更する。さらに、BR 2は、BIER IPv6に基づいてBIERパケットを転送する。具体的には、BR 2は、マルチキャストグループアドレスに基づいてDestination Option Header内のBIER TLVを検出し、BIER TLV内のBitString情報に基づいてパケットを複製および送信する。

マルチキャストデータパケットをカプセル化する（図4および図5に示される第1のノードの特定の形態の）ノードPE 1はIGPドメイン1に属し、BIERパケットを脱カプセル化する（図4および図5に示される第2のノードの特定の形態の）ノードPE 2はIGPドメイン2に属する。

IGPプロトコルが各IGPドメイン内のインターフェース上でイネーブルされることは、留意されるべきである。2つのドメイン間のノード（図6（a）および図6（b）に示されるBR 1およびBR 2）は、ドメインエッジノードと呼ばれる。IGPプロトコルは、ドメインエッジノード間ではイネーブルされない。BIERパケット転送は、IGPプロトコルを使用して確立され、言い換えると、BIERパケット転送は1つのみのIGPドメイン内で確立され、BIER Sub－domainもまた同じIGPドメイン内にある。

パケット転送の前に、PE 2は、パケットを受信するときにPE 2が、IPv6アドレスとVRFとの間の対応に基づいて、PE 2内にあって受信したパケットが属する特定のVRFを判定し、次いでパケット内の他の情報に基づいて、VRFに対応し、パケットが送信される特定のインターフェースを判定できるように、制御プレーン上でIPv6アドレスとVRFとの間の対応を確立する必要がある。

具体的には、制御プレーン上でIPv6アドレスとVRFとの間の対応を確立することは、主に以下のステップを含む。

ステップ1：この実施形態では、PE 2が属するIGPドメイン2内の各ノードのみについてSub－domainまたはBFR－IDなどの情報を構成し、PE 1が属するIGPドメイン1内の各ノードについてSub－domainまたはBFR－IDなどの対応する情報を構成することをスキップする。本出願のこの実施形態では、Sub－domainまたはBFR－IDなどの対応する情報は、パケットを脱カプセル化するノードが属するIGPドメイン内の各ノードに対して構成されるだけでよいことが、理解され得る。

具体的には、BIER IPv6のSub－domainは、PE2が属するIGPドメイン2を分割することによって取得され得る。たとえば、IGPドメイン2内の全てのノードは、同じSub－domainに属する。BFR－ID 1は、PE 2上に構成される。パケットのBitString内の000001は、パケットがPE 2に送信されるだけでよいことを示すために使用される。PE 2が属するSub－domain内の各ノードは、BIER IPv6転送テーブルを確立する。各ノードが転送テーブルを確立するプロセスは、同じSub－domain内の各ノードが転送テーブルを確立する先行技術のプロセスと同様である。詳細は本明細書には記載されない。

さらに、VPN＃1の識別子およびIPv6アドレスは、PE 2上で構成され、それぞれVRF＃2の識別子およびIPv6アドレス＃2であり、IPv6アドレス＃2は、PE 2のIPv6アドレスとも呼ばれ得る。

ステップ2：PE 1上でVPN＃1の識別子およびIPv6アドレスを構成し、これらはそれぞれVRF＃1の識別子およびIPv6アドレス＃1であり、IPv6アドレス＃1はVRF＃1の識別子に対応し、IPv6アドレス＃1は、PE 1のIPv6アドレスとも呼ばれ得る。具体的には、異なるVRF識別子は、異なるIPv6アドレスと一対一対応している。

ステップ3：PE 1は、VRF＃1の識別子およびIPv6アドレス＃1を含む第1の指示メッセージをPE 2に送信する。

任意選択的に、PE 1は、VRF＃1の識別子およびIPv6アドレス＃1をBGP－MVPN routeメッセージにカプセル化し、BGP－MVPN routeメッセージをPE 2に送信する。

あるいは、PE 1は、VRF＃1の識別子およびIPv6アドレス＃1をBGP－VPN routeメッセージにカプセル化し、BGP－VPN routeメッセージをPE 22に送信する。

あるいは、PE 1は、VRF＃1の識別子およびIPv6アドレス＃1をBGP－EVPN routeメッセージにカプセル化し、BGP－EVPN routeメッセージをPE 2に送信する。

ステップ3：PE 2は、第1の指示メッセージを受信し、IPv6アドレスとローカルVRFとの間の対応を確立する。

たとえば、PE 2は、PE 1によって送信されたBGP－MVPN routeメッセージを受信し、PE 1によって送信されたメッセージ内のVRF＃1の識別子をPE 2上で構成されたVRFの識別子と照合し、メッセージがVRF＃2に属すると判定する。したがって、PE 2は、IPv6＃1がPE 2のVRF＃2に対応することを知る。VRF＃1の識別子をPE 2上で構成されたVRFの識別子と照合することは、以下の通りであり得る。VRF＃1の識別子は、VRF＃2の識別子と一致する。したがって、PE 2は、VRF＃2がIPv6＃1に対応すると判定する。

具体的には、PE 1からPE 2によって受信したメッセージがBGP－MVPN routeメッセージであるとき、メッセージは、PE 1のVRF＃1の識別子＜route target拡張コミュニティ属性＞およびPE 1のIPv6アドレス＜PE 1 Addr 1＞を含む。

PE 1からPE 2によって受信したメッセージがBGP－VPN routeメッセージであるとき、メッセージは、PE 1のVRF＃1の識別子＜route target拡張コミュニティ属性＞およびPE 1のIPv6アドレス＜PE 1 Addr 1＞を含む。

PE 1によってPE 2に送信されたメッセージは、PE 1のIPv6アドレス＜PE 1 Addr 1＞を搬送する。

PE 1のIPv6アドレス＜PE 1 Addr 1＞は、BGP－MVPNメッセージのMP＿REACH＿NLRI属性、PTA属性、または新たに追加された別の属性で搬送され得る。

あるいは、PE 1のIPv6アドレス＜PE 1 Addr 1＞は、BGP－VPNメッセージのBGP－prefix SID属性内のSRv6－VPN SID TLV（詳細については、draft－ietf－idr－bgp－prefix－sid－27およびdraft－dawra－idr－srv6－vpn－04を参照されたい）で搬送されてもよく、マルチキャストフローの送信元アドレスXおよび送信先アドレスmcastXに関する情報は、BGP－MVPNメッセージに含まれる。

あるいは、PE 1のIPv6アドレス＜PE 1 Addr 1＞は、BGP－EVPNメッセージの属性で搬送されてもよい。

ステップ4：PE 1は、第2の指示メッセージを受信し、PE 2がパケットを脱カプセル化するノードであると判定する。

たとえば、PE 1は、PE 2からPE 1に送信されたBGP－MVPNメッセージで搬送されるパラメータを使用して、マルチキャストデータパケットの受信機PE 2および受信機PE 2のプロキシノードBRを知り得る。たとえば、BGP－MVPNメッセージは、送信元アドレスXおよびグループアドレスmcastX、PE 2のBFR－ID値、ならびにPE 2のIPv6アドレス＜PE 2 Addr 1＞を含む。PE 1は、PE 2からPE 1に送信されたBGP－MVPNメッセージおよびPE 1上にローカルで構成された事前設定構成情報を使用して、マルチキャストデータパケットの受信機PE 2および受信機PE 2のプロキシノードBR 2を知り得る。たとえば、BGP－MVPNメッセージは、マルチキャストデータパケットの送信元アドレスXおよびグループアドレスmcastX、PE 2のIPv6アドレス、ならびにPE 2のBFR－IDを含む。プロキシノードBR 2のものであってPE 2のIPv6アドレスに対応するIPv6アドレス情報＜BR 2 Addr 1＞が、PE 1上で構成される。

PE 2内の異なるIPv6アドレスと異なるVRFとの間の一対一対応が制御プレーン上で確率された後、転送プレーン上でパケット転送が実行され得ることは、理解されるべきである。具体的には、パケット転送は以下のステップを含む。

ステップ1：PE 1は、CE 1から送信されたマルチキャストデータパケットを受信し、マルチキャストデータパケットで搬送される送信元アドレス（source address、SA）は、マルチキャストデータパケットの送信元アドレス（X）であり、マルチキャストデータパケットで搬送される送信先アドレス（destination address、DA）は、マルチキャストデータパケットのグループアドレス（mcastX）である。

ステップ2：PE 1は、転送予定BIERパケットを取得するために、マルチキャストデータパケットをカプセル化する。

PE 1はまず、外部IPv6ヘッダ（外部IPv6ヘッダの送信元アドレスがIPv6アドレス＃1である）をカプセル化し、次いでDestination Option Headerをカプセル化し、最後に外部IPv6パケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。PE 1は、上述のBIERパケット転送方法と同じ方法でVpnLabelをカプセル化する必要はない。

異なるパケット転送経路に基づいて、PE 1は、以下のいくつかのケースでパケットをカプセル化する。

ケース1：BIERパケットがBR 2を通じてPE 2に転送される。

PE 1は、外部（outer）IPv6ヘッダをカプセル化し、外部IPv6ヘッダで搬送される送信元アドレスはIPv6アドレス＃1であり、外部IPv6ヘッダで搬送される送信先アドレスはBR 2のIPv6アドレス（BR 2 IPv6アドレス）である。

PE 1は、IPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダはBitString情報（BIER information、BIER Info）000001を搬送し、プロトコルフィールドは4または6である（Proto＝4または6）。あるいは、PE 1はBIER拡張ヘッダ（BIER extension header）をカプセル化し、BIER拡張ヘッダのBIER Infoは000001である。

PE 1は、VpnLabel（no VpnLabel）をカプセル化しないが、内部（inner）IPv6またはIPv4ヘッダをカプセル化し、内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスであり得、内部IPv6またはIPv4ヘッダで搬送される送信先アドレスは、マルチキャストデータパケットのグループアドレスである。

BIERパケットのペイロード（payload）は、元のマルチキャストデータパケットのIPパケットである。

この場合、カプセル化を通じて第1のノードによって取得されたBIERパケットが図6（a）のフォーマット2に示されている。図6（a）のHdrは、Headerの略である。

ケース2：BIERパケットがBR 1を通じてBR 2に転送され、次いでBR 2を通じてPE 2に転送される。

PE 1は、外部IPv6ヘッダをカプセル化し、外部IPv6ヘッダで搬送される送信元アドレスはIPv6アドレス＃1であり、外部IPv6ヘッダで搬送される送信先アドレスはBR 1のアドレス情報（たとえば、図6（b）に示されるBR 1 IPv6アドレス）である。

PE 1はSRHをカプセル化し、SRHで搬送されるアドレスリスト（SL）は、BR 1のアドレス情報（BR 1 IPv6アドレス）およびBR 2のアドレス情報（BR 2 IPv6アドレス）を含む。

PE 1は、IPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダはBitString情報000001を搬送し、Protoは4または6である。あるいは、PE 1はBIER拡張ヘッダをカプセル化し、BIER拡張ヘッダはBitString情報000001を搬送する。

PE 1は、VpnLabelをカプセル化しないが、内部IPv6またはIPv4ヘッダをカプセル化し、内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスであり得、内部IPv6またはIPv4ヘッダで搬送される送信先アドレスは、マルチキャストデータパケットのグループアドレスである。

BIERパケットのペイロードは、元のマルチキャストデータパケットのIPパケットである。

この場合、カプセル化を通じて第1のノードによって取得されたBIERパケットが図6（b）のフォーマット2に示されている。図6（b）のHdrは、Headerの略である。

ケース2では、パケットを受信した後、BR 2はSRHを削除し、BIERパケットのIPv6ヘッダの送信先アドレスをマルチキャストグループアドレス（mcastY）に変更する。

具体的には、BIERパケットがBR 1を通じてBR 2に転送されることは、構成を通じて、BIERパケットがプロキシノードBR 2に到着するためにノードBR 1を通過する必要があるとPE 1が規定することであり得る。この場合、PE 1は、カプセル化の間にSRHをカプセル化する。SRHで搬送されるアドレスリストは、指定ノードBR 1および最終ノードBR 2のアドレス情報を含み、IPv6ヘッダの送信先アドレスは、ノードBR 1で満たされる。ノードBR 1は、SRv6機能をサポートし、ノードBR 2のものであってSRH内にあるアドレスをIPv6ヘッダの送信先アドレスにコピーし、アドレスをノードBR 2に複製する。

ステップ3：PE 2がBIERパケットを脱カプセル化する。

BIERパケットを受信した後、PE 2は、パケット内のBitString 000001に基づいて、パケットが、そのBFR－IDが1であるノードに転送される必要があると判定する。先の情報構成プロセスでは、BFR－ID 1は、受信したBIERパケットを脱カプセル化すると決定するために、PE 2上で構成される。具体的には、脱カプセル化は、以下を含む。

PE 2は、外部IPv6ヘッダの送信元アドレスIPv6アドレス＃1に基づいて、パケットがVRF＃2に属すると判定する。

次いで、PE 2は、外部IPv6 Destination Option Headerに続く内部IPパケットの送信元アドレスおよび送信先アドレスに基づいて、パケットを複製し、VRF＃2に対応するアウトバウンドインターフェースに送信する。

図6（a）および図6（b）は各々、PE 1およびPE 2が異なるIGPドメイン内に配置されているときのパケット転送手順を示す。以下では、図7を参照して詳細に、パケットをカプセル化するノードおよびパケットを脱カプセル化するノードが同じIGPドメイン内に配置されているときのパケット転送手順について説明する。

図7は、本出願の一実施形態による特定の実施形態2の概略図である。概略図は、IGPドメイン1に属する3つのノード（図7に示されるPE 2、P20、およびBR 2）と、IGPドメイン1の外側にあってIGPドメイン1内のエッジノードPE 2に接続されているノードCE 1とを含む。

具体的には、図7では、CE 1は、マルチキャストデータパケットを送信する必要があるノードであり、たとえば、端末デバイスまたはネットワークデバイスであり得る。BR 2は、BIER IPv6カプセル化をサポートするルータである。たとえば、BR 2は、CE 1からマルチキャストデータパケットを受信し、BR 2は、マルチキャストデータパケット向けの外部IPv6ヘッダおよびBIER IPv6ヘッダ（すなわち、IPv6 Destination Option Header）をカプセル化することができる。

実施形態2における制御プレーン上のIPv6アドレスとVRFとの間の対応を確立するプロセスと、図6に示されるプロセスとの違いは、BR 2上でBFR－IDを構成する必要がないことにある。制御プレーン上の別のプロセスは、実施形態2のプロセスと同様であり、本明細書では再度説明されない。

パケット転送は、転送プレーン上で実行される。具体的には、パケット転送は以下のステップを含む。

ステップ1：BR 2は、CE 1から送信されたマルチキャストデータパケットを受信し、マルチキャストデータパケットは、マルチキャストデータパケットの送信元アドレス（SA＜X＞）およびマルチキャストデータパケットのグループアドレス（DA＜mcastX＞）を搬送する。

ステップ2：BR 2は、転送予定BIERパケットを取得するために、マルチキャストデータパケットをカプセル化する。

BR 2はまず、外部IPv6ヘッダ（外部IPv6ヘッダの送信元アドレスがIPv6アドレス＃1である）をカプセル化し、次いでDestination Option Headerをカプセル化し、最後に外部IPv6パケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。BR 2は、上述のBIERパケット転送方法と同じ方法でVpnLabelをカプセル化する必要はない。

特定のカプセル化手順は、以下を含む。

BR 2は、外部IPv6ヘッダをカプセル化し、外部IPv6ヘッダで搬送される送信元アドレスはIPv6アドレス＃1であり、外部IPv6ヘッダで搬送される送信先アドレスはグループアドレス（DA＜mcastY＞）である。

BR 2は、IPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダはBitString情報000001を搬送し、Protoは4または6である。あるいは、PE 1はBIER拡張ヘッダをカプセル化し、BIER拡張ヘッダはBitString情報000001を搬送する。

BR 2は、VpnLabelをカプセル化しないが、内部IPv6またはIPv4ヘッダをカプセル化し、内部IPv6またはIPv4ヘッダで搬送される送信元アドレスはマルチキャストデータパケットの送信元アドレスであり得、内部IPv6またはIPv4ヘッダで搬送される送信先アドレスは、マルチキャストデータパケットのグループアドレスである。

BIERパケットのペイロードは、元のマルチキャストデータパケットのIPパケットである。

この場合、カプセル化を通じて第1のノードによって取得されたBIERパケットが図7のフォーマット2に示されている。図7のHdrは、Headerの略である。

ステップ3：PE 2がBIERパケットを脱カプセル化する。

BIERパケットを受信した後、PE 2は、パケット内のBitString 000001に基づいて、パケットが、そのBFR－IDが1であるノードに転送される必要があると判定する。先の情報構成プロセスでは、BFR－ID 1は、受信したBIERパケットを脱カプセル化すると決定するために、PE 2上で構成される。具体的には、脱カプセル化は、以下を含む。

PE 2は、外部IPv6ヘッダの送信元アドレスIPv6アドレス＃1に基づいて、パケットがVRF＃2に属すると判定する。

次いで、PE 2は、外部IPv6 Destination Option Headerに続く内部IPパケットの送信元アドレスおよび送信先アドレスに基づいて、パケットを複製し、VRF＃2に対応するアウトバウンドインターフェースに送信する。

結論として、本出願のこの実施形態で提供されるパケット転送方法によれば、まず、制御プレーン上で、ヘッドノードは、複数のVRFと一対一対応している複数のIPv6アドレスを有し、IPv6アドレスおよびVRF識別子を搬送するためにメッセージを使用し、メッセージをテールノードに送信する。そしてテールノードは、テールノードによって転送エントリを確立するプロセスを簡略化するために、IPv6アドレスおよびVRF識別子に基づいて転送エントリを確立するだけでよい。次に、転送プレーン上で、BIER IPv6パケットをカプセル化および送信するとき、ヘッドノードは、内部IPパケットの前にVpnLabelをカプセル化する必要がなく、テールノードは、IPv6 BIERパケットを受信し、IPv6アドレスに基づいて、テールノードに対応し、パケットが属する特定のVRFを知り、次いで、パケット転送性能を改善するために、内部パケットに基づいて、パケットが複製されてVRFに対応するアウトバウンドインターフェースに送信されることを決定する。

上記では、図4から図7を参照して、本出願の実施形態で提供されるパケット転送方法を詳細に説明している。以下では、図8から図11を参照して、本出願の実施形態で提供されるパケット送信装置およびパケット受信装置について詳細に説明する。

図8は、本出願の一実施形態によるパケット送信装置の概略構造図である。パケット送信装置は、先のマルチキャストVPNにパケットをカプセル化するノードであり、処理ユニット810、受信ユニット820、および送信ユニット830を含む。

処理ユニット810は、第1の仮想プライベートネットワークVPNの第1の識別子および第1のインターネットプロトコルバージョン6 IPv6アドレスを構成し、第1のIPv6アドレスは第1の識別子に対応し、第1のVPNに属するマルチキャストデータパケットを受信した後、マルチキャストデータパケットが属する第1のVPNに基づいて第1のIPv6アドレスを取得し、第1のIPv6アドレスは第1の識別子に対応し、転送予定BIERパケットを取得するために、第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化するように構成されている。

送信ユニット830は、第1の指示メッセージを第2のノードに送信し、第1の指示メッセージは、第1のIPv6アドレスと第2の識別子との間の対応を確立するように第2のノードに指示するために使用され、第1の指示メッセージは第1の識別子および第1のIPv6アドレスを含み、第2の識別子は、第2のノードのものであって第1の識別子との事前設定対応を満たす識別子であり、転送予定BIERパケットを第2のノードに送信するように構成されている。

受信ユニット820は、マルチキャストデータパケットを受信し、第2のノードによって送信された第2の指示メッセージを受信するように構成されている。

図8に示されるパケット送信装置は、方法実施形態の第1のノードに完全に対応している。図8に示されるパケット送信装置内の対応するユニットは、図4から図7に示される方法実施形態の第1のノードによって実行される対応するステップを実行するように構成されている。

図8に示されるパケット送信装置内の受信ユニット820は、方法実施形態の受信ステップを実行し、たとえば、図4の第2のノードから第2の指示メッセージを受信するS140を実行する。処理ユニット810は、方法実施形態の第1のノードで実施または処理されるステップを実行し、たとえば、図4のVPN情報を構成するS110および図4のマルチキャストデータパケットをカプセル化するS160を実行する。送信ユニット830は、方法実施形態の送信ステップを実行し、たとえば、図4の第1の指示メッセージを第2のノードに送信するS130を実行する。

任意選択的に、受信ユニット820および送信ユニット830は、受信機能および送信機能の両方を有するトランシーバユニットを形成してもよい。処理ユニット820はプロセッサであってもよい。受信ユニット820および送信ユニット830によって形成されたトランシーバユニットは、通信インターフェースであってもよい。

図9は、本出願の一実施形態による別のパケット送信装置の概略構造図である。図9に示されるパケット送信装置は、プロセッサ910、メモリ920、および通信インターフェース930を含み得る。プロセッサ910、メモリ920、および通信インターフェース930は、通信バス940を通じて接続され得る。プロセッサ910は少なくとも1つの物理プロセッサを含み、通信インターフェース930は少なくとも1つの物理インターフェースを含む。メモリ930は、プログラムおよび第1のノードのIPアドレスなどの情報を記憶するように構成されている。

図9に示されるパケット送信装置および図8に示されるパケット送信装置は、BIERネットワーク内の同じBFIR、たとえば図6のPE 1であってもよい。図8は、論理的観点からパケット送信装置に含まれる内容を示し、図9は、物理的観点からパケット送信装置に含まれる内容を示す。図8の受信ユニット820および送信ユニット830は、図9の通信インターフェース930を使用して実施されてもよく、図8の処理ユニット810は、図9のプロセッサ910を使用して実施されてもよい。

プロセッサ910は、メモリ920から読み取られたプログラムに含まれる実行可能命令に従って、図8の処理ユニット810の動作を実行する。

通信インターフェース930は、図8の受信ユニット820および送信ユニット830の動作を実行する。

図10は、本出願の一実施形態によるパケット受信装置の概略構造図である。パケット受信装置は、先のマルチキャストVPNにパケットを脱カプセル化するノードであり、処理ユニット1010、受信ユニット1020、および送信ユニット1030を含む。

受信ユニット1020は、第1のノードから第1の指示メッセージを受信し、第1の指示メッセージは、第1のVPNの第1の識別子および第1のIPv6アドレスを含み、第1の識別子は第1のIPv6アドレスに対応し、第1のノードからBIERパケットを受信し、BIERパケットは第1のIPv6アドレスおよびマルチキャストデータパケットを含む、ように構成されている。

処理ユニット1010は、第1のIPv6アドレスおよび第1の識別子に基づいて第1のIPv6アドレスと第2の識別子との間の対応を確立し、第2の識別子は、第2のノードのものであって第1の識別子との事前設定対応を満たす識別子であり、第1のIPv6アドレスおよび第1のIPv6アドレスと第2の識別子との間の対応に基づいて、送信ユニットが、第2の識別子に対応するインターフェースにマルチキャストデータパケットを送信することを決定するように構成されている。

送信ユニット1030は、第2の識別子に対応するインターフェースにマルチキャストデータパケットを送信するように構成されている。

図10に示されるパケット受信装置は、方法実施形態の第2のノードに完全に対応している。図10に示されるパケット受信装置内の対応するユニットは、図4から図7に示される方法実施形態の第2のノードによって実行される対応するステップを実行するように構成されている。

図10に示されるパケット受信装置内の受信ユニット1020は、方法実施形態の受信ステップを実行し、たとえば、図4の第1のノードから第1の指示メッセージを受信するS130を実行する。処理ユニット1010は、方法実施形態の第2のノードで実施または処理されるステップを実行し、たとえば、図4のVPN情報を構成するS120および図4のBIERパケットを脱カプセル化するS180を実行する。送信ユニット1030は、方法実施形態の送信ステップを実行し、たとえば、図4の第2の指示メッセージを第1のノードに送信するS140を実行する。

任意選択的に、受信ユニット1020および送信ユニット1030は、受信機能および送信機能の両方を有するトランシーバユニットを形成してもよい。処理ユニット1010はプロセッサであってもよい。受信ユニット1020および送信ユニット1030によって形成されたトランシーバユニットは、通信インターフェースであってもよい。

図11は、本出願の一実施形態による別のパケット受信装置の概略構造図である。図11に示されるパケット受信装置は、プロセッサ1110、メモリ1120、および通信インターフェース1130を含み得る。プロセッサ1110、メモリ1120、および通信インターフェース1130は、通信バス1140を通じて接続され得る。プロセッサ1110は少なくとも1つの物理プロセッサを含み、通信インターフェース1130は少なくとも1つの物理インターフェースを含む。メモリ1130は、プログラムおよび第2のノードのIPアドレスなどの情報を記憶するように構成されている。

図11に示されるパケット受信装置および図10に示されるパケット受信装置は、BIERネットワーク内の同じBFIR、たとえば図6のPE 2であってもよい。図10は、論理的観点からパケット受信装置に含まれる内容を示し、図11は、物理的観点からパケット受信装置に含まれる内容を示す。図10の受信ユニット1020および送信ユニット1030は、図11の通信インターフェース1130を使用して実施されてもよく、図10の処理ユニット1010は、図11のプロセッサ1110を使用して実施されてもよい。

プロセッサ1110は、メモリ1120から読み取られたプログラムに含まれる実行可能命令に従って、図10の処理ユニット1010の動作を実行する。

通信インターフェース1130は、図10の受信ユニット1020および送信ユニット1030の動作を実行する。

本出願の一実施形態は、先の1つ以上の第1のノードおよび第2のノードを含む、パケット転送デバイスをさらに提供する。

本願はコンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、命令を記憶する。コンピュータ上で命令が実行されると、コンピュータは、図4から図7に示される方法で第1のノードによって実行されるステップを実行できるようになる。

本願はコンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、命令を記憶する。コンピュータ上で命令が実行されると、コンピュータは、図4から図7に示される方法で第2のノードによって実行されるステップを実行できるようになる。

本出願は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータ上でコンピュータプログラム製品が動作すると、コンピュータは、図4から図7に示される方法で第1のノードによって実行されるステップを実行できるようになる。

本出願は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータ上でコンピュータプログラム製品が動作すると、コンピュータは、図4から図7に示される方法で第2のノードによって実行されるステップを実行できるようになる。

本出願は、プロセッサを含むチップをさらに提供する。プロセッサは、本出願で提供されるパケット転送方法の第1のノードによって実行される対応する動作および／または手順を実行するために、メモリに記憶されたコンピュータプログラムを読み取って実行するように構成されている。任意選択的に、チップはメモリをさらに含む。メモリは、回路またはケーブルを通じてプロセッサに接続されている。プロセッサは、メモリに記憶されたコンピュータプログラムを読み取って実行するように構成されている。任意選択的に、チップは通信インターフェースをさらに含む。プロセッサは、通信インターフェースに接続されている。通信インターフェースは、処理される必要があるデータおよび／または情報を受信するように構成されている。プロセッサは、通信インターフェースからデータおよび／または情報を取得し、データおよび／または情報を処理する。通信インターフェースは、入力／出力インターフェースであってもよい。

本出願は、プロセッサを含むチップをさらに提供する。プロセッサは、本出願で提供されるパケット転送方法の第2のノードによって実行される対応する動作および／または手順を実行するために、メモリに記憶されたコンピュータプログラムを呼び出して実行するように構成されている。任意選択的に、チップはメモリをさらに含む。メモリは、回路またはケーブルを通じてプロセッサに接続されている。プロセッサは、メモリに記憶されたコンピュータプログラムを読み取って実行するように構成されている。任意選択的に、チップは通信インターフェースをさらに含む。プロセッサは、通信インターフェースに接続されている。通信インターフェースは、処理される必要があるデータおよび／または情報を受信するように構成されている。プロセッサは、通信インターフェースからデータおよび／または情報を取得し、データおよび／または情報を処理する。通信インターフェースは、入力／出力インターフェースであってもよい。

前述の実施形態では、プロセッサは、中央処理ユニット（central processing unit、CPU）、マイクロプロセッサ、特定用途向け集積回路（application－specific integrated circuit、ASIC）、または本出願の技術的ソリューションにおけるプログラム実行を制御するための1つ以上の集積回路などであり得る。たとえば、プロセッサは、デジタル信号プロセッサデバイス、マイクロプロセッサデバイス、アナログ－デジタル変換器、および、デジタル－アナログ変換器であってもよい。プロセッサは、これらのデバイスのそれぞれの機能に基づいて、これらのデバイス間で端末デバイスおよびネットワークデバイスの制御および信号処理機能を割り当ててもよい。加えて、プロセッサは、1つ以上のソフトウェアプログラムを動作させる機能を有し得る。ソフトウェアプログラムは、メモリに記憶され得る。プロセッサの機能は、ハードウェアによって実施されてもよく、または対応するソフトウェアを実行することによりハードウェアによって実施されてもよい。ハードウェアまたはソフトウェアは、前述の機能に対応する1つ以上のモジュールを含む。

メモリは、読取り専用メモリ（read－only memory、ROM）、静的情報および命令を記憶できる別のタイプの静的記憶デバイス、またはランダムアクセスメモリ（random access memory、RAM）もしくは情報および命令を記憶できる別のタイプの動的記憶デバイスであり得るか、または電気的消去可能プログラム可能読取り専用メモリ（electrically erasable programmable read－only memory、EEPROM）、コンパクトディスク読取り専用メモリ（compact disc read－only memory、CD－ROM）もしくは別の光ディスク記憶装置、光ディスク記憶装置（コンパクト光ディスク、レーザディスク、光ディスク、デジタル多用途光ディスク、およびブルーレイディスクなどを含む）、磁気ディスク記憶媒体もしくは別の磁気記憶デバイス、予期されるプログラムコードを命令もしくはデータ構造の形で搬送もしくは記憶するために使用されることができ、コンピュータによってアクセスされることのできる任意の他の媒体などであり得る。

任意選択的に、メモリおよびメモリは物理的に独立したユニットであってもよく、またはメモリがプロセッサに組み込まれてもよい。

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

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

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

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

別個の部分として説明されたユニットは、物理的に別個でなくてもよく、ユニットとして提示された部分は、物理的なユニットでなくてもよく、また、1つの位置に配置されてもよく、または複数のネットワークユニットに分散されてもよい。ユニットの一部または全部は、本出願の技術的ソリューションの目的を達成するために、実際の必要に基づいて選択されてもよい。

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

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

上記の説明は、本出願の特定の実装形態にすぎない。本願で開示される技術的範囲内で当業者が容易に想到する変形または置換は、本出願の保護範囲内に含まれるものとする。本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

810 処理ユニット
820 受信ユニット
830 送信ユニット
910 プロセッサ
920 メモリ
930 通信インターフェース
940 通信バス
1010 処理ユニット
1020 受信ユニット
1030 送信ユニット
1110 プロセッサ
1120 メモリ
1130 通信インターフェース
1140 通信バス

IPネットワークにおける効率的なポイントツーマルチポイントデータ伝送は、ネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減するために、インターネットプロトコル（Internet protocol、IP）マルチキャスト技術を使用して実施される。したがって、IPマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビ（Internet protocol television、IPTV）、ゲーム、シミュレーションなどで広く使用されている。現在、マルチキャスト技術は通常、プロトコル独立マルチキャスト（protocol independent multicast、PIM）プロトコル、マルチキャストソースディスカバリプロトコル（multicast source discovery protocol、MSDP）などを使用して実施される。これらのマルチキャストプロトコルの共通の特徴は制御プレーンマルチキャストツリーが構築される必要があることである。ネットワークプレーンは、マルチキャスト転送中に、ポイントツーマルチポイントデータ転送、ループ回避などを実施するために、マルチキャストツリーを使用することによって論理的に処理されてツリーになる。配信ツリーがコアとして構築されるマルチキャストルーティングプロトコルにおけるこのような中間ノードは、マルチキャスト転送情報の複雑な状態を維持する必要がある。ネットワーク規模が拡大し、マルチキャストデータトラフィックが増加するに連れて、マルチキャスト技術は、増加するコスト、ならびに運用および保守の大きな課題に直面する。

これを考慮して、マルチキャスト転送経路を構築するための新しい技術が業界で提案され、ビットインデックス明示的レプリケーション（bit index explicit replication、BIER）技術と呼ばれている。マルチキャスト配信ツリーが構築される必要のない、新しいマルチキャスト技術アーキテクチャが、業界で提案されている。BIER技術をサポートするルータは、ビット転送ルータ（bit forwarding router、BFR）と呼ばれる。BFRを含むマルチキャスト転送ドメインは、BIERドメインと呼ばれる。BIERドメインのエッジにおいて、ユーザのマルチキャストデータをカプセル化および転送するルータは、ビット転送入口ルータ（bit forwarding ingress router、BFIR）と呼ばれ、BIERパケットを脱カプセル化するエッジBFRデバイスは、ビット転送出口ルータ（bit forwarding egress router、BFER）と呼ばれる。マルチキャストデータは、BFIRによってカプセル化されてBIERドメインに入り、BIERドメイン内のBIERパケットのヘッダに基づいて転送され、1つ以上のBFERデバイスを通過した後にBIERドメインを離れる。BIERドメインにおいて、BIERパケットを受信および転送するデバイスは、マルチキャストデータに対応する遷移ビット転送ルータ（Bit Forwarding Router、BFR）と呼ばれる。BFRは、パケットがカプセル化されているか脱カプセル化されているかに応じて、BFIRまたはBFERであり得る。

本出願で提供されるパケット転送方法によれば、制御プレーン上で、第1のノードは、第1のVPNのために第1の識別子および第1のIPv6アドレスを構成し、第1の指示メッセージを使用して第1の識別子および第1のIPv6アドレスを第2のノードに送信し、第1の識別子は第1のIPv6アドレスに対応する。このようにして、第2のノードは、第1のVPN向けにローカルで構成され、第2の識別子と第1の識別子との間で満たされる事前設定対応に基づいて、第1のIPv6アドレスと第2の識別子との間の対応をさらに決定することができる。転送プレーンにおいて、第1のVPNに対応するインターフェースを通じて、第1のVPNに属するマルチキャストデータパケットを受信するとき、第1のノードは、第1の識別子および第1のIPv6アドレスを使用して第1のIPv6アドレスを相応に取得し、転送予定BIERパケットを取得するために第1のIPv6アドレスに基づいてマルチキャストデータパケットをカプセル化し、BIERパケットを第2のノードに送信するが、第1のノードのBIERパケットカプセル化性能およびBIERパケット送信性能を改善するために、仮想プライベートネットワークラベルVpnLabelに基づいてパケットをカプセル化する必要はない。

マルチキャストデータパケットはマルチキャストデータパケットの送信元アドレスおよびマルチキャストデータパケットのグループアドレスを搬送し、第2のノードは第1のノードの送信元アドレスおよびグループアドレスを送信し、マルチキャストデータパケットの送信元アドレスは第2のノードによって送信された送信元アドレスと同じであり、マルチキャストデータパケットのグループアドレスは第2のノードによって送信されたグループアドレスと同じであるため、第1のノードは、マルチキャストデータパケットが第2のノードに送信される必要があると判定することが、さらに理解されるべきである。第1のノードは、第2のノードがマルチキャストデータパケットに関与するノードであることを知り、したがって、マルチキャストデータパケットが第2のノードに送信される必要があると判定する。

第1の態様を参照すると、第1の態様のいくつかの実装形態では、第2の指示メッセージは、ボーダーゲートウェイプロトコルマルチキャスト仮想プライベートネットワークBGP－MVPNルートメッセージを含む。

第1の態様を参照すると、第1の態様のいくつかの実装形態では、方法は、第1のノードが、第2のノードを示す事前設定情報をカプセル化することを、さらに含む。第1のノードが第2のノードを示す事前設定情報をカプセル化することは、第1のノードがIPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderがBIERヘッダを含み、BIERヘッダが第2のノードを示す事前設定情報を搬送すること、または第1のノードがBIER拡張ヘッダをカプセル化し、BIER拡張ヘッダが第2のノードを示す事前設定情報を搬送し、BIER拡張ヘッダが新たに追加されたIPv6拡張ヘッダであることを含む。

第1の態様によれば、第1の態様のいくつかの実装形態では、第1の指示メッセージは、以下のメッセージのうちの少なくとも1つを含む：BGP－MVPNルートメッセージ、BGP－VPNルートメッセージ、またはBGPイーサネット仮想プライベートネットワークルートBGP－EVPN routeメッセージ。

第2の態様を参照すると、第2の態様のいくつかの実装形態では、第2のノードが第1のノードからBIERパケットを受信する前に、方法は、第2のノードが第2の指示メッセージを第1のノードに送信し、第2の指示メッセージが第2のノードのIPv6アドレスを含むことを、さらに含む。

第2の態様を参照すると、第2の態様のいくつかの実装形態では、第2の指示メッセージはBGP－MVPNルートメッセージを含む。

第3の態様によれば、パケット送信装置が提供される。パケット送信装置は、第1の態様のいずれか1つ、または第1の態様の可能な実装形態による第1のノードの動作を実行するように構成され得る。具体的には、パケット送信装置は、第1の態様で記載されたステップまたは機能を実行するように構成され、第1の態様における第1のノードであり得る、対応するコンポーネント（component）を含む。ステップまたは機能は、ソフトウェア、ハードウェア、またはハードウェアとソフトウェアとの組合せを使用して実施されてもよい。

第4の態様によれば、パケット受信装置が提供される。パケット受信装置は、第2の態様のいずれか1つ、または第2の態様の可能な実装形態による第2のノードの動作を実行するように構成され得る。具体的には、パケット受信装置は、第2の態様で記載されたステップまたは機能を実行するように構成され、第2の態様における第2のノードであり得る、対応するコンポーネント（component）を含む。ステップまたは機能は、ソフトウェア、ハードウェア、またはハードウェアとソフトウェアとの組合せを使用して実施されてもよい。

VPNは、multicast VPNであってもよいことは留意されるべきである。具体的には、multicast VPNは、マルチキャストが展開される仮想プライベートネットワークを指す。仮想プライベートネットワークは、レイヤ3仮想プライベートネットワーク（layer 3 virtual private network、L3VPN）またはイーサネット仮想プライベートネットワーク（Ethernet virtual private network、EVPN）であり得る。あるいは、公衆網のいくつかのサイトは、マルチキャストを展開し得る。プライベートネットワークL3VPN／EVPN／公衆網でマルチキャストを展開するための、いくつかの共通のプロトコルおよび方法がある。たとえば、ボーダーゲートウェイプロトコルマルチキャスト仮想プライベートネットワーク（border gateway protocol multicast virtual private network、BGP－MVPN）アドレスファミリメッセージは、マルチキャストがL3VPN上で展開されるときに使用される。ボーダーゲートウェイプロトコルイーサネット仮想プライベートネットワーク（border gateway protocol Ethernet virtual private network、BGP－EVPN）アドレスファミリメッセージは、マルチキャストがEVPN上で展開されるときに使用される。BGP－MVPNアドレスファミリメッセージはまた、公衆網を識別するために特殊な識別子が使用される場合、マルチキャストが公衆網上で展開されるときにも使用される。この場合、公衆網は、特殊なL3VPNまたは仮想ルーティングおよび転送（virtual routing and forwarding、VRF）と見なされる。

BIER技術は、2014年末からインターネット技術特別調査委員会（Internet Engineering Task Force、IETF）での議論を通じて生み出されたマルチキャスト技術である。BIER技術は、以下のように簡単に説明される。

値は、Sub－domain内の各エッジノード向けに構成され、BIER転送ルータ識別子（BIER forwarding router identifier、BFR－ID）として使用される。

Sub－domainの各ノードの構成情報は、IGPフラッディング方式でIGPドメイン内にフラッディングされる。具体的には、各ノードの構成情報は、ノードのIPアドレス、ノードが属するSub－domain、ノードが属するSub－domainに対応するビット転送テーブル識別子（Bit Index Forwarding Table identifier、BIFT－ID）、およびノードのBFR－IDを含む。

BIERパケット内のBitStringに基づいてBIERパケットに対応する次ホップノードを決定する方法は、単なる例にすぎず、本出願に対する限定を構成しないことが、理解されるべきである。具体的には、BitStringの機能は、従来技術のBitStringの機能と同様である。詳細は本明細書には記載されない。

概略図に示されるBIERパケットのヘッダフォーマットは、（図2の第2行および第3行に示されるように）64 bits（8バイト）を有する他のフィールドをさらに含む。具体的には、他のフィールドは、図2の第2行および第3行に示される、ニブル（Nibble）、バージョン（version、Ver）、ビット列長（BitString length、BSL）、情報エントロピー（Entropy）、運用、管理、および保守（operation, administration, and maintenance、OAM）、改訂標準バージョン（revised standard version、Rsv）、差別化サービスコードポイント（differentiated services code point、DSCP）、プロトコル（protocol、Proto）、およびビット転送入口ルータ識別子（bit forwarding ingress router identifier、BFIR－ID）などのフィールドを含む。

IPv6プロトコルの仕様に適合するために、従来技術において、別のBIERパケット転送方法がさらに提案されている。新たに追加されたタイプ・長さ・値（type length value、TLV）は、既存のIPv6 Destination Option Headerで定義され、BIERタイプ・長さ・値（BIER type length value、BIER TLV）と呼ばれる。BitString情報を含む、BIERパケットを転送するために必要とされる情報は、BIER TLVに記憶される。

BIERパケット転送方法がビットインデックス明示的レプリケーションBIER（multicast virtual private network over BIER、multicast VPN over BIER）を介してマルチキャスト仮想プライベートネットワークに適用されるとき、既存のメカニズムが依然として使用される。既存のメカニズムの鍵は、テールノードが、VpnLabelに基づいて、テールノードに対応し、受信したパケットが属する、特定の仮想ルーティングおよび転送（virtual routing and forwarding、VRF）を決定する必要があるということである。VRFの概念は仮想プライベートネットワーク（virtual private network、VPN）の概念に対応し、各VPNは1つのVRFに対応する。MVPNはマルチキャスト向けのVPNを意味する。したがって、既存のメカニズムは、MVPN over BIERシナリオで使用される必要がある。既存のメカニズムは、実際には、パケットに基づいて、パケットが属する特定のVRFを知る。

たとえば、BIERヘッダプロトコルフィールド2（Proto 2）は、BIERヘッダの後のパケットが仮想プライベートネットワークラベル＋インターネットプロトコル（virtual private network label＋internet protocol、VpnLabel＋IP）パケットであることを示すために使用される。

たとえば、ヘッドノードは、ボーダーゲートウェイプロトコル（border gateway protocol、BGP）を使用してテールノードにメッセージを送信し、メッセージは、ヘッドノードのVRF識別子、ヘッドノードのBFIR－ID、Sub－domain、およびヘッドノードによって割り当てられ、VRFに対応するVpnLabelを含む。具体的には、ヘッドノードのVRF識別子は、BGP－MVPNアドレスファミリ内のルーティングtarget（Route Target）識別子である。

1．ヘッドノードは、VpnLabelを割り当て、パケット内のVpnLabelをカプセル化する必要があり、VpnLabelは4バイトを占有する。SRv6－VPNはMPLSラベルを含まないので、IPv6／SRv6ラベルとマルチプロトコルラベル切り換え（multi-protocol label switching、MPLS）ラベルとの組合せのカプセル化形態は、既存のSRv6－VPN技術的ソリューションのカプセル化形態とは大きく異なる。

たとえば、合計で2つのVPN（VPN＃1およびVPN＃2）がある。第1のノードは、VRF＃1の識別子、およびVPN＃1のIPv6アドレス＃1を構成し、IPv6アドレス＃1はVRF＃1の識別子に対応する。第2のノードは、VRF＃1’の識別子、およびVPN＃1のIPv6アドレス＃1’を構成し、IPv6アドレス＃1’は、任意選択的にVRF＃1’の識別子に対応する。第1のノードは、VRF＃2の識別子、およびVPN＃2のIPv6アドレス＃2を構成し、IPv6アドレス＃2はVRF＃2の識別子に対応する。第2のノードは、VRF＃2’の識別子、およびVPN＃2のIPv6アドレス＃2’を構成し、IPv6アドレス＃2’は、任意選択的にVRF＃2’の識別子に対応する。

任意選択的に、いくつかの実施形態では、第2のノードの識別子は、先のBFR－ID、すなわち第2のノードが属するIGPドメイン内で第2のノード向けに構成されたBFR－IDであってもよい。さらに、第2のノードはパケットを脱カプセル化するノードであるので、第2のノード向けに構成されたBFR－IDはBFER－IDである。

可能なケース2：第2のVRFは、第2のノードに対応し、第1のVRFの識別子と包含関係にあるVRFである。たとえば、第1のVRFの識別子が「1：1」である場合、第2のVRFは、第2のノードに対応し、その識別子が「1：1および1：2」であるVRFである。識別子が包含関係を満たすということは、第2のVRFの識別子が複数の識別子を含む識別子リストであり、第1のVRFの識別子が第2のVRFに対応する識別子リストに属する識別子であるか、または第1のVRFの識別子が別の識別子リストの中の識別子であり、識別子リストが第2のVRFの識別子リストの一部または全てであることを意味する。

具体的には、第1のIPv6アドレスおよび第1のVRFの情報がBGP－VPN routeメッセージにカプセル化されることは、第1の識別子が＜route target拡張コミュニティ属性＞であり、第1のIPv6アドレスが＜第1のノードAddr 1＞であることであり得る。ここで、＜第1のノードAddr 1＞は、BGP－VPN routeメッセージのBGP－prefix SID属性内のSRv6－VPN SID TLVで搬送され得る。

任意選択的に、いくつかの実施形態では、第2の指示メッセージがBGP－MVPNルートメッセージである。

第1のノードが、S140で第2のノードによって送信された受信した第2の指示メッセージに基づいて、マルチキャストデータパケットが第2のノードに送信される必要があると判定できることは、理解されるべきである。マルチキャスト送信元のものであってマルチキャストデータパケットに含まれるアドレスは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、マルチキャストグループのものであってマルチキャストデータパケットに含まれるアドレスは、第2のノードが参加するマルチキャストグループのアドレスであり、第2のノードによって送信される第2の指示メッセージは、第2のノードによって受信される必要があるマルチキャスト送信元のアドレスと、第2のノードが参加するマルチキャストグループのアドレスとを含む。したがって、第1のノードは、マルチキャストデータパケットが第2のノードに送信される必要があると判定し、受信したマルチキャストデータパケットをさらにカプセル化する。

まず、第1のノードは、マルチキャスト送信元からマルチキャストデータパケットを受信する。マルチキャストデータパケットのフォーマット（図5（a）のフォーマット1として示される）は、IPv6またはIPv4ヘッダ（マルチキャストデータパケットがIPv6パケットである場合、フォーマットはIPv6ヘッダを含むか、またはマルチキャストデータパケットがIPv4パケットである場合、フォーマットはIPv4ヘッダを含む）、IPv6またはIPv4ヘッダの送信元アドレスおよびIPv6またはIPv4ヘッダの送信先アドレス、そして最後にパケットペイロードを含み、IPv6またはIPv4ヘッダの送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、IPv6またはIPv4ヘッダの送信先アドレスはマルチキャストデータパケットのグループアドレスである。

第1のノードは、マルチキャストデータパケットの外層でIPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダは第2のノードを示す事前設定情報を搬送する。あるいは、第1のノードは、マルチキャストデータパケットの外層でBIER拡張ヘッダをカプセル化し、BIER拡張ヘッダは、第2のノードを示す事前設定情報を搬送する。

第1のノードがIPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderがBIERヘッダを含むということは、新しいIPv6拡張ヘッダが定義されず、IPv6 Destination Option Headerがさらに拡張されることを意味し得る。BIER拡張ヘッダをカプセル化することは、新しいIPv6拡張ヘッダを定義し、BIERパケットによって必要とされる情報を搬送するために新しいIPv6拡張ヘッダを使用することとして理解され得る。言い換えると、本出願のこの実施形態では、BitString情報などをどのようにしてカプセル化するかは限定されない。既存の拡張ヘッダがさらに拡張されてもよく、または新しい拡張ヘッダが定義されてもよい。

最後に、第1のノードは、転送予定BIERパケットのペイロードとしてマルチキャストデータパケットのペイロードを使用し、言い換えると、転送予定BIERパケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。

ケース1のマルチキャストデータパケットをカプセル化するプロセスにおいて、第1のノードが、内部IPv6またはIPv4ヘッダおよび転送予定BIERパケットのペイロードをカプセル化することは、理解されるべきである。図5（a）のフォーマット1および図5（a）のフォーマット2を比較することにより、カプセル化は実際に、受信したマルチキャストデータパケットを転送予定BIERパケットにカプセル化していることがわかる。さらに、第1のノードは、マルチキャストデータパケットの外層で、外部IPv6ヘッダおよびIPv6拡張ヘッダまたはBIER拡張ヘッダをカプセル化する。

まず、第1のノードは、マルチキャスト送信元からマルチキャストデータパケットを受信する。マルチキャストデータパケットのフォーマット（図5（b）のフォーマット1として示される）は、IPv6またはIPv4ヘッダ（マルチキャストデータパケットがIPv6パケットである場合、フォーマットはIPv6ヘッダを含むか、またはマルチキャストデータパケットがIPv4パケットである場合、フォーマットはIPv4ヘッダを含む）、IPv6またはIPv4ヘッダの送信元アドレスおよびIPv6またはIPv4ヘッダの送信先アドレス、そして最後にパケットペイロードを含み、IPv6またはIPv4ヘッダの送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、IPv6またはIPv4ヘッダの送信先アドレスはマルチキャストデータパケットのグループアドレスである。

第1のノードは、IPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダは第2のノードを示す事前設定情報を搬送する。あるいは、第1のノードは、BIER拡張ヘッダをカプセル化し、BIER拡張ヘッダは、第2のノードを示す事前設定情報を搬送する。

最後に、第1のノードは、転送予定BIERパケットのペイロードとしてマルチキャストデータパケットのペイロードを使用し、言い換えると、転送予定BIERパケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。

ケース2のマルチキャストデータパケットをカプセル化するプロセスにおいて、第1のノードが、内部IPv6またはIPv4ヘッダおよび転送予定BIERパケットのペイロードをカプセル化することは、理解されるべきである。図5（b）のフォーマット1および図5（b）のフォーマット2を比較することにより、カプセル化は実際に、受信したマルチキャストデータパケットを転送予定BIERパケットにカプセル化していることがわかる。さらに、第1のノードは、マルチキャストデータパケットの外層でIPv6拡張ヘッダまたはBIER拡張ヘッダをカプセル化し、次いでIPv6 Destination Option HeaderまたはBIER拡張ヘッダの外側でSRHをカプセル化し、最後にSRHの外層で外部IPv6ヘッダをカプセル化する。

まず、第1のノードは、マルチキャスト送信元からマルチキャストデータパケットを受信する。マルチキャストデータパケットのフォーマット（図5（c）のフォーマット1として示される）は、IPv6またはIPv4ヘッダ（マルチキャストデータパケットがIPv6パケットである場合、フォーマットはIPv6ヘッダを含むか、またはマルチキャストデータパケットがIPv4パケットである場合、フォーマットはIPv4ヘッダを含む）、IPv6またはIPv4ヘッダの送信元アドレスおよびIPv6またはIPv4ヘッダの送信先アドレス、そして最後にパケットペイロードを含み、IPv6またはIPv4ヘッダの送信元アドレスはマルチキャストデータパケットの送信元アドレスであり、IPv6またはIPv4ヘッダの送信先アドレスはマルチキャストデータパケットのグループアドレスである。

第1のノードは、IPv6 Destination Option Headerをカプセル化し、IPv6 Destination Option HeaderはBIERヘッダを含み、BIERヘッダは第2のノードを示す事前設定情報を搬送する。あるいは、第1のノードは、BIER拡張ヘッダをカプセル化し、BIER拡張ヘッダは、第2のノードを示す事前設定情報を搬送する。

最後に、第1のノードは、転送予定BIERパケットのペイロードとしてマルチキャストデータパケットのペイロードを使用し、言い換えると、転送予定BIERパケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。

図6では、BR 2は、SRv6およびBIER IPv6転送をサポートするルータである。たとえば、カプセル化後に取得されたBIERパケットで搬送される送信先ユニキャストアドレスはBR 2であり、送信先ユニキャストアドレスはローカルセグメント識別子（segment identifier、SID）である。BR 2は、SIDに基づいてSRHを削除することができ、IPv6ヘッダの送信先アドレスをマルチキャストグループアドレスに変更する。さらに、BR 2は、BIER IPv6ヘッダに基づいてBIERパケットを転送する。具体的には、BR 2は、マルチキャストグループアドレスに基づいてDestination Option Header内のBIER TLVを検出し、BIER TLV内のBitString情報に基づいてパケットを複製および送信する。

あるいは、PE 1は、VRF＃1の識別子およびIPv6アドレス＃1をBGP－VPN routeメッセージにカプセル化し、BGP－VPN routeメッセージをPE 2に送信する。

ステップ4：PE 2は、第1の指示メッセージを受信し、IPv6アドレスとローカルVRFとの間の対応を確立する。

たとえば、PE 2は、PE 1によって送信されたBGP－MVPN routeメッセージを受信し、PE 1によって送信されたメッセージ内のVRF＃1の識別子をPE 2上で構成されたVRF＃2の識別子と照合し、メッセージがVRF＃2に属すると判定する。したがって、PE 2は、IPv6アドレスがPE 2のVRF＃2に対応することを知る。VRF＃1の識別子をPE 2上で構成されたVRF＃2の識別子と照合することは、以下の通りであり得る。VRF＃1の識別子は、VRF＃2の識別子と一致する。したがって、PE 2は、VRF＃2がIPv6アドレスに対応すると判定する。

PE 1のIPv6アドレス＜PE 1 Addr 1＞は、BGP－MVPNルートメッセージのMP＿REACH＿NLRI属性、PTA属性、または新たに追加された別の属性で搬送され得る。

あるいは、PE 1のIPv6アドレス＜PE 1 Addr 1＞は、BGP－VPNルートメッセージのBGP－prefix SID属性内のSRv6－VPN SID TLV（詳細については、draft－ietf－idr－bgp－prefix－sid－27およびdraft－dawra－idr－srv6－vpn－04を参照されたい）で搬送されてもよく、マルチキャストフローの送信元アドレスXおよび送信先アドレスmcastXに関する情報は、BGP－MVPNルートメッセージに含まれる。

あるいは、PE 1のIPv6アドレス＜PE 1 Addr 1＞は、BGP－EVPNルートメッセージの属性で搬送されてもよい。

ステップ5：PE 1は、第2の指示メッセージを受信し、PE 2がパケットを脱カプセル化するノードであると判定する。

たとえば、PE 1は、PE 2からPE 1に送信されたBGP－MVPNルートメッセージで搬送されるパラメータを使用して、マルチキャストデータパケットの受信機PE 2および受信機PE 2のプロキシノードBRを知り得る。たとえば、BGP－MVPNルートメッセージは、送信元アドレスXおよびグループアドレスmcastX、PE 2のBFR－ID値、ならびにPE 2のIPv6アドレス＜PE 2 Addr 1＞を含む。PE 1は、PE 2からPE 1に送信されたBGP－MVPNルートメッセージおよびPE 1上にローカルで構成された事前設定構成情報を使用して、マルチキャストデータパケットの受信機PE 2および受信機PE 2のプロキシノードBR 2を知り得る。たとえば、BGP－MVPNルートメッセージは、マルチキャストデータパケットの送信元アドレスXおよびグループアドレスmcastX、PE 2のIPv6アドレス、ならびにPE 2のBFR－IDを含む。プロキシノードBR 2のものであってPE 2のIPv6アドレスに対応するIPv6アドレス情報＜BR 2 Addr 1＞が、PE 1上で構成される。

PE 1はまず、外部IPv6ヘッダ（外部IPv6ヘッダの送信元アドレスがIPv6アドレス＃1である）をカプセル化し、次いでDestination Option Headerをカプセル化し、最後に転送予定BIERパケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。PE 1は、上述のBIERパケット転送方法と同じ方法でVpnLabelをカプセル化する必要はない。

BR 2はまず、外部IPv6ヘッダ（外部IPv6ヘッダの送信元アドレスがIPv6アドレス＃1である）をカプセル化し、次いでDestination Option Headerをカプセル化し、最後に転送予定BIERパケットのペイロードとして元のマルチキャストデータパケットのIPパケットを使用する。BR 2は、上述のBIERパケット転送方法と同じ方法でVpnLabelをカプセル化する必要はない。

任意選択的に、メモリおよびプロセッサは物理的に独立したユニットであってもよく、またはメモリがプロセッサに組み込まれてもよい。

Claims (14)

1. ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワークVPNに適用されるパケット転送方法であって、
   第1のノードによって、第1のVPNの第1の識別子および第1のインターネットプロトコルバージョン6 IPv6アドレスを構成するステップであって、前記第1のIPv6アドレスが前記第1の識別子に対応する、ステップと、
   前記第1のノードによって、第1の指示メッセージを第2のノードに送信するステップであって、前記第1の指示メッセージが、前記第1のIPv6アドレスと第2の識別子との間の対応を確立するために前記第2のノードを示すために使用され、前記第1の指示メッセージが前記第1の識別子および前記第1のIPv6アドレスを含み、前記第2の識別子が、前記第2のノードのものであって前記第1の識別子との事前設定対応を満たす識別子である、ステップと、
   前記第1のノードによって、前記第1のVPNに属するマルチキャストデータパケットを受信するステップと、
   前記第1のノードによって、前記マルチキャストデータパケットが属する前記第1のVPNに基づいて、前記第1のIPv6アドレスを取得し、前記第1のIPv6アドレスは前記第1の識別子に対応する、ステップと、
   転送予定BIERパケットを取得するために、前記第1のノードによって、前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化し、前記転送予定BIERパケットを送信するステップであって、前記転送予定BIERパケットが前記第1のIPv6アドレスを含む、ステップと
   を含む方法。
2. 前記第1のノードによって、前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化する前記ステップの前に、前記方法は、
   前記第1のノードにより、前記第2のノードによって送信された第2の指示メッセージを受信するステップであって、前記第2の指示メッセージが前記第2のノードのIPv6アドレスを含む、ステップと、
   前記第1のノードによって、前記第2の指示メッセージおよび事前設定構成情報に基づいてプロキシノードのIPv6アドレスを取得するステップであって、前記事前設定構成情報が、前記第2のノードの前記IPv6アドレスと前記プロキシノードの前記IPv6アドレスとの間の対応を含む、ステップと
   をさらに含み、
   転送予定BIERパケットを取得するために前記第1のノードによって、前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化する前記ステップ、および前記転送予定BIERパケットを送信するステップは、
   前記第1のノードによって、前記転送予定BIERパケットを取得するために前記マルチキャストデータパケットの外層でIPv6ヘッダをカプセル化するステップであって、前記IPv6ヘッダの送信元アドレスが前記第1のIPv6アドレスであり、前記IPv6ヘッダの送信先アドレスが前記プロキシノードの前記IPv6アドレスである、ステップと、
   前記第1のノードによって、前記プロキシノードを通じて前記IPv6ヘッダに基づいて前記転送予定BIERパケットを前記第2のノードに送信するステップと
   を含む、請求項1に記載の方法。
3. 前記第1のノードによって、前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化する前記ステップの前に、前記方法は、
   前記第1のノードにより、前記第2のノードによって送信された第2の指示メッセージを受信するステップであって、前記第2の指示メッセージが前記第2のノードのIPv6アドレスを含む、ステップと、
   前記第1のノードによって、前記第2の指示メッセージおよび事前設定構成情報に基づいて、指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレスを取得するステップであって、前記事前設定構成情報が、前記第2のノードの前記IPv6アドレス、前記指定ノードの前記IPv6アドレス、および前記プロキシノードの前記IPv6アドレスの間の対応を含む、ステップと
   をさらに含み、
   転送予定BIERパケットを取得するために前記第1のノードによって、前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化する前記ステップ、および前記転送予定BIERパケットを送信するステップは、
   前記第1のノードによって、前記マルチキャストデータパケットの外層でセグメントルーティングヘッダSRHをカプセル化するステップであって、前記SRHがアドレスリストを搬送し、前記アドレスリストが前記指定ノードの前記IPv6アドレスおよび前記プロキシノードの前記IPv6アドレスを含む、ステップと、
   前記第1のノードによって、前記転送予定BIERパケットを取得するために前記SRHの外層でIPv6ヘッダをカプセル化するステップであって、前記IPv6ヘッダの送信元アドレスが前記第1のIPv6アドレスであり、前記IPv6ヘッダの送信先アドレスが前記指定ノードの前記IPv6アドレスである、ステップと、
   前記第1のノードによって、前記指定ノードおよび前記プロキシノードを通じて前記SRHおよび前記IPv6ヘッダに基づいて前記転送予定BIERパケットを前記第2のノードに送信するステップと
   を含む、請求項1に記載の方法。
4. ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワークVPNに適用されるパケット転送方法であって、
   第2のノードによって、第1のノードから第1の指示メッセージを受信するステップであって、前記第1の指示メッセージが、第1のIPv6アドレスおよび第1のVPNの第1の識別子を含み、前記第1のIPv6アドレスが前記第1の識別子に対応する、ステップと、
   前記第2のノードによって、前記第1のIPv6アドレスおよび前記第1の識別子に基づいて、前記第1のIPv6アドレスと第2の識別子との間の対応を確立するステップであって、前記第2の識別子が、前記第2のノードのものであって前記第1の識別子との事前設定対応を満たす識別子である、ステップと、
   前記第2のノードによって、前記第1のノードからBIERパケットを受信するステップであって、前記BIERパケットが、前記第1のIPv6アドレスおよびマルチキャストデータパケットを含む、ステップと、
   前記第2のノードによって、前記第1のIPv6アドレスおよび前記対応に基づいて、前記第2の識別子に対応するインターフェースに前記マルチキャストデータパケットを送信するステップと
   を含む方法。
5. 前記第2のノードによって前記第1のノードからBIERパケットを受信する前記ステップの前に、前記方法は、
   前記第2のノードによって、第2の指示情報を前記第1のノードに送信するステップであって、前記第2の指示情報が、前記第2のノードのIPv6アドレスを含む、ステップ
   をさらに含む、請求項4に記載の方法。
6. 前記第2のノードによって、前記第1のIPv6アドレスおよび前記対応に基づいて、前記第2の識別子に対応するインターフェースに前記マルチキャストデータパケットを送信する前記ステップは、
   前記第2のノードによって、前記第1のIPv6アドレスおよび前記対応に基づいて前記第2の識別子を取得するステップと、
   前記マルチキャストデータパケットがマルチキャスト送信元のアドレスおよびマルチキャストグループのアドレスを含むと判定した後、前記第2のノードによって、前記第2の識別子に対応する少なくとも1つのインターフェースを取得し、前記少なくとも1つのインターフェースを通じて前記マルチキャストデータパケットを送信するステップであって、前記マルチキャスト送信元の前記アドレスが、前記第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、前記マルチキャストグループの前記アドレスが、前記第2のノードが参加するマルチキャストグループのアドレスである、ステップと
   を含む、請求項4または5に記載の方法。
7. ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワークVPNに適用されるパケット送信装置であって、
   第1の仮想プライベートネットワークVPNの第1の識別子および第1のインターネットプロトコルバージョン6 IPv6アドレスを構成するように構成された処理ユニットであって、前記第1のIPv6アドレスが前記第1の識別子に対応する、処理ユニットと、
   第1の指示メッセージを第2のノードに送信するように構成された送信ユニットであって、前記第1の指示メッセージが、前記第1のIPv6アドレスと第2の識別子との間の対応を確立するために前記第2のノードを示すために使用され、前記第1の指示メッセージが前記第1の識別子および前記第1のIPv6アドレスを含み、前記第2の識別子が、前記第2のノードのものであって前記第1の識別子との事前設定対応を満たす識別子である、送信ユニットと、
   前記第1のVPNに属するマルチキャストデータパケットを受信するように構成された受信ユニットと
   を含み、
   前記処理ユニットが、前記マルチキャストデータパケットが属する前記第1のVPNに基づいて前記第1のIPv6アドレスを取得し、前記第1のIPv6アドレスは前記第1の識別子に対応するようにさらに構成されており、
   前記処理ユニットが、転送予定BIERパケットを取得するために前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化するようにさらに構成されており、前記転送予定BIERパケットが前記送信ユニットによって送信され、前記転送予定BIERパケットが前記第1のIPv6アドレスを含む、
   パケット送信装置。
8. 前記処理ユニットが前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化する前に、前記受信ユニットは、前記第2のノードによって送信された第2の指示メッセージを受信するようにさらに構成されており、前記第2の指示メッセージが前記第2のノードのIPv6アドレスを含み、前記処理ユニットが前記第2の指示メッセージおよび事前設定構成情報に基づいてプロキシノードのIPv6アドレスを取得し、前記事前設定構成情報が、前記第2のノードの前記IPv6アドレスと前記プロキシノードの前記IPv6アドレスとの間の対応を含み、
   前記処理ユニットが、転送予定BIERパケットを取得するために前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化し、前記転送予定BIERパケットが前記送信ユニットによって送信されることは、
   前記処理ユニットが、前記転送予定BIERパケットを取得するために前記マルチキャストデータパケットの外層でIPv6ヘッダをカプセル化し、前記IPv6ヘッダの送信元アドレスが前記第1のIPv6アドレスであり、前記IPv6ヘッダの送信先アドレスが前記プロキシノードの前記IPv6アドレスであり、
   前記送信ユニットが、前記プロキシノードを通じて前記IPv6ヘッダに基づいて前記転送予定BIERパケットを前記第2のノードに送信する
   ことを含む、請求項7に記載の装置。
9. 前記処理ユニットが前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化する前に、前記受信ユニットは、前記第2のノードによって送信された第2の指示メッセージを受信するようにさらに構成されており、前記第2の指示メッセージが前記第2のノードのIPv6アドレスを含み、
   前記処理ユニットが、前記第2の指示メッセージおよび事前設定構成情報に基づいて指定ノードのIPv6アドレスおよびプロキシノードのIPv6アドレスを取得し、前記事前設定構成情報が、前記第2のノードの前記IPv6アドレス、前記指定ノードの前記IPv6アドレス、および前記プロキシノードの前記IPv6アドレスの間の対応を含み、
   前記処理ユニットが、転送予定BIERパケットを取得するために前記第1のIPv6アドレスに基づいて前記マルチキャストデータパケットをカプセル化し、前記転送予定BIERパケットが前記送信ユニットによって送信されることは、
   前記処理ユニットが、前記マルチキャストデータパケットの外層でセグメントルーティングヘッダSRHをカプセル化し、前記SRHがアドレスリストを搬送し、前記アドレスリストが前記指定ノードの前記IPv6アドレスおよび前記プロキシノードの前記IPv6アドレスを含み、
   前記処理ユニットが、前記転送予定BIERパケットを取得するために前記SRHの外層でIPv6ヘッダをカプセル化し、前記IPv6ヘッダの送信元アドレスが前記第1のIPv6アドレスであり、前記IPv6ヘッダの送信先アドレスが前記指定ノードの前記IPv6アドレスであり、
   前記送信ユニットが、前記指定ノードおよび前記プロキシノードを通じて前記SRHおよび前記IPv6ヘッダに基づいて前記転送予定BIERパケットを前記第2のノードに送信する
   ことを含む、請求項7に記載の装置。
10. ビットインデックス明示的レプリケーションBIERを介したマルチキャスト仮想プライベートネットワークVPNに適用されるパケット受信装置であって、
    第1のノードから第1の指示メッセージを受信するように構成された受信ユニットであって、前記第1の指示メッセージが、第1のVPNの第1の識別子および第1のIPv6アドレスを含み、前記第1の識別子が前記第1のIPv6アドレスに対応する、受信ユニットと、
    前記第1のIPv6アドレスおよび前記第1の識別子に基づいて、前記第1のIPv6アドレスと第2の識別子との間の対応を確立するように構成された処理ユニットであって、前記第2の識別子が、第2のノードのものであって前記第1の識別子との事前設定対応を満たす識別子である、処理ユニットと
    を含み、
    前記受信ユニットが、前記第1のノードからBIERパケットを受信するようにさらに構成されており、前記BIERパケットが、前記第1のIPv6アドレスおよびマルチキャストデータパケットを含み、
    前記処理ユニットが、前記第1のIPv6アドレスおよび前記対応に基づいて、送信ユニットが、前記第2の識別子に対応するインターフェースに前記マルチキャストデータパケットを送信すると判定する、
    パケット受信装置。
11. 前記受信ユニットが前記第1のノードから前記BIERパケットを受信する前に、前記送信ユニットが、前記第1のノードに第2の指示情報を送信するようにさらに構成されており、前記第2の指示情報は、前記送信ユニットが属する前記第2のノードのIPv6アドレスを含む、請求項10に記載の装置。
12. 前記処理ユニットが、前記第1のIPv6アドレスおよび前記対応に基づいて、送信ユニットが前記第2の識別子に対応するインターフェースに前記マルチキャストデータパケットを送信すると判定することは、
    前記処理ユニットが、前記第1のIPv6アドレスおよび前記対応に基づいて前記第2の識別子を取得し、
    前記マルチキャストデータパケットがマルチキャスト送信元のアドレスおよびマルチキャストグループのアドレスを含むと判定した後、前記処理ユニットが、前記第2の識別子に対応する少なくとも1つのインターフェースを取得し、前記送信ユニットが前記少なくとも1つのインターフェースを通じて前記マルチキャストデータパケットを送信すると判定し、前記マルチキャスト送信元の前記アドレスが、前記第2のノードによって受信される必要があるマルチキャスト送信元のアドレスであり、前記マルチキャストグループの前記アドレスが、前記第2のノードが参加するマルチキャストグループのアドレスである、
    請求項10または11に記載の装置。
13. パケット転送デバイスであって、
    コンピュータプログラムを記憶するように構成されたメモリと、
    前記デバイスが請求項1から6のいずれか一項に記載のパケット転送方法を実行できるようにするために、前記メモリ内に記憶された前記コンピュータプログラムを実行するように構成されたプロセッサと
    を含む、パケット転送デバイス。
14. コンピュータプログラムを含むコンピュータ可読記憶媒体であって、前記コンピュータプログラムがコンピュータ上で実行されると、前記コンピュータが請求項1から6のいずれか一項に記載のパケット転送方法を実行できるようになる、コンピュータ可読記憶媒体。

Images