JP2021522745A - マルチキャストデータ送信方法、関連装置、およびシステム - Google Patents

Abstract

本出願は、マルチキャストデータ送信方法を開示する。本方法は、第1のBIERドメイン内の第1のBFIRによって、第2のBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を決定するステップであって、BIFT−idは、第1のBFERのBFR−idが属するSIおよび第1のBFERによってサポートされているBSLに少なくとも基づいて決定され、第1のBFERは、マルチキャストデータを受信するために使用される第2のBFERドメイン内のBFERである、ステップと、第1のBFIRによって、マルチキャストデータをBIERデータパケットにカプセル化するステップであって、BIERデータパケットのBIERヘッダは、第2のBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を含む、ステップと、最後に、第1のBFIRによって、ラベル付けされたBIERデータパケットを第2のBFIRに送信するステップであって、ラベルは、第2のBFIRのプレフィックスに対応するラベルである、ステップとを含み得る。前述のソリューションは、マルチキャスト送信の適時性を大幅に改善し得る。

Description

本出願は、マルチキャスト技術の分野、特に、マルチキャストデータ送信方法、関連装置、およびシステムに関する。

インターネットビデオサービス、仮想現実（virtual reality、VR）、および拡張現実（augmented reality、AR）などのビッグビデオサービスの開発、データセンタ（data center、DC）内およびDC間でのトラフィックの複製およびバックアップ、ならびに分散ストレージの適用に伴い、マルチキャストサービスの需要が爆発的に増加している。従来のマルチキャスト技術は、中間ネットワークにおけるマルチキャストテーブルおよびマルチキャストステータスなどの爆発的な増加をもたらし、マルチキャストネットワークの最も複雑で制御不可能な部分になる。

ビット・インデックス・エクスプリシット・レプリケーション（bit indexed explicit replication、BIER）技術は、中間ネットワークにおけるマルチキャスト転送の問題を解決する非常に簡単な方法を提供し、マルチキャスト配信を効率的に実行し得る。これは、マルチキャスト技術の主要な問題を解決する。BIER技術については、IETFドラフト「draft−ietf−bier−architecture−07」を参照されたい。ビット・インデックス・エクスプリシット・レプリケーション（BIER）は、ステートレスマルチキャストプロトコルの典型的な表現であり、以下の特性を有する。1．マルチキャスト配信ツリーを明示的に作成するために使用されるプロトコルが必要ない、2．フローごとの状態（per−flow state）を維持するために中間ノードが必要ない。

BIER技術は、完全なVPNマルチキャストを実施するために、マルチキャスト仮想プライベートネットワーク（multicast virtual private network、MVPN）、レイヤ3仮想プライベートネットワーク（layer 3 virtual private network、L3VPN）、およびイーサネット仮想プライベートネットワーク（ethernet virtual private network、EVPN）などの様々な仮想プライベートネットワーク（virtual private network、VPN）と組み合わされ得る。MVPNは、従来の仮想プライベートネットワーク（VPN）を超えて、仮想プライベートイントラネットおよび仮想プライベート広域ネットワークという2つの優れた特異な選択肢を提供するためにユビキタスインターネットを最大限に活用する。これは、シームレスに、安全に、そして簡単にリージョンとユーザを接続し得る。MVPNは、企業のリモート相互接続にとって重要なブリッジになる。したがって、BIERは、MVPNの完全なサポートを提供する必要がある。

しかしながら、BIER技術とMVPNを組み合わせた既存のソリューションでは、マルチキャスト送信は、長い収束時間および低い適時性という問題を有する。

本出願は、マルチキャスト送信の収束時間を大幅に短縮し、マルチキャスト送信の適時性を改善するために、マルチキャストデータ送信方法、関連装置、およびシステムを提供する。

第1の態様によれば、本出願は、マルチキャスト送信元側のビット転送入力ルータ（Bit−Forwarding Ingress Router、BFIR）に適用されるマルチキャストデータ送信方法を提供する。本方法は、第1のBIERドメイン内の第1のBFIRによって、第2のBIERドメインのマルチキャストデータに対応するビットインデックス転送テーブル（Bit Index Forwarding Table、BIFT）識別子（略してBIFT−id）およびビット列（BitString）を決定するステップであって、BIFT−idは、第1のビット転送出力ルータ（Bit−Forwarding Egress Router、BFER）のBFR−idが属するサブセット識別子（Set Identifier、SI）および第1のBFERによってサポートされているビット列長（BitStringLength、BSL）に少なくとも基づいて決定され、ビット列は、第1のBFERのビット転送ルータ（Bit−Forwarding Router、BFR）識別子（略してBFR−id）に少なくとも基づいて決定され、第1のBFERは、マルチキャストデータを受信するために使用される第2のBIERドメイン内のBFERである、ステップと、次に、第1のBFIRによって、マルチキャストデータをBIERデータパケットにカプセル化するステップであって、BIERデータパケットのBIERヘッダは、第2のBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を含む、ステップと、最後に、第1のBFIRによってBIERデータパケットにラベルを付け、ラベル付けされたBIERデータパケットを第2のBFIRに送信するステップであって、ラベルは、第2のBIERドメイン内の第2のBFIRのプレフィックスに対応するラベルである、ステップとを含み得る。

第1の態様では、第1のBIERドメインは、送信者が配置されているBIERドメインであり、第2のBIERドメインは、送信者が配置されていないBIERドメインであり、別のBIERドメインと呼ばれ得る。第1のBFIRは、送信者であり、マルチキャスト送信元側のBFIRである。第2のBFIRは、別のBIERドメイン内のBFIRである。第1のBFERは、マルチキャストデータを受信するために使用される別のBIERドメイン内のBFER、すなわち、マルチキャストデータに対応するマルチキャストグループに関与する別のBIERドメイン内のBFERである。ラベルは、マルチプロトコルラベルスイッチング（Multi−Protocol Label Switching、MPLS）ラベルまたは汎用ルーティングカプセル化（Generic Routing Encapsulation、GRE）ラベルであり得る。

別のBIERドメインに送信されるマルチキャストデータに関して、送信者は、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行し、ラベル（MPLSラベルまたはGREラベルなど）をBIERデータパケットに追加し、次にBIERデータパケットを別のBIERドメイン内のBFIRにユニキャストすることが分かる。

そのとき、BIERドメインにおけるマルチキャストデータ転送は、既存のBIERメカニズム転送メカニズムに準拠する。詳細については、IETFドラフトdraft−ietf−bier−mvpn−08で説明されている既存のBIER−MVPNソリューションを参照されたい。既存のBIER−MVPNソリューションとは異なり、本出願におけるマルチキャストデータ転送はセグメント式ではないことが理解され得る。BIERヘッダは送信者側でのみ構築され、中間デバイス（例えば、経路に沿った各BIERドメインのBFIRおよびBFER）は、BIERヘッダの生成に参加する必要がもはやない。このようにして、マルチキャスト転送はより効率的になる。

第1の態様において、一部の任意選択の実施形態では、送信者は、第1のマッピングテーブルから、第2のBIERドメインのマルチキャストデータに対応するビット列およびBIFT−idを具体的に決定し得る。ここで、第1のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を含み得る。少なくとも1つのBIERドメインは、第2のBIERドメインを含む。

第1の態様に関連して、一部の任意選択の実施形態では、BIERデータパケットにラベルを付ける前に、送信者は、第2のBIERドメイン内の送信者の論理ネクストホップのプレフィックスをさらに決定し得る。第2のBIERドメイン内の送信者の論理ネクストホップは、第2のBFIRである。このようにして、別のBIERドメインに関して、送信者は、直接隣接するBFR（すなわち、BFR−NBR）をネクストホップとして使用する代わりに、ネクストホップを独立して決定し得（すなわち、別のBIERドメインのBFIRをネクストホップとして使用し得）、このため、別のBIERドメインに送信されるマルチキャストデータは、送信者が配置されているBIERドメイン内のBFRによって転送される必要がない。したがって、マルチキャストデータは、MPLSまたはGREカプセル化の後、別のBIERドメイン内のBFIRに直接送信され得、転送効率が改善される。

第1の態様において、一部の任意選択の実施形態では、送信者は、第2のBIERドメイン内のマルチキャストデータに対応するBIFT−idに基づいて第2のマッピングテーブルから第2のBIERドメイン内の送信者の論理ネクストホップのプレフィックスを具体的に決定し得る。第2のBIERドメイン内の送信者の論理ネクストホップのプレフィックスは、第2のBIERドメインのマルチキャストデータに対応するBIFT−idに対応するプレフィックスである。ここで、第2のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストデータにそれぞれ対応するBIFT−idと、少なくとも1つのBIERドメイン内の第1のBFIRの論理ネクストホップのプレフィックスとを含み得る。

以下では、BIFT−id、BitString、第1のマッピングテーブル、および第2のマッピングテーブルを決定する方法について説明する。

（1）第1に、送信者は、マルチキャスト情報アドバタイズメントおよびフィードバックによって、BIERドメイン内のどのBFERがマルチキャストグループに関与するかを知り得る。本出願では、送信者は、別のBIERドメイン内のBFIRおよびBFERのそれぞれと境界ゲートウェイプロトコル（Border Gateway Protocol、BGP）ピアを形成する。マルチキャスト情報アドバタイズメントおよびフィードバックは、以下の内容を含み得る。

1．マルチキャスト情報アドバタイズメント

送信者は、BGP接続を介して別のBIERドメイン内のBFIRおよびBFERにBGPメッセージを直接送信し得、BGPメッセージは、マルチキャスト情報（例えば、マルチキャストグループアドレス）をアドバタイズするために使用されるPマルチキャストサービスインターフェース自動検出ルート（P−Multicast Service Interface Auto−Discovery route、PMSI A−D route）を運ぶ。Intra PMSI A−D routeは、BIER識別子とマルチキャストデータに対応するマルチキャストグループの識別子（例えば、マルチキャストグループ（multicast group）アドレス232．1．1．1）とを運び得る。ここで、BIER識別子は、Intra PMSI A−D routeを運ぶBGPメッセージがBIERマルチキャストメッセージであることを示すために使用される。

2．マルチキャスト情報フィードバック

これに対応して、マルチキャストグループに関与する場合、別のBIERドメイン内のBFIRおよびBFERはそれぞれ、BGP接続を介して、リーフ自動検出ルート（Leaf Auto−Discovery route、Leaf A−D route）を運ぶBGPメッセージを送信者に直接送信し得る。これに対応して、送信者は、BGP接続を介して別のBIERドメイン内のBFIRおよびBFERのそれぞれからBPGメッセージを受信し、BGPメッセージは、leaf A−D routeを運ぶ。

送信者がBIERドメイン内のどのBFERがマルチキャストグループに関与するかを知り、マルチキャストデータをBFERに転送する方法を知ることを可能にするために、leaf A−D routeは、以下の情報を運び得る。

第1に、別のBIERドメイン内のBFER（すなわち、第1のBFER）によってフィードバックされるleaf A−D routeは、第1のBFERのBFR−id、第1のBFERが属するsub−domain、第1のBFERのBFR−idが属するSI、第1のBFERによってサポートされているBSL、および第1のBFERが属するBIERドメインの識別子を運び得る。具体的には、sub−domain、SI、BSL、およびBFR−idを運ぶために使用されるフィールドが、leaf A−D routeに追加され得、拡張コミュニティ属性（「Source−AS extended community」）が、BIERドメインの識別子を示すために有効にされる。このようにして、送信者は、sub−domain、SI、およびBSLの3つのパラメータに基づいてBIFT−idを決定し得、BFR−idに基づいてBitStringを生成し得る。言い換えると、別のBIERドメイン内のBFERのBFR−id、BFR−idが属するSI、および別のBIERドメインの識別子は、別のBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を決定するために送信者によって使用され得る。次に、送信者は、BIERドメインの識別子、BIFT−id、およびBitStringに基づいて第1のマッピングテーブルを生成し得る。詳細については、以降の内容を参照されたい。

場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、第1のBFERによってフィードバックされるleaf A−D routeは、BFERが属するsub−domainを運ぶ必要はない。

場合によっては、マルチキャストドメイン全体でサポートされているBSLが同じである可能性があり、すなわち、追加の通知は不要であり、送信者もBSLを知っている。したがって、第1のBFERによってフィードバックされるleaf A−D routeは、BSLを運ぶ必要はない。

第2に、別のBIERドメイン内のBFIR（すなわち、第2のBFIR）によってフィードバックされるleaf A−D routeは、第2のBFIRのBFR−Prefixおよび第2のBFIRが属するBIERドメインの識別子を運び得る。別のBIERドメイン内のBFIRのプレフィックスおよび別のBIERドメインの識別子は、別のBIERドメインのマルチキャストデータの論理ネクストホップのプレフィックスを決定するために送信者によって使用される。このようにして、送信者は、情報に基づいて送信者の第2のマッピングテーブルを生成し得る。詳細については、以降の内容を参照されたい。

異なるBIERドメイン間のエッジBFRが、マルチキャスト情報の高速アドバタイズメントおよび高速フィードバックを実施するために、BGPピアを確立し、BGP接続を介してBGPメッセージを直接交換し得ることが分かる。言い換えると、マルチキャスト情報アドバタイズメントおよびフィードバックは、セグメントごとのBGPメッセージ交換をもはや必要とせず、BGPメッセージはドメインを越えて直接交換される。したがって、マルチキャストアドバタイズメントおよびフィードバックの収束時間が大幅に短縮され、効率が高くなる。

（2）送信者はBIFT−idを決定する。

具体的には、送信者は、各BIERドメインからleaf A−D routeで運ばれたsub−domain、SI、およびBSLに基づいて、各BIERドメイン内の特定のマルチキャストグループにそれぞれ対応するBIFT−idを決定し得る。BIFT−idは、BIFT−idによって識別されるBIFTに基づいてマルチキャストデータを転送するために各BIERドメイン内のBFR（BFIRおよびトランジットBFRを含む）によって使用される。BIFT−idは、固定長（例えば、20ビット）を有するインデックスであり、sub−domain、SI、およびBSLの3つのパラメータに基づいて決定される。1つのBIERドメインが1つのsub−domainのみで構成される場合、sub−domainは任意選択である。

別のBIERドメインのBIFT−idを決定するためのパラメータと同様に、送信者も、sub−domain、SI、およびBSLに基づいて別のBIERドメイン内の特定のマルチキャストグループに対応するBIFT−idを決定することが分かる。これは、送信者が別のBIERドメインにおけるBIERルーティングおよび転送に使用され得るBIFT−idを構築し得ることを意味する。マルチキャストドメイン全体（複数のBIERドメイン）がBIFT−idを一緒に決定する。このようにして、送信者は、別のBIERドメインで正常にルーティングおよび転送されるBIERデータパケットを生成し得る。

各BIERドメインの特定のマルチキャストグループにそれぞれ対応するBIFT−idは、各BIERドメインの特定のマルチキャストグループに対応するマルチキャストデータにそれぞれ対応するBIFT−idであることに留意されたい。

（3）送信者はBitStringを決定する。

具体的には、送信者は、各BIERドメインからleaf A−D routeで運ばれたBFR−idに基づいて、各BIERドメイン内の特定のマルチキャストグループにそれぞれ対応するBitStringを決定し得る。BitStringは、BitStringによって識別されるBFER（すなわち、受信者）にマルチキャストデータを転送するために各BIERドメイン内のBFR（BFIRおよびトランジットBFRを含む）によって使用される。

（4）送信者は第1のマッピングテーブルを生成する。

具体的には、送信者は、各BIERドメインのBIERドメイン識別子、BIFT−id、およびBitStringに基づいて第1のマッピングテーブルを生成する。第1のマッピングテーブルは、少なくとも1つのBIERドメインの特定のマルチキャストデータに対応するBIFT−idおよびBitStringを含み得る。少なくとも1つのBIERドメインは、送信者が配置されているBIERドメインと、送信者が配置されていないBIERドメイン（すなわち、別のBIERドメイン）とを含み得る。第1のマッピングテーブルは、マルチキャストグループ識別子（例えば、マルチキャストグループアドレス）と、BIERドメインの識別子、BIFT−id、およびBitStringとの対応関係を含み得る。マルチキャストグループ識別子に対応するBIERドメインの識別子、BIFT−id、およびBitStringは、BIERドメインの識別子によって表されるBIERドメインにおいて、マルチキャストグループ識別子に対応するマルチキャストデータに対応するBIFT−idおよびBitStringを表す。

本出願では、第1のマッピングテーブルは、BIERヘッダを構築するために使用され得る。マルチキャストグループのマルチキャストデータに関して、マルチキャストデータのBIERヘッダは、送信者側でのみ構築され、中間デバイスは、BIERヘッダの再構築に参加する必要はない。

（5）送信者は第2のマッピングテーブルを生成する。

別のBIERドメインに関して、送信者は、直接隣接するBFR（すなわち、BFR−NBR）をネクストホップとして使用する代わりに、ネクストホップを独立して決定する（すなわち、別のBIERドメイン内のBFIRをネクストホップとして使用する）。

特定の第2のBIERドメインに関して、BIERドメイン内の送信者のネクストホップは、BIERドメイン内の複数のBFIRであり得る、すなわち、複数のネクストホップが存在する。複数のBFIRの一部は、マルチキャストデータをBIERドメイン内のいくつかのsub−domainに転送することを担当し得、複数のBFIRの他の部分は、マルチキャストデータをBIERドメイン内のいくつかの他のsub−domainに転送することを担当し得る。このようにして、BIERドメインに送信されるマルチキャストデータに関して、送信者は、BIERドメインのマルチキャストデータに対応するBIFT−id（BIFT−idはsub−domainと1対1に対応する）に基づいて、マルチキャストデータが転送されるBFIRを決定し得る。なぜなら、BIFT−idが、マルチキャストデータが送信されるsub−domainを示し得るからである。複数のBFIRがそれぞれどのsub−domain（または複数のsub−domain）にマルチキャストデータを転送することを担当するかは、本出願では限定されず、実際の要求に基づいて決定され得る。例えば、複数のネクストホップのそれぞれによって運ばれるデータ転送量は、負荷分散の観点から設定され得る。

特定の他のBIERドメインに関して、BIERドメイン内の送信者のネクストホップは、BIERドメイン内の1つのBFIRである場合がある、すなわち、1つのネクストホップのみが存在する。BFIRは、マルチキャストデータをBIERドメイン内のすべてのターゲットsub−domainに転送することを担当し得る。ここで、ターゲットsub−domainは、マルチキャストデータの受信者が配置されているsub−domainである。

送信者は、独立して決定されたネクストホップに基づいて第2のマッピングテーブルを生成し得る。第2のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストグループにそれぞれ対応するBIFT−idと、少なくとも1つのBIERドメイン内の送信者のネクストホップのBFR−Prefixとを含み得る。少なくとも1つのBIERドメインは、送信者が配置されているBIERドメインと、送信者が配置されていないBIERドメイン（すなわち、別のBIERドメイン）とを含み得る。送信者が配置されているBIERドメインでは、既存のBIER−MVPNソリューションを参照すると、送信者のネクストホップはBFR−NBRであり得る。別のBIERドメインでは、送信者のネクストホップは、別のBIERドメインのBFIRであり得る。

任意選択で、第2のマッピングテーブルは、マルチキャストグループ識別子（例えば、マルチキャストグループアドレス）と、BIERドメインの識別子、BIFT−id、およびBFR−Prefixとの対応関係を含み得る。マルチキャストグループ識別子に対応するBIERドメインの識別子、BIFT−id、およびBFR−Prefixは、BIERドメインの識別子によって表されるBIERドメインにおいて、マルチキャストグループ識別子に対応するマルチキャストデータに対応するBIFT−idおよび論理ネクストホップのBFR−Prefixを表す。

任意選択で、第2のマッピングテーブルは、代替的に、BIFT−idとBFR−Prefixとの対応関係であり得る。このようにして、送信者は、第1のマッピングテーブルに発見されたBIFT−idを使用して、第2のマッピングテーブルでBIFT−idに対応するBFR−Prefixを発見し得る。

特定の他のBIERドメインに関して、送信者がBIERドメインに複数のネクストホップを有する場合、第2のマッピングテーブル内のBIERドメインのドメイン識別子に対応する（1つ以上の）BIFT−idは、複数のBFR−Prefixに対応するか、または送信者がBIERドメインに1つのネクストホップのみを有する場合、第2のマッピングテーブル内のBIERドメインのドメイン識別子に対応する（1つ以上の）BIFT−idは、1つのBFR−Prefixに対応する。

本出願では、第2のマッピングテーブルは、クロスドメイン（ドメイン間）転送を実施するために、マルチキャストデータをカプセル化することによって取得されたBIERデータパケットにMPLSラベルまたはGREラベルを追加するために使用され得る。

任意選択で、送信者は、マルチキャストデータを少なくとも1つのBIERドメインに送信するための出力ポートを構成し得る。第2のマッピングテーブルは、出力ポートの識別子をさらに含み得る。このようにして、送信者は、別のBIERドメインのマルチキャストデータに対応するBIFT−idに基づいて第2のマッピングテーブルから、マルチキャストデータを別のBIERドメインに送信するために使用される出力ポートの識別子を決定し得る。ここで、マルチキャストデータを別のBIERドメインに送信するために使用される出力ポートは、第1のポートと呼ばれ得る。

第2の態様によれば、本出願は、別のBIERドメイン内のBFIRに適用されるマルチキャストデータ送信方法を提供する。本方法は、第1のBIERドメイン内の第1のBFIRによって、第2のBIERドメイン内の第2のBFIRによって送信されたラベル付けされたBIERデータパケットを受信するステップであって、ラベルは、第1のBFIRのプレフィックスに対応するラベルであり、BIERデータパケットは、第2のBFIRによりマルチキャストデータをカプセル化することによって取得され、BIERデータパケットのBIERヘッダは、第1のBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を含む、ステップを含み得る。BIFT−idは、第1のBFERのBFR−idが属するSIおよび第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、ビット列は、第1のBFERのBFR−idに少なくとも基づいて決定される。第1のBFERは、第1のBIERドメインのマルチキャストデータを受信するために使用される。次に、第1のBFIRは、BIERデータパケットを取得するためにラベルを除去し、BIERデータパケットのBIERヘッダからBIFT−idおよびビット列を取得し得る。最後に、第1のBFIRは、BIFT−idおよびビット列によって示されるBIFTに基づいてBIERデータパケットを第1のBFERに転送し得る。

第2の態様では、第1のBIERドメインは、送信者が配置されていないBIERドメインであり、第2のBIERドメインは、送信者が配置されているBIERドメインである。第1のBFIRは、第1のBIERドメイン内のBFIRである。第2のBFIRは送信者であり、マルチキャスト送信元側のBFIRである。第1のBFERは、第1のBIERドメインのマルチキャストデータを受信するために使用されるBFERである。ラベルは、MPLSラベルまたはGREラベルであり得る。

別のBIERドメインに送信されるマルチキャストデータに関して、送信者は、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行し、MPLSラベルまたはGREラベルをBIERデータパケットに追加し、次にBIERデータパケットを別のBIERドメイン内のBFIRにユニキャストすることが分かる。

そのとき、BIERドメインにおけるマルチキャストデータ転送は、既存のBIERメカニズム転送メカニズムに準拠する。既存のBIER−MVPNソリューションとは異なり、本出願におけるマルチキャストデータ転送はセグメント式ではない。BIERヘッダは送信者側でのみ構築され、中間デバイス（例えば、経路に沿った各BIERドメインのBFIRおよびBFER）は、BIERヘッダの生成に参加する必要がもはやない。このようにして、マルチキャスト転送はより効率的になる。

第2の態様に関連して、一部の任意選択の実施形態では、第1のBIERドメインのマルチキャストデータに対応するBIFT−idは、第1のBFERが属するsub−domainに基づいてさらに決定される。任意選択で、場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、第1のBFERによってフィードバックされるleaf A−D routeは、BFERが属するsub−domainを運ぶ必要はない。

第2の態様に関連して、一部の任意選択の実施形態では、第2のBFIRおよび第1のBFIRは、BGPピアを形成する。本方法は、第2のBFIRによって送信された第1のBGPメッセージを、BGP接続を介して第1のBFIRによって受信するステップであって、第1のBGPメッセージで運ばれるIntra PMSI A−D routeは、BIER識別子と、マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ステップをさらに含み得る。これに対応して、第1のBFIRは、BGP接続を介して第2のBGPメッセージを第2のBFIRに送信し、第2のBGPメッセージで運ばれるleaf A−D routeは、第1のBFIRのプレフィックスおよび第1のBIERドメインの識別子を含む。このようにして、送信者は、情報に基づいて送信者の第2のマッピングテーブルを生成し得る。詳細については、第1の態様で説明された関連する内容を参照されたい。

言い換えると、異なるBIERドメイン内のBFIRは、マルチキャスト情報の高速アドバタイズメントおよび高速フィードバックを実施するために、BGPピアを確立し、BGP接続を介してBGPメッセージを直接交換し得る。言い換えると、マルチキャスト情報アドバタイズメントおよびフィードバックは、セグメントごとのBGPメッセージ交換をもはや必要とせず、BGPメッセージはドメインを越えて直接交換される。したがって、マルチキャストアドバタイズメントおよびフィードバックの収束時間が大幅に短縮され、効率が高くなる。

第3の態様によれば、本出願は、ユーザ機器側のBFERに適用されるマルチキャストデータ送信方法を提供する。本方法は、第1のBIERドメイン内の第1のBFERによって、第1のBIERドメイン内の第1のBFIRによって送信されたBIERデータパケットを受信するステップであって、BIERデータパケットは、第2のBIERドメイン内の第2のBFIRによりマルチキャストデータをカプセル化することによって取得され、BIERデータパケットのBIERヘッダは、第1のBIERドメインのマルチキャストデータに対応するBIFT−idおよびビット列を含む、ステップを含み得る。BIFT−idは、第1のBFERのBFR−idが属するSIおよび第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、ビット列は、第1のBFERのBFR−idに少なくとも基づいて決定される。第1のBFERは、第1のBIERドメインのマルチキャストデータを受信するために使用される。次に、第1のBFERは、マルチキャストデータを取得するためにBIERデータパケットをデカプセル化し、マルチキャストデータをユーザ側デバイスに送信する。

第3の態様では、第1のBIERドメインは、送信者が配置されていないBIERドメインであり、第2のBIERドメインは、送信者が配置されているBIERドメインである。第1のBFIRは、第1のBIERドメイン内のBFIRである。第2のBFIRは送信者であり、マルチキャスト送信元側のBFIRである。第1のBFERは、第1のBIERドメインのマルチキャストデータを受信するために使用されるBFERである。ラベルは、MPLSラベルまたはGREラベルであり得る。

別のBIERドメインに送信されるマルチキャストデータに関して、送信者は、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行し、MPLSラベルまたはGREラベルをBIERデータパケットに追加し、次にBIERデータパケットを別のBIERドメイン内のBFIRにユニキャストすることが分かる。

そのとき、BIERドメインにおけるマルチキャストデータ転送は、既存のBIERメカニズム転送メカニズムに準拠する。既存のBIER−MVPNソリューションとは異なり、本出願におけるマルチキャストデータ転送はセグメント式ではない。BIERヘッダは送信者側でのみ構築され、中間デバイス（例えば、経路に沿った各BIERドメインのBFIRおよびBFER）は、BIERヘッダの生成に参加する必要がもはやない。このようにして、マルチキャスト転送はより効率的になる。

第3の態様に関連して、一部の任意選択の実施形態では、第2のBFIRおよび第1のBFERは、BGPピアを形成する。本方法は、第2のBFIRによって送信された第1のBGPメッセージを、BGP接続を介して第1のBFERによって受信するステップであって、第1のBGPメッセージで運ばれるIntra PMSI A−D routeは、BIER識別子と、マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ステップをさらに含み得る。これに対応して、第1のBFERは、BGP接続を介して第2のBGPメッセージを第2のBFIRに送信し、第2のBGPメッセージで運ばれるleaf A−D routeは、第1のBFERのBFR−id、第1のBFERのBFR−idが属するSI、および第1のBIERドメインの識別子を含む。このようにして、送信者は、情報に基づいて第1のマッピングテーブルを生成し得る。詳細については、第1の態様で説明された関連する内容を参照されたい。

言い換えると、送信者と別のBIERドメイン内のBFERが、マルチキャスト情報の高速アドバタイズメントおよび高速フィードバックを実施するために、BGPピアを確立し、BGP接続を介してBGPメッセージを直接交換し得る。言い換えると、マルチキャスト情報アドバタイズメントおよびフィードバックは、セグメントごとのBGPメッセージ交換をもはや必要とせず、BGPメッセージはドメインを越えて直接交換される。したがって、マルチキャストアドバタイズメントおよびフィードバックの収束時間が大幅に短縮され、効率が高くなる。

第3の態様に関連して、一部の任意選択の実施形態では、第1のBIERドメインのマルチキャストデータに対応するBIFT−idは、第1のBFERが属するsub−domainに基づいてさらに決定される。任意選択で、第1のBFERによってフィードバックされるleaf A−D routeは、第1のBFERが属するsub−domainをさらに運び得る。言い換えると、第2のBGPメッセージで運ばれるleaf A−D routeは、第1のBFERが属するsub−domainをさらに含み得る。任意選択で、場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、第1のBFERによってフィードバックされるleaf A−D routeは、BFERが属するsub−domainを運ぶ必要はない。

第3の態様に関連して、一部の任意選択の実施形態では、第2のBGPメッセージで運ばれるleaf A−D routeは、第1のBFERによってサポートされているBSLをさらに含み得る。任意選択で、マルチキャストドメイン全体でサポートされているBSLが同じである可能性があり、すなわち、追加の通知は不要であり、送信者もBSLを知っている。したがって、第1のBFERによってフィードバックされるleaf A−D routeは、BSLを運ぶ必要はない。

第4の態様によれば、本出願はルータを提供する。ルータは、第1の態様で提供されるマルチキャストデータ送信方法、または第1の態様の可能な実施態様のいずれか1つで提供されるマルチキャストデータ送信方法をそれ相応に実行するように構成された複数の機能モジュールまたはユニットを含み得る。

第5の態様によれば、本出願は、ルータを提供する。ルータは、第2の態様で提供されるマルチキャストデータ送信方法、または第2の態様の可能な実施態様のいずれか1つで提供されるマルチキャストデータ送信方法をそれ相応に実行するように構成された複数の機能モジュールまたはユニットを含み得る。

第6の態様によれば、本出願は、ルータを提供する。ルータは、第3の態様で提供されるマルチキャストデータ送信方法、または第3の態様の可能な実施態様のいずれか1つで提供されるマルチキャストデータ送信方法をそれ相応に実行するように構成された複数の機能モジュールまたはユニットを含み得る。

第7の態様によれば、本出願は、第1の態様で説明されたマルチキャストデータ送信方法を実行するように構成されたルータを提供する。ルータは、メモリ、ならびにメモリに結合されたプロセッサおよびトランシーバを含み得る。トランシーバは、別の通信デバイスと通信するように構成される。メモリは、第1の態様で説明されたマルチキャストデータ送信方法を実施するためのコードを記憶するように構成される。プロセッサは、メモリに記憶されたプログラムコードを実行する、すなわち、第1の態様で提供されるマルチキャストデータ送信方法、または第1の態様の可能な実施態様のいずれか1つで提供されるマルチキャストデータ送信方法を実行するように構成される。

第8の態様によれば、本出願は、第2の態様で説明されたマルチキャストデータ送信方法を実行するように構成されたルータを提供する。ルータは、メモリ、ならびにメモリに結合されたプロセッサおよびトランシーバを含み得る。トランシーバは、別の通信デバイスと通信するように構成される。メモリは、第2の態様で説明されたマルチキャストデータ送信方法を実施するためのコードを記憶するように構成される。プロセッサは、メモリに記憶されたプログラムコードを実行する、すなわち、第2の態様で提供されるマルチキャストデータ送信方法、または第2の態様の可能な実施態様のいずれか1つで提供されるマルチキャストデータ送信方法を実行するように構成される。

第9の態様によれば、本出願は、第3の態様で説明されたマルチキャストデータ送信方法を実行するように構成されたルータを提供する。ルータは、メモリ、ならびにメモリに結合されたプロセッサおよびトランシーバを含み得る。トランシーバは、別の通信デバイスと通信するように構成される。メモリは、第3の態様で説明されたマルチキャストデータ送信方法を実施するためのコードを記憶するように構成される。プロセッサは、メモリに記憶されたプログラムコードを実行する、すなわち、第3の態様で提供されるマルチキャストデータ送信方法、または第3の態様の可能な実施態様のいずれか1つで提供されるマルチキャストデータ送信方法を実行するように構成される。

第10の態様によれば、通信システムが提供され、通信システムは、第1のルータおよび第2のルータを含み得る。第1のルータは、第5の態様で説明されたルータであり得、第2のルータは、第6の態様で説明されたルータであり得る。通信システムは、第3のルータをさらに含み得、第3のルータは、第4の態様で説明されたルータであり得る。

任意選択で、第1のルータは、第8の態様で説明されたルータであり得、第2のルータは、第9の態様で説明されたルータであり得、第3のルータは、第7の態様で説明されたルータであり得る。

第11の態様によれば、コンピュータ可読記憶媒体が提供される。可読記憶媒体は命令を記憶し、命令がコンピュータ上で実行されるとき、コンピュータは、第1の態様、第2の態様、または第3の態様で説明されたマルチキャストデータ送信方法を実行することが可能である。

第12の態様によれば、命令を含むコンピュータプログラム製品が提供される。コンピュータプログラム製品がコンピュータ上で実行されるとき、コンピュータは、第2の態様または第3の態様で説明されたマルチキャストデータ送信方法を実行することが可能である。

本出願の実施形態または背景技術における技術的ソリューションをより明確に説明するために、以下では、本出願の実施形態または背景技術を説明するための添付の図面について簡単に説明する。

本出願によるBIERアーキテクチャの概略図である。 本出願によるBIERヘッダのデータ構造の概略図である。 BIERドメインにおけるトポロジ構造の例示的な概略図である。 BIERドメインにおけるマルチキャスト情報アドバタイズメントおよびフィードバックの概略図である。 BIERドメイン内のBFERがマルチキャストグループに参加するフィードバックを与える概略図である。 本出願によるBIER−MVPNの適用シナリオの概略図である。 既存のBIER−MVPNソリューションの概略フローチャートである。 既存のBIER−MVPNソリューションの概略フローチャートである。 マルチキャスト情報アドバタイズメントおよびフィードバックの既存のプロセスの概略図である。 本出願による拡張Intra PMSI A−D routeのデータ構造の概略図である。 既存のMVPNフレームワークにおけるマルチキャストデータ送信モードの概略図である。 本出願に従って最下層ラベルマッピングによってTCP接続を確立する概略図である。 本出願に従ってBGPピアを確立する概略図である。 本出願による、ドメインを越えてのマルチキャスト情報アドバタイズメントおよびフィードバックの概略図である。 本出願によるマルチキャストデータ送信方法の概略図である。 本出願によるマルチキャストデータ送信方法の概略図である。 本出願による、拡張Intra PMSI A−D routeで運ばれるマルチキャスト情報の概略図である。 別のBIERドメイン内の受信者BFERによってフィードバックされる拡張leaf A−D routeのデータ構造の概略図である。 別のBIERドメイン内のBFIRによってフィードバックされる拡張leaf A−D routeのデータ構造の概略図である。 本出願によるBIFT−idのデータ構造の概略図である。 本出願に従って送信者によって各BIERドメインからBIER情報を受信する概略図である。 本出願による第1のマッピングテーブルの概略図である。 本出願による、送信者の第2のマッピングテーブルの概略図である。 本出願に従って送信者によってマルチキャストデータを転送する動作原理の概略図である。 本出願によるマルチキャストドメインにおけるマルチキャストデータ転送の概略図である。 本出願による別のマルチキャストデータ送信方法の概略フローチャートである。 本出願による別のマルチキャストデータ送信方法の概略フローチャートである。 本出願によるルータの概略構造図である。 本出願による通信システムおよび関連装置の概略構造図である。

本出願の実施態様で使用される用語は、本出願の特定の実施形態を説明するためにのみ使用され、本出願を限定することを意図されていない。

図1は、本出願のBIERアーキテクチャを示している。BIERアーキテクチャでは、BIERをサポートするルータは、ビット転送ルータ（Bit−Forwarding Router、BFR）と呼ばれる。BIER制御プレーンプロトコルは、BIERドメインで実行され、BIERドメイン内のBFRがBIER転送メカニズムを使用してBFR間でBIERデータパケットの転送に関する情報を交換することを可能にする。

図1に示されているように、BIERドメインは、以下のルータ、すなわち、ビット転送入力ルータ（Bit−Forwarding Ingress Router、BFIR）101、ビット転送出力ルータ（Bit−Forwarding Egress Router、BFER）105、およびトランジットBFR（transit BFR）103を含み得る。具体的には、マルチキャストデータパケットは、ビット転送入力ルータ（BFIR）101でBIERドメインに入り、ビット転送出力ルータ（BFER）105でBIERドメインを出る。トランジットBFRは、同じBIERドメイン内の別のBFRからマルチキャストデータパケットを受信し、マルチキャストデータパケットを同じBIERドメイン内の別のBFRに転送するために使用される。一部のマルチキャストトラフィック（multicast traffic）では、単一のBFRがBFIRであり得る。一部の他のマルチキャストトラフィックでは、単一のBFRがBFERであり得る。さらに一部の他のマルチキャストトラフィックでは、単一のBFRがトランジットBFRであり得る。実際、所与のデータパケットに関して、BFRは、BFIRおよび／またはトランジットBFRおよび／またはBFRに対応するBFERのうちの1つであり得る。

BIERドメインは、1つ以上のサブドメイン（sub−domain）を含み得る。sub−domain識別子（sub−domain−idとして表される）は、sub−domainごとに構成され、sub−domain−idは範囲［0，255］内にある。特定のBFRが属するsub−domainに関して、BFRがBFIR／BFERとして機能し得る場合、BFRには1つのBFR−idがプロビジョニングされ、BFR−idは、sub−domain内で一意である。例えば、BIERのsub−domainが、1374個のBFRを含む場合、各BFRには1つのBFR−id（1から1374の範囲の）がプロビジョニングされ得る。特定のBFRが複数のsub−domainに属する場合、BFRは、（必ずではないが）複数のsub−domainに、異なるBFR−idを有してもよい。さらに、各BFRには、BFRが属するsub−domainの「BFRプレフィックス（BFR−Prefix）」がプロビジョニングされる。BFRのBFRプレフィックスは、BFRのIPアドレス（IPv4またはIPv6）である。所与のBFRのBFRプレフィックスは、BFRが属するsub−domainでルーティング可能である。

マルチキャストデータパケットが外部からBFIRでBIERドメインに入ると、BFIRは、マルチキャストデータパケットが送信されるBFERのセットと、データパケットが送信されるsub−domainとを決定する。BFIRがマルチキャストデータパケットに関してBFERセットおよびsub−domainを決定すると、BFIRは、BIERヘッダを使用してマルチキャストデータパケットに対してBIERカプセル化を実行する。言い換えると、マルチキャストデータパケットは、BIERデータパケットにカプセル化された後にのみ、BIERドメインで転送され得る。図2に示されているように、BIERカプセル化に使用されるBIERヘッダの形式は、BIFT−idおよびBitStringを含み得る。BIFT−idは、ビットインデックス転送テーブル（Bit Index Forwarding Table、BIFT）識別子であり、BFRがBIERデータパケットを転送するために検索する特定のBIFTを示すために使用される。BitString（ビット列と呼ばれる）は、BIERドメイン内のマルチキャストデータの受信者を表し、BitString内の各ビットは、1つのBFR−idを表す。マルチキャストグループに参加する特定のBFERを示すために、BFIRは、BitString内の特定のBFERのBFR−idに対応するビットを設定し得る。例えば、BitString「0110」は、マルチキャストグループ内の受信者がBFR−idが2のBFERおよびBFR−idが3のBFERであることを表す。

以下では、BIERドメインのマルチキャスト転送メカニズムに関わる重要な技術、すなわち、BIFTおよびBitStringについて説明する。

（1）BIFT

1．BFR−idおよびBFR−Prefixのアドバタイズ

BIERドメインでは、各BFERが、BFERのBFR−idを他のすべてのBFRにアドバタイズする。例えば、BFR−idは、不透明リンク状態アドバタイズメント（opaque link state advertisement、opaque LSA）メッセージを使用してアドバタイズされ得、BIER情報（sub−domainおよびBFR−idなど）を運ぶための拡張フィールドが、メッセージに追加される。opaque LSAは、IBGPプロトコルを実行するためのオプションである。同様に、各BFRは、BFRのBFR−Prefixを他のすべてのBFRにアドバタイズする。

2．BFRは、最初にビットインデックスルーティングテーブル（Bit Index Routing Table、BIRT）を生成する

ビットインデックスルーティングテーブル（BIRT）は、BFERのBFR−idからBFERのBFR−Prefixと、BFERへの経路上のBFRネイバー（BFR neighbour、BFR−NBR）とにマッピングするテーブルである。

図3に示されているBIERトポロジが例として使用される。図3では、各BFRのBFR−idは、SI：BitStringの形式で表され得る。SIは、BFR−idが属するサブセット識別子（Set Identifier）を表す。SIとBitstringの両方は、BFR−idを変換することによって取得され、変換は、パラメータ「ビット列長（BitStringLength、BSL）」に基づいて決定される。例えば、ビット列長（BSL）は4であると想定される。BFR−idが1である場合に、SIが0であるとき、Bitstringは「0001」である。BFR−idが2である場合に、SIが0であるとき、Bitstringは「0010」である。ここで、SIがBSLより大きくない場合、SIは0に等しい。例は、本出願を説明するためにのみ使用されており、限定として解釈されるではない。

図3に示されているトポロジでは、表1に示されているBIRTは、BFR−Bで生成される。1番目の列は、BFR−Bが到達し得るBFER（BFER−A、BFER−E、BFER−F、およびBFER−D）のBFR−idを表す。2番目の列は、BFR−Bが到達し得るBFERのBFR−Prefixを表す。3番目の列は、BFR−BがBFERに到達する経路上のBFR−NBR（ネクストホップである）を表す。

3．BFRは、BIRTに基づいてビットインデックス転送テーブル（BIFT）を生成する

BIRTのいくつかの行が同じSIおよび同じBFR−NBRを有すると想定した場合、BIFTのビットマスク（bit mask）、すなわちF−BMは、これらのいくつかの行のBFR−idに対応するBitStringに対して論理OR演算を実行することによって取得され得る。

例えば、表2は、表1に基づいて生成されたBFR−BのBIFTを示している。BIFTは、BFERのBFR−idから対応するF−BMおよびBFR−NBRにマッピングするために使用される。F−BMは、BFR−Bの各BFR−NBRから到達可能なBFERを表す。ビットマスク（F−BM）「0011」は、表1に示されているBIRT内の同じSI（0）および同じBFR−NBR（BFR−C）を有する2つの行のBitStringに対して論理OR演算を実行することによって取得され得ることが分かる。

BIERドメイン内のすべてのBFIRおよびトランジットBFRがそれぞれのBIFTを生成すると、BIERドメイン内のBFIRおよびトランジットBFRは、受信されたBIERデータパケットのBIERヘッダに基づいてマルチキャスト転送を実行し得る。

（2）BitString

BFIRは、どのBFERが特定のマルチキャストグループに関与するかを知る必要がある。このようにして、BFIRは、マルチキャストグループに対応するマルチキャストデータが送信されるBFERを決定し得る。特定のマルチキャストグループに関与するBFERは、BFIRによって特定のマルチキャストグループの受信者として決定される。特定のマルチキャストグループの受信者は、特定のマルチキャストグループに対応するマルチキャストデータの受信者である。

MVPNでは、BFIRとBFERの両方がプロバイダエッジ（Provider Edge、PE）デバイスであり、BFIRとBFERは、境界ゲートウェイプロトコル（Border Gateway Protocol、BGP）メッセージを使用してマルチキャスト情報（例えば、マルチキャストグループアドレス）を交換する。図4は、BIERドメインにおけるマルチキャスト情報アドバタイズメントおよびフィードバックのプロセスを示している。図4に示されているように、BIERドメインでは、BFIRは、マルチキャスト情報をBFERに通知するために、Pマルチキャストサービスインターフェース自動検出ルート（P−Multicast Service Interface Auto−Discovery route、PMSI A−D route）を運ぶBGPメッセージを送信する。これに対応して、マルチキャスト情報によって表されるマルチキャストグループに関与するBFERは、リーフ自動検出ルート（Leaf A−D route）を運ぶBGPメッセージを使用してフィードバックを与える。

例えば、図5に示されているように、BFIRがマルチキャストグループの受信者（BFER）を知った後、BFIRは、表3に示されているマルチキャスト受信者テーブルを生成し得る。表3に示されているマルチキャストグループ受信者テーブルでは、Receiverは、マルチキャストグループG1の受信者のPrefixを表し、Group IDは、マルチキャストグループ識別子であり、Joinedは、BFERがマルチキャストグループG1に参加するかどうかを表す。

次に、BFIRは、マルチキャストグループの受信者のBFR−idに基づいてBitStringを決定し得る。例えば、表2に示されているように、マルチキャストグループG1の受信者は、BFER−B（BFR−idが2）およびBFER−C（BFR−idが3）である。BFIRは、BFER−BのBFR−idを「0010」に変換し、BFER−CのBFR−idを「0100」に変換し、次に、BitString「0110」を取得するために、「0010」および「0100」に対して論理OR演算を実行する。

前述の内容で言及されていないBIER技術の部分については、IETF BIER＿ARCHを参照されたい。ここでは詳細は説明されない。

広く使用される次世代マルチキャストプロトコルになるには、BIER技術がMVPNを完全にサポートする必要がある。図6は、BIER−MVPN適用シナリオの例を示している。マルチキャストドメインは、複数のBIERドメイン（例えば、BIERドメイン100、BIERドメイン200、およびBIERドメイン300）を含み得る。マルチキャストデータは、送信者（マルチキャスト送信元側のBFIR）から送信される必要があり、複数回のBIERドメイン内転送およびBIERドメイン間転送を経て、最終的に各受信者（ユーザ側BFER）に到達する。マルチキャストドメイン全体の観点からは、BIERドメインは自律システム（autonomous system、AS）と同等である。BIERドメイン間のBFIRおよびBFERは、自律システム境界ルータ（自律システム境界ルータ、ASBR）とも呼ばれる。

例として図6に示されているBIER−MVPN適用シナリオを使用して、図7Aおよび図7Bは、BIER技術が使用される既存のMVPNドラフト（以下では、略して既存のBIER−MVPNソリューションと呼ばれる）（draft−ietf−bier−mvpnを参照されたい）を示している。ドラフトは、マルチキャストドメイン全体でマルチキャストデータを転送するための方法を提供する。詳細は以下の通りである。

（1）フェーズ1（S101）：BIERドメイン内のBFIRおよびBFRは、それぞれのBIFTを生成する。

前述の内容で説明された重要な技術的ポイント「BIFT」から、BIERドメインでは、BFIRおよびBFRがそれぞれ、各BFERに到達するBIFTを生成し得ることが知られ得る。BIERドメイン内のBFERは、BFERが属するsubdomain、BFERのBFR−idが属するSI、およびBFERによってサポートされているBSLを暗黙的に示すために、BIFTのBIFT−idをさらにアドバタイズする。言い換えると、BIFT−idであって、これに基づいてマルチキャストデータがBFERに転送される、BIFT−idは、BFERが属するsubdomain、BFERのBFR−idが属するSI、およびBFERによってサポートされているBSLの3つのパラメータに基づいて決定される。

さらに、BFIRは、BFIRが配置されているBIERドメイン内のBFERのBFR−PrefixとBFR−idとの対応関係を含むテーブルをさらに生成し得る。

BIERドメイン内のBFIRおよびBFRは、それぞれのBIFTを生成する。したがって、BIERデータパケットを受信した後、BFIRおよびBFRは、BIERヘッダ内のBIFT−idおよびBitStringに基づいてマルチキャストモードでBIERデータパケットを転送し得る。BIFT−idは、BIERルータがマルチキャストデータを転送するために検索するBIFTを示すために使用される。BitStringは、マルチキャストデータのすべての受信者（BFER）のBFR−idを表す。

（2）フェーズ2（S102〜S107）：マルチキャスト情報アドバタイズメントおよびフィードバック

マルチキャスト情報アドバタイズメントは、BIERドメイン内のどのBFERがマルチキャストグループに関与するかを知るためにBIERドメイン内のBFIRによって使用され、BIERドメイン内マルチキャスト情報アドバタイズメントおよびフィードバックならびにBIERドメイン間マルチキャスト情報アドバタイズメントおよびフィードバックを含む。図8は、マルチキャスト情報アドバタイズメントおよびフィードバックのプロセスを示している。図8のリソース予約プロトコル（Resource Reservation Protocol、RSVP）とマルチキャストラベル配布プロトコル（multicast label distribution protocol、MLDP）の両方は、ラベル配布を実施するために使用され得る。入力複製（Ingress Replication、IR）（ヘッドエンド複製とも呼ばれる）プロトコルは、ポイントツーマルチポイントデータ転送、例えばフラッディング転送を実施するために使用され得る。詳細は以下の通りである。

S102：BIERドメイン100でマルチキャスト情報アドバタイズメントを実行する。

図8に示されているように、送信者は、マルチキャスト情報をアドバタイズするために、ドメイン内BGPメッセージを使用してBIERドメイン100内のBFERにIntra PMSI A−D routeを送信する。BIERドメイン100内のBFERが、マルチキャスト情報によって表されるマルチキャストグループ（multicast group）に関与する場合、BFERは、送信者のマルチキャストトンネルに参加することを送信者に通知するために、leaf A−D routeをフィードバックする必要がある。

既存のBIER−MVPNソリューションでは、図9に示されているように、送信者は、Intra PMSI A−D routeを運ぶBGPメッセージがBIERマルチキャストメッセージであることを示すために、Intra PMSI A−D routeのPMSIトンネル属性（PMSI Tunnel Attribute）にBIER識別子を追加する必要がある。

S103：BIERドメイン100でマルチキャストフィードバックを実行する。

図8に示されているように、送信者によって送信されたIntra PMSI A−D routeを運ぶドメイン内BGPメッセージが受信された後、BIERドメイン100内のBFERが、マルチキャスト情報によって表されるマルチキャストグループに関与する場合、BFERは、ドメイン内BGPメッセージを使用してleaf A−D routeを送信者にフィードバックし、leaf A−D routeは、BFERのBFR−Prefixを運ぶ。特に、BIERドメイン100内のASBR1が、送信者によって送信されたIntra PMSI A−D routeを受信した後、マルチキャスト情報を別のBIERドメインにフラッディングするために、ASBR1は、BGPメッセージを使用してleaf A−D routeを送信者にフィードバックする必要がある。ここで、マルチキャストグループに関与するBFERは、マルチキャストグループの受信者である。

このようにして、送信者は、受信者のBFR−Prefixに基づいて受信者のBFR−idを発見し、次に、受信者のBFR−idに基づいて、BIERドメイン100のマルチキャストグループに対応するBitStringを決定し得る。さらに、S101では、送信者は、マルチキャストデータを異なるBFR−idを有するBFERに送信するために必要なBIFT−idを知り得る。BitStringおよびBFIT−idは、BIERヘッダの2つの最も重要な要素であり、BIERドメイン100でBIERデータパケットを受信するBFRがマルチキャストグループデータをどのように転送するかを示すために使用される。

S104：BIERドメイン間マルチキャスト情報アドバタイズメントを実行する。

図8に示されているように、BIERドメイン100内のASBR1が、送信者によって送信されたIntra PMSI A−D routeを受信した後、ASBR1は、Intra PMSI A−D routeを解析し、マルチキャストグループおよびMVPN情報を記録し、BFERを送信元として使用するドメイン間BGPメッセージを生成する。次に、ASBR1は、ドメイン間BGPメッセージを使用してフラッディング方式で、ASBR2などの、ASBR1のすべての外部境界ゲートウェイプロトコル（External Border Gateway Protocol、eBGP）ピアにInter PMSI A−D routeを送信する。

S105：BIERドメイン間マルチキャスト情報フィードバックを実行する。

図8に示されているように、ASBR2が、ASBR1によって送信されたInter PMSI A−D routeを受信した後、マルチキャスト情報を別のBIERドメイン内のBFRにフラッディングするために、ASBR2は、leaf A−D routeをASBR1にフィードバックする必要があり、leaf A−D routeは、ASBR2のBFR−Prefixを運ぶ。このようにして、ASBR1は、マルチキャストグループと受信者のBFR−Prefixとの対応関係を含むテーブルを生成し得、これにより、ASBR1は、マルチキャストデータが到達したときにマルチキャストデータが送信されるASBRを知り得る。BIERドメイン間転送は、BIERドメイン内転送とは異なり、ドメイン間マルチキャストデータ転送中に、BIERカプセル化は実行されないが、ラベルが追加されることに留意されたい。詳細は以下の内容で説明される。

S106：BIERドメイン200でマルチキャストアドバタイズメントを実行する。

図8に示されているように、ASBR2は、送信者からのマルチキャスト情報をアドバタイズするために、ドメイン内BGPメッセージを使用してBIERドメイン200内のBFERにIntra PMSI A−D routeを送信する。BIERドメイン200におけるマルチキャスト情報アドバタイズメントメカニズムは、BIERドメイン100におけるマルチキャスト情報アドバタイズメントメカニズムと同じである。詳細については、S102を参照されたい。

S107：BIERドメイン200でマルチキャストフィードバックを実行する。

図8に示されているように、ASBR2によって送信されたIntra PMSI A−D routeを運ぶドメイン内BGPメッセージが受信された後、BIERドメイン200内のBFERが、マルチキャスト情報によって表されるマルチキャストグループに関与する場合、BFERは、ドメイン内BGPメッセージを使用してleaf A−D routeを送信者にフィードバックし、leaf A−D routeは、BFERのBFR−Prefixを運ぶ。ここで、マルチキャストグループに関与するBFERは、マルチキャストグループの受信者である。

このようにして、ASBR2は、受信者のBFR−Prefixに基づいて受信者のBFR−idを発見し、次に、受信者のBFR−idに基づいて、BIERドメイン200のマルチキャストグループに対応するBitStringを決定し得る。さらに、S101では、ASBR2は、マルチキャストデータを異なるBFR−idを有するBFERに送信するために必要なBIFT−idを知り得る。BitStringおよびBFIT−idは、BIERヘッダの2つの最も重要な要素であり、BIERドメイン200でBIERデータパケットを受信するBFRがマルチキャストデータをどのように転送するかを示すために使用される。

S102からS107に基づいて、マルチキャスト情報アドバタイズメントおよびフィードバックは以下のように要約される。

1．BIERドメイン内マルチキャスト情報アドバタイズメントおよびフィードバック（S102〜S103およびS106〜S107）
a．BFIRは、マルチキャスト情報をアドバタイズするために、ドメイン内BGPメッセージを使用してIntra PMSI A−D route（追加されたBIER識別子を有する）をBFERに送信する。
b．マルチキャストグループに関与するBFERは、ドメイン内BGPメッセージを使用してleaf A−D route（BFERのprefixを運ぶ）をBFIRにフィードバックする。このようにして、BFIRは、BFERのBFR−Prefixに基づいてBFERのBFR−idを発見し、次に、ドメイン内のどのBFERがマルチキャストグループ（すなわち、受信者）に関与するかを知り、ドメインのマルチキャストグループに対応するBitStringを決定する。さらに、ステップ1では、BFIRは、マルチキャストグループを受信者に送信するために必要なBIFT−idをさらに発見し得る。BIFT−idおよびBitStringは、BIERヘッダの2つの最も重要な要素であり、BIERデータパケットを受信するBFRがドメインでマルチキャストグループをどのように転送するかを示すために使用される。BitStringの効果はBIERドメインに限定されており、BitStringは特定のBIERドメインのマルチキャストグループの受信者のみを示し得ることが分かる。

2．BIERドメイン間マルチキャスト情報アドバタイズメントおよびフィードバック（S104〜S105）
a．BIERドメイン内のBFER（BIERドメイン100内のASBR1など）は、マルチキャストアドバタイズメントを実行するために、ドメイン間BGPメッセージを使用してInter PMSI A−D route（追加されたBIER識別子を有する）を別の隣接するBIERドメイン内のBFIR（BIERドメイン200内のASBR2など）に送信する。
b．別のBIERドメイン内のBFIRは、ドメイン間BGPメッセージを使用してleaf A−D route（BFIRのBFR−Prefixを運ぶ）をBIERドメイン内のBFERにフィードバックする。このようにして、BFERは、マルチキャストグループとBFIRのBFR−Prefixとの対応関係を含むテーブルを生成し、マルチキャストデータが到達したときに特定のマルチキャストグループに対応するマルチキャストデータが送信されるBFIRを知り得る。

既存のBIER−MVPNソリューションでは、マルチキャスト情報は、セグメント化された方法でアドバタイズおよびフィードバックされることが分かる。同じマルチキャスト情報に関して、異なるBIERドメインは、最終的にマルチキャスト情報を各ドメイン内のBFERにアドバタイズするために、それぞれBGPメッセージを生成する必要がある。このようにして、マルチキャスト情報アドバタイズメントおよびフィードバックの収束時間は非常に長く、効果は低くなっている。

（3）マルチキャストデータ転送（ステップ8からステップ10）：ドメイン内転送およびドメイン間転送

既存のBIER−MVPNソリューションにマルチキャストデータ転送方法を導入する前に、MVPNフレームワークにおけるセグメントベースのドメイン間マルチキャスト送信方法が最初に導入される。例えば、図10に示されているように、送信者がマルチキャストデータを送信する必要があるとき、送信者は、マルチキャストデータのドメイン内トンネルに対応するマルチプロトコルラベルスイッチング（Multi−Protocol Label Switching、MPLS）ヘッダをカプセル化し、AS100において、AS100内のPEおよびASBR1にデータを送信するために、MPLSヘッダでカプセル化されたマルチキャストデータに対してMPLSラベル転送を実行し得る。次に、ASBR1は、MPLSヘッダでカプセル化された受信されたマルチキャストデータを解析し、マルチキャストデータの対応するドメイン間トンネルに対応する汎用ルーティングカプセル化（Generic Routing Encapsulation、GRE）ヘッダを再カプセル化し、AS200内のASBR2にデータを送信するために、ドメイン間で、GREヘッダでカプセル化されたマルチキャストデータに対してGREラベル転送を実行する。次に、ASBR2は、GREヘッダでカプセル化された受信されたマルチキャストデータを解析し、マルチキャストデータの対応するドメイン内トンネルに対応するMPLSヘッダを再カプセル化し、AS200において、受信者PEにデータを送信するために、MPLSヘッダでカプセル化されたマルチキャストデータに対してMPLSラベル転送を実行し得る。最後に、受信者PEは、MPLSヘッダを除去し、マルチキャストデータをユーザ側デバイスに転送する。

MVPNフレームワークにおけるセグメントベースのドメイン間マルチキャスト送信方法とは異なり、既存のBIER−MVPNソリューションでは、マルチキャストデータを転送するためにBIERドメインでBIER転送メカニズムが使用される。詳細は以下の通りである。

S108：BIERドメイン100でマルチキャストデータ転送を実行する。

具体的には、マルチキャストデータが到達すると、送信者は、BIERドメイン100のマルチキャストデータに対応するBitStringを検索し、BitStringは、S103で決定される。さらに、送信者は、マルチキャストデータをBIERドメイン100内の受信者に転送するために必要なBIFT−idをさらに決定する必要があり、BIFT−idは、S101で既に決定されている。次に、送信者は、BitStringおよびBIFT−idを使用してBIERヘッダを生成し、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行する。このようにして、BIERドメイン100内の送信者およびトランジットBFRは、BIERヘッダおよびBIER転送メカニズムに基づいてマルチキャストデータをBIERドメイン100内の受信者（例えば、ASBR1）に転送し得る。

S109：BIERドメイン間マルチキャストデータ転送を実行する。

具体的には、BIERデータパケットを受信すると、ASBR1は、BIERデータパケット内のマルチキャストデータに対応するBFR−Prefix（すなわち、ASBR2のBFR−Prefix）を最初に検索し、BFR−Prefixは、ステップS105で決定されており、マルチキャストデータをASBR2に送信するように示すために使用される。次に、ASBR1は、マルチキャストデータをGREまたはMPLSヘッダでカプセル化し、マルチキャストデータをASBR2に送信する。

S110：BIERドメイン200でマルチキャストデータ転送を実行する。

具体的には、ASBR2は、GREまたはMPLSヘッダでカプセル化された受信されたマルチキャストデータを解析する。次に、ASBR2は、BIERドメイン200のマルチキャストデータに対応するBitStringを検索し、BitStringは、S103で決定される。さらに、ASBR2は、マルチキャストデータをBIERドメイン200内の受信者に転送するために必要なBIFT−idをさらに決定する必要があり、BIFT−idは、S101で既に決定されている。次に、ASBR2は、BitStringおよびBIFT−idを使用してBIERヘッダを生成し、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行する。このようにして、BIERドメイン200内のASBR2およびトランジットBFRは、BIERヘッダおよびBIER転送メカニズムに基づいてマルチキャストデータをBIERドメイン200内の受信者に転送し得る。

最後に、BIERドメイン200内の受信者は、BIERデータパケットのBIERヘッダを除去し、マルチキャストデータを読み取り、マルチキャストデータをユーザ側デバイスに転送する。

S108からS110に基づいて、マルチキャストデータ転送は以下のように要約される。

1．BIERドメインにおけるマルチキャストデータ転送（S108およびS110）
a．マルチキャストデータが到達すると、BIERドメイン内のBFIRは、BIERドメインのマルチキャストデータに対応するBitStringと、マルチキャストデータをBIERドメイン内の受信者に転送するために必要なBIFT−idとを最初に発見し、マルチキャストデータのためにBIERヘッダを生成し、BIERデータパケットを取得するために、BIERヘッダを使用してマルチキャストデータに対してBIERカプセル化を実行する。
b．BIERドメイン内のBFIRおよびトランジットBFRは、BIERヘッダおよびBIER転送メカニズムに基づいてマルチキャストデータをBIERドメイン内の受信者に転送する（論理ANDなどの操作が、BitStringおよびBIFTのF−BMに対して実行されるが、詳細については、IETF BIER＿ARCHを参照されたい）。

2．BIERドメイン間マルチキャストデータ転送（S109）
a．BIERデータパケットを受信すると、ドメイン内のBFER（例えば、BIERドメインAS100内のASBR1）は、最初にBIERデータパケットをデカプセル化し、マルチキャストデータを読み取り、次にマルチキャストデータに対応するBFR−Prefix（例えば、BIERドメイン200内のASBR2のBFR−Prefix）を検索し、最後に、BFR−Prefixを使用してMPLSラベルまたはGREラベルをマルチキャストデータに追加する。
b．BFERは、ラベル付けされたマルチキャストデータを、BFR−Prefixで表される別のドメイン内のBFIRに送信する。このようにして、ラベル付けされたマルチキャストデータを受信した後、別のドメイン内のBFIRもまた、別のドメインのマルチキャストデータに対応するBitStringと、マルチキャストデータを別のドメイン内の受信者に転送するために必要なBIFT−idとを検索し、マルチキャストデータのためにBIERヘッダを生成する。最後に、別のドメイン内のBFRは、BIER転送メカニズムに基づいてマルチキャスト転送を実行する。

既存のBIER−MVPNソリューションでは、マルチキャストデータはセグメントごとに転送される。マルチキャストデータが送信者PEから別のBIERドメイン内の受信者PEに送信されるとき、複数のデバイス（各BIERドメイン内のBFIRおよびBFERなど）がBIERヘッダの生成に参加する必要がある。このようにして、効率が低く、適時性が低くなる。

既存のBIER−MVPNソリューションに存在する欠点に対して、本出願は、マルチキャストデータ送信方法を提供する。

本出願の主な発明原理は、以下の2つのフェーズ、すなわち、1．マルチキャスト情報アドバタイズメントおよびフィードバック、ならびに2．マルチキャストデータ転送、で具体化され得る。

（A）フェーズ1の主な発明原理は、マルチキャスト情報の高速アドバタイズメントおよび高速フィードバックを実施するために、異なるBIERドメイン内のエッジBFR（BFIRおよびBFER）が、BGPピアを確立し、BGP接続を介してBGPメッセージを直接交換することを含み得る。

（B）フェーズ2の主な発明原理は、マルチキャストドメイン全体（複数のBIERドメイン）が、一緒にBIFT−idを決定することを含み得る。具体的には、別のBIERドメインのBIFT−idを決定するために使用されるsub−domain、SI、およびBSLと同じように、送信者は、これらのパラメータに基づいて、別のBIERドメインのマルチキャストデータに対応するBIFT−idも決定する。BIERヘッダは、送信者でのみ構築され、中間デバイスは、BIERヘッダの構築に参加する必要はない。ドメインを越えて送信されるBIERデータパケットに関して、送信者は、ラベルカプセル化に別のBIERドメイン内のBFIRのBFIR−Prefixを使用し、次に、BIERデータパケットを別のドメイン内のBFIRにユニキャストする。既存のBIER−MVPNソリューションとは異なり、本出願におけるマルチキャストデータ転送はセグメント式ではない。中間デバイス（例えば、経路に沿った各BIERドメインのBFIRおよびBFER）は、BIERヘッダの生成に参加する必要がもはやない。このようにして、マルチキャスト転送はより効率的になる。

フェーズ1では、異なるBIERドメイン内のエッジBFRがドメインを越えてBPGメッセージを交換することを可能にするために、以下の条件、すなわち、1．最下層ラベルマッピングに基づいて確立されたTCP接続、2．手動で構成されたBGPピア（BGP peer）、および3．BGP openメッセージを使用して確立されたBGP接続が実現される必要がある。異なるBIERドメイン内のエッジBFR間にBGP接続が確立されると、既存のBIER−MVPNソリューションのセグメント式マルチキャスト情報アドバタイズメントおよびフィードバックを必要とせずに、ドメインを越えてマルチキャスト情報アドバタイズメントおよびフィードバックを実施するために、BGPメッセージが直接交換され得ることが理解され得る。

ここでは、BGPピアを手動で構成する方法に関して、関連するオペレータによって提供される構成コマンドが使用され得る。これは本出願では限定されない。BGP openメッセージを使用してBGP接続を確立する具体的な実施態様については、RFC1105を参照されたい。ここでは詳細は説明されない。

以下では、最下層ラベルマッピングに基づいてTCP接続を確立する方法を説明するために例を使用する。例えば、図11に示されているように、異なるBIERドメイン内のエッジBFR間のTCP接続は、以下のプロセスに基づいて確立され得る。

1．BIERドメイン200内のBFERは、ラベル配布プロトコル（label distribute protocol、LDP）を介して、BFERのBFR−Prefix「2．2．2．2」をBIERドメイン200内のASBR2にマッピングする。BFR−Prefix「2．2．2．2」に対応するラベルは、BFERに送信されるデータをカプセル化するために使用され得る。このようにして、ASBR2は、「2．2．2．2」に転送されるデータをカプセル化するためにどのラベルが使用される必要があるかを知り得る。

2．BIERドメイン100内のASBR1およびBIERドメイン200内のASBR2は、外部境界ゲートウェイプロトコル（External Border Gateway Protocol、EBGP）に基づいてASBR1およびASBR2のBFR−Prefixを互いに転送し、対応するラベルを設定するように互いに示す。例えば、ASBR1は、2．2．2．2（すなわち、BIERドメイン200内のBFER）に送信されるデータにラベル「222」を追加し、次に、データをASBR2に送信する必要がある。

3．ASBR1は、内部境界ゲートウェイプロトコル（内部境界ゲートウェイプロトコル、IBGP）を介して、BIERドメイン100内の境界BFR（送信者を含む）にBFR−Prefix「2．2．2．2」を直接通知する。このようにして、送信者は、データを2．2．2．2に送信するために送信者はデータをASBR1に転送するだけでよいことを知り得る。ASBR1および送信者は同じBIERドメイン（すなわち、同じAS）に属し、ラベル転送マッピングは、ASBR1と送信者との間に確立される。したがって、送信者は、2．2．2．2のターゲットを有するデータにラベル「22」（ASBR1に到達可能な）を追加するだけでよい。これに対応して、2．2．2．2のターゲットおよびラベル「22」を有するデータを受信した後、ASBR1は、ラベル「22」をラベル「222」に置き換え、ラベル「222」を有するデータをASBR2に送信する。ASBR2は、次に、ラベル「222」をラベル「2222」に置き換え、最後に、ラベル「2222」を有するデータを2．2．2．2、すなわち、BIERドメイン200内のBFERに送信する。

最下層ラベルマッピングによって、BIERドメイン200内のエッジBFRのBFR−Prefixに対応するラベルは、BIERドメイン100内のエッジBFR（送信者など）にマッピングされ、BIERドメイン100内の送信者とBIERドメイン200内のエッジBFRとの間にTCP接続が確立され得る。このようにして、図12に示されているように、BIERドメイン100内の送信者およびBIERドメイン200内のエッジBFRは、BGP接続を介してBGPメッセージを交換するために互いにEBGPピア（すなわち、EBGP peer）をさらに形成し得る。

図12に示されているアーキテクチャに基づいて、図13に示されているように、異なるBIERドメイン内のエッジBFRは、BGPプロトコルに基づいてマルチキャスト情報を直接交換し得る。具体的には、BIERドメイン100内の送信者は、マルチキャスト情報をアドバタイズするために、BGPメッセージを使用して、BIERドメイン200内のエッジBFR（ASBR2およびBFER）にIntra PMSI A−D routeを直接送信する。BIERドメイン200内のエッジBFR（ASBR2およびBFER）は、マルチキャスト情報フィードバックのためにBGPメッセージを使用してleaf A−D routeを送信者に直接送信する。

図11は、最下層ラベルマッピングによってTCP接続を確立するための方法の例を説明しているにすぎず、限定を構成するものではない。

前述の主な発明原理および図6に示されている適用シナリオに基づいて、以下では、本出願で提供されるマルチキャストデータ送信方法を詳細に説明する。図14Aおよび図14Bに示されているように、本出願で提供されるマルチキャストデータ送信方法は、以下のステップを含み得る。

（1）フェーズ1（S201）：BIERドメイン内のBFIRおよびBFRは、それぞれのBIFTを生成する。

前述の内容で説明された重要な技術的ポイント「BIFT」から、BIERドメインでは、BFIRおよびBFRがそれぞれ、各BFERに到達するBIFTを生成し得ることが知られ得る。さらに、BFIRは、BFIRが配置されているBIERドメイン内のBFERのBFR−PrefixとBFR−idとの対応関係を含むテーブルをさらに生成し得る。

BIERドメイン内のBFIRおよびBFRは、それぞれのBIFTを生成する。したがって、BIERデータパケットを受信した後、BFIRおよびBFRは、BIERヘッダ内のBIFT−idおよびBitStringに基づいてマルチキャストモードでBIERデータパケットを転送し得る。BIFT−idは、BIERルータがマルチキャストデータを転送するために検索するBIFTを示すために使用される。BitStringは、マルチキャストデータのすべての受信者（BFER）のBFR−idを表す。

（2）フェーズ2（S202〜S203）：マルチキャスト情報アドバタイズメントおよびフィードバック

S202：マルチキャスト情報アドバタイズメント

具体的には、図14Aおよび図14Bに示されているように、BIERドメイン100内の送信者は、BGPメッセージを使用してBIERドメイン100内のBFER−DにIntra PMSI A−D routeを送信し得、BGPメッセージを使用して、BIERドメイン200内のBGPピア（BFIR−EおよびBFER−Gなど）ならびにBIERドメイン300内のBGPピア（BFIR−EおよびBFER−Gなど）にIntra PMSI A−D routeを直接送信し得る。

言い換えると、送信者と、別のBIERドメイン内のBFIRおよびBFERが、BGPピアを形成する。ここで、別のBIERドメインは、送信者が配置されていないBIERドメインである。送信者は、BGP接続を介して別のBIERドメイン内のBFIRおよびBFERにBGPメッセージを直接送信し得、BGPメッセージは、マルチキャストグループのマルチキャスト情報（例えば、マルチキャストグループアドレス）をアドバタイズするために使用されるIntra PMSI A−D routeを運ぶ。これに対応して、別のBIERドメイン内のBFIRおよびBFERが、Intra PMSI A−D routeを運ぶBGPメッセージを受信した後、BFIRおよびBFERが、BGPメッセージによってアドバタイズされたマルチキャストグループに関与する場合、BFIRおよびBFERは、leaf A−D routeをフィードバックする。

図15に示されているように、Intra PMSI A−D routeは、BIER識別子およびマルチキャストグループの識別子（例えば、マルチキャストグループ（multicast group）アドレス232．1．1．1）を運び得る。ここで、BIER識別子は、Intra PMSI A−D routeを運ぶBGPメッセージがBIERマルチキャストメッセージであることを示すために使用される。

S203：マルチキャスト情報フィードバック

具体的には、図14Aおよび図14Bに示されているように、BIERドメイン100内のBFER−Dは、マルチキャスト情報フィードバックを実行するために、BGPメッセージを使用してleaf A−D routeを送信者に送信する。詳細については、既存のBIER−MVPNソリューションのS103を参照されたい。BIERドメイン200内のBGPピア（BFIR−EおよびBFER−Gなど）ならびにBIERドメイン300内のBGPピア（BFIR−EおよびBFER−Gなど）も、マルチキャスト情報フィードバックを実行するために、BGPメッセージを使用して別々にleaf A−D routeを送信者に送信する。

言い換えると、別のBIERドメイン内のBFIRおよびBFERはそれぞれ、BGP接続を介して、leaf A−D routeを運ぶBGPメッセージを送信者に直接送信し得る。これに対応して、送信者は、BGP接続を介して別のBIERドメイン内のBFIRおよびBFERのそれぞれからBPGメッセージを受信し、BGPメッセージは、leaf A−D routeを運ぶ。

送信者がBIERドメイン内のどのBFERがマルチキャストグループに関与するかを知り、マルチキャストグループに対応するマルチキャストデータをBFERに転送する方法を知ることを可能にするために、leaf A−D routeは、以下の情報を運び得る。

第1に、図16に示されているように、別のBIERドメイン内のBFERによってフィードバックされるleaf A−D routeは、BFERのBFR−id、BFERが属するsub−domain、BFERのBFR−idが属するSI、BFERによってサポートされているBSL、およびBFERが属するBIERドメインの識別子を運び得る。具体的には、sub−domain、SI、BSL、およびBFR−idを運ぶために使用されるフィールドが、leaf A−D routeに追加され得、拡張コミュニティ属性（「Source−AS extended community」）が、BIERドメインの識別子を示すために有効にされる。このようにして、送信者は、sub−domain、SI、およびBSLの3つのパラメータに基づいてBIFT−idを決定し得、BFR−idに基づいてBitStringを決定し得る。次に、送信者は、BIERドメインの識別子、BIFT−id、およびBitStringに基づいて第1のマッピングテーブルを生成し得る。詳細については、以降の内容を参照されたい。

場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、別のBIERドメイン内のBFERによってフィードバックされるleaf A−D routeは、BFERが属するsub−domainを運ぶ必要はない。

場合によっては、マルチキャストドメイン全体でサポートされているBSLが同じである可能性があり、すなわち、追加の通知は不要であり、送信者もBSLを知っている。したがって、別のBIERドメイン内のBFERによってフィードバックされるleaf A−D routeは、BSLを運ぶ必要はない。

第2に、図17に示されているように、別のBIERドメイン内のBFIR（例えば、ASBR2）によってフィードバックされるleaf A−D routeは、BFIRのBFR−PrefixおよびBFIRが属するBIERドメインの識別子を運び得る。このようにして、送信者は、情報に基づいて送信者の第2のマッピングテーブルを生成し得る。詳細については、以降の内容を参照されたい。

S202からS203から、本出願では、異なるBIERドメイン間のエッジBFRが、マルチキャスト情報の高速アドバタイズメントおよび高速フィードバックを実施するために、BGPピアを確立し、BGP接続を介してBGPメッセージを直接交換し得ることが分かることが知られ得る。言い換えると、マルチキャスト情報アドバタイズメントおよびフィードバックは、セグメントごとのBGPメッセージ交換をもはや必要とせず、BGPメッセージはドメインを越えて直接交換される。したがって、マルチキャストアドバタイズメントおよびフィードバックの収束時間が大幅に短縮され、効率が高くなる。

（3）フェーズ3（S204〜S206）：マルチキャスト転送に使用される関連するマッピングテーブルを生成する

S204：BIFT−idを決定する。

具体的には、図18に示されているように、BIFT−idは、固定長（例えば、20ビット）を有するインデックスであり、sub−domain、SI、およびBSLの3つのパラメータに基づいて決定される。1つのBIERドメインが1つのsub−domainのみで構成される場合、sub−domainは任意選択である。

図19に示されているように、送信者は、各BIERドメインからleaf A−D routeで運ばれたsub−domain、SI、およびBSLに基づいて、各BIERドメイン内の対応するマルチキャストグループにそれぞれ対応するBIFT−idを決定し得る。例えば、送信者は、BIERドメイン200からleaf A−D routeで運ばれたsub−domain、SI、およびBSLに基づいて、BIERドメイン200内の対応するマルチキャストグループに対応するBIFT−idを決定する。ここで、対応するマルチキャストグループは、leaf A−D routeによってフィードバックされたマルチキャスト情報によって示されるマルチキャストグループを指す。

具体的には、sub−domain、BSL、およびSIのビットシーケンスは、BIFT−idを形成するために順次結合され得る。sub−domainのビットシーケンスは「011」であり、BSLのビットシーケンスは「0000100」であり、SIのビットシーケンスは「0001100100」であると想定される。3つのビットシーケンスは、20ビットの長さを有するビットシーケンス「01100001000001100100」を形成するために順次結合され、このビットシーケンスがBIFT−idである。

sub−domain、SI、およびBSLであって、これらに基づいて送信者が別のBIERドメインの対応するマルチキャストグループに対応するBIFT−idを決定する、sub−domain、SI、およびBSLは、sub−domain、SI、およびBSLであって、これらに基づいて別のBIERドメインでBIFT−idが決定される、sub−domain、SI、およびBSLと同じであることが分かる。これは、送信者が別のBIERドメインにおけるBIERルーティングおよび転送に使用され得るBIFT−idを構築し得ることを意味する。マルチキャストドメイン全体（複数のBIERドメイン）がBIFT−idを一緒に決定する。このようにして、送信者は、別のBIERドメインで正常にルーティングおよび転送されるBIERデータパケットを生成し得る。

1つのBIERドメインは、少なくとも1つのsub−domainを含み得る。この場合、BIERドメインのマルチキャストグループに対応するBIFT−idは、少なくとも1つのsub−domainのマルチキャストグループにそれぞれ対応するBIFT−idであり、BIERドメインのマルチキャストグループに対応するBitStringは、少なくとも1つのsub−domainのマルチキャストグループにそれぞれ対応するBitStringである。これは、BIERドメインに送信されるマルチキャストデータに関して、送信者は、少なくとも1つのsub−domainのBIERヘッダをそれぞれ構築し、次に、少なくとも1つのsub−domainのBIERデータパケットをそれぞれカプセル化する必要があり、異なるsub−domainは、異なるBIERヘッダに対応することを意味する。

本出願では、各BIERドメインのマルチキャストグループにそれぞれ対応するBIFT−idは、各BIERドメインのマルチキャストグループに対応するマルチキャストデータにそれぞれ対応するBIFT−idである。各BIERドメインのマルチキャストグループにそれぞれ対応するBitStringは、各BIERドメインのマルチキャストグループに対応するマルチキャストデータにそれぞれ対応するBitStringである。

S205：第1のマッピングテーブルを生成する。

具体的には、送信者は、各BIERドメインのBIERドメイン識別子、BIFT−id、およびBitStringに基づいて、例として図20に示されている第1のマッピングテーブルを生成する。第1のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストグループに対応するBIFT−idおよびBitStringを含み得る。図20に示されているように、少なくとも1つのBIERドメインは、送信者が配置されているBIERドメインと、送信者が配置されていないBIERドメイン（すなわち、別のBIERドメイン）とを含み得る。

第1のマッピングテーブルは、マルチキャストグループ識別子（例えば、マルチキャストグループアドレス）と、BIERドメインの識別子、BIFT−id、およびBitStringとの対応関係を含み得る。マルチキャストグループ識別子に対応するBIERドメインの識別子、BIFT−id、およびBitStringは、BIERドメインの識別子によって表されるBIERドメインにおいて、マルチキャストグループ識別子によって表されるマルチキャストグループに対応するBIFT−idおよびBitStringを表す。

第1のマッピングテーブルでは、別のBIERドメインのマルチキャストグループに対応するBIFT−idは、別のBIERドメインの受信者が属するsub−domain、受信者のBFR−idが属するSI、および受信者によってサポートされているBSLに基づいて決定される。別のBIERドメインのマルチキャストグループに対応するBitStringは、受信者のBFR−idに基づいて決定される。ここで、受信者は、別のBIERドメインのマルチキャストグループに関与するBFERを指す。

本出願では、第1のマッピングテーブルは、BIERヘッダを構築するために使用され得る。マルチキャストグループに関して、マルチキャストグループのBIERヘッダは、送信者側でのみ構築され、中間デバイスは、BIERヘッダの再構築に参加する必要はない。

S206：送信者の第2のマッピングテーブルを生成する。

本出願では、別のBIERドメインに関して、送信者は、直接隣接するBFR（すなわち、BFR−NBR）をネクストホップとして使用する代わりに、ネクストホップを独立して決定する（すなわち、別のBIERドメイン内のBFIRをネクストホップとして使用する）。このようにして、別のBIERドメインに送信されるマルチキャストデータは、送信者が配置されているBIERドメイン内のBFRによって転送される必要がなくなる。したがって、マルチキャストデータは、MPLSまたはGREカプセル化の後、別のBIERドメイン内のBFIRに直接送信され得、転送効率が改善される。

特定の他のBIERドメインに関して、BIERドメイン内の送信者のネクストホップは、BIERドメイン内の複数のBFIRであり得る、すなわち、複数のネクストホップが存在する。複数のBFIRの一部は、マルチキャストデータをBIERドメイン内のいくつかのsub−domainに転送することを担当し得、複数のBFIRの他の部分は、マルチキャストデータをBIERドメイン内のいくつかの他のsub−domainに転送することを担当し得る。このようにして、BIERドメインに送信されるマルチキャストデータに関して、送信者は、BIERドメインのマルチキャストデータに対応するBIFT−id（BIFT−idはsub−domainと1対1に対応する）に基づいて、マルチキャストデータが転送されるBFIRを決定し得る。なぜなら、BIFT−idが、マルチキャストデータが送信されるsub−domainを示し得るからである。複数のBFIRがそれぞれどのsub−domain（または複数のsub−domain）にマルチキャストデータを転送することを担当するかは、本出願では限定されず、実際の要求に基づいて決定され得る。例えば、複数のネクストホップのそれぞれによって運ばれるデータ転送量は、負荷分散の観点から設定され得る。

特定の他のBIERドメインに関して、BIERドメイン内の送信者のネクストホップは、BIERドメイン内の1つのBFIRである場合がある、すなわち、1つのネクストホップのみが存在する。BFIRは、マルチキャストデータをBIERドメイン内のすべてのターゲットsub−domainに転送することを担当し得る。ここで、ターゲットsub−domainは、マルチキャストデータの受信者が配置されているsub−domainである。

本出願では、送信者は、独立して決定されたネクストホップに基づいて、図21に例として示されている第2のマッピングテーブルを生成し得る。第2のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストグループにそれぞれ対応するBIFT−idと、少なくとも1つのBIERドメイン内の送信者のネクストホップのBFR−Prefixとを含み得る。図21に示されているように、少なくとも1つのBIERドメインは、送信者が配置されているBIERドメインと、送信者が配置されていないBIERドメイン（すなわち、別のBIERドメイン）とを含み得る。送信者が配置されているBIERドメインでは、既存のBIER−MVPNソリューションを参照すると、送信者のネクストホップはBFR−NBRであり得る。別のBIERドメインでは、送信者のネクストホップは、別のBIERドメインのBFIRであり得る。

第2のマッピングテーブルは、マルチキャストグループ識別子（例えば、マルチキャストグループアドレス）と、BIERドメインの識別子、BIFT−id、およびBFR−Prefixとの対応関係を含み得る。マルチキャストグループ識別子に対応するBIERドメインの識別子、BIFT−id、およびBFR−Prefixは、BIERドメインの識別子によって表されるBIERドメインにおいて、マルチキャストグループによって表されるマルチキャストグループに対応するBIFT−idおよび論理ネクストホップのBFR−Prefixを表す。

特定の他のBIERドメインに関して、送信者がBIERドメインに複数のネクストホップを有する場合、第2のマッピングテーブル内のBIERドメインのドメイン識別子に対応する（1つ以上の）BIFT−idは、複数のBFR−Prefixに対応するか、または送信者がBIERドメインに1つのネクストホップのみを有する場合、第2のマッピングテーブル内のBIERドメインのドメイン識別子に対応する（1つ以上の）BIFT−idは、1つのBFR−Prefixに対応する。

本出願では、第2のマッピングテーブルは、クロスドメイン（ドメイン間）転送を実施するために、マルチキャストデータをカプセル化することによって取得されたBIERデータパケットにMPLSラベルまたはGREラベルを追加するために使用され得る。例えば、送信者は、BIERデータパケットのBIERヘッダで運ばれたBIFT−idに基づいて、BIERデータパケットが送信されるターゲットBIERドメインを決定し得る。次に、MPLSラベルまたはGREラベルをBIERデータパケットに追加した後、送信者は、ターゲットBIERドメイン内の送信者のネクストホップにBIERデータパケットを送信し得る。例は、本出願を説明するためにのみ使用されている。詳細については、以降の内容を参照されたい。詳細は説明されない。

任意選択で、送信者は、マルチキャストデータを少なくとも1つのBIERドメインに送信するための出力ポートを構成し得る。第2のマッピングテーブルは、出力ポートの識別子をさらに含み得る。このようにして、送信者は、マルチキャストデータを特定のBIERドメインに転送するためにどの出力ポートが使用されるかを知り得る。

任意選択で、第1のマッピングテーブルおよび第2のマッピングテーブルは、2つの独立したマッピング関係、すなわち、2つのテーブルであり得る。代替的に、第1のマッピングテーブルおよび第2のマッピングテーブルは、マッピング関係で、すなわち、テーブルの2つの部分で存在してもよい。第1のマッピングテーブルおよび第2のマッピングテーブルのデータ表現形式は、本出願では限定されない。第1のマッピングテーブルおよび第2のマッピングテーブルは、表形式である必要はない。

（4）フェーズ4：マルチキャストデータ転送（S207からS211）：ドメイン内転送およびドメイン間転送

S207：BIERドメイン100におけるマルチキャストデータ転送。

具体的には、マルチキャストデータが到達すると、送信者は、第1のマッピングテーブルから、BIERドメイン100のマルチキャストデータに対応するBIFT−idおよびBitStringを決定し得る。BIERドメイン100のマルチキャストデータに対応するBIFT−idおよびBitStringは、それぞれ、BIERドメイン100のマルチキャストデータに対応するマルチキャストグループに対応するBIFT−idおよびBitStringである。第1のマッピングテーブルはS205で生成されている。

次に、送信者は、BitStringおよびBIFT−idを使用してBIERヘッダを生成し、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行し得る。このようにして、BIERドメイン100内の送信者およびトランジットBFRは、BIERヘッダおよびBIER転送メカニズムに基づいてマルチキャストデータをBIERドメイン100内の受信者に転送し得る。

これに対応して、BIERドメイン100内の受信者は、BIERデータパケットを受信し、次に、マルチキャストデータを取得するためにBIERデータパケットをデカプセル化し、マルチキャストデータをユーザ側デバイスに送信し得る。

S208：送信者（BIERドメイン100内の）は、マルチキャストデータをBIERドメイン200内のBFIRにユニキャストする。

具体的には、マルチキャストデータが到達すると、送信者は、第1のマッピングテーブルから、BIERドメイン200のマルチキャストデータに対応するBIFT−idおよびBitStringを決定し、BitStringおよびBIFT−idを使用してBIERヘッダを生成し、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行し得る。第1のマッピングテーブルはS205で生成されている。

次に、送信者は、S206で生成された第2のマッピングテーブルから、BIERヘッダ内のBIFT−idに基づいてBIERドメイン200内の送信者のネクストホップのBFR−Prefixを決定し得る。さらに、送信者は、BFR−Prefixを使用してMPLSラベルまたはGREラベルをBIERデータパケットに追加し、ラベル付けされたBIERデータパケットをBIERドメイン200内のBFIRに送信し得る。

これに対応して、BIERドメイン200内のBFIRは、ラベル付けされたBIERデータパケットを受信し得、BIERデータパケットを取得するためにラベルを除去し得る。

S209：BIER転送メカニズムに基づいてBIERドメイン200でマルチキャストデータを転送する。

BIERドメイン200内のBFIRおよびトランジットBFRは、BIERデータパケットのBIERヘッダからBIFT−idおよびBitStringを取得し、最後に、BIFT−idおよびBitStringによって示されるBIFTに基づいてBIERデータパケットをBIERドメイン200内の受信者に転送し得る。詳細については、既存のBIER−MVPNソリューションのS108およびS110を参照されたい。ここでは詳細は説明されない。

これに対応して、BIERドメイン200内の受信者は、BIERデータパケットを受信し、次に、マルチキャストデータを取得するためにBIERデータパケットをデカプセル化し、マルチキャストデータをユーザ側デバイスに送信し得る。

S210からS211は、マルチキャストデータをBIERドメイン300内の受信者に転送するプロセスを説明している。このプロセスは、マルチキャストデータをBIERドメイン200内の受信者に転送するプロセスと同じであり、ここではこれ以上説明されない。

S207からS211に基づいて、マルチキャストデータ転送は以下のように要約される。

1．BIERドメイン間マルチキャストデータ転送（S208およびS210）：別のBIERドメインに送信されるマルチキャストデータに関して、送信者は、BIERデータパケットを取得するためにマルチキャストデータに対してBIERカプセル化を実行し、MPLSラベルまたはGREラベルをBIERデータパケットに追加し、次にBIERデータパケットを別のBIERドメイン内のBFIRにユニキャストする。

2．BIERドメイン内マルチキャストデータ転送（S207、S209、およびS211）：マルチキャストデータはBIERメカニズムに基づいて転送される。詳細については、既存のBIER−MVPNソリューションを参照されたい。

既存のBIER−MVPNソリューションとは異なり、本出願におけるマルチキャストデータ転送はセグメント式ではないことが知られ得る。BIERヘッダは送信者側でのみ構築され、中間デバイス（例えば、経路に沿った各BIERドメインのBFIRおよびBFER）は、BIERヘッダの生成に参加する必要がもはやない。このようにして、マルチキャスト転送はより効率的になる。

本出願では、マルチキャストデータ転送の重要な動作は送信者によって実行される。送信者の動作原理は、例として図22に示され得る。複数のBIERドメインに送信されるマルチキャストデータに関して、送信者は、最初にマルチキャストデータを複製し、次に、S205で生成された第1のマッピングテーブルに基づいて、BIERデータパケットを取得するために異なるBIERドメインに送信されるマルチキャストデータのBIERヘッダを構築する。次に、送信者は、S206で生成された第2のマッピングテーブルに基づいて、別のBIERドメインに送信されるBIERデータパケットにラベルを付け、別のBIERドメイン内の送信者のネクストホップにBIERデータパケットをユニキャストし得る。ドメイン（すなわち、送信者が配置されているBIERドメイン）で送信されるBIERデータパケットに関して、送信者は、BIER転送メカニズムに基づいてマルチキャストデータを転送する。詳細については、既存のBIER−MVPNソリューションを参照されたい。

以下では、本出願で提供されるマルチキャストデータ転送方法の特定の実施態様について説明するために例を使用する。

図23に示されている例では、マルチキャストグループ（S，G）に関与する受信者は、BIERドメイン100内のBFER−D（BFR−idが100）、BIERドメイン200内のBFER−G（BFR−idが100）、およびBIERドメイン300内のBFER−J（BFR−idが200）であると想定されている。BFER−GのBFR−Prefixに対応するラベルは「200」であり、BFER−JのBFR−Prefixに対応するラベルは「300」である。図23に示されているように、マルチキャストグループ（S，G）に対応するマルチキャストデータが到達すると、マルチキャストデータの転送プロセスは以下の通りである。

1．送信者はマルチキャストデータの3つのコピーを作成する。

2．送信者は、第1のマッピングテーブルに基づいてマルチキャストデータの3つのコピーのBIERヘッダをカプセル化する。BFER−Dに送信されるマルチキャストデータにカプセル化されるBIERヘッダは、BIERドメイン100のマルチキャストデータに対応するBIFT−id（すなわち、BIFT−100）およびBIERドメイン100のマルチキャストデータに対応するBitString（100番目のビットが1）を含む。BFER−Gに送信されるマルチキャストデータにカプセル化されるBIERヘッダは、BIERドメイン200のマルチキャストデータに対応するBIFT−id（すなわち、BIFT−200）およびBIERドメイン200のマルチキャストデータに対応するBitString（100番目のビットが1）を含む。BFER−Jに送信されるマルチキャストデータにカプセル化されるBIERヘッダは、BIERドメイン300のマルチキャストデータに対応するBIFT−id（すなわち、BIFT−300）およびBIERドメイン300のマルチキャストデータに対応するBitString（200番目のビットが1）を含む。

3．BIER転送メカニズムに基づいてBIERドメイン100でマルチキャストデータを転送する。詳細については、既存のBIER−MVPNソリューションを参照されたい。BIERデータパケットを受信した後、BIERドメイン100内の受信者は、BIERデータパケットをデカプセル化し、マルチキャストデータを読み取り、マルチキャストデータをユーザ側デバイスに転送し得る。

4．送信者は、ラベル「200」をBIERデータパケットに追加し、ラベル「200」を有するBIERデータパケットをBIERドメイン200内のBFIR−E（すなわち、ASBR2）にユニキャストする。BIERドメイン200内のBFIR−Eを受信した後、BIERドメイン200内のBFIR−Eは、BIERデータパケットを取得するためにラベル「200」を除去し得る。BIER転送メカニズムに基づいてBIERドメイン200でマルチキャストデータを転送する。詳細については、既存のBIER−MVPNソリューションを参照されたい。BIERデータパケットを受信した後、BIERドメイン200内の受信者は、BIERデータパケットをデカプセル化し、マルチキャストデータを読み取り、マルチキャストデータをユーザ側デバイスに転送し得る。

5．送信者は、ラベル「300」をBIERデータパケットに追加し、ラベル「300」を有するBIERデータパケットをBIERドメイン300内のBFIR−H（すなわち、ASBR3）にユニキャストする。BIERドメイン300内のBFIR−Hを受信した後、BIERドメイン300内のBFIR−Hは、BIERデータパケットを取得するためにラベル「300」を除去し得る。BIER転送メカニズムに基づいてBIERドメイン300でマルチキャストデータを転送する。詳細については、既存のBIER−MVPNソリューションを参照されたい。BIERデータパケットを受信した後、BIERドメイン200内の受信者は、BIERデータパケットをデカプセル化し、マルチキャストデータを読み取り、マルチキャストデータをユーザ側デバイスに転送し得る。

図23に示されている例から、既存のBIER−MVPNソリューションとは異なり、別のBIERドメイン（例えば、BIERドメイン200）内の受信者に送信されるマルチキャストデータは、BIERドメイン100およびBIERドメイン200内のBFRを介してセグメントによって転送される必要はもはやなく、中間デバイス（例えば、BIERドメイン200内のBFIR）は、BIERヘッダの生成に参加しない。このようにして、マルチキャスト転送はより効率的になる。

拡張ソリューション

一部の任意選択の実施形態では、送信者は、マルチキャスト情報をアドバタイズするために別のBIERドメイン内のBFIRにBGPメッセージを送信しなくてもよく、別のBIERドメイン内のBFIRは、BGPメッセージで運ばれるIntra PMSI A−D routeを認識および解析し得る。この拡張ソリューションは、図24Aおよび図24Bに示され得、以下の内容を含む。

（1）フェーズ1（S301）：BIERドメイン内のBFIRおよびBFRは、それぞれのBIFTを生成する。

詳細については、図14Aの実施形態のS201を参照されたい。ここでは詳細は説明されない。

（2）フェーズ2（S302からS304）：マルチキャスト情報アドバタイズメントおよびフィードバック

図14Bの実施形態におけるマルチキャスト情報アドバタイズメントおよびフィードバック（S202からS203）とは異なり、送信者は、マルチキャスト情報をアドバタイズするために別のBIERドメイン内のBFIRにBGPメッセージをもはや送信せず、別のBIERドメイン内のBFIRは、BGPメッセージで運ばれるIntra PMSI A−D routeを認識および解析し得る。詳細については、S302からS303を参照されたい。

範囲を絞り込むために、別のBIERドメイン内のBFIRは、マルチキャスト情報をアドバタイズするために使用され得るタイプ（Route type）が1、2、3、および5であるIntra PMSI A−D routeのみを解析し、次に、Intra PMSI A−D routeで運ばれたPMSI Tunnel Attributeを解析し得る。PMSI Tunnel AttributeがBIER識別子を含まない場合、別のBIERドメイン内のBFIRが、leaf A−D routeを送信者に送信する。BIER識別子を含むIntra PMSI A−D routeについては、図9を参照されたい。

（3）フェーズ3（S305からS307）：マルチキャスト転送に使用される関連するマッピングテーブルを生成する

詳細については、図14Aおよび図14Bの実施形態のS204からS206を参照されたい。ここでは詳細は説明されない。

（4）フェーズ4：マルチキャストデータ転送（S308からS312）：ドメイン内転送およびドメイン間転送

詳細については、図14Bの実施形態のS307からS311を参照されたい。ここでは詳細は説明されない。

図25は、本出願の一部の実施形態によるルータ100を示している。ルータ100は、BIERドメイン内のBFRであり、BIERドメイン内のBFIRとして実施され得るか、BIERドメイン内のトランジットBFRとして実施され得るか、またはBIERドメイン内のBFERとして実施され得る。図25に示されているように、ルータ100は、1つ以上のプロセッサ101、メモリ103、および通信インターフェース105を含み得る。これらのコンポーネントは、バス104を介してまたは別の方法で互いに接続され得る。図25では、コンポーネントがバスを介して接続されている例が使用されている。

通信インターフェース105は、別の通信デバイス、例えば別のルータと通信するためにルータ100によって使用され得る。具体的には、通信インターフェース105は、有線通信インターフェース、例えば、広域ネットワーク（WAN）インターフェースまたはローカルエリアネットワーク（LAN）インターフェースを含み得る。通信インターフェース105は、有線通信インターフェースに限定されない。一部の可能な実施形態では、通信インターフェース105は、無線通信インターフェース、例えば、無線ローカルエリアネットワーク（WLAN）インターフェースをさらに含み得る。

メモリ103は、プロセッサ101に結合され、様々なソフトウェアプログラムおよび／または命令の複数のグループを記憶するように構成される。具体的には、メモリ103は、高速ランダムアクセスメモリを含み得、不揮発性メモリ、例えば、1つ以上の磁気ディスク記憶デバイス、フラッシュメモリデバイス、または他の不揮発性ソリッドステート記憶デバイスも含み得る。メモリ103は、オペレーティングシステム（以下では簡単にシステムと呼ばれる）、例えば、uCOS、VxWorks、またはRTLinux(登録商標)などの組み込みオペレーティングシステムを記憶し得る。メモリ103は、ネットワーク通信プログラムをさらに記憶し得る。ネットワーク通信プログラムは、1つ以上の追加のデバイス、1つ以上のユーザ機器、および1つ以上のネットワークデバイスと通信するために使用され得る。

本出願の一部の実施形態では、ルータ100は、前述の方法の実施形態における送信者、例えば、図6におけるBIERドメイン100内のBFIR−Aとして実施され得る。メモリ103は、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の送信者側の実施プログラムを記憶するように構成され得る。プロセッサ101は、コンピュータ可読命令を読み出して実行するように構成され得る。具体的には、プロセッサ101は、メモリ103に記憶されたプログラム、例えば、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の送信者側の実施プログラムを呼び出し、プログラムに含まれる命令を実行するように構成され得る。送信者側の、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の実施態様については、前述の方法の実施形態を参照されたい。

本出願の一部の実施形態では、ルータ100は、前述の方法の実施形態における別のドメイン内のBFIR（例えば、図6のBIERドメイン200内のASBR2）として実施され得る。メモリ103は、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法のBFIR側の実施プログラムを記憶するように構成され得る。プロセッサ101は、コンピュータ可読命令を読み出して実行するように構成され得る。具体的には、プロセッサ101は、メモリ103に記憶されたプログラム、例えば、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の、BFIR側で実施するためのプログラムを呼び出し、プログラムに含まれる命令を実行するように構成され得る。BFIR側の、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の実施態様については、前述の方法の実施形態を参照されたい。

本出願の一部の実施形態では、ルータ100は、前述の方法の実施形態における別のドメイン内の受信者（例えば、図6のBIERドメイン200内のBFER−G）として実施され得る。メモリ103は、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の受信者側の実施プログラムを記憶するように構成され得る。具体的には、プロセッサ101は、メモリ103に記憶されたプログラム、例えば、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の受信者側の実施プログラムを呼び出し、プログラムに含まれる命令を実行するように構成され得る。受信者側の、本出願の1つ以上の実施形態で提供されるマルチキャストデータ送信方法の実施態様については、前述の方法の実施形態を参照されたい。

図25に示されているルータ100は、本出願の本実施形態の単なる実施態様であることが理解され得る。実際の用途では、ルータ100は、より多くのまたはより少ないコンポーネントをさらに含み得る。これはここでは限定されない。

図26は、本出願による別の通信システムおよび関連装置を示している。通信システム200は、以下の通信装置、すなわち、少なくとも1つの第1のルータ400および少なくとも1つの第2のルータ500を含み得る。第1のルータ400および第2のルータ500は、同じBIERドメインに配置される。第1のルータ400は、前述の方法の実施形態における別のBIERドメイン内のBFIRであり得、第2のルータ500は、前述の方法の実施形態における別のBIERドメイン内の受信者BFERであり得る。任意選択で、通信システム200は、少なくとも1つの第3のルータ300をさらに含み得る。第3のルータ300が配置されるBIERドメインは、第1のルータ400および第2のルータ500が配置されるBIERドメインとは異なる。第3のルータ300は、前述の方法の実施形態における送信者であり得る。通信システム200および通信システム200内の通信装置は、図14Aおよび図14Bまたは図24Aおよび図24Bの実施形態で説明されたマルチキャストデータ送信方法を実施し得る。詳細は以下で説明される。

図26に示されているように、第3のルータ300は、処理ユニット301および通信ユニット303を含み得る。

処理ユニット301は、第1のマッピングテーブルから、別のBIERドメインのマルチキャストデータに対応するBIFT−idおよびBitStringを決定し、BIFT−idは、別のBIERドメイン内の第2のルータ500のBFR−idが属するSIおよび第1のBFERによってサポートされているBSLに少なくとも基づいて決定され、BitStringは、第2のルータ500のBFR−idに少なくとも基づいて決定され、第2のルータ500は、マルチキャストデータを受信するように構成された、別のBIERドメイン内のBFERであり、第1のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストデータに対応するBIFT−idおよびBitStringを含む、ように構成され得る。

処理ユニット301は、マルチキャストデータをBIERデータパケットにカプセル化し、BIERデータパケットのBIERヘッダは、別のBIERドメインのマルチキャストデータに対応するBIFT−idおよびBitStringを含む、ようにさらに構成され得る。

処理ユニット301は、BIERデータパケットにラベルを付け、ラベルは、別のBIERドメイン内のBFIRのプレフィックスに対応するラベルである、ようにさらに構成され得る。

通信ユニット303は、ラベル付けされたBIERデータパケットを別のBIERドメイン内の第1のルータ400に送信するように構成され得る。

ここで、別のBIERドメインは、第3のルータ300が配置されていないBIERドメインである。ラベルは、MPLSラベルまたはGREラベルであり得る。

既存のBIER−MVPNソリューションとは異なり、本出願におけるマルチキャストデータ転送はセグメント式ではないことが理解され得る。BIERヘッダは第3のルータ300の側でのみ構築され、中間デバイス（例えば、経路に沿った各BIERドメインのBFIRおよびBFER）は、BIERヘッダの生成に参加する必要がもはやない。このようにして、マルチキャスト転送はより効率的になる。

一部の任意選択の実施形態では、処理ユニット301は、BIERデータパケットにラベルを付ける前に、別のBIERドメインのマルチキャストデータに対応するBIFT−idに基づいて第2のマッピングテーブルから別のBIERドメイン内の第3のルータ300の論理ネクストホップのプレフィックスを決定するようにさらに構成され得る。第3のルータ300の論理ネクストホップは、別のBIERドメイン内のBFIRである。第2のマッピングテーブルは、少なくとも1つのBIERドメインのマルチキャストデータにそれぞれ対応するBIFT−idと、少なくとも1つのBIERドメイン内の第3のルータ300の論理ネクストホップのプレフィックスとを含む。

このようにして、別のBIERドメインに関して、第3のルータ300は、直接隣接するBFR（すなわち、BFR−NBR）をネクストホップとして使用する代わりに、ネクストホップを独立して決定し得（すなわち、別のBIERドメインのBFIRをネクストホップとして使用し得）、このため、別のBIERドメインに送信されるマルチキャストデータは、第3のルータ300が配置されているBIERドメイン内のBFRによって転送される必要がない。したがって、マルチキャストデータは、MPLSまたはGREカプセル化の後、別のBIERドメイン内のBFIRに直接送信され得、転送効率が改善される。

一部の任意選択の実施形態では、第2のマッピングテーブルは、マルチキャストデータを少なくとも1つのBIERドメインに送信するために別個に使用される、第3のルータ300のポートの識別子をさらに含み得る。具体的には、処理ユニット301は、別のBIERドメインのマルチキャストデータに対応するBIFT−idに基づいて第2のマッピングテーブルから、マルチキャストデータを別のBIERドメインに送信するために使用される第1のポートの識別子を決定するようにさらに構成され得る。次に、通信ユニット303は、第1のポートを介して、ラベル付けされたBIERデータパケットを別のBIERドメイン内の第1のルータ400に送信するようにさらに構成され得る。

本出願では、第3のルータ300は、別のBIERドメイン内の第1のルータ400および第2のルータ500とBGPピアを形成する。マルチキャストデータを別のBIERドメイン内のBFIRに転送する前に、第3のルータ300は、マルチキャスト情報アドバタイズメントおよびフィードバックによって、BIERドメイン内のどのBFERがマルチキャストグループに関与するかを知り得る。詳細は以下の通りである。

通信ユニット303は、BGP接続を介して別のBIERドメイン内のBFIRおよびBFERにBGPメッセージを直接送信し、BGPメッセージは、マルチキャスト情報（例えば、マルチキャストグループアドレス）をアドバタイズするために使用されるIntra PMSI A−D routeを運ぶ、ようにさらに構成され得る。Intra PMSI A−D routeは、BIER識別子とマルチキャストデータに対応するマルチキャストグループの識別子（例えば、マルチキャストグループ（multicast group）アドレス232．1．1．1）とを運び得る。ここで、BIER識別子は、Intra PMSI A−D routeを運ぶBGPメッセージがBIERマルチキャストメッセージであることを示すために使用される。

通信ユニット303は、BGP接続を介して別のBIERドメイン内の第1のルータ400および第2のルータ500のそれぞれからBPGメッセージを直接受信し、BGPメッセージは、leaf A−D routeを運ぶ、ようにさらに構成され得る。

第3のルータ300がBIERドメイン内のどのBFERがマルチキャストグループに関与するかを知り、マルチキャストデータをBFERに転送する方法を知ることを可能にするために、leaf A−D routeは、以下の情報を運び得る。

第1に、別のBIERドメイン内の第2のルータ500によってフィードバックされるleaf A−D routeは、第2のルータ500のBFR−id、第2のルータ500が属するsub−domain、第2のルータ500のBFR−idが属するSI、第2のルータ500によってサポートされているBSL、および第2のルータ500が属するBIERドメインの識別子を運び得る。具体的には、sub−domain、SI、BSL、およびBFR−idを運ぶために使用されるフィールドが、leaf A−D routeに追加され得、拡張コミュニティ属性（「Source−AS extended community」）が、BIERドメインの識別子を示すために有効にされる。このようにして、第3のルータ300は、sub−domain、SI、およびBSLの3つのパラメータに基づいてBIFT−idを決定し得、BFR−idに基づいてBitStringを決定し得る。次に、第3のルータ300は、BIERドメインの識別子、BIFT−id、およびBitStringに基づいて第1のマッピングテーブルを生成し得る。

場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、別のBIERドメイン内の第2のルータ500によってフィードバックされるleaf A−D routeは、第2のルータ500が属するsub−domainを運ぶ必要はない。

場合によっては、マルチキャストドメイン全体でサポートされているBSLが同じである可能性があり、すなわち、追加の通知は不要であり、第3のルータ300もBSLを知っている。したがって、別のBIERドメイン内の第2のルータ500によってフィードバックされるleaf A−D routeは、BSLを運ぶ必要はない。

第2に、別のBIERドメイン内の第1のルータ400によってフィードバックされるleaf A−D routeは、第1のルータ400のBFR−Prefixと、第1のルータ400が属するBIERドメインの識別子とを運び得る。このようにして、第3のルータ300は、情報に基づいて第2のマッピングテーブルを生成し得る。

異なるBIERドメイン間のエッジBFRが、マルチキャスト情報の高速アドバタイズメントおよび高速フィードバックを実施するために、BGPピアを確立し、BGP接続を介してBGPメッセージを直接交換し得ることが分かる。言い換えると、マルチキャスト情報アドバタイズメントおよびフィードバックは、セグメントごとのBGPメッセージ交換をもはや必要とせず、BGPメッセージはドメインを越えて直接交換される。したがって、マルチキャストアドバタイズメントおよびフィードバックの収束時間が大幅に短縮され、効率が高くなる。

第3のルータ300の各機能ユニットの特定の実施態様については、図14Aおよび図14Bまたは図24Aおよび図24Bに対応する方法の実施形態を参照すべきことが理解され得る。ここでは詳細は説明されない。

図26に示されているように、第1のルータ400は、処理ユニット401および通信ユニット403を含み得る。

通信ユニット403は、第3のルータ300によって送信されたラベル付きBIERデータパケットを受信し、ラベルは、第1のルータ400のプレフィックスに対応するラベルであり、BIERデータパケットは、マルチキャストデータをカプセル化することによって第3のルータ300によって取得され、BIERデータパケットのBIERヘッダは、別のBIERドメインのマルチキャストデータに対応するBIFT−idおよびBitStringを含む、ように構成され得る。BIFT−idは、第2のルータ500のBFR−idが属するSIおよび第2のルータ500によってサポートされているビット列長に少なくとも基づいて決定され、BitStringは、第2のルータ500のBFR−idに少なくとも基づいて決定される。第2のルータ500は、マルチキャストデータを受信するように構成された別のBIERドメイン内のBFERである。

処理ユニット401は、BIERデータパケットを取得するためにラベルを除去し、BIERデータパケットのBIERヘッダからBIFT−idおよびBitStringを取得するように構成され得る。

通信ユニット403は、BIFT−idおよびBitStringによって示されるBIFTに基づいてBIERデータパケットを第2のルータ500に転送するようにさらに構成され得る。

ここで、別のBIERドメインは、第3のルータ300が配置されていないBIERドメインである。ラベルは、MPLSラベルまたはGREラベルであり得る。

一部の任意選択の実施形態では、別のBIERドメインのマルチキャストデータに対応するBIFT−idは、第2のルータ500が属するsub−domainに基づいてさらに決定される。任意選択で、場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、第2のルータ500によってフィードバックされるleaf A−D routeは、BFERが属するsub−domainを運ぶ必要はない。

一部の任意選択の実施形態では、第3のルータ300および第1のルータ400は、BGPピアを形成する。通信ユニット403は、BGP接続を介して、第3のルータ300によって送信された第1のBGPメッセージを受信し、第1のBGPメッセージで運ばれるIntra PMSI A−D routeは、BIER識別子と、マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ようにさらに構成され得る。これに対応して、通信ユニット403は、BGP接続を介して第2のBGPメッセージを第3のルータ300に送信し、第2のBGPメッセージで運ばれるleaf A−D routeは、第1のルータ400のプレフィックスおよび第1のルータ400が配置されているBIERドメインの識別子を含む、ようにさらに構成され得る。このようにして、第3のルータ300は、情報に基づいて第2のマッピングテーブルを生成し得る。詳細については、第1の態様で説明された関連する内容を参照されたい。

第1のルータ400の各機能ユニットの特定の実施態様については、図14Aおよび図14Bまたは図24Aおよび図24Bに対応する方法の実施形態を参照すべきことが理解され得る。ここでは詳細は説明されない。

図26に示されているように、第2のルータ500は、処理ユニット501および通信ユニット403を含み得る。

通信ユニット503は、第3のルータ300によって送信されたBIERデータパケットを受信し、BIERデータパケットは、マルチキャストデータをカプセル化することによって第3のルータ300によって取得され、BIERデータパケットのBIERヘッダは、別のBIERドメインのマルチキャストデータに対応するBIFT−idおよびBitStringを含む、ように構成され得る。BIFT−idは、第2のルータ500のBFR−idが属するSIおよび第2のルータ500によってサポートされているビット列長に少なくとも基づいて決定され、BitStringは、第2のルータ500のBFR−idに少なくとも基づいて決定される。第2のルータ500は、マルチキャストデータを受信するように構成された別のBIERドメイン内のBFERである。

処理ユニット501は、マルチキャストデータを取得するためにBIERデータパケットをデカプセル化するように構成され得る。

通信ユニット503は、マルチキャストデータをユーザ側デバイスに送信するようにさらに構成され得る。

ここで、別のBIERドメインは、第3のルータ300が配置されていないBIERドメインである。ラベルは、MPLSラベルまたはGREラベルであり得る。

一部の任意選択の実施形態では、第3のルータ300および第2のルータ500は、BGPピアを形成する。通信ユニット503は、BGP接続を介して、第3のルータ300によって送信された第1のBGPメッセージを受信し、第1のBGPメッセージで運ばれるIntra PMSI A−D routeは、BIER識別子と、マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ようにさらに構成され得る。これに対応して、通信ユニット503は、BGP接続を介して第2のBGPメッセージを第3のルータ300に送信し、第2のBGPメッセージで運ばれるleaf A−D routeは、第2のルータ500のBFR−id、第2のルータ500のBFR−idが属するSI、および別のBIERドメインの識別子を含む、ようにさらに構成され得る。このようにして、第3のルータ300は、情報に基づいて第1のマッピングテーブルを生成し得る。詳細については、第1の態様で説明された関連する内容を参照されたい。

一部の任意選択の実施形態では、別のBIERドメインのマルチキャストデータに対応するBIFT−idは、第2のルータ500が属するsub−domainに基づいてさらに決定される。任意選択で、第2のルータ500によってフィードバックされるleaf A−D routeは、第2のルータ500が属するsub−domainをさらに運び得る。言い換えると、第2のBGPメッセージで運ばれるleaf A−D routeは、第2のルータ500が属するsub−domainをさらに含み得る。任意選択で、場合によっては、1つのsub−domainのみで1つのBIERドメインが構成される。この場合、BIFT−idは、SIおよびBSLの2つのパラメータのみに基づいて決定され得る。したがって、第2のルータ500によってフィードバックされるleaf A−D routeは、BFERが属するsub−domainを運ぶ必要はない。

一部の任意選択の実施形態では、第2のBGPメッセージで運ばれるleaf A−D routeは、第2のルータ500によってサポートされているBSLをさらに含み得る。任意選択で、マルチキャストドメイン全体でサポートされているBSLが同じである可能性があり、すなわち、追加の通知は不要であり、第3のルータ300もBSLを知っている。したがって、第2のルータ500によってフィードバックされるleaf A−D routeは、BSLを運ぶ必要はない。

第2のルータ500の各機能ユニットの特定の実施態様については、図14Aおよび図14Bまたは図24Aおよび図24Bに対応する方法の実施形態を参照すべきことが理解され得る。ここでは詳細は説明されない。

結論として、本出願で提供される技術的ソリューションを実施することによって、マルチキャスト送信の収束時間は大幅に短縮され得、マルチキャスト送信の適時性が改善される。

当業者は、実施形態における方法のプロセスの全部または一部が、関連するハードウェアに命令するコンピュータプログラムによって実施され得ることを理解し得る。プログラムは、コンピュータ可読記憶媒体に記憶され得る。プログラムが実行されると、実施形態の方法のプロセスが実行される。前述の記憶媒体は、ROM、ランダムアクセスメモリRAM、磁気ディスク、または光ディスクなどの、プログラムコードを記憶し得る任意の媒体を含む。

100 BIERドメイン、ルータ
101 プロセッサ
103 メモリ
104 バス
105 通信インターフェース
200 BIERドメイン、通信システム
300 BIERドメイン、第3のルータ
301,401,501 処理ユニット
303,403,503 通信ユニット
400 第1のルータ
500 第2のルータ

Claims (34)

1. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内の第1のビット転送入力ルータBFIRによって、第2のBIERドメインのマルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを決定するステップであって、前記BIFT−idは、第1のビット転送出力ルータBFERのビット転送ルータ識別子BFR−idが属するサブセット識別子SIおよび前記第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、前記ビット列は、前記第1のBFERの前記BFR−idに少なくとも基づいて決定され、前記第1のBFERは、前記マルチキャストデータを受信するために使用される前記第2のBIERドメイン内のBFERである、ステップと、
   前記第1のBFIRによって、前記マルチキャストデータをBIERデータパケットにカプセル化するステップであって、前記BIERデータパケットのBIERヘッダは、前記第2のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idおよび前記ビット列を含む、ステップと、
   前記第1のBFIRによって前記BIERデータパケットにラベルを付け、前記ラベルは、前記第2のBIERドメイン内の第2のBFIRのプレフィックスに対応するラベルであり、前記ラベル付けされたBIERデータパケットを前記第2のBFIRに送信するステップと
   を含むマルチキャストデータ送信方法。
2. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内の第1のビット転送入力ルータBFIRによって、第2のBIERドメインのマルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを決定する前記ステップは、
   前記第1のBFIRによって第1のマッピングテーブルから、前記第2のBIERドメインの前記マルチキャストデータに対応する前記ビット列および前記BIFT−idを決定するステップであって、前記第1のマッピングテーブルは、少なくとも1つのBIERドメインの前記マルチキャストデータに対応するBIFT−idおよびビット列を含む、ステップ
   を特に含む、請求項1に記載の方法。
3. 前記第1のBFIRによって前記BIERデータパケットにラベルを付ける前記ステップの前に、前記方法は、
   前記第1のBFIRによって、前記第2のBIERドメイン内の前記第1のBFIRの論理ネクストホップのプレフィックスを決定するステップであって、前記第2のBIERドメイン内の前記第1のBFIRの前記論理ネクストホップは、前記第2のBFIRである、ステップ
   をさらに含む、請求項1または2に記載の方法。
4. 前記第1のBFIRによって、前記第2のBIERドメイン内の前記第1のBFIRの論理ネクストホップのプレフィックスを決定する前記ステップは、
   前記第1のBFIRによって、第2のマッピングテーブルから前記第2のBIERドメイン内の前記第1のBFIRの前記論理ネクストホップの前記プレフィックスを決定するステップであって、前記第2のBIERドメイン内の前記第1のBFIRの前記論理ネクストホップの前記プレフィックスは、前記第2のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idに対応するプレフィックスであり、前記第2のマッピングテーブルは、少なくとも1つのBIERドメインの前記マルチキャストデータに対応するBIFT−idと、前記少なくとも1つのBIERドメイン内の前記第1のBFIRの論理ネクストホップのプレフィックスとを含む、ステップ
   を特に含む、請求項3に記載の方法。
5. 前記方法は、
   前記第1のBFIRによって、BGP接続を介して第1のBGPメッセージを前記第2のBIERドメイン内のBFIRおよびBFERに送信するステップであって、前記第1のBGPメッセージで運ばれるイントラPマルチキャストサービスインターフェース自動検出ルートintra PMSI A−D routeは、BIER識別子と、前記マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ステップと、
   前記第2のBFIRによって送信された第2のBGPメッセージを、前記BGP接続を介して前記第1のBFIRによって受信するステップであって、前記第2のBGPメッセージで運ばれるリーフ自動検出ルートleaf A−D routeは、前記第2のBFIRの前記プレフィックスおよび前記第2のBIERドメインの識別子を含む、ステップと、
   前記第1のBFERによって送信された第3のBGPメッセージを、前記BGP接続を介して前記第1のBFIRによって受信するステップであって、前記第3のBGPメッセージで運ばれるleaf A−D routeは、前記第1のBFERの前記BFR−id、前記第1のBFERが属する前記BFR−idの前記SI、および前記第2のBIERドメインの前記識別子を含む、ステップと
   をさらに含む、請求項1から4のいずれか一項に記載の方法。
6. 前記第3のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERが属するサブドメインsub−domainをさらに含む、請求項5に記載の方法。
7. 前記第3のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERによってサポートされている前記ビット列長をさらに含む、請求項5または6に記載の方法。
8. 前記第2のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idは、前記第1のBFERが属する前記サブドメインに基づいてさらに決定される、請求項1から7のいずれか一項に記載の方法。
9. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内の第1のビット転送入力ルータBFIRによって、第2のBIERドメイン内の第2のBFIRによって送信されたラベル付けされたBIERデータパケットを受信するステップであって、前記ラベルは、前記第1のBFIRのプレフィックスに対応するラベルであり、前記BIERデータパケットは、前記第2のBFIRによりマルチキャストデータをカプセル化することによって取得され、前記BIERデータパケットのBIERヘッダは、前記第1のBIERドメインの前記マルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを含み、前記BIFT−idは、第1のビット転送出力ルータBFERのビット転送ルータ識別子BFR−idが属するサブセット識別子SIおよび前記第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、前記ビット列は、前記第1のBFERの前記BFR−idに少なくとも基づいて決定され、前記第1のBFERは、前記マルチキャストデータを受信するために使用される前記第1のBIERドメイン内のBFERである、ステップと、
   前記第1のBFIRによって、前記BIERデータパケットを取得するために前記ラベルを除去し、前記BIERデータパケットの前記BIERヘッダから前記BIFT−idおよび前記ビット列を取得するステップと、
   前記第1のBFIRによって、前記BIFT−idおよび前記ビット列によって示されるBIFTに基づいて前記BIERデータパケットを前記第1のBFERに転送するステップと
   を含むマルチキャストデータ送信方法。
10. 前記方法は、
    前記第2のBFIRによって送信された第1のBGPメッセージを、BGP接続を介して前記第1のBFIRによって受信するステップであって、前記第1のBGPメッセージで運ばれるイントラPマルチキャストサービスインターフェース自動検出ルートintra PMSI A−D routeは、BIER識別子と、前記マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ステップと、
    前記第1のBFIRによって、前記第1のBGPメッセージに応答して前記BGP接続を介して第2のBGPメッセージを前記第2のBFIRに送信するステップであって、前記第2のBGPメッセージで運ばれるリーフ自動検出ルートleaf A−D routeは、前記第1のBFIRの前記プレフィックスおよび前記第1のBIERドメインの識別子を含む、ステップと
    をさらに含む、請求項9に記載の方法。
11. 前記第1のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idは、前記第1のBFERが属するサブドメインsub−domainに基づいてさらに決定される、請求項9または10に記載の方法。
12. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内の第1のビット転送出力ルータBFERによって境界ゲートウェイプロトコルBGP接続を介して、第2のBIERドメイン内の第2のビット転送入力ルータBFIRによって送信された第1のBGPメッセージを受信するステップであって、前記第1のBGPメッセージで運ばれるイントラPマルチキャストサービスインターフェース自動検出ルートintra PMSI A−D routeは、BIER識別子と、前記マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ステップと、
    前記第1のBFERによって、前記マルチキャストデータに対応する前記マルチキャストグループの前記識別子に基づいて、前記マルチキャストデータを受信することを決定し、前記BGP接続を介して第2のBGPメッセージを前記第2のBFIRに送信するステップであって、前記第2のBGPメッセージで運ばれるリーフ自動検出ルートleaf A−D routeは、前記第1のBFERのBFR−id、前記第1のBFERの前記BFR−idが属するSI、および前記第1のBIERドメインの識別子を含む、ステップと、
    前記第1のBIERドメイン内の第1のBFIRによって送信されたBIERデータパケットを、前記第1のBFERによって受信するステップであって、前記BIERデータパケットは、前記第2のBFIRにより前記マルチキャストデータをカプセル化することによって取得され、前記BIERデータパケットのBIERヘッダは、前記第1のBIERドメインの前記マルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを含み、前記BIFT−idは、前記第1のBFERの前記ビット転送ルータ識別子BFR−idが属するサブセット識別子SIおよび前記第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、前記ビット列は、前記第1のBFERの前記BFR−idに少なくとも基づいて決定される、ステップと、
    前記第1のBFERによって、前記マルチキャストデータを取得するために前記BIERデータパケットをデカプセル化し、前記マルチキャストデータをユーザ側デバイスに送信するステップと
    を含むマルチキャトデータ送信方法。
13. 前記第2のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERが属するサブドメインsub−domainをさらに含む、請求項12に記載の方法。
14. 前記第2のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERによってサポートされている前記ビット列長をさらに含む、請求項12または13に記載の方法。
15. 前記第1のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idは、前記第1のBFERが属する前記sub−domainに基づいてさらに決定される、請求項12から14のいずれか一項に記載の方法。
16. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内のルータであって、
    第2のBIERドメインのマルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを決定し、前記BIFT−idは、第1のビット転送出力ルータBFERのビット転送ルータ識別子BFR−idが属するサブセット識別子SIおよび前記第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、前記ビット列は、前記第1のBFERの前記BFR−idに少なくとも基づいて決定され、前記第1のBFERは、前記マルチキャストデータを受信するために使用される前記第2のBIERドメイン内のBFERである、ように構成された処理ユニットであって、
    前記処理ユニットは、前記マルチキャストデータをBIERデータパケットにカプセル化し、前記BIERデータパケットのBIERヘッダは、前記第2のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idおよび前記ビット列を含む、ようにさらに構成されており、
    前記処理ユニットは、前記第1のBFIRによって前記BIERデータパケットにラベルを付け、前記ラベルは、前記第2のBIERドメイン内の第2のBFIRのプレフィックスに対応するラベルである、ように構成されている、処理ユニットと、
    前記ラベル付けされたBIERデータパケットを前記第2のBFIRに送信するように構成された通信ユニットと
    を備えるルータ。
17. 前記処理ユニットは、第1のマッピングテーブルから、前記第2のBIERドメインの前記マルチキャストデータに対応する前記ビット列および前記BIFT−idを決定し、前記第1のマッピングテーブルは、少なくとも1つのBIERドメインの前記マルチキャストデータに対応するBIFT−idおよびビット列を含む、ように特に構成されている、請求項16に記載のルータ。
18. 前記処理ユニットは、前記第2のBIERドメイン内の前記第1のBFIRの論理ネクストホップのプレフィックスを決定するようにさらに構成されており、前記第2のBIERドメイン内の前記第1のBFIRの前記論理ネクストホップは、前記第2のBFIRである、請求項16または17に記載のルータ。
19. 前記処理ユニットは、第2のマッピングテーブルから前記第2のBIERドメイン内の前記第1のBFIRの前記論理ネクストホップの前記プレフィックスを決定し、前記第2のBIERドメイン内の前記第1のBFIRの前記論理ネクストホップの前記プレフィックスは、前記第2のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idに対応するプレフィックスであり、前記第2のマッピングテーブルは、少なくとも1つのBIERドメインの前記マルチキャストデータに対応するBIFT−idと、前記少なくとも1つのBIERドメイン内の前記第1のBFIRの論理ネクストホップのプレフィックスとを含む、ように特に構成されている、請求項18に記載のルータ。
20. 前記通信ユニットは、BGP接続を介して第1のBGPメッセージを前記第2のBIERドメイン内のBFIRおよびBFERに送信し、前記第1のBGPメッセージで運ばれるイントラPマルチキャストサービスインターフェース自動検出ルートIntra PMSI A−D routeは、BIER識別子と、前記マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ようにさらに構成されており、
    前記通信ユニットは、前記第2のBFIRによって送信された第2のBGPメッセージを前記BGP接続を介して受信し、前記第2のBGPメッセージで運ばれるリーフ自動検出ルートleaf A−D routeは、前記第2のBFIRの前記プレフィックスおよび前記第2のBIERドメインの識別子を含む、ようにさらに構成されており、
    前記通信ユニットは、前記第1のBFERによって送信された第3のBGPメッセージを前記BGP接続を介して受信し、前記第3のBGPメッセージで運ばれるleaf A−D routeは、前記第1のBFERの前記BFR−id、前記第1のBFERが属する前記BFR−idの前記SI、および前記第2のBIERドメインの前記識別子を含む、ようにさらに構成されている、請求項16から19のいずれか一項に記載のルータ。
21. 前記第3のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERが属するサブドメインsub−domainをさらに含む、請求項20に記載のルータ。
22. 前記第3のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERによってサポートされている前記ビット列長をさらに含む、請求項20または21に記載のルータ。
23. 前記第2のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idは、前記第1のBFERが属する前記sub−domainに基づいてさらに決定される、請求項16から22のいずれか一項に記載のルータ。
24. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内のルータであって、
    第2のBIERドメイン内の第2のビット転送入力ルータBFIRによって送信されたラベル付けされたBIERデータパケットを受信し、前記ラベルは、前記第1のBFIRのプレフィックスに対応するラベルであり、前記BIERデータパケットは、前記第2のBFIRによりマルチキャストデータをカプセル化することによって取得され、前記BIERデータパケットのBIERヘッダは、前記第1のBIERドメインの前記マルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを含み、前記BIFT−idは、第1のビット転送出力ルータBFERのビット転送ルータ識別子BFR−idが属するサブセット識別子SIおよび前記第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、前記ビット列は、前記第1のBFERの前記BFR−idに少なくとも基づいて決定され、前記第1のBFERは、前記マルチキャストデータを受信するために使用される前記第1のBIERドメイン内のBFERである、ように構成された通信ユニットと、
    前記BIERデータパケットを取得するために前記ラベルを除去し、前記BIERデータパケットの前記BIERヘッダから前記BIFT−idおよび前記ビット列を取得するように構成された処理ユニットと
    を備え、前記通信ユニットは、前記BIFT−idおよび前記ビット列によって示されるBIFTに基づいて前記BIERデータパケットを前記第1のBFERに転送するようにさらに構成されている、ルータ。
25. 前記通信ユニットは、前記第2のBFIRによって送信された第1のBGPメッセージをBGP接続を介して受信し、前記第1のBGPメッセージで運ばれるイントラPマルチキャストサービスインターフェース自動検出ルートIntra PMSI A−D routeは、BIER識別子と、前記マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ようにさらに構成されており、
    前記通信ユニットは、前記第1のBGPメッセージに応答して前記BGP接続を介して第2のBGPメッセージを前記第2のBFIRに送信し、前記第2のBGPメッセージで運ばれるリーフ自動検出ルートleaf A−D routeは、前記第1のBFIRの前記プレフィックスおよび前記第1のBIERドメインの識別子を含む、ようにさらに構成されている、請求項24に記載のルータ。
26. 前記第1のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idは、前記第1のBFERが属するサブドメインsub−domainに基づいてさらに決定される、請求項24または25に記載のルータ。
27. 第1のビット・インデックス・エクスプリシット・レプリケーションBIERドメイン内のルータであって、
    第2のBIERドメイン内の第2のビット転送入力ルータBFIRによって送信された第1のBGPメッセージを、境界ゲートウェイプロトコルBGP接続を介して受信し、前記第1のBGPメッセージで運ばれるイントラPマルチキャストサービスインターフェース自動検出ルートIntra PMSI A−D routeは、BIER識別子と、前記マルチキャストデータに対応するマルチキャストグループの識別子とを含む、ように構成された通信ユニットであって、
    前記通信ユニットは、前記BGP接続を介して第2のBGPメッセージを前記第2のBFIRに送信し、前記第2のBGPメッセージで運ばれるリーフ自動検出ルートleaf A−D routeは、前記第1のBFERのBFR−id、前記第1のBFERの前記BFR−idが属するSI、および前記第1のBIERドメインの識別子を含む、ようにさらに構成されており、
    前記通信ユニットは、前記第1のBIERドメイン内の第1のBFIRによって送信されたBIERデータパケットを受信し、前記BIERデータパケットは、前記第2のBFIRにより前記マルチキャストデータをカプセル化することによって取得され、前記BIERデータパケットのBIERヘッダは、前記第1のBIERドメインの前記マルチキャストデータに対応するビット列およびビットインデックス転送テーブル識別子BIFT−idを含み、前記BIFT−idは、前記第1のBFERの前記ビット転送ルータ識別子BFR−idが属するサブセット識別子SIおよび前記第1のBFERによってサポートされているビット列長に少なくとも基づいて決定され、前記ビット列は、前記第1のBFERの前記BFR−idに少なくとも基づいて決定され、前記第1のBFERは、前記マルチキャストデータを受信するために使用される前記第1のBIERドメイン内のBFERである、ようにさらに構成されている、通信ユニットと、
    前記マルチキャストデータを取得するために前記BIERデータパケットをデカプセル化するように構成された処理ユニットと
    を備え、前記通信ユニットは、前記マルチキャストデータをユーザ側デバイスに送信するようにさらに構成されている、ルータ。
28. 前記第2のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERが属するサブドメインsub−domainをさらに含む、請求項27に記載のルータ。
29. 前記第2のBGPメッセージで運ばれる前記leaf A−D routeは、前記第1のBFERによってサポートされている前記ビット列長をさらに含む、請求項27または28に記載のルータ。
30. 前記第1のBIERドメインの前記マルチキャストデータに対応する前記BIFT−idは、前記第1のBFERが属する前記サブドメインに基づいてさらに決定される、請求項27から29のいずれか一項に記載のルータ。
31. 第1のルータおよび第2のルータを備える通信システムであって、
    前記第1のルータは、請求項24から26のいずれか一項に記載のルータであり、前記第2のルータは、請求項27から30のいずれか一項に記載のルータである、通信システム。
32. 第3のルータをさらに備え、前記第3のルータは、請求項16から23のいずれか一項に記載のルータである、請求項31に記載の通信システム。
33. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は、命令を記憶しており、前記命令がコンピュータ上で実行されるとき、前記コンピュータは、請求項1から15のいずれか一項に記載の方法を実行する、コンピュータ可読記憶媒体。
34. コンピュータプログラム製品であって、前記コンピュータプログラム製品がコンピュータ上で実行されるとき、前記コンピュータは、請求項1から15のいずれか一項に記載の方法を実行する、コンピュータプログラム製品。

Images