JP2022535405A - Ｂｉｅｒパケット送信方法及び装置 - Google Patents

Ｂｉｅｒパケット送信方法及び装置 Download PDF

Info

Publication number
JP2022535405A
JP2022535405A JP2021571827A JP2021571827A JP2022535405A JP 2022535405 A JP2022535405 A JP 2022535405A JP 2021571827 A JP2021571827 A JP 2021571827A JP 2021571827 A JP2021571827 A JP 2021571827A JP 2022535405 A JP2022535405 A JP 2022535405A
Authority
JP
Japan
Prior art keywords
bier
header
ipv6
forwarding
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021571827A
Other languages
English (en)
Other versions
JP7322188B2 (ja
Inventor
シエ，ジンルゥォン
シア，ヤン
リゥ，イソォン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2022535405A publication Critical patent/JP2022535405A/ja
Application granted granted Critical
Publication of JP7322188B2 publication Critical patent/JP7322188B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/32—Flooding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

この出願は、ＢＩＥＲパケット送信方法を提供する。当該方法は、ＩＰｖ６プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信し該ＢＩＥＲパケットはＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは第１の転送装置の第１のＩＰｖ６アドレスであり、転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定し、該識別子は、第１のＩＰｖ６アドレスがＢＩＥＲ転送用の宛先アドレスであることを指し示すために使用されることを含む。この出願にて提供される技術的ソリューションでは、ノードが、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を行うことを決定し得る。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスに基づいてパケットタイプを決定することを防ぐ。従って、転送効率が改善される。

Description

この出願は、“ＢＩＥＲパケット送信方法及び装置”と題して２０１９年６月６日に中国特許庁に出願された中国特許出願第２０１９１０４９３１１４．７号に対する優先権を主張するものであり、それをその全体にてここに援用する。
この出願は、ネットワーク通信分野に関し、より具体的には、ビットインデックス明示的複製ＢＩＥＲパケット送信方法及び装置に関する。
インターネットプロトコル（internet protocol、ＩＰ）マルチキャスト技術は、ＩＰネットワーク上での効率的なポイント・ツー・マルチポイントデータ伝送を実現し、それにより、ネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減させる。従って、インターネットプロトコルマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビジョン（internet protocol television、ＩＰＴＶ）、ゲーム、シミュレーション、及びこれらに類するものにおいて広く使用されている。マルチキャスト技術を用いたマルチキャストプロトコルによれば、ポイント・ツー・マルチポイントデータ転送を実現するために、ネットワークプレーンを論理ツリー状の構造にするように制御プレーンマルチキャストツリーを構築する必要がある。配信ツリー構築を中核とするこのようなマルチキャストルーティングプロトコルにおけるトランジットノードは、マルチキャスト転送情報の複雑なステータスを維持管理する必要がある。ネットワーク規模が大きくなり、マルチキャストデータトラフィックがますます増えるにつれて、マルチキャスト技術は、ますます高まるコスト、並びに大きな運用及び保守上の難題に直面する。
これに対処するために、マルチキャストデータ転送パスを構築するための新しい技術が業界で提唱され、ビットインデックス明示的複製（bitindexed explicit replication、ＢＩＥＲ）技術と呼ばれている。この技術は、マルチキャスト配信ツリーを構築する必要のない新しいマルチキャスト技術アーキテクチャを提案するものである。ＢＩＥＲ技術をサポートする転送ノードは、カプセル化されたＢＩＥＲヘッダ情報に基づいてＢＩＥＲドメインでＢＩＥＲパケットを転送することができる。
ＢＩＥＲパケットは、インターネットプロトコルバージョン６（internet protocol version 6、ＩＰｖ６）を用いた伝送のためにカプセル化される必要がある。従来の技術的ソリューションでは、ＢＩＥＲ技術をサポートする転送ノードが、各ノードによってフラッディングされる一般ＩＰアドレスを、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドにカプセル化する。しかしながら、一般ＩＰアドレスが宛先アドレスフィールド内に埋められるので、ＢＩＥＲパケットを受信するノードが、宛先アドレスフィールド内のＩＰｖ６アドレスに基づいてパケットフォーマットのタイプを決定する必要があり、それにより比較的低い転送効率をもたらす。
故に、転送効率をどのように改善するかが、現在喫緊に解決される必要がある問題となっている。
この出願は、ＢＩＥＲパケット送信方法及び装置を提供する。隣接ノードの第１のＩＰｖ６アドレスが、ＩＰｖ６拡張ヘッダ内の宛先アドレスフィールドに埋められ得る。斯くして、隣接ノードは、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスと他のフィールドとに基づいてパケットタイプを一つ一つ決定することを防止する。従って、転送効率が改善される。
第１の態様によれば、ＢＩＥＲパケット送信方法が提供される。当該方法は、第１の転送装置が、インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信することを含み、ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、第１の転送装置の第１のＩＰｖ６アドレスである。第１の転送装置は、転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定し、該識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される。
前述の技術的ソリューションでは、隣接ノードの第１のＩＰｖ６アドレスをＩＰｖ６拡張ヘッダ内の宛先アドレスフィールドに埋めることで、隣接ノードが、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定するようにし得る。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスと他のフィールドとに基づいてパケットタイプを一つ一つ決定することを防止する。従って、転送効率が改善される。
取り得る一実装において、第１の転送装置は、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが転送テーブル内の第１のＩＰｖ６アドレスと同じであることを決定し、そして、第１の転送装置は、第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。
取り得る他の一実装において、第１の転送装置は、第１のＩＰｖ６アドレス及び識別子を設定する。
取り得る他の一実装において、第１の転送装置が、インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信する前に、当該方法は更に、第１の転送装置が、ルーティングプロトコルを用いて、第１の転送装置の第１のＩＰｖ６アドレス及び識別子をネットワークにフラッディングすること、を含む。
前述の技術的ソリューションでは、第１の転送装置が第１のＩＰｖ６アドレス及び識別子をネットワーク内の他のノードにフラッディングすることで、ネットワーク内の他のノードが、転送テーブルを構築し、第１の転送装置によってフラッディングされた第１のＩＰｖ６アドレスに基づいてパケットをカプセル化するようにし得る。
理解されるべきことには、ルーティングプロトコルを用いることによって第１の転送装置によってネットワークにフラッディングされる第１のＩＰｖ６アドレス及び識別子は、ＢＩＥＲメッセージと同じメッセージ内で運ばれてもよいし、あるいは、ＢＩＥＲメッセージとは異なるメッセージ内であってもよい。これは、この出願において特に限定されることではない。
取り得る他の一実装において、第１のＩＰｖ６アドレスは、セグメントルーティング・オーバ・ＩＰｖ６（IPv6 segment routing、ＳＲｖ６）のセグメント識別子（segment identify、ＳＩＤ）である。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダ（next header、ＮＨ）フィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、第１の転送装置は、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダ（routingheader、）ＲＨ）であり、且つルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、第１の転送装置は、ルーティングヘッダＲＨをポッピングし、且つＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。
取り得る他の一実装において、ルーティングヘッダＲＨはセグメントルーティングヘッダ（segmentroutingheader、ＳＲＨ）であり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、第１の転送装置は、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、４、４１、９７、又は１３７であるときに、第１の転送装置は、ＩＰｖ６基本ヘッダをポッピングし、ユーザデータパケットを転送する。
取り得る他の一実装において、第１の転送装置は、ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、ＢＩＥＲ転送テーブルは、第３の転送装置によってフラッディングされたメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築され、そして、第１の転送装置は、ＢＩＥＲ転送テーブルに基づいてＢＩＥＲパケットを第３の転送装置に対して複製する。
取り得る他の一実装において、第１の転送装置は、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、第１の転送装置は、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングし、そして、第１の転送装置は、拡張ヘッダを含まないＢＩＥＲパケットを第３の転送装置に対して複製する。
取り得る他の一実装において、第３の転送装置がリーフノードであると決定したときに、第１の転送装置は、１つ以上のＢＩＥＲヘッダを運ぶ拡張ヘッダをポッピングする。
取り得る他の一実装において、拡張ヘッダは宛先オプションヘッダである。
取り得る他の一実装において、ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを含む。
第２の態様によれば、ＢＩＥＲパケット送信装置が提供され、当該装置は、
インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信するように構成された受信モジュールであり、ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、第１の転送装置の第１のＩＰｖ６アドレスである、受信モジュールと、
転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定するように構成された処理モジュールであり、識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される、処理モジュールと、
を含む。
取り得る一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが転送テーブル内の第１のＩＰｖ６アドレスと同じであることを決定するように構成される。第１の転送装置は、第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。
取り得る他の一実装において、当該装置は更に、第１のＩＰｖ６アドレス及び識別子を設定するように構成された設定モジュール、を含む。
取り得る他の一実装において、当該装置は更に、ルーティングプロトコルを用いて、第１の転送装置の第１のＩＰｖ６アドレス及び識別子をネットワークにフラッディングするように構成された送信モジュール、を含む。
取り得る他の一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成されている。
取り得る他の一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダＲＨであり、且つルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ルーティングヘッダＲＨをポッピングし、且つＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成されている。
取り得る他の一実装において、ルーティングヘッダＲＨはセグメントルーティングヘッダＳＲＨであり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である。
取り得る他の一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成されている。
取り得る他の一実装において、処理モジュールは具体的に、ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、ＢＩＥＲ転送テーブルは、第３の転送装置によってフラッディングされたＢＩＥＲメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築される、ように構成されており、第１の転送装置は、ＢＩＥＲ転送テーブルに基づいてＢＩＥＲパケットを第３の転送装置に対して複製する。
取り得る他の一実装において、処理モジュールは具体的に、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングし、拡張ヘッダを含まないＢＩＥＲパケットを第３の転送装置に対して複製する、ように構成されている。
取り得る他の一実装において、処理モジュールは具体的に、第３の転送装置がリーフノードであると決定したときに、１つ以上のＢＩＥＲヘッダを運ぶ拡張ヘッダをポッピングする、ように構成されている。
取り得る他の一実装において、拡張ヘッダは宛先オプションヘッダである。
取り得る他の一実装において、ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを含む。
第３の態様によれば、入力／出力インタフェースと、プロセッサと、メモリとを含む第１転送装置が提供され、プロセッサは、入力／出力インタフェースを制御して情報を送信及び受信するように構成され、メモリは、コンピュータプログラムを格納するように構成され、プロセッサが、メモリからコンピュータプログラムを呼び出してコンピュータプログラムを実行することで、第１の態様又は第１の態様の取り得る実装のうちのいずれか１つに従った方法を当該第１転送装置が実行する。
オプションで、プロセッサは、汎用プロセッサであってもよく、ハードウェア又はソフトウェアを用いて実装され得る。ハードウェアを用いてプロセッサが実装されるとき、プロセッサは、論理回路、集積回路、又はこれらに類するものとし得る。ソフトウェアを用いてプロセッサが実装されるとき、プロセッサは、汎用プロセッサとすることができ、メモリに格納されたソフトウェアコードを読み出すことによって実装される。メモリは、プロセッサ内に集積されてもよいし、あるいは、プロセッサの外部に置かれて独立に存在してもよい。
第４の態様によれば、コンピュータプログラムプロダクトが提供される。当該コンピュータプログラムプロダクトは、コンピュータプログラムコードを含む。該コンピュータプログラムコードがコンピュータ上で実行されるとき、該コンピュータは、前述の態様における方法を実行することを可能にされる。
第５の態様によれば、コンピュータ読み取り可能媒体が提供される。当該コンピュータ読み取り可能媒体はプログラムコードを格納しており、該コンピュータプログラムコードがコンピュータ上で実行されるとき、該コンピュータは、前述の態様における方法を実行することを可能にされる。
第６の態様によれば、システムが提供される。当該システムは、第１の転送ノード、第２の転送ノード、及び第３の転送ノードを含み、第１の転送ノードは、第１の態様又は第１の態様の取り得る実装のうちのいずれか１つに従った方法を実行するように構成される。第２の転送ノードは、第１の転送ノードによってフラッディングされた第１のＩＰｖ６アドレスに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールドを埋め、そして、ＢＩＥＲパケットを第１の転送ノードに送信するように構成される。第３の転送ノードは、第１の転送ノードによって送信されたＢＩＥＲパケットを受信し、そして、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが、当該第３の転送ノードに対して設定された第１のＩＰｖ６アドレスであることに基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行するように構成される。
この出願の一実施形態に従ったＢＩＥＲ技術の概略ネットワーキング図である。 この出願の一実施形態に従った、ＢＩＥＲドメインでＢＩＥＲヘッダに基づいてＢＩＥＲパケットを送信することの概略ブロック図である。 この出願の一実施形態に従ったＢＩＥＲｖ６パケットフォーマットの概略図であ。 この出願の一実施形態に従ったＢＩＥＲパケット送信方法の概略フローチャートである。 この出願の一実施形態に従ったＳＲｖ６ ｌｏｃａｔｏｒメッセージフォーマットの概略図である。 この出願の一実施形態に従ったＩＰｖ６－ｐｒｅｆｉｘメッセージフォーマットの概略図である。 この出願の一実施形態に従ったＢＩＥＲパケット送信装置７００の概略構成図である。 この出願の一実施形態に従った第１転送装置８００の概略構成図である。
以下、添付の図面を参照して、この出願の技術的ソリューションを説明する。
インターネットプロトコル（internet protocol、ＩＰ）マルチキャスト技術は、ＩＰネットワーク上での効率的なポイント・ツー・マルチポイントデータ伝送を実現し、それにより、ネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減させる。従って、インターネットプロトコルマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビジョン（internet protocol television、ＩＰＴＶ）、ゲーム、シミュレーション、及びこれらに類するものにおいて広く使用されている。マルチキャスト技術を用いたマルチキャストプロトコルによれば、ポイント・ツー・マルチポイントデータ転送を実現するために、ネットワークプレーンを論理ツリー状の構造にするように制御プレーンマルチキャストツリーを構築する必要がある。配信ツリー構築を中核とするこのようなマルチキャストルーティングプロトコルにおけるトランジットノードは、マルチキャスト転送情報の複雑なステータスを維持管理する必要がある。ネットワーク規模が大きくなり、マルチキャストデータトラフィックがますます増えるにつれて、マルチキャスト技術は、ますます高まるコスト、並びに大きな運用及び保守上の難題に直面する。
これに対処するために、マルチキャストデータ転送パスを構築するための新しい技術が業界で提唱され、ビットインデックス明示的複製（bitindexed explicit replication、ＢＩＥＲ）技術と呼ばれている。当該技術は、マルチキャスト配信ツリーを構築する必要のない新しいマルチキャスト技術アーキテクチャを提案するものである。図１に示すように、ＢＩＥＲ技術をサポートするルータは、ビット転送ルータ（BIER forwarding router、ＢＦＲ）と称されることがあり、ＢＦＲ装置は、ＢＩＥＲパケットを受信して転送し得る。１つ以上のＢＦＲを含むマルチキャスト転送ドメインは、ＢＩＥＲドメイン（BIER domain）と称される。ＢＩＥＲドメインのエッジにおいて、ユーザのマルチキャストデータに対してＢＩＥＲデータパケットカプセル化を実行する装置は、ビット転送イングレスルータ（BIERforwarding ingress router、ＢＦＩＲ）と称され、ＢＩＥＲデータパケットをカプセル解除する装置は、ビット転送エグレスルータ（BIERforwarding egress router、ＢＦＥＲ）と称される。
ＢＩＥＲドメインにおいて、各エッジノード（例えば、ＢＦＥＲ）は、ＢＩＥＲサブドメイン（sub domain、ＳＤ）全体内でグローバルに一意であるビット位置（bit position）を有して設定される。例えば、値は、例えば１から２５６の範囲の値といった各エッジノードに対するＢＦＲ識別子（identification、ＩＤ）として設定され得る。ＢＩＥＲドメイン内の全てのＢＦＲＩＤがビット列（bit string）を形成する。ＢＩＥＲドメイン内でユーザデータトラフィック（ＢＩＥＲパケットとも称される）の伝送のために、特定のＢＩＥＲヘッダをカプセル化する必要がある。ＢＩＥＲヘッダは、ユーザデータトラフィックの全ての宛先ノードを特定するビット列を含む。ＢＩＥＲドメイン内のトランジットノードは、ユーザデータトラフィックを全ての宛先アドレスに送ることができることを保証するよう、ＢＩＥＲヘッダ内で運ばれるビット列に基づいてルーティングを実行する。
ノードに対して設定されたビット位置情報は、内部ゲートウェイプロトコル（interior gateway protocol、ＩＧＰ）又は境界ゲートウェイプロトコル（border gateway protocol、ＢＧＰ）を用いることによって、前もってＢＩＥＲドメイン内にフラッディングされる。そして、ＢＩＥＲドメイン内の各ノードに転送されるべきユーザデータトラフィックを指し示すために、ビットインデックス転送テーブル（bit index forwarding table、ＢＩＦＴ）が形成される。ＢＩＥＲヘッダとともにカプセル化されたＢＩＥＲパケットを受信すると、ＢＦＲはＢＩＦＴに従って、ＢＩＥＲパケットを宛先ノードに転送する。この出願の実施形態において、内部ゲートウェイプロトコルＩＧＰは、以下に限られないが、オープン最短パスファースト（open shortest path first、ＯＳＰＦ）プロトコル、中間システム間（intermediate system tointermediate system、ＩＳＩＳ）プロトコル、及びこれらに類するものを含み得る。
理解を容易にするために、以下にて、ＢＩＥＲ技術における基本概念を説明する。
（１）ＢＩＦＴ ＩＤ
ＢＩＦＴ ＩＤフィールドは、サブドメイン（sub-domain、ＳＤ）／ビット列長（bit string length、ＢＳＬ）／セット識別子（set identifier、ＳＩ）の組み合わせを含み得る。異なるＢＩＦＴ ＩＤは、ＳＤ／ＢＳＬ／ＳＩの異なる組み合わせに対応し得る。
１． サブドメイン（ＳＤ）
ＢＩＥＲドメインは、実際のサービスシナリオの要求に従って複数の異なるサブドメインＳＤを有して構成され得る。各サブドメインＳＤが、範囲［０－２５５］内の８ビット値であるサブドメイン識別子（sub-domain identify、ＳＤ－ＩＤ）で表される。例えば、例えば異なる仮想プライベートネットワーク（virtual private network、ＶＰＮ）といった異なるサービスに基づいて、ＢＩＥＲドメイン内に異なるＳＤが構成され得る。例えば、ＶＰＮ １はＳＤ ０を使用し、ＶＰＮ １はＳＤ １を使用する。
なお、代わりに複数のＶＰＮが同じＳＤを使用してもよい。ＢＩＥＲドメイン内の異なるＳＤは、同一のＩＧＰプロセス又はトポロジー内にあってもよいし、あるいは同一のＩＧＰプロセス又はトポロジー内になくてもよい。これは、この出願の実施形態において特に限定されることではない。
２． ビット列長（ＢＳＬ）
ＢＳＬは、ＢＩＥＲヘッダに含まれるビット列の長さである。複数のＢＳＬが存在し得る。これは、この出願の実施形態において特に限定されることではない。ＢＳＬは、６４ビット（最小）、１２８ビット、２５６ビット、５１２ビット、１０２４ビット、２０４８ビット、又は４０９６ビット（最大）とし得る。具体的には、パケットの識別に４ビットが使用される。例えば、ＢＳＬが６４ビットであるとき、０００１がパケットの識別に使用され、ＢＳＬが１２８ビットであるとき、００１０がパケットの識別に使用され、ＢＳＬが５１２ビットであるとき、０１００がパケットの識別に使用され、ＢＳＬが１０２４ビットであるとき、０１０１がパケットの識別に使用され、等々である。
３． セット識別子（ＳＩ）
ＳＩは、ネットワーク内の複数のノード又は設定されたＢＦＲ ＩＤを含むセットとして理解され得る。例えば、ＢＳＬが２５６ビットであるが、ネットワークに２５６よりも多いノードが存在する又は２５６よりも多いＢＦＲ ＩＤが設定されているとき、それらのノード又はＢＦＲ ＩＤは複数の異なるセットに分割される必要がある。例えば、そのＢＦＲ ＩＤが１から２５６であるノードがセット０（setindex ０、すなわち、ＳＩ＝０）を形成し、そのＢＦＲ ＩＤが２５７から５１２であるノードがセット１（setindex １、すなわち、ＳＩ＝１）を形成する。
ＢＩＥＲパケットを受信した後、ＢＩＥＲドメイン内のＢＦＲは、ＢＩＥＲヘッダ内のＢＩＦＴ ＩＤに基づいて、ＢＩＥＲパケットが属するＳＤ、使用されるＢＳＬ、及びパケット又は設定されたＢＦＲ ＩＤを転送するノードを含むセットを決定し得る。
以下に、ＢＩＦＴ ＩＤによって表されるＳＤ／ＢＳＬ／ＳＩの幾つかの取り得る組み合わせを列記する：
ＢＩＦＴ ＩＤ＝９１：ＳＤ ０、ＢＳＬ ２５６、ＳＩ ０に対応
ＢＩＦＴ ＩＤ＝９２：ＳＤ ０、ＢＳＬ ２５６、ＳＩ １に対応
ＢＩＦＴ ＩＤ＝９３：ＳＤ ０、ＢＳＬ ２５６、ＳＩ ２に対応
ＢＩＦＴ ＩＤ＝９４：ＳＤ ０、ＢＳＬ ２５６、ＳＩ ３に対応
ＢＩＦＴ ＩＤ＝９５：ＳＤ ０、ＢＳＬ ５１２、ＳＩ ０に対応
ＢＩＦＴ ＩＤ＝９６：ＳＤ ０、ＢＳＬ ５１２、ＳＩ １に対応。
例えば、ＢＩＦＴ ＩＤが９２であるとき、ＢＩＥＲパケットを受信した後、ＢＦＲは、ＢＩＥＲヘッダ内のＢＩＦＴ ＩＤに基づいて、ＢＩＥＲパケットがＳＤ ０に属し、ＢＩＥＲヘッダで使用されるＢＳＬが２５６ビットであり、且つＢＩＥＲパケットがセット１（そのＢＦＲ ＩＤが２５７から５１２であるノードを含むセット）に属することを決定し得る。
（２）ＢＦＲプレフィックス（BFR-prefix）
ＢＦＲプレフィックスは、各ＢＦＲのアドレス情報である。各ＢＦＲのアドレス情報は、ＢＩＥＲドメイン内で一意であり、ルータ識別子（routinidentifier）と等価である。具体的には、ＢＦＲ－ｐｒｅｆｉｘは一般にＢＦＲ装置のループバック（loopback）アドレスである。
（３）ビット列（bit string）
ビット列内の各ビットは、ＢＩＥＲパケットを受信する次ホップノードを指し示すために使用され得る。ＢＩＥＲドメイン内のＢＦＲがＢＩＥＲパケットヘッダを受信すると、ＢＦＲは、ＢＩＥＲヘッダ内で運ばれるビット列及びＢＩＦＴ ＩＤに基づいてＢＩＥＲパケットを転送する。
例えば、ＢＦＲによって受信されたＢＩＥＲヘッダ内のＢＩＦＴ ＩＤは９２であり、ビット列の長さは２５６ビットであり、ＢＩＥＲパケットを転送するノードは、そのＢＦＲ ＩＤが２５７から５１２であるノードのうちの１つである。ビット列内の最下位ビット（最も右のビット）は、宛先ノードがそのＢＦＲ ＩＤが２５７であるノードであることを指し示すために使用され、右から左に２番目のビットは、宛先ノードがそのＢＦＲ ＩＤが２５８であるノードであることを指し示すために使用される。
図２を参照して、以下、ＢＩＥＲ技術に基づいてＢＩＥＲパケットを転送するプロセスを詳細に説明する。
図２に示すように、各ＢＩＥＲドメイン内のエッジノードに一意なＢＦＲ－ｉｄを割り当てる必要がある。例えば、エッジノードＡ、Ｄ、Ｅ、及びＦに設定されるＢＦＲ－ｉｄは、それぞれ、４、１、２、及び３である。ＢＩＥＲヘッダ内にカプセル化されたビット列が、トラフィックの全ての宛先ノードを特定する。例えば、そのＢＦＲ－ｉｄが１であるノードＤに対応するビット列は０００１であり、そのＢＦＲ－ｉｄが２であるノードＦに対応するビット列は００１０であり、そのＢＦＲ－ｉｄが３であるノードＥに対応するビット列は０１００であり、そのＢＦＲ－ｉｄが４であるノードＡに対応するビット列は１０００である。
理解されるべきことには、各ＢＩＥＲドメイン内のエッジノードに割り当てられるＢＦＲ－ｉｄ値を、ルーティングプロトコルを用いることによって該ＢＩＥＲドメイン内の他のネットワーク装置にフラッディングすることができ、フラッディングされるＢＩＥＲ情報は更に、ネットワークノードのＩＰアドレス及びカプセル化情報を含む。例えば、ノードＡのフラッディングされるＢＩＥＲ情報は、ノードＡのＩＰアドレス及びＢＩＦＴ－ｉｄを運ぶ。ＢＩＥＲドメイン内のノードは、フラッディングされたＢＩＥＲ情報に基づいてビットインデックス転送テーブルＢＩＦＴを構築し得る。ＢＩＥＲパケットを受信した後、ノードは、構築したＢＩＦＴに従ってＢＩＥＲパケットを宛先ノードに転送する。
ノードＡの場合、そのＢＦＲ－ｉｄが１、２、及び３であるのＢＩＥＲノードへの次ホップはノードＢであり、そのＢＦＲ－ｉｄが４であるＢＩＥＲノードへの次ホップはノードＡ自身である。従って、ノードＡによって構築されるＢＩＦＴは次のようになる：
転送エントリ１：隣接（neighbor、Ｎｂｒ）＝Ｂ、転送ビットマスク（forwarding bit mask、ＦＢＭ）＝０１１１；
転送エントリ２：Ｎｂｒ＊＝Ａ、ＦＢＭ＝１０００。
転送エントリ１は、ＢＩＥＲパケット内のビット列のうち、右から左に１番目のビット、２番目のビット、又は３番目のビットのいずれか１つが１であるときに、ＢＩＥＲパケットが隣接ノードＢに送られることを指し示すために使用される。転送エントリ２は、ＢＩＥＲパケット内のビット列のうち、右から左に４番目のビットが１であるときに、ＢＩＥＲパケットがノードＡに送られることを指し示すために使用される。ノードＡはそれ自身であるため、ノードＡはＢＩＥＲヘッダを取り除き、ＢＩＥＲパケットを元のユーザデータパケットとして転送する。
なお、転送エントリにおいて、＊は、Ｎｂｒがノードそれ自身であることを指し示すために使用される。同様に、他のノードも、隣接ノードに基づいてＢＩＦＴを構築し得る。詳細については、図２を参照されたい。詳細をここで再び説明することはしない。
ユーザデータパケットを受信した後、ノードＡは、ユーザデータパケットをＢＩＥＲヘッダとともにカプセル化する。一例において、ユーザデータパケットを受信した後、ノードＡは、境界ゲートウェイプロトコルＢＧＰメッセージに基づいて、ユーザデータパケットの受取人を知ることができる。例えば、ユーザデータパケットの受取人は、そのＢＦＲ－ｉｄが３であるノードＥ、そのＢＦＲ－ｉｄが２であるノードＦ、及びそのＢＦＲ－ｉｄが１であるノードＤである。ノードＡは、ビット列が０１１１であるＢＩＥＲヘッダとともにＢＩＥＲパケットをカプセル化し、カプセル化したＢＩＥＲパケットを転送エントリ１に基づいて隣接ノードＢに転送する。ＢＩＥＲパケットを受信した後、ノードＢは、ビット列０１１１とＢＩＦＴとに基づいて、ＢＩＥＲパケットがノードＣ及びノードＥに別々に送信される必要があることを決定する。ＢＩＥＲパケットをノードＣに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列０１１１とＢＩＦＴ内のＮｂｒ＝ＣエントリのＦＢＭフィールドとに対してＡＮＤ演算を実行し得る。この出願のこの実施形態では、ＡＮＤの結果は００１１である。従って、ノードＢは、ＢＩＥＲヘッダ内のビット列を００１１に変更し、ＢＩＥＲパケットをノードＣに送信し得る。同様に、ＢＩＥＲパケットをノードＥに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列を０１００に変更し得る。ＢＩＥＲパケットを受信した後、ノードＥは、ビット列０１００に基づいて、ＢＩＥＲパケットが隣接ノードＥに送られるべきであると決定する。ノードＥは、転送テーブル内の識別子＊に従って、隣接ノードＥがノードＥ自身であると決定するので、ノードＥは、ＢＩＥＲヘッダをカプセル解除し、内部層のユーザデータパケットの宛先アドレスに基づいてＢＩＥＲパケットを転送する。
理解されるべきことには、ＢＩＥＲヘッダは、異なるプロトコルでは異なるカプセル化フォーマットを持つ。ＩＰｖ６を用いてカプセル化されたＢＩＥＲパケットは、ＢＩＥＲｖ６パケットとも称されることがある。リンク層にイーサネットリンクを使用するＢＩＥＲｖ６パケットのフォーマットは次の通りである：
Ｅｔｈヘッダ＋ＩＰｖ６基本ヘッダ＋ＩＰｖ６拡張ヘッダ（ＢＩＥＲヘッダを含む）＋ユーザデータパケット
なお、説明を容易にするために、ＢＩＥＲｖ６パケットのカプセル化がイーサネットリンク層にオーバーレイされる例を用いる。この出願のこの実施形態において、ＢＩＥＲカプセル化は代わりに、例えばポイント・ツー・ポイントプロトコル（pointtopoint protocol、ＰＰＰ）リンクといった別タイプのリンクにオーバーレイされてもよい。
理解されるべきことには、複数のＩＰｖ６拡張ヘッダタイプが存在し、例えば、ＩＰｖ６拡張ヘッダが宛先オプションヘッダ（destination options header）とし得る。これは、この出願の実施形態において特に限定されることではない。
図３を参照して、以下、ＩＰｖ６拡張ヘッダが宛先オプションヘッダである例を使って、ＩＰｖ６を用いてカプセル化されたＢＩＥＲパケットのフォーマットを詳細に説明する。
図３を参照するに、ＢＩＥＲｖ６パケットは、ＢＩＥＲｖ６ヘッダ及び内部層のユーザデータパケット（例えば、ＩＰｖ６パケットとし得る）を含み得る。ＢＩＥＲｖ６ヘッダは、ＩＰｖ６基本ヘッダと宛先オプションヘッダとを含み得る。宛先オプションヘッダがＢＩＥＲヘッダを運ぶ。ＢＩＥＲヘッダに関する詳細については、前述の説明を参照されたい。詳細をここで再び説明することはしない。
（１）ＩＰｖ６基本ヘッダ
バージョン（version）：４ビット長
トラフィッククラス（traffic class、ＴＣ）：８ビット長。このフィールドは、ＩＰｖ６パケットのクラス及び優先度を指し示す。
フローラベル（flow label）：２０ビット長。“フロー”は、ネットワーク上の特定の送信元アドレスから特定の宛先アドレスへのデータパケットとして理解され得る。同一“フロー”に属するデータパケットは、同じフローラベルを持つ。
ペイロード長（payload length）：１６ビット長。このフィールドは、ＩＰｖ６基本ヘッダ以外の長さ、例えば、ＩＰｖ６拡張ヘッダ及び内部層のユーザデータパケットの長さ、を指し示す。
次ヘッダ（next header、ＮＨ）：８ビット長。このフィールドは、ＩＰｖ６基本ヘッダのすぐ後に続くＩＰｖ６拡張ヘッダの識別子（すなわち、ＩＰｖ６拡張ヘッダのタイプ）として理解されることができ、各ＩＰｖ６拡張ヘッダもＮＨフィールドを含む。
ホップ限度（hop limit、ＨＬ）：８ビット長。このフィールドは、ＩＰｖ４パケットヘッダ内の有効期間（time to live、ＴＴＬ）フィールドと同様である。
送信元アドレス（source address、ＳＡ）：１２８ビット長。このフィールドは、データパケットを送信するノードのＩＰｖ６アドレスを埋めるのに使用される。
宛先アドレス（destination address、ＤＡ）：１２８ビット長。このフィールドはデータパケットを受信するノードのＩＰｖ６アドレスを埋めるのに使用される。宛先アドレスフィールドはユニキャストアドレスである。例えば、ノードＤにＢＩＥＲパケットを送るとき、ノードＢは、宛先アドレスフィールドをノードＤのＩＰｖ６アドレスで埋めることができる。
（２）宛先オプションヘッダ（destination options header）
次ヘッダ（next header、ＮＨ）：８ビット長。このフィールドは、宛先オプションヘッダのすぐ後に続くＩＰｖ６拡張ヘッダの識別子（すなわち、ＩＰｖ６拡張ヘッダのタイプ）、又は例えばユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）パケットのタイプといった上位層ヘッダ（upper-layer header）のタイプとして理解され得る。
拡張ヘッダ長（header extend length、Ｈｄｒ Ｅｘｔ Ｌｅｎ）：８ビット長。このフィールドは、例えば宛先オプションヘッダの長さといった、ＩＰｖ６拡張ヘッダの長さを記述する。
タイプ－長さ－値（typelength value、ＴＬＶ）：ＴＬＶ内のタイプ値は、ＴＬＶが１つのＢＩＥＲヘッダを含むことを指し示し、ＴＬＶ内の値部分がＢＩＥＲヘッダ全体を含む。具体的には、ＴＬＶ内のタイプ値は、図３に示されるオプションタイプ（option type）フィールドで運ばれ、値部分は、図３に示されるＢＩＥＲヘッダ（BIER header）フィールドで運ばれる。
この出願のこの実施形態で提供されるＢＩＥＲパケット送信方法によれば、ＢＩＥＲパケットを受信するノードのものであって識別子を運ぶものであるＩＰｖ６アドレスがＩＰｖ６拡張ヘッダの宛先アドレスフィールドに埋められ得る。斯くして、ＢＩＥＲパケットを受信するノードは、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスと他のフィールドとに基づいてパケットタイプを一つ一つ決定することを防止する。従って、転送効率が改善される。
図４は、この出願の一実施形態に従ったＢＩＥＲパケット送信方法の概略フローチャートである。図４の方法は、ステップ４１０及び４２０を含み得る。以下、ステップ４１０及び４２０を別々に詳細に説明する。
ステップ４１０：第１の転送装置が、ＩＰｖ６プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信する。
第１の転送装置によって受信されるＩＰｖ６プロトコルを用いてカプセル化されたＢＩＥＲパケットは、ＩＰｖ６基本ヘッダとＢＩＥＲヘッダとを含む。ＩＰｖ６プロトコルを用いてカプセル化されたＢＩＥＲパケットの具体的なフォーマットについては、図３の説明を参照されたい。詳細をここで再び説明することはしない。
なお、ＢＩＥＲパケットは、マルチキャストデータを含んでいてもよいし、ユニキャストデータを含んでいてもよい。これは、この出願のこの実施形態において特に限定されることではない。
ステップ４２０：第１の転送装置が、ＢＩＥＲパケットにカプセル化され、転送テーブルに含められた第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定し、該識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される。
第１の転送装置は、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが第１のＩＰｖ６アドレスであることを決定し、且つローカルに格納された転送テーブル内に第１のＩＰｖ６アドレスが存在するかを決定する。第１のＩＰｖ６アドレスが設定されている場合、第１の転送装置がＢＩＥＲパケットの受信ノードであることが理解され得る。第１の転送装置は更に、転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行する必要があることを決定することができ、該識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される。
例えば、転送テーブル内に設定された第１のＩＰｖ６アドレスに対応する識別子がＥｎｄ．ＢＩＥＲである場合、第１のＩＰｖ６アドレスに設定されたエンド機能（end function）がＢＩＥＲパケット上でＢＩＥＲ転送を行っていることが理解され得る。第１のＩＰｖ６アドレスは、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスとも称され得る。
なお、第１のＩＰｖ６アドレスは、第１の転送装置に対して新たに設定されるアドレスであってもよいし、あるいは既に設定されたアドレスであってもよい。これは、この出願のこの実施形態において特に限定されることではない。
オプションで、一部の実施形態において、例えば第１の転送装置といった、ＢＩＥＲドメイン内のノードは、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをＢＩＥＲドメイン内の他のノードに対してフラッディングして、ＢＩＥＲパケットを転送するようにＢＩＥＲドメイン内の各ノードに指し示すために使用されるＢＩＦＴを形成し得る。換言すれば、ＢＩＥＲドメイン内の各ノードが、隣接ノードによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて、ＢＩＦＴ又はＢＩＥＲルーティングテーブルを構築し得る。
第１の転送装置がＢＩＥＲドメイン内の他のノードに対してＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをフラッディングし得る実装は複数存在する。これは、この出願のこの実施形態において特に限定されることではない。一例において、第１の転送装置は、第１のＩＰｖ６アドレスがＥｎｄ．ＢＩＥＲタイプのものであることを指し示す識別子を運ぶためにＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘフラッディングメッセージを使用する。他の一例では、第１の転送装置は、ＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘフラッディングメッセージとは異なるメッセージを使用し、すなわち、第１の転送装置はＳＲｖ６ ｌｏｃａｔｏｒメッセージを使用して、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスと、ＩＰｖ６アドレスに対応する識別子とを運ぶ。この識別子は、ＩＰｖ６アドレスのタイプがＥｎｄ．ＢＩＥＲであることを指し示す。以下にて、具体的な例を参照して詳細な説明を提供する。詳細をここで再び説明することはしない。
理解されるべきことには、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＢＩＥＲｖ６パケットがカプセル化されて転送されるときに運ばれるＩＰｖ６宛先アドレスを示すために使用される。
以下では、第１の転送装置が図２に示したノードＢである例を用いることによって、この実施形態で提供されるＢＩＥＲパケット送信プロセスを詳細に説明する。
ステップ１：ノードＢが、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスを設定する。
取り得る一実装において、設定されるＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＩＰｖ６－ｐｒｅｆｉｘとは異なるＩＰｖ６アドレスとし得る。例えば、ＳＩＤをＳＲｖ６ ｌｏｃａｔｏｒアドレス空間から選択することができる。以下は、ｌｏｃａｔｏｒにおいてＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスを設定するための特定の一実装である：
segment-routing ipv6
locator as1 ipv6-prefix 2002::
opcode ::AAAA End.BIER ##Ｅｎｄ．ＢＩＥＲタイプのＳＩＤとして2002::AAAAを設定する
opcode ::AAAB End.X ##Ｅｎｄ．ＸタイプのＳＩＤとして2002::AAABを設定する。
取り得る他の一実装において、設定されるＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、インタフェース（例えば、ループバックインタフェース）上に設定された１２８ビットマスクを持つＩＰｖ６アドレスとし得る。Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスの設定方法は、一般ＩＰｖ６アドレスの設定方法とは異なる。具体的な設定方法は次の通りであるとおりです：
interface loopback0
ipv6 address 2001::000A 128 ##これは一般ＩＰｖ６アドレスである
ipv6 address 2001::000B 128 End.BIER ##これはＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスである。
以下は、Ｅｎｄ．ＢＩＥＲがＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘとしても使用される設定である：
sub-domain 6 ipv6 ##ＩＰｖ６を用いるようにＢＩＥＲサブドメイン６を設定する
BFR-prefix 2001::000B ##Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘとして設定する。
以下は、Ｅｎｄ．ＢＩＥＲがＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘとしても使用される別の設定である：
Bier
sub-domain 6 ipv6 ##ＩＰｖ６を用いるようにＢＩＥＲサブドメイン６を設定する
BFR-prefix loopback0 ##ｌｏｏｐｂａｃｋ０上に設定されたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをＢＦＲ－ｐｒｅｆｉｘとして使用する。
ステップ２：ノードＢが、設定されたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをローカルに格納するとともにフラッディングする。
取り得る一実装において、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレス及びそのＥｎｄ．ＢＩＥＲインジケーション情報をＢＩＥＲドメイン内の他のノードに対してフラッディングするためにノードＢによって使用されるメッセージは、ＢＩＥＲ情報をフラッディングするのに使用されるメッセージとは異なる。例えば、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレス及びＥｎｄ．ＢＩＥＲインジケーション情報は、ＩＳ－ＩＳ ＳＲｖ６ ｌｏｃａｔｏｒメッセージ内で運ばれ、ＢＩＥＲ情報は、ＩＳ－ＩＳ ｐｒｅｆｉｘ－ｒｅａｃｈａｂｉｌｉｔｙメッセージ内で運ばれる。
具体的には、図５を参照するに、ＢＩＥＲ情報は、ＩＳ－ＩＳプレフィックスリーチャビリティ（prefix-reachability）ＴＬＶメッセージ内で運ばれる。該メッセージは、ＢＦＲ－ＰｒｅｆｉｘのＩＰｖ６アドレス（ＢＦＲ－ＩＰｖ６－Ｐｒｅｆｉｘと称する）を運び、さらに、ＢＩＥＲサブドメイン（sub-domain）情報を運び、例えば、ＢＩＥＲサブドメイン情報はＢＩＥＲ情報サブＴＬＶ（BIER InfosubTLV）とし得る。Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＩＳ－ＩＳ ＳＲｖ６ ｌｏｃａｔｏｒメッセージ内で運ばれる。例えば、Ｅｎｄ．ＢＩＥＲのＳＩＤ値（例えば、ＳＩＤは第１のＩＰｖ６アドレスを指し示す）及びＥｎｄ．ＢＩＥＲインジケーション（例えば、ＳＩＤタイプがＥｎｄ．ＢＩＥＲを指し示す）は、ＳＲｖ６ ｌｏｃａｔｏｒメッセージ内のＥｎｄ．ＢＩＥＲのＳＲｖ６ ＳＩＤ情報内で運ばれ得る。Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＢＦＲ－Ｐｒｅｆｉｘに対応するＩＰｖ６アドレスと異なってもよいし同じであってもよい。
取り得る他の一実装において、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレス及びＥｎｄ．ＢＩＥＲ識別子は、ＢＩＥＲ情報と同じメッセージ内で運ばれてもよい。例えば、ＩＳ－ＩＳ ｐｒｅｆｉｘ－ｒｅａｃｈａｂｉｌｉｔｙメッセージが、Ｅｎｄ．ＢＩＥＲインジケーション（例えば、ＳＩＤタイプ＝Ｅｎｄ．ＢＩＥＲ）を運び、さらに、例えばＢＩＥＲサブドメインＳＤなどのＢＩＥＲ情報を運ぶ。
具体的には、図６を参照するに、ＢＩＥＲサブドメイン（sub-domain）情報に加えて、例えばＳＩＤタイプ＝Ｅｎｄ．ＢＩＥＲといった、Ｅｎｄ．ＢＩＥＲインジケーション情報も、ＢＩＥＲ情報をフラッディングするのに使用されるメッセージ内で運ばれ得る。対応して、ＢＦＲ－Ｐｒｅｆｉｘに対応するＩＰｖ６アドレスも、Ｅｎｄ．ＢＩＥＲタイプＩＰｖ６アドレスとして使用され、Ｅｎｄ．ＢＩＥＲインジケーション情報を持つ。
ステップ３：ノードＡが、ノードＢによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて、ＩＰｖ６ヘッダをカプセル化する。
ノードＡは、ノードＢによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて転送エントリを構築し、該転送エントリに従って、ノードＢへの複製が必要であると決定する。ノードＡは、次いで、ノードＢによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスを、ＩＰｖ６基本ヘッダ内のＤＡフィールドに埋めて、ノードＢにＢＩＥＲパケットを送信する。
ステップ４：ノードＢが、受信したＢＩＥＲパケット内で運ばれたＤＡフィールド内のノードＢのＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行する。
ノードＡによって送信されたＢＩＥＲパケットを受信した後、ノードＢは、ＩＰｖ６基本ヘッダ内のＤＡフィールドに埋められたアドレスが、ノードＢに対して設定されたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスであることを決定する。具体的には、ノードＢは、ローカルに格納した転送テーブル内のＩＰｖ６アドレスがＩＰｖ６基本ヘッダ内のＤＡフィールドに埋められたアドレスと同じであることを決定し、そして、転送テーブル内のＩＰｖ６アドレスに対応する例えばＳＩＤタイプ＝Ｅｎｄ．ＢＩＥＲといった識別子に基づいて、受信したＢＩＥＲパケット上でＢＩＥＲ転送を実行する必要があることを決定し得る。
取り得る一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるとき、ＢＩＥＲパケットがＳＲＨヘッダを含む場合に、ノードＢは、ＳＲＨヘッダをポッピングし、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、インターネット制御メッセージプロトコル（internet control message protoco、ＩＣＭＰ）パラメータ問題メッセージを送信する。次の例では、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF NH=60 ##ＩＰｖ６基本ヘッダ内の次ヘッダＮＨが宛先オプションヘッダ（６０によって識別される）である
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE
9. drop the packet; possibly send an ICMP parameter problem message;
“NH=60”は、ＩＰｖ６基本ヘッダ内の次ヘッダが宛先オプションヘッダであることを指し示し、“DestOptHdr OptType=BIER”は、宛先オプションヘッダ内の第１オプションＴＬＶのタイプがＢＩＥＲであることを指し示し、“HdrExtLen*8+8=4+OptLength”は、宛先オプションヘッダが１つのＴＬＶのみを含むことを指し示す。ＴＬＶの長さ＋４が、宛先拡張ヘッダの全長と同じである（すなわち、宛先拡張ヘッダは１つのＢＩＥＲ ＴＬＶのみを含む）。
取り得る他の一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨが、セグメントルーティングヘッダＳＲＨであり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬが０であり、且つルーティングヘッダＳＲＨの次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるとき、ノードＢは、ＳＲＨヘッダをポッピングし、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、ＩＣＭＰパラメータ問題メッセージを送信する。次の例では、ルーティングヘッダＳＲＨ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF (NH=SRH and SL=0 and SRH_NH=DestOptHdr) ##拡張ヘッダがＳＲＨ及びＤｅｓｔＯｐｔＨｄｒである
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
ステップ８において、次ヘッダがＮＨチェーンの最後のＮＨである場合、すなわち、次ヘッダが上位層ヘッダ（upper-layer heade）で埋められたＮＨフィールドである場合、該上位層ヘッダは内部層パケットのタイプを指し示すことができ、ノードは、内部層ユーザデータパケットを転送することができる。例えば、IPv6_NH=4は、次ヘッダによって指し示される内部層パケットのタイプがＩＰｖ４であることを指し示し、IPv6_NH=41は、次ヘッダによって指し示される内部層パケットのタイプがＩＰｖ６であることを指し示し、IPv6_NH=6は、次ヘッダによって指し示される内部層パケットのタイプが伝送制御プロトコル（transmission control protoco、ＴＣＰ）であることを指し示し、IPv6_NH=17は、次ヘッダによって指し示される内部層パケットのタイプがユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）であることを指し示し、IPv6_NH=58は、次ヘッダによって指し示される内部層パケットのタイプがＩＣＭＰであることを指し示し、そして、IPv6_NH=137は次ヘッダによって指し示される内部層パケットのタイプがマルチプロトコルラベルスイッチング（multi-protocol label switching、ＭＰＬＳ）であることを指す示す。
取り得る他の一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨがフラグメントヘッダ（fragment header）であり、且つフラグメントヘッダの次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるとき、あるいは、ＩＰｖ６基本ヘッダが、ＢＩＥＲを運ぶ拡張ヘッダに続かれ、次いでフラグメントヘッダに続かれるとき、ノードＢは、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、ＩＣＭＰパラメータ問題メッセージを送信する。処理手順は以下の通りである：
1. IF (NH=Frag and Frag_NH=DestOptHdr) or (NH=DestOptHdr and Dest_NH=Frag)
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
取り得る他の一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、拡張ヘッダの次ヘッダＮＨが認証ヘッダ（authentication header、ＡＨ）であるとき、ＢＩＥＲパケットがＳＲＨヘッダを含む場合に、ノードＢは、ＳＲＨヘッダをポッピングし、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、インターネット制御メッセージプロトコル（internet control message protoco、ＩＣＭＰ）パラメータ問題メッセージを送信する。次の例では、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF (IPv6_NH=DestOptHdr and Dest_NH=AH)
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
取り得る他の一実装において、ＩＰｖ６ ＮＨチェーンの最後のＮＨがＩＣＭＰｖ６である（すなわちlast_NH=ICMPv6）場合、ＢＩＥＲパケットは、例えばＩＣＭＰｖ６パケットカウントを追加したりＩＣＭＰｖ６応答パケットを送信したりするといった処理のために中央演算処理ユニット（central processing unit、ＣＰＵ）に送り込まれ得る。具体的な設定は以下の通りである：
1. IF Last_NH=ICMPv6 ##ＩＰｖ６ ＮＨチェーンの最後のＮＨがＩＣＭＰｖ６パケットを指し示す場合
2. Pump to CPU, add packet counter, possibly send an ICMP response message.
ステップ５：ノードＢが、ＢＩＥＲパケットを隣接ノードＥに転送する。
ノードＢは、転送エントリ及びビット列０１１１に基づいて、ＢＩＥＲパケットがノードＣ及びノードＥに別々に送信される必要があることを決定し得る。ＢＩＥＲパケットをノードＣに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列を００１１に変更し、ＩＰｖ６基本ヘッダ内のＤＡフィールドに、ノードＣによってフラッディングされたＥＮＤ．ＢＩＥＲタイプのＩＰｖ６アドレスを埋め、そして、ＢＩＥＲパケットをノードＣに送信し得る。同様に、ＢＩＥＲパケットをノードＥに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列を０１００に変更し、ＩＰｖ６基本ヘッダ内のＤＡフィールドに、ノードＥによってフラッディングされたＥＮＤ．ＢＩＥＲタイプのＩＰｖ６アドレスを埋め、そして、ＢＩＥＲパケットをノードＥに送信し得る。
取り得る一実装において、この出願のこの実施形態で、ノードＢがノードＥにＢＩＥＲパケットを送信するとき、ノードＢの隣接ノードＥがリーフノードとして決定される場合に、ノードＢは、ＢＩＥＲパケット内のＢＩＥＲヘッダを運ぶ拡張ヘッダをポッピングし得る。例えば、ノードＢは、ＢＩＥＲヘッダを運ぶ宛先オプションヘッダをポッピングし、ＢＩＥＲヘッダを運ぶ宛先オプションヘッダを含まないＢＩＥＲパケットをノードＥに送信する。ノードＢによって送信されたＢＩＥＲパケットをノードＥが受信した後、ノードＥはリーフノードであるので、ノードＥは、ＢＩＥＲヘッダを運ぶ拡張ヘッダをカプセル解除し、内部層ユーザデータパケットを転送する必要がある。ノードＢによって送信されたＢＩＥＲパケットが、ＢＩＥＲヘッダを運ぶ拡張ヘッダを含まない場合、ノードＥは、ＢＩＥＲヘッダを運ぶ拡張ヘッダをカプセル解除することなく、内部層ユーザデータパケットを直接転送することができる。具体的な設定は以下の通りである：
1. IF NH=60 ##ＩＰｖ６基本ヘッダ内の次ヘッダＮＨが宛先オプションヘッダ（６０によって識別される）である
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
ノードＥによって受信されたＢＩＥＲパケットがＢＩＥＲヘッダを含んでいないとき、ステップ１から７はスキップされることができ、ステップ８及び９を直接実行し、それによりリーフノードＥの処理オーバーヘッドを削減することができる。
前述の技術的ソリューションでは、より柔軟なＢＩＥＲ展開を更にサポートすることができる。例えば、リーフノードＥはＢＩＥＲヘッダの読み取り又は処理をサポートしなくてもよいが、リーフノードＥが外部ＩＰｖ６ヘッダのポッピングをサポートする場合には、リーフノードＥはこの方法に従ってネットワーク内に展開されてもよい。
取り得る他の一実装において、ノードＢによって受信された宛先アドレスがＢのＥＮＤ．ＢＩＥＲである場合、ノードＢは以下のＥＮＤ．ＢＩＥＲ処理手順を実行する：ノードＢは、ＩＰｖ６拡張ヘッダ内にＮ個のＢＩＥＲヘッダがあることを決定し、Ｍ番目のＢＩＥＲヘッダを読み取って複製し（例えば、Ｍ番目のＢＩＥＲヘッダをノードＥに対して複製し）、ノードＥのＥＮＤ．ＢＩＥＲをＩＰｖ６ ＤＡフィールドに埋め、Ｍ番目のＢＩＥＲヘッダ以外のＢＩＥＲヘッダをポッピングし、そして、Ｍ番目のＢＩＥＲヘッダのみを保持する。ＩＰｖ６拡張ヘッダの長さフィールドはそれに従って変化される。次の例では、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF NH=60 //con2
2. IF (DestOptHdr OptType=BIER) and ((HdrExtLen*8+8)%(4+OptLength1)=0) //con1
3. Walk each TLV in DestOptHdr
4. If (OptType=BIER and OptLen=OptLength1) or(OptType=PadN and OptLen=0)
5. Continue
6. ELSE
7. Drop the packet; possibly send an ICMP parameter problem message;
8. End Walk of each TLV
9. For (N=0; N<(HdrExtLen*8+8)/(4+OptLength1); N++)
10. lookup the BIER Header begin from (N*OptLength1+4)bytes
11. copy packet if this packet need to forward to according to this lookup.
12. pop the TLV(s) except for this one, Set HdrExtLen=(4+OptLength1)/8.
13. forward via the matched entry,
14. END-FOR
15 ELSE //end of con1
16. drop the packet; possibly send an ICMP parameter problem message;
17. ELSE //end of con2
18. drop the packet; possibly send an ICMP parameter problem message;
ステップ２で、“HdrExtLen*8+8”は宛先オプションヘッダ（DestOptHdr）の全長を表し、“OptLength1”は第１のＢＩＥＲ ＴＬＶにおける長さ（Length、すなわち、ＢＩＥＲヘッダの長さ）を表す。宛先オプションヘッダ（DestOptHdr）がヘッダ全体の長さが８の整数倍であることを要求するので、ＢＩＥＲヘッダの長さ＋４は８の整数倍である。宛先オプションヘッダの長さは８バイトの単位であり、最初の８バイトは含まない。例えば：
（ＮｅｘｔＨｅａｄｅｒ＝ｘ，Ｌｅｎｇｔｈ＝１７，Ｔｙｐｅ＝ＢＩＥＲ，Ｌｅｎｇｔｈ＝４４） ／／注１；
（ＢＩＥＲヘッダ＜１２バイト（固定長）＋２５６ビットを表す３２バイト＞）／／最初のＢＩＥＲヘッダ；
（Ｔｙｐｅ＝ＰａｄＮ，Ｌｅｎｇｔｈ＝０，Ｔｙｐｅ＝ＢＩＥＲ，Ｌｅｎｇｔｈ＝４４）／／注２；
（ＢＩＥＲヘッダ＜１２バイト（固定長）＋２５６ビットを表す３２バイト＞））／／２番目のＢＩＥＲヘッダ；
（Ｔｙｐｅ＝ＰａｄＮ，Ｌｅｎｇｔｈ＝０，Ｔｙｐｅ＝ＢＩＥＲ，Ｌｅｎｇｔｈ＝４４）／／注３；
（ＢＩＥＲヘッダ＜１２バイト（固定長）＋２５６ビットを表す３２バイト＞））／／３番目のＢＩＥＲヘッダ；
注１：ＤｅｓｔＯｐｔＨｄｒは、ＮＨフィールド及び長さフィールドから始まる；
注２：ＰａｄＮ ＴＬＶは、２番目のＢＩＥＲ ＴＬＶの前にパディングされる；
注３：ＰａｄＮ ＴＬＶは、３番目のＢＩＥＲ ＴＬＶの前にパディングされる。
前述の構成において、ステップ３から８は、パケットフォーマットが要求を満たすかが決定されるループである。この出願のこの実施形態では、複数のＢＩＥＲヘッダは同じ長さ（すなわち、最初のＢＩＥＲヘッダのＯｐｔＬｅｎｇｔｈ１と同じ長さ）を持つことが要求され、２番目以降のＢＩＥＲヘッダはＰａｄＮでパディングされる（ＲＦＣ ８２００におけるパディング要求を参照）。
前述の設定において、ステップ９から１４は、各ＢＩＥＲヘッダが検討されるがＰａｄＮヘッダは処理されない別のループである。最初のＢＩＥＲヘッダが処理されるとき、最初のＢＩＥＲヘッダに続く２つのＢＩＥＲヘッダをポッピングするのは比較的容易であり、すなわち、（１＊（ＯｐｔＬｅｎｇｔｈ１＋４））番目のバイトから始まる９６バイトのみが破棄される必要があり、ＩＰｖ６拡張ヘッダの長さフィールド（ＤｅｓｔＯｐｔＨｄｒ Ｌｅｎｇｔｈ）が５に設定される。２番目のＢＩＥＲヘッダが処理されるとき、最初の及び３番目のＢＩＥＲヘッダがポッピングされる必要があり、すなわち、２番目のＢＩＥＲヘッダ（１＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトから始まるＯｐｔＬｅｎｇｔｈバイト）が、（０＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトがある位置にコピーされる必要があり、（１＊（ＯｐｔＬｅｎｇｔｈ１＋４））番目のバイトから始まる９６バイトが破棄され、ＤｅｓｔＯｐｔＨｄｒ Ｌｅｎｇｔｈが５に設定される。
３番目のＢＩＥＲヘッダが処理されるとき、最初の及び２番目のＢＩＥＲヘッダがポッピングされる必要があり、すなわち、３番目のＢＩＥＲヘッダ（２＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトから始まるＯｐｔＬｅｎｇｔｈバイト）が、（０＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトがある位置にコピーされる必要があり、（１＊（ＯｐｔＬｅｎｇｔｈ１＋４））番目のバイトから始まる９６バイトが破棄され、ＤｅｓｔＯｐｔＨｄｒ Ｌｅｎｇｔｈが５に設定される。
以上では、図１から図６を参照して、この出願の実施形態で提供されるＢＩＥＲパケット送信方法を詳細に説明している。以下では、図７及び図８を参照して、この出願の実施形態におけるＢＩＥＲパケット送信装置を詳細に説明する。理解されるべきことには、方法実施形態の説明は装置実施形態の説明に対応する。従って、詳細に説明されない部分については、前述の方法実施形態における説明を参照されたい。
図７は、この出願の一実施形態に従ったＢＩＥＲパケット送信装置７００の概略構成図である。ＢＩＥＲパケット送信装置７００は、
インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信するように構成された受信モジュール７１０であり、ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、第１の転送装置の第１のＩＰｖ６アドレスである、受信モジュール７１０と、
転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定するように構成された処理モジュール７２０であり、識別子は、第１のＩＰｖ６アドレスがＢＩＥＲ転送の宛先アドレスであることを指し示すために使用される、処理モジュール７２０と、
を含み得る。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが転送テーブル内の第１のＩＰｖ６アドレスと同じであることを決定するように構成される。第１の転送装置は、第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。
オプションで、ＢＩＥＲパケット送信装置７００は更に、第１のＩＰｖ６アドレス及び識別子を設定するように構成された設定モジュール７４０を含む。
オプションで、装置７００は更に、ルーティングプロトコルを用いて、第１の転送装置の第１のＩＰｖ６アドレス及び識別子をネットワークにフラッディングするように構成された送信モジュール７３０を含む。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成される。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダＲＨであり、且つルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ルーティングヘッダＲＨをポッピングし、且つＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成される。
オプションで、ルーティングヘッダＲＨはセグメントルーティングヘッダＳＲＨであり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成される。
オプションで、処理モジュール７２０は具体的に、ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、ＢＩＥＲ転送テーブルは、第３の転送装置によってフラッディングされたＢＩＥＲメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築される、ように構成され、第１の転送装置は、ＢＩＥＲ転送テーブルに基づいてＢＩＥＲパケットを第３の転送装置に対して複製する。
オプションで、処理モジュール７２０は具体的に、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングし、拡張ヘッダを含まないＢＩＥＲパケットを第３の転送装置に対して複製する、ように構成される。
オプションで、処理モジュール７２０は具体的に、第３の転送装置がリーフノードであると決定したときに、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングする、ように構成される。
オプションで、拡張ヘッダは宛先オプションヘッダである。
オプションで、ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを含む。
図８は、この出願の一実施形態に従った第１転送装置８００の概略構成図である。第１転送装置６００は、メモリ８１０と、プロセッサ８２０と、入力／出力インタフェース８３０とを含み得る。
メモリ８１０、プロセッサ８２０、及び入力／出力インタフェース８３０は、内部接続パスを用いて接続される。メモリ８１０は、プログラム命令を格納するように構成される。プロセッサ８２０は、メモリ８１０に格納されたプログラム命令を実行して、入力データ及び情報を受信し、例えば演算結果などのデータを出力するように、入力／出力インタフェース８３０を制御するように構成される。
理解されるべきことには、この出願の実施形態におけるプロセッサ８２０は、中央演算処理ユニット（central processing unit、ＣＰＵ）であってもよいし、あるいは更には、別の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、又は別のプログラマブル論理デバイス、ディスクリートのゲート若しくはトランジスタ論理デバイス、ディスクリートのハードウェアコンポーネント、又はこれらに類するものであってもよい。汎用プロセッサはマイクロプロセッサであってもよく、あるいはプロセッサは、任意の従来からのプロセッサ又はそれに類するものであってもよい。代わりに、プロセッサ８２０は、１つ以上の集積回路であってもよく、関連プログラムを実行して、この出願の実施形態で提供される技術的ソリューションを実装するように構成される。
メモリ８１０は、読み出し専用メモリ及びランダムアクセスメモリを含み得るとともに、命令及びデータをプロセッサ８２０に提供し得る。プロセッサ８２０の一部が更に、不揮発性ランダムアクセスメモリを含んでもよい。例えば、プロセッサ８２０は更に、デバイスタイプの情報を格納してもよい。
一実装プロセスにおいて、前述の方法におけるステップは、プロセッサ８２０内のハードウェア集積論理回路を使用することによって、又はソフトウェアの形態の命令を使用することによって実装されることができる。この出願の実施形態を参照して開示された方法は、ハードウェアプロセッサによって直接実行されてもよいし、あるいはプロセッサ内のハードウェアとソフトウェアモジュールとの組み合わせを用いることによって実行されてもよい。ソフトウェアモジュールは、例えばランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的消去プログラム可能メモリ、又はレジスタなどの、当該技術分野における成熟した記憶媒体内に置かれ得る。記憶媒体がメモリ８１０内に配置され、そして、プロセッサ８２０が、メモリ８１０内の情報を読み出し、プロセッサのハードウェアと組み合わさって、上述の方法におけるステップを実行する。繰り返しを避けるために、詳細をここで再び説明することはしない。
理解されるべきことには、この出願の実施形態に従った第１転送装置８００は、この出願の実施形態における図２から図４に示した方法の対応する手順を実行するように構成される。加えて、第１転送装置８００内のモジュールの前述の及びその他の動作及び／又は機能は、この出願の実施形態における図２から図４に示した方法の対応する手順を実装するように別々に使用される。簡潔さのため、詳細をここで再び説明することはしない。
なお、図８に示す第１転送装置８００において、プロセッサは、メモリ内のコンピュータプログラムを呼び出して、モジュールによって実行されるステップを実装し得る。例えば、プロセッサは、キャッシュに格納されたコンピュータ命令を呼び出して、モジュール（例えば、図７に示した受信モジュール７１０及び処理モジュール７２０）によって実行されるステップを実行し得る。
理解されるべきことには、上述のプロセスのシーケンス番号は、この出願の様々な実施態様における実行順序を意味するものではない。プロセスの実行順序は、プロセスの機能及び内部ロジックに従って決定されるべきであり、この出願の実施態様の実装プロセスに対する何らかの限定として解釈されるべきでない。
当業者が認識し得ることには、この明細書に開示された実施形態にて記述された例と組み合わせて、ユニット及びアルゴリズムステップは、電子ハードウェアによって、又はコンピュータソフトウェアと電子ハードウェアとの組み合わせによって実装され得る。機能がハードウェアによって実行されるのか、それともソフトウェアによって実行されるのかは、技術的ソリューションの特定の用途及び設計制約に依存する。当業者は、特定の用途ごとに、記載された機能を実装するために異なる方法を用いることができるのであり、その実装がこの出願の範囲を超えるものであると考えるべきではない。
当業者によって明確に理解され得ることには、簡便且つ簡潔な説明の目的のため、上述のシステム、装置、及びユニットの詳細な動作プロセスについては、上述の方法の実施形態における対応するプロセスを参照されたく、ここで再び詳細を説明することはしない。
この出願にて提供された一部の実施形態において、理解されるべきことには、開示されたシステム、装置、及び方法は、その他のようにして実施されてもよい。例えば、記載された装置の実施形態は単なる例である。例えば、ユニット分割は、単なる論理機能分割であり、実際の実装においてはその他の分割とし得る。例えば、複数のユニット又はコンポーネントが別のシステムへと組み合わされたり統合されたりしてもよく、あるいは、一部の機構が無視されたり実行されなかったりしてもよい。また、図示又は説明された相互結合又は直接結合又は通信接続は、何らかのインタフェースを用いることによって実装され得る。装置又はユニットの間の間接結合又は通信接続は、電子的な形態、機械的な形態、又はその他の形態にて実装され得る。
別々の部分として記載されたユニットは、物理的に別々であってもなくてもよく、また、ユニットとして示された部分は、物理的なユニットであってもなくてもよく、一箇所にあってもよいし複数のネットワークユニットに分散されてもよい。それらユニットの一部又は全てが、実施形態のソリューションの目的を達成するように、実際の要求に基づいて選択され得る。
また、この出願の実施形態における複数の機能ユニットが１つの処理ユニットへと統合されてもよく、あるいは、それらユニットの各々が物理的に単独で存在してもよく、あるいは、２つ以上のユニットが１つのユニットへと統合される。
機能がソフトウェア機能ユニットの形態で実装されて、独立したプロダクトとして販売又は使用されるとき、その機能はコンピュータ読み取り可能記憶媒体に格納されてもよい。このような理解に基づき、この出願の技術的ソリューションは本質的に、又は先行技術に対して寄与する部分は、又は技術的ソリューションの一部は、ソフトウェアプロダクトの形態で実装され得る。コンピュータソフトウェアプロダクトは、記憶媒体に格納されるとともに、この出願の実施形態にて記載された方法のステップの全て又は一部を実行するようにコンピュータ装置（これは、パーソナルコンピュータ、サーバ、又はネットワーク装置）に命令する幾つかの命令を含む。上述の記憶媒体は、例えばＵＳＢフラッシュドライブ、リムーバブルハードディスク、読み出し専用メモリ（read-only memory，ＲＯＭ）、ランダムアクセスメモリ（random access memory，ＲＡＭ）、磁気ディスク、又は光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。
以上の説明は、単にこの出願の特定の実装であり、この出願の保護範囲を限定することを意図するものではない。この出願にて開示された技術的範囲内で当業者が容易に考え付く如何なる変形又は置換も、この出願の保護範囲に入るものである。従って、この出願の保護範囲は、請求項の保護範囲に従うものである。
以上の説明は、単に本発明の特定の実装であり、本発明の保護範囲を限定することを意図するものではない。本発明にて開示された技術的範囲内で当業者が容易に考え付く如何なる変形又は置換も、本発明の保護範囲に入るものである。従って、本発明の保護範囲は、請求項の保護範囲に従うものである。
この出願は、“ＢＩＥＲパケット送信方法及び装置”と題して２０１９年６月６日に中国特許庁に出願された中国特許出願第２０１９１０４９３１１４．７号に対する優先権を主張するものであり、それをその全体にてここに援用する。
この出願は、ネットワーク通信分野に関し、より具体的には、ビットインデックス明示的複製ＢＩＥＲパケット送信方法及び装置に関する。
インターネットプロトコル（internet protocol、ＩＰ）マルチキャスト技術は、ＩＰネットワーク上での効率的なポイント・ツー・マルチポイントデータ伝送を実現し、それにより、ネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減させる。従って、インターネットプロトコルマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビジョン（internet protocol television、ＩＰＴＶ）、ゲーム、シミュレーション、及びこれらに類するものにおいて広く使用されている。マルチキャスト技術を用いたマルチキャストプロトコルによれば、ポイント・ツー・マルチポイントデータ転送を実現するために、ネットワークプレーンを論理ツリー状の構造にするように制御プレーンマルチキャストツリーを構築する必要がある。配信ツリー構築を中核とするこのようなマルチキャストルーティングプロトコルにおけるトランジットノードは、マルチキャスト転送情報の複雑なステータスを維持管理する必要がある。ネットワーク規模が大きくなり、マルチキャストデータトラフィックがますます増えるにつれて、マルチキャスト技術は、ますます高まるコスト、並びに大きな運用及び保守上の難題に直面する。
これに対処するために、マルチキャストデータ転送パスを構築するための新しい技術が業界で提唱され、ビットインデックス明示的複製（bit index explicit replication、ＢＩＥＲ）技術と呼ばれている。この技術は、マルチキャスト配信ツリーを構築する必要のない新しいマルチキャスト技術アーキテクチャを提案するものである。ＢＩＥＲ技術をサポートする転送ノードは、カプセル化されたＢＩＥＲヘッダ情報に基づいてＢＩＥＲドメインでＢＩＥＲパケットを転送することができる。
ＢＩＥＲパケットは、インターネットプロトコルバージョン６（internet protocol version 6、ＩＰｖ６）を用いた伝送のためにカプセル化される必要がある。従来の技術的ソリューションでは、ＢＩＥＲ技術をサポートする転送ノードが、各ノードによってフラッディングされる一般ＩＰアドレスを、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドにカプセル化する。しかしながら、一般ＩＰアドレスが宛先アドレスフィールド内に埋められるので、ＢＩＥＲパケットを受信するノードが、宛先アドレスフィールド内のＩＰｖ６アドレスに基づいてパケットフォーマットのタイプを決定する必要があり、それにより比較的低い転送効率をもたらす。
故に、転送効率をどのように改善するかが、現在喫緊に解決される必要がある問題となっている。
この出願は、ＢＩＥＲパケット送信方法及び装置を提供する。隣接ノードの第１のＩＰｖ６アドレスが、ＩＰｖ６拡張ヘッダ内の宛先アドレスフィールドに埋められ得る。斯くして、隣接ノードは、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスと他のフィールドとに基づいてパケットタイプを一つ一つ決定することを防止する。従って、転送効率が改善される。
第１の態様によれば、ＢＩＥＲパケット送信方法が提供される。当該方法は、第１の転送装置が、インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信することを含み、ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、第１の転送装置の第１のＩＰｖ６アドレスである。第１の転送装置は、転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定し、該識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される。
前述の技術的ソリューションでは、隣接ノードの第１のＩＰｖ６アドレスをＩＰｖ６拡張ヘッダ内の宛先アドレスフィールドに埋めることで、隣接ノードが、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定するようにし得る。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスと他のフィールドとに基づいてパケットタイプを一つ一つ決定することを防止する。従って、転送効率が改善される。
取り得る一実装において、第１の転送装置は、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが転送テーブル内の第１のＩＰｖ６アドレスと同じであることを決定し、そして、第１の転送装置は、第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。
取り得る他の一実装において、第１の転送装置は、第１のＩＰｖ６アドレス及び識別子を設定する。
取り得る他の一実装において、第１の転送装置が、インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信する前に、当該方法は更に、第１の転送装置が、ルーティングプロトコルを用いて、第１の転送装置の第１のＩＰｖ６アドレス及び識別子をネットワークにフラッディングすること、を含む。
前述の技術的ソリューションでは、第１の転送装置が第１のＩＰｖ６アドレス及び識別子をネットワーク内の他のノードにフラッディングすることで、ネットワーク内の他のノードが、転送テーブルを構築し、第１の転送装置によってフラッディングされた第１のＩＰｖ６アドレスに基づいてパケットをカプセル化するようにし得る。
理解されるべきことには、ルーティングプロトコルを用いることによって第１の転送装置によってネットワークにフラッディングされる第１のＩＰｖ６アドレス及び識別子は、ＢＩＥＲメッセージと同じメッセージ内で運ばれてもよいし、あるいは、ＢＩＥＲメッセージとは異なるメッセージ内であってもよい。これは、この出願において特に限定されることではない。
取り得る他の一実装において、第１のＩＰｖ６アドレスは、セグメントルーティング・オーバ・ＩＰｖ６（ＳＲｖ６）のセグメント識別子（segment identifier、ＳＩＤ）である。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダ（next header、ＮＨ）フィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、第１の転送装置は、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダ（routing header、）ＲＨ）であり、且つルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、第１の転送装置は、ルーティングヘッダＲＨをポッピングし、且つＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。
取り得る他の一実装において、ルーティングヘッダＲＨはセグメントルーティングヘッダ（segment routing header、ＳＲＨ）であり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、第１の転送装置は、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。
取り得る他の一実装において、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、４、４１、９７、又は１３７であるときに、第１の転送装置は、ＩＰｖ６基本ヘッダをポッピングし、ユーザデータパケットを転送する。
取り得る他の一実装において、第１の転送装置は、ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、ＢＩＥＲ転送テーブルは、第３の転送装置によってフラッディングされたメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築され、そして、第１の転送装置は、ＢＩＥＲ転送テーブルに基づいてＢＩＥＲパケットを第３の転送装置に対して複製する。
取り得る他の一実装において、第１の転送装置は、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、第１の転送装置は、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングし、そして、第１の転送装置は、拡張ヘッダを含まないＢＩＥＲパケットを第３の転送装置に対して複製する。
取り得る他の一実装において、第３の転送装置がリーフノードであると決定したときに、第１の転送装置は、１つ以上のＢＩＥＲヘッダを運ぶ拡張ヘッダをポッピングする。
取り得る他の一実装において、拡張ヘッダは宛先オプションヘッダである。
取り得る他の一実装において、ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを含む。
第２の態様によれば、ＢＩＥＲパケット送信装置が提供され、当該装置は、
インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信するように構成された受信モジュールであり、ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、第１の転送装置の第１のＩＰｖ６アドレスである、受信モジュールと、
転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定するように構成された処理モジュールであり、識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される、処理モジュールと、
を含む。
取り得る一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが転送テーブル内の第１のＩＰｖ６アドレスと同じであることを決定するように構成される。第１の転送装置は、第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。
取り得る他の一実装において、当該装置は更に、第１のＩＰｖ６アドレス及び識別子を設定するように構成された設定モジュール、を含む。
取り得る他の一実装において、当該装置は更に、ルーティングプロトコルを用いて、第１の転送装置の第１のＩＰｖ６アドレス及び識別子をネットワークにフラッディングするように構成された送信モジュール、を含む。
取り得る他の一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成されている。
取り得る他の一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダＲＨであり、且つルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ルーティングヘッダＲＨをポッピングし、且つＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成されている。
取り得る他の一実装において、ルーティングヘッダＲＨはセグメントルーティングヘッダＳＲＨであり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である。
取り得る他の一実装において、処理モジュールは具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成されている。
取り得る他の一実装において、処理モジュールは具体的に、ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、ＢＩＥＲ転送テーブルは、第３の転送装置によってフラッディングされたＢＩＥＲメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築される、ように構成されており、第１の転送装置は、ＢＩＥＲ転送テーブルに基づいてＢＩＥＲパケットを第３の転送装置に対して複製する。
取り得る他の一実装において、処理モジュールは具体的に、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングし、拡張ヘッダを含まないＢＩＥＲパケットを第３の転送装置に対して複製する、ように構成されている。
取り得る他の一実装において、処理モジュールは具体的に、第３の転送装置がリーフノードであると決定したときに、１つ以上のＢＩＥＲヘッダを運ぶ拡張ヘッダをポッピングする、ように構成されている。
取り得る他の一実装において、拡張ヘッダは宛先オプションヘッダである。
取り得る他の一実装において、ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを含む。
第３の態様によれば、入力／出力インタフェースと、プロセッサと、メモリとを含む第１転送装置が提供され、プロセッサは、入力／出力インタフェースを制御して情報を送信及び受信するように構成され、メモリは、コンピュータプログラムを格納するように構成され、プロセッサが、メモリからコンピュータプログラムを呼び出してコンピュータプログラムを実行することで、第１の態様又は第１の態様の取り得る実装のうちのいずれか１つに従った方法を当該第１転送装置が実行する。
オプションで、プロセッサは、汎用プロセッサであってもよく、ハードウェア又はソフトウェアを用いて実装され得る。ハードウェアを用いてプロセッサが実装されるとき、プロセッサは、論理回路、集積回路、又はこれらに類するものとし得る。ソフトウェアを用いてプロセッサが実装されるとき、プロセッサは、汎用プロセッサとすることができ、メモリに格納されたソフトウェアコードを読み出すことによって実装される。メモリは、プロセッサ内に集積されてもよいし、あるいは、プロセッサの外部に置かれて独立に存在してもよい。
第４の態様によれば、コンピュータプログラムプロダクトが提供される。当該コンピュータプログラムプロダクトは、コンピュータプログラムコードを含む。該コンピュータプログラムコードがコンピュータ上で実行されるとき、該コンピュータは、前述の態様における方法を実行することを可能にされる。
第５の態様によれば、コンピュータ読み取り可能媒体が提供される。当該コンピュータ読み取り可能媒体はプログラムコードを格納しており、該コンピュータプログラムコードがコンピュータ上で実行されるとき、該コンピュータは、前述の態様における方法を実行することを可能にされる。
第６の態様によれば、システムが提供される。当該システムは、第１の転送ノード、第２の転送ノード、及び第３の転送ノードを含み、第１の転送ノードは、第１の態様又は第１の態様の取り得る実装のうちのいずれか１つに従った方法を実行するように構成される。第２の転送ノードは、第１の転送ノードによってフラッディングされた第１のＩＰｖ６アドレスに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールドを埋め、そして、ＢＩＥＲパケットを第１の転送ノードに送信するように構成される。第３の転送ノードは、第１の転送ノードによって送信されたＢＩＥＲパケットを受信し、そして、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが、当該第３の転送ノードに対して設定された第１のＩＰｖ６アドレスであることに基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行するように構成される。
この出願の一実施形態に従ったＢＩＥＲ技術の概略ネットワーキング図である。 この出願の一実施形態に従った、ＢＩＥＲドメインでＢＩＥＲヘッダに基づいてＢＩＥＲパケットを送信することの概略ブロック図である。 この出願の一実施形態に従ったＢＩＥＲｖ６パケットフォーマットの概略図であ。 この出願の一実施形態に従ったＢＩＥＲパケット送信方法の概略フローチャートである。 この出願の一実施形態に従ったＳＲｖ６ ｌｏｃａｔｏｒメッセージフォーマットの概略図である。 この出願の一実施形態に従ったＩＰｖ６－ｐｒｅｆｉｘメッセージフォーマットの概略図である。 この出願の一実施形態に従ったＢＩＥＲパケット送信装置７００の概略構成図である。 この出願の一実施形態に従った第１転送装置８００の概略構成図である。
以下、添付の図面を参照して、この出願の技術的ソリューションを説明する。
インターネットプロトコル（internet protocol、ＩＰ）マルチキャスト技術は、ＩＰネットワーク上での効率的なポイント・ツー・マルチポイントデータ伝送を実現し、それにより、ネットワーク帯域幅を効果的に節約し、ネットワーク負荷を低減させる。従って、インターネットプロトコルマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビジョン（internet protocol television、ＩＰＴＶ）、ゲーム、シミュレーション、及びこれらに類するものにおいて広く使用されている。マルチキャスト技術を用いたマルチキャストプロトコルによれば、ポイント・ツー・マルチポイントデータ転送を実現するために、ネットワークプレーンを論理ツリー状の構造にするように制御プレーンマルチキャストツリーを構築する必要がある。配信ツリー構築を中核とするこのようなマルチキャストルーティングプロトコルにおけるトランジットノードは、マルチキャスト転送情報の複雑なステータスを維持管理する必要がある。ネットワーク規模が大きくなり、マルチキャストデータトラフィックがますます増えるにつれて、マルチキャスト技術は、ますます高まるコスト、並びに大きな運用及び保守上の難題に直面する。
これに対処するために、マルチキャストデータ転送パスを構築するための新しい技術が業界で提唱され、ビットインデックス明示的複製（bitindexed explicit replication、ＢＩＥＲ）技術と呼ばれている。当該技術は、マルチキャスト配信ツリーを構築する必要のない新しいマルチキャスト技術アーキテクチャを提案するものである。図１に示すように、ＢＩＥＲ技術をサポートするルータは、ビット転送ルータ（BIER forwarding router、ＢＦＲ）と称されることがあり、ＢＦＲ装置は、ＢＩＥＲパケットを受信して転送し得る。１つ以上のＢＦＲを含むマルチキャスト転送ドメインは、ＢＩＥＲドメイン（BIER domain）と称される。ＢＩＥＲドメインのエッジにおいて、ユーザのマルチキャストデータに対してＢＩＥＲデータパケットカプセル化を実行する装置は、ビット転送イングレスルータ（BIER forwarding ingress router、ＢＦＩＲ）と称され、ＢＩＥＲデータパケットをカプセル解除する装置は、ビット転送エグレスルータ（BIER forwarding egress router、ＢＦＥＲ）と称される。
ＢＩＥＲドメインにおいて、各エッジノード（例えば、ＢＦＥＲ）は、ＢＩＥＲサブドメイン（sub domain、ＳＤ）全体内でグローバルに一意であるビット位置（bit position）を有して設定される。例えば、値は、例えば１から２５６の範囲の値といった各エッジノードに対するＢＦＲ識別子（identification、ＩＤ）として設定され得る。ＢＩＥＲドメイン内の全てのＢＦＲ ＩＤがビット列（bit string）を形成する。ＢＩＥＲドメイン内でユーザデータトラフィック（ＢＩＥＲパケットとも称される）の伝送のために、特定のＢＩＥＲヘッダをカプセル化する必要がある。ＢＩＥＲヘッダは、ユーザデータトラフィックの全ての宛先ノードを特定するビット列を含む。ＢＩＥＲドメイン内のトランジットノードは、ユーザデータトラフィックを全ての宛先アドレスに送ることができることを保証するよう、ＢＩＥＲヘッダ内で運ばれるビット列に基づいてルーティングを実行する。
ノードに対して設定されたビット位置情報は、内部ゲートウェイプロトコル（interior gateway protocol、ＩＧＰ）又は境界ゲートウェイプロトコル（border gateway protocol、ＢＧＰ）を用いることによって、前もってＢＩＥＲドメイン内にフラッディングされる。そして、ＢＩＥＲドメイン内の各ノードに転送されるべきユーザデータトラフィックを指し示すために、ビットインデックス転送テーブル（bit index forwarding table、ＢＩＦＴ）が形成される。ＢＩＥＲヘッダとともにカプセル化されたＢＩＥＲパケットを受信すると、ＢＦＲはＢＩＦＴに従って、ＢＩＥＲパケットを宛先ノードに転送する。この出願の実施形態において、内部ゲートウェイプロトコルＩＧＰは、以下に限られないが、オープン最短パスファースト（open shortest path first、ＯＳＰＦ）プロトコル、中間システム間（intermediate system to intermediate system、ＩＳＩＳ）プロトコル、及びこれらに類するものを含み得る。
理解を容易にするために、以下にて、ＢＩＥＲ技術における基本概念を説明する。
（１）ＢＩＦＴ ＩＤ
ＢＩＦＴ ＩＤフィールドは、サブドメイン（sub-domain、ＳＤ）／ビット列長（bit string length、ＢＳＬ）／セット識別子（set identifier、ＳＩ）の組み合わせを含み得る。異なるＢＩＦＴ ＩＤは、ＳＤ／ＢＳＬ／ＳＩの異なる組み合わせに対応し得る。
１． サブドメイン（ＳＤ）
ＢＩＥＲドメインは、実際のサービスシナリオの要求に従って複数の異なるサブドメインＳＤを有して構成され得る。各サブドメインＳＤが、範囲［０－２５５］内の８ビット値であるサブドメイン識別子（sub-domain identify、ＳＤ－ＩＤ）で表される。例えば、例えば異なる仮想プライベートネットワーク（virtual private network、ＶＰＮ）といった異なるサービスに基づいて、ＢＩＥＲドメイン内に異なるＳＤが構成され得る。例えば、ＶＰＮ １はＳＤ ０を使用し、ＶＰＮ １はＳＤ １を使用する。
なお、代わりに複数のＶＰＮが同じＳＤを使用してもよい。ＢＩＥＲドメイン内の異なるＳＤは、同一のＩＧＰプロセス又はトポロジー内にあってもよいし、あるいは同一のＩＧＰプロセス又はトポロジー内になくてもよい。これは、この出願の実施形態において特に限定されることではない。
２． ビット列長（ＢＳＬ）
ＢＳＬは、ＢＩＥＲヘッダに含まれるビット列の長さである。複数のＢＳＬが存在し得る。これは、この出願の実施形態において特に限定されることではない。ＢＳＬは、６４ビット（最小）、１２８ビット、２５６ビット、５１２ビット、１０２４ビット、２０４８ビット、又は４０９６ビット（最大）とし得る。具体的には、パケットの識別に４ビットが使用される。例えば、ＢＳＬが６４ビットであるとき、０００１がパケットの識別に使用され、ＢＳＬが１２８ビットであるとき、００１０がパケットの識別に使用され、ＢＳＬが５１２ビットであるとき、０１００がパケットの識別に使用され、ＢＳＬが１０２４ビットであるとき、０１０１がパケットの識別に使用され、等々である。
３． セット識別子（ＳＩ）
ＳＩは、ネットワーク内の複数のノード又は設定されたＢＦＲ ＩＤを含むセットとして理解され得る。例えば、ＢＳＬが２５６ビットであるが、ネットワークに２５６よりも多いノードが存在する又は２５６よりも多いＢＦＲ ＩＤが設定されているとき、それらのノード又はＢＦＲ ＩＤは複数の異なるセットに分割される必要がある。例えば、そのＢＦＲ ＩＤが１から２５６であるノードがセット０（setindex ０、すなわち、ＳＩ＝０）を形成し、そのＢＦＲ ＩＤが２５７から５１２であるノードがセット１（setindex １、すなわち、ＳＩ＝１）を形成する。
ＢＩＥＲパケットを受信した後、ＢＩＥＲドメイン内のＢＦＲは、ＢＩＥＲヘッダ内のＢＩＦＴ ＩＤに基づいて、ＢＩＥＲパケットが属するＳＤ、使用されるＢＳＬ、及びパケット又は設定されたＢＦＲ ＩＤを転送するノードを含むセットを決定し得る。
以下に、ＢＩＦＴ ＩＤによって表されるＳＤ／ＢＳＬ／ＳＩの幾つかの取り得る組み合わせを列記する：
ＢＩＦＴ ＩＤ＝９１：ＳＤ ０、ＢＳＬ ２５６、ＳＩ ０に対応
ＢＩＦＴ ＩＤ＝９２：ＳＤ ０、ＢＳＬ ２５６、ＳＩ １に対応
ＢＩＦＴ ＩＤ＝９３：ＳＤ ０、ＢＳＬ ２５６、ＳＩ ２に対応
ＢＩＦＴ ＩＤ＝９４：ＳＤ ０、ＢＳＬ ２５６、ＳＩ ３に対応
ＢＩＦＴ ＩＤ＝９５：ＳＤ ０、ＢＳＬ ５１２、ＳＩ ０に対応
ＢＩＦＴ ＩＤ＝９６：ＳＤ ０、ＢＳＬ ５１２、ＳＩ １に対応。
例えば、ＢＩＦＴ ＩＤが９２であるとき、ＢＩＥＲパケットを受信した後、ＢＦＲは、ＢＩＥＲヘッダ内のＢＩＦＴ ＩＤに基づいて、ＢＩＥＲパケットがＳＤ ０に属し、ＢＩＥＲヘッダで使用されるＢＳＬが２５６ビットであり、且つＢＩＥＲパケットがセット１（そのＢＦＲ ＩＤが２５７から５１２であるノードを含むセット）に属することを決定し得る。
（２）ＢＦＲプレフィックス（BFR-prefix）
ＢＦＲプレフィックスは、各ＢＦＲのアドレス情報である。各ＢＦＲのアドレス情報は、ＢＩＥＲドメイン内で一意であり、ルータ識別子と等価である。具体的には、ＢＦＲ－ｐｒｅｆｉｘは一般にＢＦＲ装置のループバック（loopback）アドレスである。
（３）ビット列（bit string）
ビット列内の各ビットは、ＢＩＥＲパケットを受信する次ホップノードを指し示すために使用され得る。ＢＩＥＲドメイン内のＢＦＲがＢＩＥＲパケットヘッダを受信すると、ＢＦＲは、ＢＩＥＲヘッダ内で運ばれるビット列及びＢＩＦＴ ＩＤに基づいてＢＩＥＲパケットを転送する。
例えば、ＢＦＲによって受信されたＢＩＥＲヘッダ内のＢＩＦＴ ＩＤは９２であり、ビット列の長さは２５６ビットであり、ＢＩＥＲパケットを転送するノードは、そのＢＦＲ ＩＤが２５７から５１２であるノードのうちの１つである。ビット列内の最下位ビット（最も右のビット）は、宛先ノードがそのＢＦＲ ＩＤが２５７であるノードであることを指し示すために使用され、右から左に２番目のビットは、宛先ノードがそのＢＦＲ ＩＤが２５８であるノードであることを指し示すために使用される。
図２を参照して、以下、ＢＩＥＲ技術に基づいてＢＩＥＲパケットを転送するプロセスを詳細に説明する。
図２に示すように、各ＢＩＥＲドメイン内のエッジノードに一意なＢＦＲ－ｉｄを割り当てる必要がある。例えば、エッジノードＡ、Ｄ、Ｅ、及びＦに設定されるＢＦＲ－ｉｄは、それぞれ、４、１、３、及び２である。ＢＩＥＲヘッダ内にカプセル化されたビット列が、トラフィックの全ての宛先ノードを特定する。例えば、そのＢＦＲ－ｉｄが１であるノードＤに対応するビット列は０００１であり、そのＢＦＲ－ｉｄが２であるノードＦに対応するビット列は００１０であり、そのＢＦＲ－ｉｄが３であるノードＥに対応するビット列は０１００であり、そのＢＦＲ－ｉｄが４であるノードＡに対応するビット列は１０００である。
理解されるべきことには、各ＢＩＥＲドメイン内のエッジノードに割り当てられるＢＦＲ－ｉｄ値を、ルーティングプロトコルを用いることによって該ＢＩＥＲドメイン内の他のネットワーク装置にフラッディングすることができ、フラッディングされるＢＩＥＲ情報は更に、エッジノードのＩＰアドレス及びカプセル化情報を含む。例えば、ノードＡのフラッディングされるＢＩＥＲ情報は、ノードＡのＩＰアドレス及びＢＩＦＴ－ｉｄを運ぶ。ＢＩＥＲドメイン内のノードは、フラッディングされたＢＩＥＲ情報に基づいてビットインデックス転送テーブルＢＩＦＴを構築し得る。ＢＩＥＲパケットを受信した後、ノードは、構築したＢＩＦＴに従ってＢＩＥＲパケットを宛先ノードに転送する。
ノードＡの場合、そのＢＦＲ－ｉｄが１、２、及び３であるのＢＩＥＲノードへの次ホップはノードＢであり、そのＢＦＲ－ｉｄが４であるＢＩＥＲノードへの次ホップはノードＡ自身である。従って、ノードＡによって構築されるＢＩＦＴは次のようになる：
転送エントリ１：隣接（neighbor、Ｎｂｒ）＝Ｂ、転送ビットマスク（forwarding bit mask、ＦＢＭ）＝０１１１；
転送エントリ２：Ｎｂｒ＊＝Ａ、ＦＢＭ＝１０００。
転送エントリ１は、ＢＩＥＲパケット内のビット列のうち、右から左に１番目のビット、２番目のビット、又は３番目のビットのいずれか１つが１であるときに、ＢＩＥＲパケットが隣接ノードＢに送られることを指し示すために使用される。転送エントリ２は、ＢＩＥＲパケット内のビット列のうち、右から左に４番目のビットが１であるときに、ＢＩＥＲパケットがノードＡに送られることを指し示すために使用される。ノードＡはそれ自身であるため、ノードＡはＢＩＥＲヘッダを取り除き、ＢＩＥＲパケットを元のユーザデータパケットとして転送する。
なお、転送エントリにおいて、＊は、Ｎｂｒがノードそれ自身であることを指し示すために使用される。同様に、他のノードも、隣接ノードに基づいてＢＩＦＴを構築し得る。詳細については、図２を参照されたい。詳細をここで再び説明することはしない。
ユーザデータパケットを受信した後、ノードＡは、ユーザデータパケットをＢＩＥＲヘッダとともにカプセル化する。一例において、ユーザデータパケットを受信した後、ノードＡは、境界ゲートウェイプロトコルＢＧＰメッセージに基づいて、ユーザデータパケットの受取人を知ることができる。例えば、ユーザデータパケットの受取人は、そのＢＦＲ－ｉｄが３であるノードＥ、そのＢＦＲ－ｉｄが２であるノードＦ、及びそのＢＦＲ－ｉｄが１であるノードＤである。ノードＡは、ビット列が０１１１であるＢＩＥＲヘッダとともにＢＩＥＲパケットをカプセル化し、カプセル化したＢＩＥＲパケットを転送エントリ１に基づいて隣接ノードＢに転送する。ＢＩＥＲパケットを受信した後、ノードＢは、ビット列０１１１とＢＩＦＴとに基づいて、ＢＩＥＲパケットがノードＣ及びノードＥに別々に送信される必要があることを決定する。ＢＩＥＲパケットをノードＣに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列０１１１とＢＩＦＴ内のＮｂｒ＝ＣエントリのＦＢＭフィールドとに対してＡＮＤ演算を実行し得る。この出願のこの実施形態では、ＡＮＤの結果は００１１である。従って、ノードＢは、ＢＩＥＲヘッダ内のビット列を００１１に変更し、ＢＩＥＲパケットをノードＣに送信し得る。同様に、ＢＩＥＲパケットをノードＥに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列を０１００に変更し得る。ＢＩＥＲパケットを受信した後、ノードＥは、ビット列０１００に基づいて、ＢＩＥＲパケットが隣接ノードＥに送られるべきであると決定する。ノードＥは、転送テーブル内の識別子＊に従って、隣接ノードＥがノードＥ自身であると決定するので、ノードＥは、ＢＩＥＲヘッダをカプセル解除し、内部層のユーザデータパケットの宛先アドレスに基づいてＢＩＥＲパケットを転送する。
理解されるべきことには、ＢＩＥＲヘッダは、異なるプロトコルでは異なるカプセル化フォーマットを持つ。ＩＰｖ６を用いてカプセル化されたＢＩＥＲパケットは、ＢＩＥＲｖ６パケットとも称されることがある。リンク層にイーサネットリンクを使用するＢＩＥＲｖ６パケットのフォーマットは次の通りである：
Ｅｔｈヘッダ＋ＩＰｖ６基本ヘッダ＋ＩＰｖ６拡張ヘッダ（ＢＩＥＲヘッダを含む）＋ユーザデータパケット
なお、説明を容易にするために、ＢＩＥＲｖ６パケットのカプセル化がイーサネットリンク層にオーバーレイされる例を用いる。この出願のこの実施形態において、ＢＩＥＲカプセル化は代わりに、例えばポイント・ツー・ポイントプロトコル（point-to-point protocol、ＰＰＰ）リンクといった別タイプのリンクにオーバーレイされてもよい。
理解されるべきことには、複数のＩＰｖ６拡張ヘッダタイプが存在し、例えば、ＩＰｖ６拡張ヘッダが宛先オプションヘッダ（destination options header）とし得る。これは、この出願の実施形態において特に限定されることではない。
図３を参照して、以下、ＩＰｖ６拡張ヘッダが宛先オプションヘッダである例を使って、ＩＰｖ６を用いてカプセル化されたＢＩＥＲパケットのフォーマットを詳細に説明する。
図３を参照するに、ＢＩＥＲｖ６パケットは、ＢＩＥＲｖ６ヘッダ及び内部層のユーザデータパケット（例えば、ＩＰｖ６パケットとし得る）を含み得る。ＢＩＥＲｖ６ヘッダは、ＩＰｖ６基本ヘッダと宛先オプションヘッダとを含み得る。宛先オプションヘッダがＢＩＥＲヘッダを運ぶ。ＢＩＥＲヘッダに関する詳細については、前述の説明を参照されたい。詳細をここで再び説明することはしない。
（１）ＩＰｖ６基本ヘッダ
バージョン（version）：４ビット長
トラフィッククラス（traffic class、ＴＣ）：８ビット長。このフィールドは、ＩＰｖ６パケットのクラス及び優先度を指し示す。
フローラベル（flow label）：２０ビット長。“フロー”は、ネットワーク上の特定の送信元アドレスから特定の宛先アドレスへのデータパケットとして理解され得る。同一“フロー”に属するデータパケットは、同じフローラベルを持つ。
ペイロード長（payload length）：１６ビット長。このフィールドは、ＩＰｖ６基本ヘッダ以外の長さ、例えば、ＩＰｖ６拡張ヘッダ及び内部層のユーザデータパケットの長さ、を指し示す。
次ヘッダ（next header、ＮＨ）：８ビット長。このフィールドは、ＩＰｖ６基本ヘッダのすぐ後に続くＩＰｖ６拡張ヘッダの識別子（すなわち、ＩＰｖ６拡張ヘッダのタイプ）として理解されることができ、各ＩＰｖ６拡張ヘッダもＮＨフィールドを含む。
ホップ限度（hop limit、ＨＬ）：８ビット長。このフィールドは、ＩＰｖ４パケットヘッダ内の有効期間（time to live、ＴＴＬ）フィールドと同様である。
送信元アドレス（source address、ＳＡ）：１２８ビット長。このフィールドは、データパケットを送信するノードのＩＰｖ６アドレスを埋めるのに使用される。
宛先アドレス（destination address、ＤＡ）：１２８ビット長。このフィールドはデータパケットを受信するノードのＩＰｖ６アドレスを埋めるのに使用される。宛先アドレスフィールドはユニキャストアドレスである。例えば、ノードＤにＢＩＥＲパケットを送るとき、ノードＢは、宛先アドレスフィールドをノードＤのＩＰｖ６アドレスで埋めることができる。
（２）宛先オプションヘッダ（destination options header）
次ヘッダ（next header、ＮＨ）：８ビット長。このフィールドは、宛先オプションヘッダのすぐ後に続くＩＰｖ６拡張ヘッダの識別子（すなわち、ＩＰｖ６拡張ヘッダのタイプ）、又は例えばユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）パケットのタイプといった上位層ヘッダ（upper-layer header）のタイプとして理解され得る。
拡張ヘッダ長（header extend length、Ｈｄｒ Ｅｘｔ Ｌｅｎ）：８ビット長。このフィールドは、例えば宛先オプションヘッダの長さといった、ＩＰｖ６拡張ヘッダの長さを記述する。
タイプ－長さ－値（type-length-value、ＴＬＶ）：ＴＬＶ内のタイプ値は、ＴＬＶが１つのＢＩＥＲヘッダを含むことを指し示し、ＴＬＶ内の値部分がＢＩＥＲヘッダ全体を含む。具体的には、ＴＬＶ内のタイプ値は、図３に示されるオプションタイプ（option type）フィールドで運ばれ、値部分は、図３に示されるＢＩＥＲヘッダ（BIER header）フィールドで運ばれる。
この出願のこの実施形態で提供されるＢＩＥＲパケット送信方法によれば、ＢＩＥＲパケットを受信するノードのものであって識別子を運ぶものであるＩＰｖ６アドレスがＩＰｖ６拡張ヘッダの宛先アドレスフィールドに埋められ得る。斯くして、ＢＩＥＲパケットを受信するノードは、第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。これは、ＢＩＥＲパケットを受信するノードが、従来技術におけるＩＰｖ６アドレスと他のフィールドとに基づいてパケットタイプを一つ一つ決定することを防止する。従って、転送効率が改善される。
図４は、この出願の一実施形態に従ったＢＩＥＲパケット送信方法の概略フローチャートである。図４の方法は、ステップ４１０及び４２０を含み得る。以下、ステップ４１０及び４２０を別々に詳細に説明する。
ステップ４１０：第１の転送装置が、ＩＰｖ６プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信する。
第１の転送装置によって受信されるＩＰｖ６プロトコルを用いてカプセル化されたＢＩＥＲパケットは、ＩＰｖ６基本ヘッダとＢＩＥＲヘッダとを含む。ＩＰｖ６プロトコルを用いてカプセル化されたＢＩＥＲパケットの具体的なフォーマットについては、図３の説明を参照されたい。詳細をここで再び説明することはしない。
なお、ＢＩＥＲパケットは、マルチキャストデータを含んでいてもよいし、ユニキャストデータを含んでいてもよい。これは、この出願のこの実施形態において特に限定されることではない。
ステップ４２０：第１の転送装置が、ＢＩＥＲパケットにカプセル化され、転送テーブルに含められた第１のＩＰｖ６アドレスの識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定し、該識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される。
第１の転送装置は、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが第１のＩＰｖ６アドレスであることを決定し、且つローカルに格納された転送テーブル内に第１のＩＰｖ６アドレスが存在するかを決定する。第１のＩＰｖ６アドレスが設定されている場合、第１の転送装置がＢＩＥＲパケットの受信ノードであることが理解され得る。第１の転送装置は更に、転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行する必要があることを決定することができ、該識別子は、第１のＩＰｖ６アドレスが、それに基づいてＢＩＥＲ転送が実行される宛先アドレスであることを指し示すために使用される。
例えば、転送テーブル内に設定された第１のＩＰｖ６アドレスに対応する識別子がＥｎｄ．ＢＩＥＲである場合、第１のＩＰｖ６アドレスに設定されたエンド機能（end function）がＢＩＥＲパケット上でＢＩＥＲ転送を行っていることが理解され得る。第１のＩＰｖ６アドレスは、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスとも称され得る。
なお、第１のＩＰｖ６アドレスは、第１の転送装置に対して新たに設定されるアドレスであってもよいし、あるいは既に設定されたアドレスであってもよい。これは、この出願のこの実施形態において特に限定されることではない。
オプションで、一部の実施形態において、例えば第１の転送装置といった、ＢＩＥＲドメイン内のノードは、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをＢＩＥＲドメイン内の他のノードに対してフラッディングして、ＢＩＥＲパケットを転送するようにＢＩＥＲドメイン内の各ノードに指し示すために使用されるＢＩＦＴを形成し得る。換言すれば、ＢＩＥＲドメイン内の各ノードが、隣接ノードによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて、ＢＩＦＴ又はＢＩＥＲルーティングテーブルを構築し得る。
第１の転送装置がＢＩＥＲドメイン内の他のノードに対してＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをフラッディングし得る実装は複数存在する。これは、この出願のこの実施形態において特に限定されることではない。一例において、第１の転送装置は、第１のＩＰｖ６アドレスがＥｎｄ．ＢＩＥＲタイプのものであることを指し示す識別子を運ぶためにＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘフラッディングメッセージを使用する。他の一例では、第１の転送装置は、ＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘフラッディングメッセージとは異なるメッセージを使用し、すなわち、第１の転送装置はＳＲｖ６ ｌｏｃａｔｏｒメッセージを使用して、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスと、ＩＰｖ６アドレスに対応する識別子とを運ぶ。この識別子は、ＩＰｖ６アドレスのタイプがＥｎｄ．ＢＩＥＲであることを指し示す。以下にて、具体的な例を参照して詳細な説明を提供する。詳細をここで再び説明することはしない。
理解されるべきことには、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＢＩＥＲｖ６パケットがカプセル化されて転送されるときに運ばれるＩＰｖ６宛先アドレスを示すために使用される。
以下では、第１の転送装置が図２に示したノードＢである例を用いることによって、この実施形態で提供されるＢＩＥＲパケット送信プロセスを詳細に説明する。
ステップ１：ノードＢが、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスを設定する。
取り得る一実装において、設定されるＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＩＰｖ６－ｐｒｅｆｉｘとは異なるＩＰｖ６アドレスとし得る。例えば、ＳＩＤをＳＲｖ６ ｌｏｃａｔｏｒアドレス空間から選択することができる。以下は、ｌｏｃａｔｏｒにおいてＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスを設定するための特定の一実装である：
segment-routing ipv6
locator as1 ipv6-prefix 2002::
opcode ::AAAA End.BIER ##Ｅｎｄ．ＢＩＥＲタイプのＳＩＤとして2002::AAAAを設定する
opcode ::AAAB End.X ##Ｅｎｄ．ＸタイプのＳＩＤとして2002::AAABを設定する。
取り得る他の一実装において、設定されるＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、インタフェース（例えば、ループバックインタフェース）上に設定された１２８ビットマスクを持つＩＰｖ６アドレスとし得る。Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスの設定方法は、一般ＩＰｖ６アドレスの設定方法とは異なる。具体的な設定方法は次の通りであるとおりです：
interface loopback0
ipv6 address 2001::000A 128 ##これは一般ＩＰｖ６アドレスである
ipv6 address 2001::000B 128 End.BIER ##これはＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスである。
以下は、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスがＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘとしても使用される設定である：
sub-domain 6 ipv6 ##ＩＰｖ６を用いるようにＢＩＥＲサブドメイン６を設定する
BFR-prefix 2001::000B ##Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘとして設定する。
以下は、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスがＢＦＲ－ＩＰｖ６－ｐｒｅｆｉｘとしても使用される別の設定である：
Bier
sub-domain 6 ipv6 ##ＩＰｖ６を用いるようにＢＩＥＲサブドメイン６を設定する
BFR-prefix loopback0 ##ｌｏｏｐｂａｃｋ０上に設定されたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをＢＦＲ－ｐｒｅｆｉｘとして使用する。
ステップ２：ノードＢが、設定されたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスをローカルに格納するとともにフラッディングする。
取り得る一実装において、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレス及びそのＥｎｄ．ＢＩＥＲインジケーション情報をＢＩＥＲドメイン内の他のノードに対してフラッディングするためにノードＢによって使用されるメッセージは、ＢＩＥＲ情報をフラッディングするのに使用されるメッセージとは異なる。例えば、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレス及びＥｎｄ．ＢＩＥＲインジケーション情報は、ＩＳ－ＩＳ ＳＲｖ６ ｌｏｃａｔｏｒメッセージ内で運ばれ、ＢＩＥＲ情報は、ＩＳ－ＩＳ ｐｒｅｆｉｘ－ｒｅａｃｈａｂｉｌｉｔｙメッセージ内で運ばれる。
具体的には、図５を参照するに、ＢＩＥＲ情報は、ＩＳ－ＩＳプレフィックスリーチャビリティ（prefix-reachability）ＴＬＶメッセージ内で運ばれる。該メッセージは、ＢＦＲ－ＰｒｅｆｉｘのＩＰｖ６アドレス（ＢＦＲ－ＩＰｖ６－Ｐｒｅｆｉｘと称する）を運び、さらに、ＢＩＥＲサブドメイン（sub-domain）情報を運び、例えば、ＢＩＥＲサブドメイン情報はＢＩＥＲ情報サブＴＬＶ（BIER Info sub-TLV）とし得る。Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＩＳ－ＩＳ ＳＲｖ６ ｌｏｃａｔｏｒメッセージ内で運ばれる。例えば、Ｅｎｄ．ＢＩＥＲのＳＩＤ値（例えば、ＳＩＤは第１のＩＰｖ６アドレスを指し示す）及びＥｎｄ．ＢＩＥＲインジケーション（例えば、ＳＩＤタイプがＥｎｄ．ＢＩＥＲを指し示す）は、ＳＲｖ６ ｌｏｃａｔｏｒメッセージ内のＥｎｄ．ＢＩＥＲのＳＲｖ６ ＳＩＤ情報内で運ばれ得る。Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスは、ＢＦＲ－Ｐｒｅｆｉｘに対応するＩＰｖ６アドレスと異なってもよいし同じであってもよい。
取り得る他の一実装において、Ｅｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレス及びＥｎｄ．ＢＩＥＲ識別子は、ＢＩＥＲ情報と同じメッセージ内で運ばれてもよい。例えば、ＩＳ－ＩＳ ｐｒｅｆｉｘ－ｒｅａｃｈａｂｉｌｉｔｙメッセージが、Ｅｎｄ．ＢＩＥＲインジケーション（例えば、ＳＩＤタイプ＝Ｅｎｄ．ＢＩＥＲ）を運び、さらに、例えばＢＩＥＲサブドメインＳＤなどのＢＩＥＲ情報を運ぶ。
具体的には、図６を参照するに、ＢＩＥＲサブドメイン（sub-domain）情報に加えて、例えばＳＩＤタイプ＝Ｅｎｄ．ＢＩＥＲといった、Ｅｎｄ．ＢＩＥＲインジケーション情報も、ＢＩＥＲ情報をフラッディングするのに使用されるメッセージ内で運ばれ得る。対応して、ＢＦＲ－Ｐｒｅｆｉｘに対応するＩＰｖ６アドレスも、Ｅｎｄ．ＢＩＥＲタイプＩＰｖ６アドレスとして使用され、Ｅｎｄ．ＢＩＥＲインジケーション情報を持つ。
ステップ３：ノードＡが、ノードＢによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて、ＩＰｖ６ヘッダをカプセル化する。
ノードＡは、ノードＢによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて転送エントリを構築し、該転送エントリに従って、ノードＢへの複製が必要であると決定する。ノードＡは、次いで、ノードＢによってフラッディングされたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスを、ＩＰｖ６基本ヘッダ内のＤＡフィールドに埋めて、ノードＢにＢＩＥＲパケットを送信する。
ステップ４：ノードＢが、受信したＢＩＥＲパケット内で運ばれたＤＡフィールド内のノードＢのＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスに基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行する。
ノードＡによって送信されたＢＩＥＲパケットを受信した後、ノードＢは、ＩＰｖ６基本ヘッダ内のＤＡフィールドに埋められたアドレスが、ノードＢに対して設定されたＥｎｄ．ＢＩＥＲタイプのＩＰｖ６アドレスであることを決定する。具体的には、ノードＢは、ローカルに格納した転送テーブル内のＩＰｖ６アドレスがＩＰｖ６基本ヘッダ内のＤＡフィールドに埋められたアドレスと同じであることを決定し、そして、転送テーブル内のＩＰｖ６アドレスに対応する例えばＳＩＤタイプ＝Ｅｎｄ．ＢＩＥＲといった識別子に基づいて、受信したＢＩＥＲパケット上でＢＩＥＲ転送を実行する必要があることを決定し得る。
取り得る一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるとき、ＢＩＥＲパケットがＳＲＨヘッダを含む場合に、ノードＢは、ＳＲＨヘッダをポッピングし、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、インターネット制御メッセージプロトコル（internet control message protocol、ＩＣＭＰ）パラメータ問題メッセージを送信する。次の例では、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF NH=60 ##ＩＰｖ６基本ヘッダ内の次ヘッダＮＨが宛先オプションヘッダ（６０によって識別される）である
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE
9. drop the packet; possibly send an ICMP parameter problem message;
“NH=60”は、ＩＰｖ６基本ヘッダ内の次ヘッダが宛先オプションヘッダであることを指し示し、“DestOptHdr OptType=BIER”は、宛先オプションヘッダ内の第１オプションＴＬＶのタイプがＢＩＥＲであることを指し示し、“HdrExtLen*8+8=4+OptLength”は、宛先オプションヘッダが１つのＴＬＶのみを含むことを指し示す。ＴＬＶの長さ＋４が、宛先拡張ヘッダの全長と同じである（すなわち、宛先拡張ヘッダは１つのＢＩＥＲ ＴＬＶのみを含む）。
取り得る他の一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨが、セグメントルーティングヘッダＳＲＨであり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬが０であり、且つセグメントルーティングヘッダＳＲＨの次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるとき、ノードＢは、ＳＲＨヘッダをポッピングし、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、ＩＣＭＰパラメータ問題メッセージを送信する。次の例では、ルーティングヘッダＳＲＨ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF (NH=SRH and SL=0 and SRH_NH=DestOptHdr) ##拡張ヘッダがＳＲＨ及びＤｅｓｔＯｐｔＨｄｒである
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
ステップ８において、次ヘッダがＮＨチェーンの最後のＮＨである場合、すなわち、次ヘッダが上位層ヘッダ（upper-layer header）で埋められたＮＨフィールドである場合、該上位層ヘッダは内部層パケットのタイプを指し示すことができ、ノードは、内部層ユーザデータパケットを転送することができる。例えば、IPv6_NH=4は、次ヘッダによって指し示される内部層パケットのタイプがＩＰｖ４であることを指し示し、IPv6_NH=41は、次ヘッダによって指し示される内部層パケットのタイプがＩＰｖ６であることを指し示し、IPv6_NH=6は、次ヘッダによって指し示される内部層パケットのタイプが伝送制御プロトコル（transmission control protocol、ＴＣＰ）であることを指し示し、IPv6_NH=17は、次ヘッダによって指し示される内部層パケットのタイプがユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）であることを指し示し、IPv6_NH=58は、次ヘッダによって指し示される内部層パケットのタイプがＩＣＭＰであることを指し示し、そして、IPv6_NH=137は次ヘッダによって指し示される内部層パケットのタイプがマルチプロトコルラベルスイッチング（multi-protocol label switching、ＭＰＬＳ）であることを指す示す。
取り得る他の一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨがフラグメントヘッダ（fragment header）であり、且つフラグメントヘッダの次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるとき、あるいは、ＩＰｖ６基本ヘッダが、ＢＩＥＲを運ぶ拡張ヘッダに続かれ、次いでフラグメントヘッダに続かれるとき、ノードＢは、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、ＩＣＭＰパラメータ問題メッセージを送信する。処理手順は以下の通りである：
1. IF (NH=Frag and Frag_NH=DestOptHdr) or (NH=DestOptHdr and Dest_NH=Frag)
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
取り得る他の一実装において、ノードＢによって受信されたＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の次ヘッダＮＨが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、拡張ヘッダの次ヘッダＮＨが認証ヘッダ（authentication header、ＡＨ）であるとき、ＢＩＥＲパケットがＳＲＨヘッダを含む場合に、ノードＢは、ＳＲＨヘッダをポッピングし、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する。それ以外の場合、ノードＢは、ＢＩＥＲパケットを破棄し、インターネット制御メッセージプロトコル（internet control message protoco、ＩＣＭＰ）パラメータ問題メッセージを送信する。次の例では、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF (IPv6_NH=DestOptHdr and Dest_NH=AH)
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the SRH if exists. ##ＳＲＨヘッダが存在する場合、ＳＲＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
取り得る他の一実装において、ＩＰｖ６ ＮＨチェーンの最後のＮＨがＩＣＭＰｖ６である（すなわちlast_NH=ICMPv6）場合、ＢＩＥＲパケットは、例えばＩＣＭＰｖ６パケットカウントを追加したりＩＣＭＰｖ６応答パケットを送信したりするといった処理のために中央演算処理ユニット（central processing unit、ＣＰＵ）に送り込まれ得る。具体的な設定は以下の通りである：
1. IF Last_NH=ICMPv6 ##ＩＰｖ６ ＮＨチェーンの最後のＮＨがＩＣＭＰｖ６パケットを指し示す場合
2. Pump to CPU, add packet counter, possibly send an ICMP response message.
ステップ５：ノードＢが、ＢＩＥＲパケットを隣接ノードＥに転送する。
ノードＢは、転送エントリ及びビット列０１１１に基づいて、ＢＩＥＲパケットがノードＣ及びノードＥに別々に送信される必要があることを決定し得る。ＢＩＥＲパケットをノードＣに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列を００１１に変更し、ＩＰｖ６基本ヘッダ内のＤＡフィールドに、ノードＣによってフラッディングされたＥＮＤ．ＢＩＥＲタイプのＩＰｖ６アドレスを埋め、そして、ＢＩＥＲパケットをノードＣに送信し得る。同様に、ＢＩＥＲパケットをノードＥに送信するとき、ノードＢは、ＢＩＥＲヘッダ内のビット列を０１００に変更し、ＩＰｖ６基本ヘッダ内のＤＡフィールドに、ノードＥによってフラッディングされたＥＮＤ．ＢＩＥＲタイプのＩＰｖ６アドレスを埋め、そして、ＢＩＥＲパケットをノードＥに送信し得る。
取り得る一実装において、この出願のこの実施形態で、ノードＢがノードＥにＢＩＥＲパケットを送信するとき、ノードＢの隣接ノードＥがリーフノードとして決定される場合に、ノードＢは、ＢＩＥＲパケット内のＢＩＥＲヘッダを運ぶ拡張ヘッダをポッピングし得る。例えば、ノードＢは、ＢＩＥＲヘッダを運ぶ宛先オプションヘッダをポッピングし、ＢＩＥＲヘッダを運ぶ宛先オプションヘッダを含まないＢＩＥＲパケットをノードＥに送信する。ノードＢによって送信されたＢＩＥＲパケットをノードＥが受信した後、ノードＥはリーフノードであるので、ノードＥは、ＢＩＥＲヘッダを運ぶ拡張ヘッダをカプセル解除し、内部層ユーザデータパケットを転送する必要がある。ノードＢによって送信されたＢＩＥＲパケットが、ＢＩＥＲヘッダを運ぶ拡張ヘッダを含まない場合、ノードＥは、ＢＩＥＲヘッダを運ぶ拡張ヘッダをカプセル解除することなく、内部層ユーザデータパケットを直接転送することができる。具体的な設定は以下の通りである：
1. IF NH=60 ##ＩＰｖ６基本ヘッダ内の次ヘッダＮＨが宛先オプションヘッダ（６０によって識別される）である
2. IF (DestOptHdr OptType=BIER) and (HdrExtLen*8+8=4+OptLength)
3. pop the DoH if exists. ##ＤｏＨヘッダが存在する場合、ＤｏＨヘッダをポッピングする
4. lookup the BIER Header inside the BIER. ##ＢＩＥＲ内でＢＩＥＲヘッダを位置特定する
5. forward via the matched entry. ##一致したエントリに基づいてパケットを転送する
6. ELSE
7. drop the packet; possibly send an ICMP parameter problem message;
8. ELSE IF (IPv6_NH=4 or 41 or 97 or 137)
9. pop the Outer IPv6 header, and process the next header.
10. ELSE
11. drop the packet; possibly send an ICMP parameter problem message;
ノードＥによって受信されたＢＩＥＲパケットがＢＩＥＲヘッダを含んでいないとき、ステップ１から７はスキップされることができ、ステップ８及び９を直接実行し、それによりリーフノードＥの処理オーバーヘッドを削減することができる。
前述の技術的ソリューションでは、より柔軟なＢＩＥＲ展開を更にサポートすることができる。例えば、リーフノードＥはＢＩＥＲヘッダの読み取り又は処理をサポートしなくてもよいが、リーフノードＥが外部ＩＰｖ６ヘッダのポッピングをサポートする場合には、リーフノードＥはこの方法に従ってネットワーク内に展開されてもよい。
取り得る他の一実装において、ノードＢによって受信された宛先アドレスがＢのＥＮＤ．ＢＩＥＲである場合、ノードＢは以下のＥＮＤ．ＢＩＥＲ処理手順を実行する：ノードＢは、ＩＰｖ６拡張ヘッダ内にＮ個のＢＩＥＲヘッダがあることを決定し、Ｍ番目のＢＩＥＲヘッダを読み取って複製し（例えば、Ｍ番目のＢＩＥＲヘッダをノードＥに対して複製し）、ノードＥのＥＮＤ．ＢＩＥＲをＩＰｖ６ ＤＡフィールドに埋め、Ｍ番目のＢＩＥＲヘッダ以外のＢＩＥＲヘッダをポッピングし、そして、Ｍ番目のＢＩＥＲヘッダのみを保持する。ＩＰｖ６拡張ヘッダの長さフィールドはそれに従って変化される。次の例では、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨは宛先オプションヘッダである。具体的な設定は以下の通りである：
1. IF NH=60 //con2
2. IF (DestOptHdr OptType=BIER) and ((HdrExtLen*8+8)%(4+OptLength1)=0) //con1
3. Walk each TLV in DestOptHdr
4. If (OptType=BIER and OptLen=OptLength1) or(OptType=PadN and OptLen=0)
5. Continue
6. ELSE
7. Drop the packet; possibly send an ICMP parameter problem message;
8. End Walk of each TLV
9. For (N=0; N<(HdrExtLen*8+8)/(4+OptLength1); N++)
10. lookup the BIER Header begin from (N*OptLength1+4)bytes
11. copy packet if this packet need to forward to according to this lookup.
12. pop the TLV(s) except for this one, Set HdrExtLen=(4+OptLength1)/8.
13. forward via the matched entry,
14. END-FOR
15 ELSE //end of con1
16. drop the packet; possibly send an ICMP parameter problem message;
17. ELSE //end of con2
18. drop the packet; possibly send an ICMP parameter problem message;
ステップ２で、“HdrExtLen*8+8”は宛先オプションヘッダ（DestOptHdr）の全長を表し、“OptLength1”は第１のＢＩＥＲ ＴＬＶにおける長さ（Length、すなわち、ＢＩＥＲヘッダの長さ）を表す。宛先オプションヘッダ（DestOptHdr）がヘッダ全体の長さが８の整数倍であることを要求するので、ＢＩＥＲヘッダの長さ＋４は８の整数倍である。宛先オプションヘッダの長さは８バイトの単位であり、最初の８バイトは含まない。例えば：
（ＮｅｘｔＨｅａｄｅｒ＝ｘ，Ｌｅｎｇｔｈ＝１７，Ｔｙｐｅ＝ＢＩＥＲ，Ｌｅｎｇｔｈ＝４４） ／／注１；
（ＢＩＥＲヘッダ＜１２バイト（固定長）＋２５６ビットを表す３２バイト＞）／／最初のＢＩＥＲヘッダ；
（Ｔｙｐｅ＝ＰａｄＮ，Ｌｅｎｇｔｈ＝０，Ｔｙｐｅ＝ＢＩＥＲ，Ｌｅｎｇｔｈ＝４４）／／注２；
（ＢＩＥＲヘッダ＜１２バイト（固定長）＋２５６ビットを表す３２バイト＞））／／２番目のＢＩＥＲヘッダ；
（Ｔｙｐｅ＝ＰａｄＮ，Ｌｅｎｇｔｈ＝０，Ｔｙｐｅ＝ＢＩＥＲ，Ｌｅｎｇｔｈ＝４４）／／注３；
（ＢＩＥＲヘッダ＜１２バイト（固定長）＋２５６ビットを表す３２バイト＞））／／３番目のＢＩＥＲヘッダ；
注１：ＤｅｓｔＯｐｔＨｄｒは、ＮＨフィールド及び長さフィールドから始まる；
注２：ＰａｄＮ ＴＬＶは、２番目のＢＩＥＲ ＴＬＶの前にパディングされる；
注３：ＰａｄＮ ＴＬＶは、３番目のＢＩＥＲ ＴＬＶの前にパディングされる。
前述の構成において、ステップ３から８は、パケットフォーマットが要求を満たすかが決定されるループである。この出願のこの実施形態では、複数のＢＩＥＲヘッダは同じ長さ（すなわち、最初のＢＩＥＲヘッダのＯｐｔＬｅｎｇｔｈ１と同じ長さ）を持つことが要求され、２番目以降のＢＩＥＲヘッダはＰａｄＮでパディングされる（ＲＦＣ ８２００におけるパディング要求を参照）。
前述の設定において、ステップ９から１４は、各ＢＩＥＲヘッダが検討されるがＰａｄＮヘッダは処理されない別のループである。最初のＢＩＥＲヘッダが処理されるとき、最初のＢＩＥＲヘッダに続く２つのＢＩＥＲヘッダをポッピングするのは比較的容易であり、すなわち、（１＊（ＯｐｔＬｅｎｇｔｈ１＋４））番目のバイトから始まる９６バイトのみが破棄される必要があり、ＩＰｖ６拡張ヘッダの長さフィールド（ＤｅｓｔＯｐｔＨｄｒ Ｌｅｎｇｔｈ）が５に設定される。２番目のＢＩＥＲヘッダが処理されるとき、最初の及び３番目のＢＩＥＲヘッダがポッピングされる必要があり、すなわち、２番目のＢＩＥＲヘッダ（１＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトから始まるＯｐｔＬｅｎｇｔｈバイト）が、（０＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトがある位置にコピーされる必要があり、（１＊（ＯｐｔＬｅｎｇｔｈ１＋４））番目のバイトから始まる９６バイトが破棄され、ＤｅｓｔＯｐｔＨｄｒ Ｌｅｎｇｔｈが５に設定される。
３番目のＢＩＥＲヘッダが処理されるとき、最初の及び２番目のＢＩＥＲヘッダがポッピングされる必要があり、すなわち、３番目のＢＩＥＲヘッダ（２＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトから始まるＯｐｔＬｅｎｇｔｈバイト）が、（０＊（ＯｐｔＬｅｎｇｔｈ１＋４）＋４）番目のバイトがある位置にコピーされる必要があり、（１＊（ＯｐｔＬｅｎｇｔｈ１＋４））番目のバイトから始まる９６バイトが破棄され、ＤｅｓｔＯｐｔＨｄｒ Ｌｅｎｇｔｈが５に設定される。
以上では、図１から図６を参照して、この出願の実施形態で提供されるＢＩＥＲパケット送信方法を詳細に説明している。以下では、図７及び図８を参照して、この出願の実施形態におけるＢＩＥＲパケット送信装置を詳細に説明する。理解されるべきことには、方法実施形態の説明は装置実施形態の説明に対応する。従って、詳細に説明されない部分については、前述の方法実施形態における説明を参照されたい。
図７は、この出願の一実施形態に従ったＢＩＥＲパケット送信装置７００の概略構成図である。ＢＩＥＲパケット送信装置７００は、
インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信するように構成された受信モジュール７１０であり、ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを含み、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、第１の転送装置の第１のＩＰｖ６アドレスである、受信モジュール７１０と、
転送テーブル内の第１のＩＰｖ６アドレスに対応する識別子に基づいてＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定するように構成された処理モジュール７２０であり、識別子は、第１のＩＰｖ６アドレスがＢＩＥＲ転送の宛先アドレスであることを指し示すために使用される、処理モジュール７２０と、
を含み得る。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドに埋められたアドレスが転送テーブル内の第１のＩＰｖ６アドレスと同じであることを決定するように構成される。第１の転送装置は、第１のＩＰｖ６アドレスに対応する識別子に基づいて、ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを決定する。
オプションで、ＢＩＥＲパケット送信装置７００は更に、第１のＩＰｖ６アドレス及び識別子を設定するように構成された設定モジュール７４０を含む。
オプションで、装置７００は更に、ルーティングプロトコルを用いて、第１の転送装置の第１のＩＰｖ６アドレス及び識別子をネットワークにフラッディングするように構成された送信モジュール７３０を含む。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成される。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダＲＨであり、且つルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、ルーティングヘッダＲＨをポッピングし、且つＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成される。
オプションで、ルーティングヘッダＲＨはセグメントルーティングヘッダＳＲＨであり、セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である。
オプションで、処理モジュール７２０は具体的に、ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、ように構成される。
オプションで、処理モジュール７２０は具体的に、ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットのＩＰｖ６基本ヘッダ内の宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、ＢＩＥＲ転送テーブルは、第３の転送装置によってフラッディングされたＢＩＥＲメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築される、ように構成され、第１の転送装置は、ＢＩＥＲ転送テーブルに基づいてＢＩＥＲパケットを第３の転送装置に対して複製する。
オプションで、処理モジュール７２０は具体的に、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングし、拡張ヘッダを含まないＢＩＥＲパケットを第３の転送装置に対して複製する、ように構成される。
オプションで、処理モジュール７２０は具体的に、第３の転送装置がリーフノードであると決定したときに、１つ以上のＢＩＥＲヘッダを含む拡張ヘッダをポッピングする、ように構成される。
オプションで、拡張ヘッダは宛先オプションヘッダである。
オプションで、ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを含む。
図８は、この出願の一実施形態に従った第１転送装置８００の概略構成図である。第１転送装置６００は、メモリ８１０と、プロセッサ８２０と、入力／出力インタフェース８３０とを含み得る。
メモリ８１０、プロセッサ８２０、及び入力／出力インタフェース８３０は、内部接続パスを用いて接続される。メモリ８１０は、プログラム命令を格納するように構成される。プロセッサ８２０は、メモリ８１０に格納されたプログラム命令を実行して、入力データ及び情報を受信し、例えば演算結果などのデータを出力するように、入力／出力インタフェース８３０を制御するように構成される。
理解されるべきことには、この出願の実施形態におけるプロセッサ８２０は、中央演算処理ユニット（central processing unit、ＣＰＵ）であってもよいし、あるいは更には、別の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、又は別のプログラマブル論理デバイス、ディスクリートのゲート若しくはトランジスタ論理デバイス、ディスクリートのハードウェアコンポーネント、又はこれらに類するものであってもよい。汎用プロセッサはマイクロプロセッサであってもよく、あるいはプロセッサは、任意の従来からのプロセッサ又はそれに類するものであってもよい。代わりに、プロセッサ８２０は、１つ以上の集積回路であってもよく、関連プログラムを実行して、この出願の実施形態で提供される技術的ソリューションを実装するように構成される。
メモリ８１０は、読み出し専用メモリ及びランダムアクセスメモリを含み得るとともに、命令及びデータをプロセッサ８２０に提供し得る。プロセッサ８２０の一部が更に、不揮発性ランダムアクセスメモリを含んでもよい。例えば、プロセッサ８２０は更に、デバイスタイプの情報を格納してもよい。
一実装プロセスにおいて、前述の方法におけるステップは、プロセッサ８２０内のハードウェア集積論理回路を使用することによって、又はソフトウェアの形態の命令を使用することによって実装されることができる。この出願の実施形態を参照して開示された方法は、ハードウェアプロセッサによって直接実行されてもよいし、あるいはプロセッサ内のハードウェアとソフトウェアモジュールとの組み合わせを用いることによって実行されてもよい。ソフトウェアモジュールは、例えばランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的消去プログラム可能メモリ、又はレジスタなどの、当該技術分野における成熟した記憶媒体内に置かれ得る。記憶媒体がメモリ８１０内に配置され、そして、プロセッサ８２０が、メモリ８１０内の情報を読み出し、プロセッサのハードウェアと組み合わさって、上述の方法におけるステップを実行する。繰り返しを避けるために、詳細をここで再び説明することはしない。
理解されるべきことには、この出願の実施形態に従った第１転送装置８００は、この出願の実施形態における図２から図４に示した方法の対応する手順を実行するように構成される。加えて、第１転送装置８００内のモジュールの前述の及びその他の動作及び／又は機能は、この出願の実施形態における図２から図４に示した方法の対応する手順を実装するように別々に使用される。簡潔さのため、詳細をここで再び説明することはしない。
なお、図８に示す第１転送装置８００において、プロセッサは、メモリ内のコンピュータプログラムを呼び出して、モジュールによって実行されるステップを実装し得る。例えば、プロセッサは、キャッシュに格納されたコンピュータ命令を呼び出して、モジュール（例えば、図７に示した受信モジュール７１０及び処理モジュール７２０）によって実行されるステップを実行し得る。
理解されるべきことには、上述のプロセスのシーケンス番号は、この出願の様々な実施態様における実行順序を意味するものではない。プロセスの実行順序は、プロセスの機能及び内部ロジックに従って決定されるべきであり、この出願の実施態様の実装プロセスに対する何らかの限定として解釈されるべきでない。
当業者が認識し得ることには、この明細書に開示された実施形態にて記述された例と組み合わせて、ユニット及びアルゴリズムステップは、電子ハードウェアによって、又はコンピュータソフトウェアと電子ハードウェアとの組み合わせによって実装され得る。機能がハードウェアによって実行されるのか、それともソフトウェアによって実行されるのかは、技術的ソリューションの特定の用途及び設計制約に依存する。当業者は、特定の用途ごとに、記載された機能を実装するために異なる方法を用いることができるのであり、その実装がこの出願の範囲を超えるものであると考えるべきではない。
当業者によって明確に理解され得ることには、簡便且つ簡潔な説明の目的のため、上述のシステム、装置、及びユニットの詳細な動作プロセスについては、上述の方法の実施形態における対応するプロセスを参照されたく、ここで再び詳細を説明することはしない。
この出願にて提供された一部の実施形態において、理解されるべきことには、開示されたシステム、装置、及び方法は、その他のようにして実施されてもよい。例えば、記載された装置の実施形態は単なる例である。例えば、ユニット分割は、単なる論理機能分割であり、実際の実装においてはその他の分割とし得る。例えば、複数のユニット又はコンポーネントが別のシステムへと組み合わされたり統合されたりしてもよく、あるいは、一部の機構が無視されたり実行されなかったりしてもよい。また、図示又は説明された相互結合又は直接結合又は通信接続は、何らかのインタフェースを用いることによって実装され得る。装置又はユニットの間の間接結合又は通信接続は、電子的な形態、機械的な形態、又はその他の形態にて実装され得る。
別々の部分として記載されたユニットは、物理的に別々であってもなくてもよく、また、ユニットとして示された部分は、物理的なユニットであってもなくてもよく、一箇所にあってもよいし複数のネットワークユニットに分散されてもよい。それらユニットの一部又は全てが、実施形態のソリューションの目的を達成するように、実際の要求に基づいて選択され得る。
また、この出願の実施形態における複数の機能ユニットが１つの処理ユニットへと統合されてもよく、あるいは、それらユニットの各々が物理的に単独で存在してもよく、あるいは、２つ以上のユニットが１つのユニットへと統合される。
機能がソフトウェア機能ユニットの形態で実装されて、独立したプロダクトとして販売又は使用されるとき、その機能はコンピュータ読み取り可能記憶媒体に格納されてもよい。このような理解に基づき、この出願の技術的ソリューションは本質的に、又は先行技術に対して寄与する部分は、又は技術的ソリューションの一部は、ソフトウェアプロダクトの形態で実装され得る。コンピュータソフトウェアプロダクトは、記憶媒体に格納されるとともに、この出願の実施形態にて記載された方法のステップの全て又は一部を実行するようにコンピュータ装置（これは、パーソナルコンピュータ、サーバ、又はネットワーク装置）に命令する幾つかの命令を含む。上述の記憶媒体は、例えばＵＳＢフラッシュドライブ、リムーバブルハードディスク、読み出し専用メモリ（read-only memory，ＲＯＭ）、ランダムアクセスメモリ（random access memory，ＲＡＭ）、磁気ディスク、又は光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。
以上の説明は、単にこの出願の特定の実装であり、この出願の保護範囲を限定することを意図するものではない。この出願にて開示された技術的範囲内で当業者が容易に考え付く如何なる変形又は置換も、この出願の保護範囲に入るものである。従って、この出願の保護範囲は、請求項の保護範囲に従うものである。
以上の説明は、単に本発明の特定の実装であり、本発明の保護範囲を限定することを意図するものではない。本発明にて開示された技術的範囲内で当業者が容易に考え付く如何なる変形又は置換も、本発明の保護範囲に入るものである。従って、本発明の保護範囲は、請求項の保護範囲に従うものである。

Claims (28)

  1. ビットインデックス明示的複製ＢＩＥＲパケット送信方法であって、
    第１の転送装置により、インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信するステップであり、前記ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを有し、前記ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、前記第１の転送装置の第１のＩＰｖ６アドレスである、ステップと、
    前記第１の転送装置により、転送テーブル内の前記第１のＩＰｖ６アドレスに対応する識別子に基づいて前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行するステップであり、前記識別子は、前記第１のＩＰｖ６アドレスがＢＩＥＲの宛先アドレスであることを指し示すために使用される、ステップと、
    を有する方法。
  2. 前記第１の転送装置により、転送テーブル内の前記第１のＩＰｖ６アドレスに対応する識別子に基づいて前記ＢＩＥＲパケット上でＢＩＥＲ転送を前記実行するステップは、
    前記第１の転送装置により、前記ＩＰｖ６基本ヘッダ内の前記宛先アドレスフィールドに埋められたアドレスが前記転送テーブル内の前記第１のＩＰｖ６アドレスと同じであることを決定し、
    前記第１の転送装置により、前記第１のＩＰｖ６アドレスに対応する前記識別子に基づいて、前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行する、
    ことを有する、請求項１に記載の方法。
  3. 当該方法は更に、
    前記第１の転送装置により、前記第１のＩＰｖ６アドレス及び前記識別子を設定するステップ、
    を有する、請求項１又は２に記載の方法。
  4. 第１の転送装置により、インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを前記受信するステップの前に、当該方法は更に、
    前記第１の転送装置により、ルーティングプロトコルを用いて、前記第１の転送装置の前記第１のＩＰｖ６アドレス及び前記識別子をネットワークにフラッディングするステップ、
    を有する、請求項１乃至３のいずれか一項に記載の方法。
  5. 前記第１の転送装置により、前記第１のＩＰｖ６アドレスに対応する前記識別子に基づいて、前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを前記決定するステップは、
    前記ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、前記第１の転送装置により、前記ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、
    ことを有する、請求項１乃至４のいずれか一項に記載の方法。
  6. 前記第１の転送装置により、前記第１のＩＰｖ６アドレスに対応する前記識別子に基づいて、前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを前記決定するステップは、
    前記ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダＲＨであり、且つ前記ルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、前記第１の転送装置により、前記ルーティングヘッダＲＨをポッピングし、且つ前記ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、
    ことを有する、請求項１乃至４のいずれか一項に記載の方法。
  7. 前記ルーティングヘッダＲＨはセグメントルーティングヘッダＳＲＨであり、前記セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である、請求項６に記載の方法。
  8. 前記第１の転送装置により、前記第１のＩＰｖ６アドレスに対応する前記識別子に基づいて、前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを前記決定するステップは、
    前記ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ前記拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、前記第１の転送装置により、前記ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、
    ことを有する、請求項１乃至４のいずれか一項に記載の方法。
  9. 前記第１の転送装置により、前記第１のＩＰｖ６アドレスに対応する前記識別子に基づいて、前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行することを前記決定するステップは、
    前記第１の転送装置により、前記ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットの前記ＩＰｖ６基本ヘッダ内の前記宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、前記ＢＩＥＲ転送テーブルは、前記第３の転送装置によってフラッディングされたＢＩＥＲメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築され、
    前記第１の転送装置により、前記ＢＩＥＲ転送テーブルに基づいて前記ＢＩＥＲパケットを前記第３の転送装置に対して複製する、
    ことを有する、請求項５乃至８のいずれか一項に記載の方法。
  10. 前記第１の転送装置により、前記ＢＩＥＲ転送テーブルに基づいて前記ＢＩＥＲパケットを前記第３の転送装置に対して前記複製することは、
    前記第１の転送装置により、１つ以上の運ばれるＢＩＥＲヘッダをポッピングし、
    前記第１の転送装置により、１つ以上のＢＩＥＲヘッダを有する拡張ヘッダをポッピングし、
    前記第１の転送装置により、前記拡張ヘッダを有しない前記ＢＩＥＲパケットを前記第３の転送装置に対して複製する、
    ことを有する、請求項９に記載の方法。
  11. 前記第１の転送装置により、１つ以上のＢＩＥＲヘッダを有する拡張ヘッダを前記ポッピングすることは、
    前記第３の転送装置がリーフノードであると決定したときに、前記第１の転送装置により、１つ以上のＢＩＥＲヘッダを有する前記拡張ヘッダをポッピングする、
    ことを有する、請求項１０に記載の方法。
  12. 前記拡張ヘッダは宛先オプションヘッダである、請求項５乃至１１のいずれか一項に記載の方法。
  13. 前記ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを有する、請求項４乃至１２のいずれか一項に記載の方法。
  14. ビットインデックス明示的複製ＢＩＥＲパケット送信装置であって、
    インターネットプロトコルバージョン６ ＩＰｖ６ プロトコルを用いてカプセル化されて第２の転送装置によって送信されたＢＩＥＲパケットを受信するように構成された受信モジュールであり、前記ＢＩＥＲパケットは、ＩＰｖ６基本ヘッダ及びＢＩＥＲヘッダを有し、前記ＩＰｖ６基本ヘッダ内の宛先アドレスフィールドは、前記第１の転送装置の第１のＩＰｖ６アドレスである、受信モジュールと、
    転送テーブル内の前記第１のＩＰｖ６アドレスに対応する識別子に基づいて前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行するように構成された処理モジュールであり、前記識別子は、前記第１のＩＰｖ６アドレスがＢＩＥＲの宛先アドレスであることを指し示すために使用される、処理モジュールと、
    を有する装置。
  15. 前記処理モジュールは具体的に、
    前記ＩＰｖ６基本ヘッダ内の前記宛先アドレスフィールドに埋められたアドレスが前記転送テーブル内の前記第１のＩＰｖ６アドレスと同じであることを決定し、
    前記第１のＩＰｖ６アドレスに対応する前記識別子に基づいて、前記ＢＩＥＲパケット上でＢＩＥＲ転送を実行する、
    ように構成されている、請求項１４に記載の装置。
  16. 当該装置は更に、
    前記第１のＩＰｖ６アドレス及び前記識別子を設定するように構成された設定モジュール、
    を有する、請求項１４又は１５に記載の装置。
  17. 当該装置は更に、
    ルーティングプロトコルを用いて、前記第１の転送装置の前記第１のＩＰｖ６アドレス及び前記識別子をネットワークにフラッディングするように構成された送信モジュール、
    を有する、請求項１４乃至１６のいずれか一項に記載の装置。
  18. 前記処理モジュールは、
    前記ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、前記ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、
    ように構成されている、請求項１４乃至１７のいずれか一項に記載の装置。
  19. 前記処理モジュールは、
    前記ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドがルーティングヘッダＲＨであり、且つ前記ルーティングヘッダＲＨ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであるときに、前記ルーティングヘッダＲＨをポッピングし、且つ前記ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、
    ように構成されている、請求項１４乃至１７のいずれか一項に記載の装置。
  20. 前記ルーティングヘッダＲＨはセグメントルーティングヘッダＳＲＨであり、前記セグメントルーティングヘッダＳＲＨのセグメント左ＳＬは０である、請求項１９に記載の装置。
  21. 前記処理モジュールは、
    前記ＩＰｖ６基本ヘッダ内の次ヘッダＮＨフィールドが、１つのＢＩＥＲヘッダを運ぶ拡張ヘッダであり、且つ前記拡張ヘッダ内の次ヘッダＮＨフィールドがＡＨ認証ヘッダであるときに、前記ＢＩＥＲヘッダ内のビット列フィールドに基づいてＢＩＥＲ転送を実行する、
    ように構成されている、請求項１４乃至１７のいずれか一項に記載の装置。
  22. 前記処理モジュールは、
    前記ＢＩＥＲヘッダ内のビット列及びＢＩＥＲ転送テーブルに基づいて、ＢＩＥＲパケットの前記ＩＰｖ６基本ヘッダ内の前記宛先アドレスフィールド内の第３の転送装置の第１のＩＰｖ６アドレスを埋め、前記ＢＩＥＲ転送テーブルは、前記第３の転送装置によってフラッディングされたＢＩＥＲメッセージ内で運ばれる第１のＩＰｖ６アドレスに基づいて構築される、
    ように構成されており、
    前記第１の転送装置は、前記ＢＩＥＲ転送テーブルに基づいて前記ＢＩＥＲパケットを前記第３の転送装置に対して複製する、
    請求項１８乃至２１のいずれか一項に記載の装置。
  23. 前記処理モジュールは具体的に、
    １つ以上の運ばれるＢＩＥＲヘッダをポッピングし、
    １つ以上のＢＩＥＲヘッダを有する拡張ヘッダをポッピングし、
    前記拡張ヘッダを有しない前記ＢＩＥＲパケットを前記第３の転送装置に対して複製する、
    ように構成されている、請求項２２に記載の装置。
  24. 前記処理モジュールは具体的に、
    前記第３の転送装置がリーフノードであると決定したときに、１つ以上のＢＩＥＲヘッダを有する前記拡張ヘッダをポッピングする、
    ように構成されている、請求項２３に記載の装置。
  25. 前記拡張ヘッダは宛先オプションヘッダである、請求項１８乃至２４のいずれか一項に記載の装置。
  26. 前記ルーティングプロトコルは、中間システム間ＩＳ－ＩＳプロトコル、オープン最短パスファーストＯＳＰＦプロトコル、又は境界ゲートウェイプロトコルＢＧＰのうちのいずれか１つを有する、請求項１７乃至２５のいずれか一項に記載の装置。
  27. 入力／出力インタフェースと、プロセッサと、メモリとを有し、前記メモリは、プログラム命令を格納するように構成され、前記プロセッサは、前記メモリから前記プログラム命令を呼び出し、前記プログラム命令を実行して、請求項１乃至１３のいずれか一項に記載の方法を実行するように構成されている、第１転送装置。
  28. コンピュータプログラムを有し、該コンピュータプログラムがコンピュータ上で実行されるとき、該コンピュータは、請求項１乃至１３のいずれか一項に記載の方法を実行することを可能にされる、コンピュータ読み取り可能記憶媒体。

JP2021571827A 2019-06-06 2020-06-07 Ｂｉｅｒパケット送信方法及び装置 Active JP7322188B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910493114.7 2019-06-06
CN201910493114.7A CN112054959B (zh) 2019-06-06 2019-06-06 一种bier报文的发送方法和装置
PCT/CN2020/094791 WO2020244651A1 (zh) 2019-06-06 2020-06-07 一种bier报文的发送方法和装置

Publications (2)

Publication Number Publication Date
JP2022535405A true JP2022535405A (ja) 2022-08-08
JP7322188B2 JP7322188B2 (ja) 2023-08-07

Family

ID=73609062

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021571827A Active JP7322188B2 (ja) 2019-06-06 2020-06-07 Ｂｉｅｒパケット送信方法及び装置

Country Status (8)

Country Link
US (1) US11949585B2 (ja)
EP (1) EP3965381A4 (ja)
JP (1) JP7322188B2 (ja)
KR (1) KR102657811B1 (ja)
CN (2) CN112054959B (ja)
BR (1) BR112021024190A2 (ja)
MX (1) MX2021014793A (ja)
WO (1) WO2020244651A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11632254B2 (en) * 2020-02-21 2023-04-18 Mcafee, Llc Home or enterprise router-based secure domain name services
CN113055294A (zh) * 2020-12-29 2021-06-29 中兴通讯股份有限公司 报文封装、解封装方法、装置、存储介质及电子装置
CN114945000B (zh) * 2021-02-07 2023-08-15 中国移动通信有限公司研究院 一种组播报文传输方法、位转发路由器及存储介质
US11705983B2 (en) * 2021-03-22 2023-07-18 Cisco Technology, Inc. Efficient BIER forwarding over varying BSL domain using header stitching
CN115314150A (zh) * 2021-04-21 2022-11-08 中兴通讯股份有限公司 一种报文处理方法、装置、存储介质及电子装置
CN115277552A (zh) * 2021-04-30 2022-11-01 华为技术有限公司 传输报文的方法、装置及设备
CN115699685A (zh) * 2021-05-28 2023-02-03 新华三技术有限公司 随流检测方法和电子设备
CN115733790A (zh) * 2021-09-02 2023-03-03 华为技术有限公司 报文转发方法、装置、设备及存储介质
CN113839895B (zh) * 2021-11-01 2023-08-22 新华三技术有限公司合肥分公司 一种报文转发方法及装置
CN115134275A (zh) * 2022-06-06 2022-09-30 中国信息通信研究院 利用IPv6逐跳扩展头实现单向网络测试的方法、电子设备及存储介质
EP4376375A1 (en) * 2022-11-28 2024-05-29 Huawei Technologies Co., Ltd. Packet mirroring method, apparatus, and system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150256456A1 (en) * 2014-03-06 2015-09-10 Cisco Technology, Inc. Segment routing extension headers
WO2019057199A1 (zh) * 2017-09-25 2019-03-28 华为技术有限公司 一种报文转发的方法及网络设备

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7246175B1 (en) 2001-12-07 2007-07-17 Cisco Technology, Inc. IPv6 over MPLS IPv4 core
US10447575B1 (en) * 2012-12-27 2019-10-15 Sitting Man, Llc Routing methods, systems, and computer program products
WO2015042156A1 (en) * 2013-09-17 2015-03-26 Cisco Technology, Inc. Bit indexed explicit replication
US9438432B2 (en) * 2013-09-17 2016-09-06 Cisco Technology, Inc. Bit indexed explicit replication packet encapsulation
US11451474B2 (en) * 2013-09-17 2022-09-20 Cisco Technology, Inc. Equal cost multi-path with bit indexed explicit replication
US9444677B2 (en) 2013-10-18 2016-09-13 Cisco Technology, Inc. Scalable edge node protection using IPv6 segment routing extension header
US9749410B2 (en) * 2014-11-18 2017-08-29 Cisco Technology, Inc. Using bit index explicit replication (BIER) in low-power and lossy networks
US10341221B2 (en) * 2015-02-26 2019-07-02 Cisco Technology, Inc. Traffic engineering for bit indexed explicit replication
CN106341327A (zh) * 2015-07-08 2017-01-18 中兴通讯股份有限公司 一种bier报文的传输方法及系统
CN106572017B (zh) * 2015-10-09 2021-06-15 中兴通讯股份有限公司 Bier信息的发送方法、接收方法及装置
CN106603407B (zh) * 2015-10-16 2020-10-27 中兴通讯股份有限公司 组播地址的传输方法和装置
CN111294236B (zh) * 2015-12-28 2023-04-18 华为技术有限公司 基于业务功能链sfc的通信方法和装置
US9992111B2 (en) 2016-01-21 2018-06-05 Cisco Technology, Inc. Router table scaling in modular platforms
US10270690B2 (en) 2016-02-29 2019-04-23 Cisco Technology, Inc. System and method for dataplane-signaled packet capture in IPV6 environment
GB201612356D0 (en) 2016-04-19 2016-08-31 Cisco Tech Inc Network monitoring and control system and method
CN107592262A (zh) * 2016-07-07 2018-01-16 中兴通讯股份有限公司 报文发送方法和装置、报文跨域转发的网络架构
US10382597B2 (en) 2016-07-20 2019-08-13 Cisco Technology, Inc. System and method for transport-layer level identification and isolation of container traffic
CN107786451A (zh) * 2016-08-30 2018-03-09 中兴通讯股份有限公司 一种元数据的传输方法及装置
US10469379B2 (en) * 2017-02-17 2019-11-05 Cisco Technology, Inc. System and method to facilitate content delivery to multiple recipients in a network environment
CN108632150B (zh) * 2017-03-22 2022-02-25 中兴通讯股份有限公司 一种信息传递方法及装置
US10447496B2 (en) * 2017-03-30 2019-10-15 Cisco Technology, Inc. Multicast traffic steering using tree identity in bit indexed explicit replication (BIER)
CN108965134B (zh) * 2017-05-23 2022-04-29 中兴通讯股份有限公司 报文转发方法及装置
US10506083B2 (en) 2017-06-27 2019-12-10 Cisco Technology, Inc. Segment routing gateway storing segment routing encapsulating header used in encapsulating and forwarding of returned native packet
US10367734B2 (en) 2017-07-11 2019-07-30 Cisco Technology, Inc. Forwarding of packets in a network based on multiple compact forwarding identifiers represented in a single internet protocol version 6 (IPv6) address
CN109510771B (zh) * 2017-09-15 2021-06-29 北京华为数字技术有限公司 组播传输方法及相关设备
CN109756425B (zh) * 2017-11-07 2022-01-18 中国电信股份有限公司 组播转发方法、装置以及bfr
CN109729012B (zh) * 2018-12-24 2021-08-24 新华三技术有限公司 一种单播报文传输方法和装置
CN110784411B (zh) * 2019-09-30 2021-10-01 华为技术有限公司 建立bier转发表项的方法、装置和系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150256456A1 (en) * 2014-03-06 2015-09-10 Cisco Technology, Inc. Segment routing extension headers
WO2019057199A1 (zh) * 2017-09-25 2019-03-28 华为技术有限公司 一种报文转发的方法及网络设备
CN109561021A (zh) * 2017-09-25 2019-04-02 华为技术有限公司 一种报文转发的方法及网络设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Encapsulation for BIER in Non-MPLS IPv6 Networks draft-xie-bier-6man-encapsulation-02", ENCAPSULATION FOR BIER IN NON-MPLS IPV6 NETWORKS DRAFT-XIE-BIER-6MAN-ENCAPSULATION-02, JPN6023001443, 1 September 2018 (2018-09-01), ISSN: 0004971844 *

Also Published As

Publication number Publication date
MX2021014793A (es) 2022-01-18
CN114189473A (zh) 2022-03-15
EP3965381A1 (en) 2022-03-09
CN112054959B (zh) 2021-11-19
JP7322188B2 (ja) 2023-08-07
WO2020244651A1 (zh) 2020-12-10
KR20220007736A (ko) 2022-01-18
CN112054959A (zh) 2020-12-08
BR112021024190A2 (pt) 2022-01-11
CN114189473B (zh) 2023-07-14
EP3965381A4 (en) 2022-10-26
US20220109623A1 (en) 2022-04-07
US11949585B2 (en) 2024-04-02
KR102657811B1 (ko) 2024-04-15

Similar Documents

Publication Publication Date Title
JP7322188B2 (ja) Ｂｉｅｒパケット送信方法及び装置
US11902049B2 (en) BIER packet sending method and apparatus
JP7419510B2 (ja) Ｂｉｅｒ転送項目構築方法、装置、およびシステム
JP7208386B2 (ja) パケット転送方法、パケット送信装置、およびパケット受信装置
AU2011244044B2 (en) Efficient encapsulation of packets transmitted on a packet-pseudowire over a Packet Switched Network
JP5992602B2 (ja) ＩＰｖ６ネットワークにおいてラベル配布プロトコル（ＬＤＰ）を使用するためのシステムおよび方法
AU2011244044A1 (en) Efficient encapsulation of packets transmitted on a packet-pseudowire over a Packet Switched Network
WO2022041916A1 (zh) 报文头的处理方法及装置、存储介质、电子装置
JP2010177800A (ja) パケット転送方法及びノード装置
JP2023549797A (ja) Ｂｉｅｒパケット転送方法、デバイス、及びシステム
Bao et al. IP/ICMP translation algorithm
WO2023174188A1 (zh) 一种报文处理的方法、路由通告的方法及相关设备
US20240171510A1 (en) Packet transmission method and related device
WO2024045537A1 (zh) 报文传输的方法和网络设备
Eastlake 3rd et al. Transparent interconnection of lots of links (TRILL): Clarifications, corrections, and updates
EP3863237B1 (en) Packet forwarding method, packet transmission device, and packet reception device
EP4246917A1 (en) Message transmission method, method for acquiring correspondence, and apparatus and system
US11757767B2 (en) Source routing with shadow addresses
WO2024092288A1 (en) Segment routing (sr) binding protection
Bao et al. RFC 7915: IP/ICMP Translation Algorithm
CN115733790A (zh) 报文转发方法、装置、设备及存储介质
Gashinsky TRILL working group L. Dunbar Internet Draft D. Eastlake Intended status: Standard Track Huawei Expires: Sept 2012 Radia Perlman Intel

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211227

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211227

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221228

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230420

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230627

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230726

R150 Certificate of patent or registration of utility model

Ref document number: 7322188

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150