JP2022548987A - リバースパス転送ｒｐｆチェック方法及び装置 - Google Patents

リバースパス転送ｒｐｆチェック方法及び装置 Download PDF

Info

Publication number
JP2022548987A
JP2022548987A JP2022518284A JP2022518284A JP2022548987A JP 2022548987 A JP2022548987 A JP 2022548987A JP 2022518284 A JP2022518284 A JP 2022518284A JP 2022518284 A JP2022518284 A JP 2022518284A JP 2022548987 A JP2022548987 A JP 2022548987A
Authority
JP
Japan
Prior art keywords
identifier
multicast
node
address
correspondence
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
JP2022518284A
Other languages
English (en)
Other versions
JP7397178B2 (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 JP2022548987A publication Critical patent/JP2022548987A/ja
Application granted granted Critical
Publication of JP7397178B2 publication Critical patent/JP7397178B2/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
    • 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/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical 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/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/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/70—Routing based on monitoring results
    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/604—Address structures or formats
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses
    • 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/72—Routing based on the source address
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

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

Abstract

本出願の実施形態は、ＲＰＦチェック方法を開示する。ヘッドノードからマルチキャストデータパケットを受信した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びマルチキャストデータパケット内で搬送されるカプセル化情報を取得し得る。次いで、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて、マルチキャストデータパケットに対応するアップストリームマルチキャストネクストホップＵＭＨノードを識別するために使用される第１の識別子を取得する。加えて、テールノードは、マルチキャストデータパケットのカプセル化情報及び第２の対応に基づいて、マルチキャストデータパケットに対応するヘッドノードを識別するために使用される第２の識別子をさらに取得し得る。第１の識別子及び第２の識別子を取得した後、テールノードは、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行し得る。本出願の実施形態では、第１の識別子及び第２の識別子のデータ長はそれぞれ１２８ビット未満である。したがって、本出願の実施形態では、ＲＰＦチェックを簡素化するために、１２８ビット未満の２つのデータを比較してもよい。

Description

本出願は、通信分野に関し、特に、リバースパス転送ＲＰＦチェック方法及び装置に関する。
本出願は、中国特許出願第ＣＮ２０１９１０９００９５４．０は、２０１９年９月２３日に中国国家知的財産管理局に出願され、「リバースパス転送ＲＰＦチェック方法及び装置」と題され、その全体が参照により本明細書に組み込まれる。
現在、仮想プライベートネットワーク（ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ、ＶＰＮ）は、コアネットワーク内にあり、プロバイダによって提供されるネットワークエッジノード（ｐｒｏｖｉｄｅｒ ｅｄｇｅ、ＰＥ）上に展開され得る。それに応じて、ＶＰＮインスタンスを使用して、マルチキャストサービスを処理し得る。マルチキャストサービスを使用して、マルチキャストグループ内の１つのＰＥから１つまたは複数の他のＰＥにマルチキャストデータパケットを送信することができる。
実際のアプリケーションでは、マルチキャストデータパケットが１つのＰＥから複数の他のＰＥに送信されるとき、マルチキャストデータパケットを受信するＰＥ、例えば、テールノードは、受信したマルチキャストデータパケットに対してリバースパス転送（ｒｅｖｅｒｓｅ ｐａｔｈ ｆｏｒｗａｒｄｉｎｇ、ＲＰＦ）チェックを実行する必要がある。テールノードは、チェック結果に基づいて、マルチキャストデータパケットを転送するかどうかを決定する。ＲＰＦチェックは、マルチキャストデータパケットが、選択されたアップストリームマルチキャストネクストホップ（ｕｐｓｔｒｅａｍ ｍｕｌｔｉｃａｓｔ ｈｏｐ、ＵＭＨ）ノードから来ているかどうかを決定するためのものである。マルチキャストデータパケットが、選択されたアップストリームマルチキャストネクストホップノードから来る場合、テールノードはマルチキャストデータパケットを転送する；または、マルチキャストデータパケットが、選択されたアップストリームマルチキャストネクストホップノードから来ない場合、テールノードはマルチキャストデータパケットを破棄する。
ＶＰＮが展開されているプロバイダネットワークがインターネットプロトコルバージョン６（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６、ＩＰｖ６）ネットワークである場合、マルチキャストサービスを実装するテールノードによって実行されるＲＰＦチェックは複雑である。
本出願の実施形態は、ＲＰＦチェックを簡素化するためのＲＰＦ方法及び装置を提供する。
第１の態様によれば、本出願の一実施形態は、リバースパス転送チェック方法を提供する。ヘッドノードからマルチキャストデータパケットを受信した後、テールノードは、マルチキャストデータパケットを解析して、マルチキャストソースアドレス、マルチキャストグループアドレス、及びマルチキャストデータパケット内で搬送されるカプセル化情報を取得し得る。マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて、マルチキャストデータパケットに対応するアップストリームマルチキャストネクストホップＵＭＨノードを識別するために使用される第１の識別子を取得し得る。第１の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間のマッピング関係を含む。したがって、マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、第１の対応に基づいて第１の識別子を決定し得る。加えて、テールノードは、マルチキャストデータパケットのカプセル化情報及び第２の対応に基づいて、マルチキャストデータパケットに対応するヘッドノードを識別するために使用される第２の識別子をさらに取得し得る。第１の識別子及び第２の識別子を取得した後、テールノードは、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行し得る。ＩＰｖ６ネットワークにおいて、ノードのアドレスは、１２８ビットを使用して表されることが理解できる。したがって、ＲＰＦチェックを実行するとき、テールノードは２つの１２８ビットデータを比較する必要がある。その結果、ＲＰＦチェックは複雑である。しかしながら、本出願のこの実施形態では、第１の識別子及び第２の識別子のデータ長はそれぞれ１２８ビット未満である。したがって、本出願のこの実施形態では、１２８ビット未満の２つのデータを比較して、ＲＰＦチェックを完了し得る。従来の技術と比較して、本出願のこの実施形態で提供される解決策では、ＲＰＦチェックが簡素化されることを学ぶことができる。
一実施態様では、第１の対応は、事前にテールノードによって生成され得る。具体的には、テールノードは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信し得る。マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。新しいマルチキャストジョインメッセージを受信した後、テールノードは、マルチキャストジョインメッセージを解析して、マルチキャストジョインメッセージ内のマルチキャストソースアドレスを取得し、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得し得る。次いで、テールノードは、ＵＭＨノードのＩＰｖ６アドレスに基づいて、ＵＭＨノードのＩＰｖ６アドレスに対応する第１の識別子を取得し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間の対応を確立し、言い換えれば、第１の対応を確立し、その後のＲＦＰチェックの間の第１の対応に基づいて第１の識別子が決定される。
一実施態様では、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に加えて、第１の対応は、マルチキャストインスタンスの識別子をさらに含み得る。マルチキャストインスタンスは、テールノードに対応する。言い換えると、マルチキャストインスタンスは、テールノードのマルチキャストインスタンスである。この場合、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得する特定の実装では、テールノードは、マルチキャストインスタンスの識別子をさらに決定し得、次いで、テールノードは、マルチキャストインスタンスの識別子及びマルチキャストソースアドレスを参照してＵＭＨノードのＩＰｖ６アドレスを検索する。具体的には、テールノードは、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含む所定の第３の対応に基づいて、ＵＭＨノードのＩＰｖ６アドレスを決定し得る。対応して、第１の対応を確立するとき、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、第１の識別子、及びマルチキャストインスタンスの識別子の間で第１の対応をさらに確立し得る。
一実装では、ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、ＭＶＰＮインスタンスの識別子であってよく、ＥＶＰＮの場合、マルチキャストインスタンスの識別子は、ＥＶＰＮインスタンスの識別子であってよい。加えて、実際の適用では、ＭＶＰＮの場合、マルチキャストジョインメッセージを受信するインターフェースが属するＶＲＦの識別子を使用して、マルチキャストインスタンスを識別し得る。したがって、ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、例えば、マルチキャストジョインメッセージを受信するインターフェースが属するＶＲＦの識別子であってもよい。
一実装では、第２の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、テールノードは、以下の方法で第２の対応を確立してもよい：テールノードは、ヘッドノードによって送信されたマルチキャストルーティングメッセージを受信する。マルチキャストルーティングメッセージは、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子を含む。テールノードは、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得する。テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
一実装では、第２の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがＢＩＥＲトンネルである場合、テールノードは、以下の方法で第２の対応を確立してもよい：テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信する。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス及びＢＩＥＲトンネルの識別子を含む。テールノードは、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得する。テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
一実装では、第２の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、テールノードは、以下の方法で第２の対応を確立してもよい：テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信する。マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含む。カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである。テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
一実装では、ＭＶＰＮの場合、ヘッドノードによってテールノードに送信されたマルチキャストルーティングメッセージは、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報である。ＥＶＰＮの場合、ヘッドノードによってテールノードに送信されたマルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
一実装では、実際の適用では、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表され得、２つの３２ビットデータを比較する複雑さは、通常、テールノードによって許容することができる範囲内にある。したがって、本出願のこの実施形態の一実装では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値であり得る。
一実装では、プロバイダネットワークは、代替的に、ｖ４ｖ６デュアルスタックネットワークであってもよく、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表されてもよいと考えられる。第１の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別し、第２の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別するために、第１の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできず、それに応じて、第２の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできない。現在、０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦの範囲の値は、ＩＰｖ４ネットワーク内のノードのアドレスとして使用されず、０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦの範囲の値は、ＩＰｖ４ネットワークのノードのアドレスとして使用されない。したがって、第１の識別子及び第２の識別子は、範囲０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦ内にあり得るか、または第１の識別子及び第２の識別子は、範囲０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ内にあり得る。
第２の態様によれば、本出願の一実施形態は、ＲＰＦチェック装置を提供する。装置は、マルチキャストデータパケットをヘッドノードから受信するように構成された受信ユニットであって、マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む、受信ユニットと、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得するように構成された取得ユニットであって、第１の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子を含み、第１の識別子は、マルチキャストデータパケットに対応するアップストリームマルチキャストネクストホップＵＭＨノードを識別するために使用され、取得ユニットは、カプセル化情報及び第２の対応に基づいて第２の識別子を取得するようにさらに構成され、第２の対応は、カプセル化情報及び第２の識別子を含み、第２の識別子は、ヘッドノードを識別するために使用され、第１の識別子及び第２の識別子はそれぞれ１２８ビット未満である、取得ユニットと、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行するように構成されたＲＰＦチェックユニットと、を含む。
一実施態様では、受信ユニットは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成され、マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含み、取得ユニットは、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、ＵＭＨノードのＩＰｖ６アドレスに基づいて第１の識別子を取得し、第１の識別子は、ＵＭＨノードのＩＰｖ６アドレスに対応し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に基づいて第１の対応を取得するようにさらに構成される。
一実施態様では、第１の対応は、マルチキャストインスタンスの識別子をさらに含み、取得ユニットは、マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、マルチキャストソースアドレス、第３の対応、及びマルチキャストインスタンスの識別子に基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、第３の対応は、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含み、マルチキャストソースアドレス、マルチキャストグループアドレス、マルチキャストインスタンスの識別子、及び第１の識別子に基づいて第１の対応を取得するように特に構成される。
一実施態様では、マルチキャストインスタンスの識別子は、仮想ルーティング転送ＶＲＦの識別子またはイーサネット仮想プライベートネットワークＥＶＰＮインスタンスの識別子を含む。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のマルチプロトコルラベルスイッチングＭＰＬＳポイントツーマルチポイントＰ２ＭＰトンネルの識別子を含み、取得ユニットは、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得し、第４の対応は、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードによってＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するようにさらに構成される。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のビットインデックス明示的レプリケーションＢＩＥＲトンネルの識別子を含み、ビアトンネルの識別子は、ＢＩＥＲトンネルの識別子は、ＢＩＥＲサブドメイン識別子サブドメインＩＤを含み、取得ユニットは、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得し、第５の対応は、ＢＩＥＲトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子ＢＩＦＴ－ｉｄを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するようにさらに構成される。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスであり、取得ユニットは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するようにさらに構成される。
一実施態様では、マルチキャストルーティング情報は、マルチキャスト仮想プライベートネットワークＭＶＰＮルーティング情報またはイーサネット仮想プライベートネットワークＥＶＰＮルーティング情報を含む。
一実施態様では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値である。
一実施態様では、第１の識別子及び第２の識別子は、次のアドレス範囲、０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦまたは０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦのうちの１つの範囲内にある。
第３の態様によれば、本出願の一実施形態は、ＲＰＦチェックデバイスを提供する。デバイスは、プロセッサ及びメモリを含み、メモリは、命令を記憶するように構成され、プロセッサは、第１の態様及び第１の態様の実装のいずれか１つによる方法を実行するために、メモリ内の命令を実行するように構成される。
第４の態様によれば、本出願の一実施形態は、命令を含むコンピュータ可読記憶媒体を提供する。命令がコンピュータ上で実行されるとき、コンピュータは、第１の態様及び第１の態様の実装のいずれか１つによる方法を実行することが可能である。
第５の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第１の態様及び第１の態様の実装のいずれか１つによる方法を実行することが可能である。
本出願の一実施形態によるマルチキャストネットワークの構造の概略図である。 本出願の一実施形態によるＲＰＦチェック方法の概略フローチャートである。 本出願の一実施形態による、第１の対応を生成するための方法のシグナリング相互作用図である。 本出願の一実施形態による、第２の対応を生成するための方法のシグナリング相互作用図である。 本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。 本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。 本出願の一実施形態によるＲＰＦチェック装置の構造の概略図である。 本出願の一実施形態によるＲＰＦチェックデバイスの構造の概略図である。
本出願の実施形態は、ＶＰＮが展開されているプロバイダネットワークが従来技術におけるＩＰｖ６ネットワークである場合に、テールノードによって実行されたＲＰＦチェックが複雑であるという問題を解決するためのＲＰＦチェック方法を提供する。
わかりやすくするために、本出願の実施形態の適用シナリオを最初に説明する。
図１は、本出願の一実施形態によるマルチキャストネットワークの構造の概略図である。
図１に示すように、ＣＥ１、ＣＥ２、及びＣＥ３は、ユーザ機器であってもよい。具体的には、ＣＥ１、ＣＥ２、及びＣＥ３は、ユーザボーダールータであってもよい。ＰＥ１、ＰＥ１ｂ、Ｐ１、Ｐ２、ＰＥ２、ＰＥ３は、プロバイダネットワーク内のデバイスである。ＣＥ１は、マルチキャストソースサーバに、具体的には、マルチキャストデータパケットを送信するソースノードに接続される。ＰＥ１、ＰＥ１ｂ、ＰＥ２、ＰＥ３は、プロバイダネットワーク内のエッジノードである。ＣＥ２及びＣＥ３は、マルチキャスト受信ノードに接続される。マルチキャスト受信ノードは、例えば、パーソナルコンピュータ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ、ＰＣ）またはセットトップボックス（ｓｅｔ ｔｏｐ ｂｏｘ、ＳＴＢ）デバイスであってもよい。ＣＥ２は、ＰＥ２からマルチキャストデータパケットを受信してよく、ＣＥ３は、ＰＥ３からマルチキャストデータパケットを受信してよい。
実際の適用では、ＶＰＮは、プロバイダネットワーク内のエッジノード上に展開され得ることに留意されたい。ＶＰＮインスタンス及びＶＰＮインスタンスが展開されるネットワーク構造に使用されるシグナリングに基づいて、ＶＰＮは、レイヤ３仮想プライベートネットワーク（Ｌａｙｅｒ－３ ＶＰＮ、Ｌ３ＶＰＮ）またはイーサネット仮想プライベートネットワーク（ｅｔｈｅｒｎｅｔ ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ、ＥＶＰＮ）であり得る。Ｌ３ＶＰＮでは、ユニキャストサービスは、ボーダーゲートウェイプロトコル（ｂｏｒｄｅｒ ｇａｔｅｗａｙ ｐｒｏｔｏｃｏｌ、ＢＧＰ）ＶＰＮｖ４シグナリングまたはＶＰＮｖ６シグナリングに基づいて確立されてもよく、もしくはマルチキャストサービス、すなわち、ＭＶＰＮサービスは、ＢＧＰマルチキャスト仮想プライベートネットワーク（ｍｕｌｔｉｃａｓｔ ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ、ＭＶＰＮ）シグナリングに基づいて確立されてもよい。ＥＶＰＮでは、ユニキャストサービスは、ＢＧＰ ＥＶＰＮシグナリングに基づいて確立されてもよく、またはマルチキャストサービス、すなわち、ＥＶＰＮマルチキャストサービスは、ＢＧＰ ＥＶＰＮマルチキャストシグナリングに基づいて確立されてもよい。さらに、マルチキャストサービスは、ＥＶＰＮにおけるＢＧＰ ＭＶＰＮシグナリングに基づいて確立されてもよく、そのようなマルチキャストサービスは、ＭＶＰＮサービスとも呼ばれる。ＭＶＰＮ及びＥＶＰＮにおけるマルチキャストサービスを処理する同じ一般的な手順がある。本出願のこの実施形態における以下の説明では、ＭＶＰＮが、説明のための例として使用される。
プロバイダのＰＥとユーザ機器、すなわちＣＥとの間のマルチキャストサービスがＩＰｖ６マルチキャストである場合、マルチキャストサービスはＩＰｖ６ ＭＶＰＮと呼ばれる。プロバイダのＰＥとユーザ機器、すなわちＣＥとの間のマルチキャストサービスがＩＰｖ４マルチキャストである場合、マルチキャストサービスはＩＰｖ４ ＭＶＰＮと呼ばれる。本出願のこの実施形態では、ＩＰｖ６ ＭＶＰＮとＩＰｖ４ ＭＶＰＮの両方が適用可能であり、ＭＶＰＮと総称される。
プロバイダのＰＥ間の部分は、ＶＰＮバックボーン（ＶＰＮ ｂａｃｋｂｏｎｅ）と呼ばれる。本出願のこの実施形態では、ＶＰＮバックボーンは、ＩＰｖ６シングルプロトコルスタックが動作するネットワーク、またはＩＰｖ４及びＩＰｖ６デュアルスタック（またはｖ４ｖ６デュアルスタック）が動作するネットワークであってもよい。ＭＶＰＮでのマルチキャストルート選択にＩＰｖ６アドレスが使用されることを確認する必要があるだけである。ＩＰｖ６シングルプロトコルスタックまたはｖ４ｖ６デュアルスタックが使用されるかどうかは、本出願のこの実施形態では限定されない。
さらに、ＭＶＰＮシグナリングは、ＶＰＮマルチキャスト及びパブリックネットワークマルチキャストの両方に適用できる。ＶＰＮマルチキャストは、Ｌ３ＶＰＮに基づいて確立されたＶＰＮであっても、ＥＶＰＮに基づいて確立されたＶＰＮであってもよい。本出願のこの実施形態におけるＭＶＰＮは、パブリックネットワークマルチキャストに使用されるＭＶＰＮシグナリング方法と、ＶＰＮマルチキャストに使用されるＭＶＰＮシグナリング方法の両方を含む。これは、本出願のこの実施形態では限定されない。
確かに、プロバイダのＰＥとユーザ機器との間のマルチキャストネットワークは、代替的に、ｖ４ｖ６デュアルスタックネットワークであり得る。言い換えると、ＩＰｖ４ネットワーク及びＩＰｖ６ネットワークの両方がサポートされる。本出願のこの実施形態では、プロバイダのＰＥとユーザ機器との間のネットワークは限定されない。
実際の適用では、包括的プロバイダマルチキャストサービスインターフェース（ｉｎｃｌｕｓｉｖｅ ｐｒｏｖｉｄｅｒ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ ｉｎｔｅｒｆａｃｅ、ＩＰＭＳＩ）トンネルを使用して、ＭＶＰＮ内でマルチキャストサービスを搬送することができる。ＩＰＭＳＩトンネルを使用してマルチキャストサービスを搬送する場合、マルチキャストデータパケットがトンネルを介して伝送される処理において、トンネルタイプに基づいて、マルチキャストソースからのマルチキャストデータパケットに、使用されたトンネルタイプにマッチするカプセル化情報のレイヤを追加してもよい。
ＩＰＭＳＩトンネルは、図１を参照して説明される。ＩＰＭＳＩトンネルは、例えば、ＰＥ１、ＰＥ１ｂ、ＰＥ２、及びＰＥ３の間に確立されたポイントツーマルチプルポイント（ｐｏｉｎｔ ｔｏ ｍｕｌｔｉｐｌｅ ｐｏｉｎｔ、Ｐ２ＭＰ）トンネル、例えば、そのルートノードがＰＥ１であり、リーフノードがＰＥ１ｂ、ＰＥ２、及びＰＥ３であるＰ２ＭＰトンネルであってもよい。Ｐ２ＭＰトンネルは、マルチキャストサービスを搬送するために使用される。例えば、ＰＥ１によって受信されたすべてのマルチキャストデータパケットは、Ｐ２ＭＰトンネルを介してＰＥ２及びＰＥ３に送信されてもよい。確かに、ＩＰＭＳＩトンネルは、代替的に、そのルートノードがＰＥ１ｂであり、リーフノードがＰＥ１、ＰＥ２、及びＰＥ３であるＰ２ＭＰトンネルであり得る。Ｐ２ＭＰトンネルは、マルチキャストサービスを搬送するために使用される。例えば、ＰＥ１ｂによって受信されたすべてのマルチキャストデータパケットは、Ｐ２ＭＰトンネルを介してＰＥ２及びＰＥ３に送信されてもよい。
図１は、わかりやすくするためにのみマルチキャストネットワークを示し、マルチキャストネットワークは、代替的に別の構造であってもよく、トンネルタイプは、Ｐ２ＭＰトンネルに限定されないことに留意されたい。別の構造のマルチキャストネットワークについては、Ｐ２ＭＰトンネルまたはマルチプルポイントツーマルチプルポイント（ｍｕｌｔｉｐｌｅ ｐｏｉｎｔ ｔｏ ｍｕｌｔｉｐｌｅ ｐｏｉｎｔ、ＭＰ２ＭＰ）トンネルは、マルチキャストネットワークの特定の構造に基づいて、複数のＰＥの間に確立され得る。これは、本出願のこの実施形態では特に限定されない。
図１に示すように、ＣＥ１は、ＰＥ１に加えてＰＥ１ｂに接続されている。マルチキャストグループ（Ｓ１、Ｇ１）に対してユーザによって送信されたマルチキャストジョイン要求を受信した後、ＰＥ２は、マルチキャストソースアドレスＳ１のルートの次のホップを検索する。マルチキャストソースアドレスＳ１は、ＣＥ１に接続されているマルチキャストソースサーバのＩＰアドレスまたはＩＰｖ６アドレスである。ＭＶＰＮが適用されるネットワークについて、マルチキャストソースアドレスＳ１のルートであり、ＰＥ２によって見つかるルートは、ＶＰＮプライベートネットワークルートであり得、ルートの次のホップは、ＢＧＰネクストホップである。マルチキャストソースのルートであり、ＭＶＰＮのテールノードから見つかる次のホップは、「ＶＰＮバックボーンを横切る（ａｃｒｏｓｓ ｔｈｅ ＶＰＮ ｂａｃｋｂｏｎｅ）」次のホップであり、ＵＭＨノードとも呼ばれる。
図１に示されるように、ＣＥ１の２つの次のホップが存在してよく、それぞれ、ＰＥ１及びＰＥ１ｂである。対応して、ＰＥ２はまた、クエリを通じて、マルチキャストソースアドレスＳ１へのルートの２つの次のホップを取得し得る。ＰＥ２は、ＢＧＰルート選択ルールに基づいて、Ｓ１に対応するマルチキャストソースのアップストリームマルチキャストネクストホップＵＭＨノードとして、ＰＥ１及びＰＥ１ｂのうちの１つを選択する。このプロセスは、ＵＭＨ選択と呼ばれる。同様に、ＰＥ３は、ＰＥ３のＵＭＨ選択を行う。例えば、ＰＥ２は、Ｓ１に対応するマルチキャストソースのＵＭＨとしてＰＥ１を選択し、ＰＥ３は、Ｓ１に対応するマルチキャストソースのＵＭＨとしてＰＥ１ｂを選択する。図１に示すネットワーク内でマルチキャストサービスが搬送された場合、ＰＥ１は受信したマルチキャストデータパケットをＰＥ２及びＰＥ３に送信する。対応して、ＰＥ１ｂは、受信したマルチキャストデータパケットをＰＥ２及びＰＥ３に送信する。ＣＥ１によって送信された１つのマルチキャストデータパケットについて、ＰＥ２は、マルチキャストデータパケットを繰り返し受信することを理解することができる。例えば、マルチキャストデータパケットは、経路ＣＥ１－＞ＰＥ１－＞Ｐ１－＞ＰＥ２を介してＰＥ２に到達し得、マルチキャストデータパケットは、代替的に経路ＣＥ１－＞ＰＥ１ｂ－＞Ｐ２－＞ＰＥ２を介してＰＥ２に到達し得る。同様に、ＰＥ３は、マルチキャストデータパケットを繰り返し受信する。
この場合、ＰＥ２及びＰＥ３はＲＰＦチェックを行い、ＰＥ２及びＰＥ３は選択したＵＭＨからのパケットのみを転送する。例えば、ＰＥ２は、ＰＥ１からのパケットを転送し、ＰＥ１ｂからのパケットを破棄し、ＰＥ３は、ＰＥ１ｂからのパケットを転送し、ＰＥ１からのパケットを破棄する。
従来の技術では、マルチキャストデータパケットを受信した後、テールノード、例えばＰＥ２は、マルチキャストデータパケットに対してＲＰＦチェックを実行してもよく、言い換えれば、マルチキャストデータパケットが、選択されたＵＭＨノードから来るかどうかを決定してもよい。具体的には、プロバイダネットワークがＩＰｖ６ネットワークである場合、ＩＰｖ６ネットワーク内の各ノードのアドレスは、１２８ビットを使用して表される。したがって、ＲＰＦチェックを実行する必要がある場合、テールノードは、ＵＭＨノードの第１のアドレスを取得し、マルチキャストデータパケットのカプセル化情報に基づいてヘッドノードの第２のアドレスを取得し、比較を通じて、第１のアドレスが第２のアドレスと同一であるかどうかを学習して、ＲＰＦチェックを完了し得る。従来の技術では、ＶＰＮが展開されているプロバイダネットワークがＩＰｖ６ネットワークである場合に、ＲＰＦチェックを完了する必要がある場合、２つの１２８ビットＩＰｖ６アドレス（すなわち、第１のアドレス及び第２のアドレス）を比較する必要があることを学ぶことができる。その結果、ＲＰＦチェックは複雑である。加えて、テールノードは、ＵＭＨノードの１２８ビットＩＰｖ６アドレス及びヘッドノードの１２８ビットＩＰｖ６アドレスを格納する必要がある。したがって、対応する記憶量は大きい。
これに鑑み、本出願の一実施形態は、ＶＰＮが展開されているプロバイダネットワークがＩＰｖ６ネットワークである場合のＲＰＦチェックを簡素化するためのＲＰＦチェック方法を提供する。本出願のこの実施形態において提供されるＲＰＦチェック方法を、添付の図面を参照して以下に説明する。
図２は、本出願の一実施形態によるＲＰＦチェック方法の概略フローチャートである。
本出願のこの実施形態において提供されるＲＰＦチェック方法は、ＩＰｖ６ネットワークに適用されてもよい。ＩＰｖ６ネットワークは、ヘッドノード及びテールノードを含む。ヘッドノード及びテールノードはそれぞれ、ＩＰｖ６ネットワーク内のエッジノードである。ヘッドノードは、マルチキャストソースまたはマルチキャストソースに接続されたユーザ機器からマルチキャストデータパケットを受信するノードである。テールノードは、ヘッドノードからマルチキャストデータパケットを受信し、マルチキャストデータパケットをマルチキャストデータパケットの宛先ノードに転送するノードである。例えば、図１のＰＥ１及びＰＥ１ｂは、ヘッドノードであってよく、ＰＥ２及びＰＥ３は、テールノードであってよい。
本出願のこの実施形態において提供されるＲＰＦチェック方法は、例えば、以下のステップ１０１から１０４を使用して実装してもよい。
ステップ１０１：テールノードは、マルチキャストデータパケットをヘッドノードから受信し、マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む。
このステップにおけるマルチキャストデータパケットは、マルチキャストソースによってヘッドノードに送信され、ヘッドノードが対応するカプセル化情報を追加し、テールノードに送信されるパケットである。
上述のように、ＩＰＭＳＩトンネルは、マルチキャストサービスを搬送するために使用され得る。ＩＰＭＳＩトンネルがマルチキャストサービスを搬送するために使用されるとき、マルチキャストデータパケットがトンネルを介して伝送されるプロセスにおいて、ヘッドノードは、使用されたトンネルタイプに基づいて、マルチキャストソースからのマルチキャストデータパケットに、トンネルタイプにマッチするカプセル化情報のレイヤを追加し得る。具体的には、マルチキャストデータパケットを転送する前に、ヘッドノードは、マルチキャストソースからのマルチキャストデータパケットに、ヘッドノードに対応し、使用されたトンネルタイプにマッチするカプセル化を追加し得る。例えば、マルチキャストソースノードからマルチキャストデータパケットを受信した後、ヘッドノードは、カプセル化情報をマルチキャストデータパケットの外側カプセル化フィールドに追加し、カプセル化情報が追加されるマルチキャストデータパケットをテールノードに送信し得る。言い換えると、テールノードによって受信されたマルチキャストデータパケットは、カプセル化情報を含むパケットである。
マルチキャストデータパケットを受信した後、テールノードは、対応するユーザ機器にマルチキャストデータパケットを転送するかどうかを決定し得る。本出願のこの実施形態では、マルチキャストデータパケットは、ＩＰｖ４パケットであってもよく、またはＩＰｖ６パケットであってもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態では、マルチキャストデータパケットは、マルチキャストソースアドレス及びマルチキャストグループアドレスを搬送する。マルチキャストソースアドレスは、マルチキャストソースノードのアドレスである。マルチキャストグループアドレスは、マルチキャスト宛先ノードのアドレスである。マルチキャストデータパケットを受信した後、テールノードは、マルチキャストデータパケットを解析して、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を取得し得る。
ステップ１０２：テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得し、第１の識別子は、マルチキャストデータパケットに対応するＵＭＨノードを識別するために使用される。
本出願のこの実施形態では、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間の対応、すなわち第１の対応を予め記憶する。第１の対応は、マルチキャスト転送情報（ｍｕｌｔｉｃａｓｔ ｆｏｒｗａｒｄｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ｂａｓｅ、ＭＦＩＢ）テーブルのエントリに格納され得る。したがって、マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、第１の対応に基づいて、マルチキャストデータパケットに対応するＵＭＨノードを識別するために使用される第１の識別子を決定し得る。
第１の識別子は、マルチキャストデータパケットに対応するＵＭＨノードのアドレスに類似しており、第１の識別子はまた、マルチキャストデータパケットに対応するＵＭＨノードを一意に識別し得ることに留意されたい。しかしながら、ＩＰｖ６ネットワークでは、マルチキャストデータパケットに対応するＵＭＨノードのアドレスは１２８ビットデータである。しかしながら、本出願のこの実施形態では、第１の識別子は、１２８ビット未満である。
ステップ１０３：テールノードは、カプセル化情報及び第２の対応に基づいて、ヘッドノードを識別するために使用される第２の識別子を取得する。
本出願のこの実施形態では、テールノードは、カプセル化情報と第２の識別子との間の対応、すなわち第２の対応を事前に記憶する。第２の識別子は、マルチキャストデータパケットに対応するヘッドノードのアドレスに類似しており、第２の識別子はまた、マルチキャストデータパケットに対応するヘッドノードを一意に識別し得る。しかしながら、ＩＰｖ６ネットワークでは、マルチキャストデータパケットに対応するヘッドノードのアドレスは１２８ビットデータである。しかしながら、本出願のこの実施形態では、第２の識別子は、１２８ビット未満である。
ステップ１０１で説明されるように、マルチキャストデータパケットを受信した後、テールノードは、対応するカプセル化情報を取得するために、マルチキャストデータパケットを解析し得る。解析を通じてカプセル化情報を取得した後、テールノードは、カプセル化情報及び第２の対応に基づいて、ヘッドノードに対応する第２の識別子を決定し得る。第２の対応は、例えば、（ＭＰＬＳ Ｐ２ＭＰラベル＝Ｌｘ、ＲｏｏｔＩＰ＝Ｒｘ）であってもよい。カプセル化情報がＬｘであると決定した後、第２の識別子がＲｘであると決定され得る。
カプセル化情報は、マルチキャストサービスを搬送するトンネルのタイプに関するものであることに留意されたい。本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルのタイプは、ＭＰＬＳ Ｐ２ＭＰトンネルであってもよく、ビットインデックス明示的レプリケーションマルチプロトコルラベルスイッチング（ｂｉｔ ｉｎｄｅｘｅｄ ｅｘｐｌｉｃｉｔ ｒｅｐｌｉｃａｔｉｏｎ ＭＰＬＳ、ＢＩＥＲ－ＭＰＬＳ）トンネルであってもよく、またはＢＩＥＲｖ６トンネルであってもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、対応するカプセル化情報は、ＭＰＬＳ Ｐ２ＭＰトンネルラベルを含み得る。マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、対応するカプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子（Ｂｉｔ Ｉｎｄｅｘ Ｆｏｒｗａｒｄｉｎｇ Ｔａｂｌｅ Ｉｄｅｎｔｉｆｉｅｒ、ＢＩＦＴ－ｉｄ）を含んでよい。マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、対応するカプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスを含んでよい。
ステップ１０４：テールノードは、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行する。
第１の識別子を決定した後、テールノードはＵＭＨノードを決定し得ることが理解することができる。第２の識別子を決定した後、テールノードは、マルチキャストデータパケットを実際に転送するヘッドノードを決定する。したがって、テールノードは、第１の識別子と第２の識別子とを比較することによってＲＰＦチェックを実行し得る。第１の識別子が第２の識別子に等しい場合、マルチキャストデータパケットがテールノードによって選択されたＵＭＨノードからであることを示し、マルチキャストデータパケットに対して実行されたＲＰＦチェックが成功する。さらに、テールノードは、マルチキャストデータパケットを転送し得る。第１の識別子が第２の識別子と等しくない場合、マルチキャストデータパケットがテールノードによって選択されたＵＭＨノードからではないことを示し、マルチキャストデータパケットに対して実行されたＲＰＦチェックが失敗する。さらに、テールノードは、マルチキャストデータパケットを破棄し得る。
前述の説明から、本出願のこの実施形態において提供される解決策によれば、第１の識別子及び第２の識別子のデータ長はそれぞれ１２８ビット未満であることを学ぶことができる。したがって、本出願のこの実施形態では、１２８ビット未満の２つのデータを比較して、ＲＰＦチェックを完了し得る。本出願のこの実施形態において提供される解決策によれば、テールノードによって実行されるＲＰＦチェックの計算量を減らすことができることを学ぶことができる。
上述のように、第１の識別子及び第２の識別子はそれぞれ、１２８ビット以下の値である。実際の適用では、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表され得、２つの３２ビットデータを比較することの複雑さは、通常、テールノードによって許容することができる範囲内にある。したがって、本出願のこの実施形態の一実装では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値であり得る。マルチキャストネットワークがＩＰｖ６ ＭＶＰＮ（またはＩＰｖ６ ＥＶＰＮ）である場合、各ノードのアドレスが１２８ビットであるため、３２ビットを使用してアドレスが記述されるノードが存在しないことを理解することができる。したがって、この場合、第１の識別子及び第２の識別子はそれぞれ、３２ビット未満の任意の値を使用して表され得る。
上述のように、プロバイダネットワークは、代替的に、ｖ４ｖ６デュアルスタックネットワークであってもよく、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表されてもよい。この場合、第１の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別し、第２の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別するために、第１の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできず、それに応じて、第２の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできない。現在、範囲０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦ内の値は、ＩＰｖ４ネットワーク内のノードのアドレスとして使用されず、範囲０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ内の値は、ＩＰｖ４ネットワーク内のノードのアドレスとして使用されない。したがって、本出願のこの実施形態の一実装では、第１の識別子及び第２の識別子は、範囲０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦ内にあり得るか、または第１の識別子及び第２の識別子は、範囲０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ内にあり得る。
本出願のこの実施形態では、第１の対応は、事前にテールノードによって生成され得る。テールノードが第１の対応を生成する具体的な実装は、添付の図面を参照して以下に説明される。
図３は、本出願の一実施形態による、第１の対応を生成するための方法のシグナリング相互作用図である。図３の第１の対応を生成する方法は、例えば、以下のステップ２０１から２０４を用いて実装してもよい。
ステップ２０１：カスタマエッジノードは、マルチキャストジョインメッセージをテールノードに送信し、マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。
マルチキャストジョインメッセージは、本出願のこの実施形態では特に限定されず、マルチキャストジョインメッセージは、例えば、プロトコル非依存マルチキャスト（ｐｒｏｔｏｃｏｌ ｉｎｄｅｐｅｎｄｅｎｔ ｍｕｌｔｉｃａｓｔ、ＰＩＭ）メッセージであり得る。
新しいマルチキャストジョインメッセージを受信した後、テールノードは、マルチキャストジョインメッセージを解析して、マルチキャストジョインメッセージ内のマルチキャストソースアドレスを取得し、マルチキャストソースアドレスに基づいて、続いて、ＵＭＨノードのＩＰｖ６アドレスを取得し得る。
ステップ２０２：テールノードは、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得する。
実際の適用では、ヘッドノードは、ルーティングメッセージをテールノードに送信し得る。ルーティングメッセージは、マルチキャストソースアドレス及びＵＭＨノードのＩＰｖ６アドレスを搬送する。ルーティングメッセージを受信した後、テールノードは、マルチキャストソースアドレス、ＵＭＨノードのＩＰｖ６アドレス、及びマルチキャストソースアドレスとＵＭＨノードのＩＰｖ６アドレスとの間の対応を記憶し得る。カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信し、解析を通じて、マルチキャストジョインメッセージ内で搬送されたマルチキャストソースアドレスを取得した後、テールノードは、マルチキャストソースアドレスとＵＭＨノードのＩＰｖ６アドレスとの間の事前に記憶された対応に基づいて、ＵＭＨノードの対応するＩＰｖ６アドレスを取得し得る。
ヘッドノードによってテールノードに送信されるルーティングメッセージは、ユニキャストルーティングメッセージであってもよく、またはマルチキャストルーティングメッセージであってもよいことに留意されたい。これは、本出願のこの実施形態では特に限定されない。具体的には、ルーティングメッセージがユニキャストルーティングメッセージである場合、ルーティングメッセージに含まれるマルチキャストソースアドレスは、アドレス範囲またはマルチキャストソースアドレスを含むアドレスプレフィックスであり得る。ユニキャストルーティングメッセージは、ボーダーゲートウェイプロトコルＶＰＮｖ４（ｂｏｒｄｅｒ ｇａｔｅｗａｙ ｐｒｏｔｏｃｏｌ ＶＰＮｖ４、ＢＧＰ－ＶＰＮｖ４）ルーティングメッセージ、ＢＧＰ－ＶＰＮｖ６ルーティングメッセージ、ＢＧＰ－ＥＶＰＮルーティングメッセージ、ＢＧＰ－ＩＰｖ４－ユニキャストルーティングメッセージ、及びＢＧＰ－ＩＰｖ６－ユニキャストルーティングメッセージのいずれか１つであってもよい。ルーティングメッセージがマルチキャストルーティングメッセージである場合、マルチキャストルーティングメッセージは、ＢＧＰ－ＭＶＰＮ包括的プロバイダマルチキャストサービスインターフェースオートディスカバリ（ＩＰＭＳＩ ａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、ＩＰＭＳＩ Ａ－Ｄ）ルーティングメッセージ、ＢＧＰ－ＭＶＰＮ選択的プロバイダマルチキャストサービスインターフェースオートディスカバリ（ｓｅｌｅｃｔｉｖｅ ｐｒｏｖｉｄｅｒ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ ｉｎｔｅｒｆａｃｅ ａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、ＳＰＭＳＩ Ａ－Ｄ）ルーティングメッセージ、またはＢＧＰ－ＥＶＰＮ包括的マルチキャストイーサネットタグ（ｉｎｃｌｕｓｉｖｅ ｍｕｌｔｉｃａｓｔ ｅｔｈｅｒｎｅｔ ｔａｇ、ＩＭＥＴ）ルーティングメッセージであり得る。
ステップ２０３：テールノードは、ＵＭＨノードのＩＰｖ６アドレスに基づいて第１の識別子を取得し、第１の識別子は、ＵＭＨノードのＩＰｖ６アドレスに対応する。
本出願のこの実施形態の一実装では、ＵＭＨノードのＩＰｖ６アドレスを取得した後、テールノードは、ＩＰｖ６アドレスと識別子との間のマッピング関係に基づいて、１２８ビットＩＰｖ６アドレスを１２８ビット未満の第１の識別子にマッピングし得る。本出願のこの実施形態では、ＩＰｖ６アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてもよく、またはテールノードがＵＭＨノードのＩＰｖ６アドレスを決定した後に生成されてもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態のさらに別の実装では、ＵＭＨノードのＩＰｖ６アドレスを決定した後、テールノードは、所定の識別子生成ルールに基づいて第１の識別子を生成し得る。
ステップ２０４：テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に基づいて第１の対応を取得する。
マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子を決定した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間で対応を確立してもよく、言い換えれば、第１の対応を確立してもよい。
本出願のこの実施態様の一実装では、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に加えて、第１の対応は、マルチキャストインスタンスの識別子をさらに含み得る。マルチキャストインスタンスは、テールノードに対応する。言い換えると、マルチキャストインスタンスは、テールノードのマルチキャストインスタンスである。この場合、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得する特定の実装では、テールノードは、マルチキャストインスタンスの識別子をさらに決定し得、次いで、テールノードは、マルチキャストインスタンスの識別子及びマルチキャストソースアドレスを参照してＵＭＨノードのＩＰｖ６アドレスを検索する。具体的には、テールノードは、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含む所定の第３の対応に基づいて、ＵＭＨノードのＩＰｖ６アドレスを決定し得る。対応して、第１の対応を確立するとき、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、第１の識別子、及びマルチキャストインスタンスの識別子の間で第１の対応をさらに確立し得る。
マルチキャストインスタンスの識別子は、本出願のこの実施形態では特に限定されない。ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、ＭＶＰＮインスタンスの識別子であってよく、ＥＶＰＮの場合、マルチキャストインスタンスの識別子は、ＥＶＰＮインスタンスの識別子であってよい。加えて、実際の適用では、ＭＶＰＮの場合、マルチキャストジョインメッセージを受信するインターフェースが属する仮想ルーティング転送（ｖｉｒｔｕａｌ ｒｏｕｔｉｎｇ ｆｏｒｗａｒｄｉｎｇ、ＶＲＦ）の識別子を使用して、マルチキャストインスタンスを識別し得る。したがって、ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、例えば、マルチキャストジョインメッセージを受信するインターフェースが属するＶＲＦの識別子であってもよい。テールノードは、ＢＧＰ ＭＶＰＮアドレスファミリのＣマルチキャストルートを生成し得、Ｃマルチキャストルートは、第１の識別子を搬送する。
本出願のこの実施形態では、カプセル化情報と第２の識別子との間の前述の第２の対応は、事前に生成され、テールノードによって記憶されてもよい。テールノードが第１の対応を生成する具体的な実装は、添付の図面を参照して以下に説明される。
上述のように、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、対応するカプセル化情報は、ＭＰＬＳ Ｐ２ＭＰトンネルラベルを含み得る。マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、対応するカプセル化情報は、テールノードのＢＩＦＴ－ｉｄを含み得る。マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、対応するカプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスを含んでよい。
第２の対応を確立する具体的な実装は、マルチキャストサービスを搬送する３つのトンネルについてそれぞれ以下に説明される。
図４は、本出願の一実施形態による、第２の対応を生成するための方法のシグナリング相互作用図である。
図４に示す方法は、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合に、テールノードが第２の対応を生成するシグナリング相互作用図である。図４に示す方法は、例えば、以下のステップ３０１から３０４を使用して実装してもよい。
ステップ３０１：ヘッドノードは、マルチキャストルーティングメッセージをテールノードに送信し、マルチキャストルーティングメッセージは、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子とを含む。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、およびヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子を搬送する。
ＭＰＬＳ Ｐ２ＭＰトンネルの識別子は、本出願のこの実施形態では特に限定されない。ＭＰＬＳ Ｐ２ＭＰトンネルの識別子は、マルチキャストラベル配布プロトコル（ｍｕｌｔｉｃａｓｔ ｌａｂｅｌ ｄｉｓｔｒｉｂｕｔｉｏｎ ｐｒｏｔｏｃｏｌ、ｍＬＤＰ）転送等価クラス（ｆｏｒｗａｒｄｉｎｇ ｅｑｕａｌ ｃｌａｓｓ、ＦＥＣ）、及びリソース予約プロトコルトラフィックエンジニアリング（ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｐｒｏｔｏｃｏｌ ｔｒａｆｆｉｃ ｅｎｇｉｎｅｅｒｉｎｇ、ＲＳＶＰ－ＴＥ）セッション識別子（Ｓｅｓｓｉｏｎ ＩＤ）を含む。
マルチキャストルーティングメッセージを受信した後、テールノードは、マルチキャストルーティングメッセージを解析して、ヘッドノードのＩＰｖ６アドレス、およびヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子を取得し得る。
ＭＶＰＮについて、マルチキャストルーティング情報は、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報であることを理解することができる。ＥＶＰＮの場合、マルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
ステップ３０２：テールノードは、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得する。
本出願のこの実施形態では、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子を決定した後、テールノードは、第４の対応を参照して、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子に対応するカプセル化情報を決定し得る。第４の対応は、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び対応するカプセル化情報を含み、カプセル化情報は、テールノードによってＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含む。
ステップ３０３：テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。
ステップ３０３の実装は、ステップ２０３のそれと類似することに留意されたい。本出願のこの実施形態の一実装では、ヘッドノードのＩＰｖ６アドレスを取得した後、テールノードは、ＩＰｖ６アドレスと識別子との間のマッピング関係に基づいて、１２８ビットＩＰｖ６アドレスを１２８ビット未満の第２の識別子にマッピングし得る。本出願のこの実施形態では、ＩＰｖ６アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてもよく、またはテールノードがＵＭＨノードのＩＰｖ６アドレスを決定した後に生成されてもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態のさらに別の実装では、ヘッドノードのＩＰｖ６アドレスを決定した後、テールノードは、所定の識別子生成ルールに基づいて第２の識別子を生成し得る。
本明細書では、ＩＰｖ６アドレスと識別子との間のマッピング関係は、ステップ２０３でのＩＰｖ６アドレスと識別子との間のマッピング関係と同じであることを強調するべきである。ＩＰｖ６アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてよい。ＩＰｖ６アドレスと識別子との間のマッピング関係は、テールノードがヘッドノードによって送信されたマルチキャストルーティング情報を受信する前または後に生成されてもよい。ＩＰｖ６アドレスと識別子との間のマッピング関係は、テールノードがＵＭＨノードを決定する前または後に生成されてよい。例えば、テールノードが最初にユーザ機器からマルチキャストジョイン要求を受信し、次いでヘッドノードによって送信されたＭＶＰＮルーティング情報を受信する場合、マッピング関係は、テールノードがユーザ機器からマルチキャストジョイン要求を受信した後に生成されてよい。具体的には、テールノードは、マルチキャストルーティング情報に基づいてＵＭＨノードを決定し、次いでマッピング関係を生成してもよく、またはマッピング関係を生成し、次いでＵＭＨノードを決定してもよい。別の例では、テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信し、次いで、ユーザ機器からマルチキャストジョイン要求を受信する。この場合、マッピング関係は、テールノードがマルチキャストルーティング情報を受信した後に確立されてよい。これは、本出願のこの実施形態では特に限定されない。これに対応して、ここにおける識別子生成ルール及び、ステップ２０３における識別子生成ルールは、同一のルールである。
ステップ３０４：テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
ヘッドノードのＩＰｖ６アドレスに対応する第２の識別子、及びＭＰＬＳ Ｐ２ＭＰトンネルの識別子に対応するカプセル化情報を決定した後、テールノードは、カプセル化情報と第２の識別子との間の第２の対応を確立し、記憶してもよく、それにより、その後にＲＰＦチェックを実行するとき、テールノードは、第２の対応に基づいて第２の識別子を決定する。
図５は、本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。
図５に示す方法は、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合に、テールノードが第２の対応を生成するシグナリング相互作用図である。図５に示す方法は、例えば、以下のステップ４０１から４０４を使用して実装してもよい。
ステップ４０１：ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し、マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス及びＢＩＥＲトンネルの識別子を含む。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、およびヘッドノードとテールノードとの間のＢＩＥＲ－ＭＰＬＳトンネルの識別子を搬送する。
ＢＩＥＲ－ＭＰＬＳトンネルの識別子は、本出願のこの実施形態では特に限定されない。ＢＩＥＲ－ＭＰＬＳトンネルの識別子は、ＢＩＥＲサブドメイン識別子サブドメインＩＤを含む。
マルチキャストルーティングメッセージを受信した後、テールノードは、マルチキャストルーティングメッセージを解析して、ヘッドノードのＩＰｖ６アドレス及びＢＩＥＲトンネルの識別子を取得し得る。
ＭＶＰＮにとって、マルチキャストルーティング情報は、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報であることを理解することができる。ＥＶＰＮの場合、マルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
ステップ４０２：テールノードは、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得する。
本出願のこの実施形態では、ＢＩＥＲトンネルの識別子を決定した後、テールノードは、第５の対応を参照して、ＢＩＥＲトンネルの識別子に対応するカプセル化情報を決定し得る。第５の対応は、ＢＩＥＲトンネルの識別子及び対応するカプセル化情報を含み、カプセル化情報は、テールノードに対応するＢＩＦＴ－ｉｄを含む。
ステップ４０３：テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。
ステップ４０４：テールノードは、カプセル化情報及び第２の識別子に基づいて、第２の対応を取得する。
ステップ４０３及び４０４は、ステップ３０３及び３０４の実装に類似している。具体的な説明については、ステップ３０３及び３０４の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
図６は、本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。
図６に示す方法は、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合に、テールノードが第２の対応を生成するシグナリング相互作用図である。図６に示す方法は、例えば、以下のステップ５０１から５０３を使用して実装してもよい。
ステップ５０１：ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し、マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス及びヘッドノードによって使用されるカプセル化情報を搬送する。カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである。したがって、マルチキャストルーティング情報を受信した後、テールノードは、マルチキャストルーティング情報を解析して、カプセル化情報を取得し得る。
ＭＶＰＮについて、マルチキャストルーティング情報は、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報であることを理解することができる。ＥＶＰＮの場合、マルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
ステップ５０２：テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。
ステップ５０３：テールノードは、カプセル化情報及び第２の識別子に基づいて、第２の対応を取得する。
ステップ５０２及び５０３は、ステップ３０３及び３０４の実装に類似している。具体的な説明については、ステップ３０３及び３０４の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
上記は、マルチキャストサービスを搬送する３つのタイプのトンネルにそれぞれ対応する第２の対応確立方法について説明した。下記は、マルチキャストサービスを搬送する３つのタイプのトンネルについての特定のシナリオを参照して、第２の対応を確立する特定の実装を別途説明する。
第１に、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合の第２の対応を確立する具体的な実装を説明する。
マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、カプセル化情報はＭＰＬＳ Ｐ２ＭＰラベルを含むラベルスタックである。第２の対応は、ＭＰＬＳ＿Ｐ２ＭＰエントリであり、エントリは、（ＭＰＬＳ Ｐ２ＭＰラベル、ＲｏｏｔＩＰｖ６から取得された第２の識別子）として表され得る。ＭＰＬＳ Ｐ２ＭＰラベルはＭＰＬＳ Ｐ２ＭＰトンネルラベルを示し、ＲｏｏｔＩＰｖ６はヘッドノードのＩＰｖ６アドレスを示す。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、マルチキャストラベルディストリビューションプロトコル（ｍｕｌｔｉｃａｓｔＬＤＰ、ｍＬＤＰ） Ｐ２ＭＰトンネル識別子転送等価クラス（ｆｏｒｗａｒｄｉｎｇ ｅｑｕａｌ ｃｌａｓｓ、ＦＥＣ）を適用し、ＦＥＣは、ヘッドノードのＩＰｖ６アドレス１及びトンネルＩＤを含む。様々なトンネルＩＤが、同じノードの様々なｍＬＤＰ Ｐ２ＭＰトンネルに使用される。ヘッドノードは、テールノードへの包括的（包括的ＰＭＳＩ、ＩＰＭＳＩ）ルートを公開する。ルートはＰＭＳＩトンネル属性（ＰＭＳＩ ｔｕｎｎｅｌ ａｔｔｒｉｂｕｔｅ）ＰＴＡを搬送し、ＰＴＡは適用されたＦＥＣを搬送する。ヘッドノードは、ＰＴＡを搬送するＩＰＭＳＩルートを公開し、ＰＴＡは通常、構成によってトリガされる。例えば、送信者有効（ｓｅｎｄｅｒ－ｅｎａｂｌｅ）は、このノードがヘッドノードであることを示すためにヘッドノードに対して構成される。ヘッドノードはＩＰＭＳＩトンネルで構成され、特定のタイプのＩＰＭＳＩトンネルはｍＬＤＰ等である。
ＩＰＭＳＩルーティングメッセージを受信した後、テールノードは、ＦＥＣ情報に基づいてｍＬＤＰ Ｐ２ＭＰトンネルを確立する。具体的には、テールノードは、ラベル、すなわちＭＰＬＳ Ｐ２ＭＰラベルをＦＥＣに割り当て、ＭＰＬＳ Ｐ２ＭＰラベルとヘッドノードのＩＰｖ６アドレス１の第２の識別子、すなわちＭＰＬＳ＿Ｐ２ＭＰエントリとの間の対応を確立する。加えて、テールノードは、ＦＥＣ内のヘッドノードのアドレス情報に基づいて、このアドレスのルートの次のホップを検索し、ネクストホップルータにマッピングメッセージを送信する。マッピングメッセージには、ＦＥＣ及びテールノードによって割り当てられたＭＰＬＳ Ｐ２ＭＰラベルを搬送する。ネクストホップルータは、全体の経路が確立されるまで、ＦＥＣによって識別されるヘッドノードの方向の次のホップにマッピングメッセージを送信し続ける。
以下では、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合に、第２の対応を確立する具体的な実装について説明する。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、カプセル化情報は、ＢＩＥＲ転送ルータヘッドノード識別子及びＢＩＥＲ ＭＰＬＳラベルを含む。ＢＩＥＲ転送ルータヘッドノード識別子は、具体的には、ＢＩＥＲ－ＭＰＬＳヘッダのＢＩＦＴ－ｉｄフィールドに含まれるサブドメイン情報及びＢＦＩＲ－ｉｄフィールドであってもよい。対応して、第２の対応は、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリである。ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリは、（サブドメイン、ＢＦＩＲ－ｉｄ、ＲｏｏｔＩＰｖ６から取得された第２の識別子）として表され得る。エントリは、別のフィールドを有してもよい。例えば、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリは、（サブドメイン、ＢＦＩＲ－ｉｄ、ＶＰＮラベル、ＲｏｏｔＩＰｖ６から取得された第２の識別子、ＶＲＦ）として表され得る。これは、本出願のこの実施形態では特に限定されない。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、ＩＰＭＳＩルートまたは選択的プロバイダマルチキャストサービスインターフェース（Ｓｅｌｅｃｔｉｖｅ Ｐｒｏｖｉｄｅｒ－Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ、ＳＰＭＳＩ）ルート及びＰＴＡをテールノードに送信する。ＩＰＭＳＩまたはＳＰＭＳＩルーティング情報は、ヘッドノードのＩＰｖ６アドレス１を含み、ＰＴＡは、サブドメイン、ＢＦＲ－ｉｄ情報、及びＩＰｖ６ビット転送ルータプレフィックス（ｂｉｔ ｆｏｒｗａｒｄｉｎｇ ｒｏｕｔｅｒ ｐｒｅｆｉｘ、ＢＦＲ－ｐｒｅｆｉｘ）アドレス２を含む。加えて、ＩＰＭＳＩルートはさらに、ルートターゲット（ｒｏｕｔｅ－ｔａｒｇｅｔ，ＲＴ）拡張コミュニティ属性を搬送する。このメッセージを受信した後、テールノードは、ＲＴ拡張コミュニティ属性に基づいてテールノードの対応するＶＲＦを学習し、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリを確立する。ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリは、（サブドメイン、ＢＦＩＲ－ｉｄ、ＶＰＮラベル、ＲｏｏｔＩＰ＜第２の識別子＞、ＶＲＦ）として表される。ＢＦＩＲ－ｉｄは、ヘッドノードからのルーティングメッセージ内のＰＴＡのＢＦＲ－ｉｄである。サブドメイン、ＢＦＩＲ－ｉｄ、及びＶＰＮラベルは、パケットの外部カプセル化から取得され得る情報である。例えば、サブドメインは、パケットのＢＩＥＲヘッダの最初の２０ビットであるＢＩＦＴ－ｉｄフィールドから取得されてもよく、ＢＦＩＲ－ｉｄは、ＢＩＥＲヘッダ内のＢＦＩＲ－ｉｄフィールドから取得され、ＶＰＮラベルは、パケットのＢＩＥＲヘッダの後のラベルから取得される。ＲｏｏｔＩＰｖ６から取得される第２の識別子は、ヘッドノードのＩＰＭＳＩルートのルーティング情報内のＩＰｖ６アドレス１から取得される第２の識別子であり、ＢＦＲプレフィックスアドレスではない。ＲｏｏｔＩＰｖ６アドレスはまた、ＵＭＨルート選択中に選択され得るヘッドノードのアドレスである。
最後に、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合の第２の対応を確立する具体的な実装を説明する。
マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、カプセル化情報は、外部ＩＰｖ６ヘッダ及びＩＰｖ６拡張ヘッダ内に位置するＢＩＥＲヘッダであり、第２の対応はＭＶＰＮ＿ＩＬＭＢＩＥＲｖ６エントリである。ＭＶＰＮ＿ＩＬＭＢＩＥＲｖ６エントリは、（ＭＶＰＮインスタンスを識別するＩＰｖ６アドレス、ＲｏｏｔＩＰｖ６から取得された第２の識別子）として表され得る。エントリは、別のフィールドを有し得、具体的には、（ＭＶＰＮインスタンスを識別するＩＰｖ６アドレス、ＲｏｏｔＩＰｖ６から取得された第２の識別子、ＶＲＦ）として表される。これは、本出願のこの実施形態では特に限定されない。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、ＭＶＰＮインスタンスを識別するために使用されるＩＰＭＳＩまたはＳＰＭＳＩルート、ＰＴＡ属性、及びＩＰｖ６アドレス（プレフィックス－ＳＩＤ属性内）をテールノードに送信する。ＩＰＭＳＩまたはＳＰＭＳＩルーティング情報は、ヘッドノードのＩＰｖ６アドレス１、サブドメインを搬送するＰＴＡ、ＢＦＲ－ｉｄ情報、及びＩＰｖ６ ＢＦＲ－プレフィックスアドレス２を含む。加えて、ルートはさらに、ＲＴ拡張コミュニティ属性及びプレフィックス－ＳＩＤ属性を搬送する。プレフィックス－ＳＩＤ属性は、ＶＰＮインスタンスを識別するＩＰｖ６アドレス３を含む。このメッセージを受信した後、テールノードは、ＲＴ拡張コミュニティ属性に基づいてテールノードの対応するＶＲＦを学習し、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリを確立する。ＭＶＰＮ＿ＩＬＭＢＩＥＲｖ６エントリは、（マルチキャストインスタンスを識別するＩＰｖ６アドレス、ＲｏｏｔＩＰ＜第２の識別子＞、ＶＲＦ）として表され得る。ＭＶＰＮを識別するＩＰｖ６アドレスは、ヘッドノードからのルーティングメッセージ内のプレフィックス－ＳＩＤ属性のＩＰｖ６アドレス３、及びマルチキャストデータパケットのソースアドレス内で搬送されるアドレスである。ＲｏｏｔＩＰｖ６から取得した第２の識別子は、ヘッドノードのＩＰＭＳＩルートのルーティング情報のＩＰｖ６アドレス１に対応する第２の識別子であり、ヘッドノードを表す。例えば、同じ第２の識別子が、複数のＭＶＰＮインスタンスに対して使用されてもよい。第２の識別子はまた、ヘッドノードを識別するために使用され得、ＵＭＨルート選択中に選択される第２の識別子である。
前述の実施形態に提供されるＲＰＦチェック方法に基づいて、本出願の一実施形態は、ＲＰＦチェック装置をさらに提供し、装置は、テールノードに適用されてもよい。図７は、本出願の一実施形態によるＲＰＦチェック装置の構造の概略図である。
図７に示されるＲＰＦチェック装置７００は、前述の実施形態においてテールノードによって実行されるＲＰＦチェック方法を実行するように構成され、具体的には、方法は、図２から図６においてテールノードによって実行されるステップを含んでよい。例えば、ＲＰＦチェック装置７００は、受信ユニット７０１、取得ユニット７０２、及びＲＰＦチェックユニット７０３を含んでもよい。
受信ユニット７０１は、ヘッドノードからマルチキャストデータパケットを受信するように構成される。マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む。
取得ユニット７０２は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得するように構成される。第１の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子を含み、第１の識別子は、マルチキャストデータパケットに対応するアップストリームマルチキャストネクストホップＵＭＨノードを識別するために使用される。
取得ユニット７０２は、カプセル化情報及び第２の対応に基づいて第２の識別子を取得するようにさらに構成される。第２の対応は、カプセル化情報及び第２の識別子を含み、第２の識別子は、ヘッドノードを識別するために使用され、第１の識別子及び第２の識別子はそれぞれ１２８ビット未満である。
ＲＰＦチェックユニット７０３は、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを行うように構成される。
一実装では、受信ユニット７０１は、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成される。マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。
取得ユニット７０２は、さらに、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、ＵＭＨノードのＩＰｖ６アドレスに基づいて第１の識別子を取得し、第１の識別子は、ＵＭＨノードのＩＰｖ６アドレスに対応し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に基づいて第１の対応を取得するように構成される。
一実装では、第１の対応は、マルチキャストインスタンスの識別子をさらに含み、取得ユニット７０２は、
マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、マルチキャストソースアドレス、第３の対応、及びマルチキャストインスタンスの識別子に基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、第３の対応は、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含み、マルチキャストソースアドレス、マルチキャストグループアドレス、マルチキャストインスタンスの識別子、及び第１の識別子に基づいて第１の対応を取得するように特に構成される。
一実装では、マルチキャストインスタンスの識別子は、仮想ルーティング転送ＶＲＦの識別子またはイーサネット仮想プライベートネットワークＥＶＰＮインスタンスの識別子を含む。
一実装では、受信ユニット７０１は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のマルチプロトコルラベルスイッチングＭＰＬＳポイントツーマルチポイントＰ２ＭＰトンネルの識別子を含む。
取得ユニット７０２は、さらに、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得し、第４の対応は、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードによってＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するように構成される。
一実装では、受信ユニット７０１は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のビットインデックス明示的レプリケーションＢＩＥＲトンネルの識別子を含み、ＢＩＥＲトンネルの識別子は、ＢＩＥＲサブドメイン識別子サブドメインＩＤを含む。
取得ユニット７０２は、さらに、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得し、第５の対応は、ＢＩＥＲトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子ＢＩＦＴ－ｉｄを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するように構成される。
一実装では、受信ユニット７０１は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられるＩＰｖ６アドレスである。
取得ユニット７０２は、さらに、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子はヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するように構成される。
一実装では、マルチキャストルーティング情報は、マルチキャスト仮想プライベートネットワークＭＶＰＮルーティング情報またはイーサネット仮想プライベートネットワークＥＶＰＮルーティング情報を含む。
一実装では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値である。
一実装では、第１の識別子及び第２の識別子は、次のアドレス範囲、
０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦまたは０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ
のうちの１つの範囲内にある。
装置７００は、前述の方法の実施形態で提供されるＲＰＦチェック方法に対応する装置であるため、装置７００の各ユニットの具体的な実装は、前述の方法の実施形態のそれと同様の概念を有する。したがって、装置７００の各ユニットの具体的な実装については、前述の方法の実施形態の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
本出願の一実施形態は、ＲＰＦチェックデバイスをさらに提供する。デバイスは、プロセッサ及びメモリを含む。
メモリは、命令を格納するように構成される。
プロセッサは、メモリ内の命令を実行し、前述の方法の実施形態では、テールノードによって実行されるＲＰＦチェック方法を実行するように構成される。
本出願のこの実施形態で提供されるＲＰＦチェックデバイスのハードウェア構造は、図８に示される構造であってもよいことに留意されたい。図８は、本出願の一実施形態によるＲＰＦチェックデバイスの構造の概略図である。
図８を参照されたい。ＲＰＦチェックデバイス８００は、プロセッサ８１０、通信インターフェース８２０、及びメモリ８３０を含む。デバイス８００内に１つまたは複数のプロセッサ８１０が存在し得る。図８において、１つのプロセッサが例として使用される。本出願のこの実施形態では、プロセッサ８１０、通信インターフェース８２０、及びメモリ８３０は、バスシステムを介して、または別の方法で接続されてもよい。図８では、プロセッサ８１０、通信インターフェース８２０、及びメモリ８３０がバスシステム８４０を介して接続される例が使用される。
プロセッサ８１０は、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、ネットワークプロセッサ（ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｏｒ、ＮＰ）、またはＣＰＵ及びＮＰの組み合わせであってもよい。プロセッサ８１０は、ハードウェアチップをさらに含んでもよい。ハードウェアチップは、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）、プログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、またはそれらの組み合わせであり得る。ＰＬＤは、複合プログラム可能論理デバイス（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＣＰＬＤ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、汎用アレイロジック（ｇｅｎｅｒｉｃ ａｒｒａｙ ｌｏｇｉｃ、ＧＡＬ）、またはそれらの任意の組み合わせであり得る。
メモリ８３０は、揮発性メモリ（ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば、ランダムアクセスメモリ（ｒａｎｄｏｍ－ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）を含み得る。メモリ８３０は、あるいは、不揮発性メモリ（ｎｏｎ－ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）、ハードディスクドライブ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ、ＨＤＤ）、またはソリッドステートドライブ（ｓｏｌｉｄ－ｓｔａｔｅ ｄｒｉｖｅ、ＳＳＤ）を含んでもよい。メモリ８３０は、前述のタイプのメモリの組み合わせをさらに含み得る。
メモリ８３０は、前述の実施形態において、第１の対応、第２の対応、第３の対応、第４の対応、及び第５の対応を記憶してもよい。
任意選択で、メモリ８３０は、オペレーティングシステム及びプログラム、実行可能モジュールもしくはデータ構造、またはそのサブセット、またはその拡張セットを格納する。プログラムは、様々な動作を実装するために使用される様々な動作命令を含み得る。オペレーティングシステムは、様々な基本サービスを実装し、ハードウェアベースのタスクを処理するために使用される、様々なシステムプログラムを含み得る。プロセッサ８１０は、本出願の実施形態において提供されるデータ収集方法を実装するために、メモリ８３０内のプログラムを読み取り得る。
バスシステム８４０は、周辺コンポーネント相互接続（ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ、ＰＣＩ）バス、拡張業界標準アーキテクチャ（ｅｘｔｅｎｄｅｄ ｉｎｄｕｓｔｒｙ ｓｔａｎｄａｒｄ ａｒｃｈｉｔｅｃｔｕｒｅ、ＥＩＳＡ）バスなどであってもよい。バスシステム８４０は、アドレスバス、データバス、制御バスなどに分類され得る。表現を容易にするために、図８のバスシステムを表すために、１つの太い線のみが使用されるが、これは、１つのバスのみ、または１つのタイプのバスのみがあることを意味しない。
本出願の実施形態は、命令を含むコンピュータ可読記憶媒体をさらに提供する。命令がコンピュータ上で実行されるとき、コンピュータは、テールノードによって実行され、方法の実施形態で提供されるＲＰＦチェック方法を実行することが可能である。
本出願の実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、テールノードによって実行され、方法の実施形態で提供されるＲＰＦチェック方法を実行することが可能である。
本出願の明細書、特許請求の範囲、及び添付の図面において、用語「第１の」、「第２の」、「第３の」、「第４の」等（存在する場合）は、類似のオブジェクトを区別することを意図しているが、必ずしも特定の順序または配列を示すものではない。このように呼ばれるデータは、本明細書に記載の実施形態が、本明細書に例示または記載される順序とは異なる順序で実施することができるように、適切な状況で交換可能であることを理解されたい。さらに、用語「含む（ｉｎｃｌｕｄｅ）」、「含む（ｃｏｎｔａｉｎ）」、及び任意の他の変形例は、非排他的包含、例えば、ステップまたは単位のリストを含むプロセス、方法、システム、製品、またはデバイスをカバーすることを意味し、これらのステップまたは単位に必ずしも限定されないが、そのようなプロセス、方法、製品、またはデバイスに明示的に列挙されていない、または固有の他のステップまたは単位を含み得る。
便利で簡単な説明の目的で、前述のシステム、装置、及びユニットの詳細な作業プロセスについて、前述の方法の実施形態における対応するプロセスを参照すること、及び詳細については本明細書では再度説明しないことは、当業者によって明確に理解され得る。
本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、及び方法は、他の方法で実施され得ることを理解されたい。例えば、説明した装置の実施形態は単なる例にすぎない。例えば、ユニットへの分割は、単なる論理モジュール分割であり、実際の実装中は他の分割であってもよい。例えば、複数のユニットまたはコンポーネントを組み合わせたり、別のシステムに統合したり、またはいくつかの機能を無視したり、実行しなかったりし得る。さらに、表示または説明されている相互結合または直接結合または通信接続は、いくつかのインターフェースを使用して実装し得る。装置またはユニット間の間接的な結合または通信接続は、電子的、機械的、または他の形態で実装し得る。
別個の部分として説明されるユニットは、物理的に分離されている場合とされていない場合があり、ユニットとして表示される部分は、物理ユニットである場合とそうでない場合があり、１つの位置に配置されている場合と複数のネットワークユニット上に分散されている場合がある。ユニットのいくつかまたはすべては、実施形態の解決策の目的を達成するための実際の要件に基づいて取得され得る。
さらに、本出願の実施形態におけるモジュールユニットは、１つの処理ユニットに統合され得るか、またはユニットのそれぞれが物理的に単独で存在し得るか、または２つ以上のユニットが１つのユニットに統合される。統合されたユニットは、ハードウェアの形で実装されてもよく、ソフトウェアモジュールユニットの形で実装されてもよい。
統合されたユニットがソフトウェアモジュールユニットの形で実装され、独立した製品として販売または使用される場合、統合されたユニットは、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づいて、本出願の実施形態の技術的解決策は基本的に、または先行技術に寄与する部分、または技術的解決策のすべてまたは一部は、ソフトウェア製品の形で実装され得る。コンピュータソフトウェア製品は、記憶媒体に格納され、コンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスであり得る）に、本出願の実施形態で説明された方法のステップのすべてまたはいくつかを実行するように指示するためのいくつかの命令を含む。前述の記憶媒体は、ＵＳＢフラッシュドライブ、リムーバブルハードディスク、読み取り専用メモリ（ＲＯＭ，Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ，Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク、または光ディスクなどの、プログラムコードを格納できる任意の媒体を含む。
当業者は、前述の１つ以上の実施例において、本発明に記載される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせによって実装され得ることを認識すべきである。ソフトウェアが機能を実装するために使用されるとき、機能は、コンピュータ可読媒体に記憶されてもよく、またはコンピュータ可読媒体に１つ以上の命令またはコードとして伝送されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含み、通信媒体は、コンピュータプログラムをある場所から別の場所に伝送することを可能にする任意の媒体を含む。記憶媒体は、汎用コンピュータまたは専用コンピュータにアクセス可能な任意の利用可能な媒体であり得る。
上記の特定の実装では、本発明の目的、技術的解決策、及び有益な効果をさらに詳細に説明する。上記の説明は、本発明の特定の実装に過ぎないことを理解されたい。
結論として、前述の実施形態は、本出願の技術的解決策を説明することのみを意図しており、本出願を限定することを意図していない。本出願は、前述の実施形態を参照して詳細に説明されるが、当業者は、本出願の実施形態の技術的解決策の範囲から逸脱することなく、前述の実施形態に記載された技術的解決策に修正を加え、またはそのいくつかの技術的特徴に等価な置き換えを行ってもよいことを理解すべきである。
本出願は、通信分野に関し、特に、リバースパス転送ＲＰＦチェック方法及び装置に関する。
本出願は、中国特許出願第ＣＮ２０１９１０９００９５４．０は、２０１９年９月２３日に中国国家知的財産管理局に出願され、「リバースパス転送ＲＰＦチェック方法及び装置」と題され、その全体が参照により本明細書に組み込まれる。
現在、仮想プライベートネットワーク（ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ、ＶＰＮ）は、コアネットワーク内にあり、プロバイダによって提供されるネットワークエッジ（ｐｒｏｖｉｄｅｒ ｅｄｇｅ、ＰＥ）ノード上に展開され得る。それに応じて、ＶＰＮインスタンスを使用して、マルチキャストサービスを処理し得る。マルチキャストサービスを使用して、マルチキャストグループ内の１つのＰＥから１つまたは複数の他のＰＥにマルチキャストデータパケットを送信することができる。
実際のアプリケーションでは、マルチキャストデータパケットが１つのＰＥから複数の他のＰＥに送信されるとき、マルチキャストデータパケットを受信するＰＥ、例えば、テールノードは、受信したマルチキャストデータパケットに対してリバースパス転送（ｒｅｖｅｒｓｅ ｐａｔｈ ｆｏｒｗａｒｄｉｎｇ、ＲＰＦ）チェックを実行する必要がある。テールノードは、チェック結果に基づいて、マルチキャストデータパケットを転送するかどうかを決定する。ＲＰＦチェックは、マルチキャストデータパケットが、選択されたアップストリームマルチキャストホップ（ｕｐｓｔｒｅａｍ ｍｕｌｔｉｃａｓｔ ｈｏｐ、ＵＭＨ）ノードから来ているかどうかを決定するためのものである。マルチキャストデータパケットが、選択されたアップストリームマルチキャストホップノードから来る場合、テールノードはマルチキャストデータパケットを転送する；または、マルチキャストデータパケットが、選択されたアップストリームマルチキャストホップノードから来ない場合、テールノードはマルチキャストデータパケットを破棄する。
ＶＰＮが展開されているプロバイダネットワークがインターネットプロトコルバージョン６（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６、ＩＰｖ６）ネットワークである場合、マルチキャストサービスを実装するテールノードによって実行されるＲＰＦチェックは複雑である。
本出願の実施形態は、ＲＰＦチェックを簡素化するためのＲＰＦ方法及び装置を提供する。
第１の態様によれば、本出願の一実施形態は、リバースパス転送チェック方法を提供する。ヘッドノードからマルチキャストデータパケットを受信した後、テールノードは、マルチキャストデータパケットを解析して、マルチキャストソースアドレス、マルチキャストグループアドレス、及びマルチキャストデータパケット内で搬送されるカプセル化情報を取得し得る。マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて、マルチキャストデータパケットに対応するアップストリームマルチキャストホップＵＭＨノードを識別するために使用される第１の識別子を取得し得る。第１の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間のマッピング関係を含む。したがって、マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、第１の対応に基づいて第１の識別子を決定し得る。加えて、テールノードは、マルチキャストデータパケットのカプセル化情報及び第２の対応に基づいて、マルチキャストデータパケットに対応するヘッドノードを識別するために使用される第２の識別子をさらに取得し得る。第１の識別子及び第２の識別子を取得した後、テールノードは、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行し得る。ＩＰｖ６ネットワークにおいて、ノードのアドレスは、１２８ビットを使用して表されることが理解できる。したがって、ＲＰＦチェックを実行するとき、テールノードは２つの１２８ビットデータを比較する必要がある。その結果、ＲＰＦチェックは複雑である。しかしながら、本出願のこの実施形態では、第１の識別子及び第２の識別子のデータ長はそれぞれ１２８ビット未満である。したがって、本出願のこの実施形態では、１２８ビット未満の２つのデータを比較して、ＲＰＦチェックを完了し得る。従来の技術と比較して、本出願のこの実施形態で提供される解決策では、ＲＰＦチェックが簡素化されることを学ぶことができる。
一実施態様では、第１の対応は、事前にテールノードによって生成され得る。具体的には、テールノードは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信し得る。マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。マルチキャストジョインメッセージを受信した後、テールノードは、マルチキャストジョインメッセージを解析して、マルチキャストジョインメッセージ内のマルチキャストソースアドレスを取得し、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得し得る。次いで、テールノードは、ＵＭＨノードのＩＰｖ６アドレスに基づいて、ＵＭＨノードのＩＰｖ６アドレスに対応する第１の識別子を取得し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間の対応を確立し、言い換えれば、第１の対応を確立し、その後のＲＰＦチェックの間の第１の対応に基づいて第１の識別子が決定される。
一実施態様では、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に加えて、第１の対応は、マルチキャストインスタンスの識別子をさらに含み得る。マルチキャストインスタンスは、テールノードに対応する。言い換えると、マルチキャストインスタンスは、テールノードのマルチキャストインスタンスである。この場合、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得する特定の実装では、テールノードは、マルチキャストインスタンスの識別子をさらに決定し得、次いで、テールノードは、マルチキャストインスタンスの識別子及びマルチキャストソースアドレスを参照してＵＭＨノードのＩＰｖ６アドレスを検索する。具体的には、テールノードは、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含む所定の第３の対応に基づいて、ＵＭＨノードのＩＰｖ６アドレスを決定し得る。対応して、第１の対応を確立するとき、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、第１の識別子、及びマルチキャストインスタンスの識別子の間で第１の対応をさらに確立し得る。
一実装では、ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、ＭＶＰＮインスタンスの識別子であってよく、ＥＶＰＮの場合、マルチキャストインスタンスの識別子は、ＥＶＰＮインスタンスの識別子であってよい。加えて、実際の適用では、ＭＶＰＮの場合、マルチキャストジョインメッセージを受信するインターフェースが属するＶＲＦの識別子を使用して、マルチキャストインスタンスを識別し得る。したがって、ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、例えば、マルチキャストジョインメッセージを受信するインターフェースが属するＶＲＦの識別子であってもよい。
一実装では、第２の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、テールノードは、以下の方法で第２の対応を確立してもよい：テールノードは、ヘッドノードによって送信されたマルチキャストルーティングメッセージを受信する。マルチキャストルーティングメッセージは、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子を含む。テールノードは、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得する。テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
一実装では、第２の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがＢＩＥＲトンネルである場合、テールノードは、以下の方法で第２の対応を確立してもよい：テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信する。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス及びＢＩＥＲトンネルの識別子を含む。テールノードは、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得する。テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
一実装では、第２の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、テールノードは、以下の方法で第２の対応を確立してもよい：テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信する。マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含む。カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである。テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
一実装では、ＭＶＰＮの場合、ヘッドノードによってテールノードに送信されたマルチキャストルーティングメッセージは、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報である。ＥＶＰＮの場合、ヘッドノードによってテールノードに送信されたマルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
一実装では、実際の適用では、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表され得、２つの３２ビットデータを比較する複雑さは、通常、テールノードによって許容することができる範囲内にある。したがって、本出願のこの実施形態の一実装では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値であり得る。
一実装では、プロバイダネットワークは、代替的に、ｖ４ｖ６デュアルスタックネットワークであってもよく、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表されてもよいと考えられる。第１の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別し、第２の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別するために、第１の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできず、それに応じて、第２の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできない。現在、０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦの範囲の値は、ＩＰｖ４ネットワーク内のノードのアドレスとして使用されず、０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦの範囲の値は、ＩＰｖ４ネットワークのノードのアドレスとして使用されない。したがって、第１の識別子及び第２の識別子は、範囲０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦ内にあり得るか、または第１の識別子及び第２の識別子は、範囲０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ内にあり得る。
第２の態様によれば、本出願の一実施形態は、ＲＰＦチェック装置を提供する。装置は、マルチキャストデータパケットをヘッドノードから受信するように構成された受信ユニットであって、マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む、受信ユニットと、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得するように構成された取得ユニットであって、第１の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子を含み、第１の識別子は、マルチキャストデータパケットに対応するアップストリームマルチキャストホップＵＭＨノードを識別するために使用され、取得ユニットは、カプセル化情報及び第２の対応に基づいて第２の識別子を取得するようにさらに構成され、第２の対応は、カプセル化情報及び第２の識別子を含み、第２の識別子は、ヘッドノードを識別するために使用され、第１の識別子及び第２の識別子はそれぞれ１２８ビット未満である、取得ユニットと、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行するように構成されたＲＰＦチェックユニットと、を含む。
一実施態様では、受信ユニットは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成され、マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含み、取得ユニットは、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、ＵＭＨノードのＩＰｖ６アドレスに基づいて第１の識別子を取得し、第１の識別子は、ＵＭＨノードのＩＰｖ６アドレスに対応し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に基づいて第１の対応を取得するようにさらに構成される。
一実施態様では、第１の対応は、マルチキャストインスタンスの識別子をさらに含み、取得ユニットは、マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、マルチキャストソースアドレス、第３の対応、及びマルチキャストインスタンスの識別子に基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、第３の対応は、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含み、マルチキャストソースアドレス、マルチキャストグループアドレス、マルチキャストインスタンスの識別子、及び第１の識別子に基づいて第１の対応を取得するように特に構成される。
一実施態様では、マルチキャストインスタンスの識別子は、仮想ルーティング転送ＶＲＦの識別子またはイーサネット仮想プライベートネットワークＥＶＰＮインスタンスの識別子を含む。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のマルチプロトコルラベルスイッチングＭＰＬＳポイントツーマルチポイントＰ２ＭＰトンネルの識別子を含み、取得ユニットは、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得し、第４の対応は、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードによってＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するようにさらに構成される。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のビットインデックス明示的レプリケーションＢＩＥＲトンネルの識別子を含み、ビアトンネルの識別子は、ＢＩＥＲトンネルの識別子は、ＢＩＥＲサブドメイン識別子（ＩＤ）を含み、取得ユニットは、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得し、第５の対応は、ＢＩＥＲトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子ＢＩＦＴ－ｉｄを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するようにさらに構成される。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスであり、取得ユニットは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するようにさらに構成される。
一実施態様では、マルチキャストルーティング情報は、マルチキャスト仮想プライベートネットワークＭＶＰＮルーティング情報またはイーサネット仮想プライベートネットワークＥＶＰＮルーティング情報を含む。
一実施態様では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値である。
一実施態様では、第１の識別子及び第２の識別子は、次のアドレス範囲、０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦまたは０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦのうちの１つの範囲内にある。
第３の態様によれば、本出願の一実施形態は、ＲＰＦチェックデバイスを提供する。デバイスは、プロセッサ及びメモリを含み、メモリは、命令を記憶するように構成され、プロセッサは、第１の態様及び第１の態様の実装のいずれか１つによる方法を実行するために、メモリ内の命令を実行するように構成される。
第４の態様によれば、本出願の一実施形態は、命令を含むコンピュータ可読記憶媒体を提供する。命令がコンピュータ上で実行されるとき、コンピュータは、第１の態様及び第１の態様の実装のいずれか１つによる方法を実行することが可能である。
第５の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第１の態様及び第１の態様の実装のいずれか１つによる方法を実行することが可能である。
本出願の一実施形態によるマルチキャストネットワークの構造の概略図である。 本出願の一実施形態によるＲＰＦチェック方法の概略フローチャートである。 本出願の一実施形態による、第１の対応を生成するための方法のシグナリング相互作用図である。 本出願の一実施形態による、第２の対応を生成するための方法のシグナリング相互作用図である。 本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。 本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。 本出願の一実施形態によるＲＰＦチェック装置の構造の概略図である。 本出願の一実施形態によるＲＰＦチェックデバイスの構造の概略図である。
本出願の実施形態は、ＶＰＮが展開されているプロバイダネットワークが従来技術におけるＩＰｖ６ネットワークである場合に、テールノードによって実行されたＲＰＦチェックが複雑であるという問題を解決するためのＲＰＦチェック方法を提供する。
わかりやすくするために、本出願の実施形態の適用シナリオを最初に説明する。
図１は、本出願の一実施形態によるマルチキャストネットワークの構造の概略図である。
図１に示すように、ＣＥ１、ＣＥ２、及びＣＥ３は、ユーザ機器であってもよい。具体的には、ＣＥ１、ＣＥ２、及びＣＥ３は、ユーザボーダールータであってもよい。ＰＥ１、ＰＥ１ｂ、Ｐ１、Ｐ２、ＰＥ２、ＰＥ３は、プロバイダネットワーク内のデバイスである。ＣＥ１は、マルチキャストソースサーバに、具体的には、マルチキャストデータパケットを送信するソースノードに接続される。ＰＥ１、ＰＥ１ｂ、ＰＥ２、ＰＥ３は、プロバイダネットワーク内のエッジノードである。ＣＥ２及びＣＥ３は、マルチキャスト受信ノードに接続される。マルチキャスト受信ノードは、例えば、パーソナルコンピュータ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ、ＰＣ）またはセットトップボックス（ｓｅｔ ｔｏｐ ｂｏｘ、ＳＴＢ）デバイスであってもよい。ＣＥ２は、ＰＥ２からマルチキャストデータパケットを受信してよく、ＣＥ３は、ＰＥ３からマルチキャストデータパケットを受信してよい。
実際の適用では、ＶＰＮは、プロバイダネットワーク内のエッジノード上に展開され得ることに留意されたい。ＶＰＮインスタンス及びＶＰＮインスタンスが展開されるネットワーク構造に使用されるシグナリングに基づいて、ＶＰＮは、レイヤ３仮想プライベートネットワーク（Ｌａｙｅｒ－３ ＶＰＮ、Ｌ３ＶＰＮ）またはイーサネット仮想プライベートネットワーク（ｅｔｈｅｒｎｅｔ ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ、ＥＶＰＮ）であり得る。Ｌ３ＶＰＮでは、ユニキャストサービスは、ボーダーゲートウェイプロトコル（ｂｏｒｄｅｒ ｇａｔｅｗａｙ ｐｒｏｔｏｃｏｌ、ＢＧＰ）ＶＰＮｖ４シグナリングまたはＶＰＮｖ６シグナリングに基づいて確立されてもよく、もしくはマルチキャストサービス、すなわち、ＭＶＰＮサービスは、ＢＧＰマルチキャスト仮想プライベートネットワーク（ｍｕｌｔｉｃａｓｔ ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ、ＭＶＰＮ）シグナリングに基づいて確立されてもよい。ＥＶＰＮでは、ユニキャストサービスは、ＢＧＰ ＥＶＰＮシグナリングに基づいて確立されてもよく、またはマルチキャストサービス、すなわち、ＥＶＰＮマルチキャストサービスは、ＢＧＰ ＥＶＰＮマルチキャストシグナリングに基づいて確立されてもよい。さらに、マルチキャストサービスは、ＥＶＰＮにおけるＢＧＰ ＭＶＰＮシグナリングに基づいて確立されてもよく、そのようなマルチキャストサービスは、ＭＶＰＮサービスとも呼ばれる。ＭＶＰＮ及びＥＶＰＮにおけるマルチキャストサービスを処理する同じ一般的な手順がある。本出願のこの実施形態における以下の説明では、ＭＶＰＮが、説明のための例として使用される。
プロバイダのＰＥとユーザ機器、すなわちＣＥとの間のマルチキャストサービスがＩＰｖ６マルチキャストである場合、マルチキャストサービスはＩＰｖ６ ＭＶＰＮと呼ばれる。プロバイダのＰＥとユーザ機器、すなわちＣＥとの間のマルチキャストサービスがＩＰｖ４マルチキャストである場合、マルチキャストサービスはＩＰｖ４ ＭＶＰＮと呼ばれる。本出願のこの実施形態では、ＩＰｖ６ ＭＶＰＮとＩＰｖ４ ＭＶＰＮの両方が適用可能であり、ＭＶＰＮと総称される。
プロバイダのＰＥ間の部分は、ＶＰＮバックボーン（ＶＰＮ ｂａｃｋｂｏｎｅ）と呼ばれる。本出願のこの実施形態では、ＶＰＮバックボーンは、ＩＰｖ６シングルプロトコルスタックが動作するネットワーク、またはＩＰｖ４及びＩＰｖ６デュアルスタック（またはｖ４ｖ６デュアルスタック）が動作するネットワークであってもよい。ＭＶＰＮでのマルチキャストルート選択にＩＰｖ６アドレスが使用されることを確認する必要があるだけである。ＩＰｖ６シングルプロトコルスタックまたはｖ４ｖ６デュアルスタックが使用されるかどうかは、本出願のこの実施形態では限定されない。
さらに、ＭＶＰＮシグナリングは、ＶＰＮマルチキャスト及びパブリックネットワークマルチキャストの両方に適用できる。ＶＰＮマルチキャストは、Ｌ３ＶＰＮに基づいて確立されたＶＰＮであっても、ＥＶＰＮに基づいて確立されたＶＰＮであってもよい。本出願のこの実施形態におけるＭＶＰＮは、パブリックネットワークマルチキャストに使用されるＭＶＰＮシグナリング方法と、ＶＰＮマルチキャストに使用されるＭＶＰＮシグナリング方法の両方を含む。これは、本出願のこの実施形態では限定されない。
確かに、プロバイダのＰＥとユーザ機器との間のマルチキャストネットワークは、代替的に、ｖ４ｖ６デュアルスタックネットワークであり得る。言い換えると、ＩＰｖ４ネットワーク及びＩＰｖ６ネットワークの両方がサポートされる。本出願のこの実施形態では、プロバイダのＰＥとユーザ機器との間のネットワークは限定されない。
実際の適用では、包括的プロバイダマルチキャストサービスインターフェース（ｉｎｃｌｕｓｉｖｅ ｐｒｏｖｉｄｅｒ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ ｉｎｔｅｒｆａｃｅ、ＩＰＭＳＩ）トンネルを使用して、ＭＶＰＮ内でマルチキャストサービスを搬送することができる。ＩＰＭＳＩトンネルを使用してマルチキャストサービスを搬送する場合、マルチキャストデータパケットがトンネルを介して伝送される処理において、トンネルタイプに基づいて、マルチキャストソースからのマルチキャストデータパケットに、使用されたトンネルタイプにマッチするカプセル化情報のレイヤを追加してもよい。
ＩＰＭＳＩトンネルは、図１を参照して説明される。ＩＰＭＳＩトンネルは、例えば、ＰＥ１、ＰＥ１ｂ、ＰＥ２、及びＰＥ３の間に確立されたポイントツーマルチプルポイント（ｐｏｉｎｔ－ｔｏ－ｍｕｌｔｉｐｏｉｎｔ、Ｐ２ＭＰ）トンネル、例えば、そのルートノードがＰＥ１であり、リーフノードがＰＥ１ｂ、ＰＥ２、及びＰＥ３であるＰ２ＭＰトンネルであってもよい。Ｐ２ＭＰトンネルは、マルチキャストサービスを搬送するために使用される。例えば、ＰＥ１によって受信されたすべてのマルチキャストデータパケットは、Ｐ２ＭＰトンネルを介してＰＥ２及びＰＥ３に送信されてもよい。確かに、ＩＰＭＳＩトンネルは、代替的に、そのルートノードがＰＥ１ｂであり、リーフノードがＰＥ１、ＰＥ２、及びＰＥ３であるＰ２ＭＰトンネルであり得る。Ｐ２ＭＰトンネルは、マルチキャストサービスを搬送するために使用される。例えば、ＰＥ１ｂによって受信されたすべてのマルチキャストデータパケットは、Ｐ２ＭＰトンネルを介してＰＥ２及びＰＥ３に送信されてもよい。
図１は、わかりやすくするためにのみマルチキャストネットワークを示し、マルチキャストネットワークは、代替的に別の構造であってもよく、トンネルタイプは、Ｐ２ＭＰトンネルに限定されないことに留意されたい。別の構造のマルチキャストネットワークについては、Ｐ２ＭＰトンネルまたはマルチプルポイントツーマルチプルポイント（ｍｕｌｔｉｐｌｅ ｐｏｉｎｔ－ｔｏ－ｍｕｌｔｉｐｏｉｎｔ、ＭＰ２ＭＰ）トンネルは、マルチキャストネットワークの特定の構造に基づいて、複数のＰＥの間に確立され得る。これは、本出願のこの実施形態では特に限定されない。
図１に示すように、ＣＥ１は、ＰＥ１に加えてＰＥ１ｂに接続されている。マルチキャストグループ（Ｓ１、Ｇ１）に対してユーザによって送信されたマルチキャストジョイン要求を受信した後、ＰＥ２は、マルチキャストソースアドレスＳ１のルートの次のホップを検索する。マルチキャストソースアドレスＳ１は、ＣＥ１に接続されているマルチキャストソースサーバのＩＰアドレスまたはＩＰｖ６アドレスである。ＭＶＰＮが適用されるネットワークについて、マルチキャストソースアドレスＳ１のルートであり、ＰＥ２によって見つかるルートは、ＶＰＮプライベートネットワークルートであり得、ルートの次のホップは、ＢＧＰネクストホップである。マルチキャストソースのルートであり、ＭＶＰＮのテールノードから見つかる次のホップは、「ＶＰＮバックボーンを横切る（ａｃｒｏｓｓ ｔｈｅ ＶＰＮ ｂａｃｋｂｏｎｅ）」次のホップであり、ＵＭＨノードとも呼ばれる。
図１に示されるように、ＣＥ１の２つの次のホップが存在してよく、それぞれ、ＰＥ１及びＰＥ１ｂである。対応して、ＰＥ２はまた、クエリを通じて、マルチキャストソースアドレスＳ１へのルートの２つの次のホップを取得し得る。ＰＥ２は、ＢＧＰルート選択ルールに基づいて、Ｓ１に対応するマルチキャストソースのアップストリームマルチキャストホップＵＭＨノードとして、ＰＥ１及びＰＥ１ｂのうちの１つを選択する。このプロセスは、ＵＭＨ選択と呼ばれる。同様に、ＰＥ３は、ＰＥ３のＵＭＨ選択を行う。例えば、ＰＥ２は、Ｓ１に対応するマルチキャストソースのＵＭＨとしてＰＥ１を選択し、ＰＥ３は、Ｓ１に対応するマルチキャストソースのＵＭＨとしてＰＥ１ｂを選択する。図１に示すネットワーク内でマルチキャストサービスが搬送された場合、ＰＥ１は受信したマルチキャストデータパケットをＰＥ２及びＰＥ３に送信する。対応して、ＰＥ１ｂは、受信したマルチキャストデータパケットをＰＥ２及びＰＥ３に送信する。ＣＥ１によって送信された１つのマルチキャストデータパケットについて、ＰＥ２は、マルチキャストデータパケットを繰り返し受信することを理解することができる。例えば、マルチキャストデータパケットは、経路ＣＥ１－＞ＰＥ１－＞Ｐ１－＞ＰＥ２を介してＰＥ２に到達し得、マルチキャストデータパケットは、代替的に経路ＣＥ１－＞ＰＥ１ｂ－＞Ｐ２－＞ＰＥ２を介してＰＥ２に到達し得る。同様に、ＰＥ３は、マルチキャストデータパケットを繰り返し受信する。
この場合、ＰＥ２及びＰＥ３はＲＰＦチェックを行い、ＰＥ２及びＰＥ３は選択したＵＭＨノードからのパケットのみを転送する。例えば、ＰＥ２は、ＰＥ１からのパケットを転送し、ＰＥ１ｂからのパケットを破棄し、ＰＥ３は、ＰＥ１ｂからのパケットを転送し、ＰＥ１からのパケットを破棄する。
従来の技術では、マルチキャストデータパケットを受信した後、テールノード、例えばＰＥ２は、マルチキャストデータパケットに対してＲＰＦチェックを実行してもよく、言い換えれば、マルチキャストデータパケットが、選択されたＵＭＨノードから来るかどうかを決定してもよい。具体的には、プロバイダネットワークがＩＰｖ６ネットワークである場合、ＩＰｖ６ネットワーク内の各ノードのアドレスは、１２８ビットを使用して表される。したがって、ＲＰＦチェックを実行する必要がある場合、テールノードは、ＵＭＨノードの第１のアドレスを取得し、マルチキャストデータパケットのカプセル化情報に基づいてヘッドノードの第２のアドレスを取得し、比較を通じて、第１のアドレスが第２のアドレスと同一であるかどうかを学習して、ＲＰＦチェックを完了し得る。従来の技術では、ＶＰＮが展開されているプロバイダネットワークがＩＰｖ６ネットワークである場合に、ＲＰＦチェックを完了する必要がある場合、２つの１２８ビットＩＰｖ６アドレス（すなわち、第１のアドレス及び第２のアドレス）を比較する必要があることを学ぶことができる。その結果、ＲＰＦチェックは複雑である。加えて、テールノードは、ＵＭＨノードの１２８ビットＩＰｖ６アドレス及びヘッドノードの１２８ビットＩＰｖ６アドレスを格納する必要がある。したがって、対応する記憶量は大きい。
これに鑑み、本出願の一実施形態は、ＶＰＮが展開されているプロバイダネットワークがＩＰｖ６ネットワークである場合のＲＰＦチェックを簡素化するためのＲＰＦチェック方法を提供する。本出願のこの実施形態において提供されるＲＰＦチェック方法を、添付の図面を参照して以下に説明する。
図２は、本出願の一実施形態によるＲＰＦチェック方法の概略フローチャートである。
本出願のこの実施形態において提供されるＲＰＦチェック方法は、ＩＰｖ６ネットワークに適用されてもよい。ＩＰｖ６ネットワークは、ヘッドノード及びテールノードを含む。ヘッドノード及びテールノードはそれぞれ、ＩＰｖ６ネットワーク内のエッジノードである。ヘッドノードは、マルチキャストソースまたはマルチキャストソースに接続されたユーザ機器からマルチキャストデータパケットを受信するノードである。テールノードは、ヘッドノードからマルチキャストデータパケットを受信し、マルチキャストデータパケットをマルチキャストデータパケットの宛先ノードに転送するノードである。例えば、図１のＰＥ１及びＰＥ１ｂは、ヘッドノードであってよく、ＰＥ２及びＰＥ３は、テールノードであってよい。
本出願のこの実施形態において提供されるＲＰＦチェック方法は、例えば、以下のステップ１０１から１０４を使用して実装してもよい。
ステップ１０１：テールノードは、マルチキャストデータパケットをヘッドノードから受信し、マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む。
このステップにおけるマルチキャストデータパケットは、マルチキャストソースによってヘッドノードに送信され、ヘッドノードが対応するカプセル化情報を追加し、テールノードに送信されるパケットである。
上述のように、ＩＰＭＳＩトンネルは、マルチキャストサービスを搬送するために使用され得る。ＩＰＭＳＩトンネルがマルチキャストサービスを搬送するために使用されるとき、マルチキャストデータパケットがトンネルを介して伝送されるプロセスにおいて、ヘッドノードは、使用されたトンネルタイプに基づいて、マルチキャストソースからのマルチキャストデータパケットに、トンネルタイプにマッチするカプセル化情報のレイヤを追加し得る。具体的には、マルチキャストデータパケットを転送する前に、ヘッドノードは、マルチキャストソースからのマルチキャストデータパケットに、ヘッドノードに対応し、使用されたトンネルタイプにマッチするカプセル化情報を追加し得る。例えば、マルチキャストソースノードからマルチキャストデータパケットを受信した後、ヘッドノードは、カプセル化情報をマルチキャストデータパケットの外側カプセル化フィールドに追加し、カプセル化情報が追加されるマルチキャストデータパケットをテールノードに送信し得る。言い換えると、テールノードによって受信されたマルチキャストデータパケットは、カプセル化情報を含むパケットである。
マルチキャストデータパケットを受信した後、テールノードは、対応するユーザ機器にマルチキャストデータパケットを転送するかどうかを決定し得る。本出願のこの実施形態では、マルチキャストデータパケットは、ＩＰｖ４パケットであってもよく、またはＩＰｖ６パケットであってもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態では、マルチキャストデータパケットは、マルチキャストソースアドレス及びマルチキャストグループアドレスを搬送する。マルチキャストソースアドレスは、マルチキャストソースノードのアドレスである。マルチキャストグループアドレスは、マルチキャスト宛先ノードのアドレスである。マルチキャストデータパケットを受信した後、テールノードは、マルチキャストデータパケットを解析して、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を取得し得る。
ステップ１０２：テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得し、第１の識別子は、マルチキャストデータパケットに対応するＵＭＨノードを識別するために使用される。
本出願のこの実施形態では、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間の対応、すなわち第１の対応を予め記憶する。第１の対応は、マルチキャスト転送情報ベース（ｍｕｌｔｉｃａｓｔ ｆｏｒｗａｒｄｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ｂａｓｅ、ＭＦＩＢ）テーブルのエントリに格納され得る。したがって、マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、第１の対応に基づいて、マルチキャストデータパケットに対応するＵＭＨノードを識別するために使用される第１の識別子を決定し得る。
第１の識別子は、マルチキャストデータパケットに対応するＵＭＨノードのアドレスに類似しており、第１の識別子はまた、マルチキャストデータパケットに対応するＵＭＨノードを一意に識別し得ることに留意されたい。しかしながら、ＩＰｖ６ネットワークでは、マルチキャストデータパケットに対応するＵＭＨノードのアドレスは１２８ビットデータである。しかしながら、本出願のこの実施形態では、第１の識別子は、１２８ビット未満である。
ステップ１０３：テールノードは、カプセル化情報及び第２の対応に基づいて、ヘッドノードを識別するために使用される第２の識別子を取得する。
本出願のこの実施形態では、テールノードは、カプセル化情報と第２の識別子との間の対応、すなわち第２の対応を事前に記憶する。第２の識別子は、マルチキャストデータパケットに対応するヘッドノードのアドレスに類似しており、第２の識別子はまた、マルチキャストデータパケットに対応するヘッドノードを一意に識別し得る。しかしながら、ＩＰｖ６ネットワークでは、マルチキャストデータパケットに対応するヘッドノードのアドレスは１２８ビットデータである。しかしながら、本出願のこの実施形態では、第２の識別子は、１２８ビット未満である。
ステップ１０１で説明されるように、マルチキャストデータパケットを受信した後、テールノードは、対応するカプセル化情報を取得するために、マルチキャストデータパケットを解析し得る。解析を通じてカプセル化情報を取得した後、テールノードは、カプセル化情報及び第２の対応に基づいて、ヘッドノードに対応する第２の識別子を決定し得る。第２の対応は、例えば、（ＭＰＬＳ Ｐ２ＭＰラベル＝Ｌｘ、ＲｏｏｔＩＰ＝Ｒｘ）であってもよい。カプセル化情報がＬｘであると決定した後、第２の識別子がＲｘであると決定され得る。
カプセル化情報は、マルチキャストサービスを搬送するトンネルのタイプに関するものであることに留意されたい。本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルのタイプは、ＭＰＬＳ Ｐ２ＭＰトンネルであってもよく、ビットインデックス明示的レプリケーションマルチプロトコルラベルスイッチング（ｂｉｔ ｉｎｄｅｘ ｅｘｐｌｉｃｉｔ ｒｅｐｌｉｃａｔｉｏｎ ＭＰＬＳ、ＢＩＥＲ－ＭＰＬＳ）トンネルであってもよく、またはＢＩＥＲｖ６トンネルであってもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、対応するカプセル化情報は、ＭＰＬＳ Ｐ２ＭＰトンネルラベルを含み得る。マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、対応するカプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子（Ｂｉｔ Ｉｎｄｅｘ Ｆｏｒｗａｒｄｉｎｇ Ｔａｂｌｅ Ｉｄｅｎｔｉｆｉｅｒ、ＢＩＦＴ－ｉｄ）を含んでよい。マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、対応するカプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスを含んでよい。
ステップ１０４：テールノードは、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを実行する。
第１の識別子を決定した後、テールノードはＵＭＨノードを決定し得ることが理解することができる。第２の識別子を決定した後、テールノードは、マルチキャストデータパケットを実際に転送するヘッドノードを決定する。したがって、テールノードは、第１の識別子と第２の識別子とを比較することによってＲＰＦチェックを実行し得る。第１の識別子が第２の識別子に等しい場合、マルチキャストデータパケットがテールノードによって選択されたＵＭＨノードからであることを示し、マルチキャストデータパケットに対して実行されたＲＰＦチェックが成功する。さらに、テールノードは、マルチキャストデータパケットを転送し得る。第１の識別子が第２の識別子と等しくない場合、マルチキャストデータパケットがテールノードによって選択されたＵＭＨノードからではないことを示し、マルチキャストデータパケットに対して実行されたＲＰＦチェックが失敗する。さらに、テールノードは、マルチキャストデータパケットを破棄し得る。
前述の説明から、本出願のこの実施形態において提供される解決策によれば、第１の識別子及び第２の識別子のデータ長はそれぞれ１２８ビット未満であることを学ぶことができる。したがって、本出願のこの実施形態では、１２８ビット未満の２つのデータを比較して、ＲＰＦチェックを完了し得る。本出願のこの実施形態において提供される解決策によれば、テールノードによって実行されるＲＰＦチェックの計算量を減らすことができることを学ぶことができる。
上述のように、第１の識別子及び第２の識別子はそれぞれ、１２８ビット以下の値である。実際の適用では、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表され得、２つの３２ビットデータを比較することの複雑さは、通常、テールノードによって許容することができる範囲内にある。したがって、本出願のこの実施形態の一実装では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値であり得る。マルチキャストネットワークがＩＰｖ６ ＭＶＰＮ（またはＩＰｖ６ ＥＶＰＮ）である場合、各ノードのアドレスが１２８ビットであるため、３２ビットを使用してアドレスが記述されるノードが存在しないことを理解することができる。したがって、この場合、第１の識別子及び第２の識別子はそれぞれ、３２ビット未満の任意の値を使用して表され得る。
上述のように、プロバイダネットワークは、代替的に、ｖ４ｖ６デュアルスタックネットワークであってもよく、ＩＰｖ４ネットワーク内のノードのアドレスは、３２ビットを使用して表されてもよい。この場合、第１の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別し、第２の識別子をＩＰｖ４ネットワーク内のノードのアドレスと区別するために、第１の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできず、それに応じて、第２の識別子の値範囲は、ＩＰｖ４ネットワーク内のノードのアドレス範囲と重複することはできない。現在、範囲０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦ内の値は、ＩＰｖ４ネットワーク内のノードのアドレスとして使用されず、範囲０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ内の値は、ＩＰｖ４ネットワーク内のノードのアドレスとして使用されない。したがって、本出願のこの実施形態の一実装では、第１の識別子及び第２の識別子は、範囲０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦ内にあり得るか、または第１の識別子及び第２の識別子は、範囲０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ内にあり得る。
本出願のこの実施形態では、第１の対応は、事前にテールノードによって生成され得る。テールノードが第１の対応を生成する具体的な実装は、添付の図面を参照して以下に説明される。
図３は、本出願の一実施形態による、第１の対応を生成するための方法のシグナリング相互作用図である。図３の第１の対応を生成する方法は、例えば、以下のステップ２０１から２０４を用いて実装してもよい。
ステップ２０１：カスタマエッジノードは、マルチキャストジョインメッセージをテールノードに送信し、マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。
マルチキャストジョインメッセージは、本出願のこの実施形態では特に限定されず、マルチキャストジョインメッセージは、例えば、プロトコル非依存マルチキャスト（ｐｒｏｔｏｃｏｌ ｉｎｄｅｐｅｎｄｅｎｔ ｍｕｌｔｉｃａｓｔ、ＰＩＭ）メッセージであり得る。
マルチキャストジョインメッセージを受信した後、テールノードは、マルチキャストジョインメッセージを解析して、マルチキャストジョインメッセージ内のマルチキャストソースアドレスを取得し、マルチキャストソースアドレスに基づいて、続いて、ＵＭＨノードのＩＰｖ６アドレスを取得し得る。
ステップ２０２：テールノードは、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得する。
実際の適用では、ヘッドノードは、ルーティングメッセージをテールノードに送信し得る。ルーティングメッセージは、マルチキャストソースアドレス及びＵＭＨノードのＩＰｖ６アドレスを搬送する。ルーティングメッセージを受信した後、テールノードは、マルチキャストソースアドレス、ＵＭＨノードのＩＰｖ６アドレス、及びマルチキャストソースアドレスとＵＭＨノードのＩＰｖ６アドレスとの間の対応を記憶し得る。カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信し、解析を通じて、マルチキャストジョインメッセージ内で搬送されたマルチキャストソースアドレスを取得した後、テールノードは、マルチキャストソースアドレスとＵＭＨノードのＩＰｖ６アドレスとの間の事前に記憶された対応に基づいて、ＵＭＨノードの対応するＩＰｖ６アドレスを取得し得る。
ヘッドノードによってテールノードに送信されるルーティングメッセージは、ユニキャストルーティングメッセージであってもよく、またはマルチキャストルーティングメッセージであってもよいことに留意されたい。これは、本出願のこの実施形態では特に限定されない。具体的には、ルーティングメッセージがユニキャストルーティングメッセージである場合、ルーティングメッセージに含まれるマルチキャストソースアドレスは、アドレス範囲またはマルチキャストソースアドレスを含むアドレスプレフィックスであり得る。ユニキャストルーティングメッセージは、ボーダーゲートウェイプロトコルＶＰＮｖ４（ｂｏｒｄｅｒ ｇａｔｅｗａｙ ｐｒｏｔｏｃｏｌ ＶＰＮｖ４、ＢＧＰ－ＶＰＮｖ４）ルーティングメッセージ、ＢＧＰ－ＶＰＮｖ６ルーティングメッセージ、ＢＧＰ－ＥＶＰＮルーティングメッセージ、ＢＧＰ－ＩＰｖ４－ユニキャストルーティングメッセージ、及びＢＧＰ－ＩＰｖ６－ユニキャストルーティングメッセージのいずれか１つであってもよい。ルーティングメッセージがマルチキャストルーティングメッセージである場合、マルチキャストルーティングメッセージは、ＢＧＰ－ＭＶＰＮ包括的プロバイダマルチキャストサービスインターフェースオートディスカバリ（ＩＰＭＳＩ ａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、ＩＰＭＳＩ Ａ－Ｄ）ルーティングメッセージ、ＢＧＰ－ＭＶＰＮ選択的プロバイダマルチキャストサービスインターフェースオートディスカバリ（ｓｅｌｅｃｔｉｖｅ ｐｒｏｖｉｄｅｒ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ ｉｎｔｅｒｆａｃｅ ａｕｔｏ－ｄｉｓｃｏｖｅｒｙ、ＳＰＭＳＩ Ａ－Ｄ）ルーティングメッセージ、またはＢＧＰ－ＥＶＰＮ包括的マルチキャストイーサネットタグ（ｉｎｃｌｕｓｉｖｅ ｍｕｌｔｉｃａｓｔ ｅｔｈｅｒｎｅｔ ｔａｇ、ＩＭＥＴ）ルーティングメッセージであり得る。
ステップ２０３：テールノードは、ＵＭＨノードのＩＰｖ６アドレスに基づいて第１の識別子を取得し、第１の識別子は、ＵＭＨノードのＩＰｖ６アドレスに対応する。
本出願のこの実施形態の一実装では、ＵＭＨノードのＩＰｖ６アドレスを取得した後、テールノードは、ＩＰｖ６アドレスと識別子との間のマッピング関係に基づいて、１２８ビットＩＰｖ６アドレスを１２８ビット未満の第１の識別子にマッピングし得る。本出願のこの実施形態では、ＩＰｖ６アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてもよく、またはテールノードがＵＭＨノードのＩＰｖ６アドレスを決定した後に生成されてもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態のさらに別の実装では、ＵＭＨノードのＩＰｖ６アドレスを決定した後、テールノードは、所定の識別子生成ルールに基づいて第１の識別子を生成し得る。
ステップ２０４：テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に基づいて第１の対応を取得する。
マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子を決定した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子の間で対応を確立してもよく、言い換えれば、第１の対応を確立してもよい。
本出願のこの実施態様の一実装では、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に加えて、第１の対応は、マルチキャストインスタンスの識別子をさらに含み得る。マルチキャストインスタンスは、テールノードに対応する。言い換えると、マルチキャストインスタンスは、テールノードのマルチキャストインスタンスである。この場合、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得する特定の実装では、テールノードは、マルチキャストインスタンスの識別子をさらに決定し得、次いで、テールノードは、マルチキャストインスタンスの識別子及びマルチキャストソースアドレスを参照してＵＭＨノードのＩＰｖ６アドレスを検索する。具体的には、テールノードは、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含む所定の第３の対応に基づいて、ＵＭＨノードのＩＰｖ６アドレスを決定し得る。対応して、第１の対応を確立するとき、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、第１の識別子、及びマルチキャストインスタンスの識別子の間で第１の対応をさらに確立し得る。
マルチキャストインスタンスの識別子は、本出願のこの実施形態では特に限定されない。ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、ＭＶＰＮインスタンスの識別子であってよく、ＥＶＰＮの場合、マルチキャストインスタンスの識別子は、ＥＶＰＮインスタンスの識別子であってよい。加えて、実際の適用では、ＭＶＰＮの場合、マルチキャストジョインメッセージを受信するインターフェースが属する仮想ルーティング転送（ｖｉｒｔｕａｌ ｒｏｕｔｉｎｇ ｆｏｒｗａｒｄｉｎｇ、ＶＲＦ）の識別子を使用して、マルチキャストインスタンスを識別し得る。したがって、ＭＶＰＮの場合、マルチキャストインスタンスの識別子は、例えば、マルチキャストジョインメッセージを受信するインターフェースが属するＶＲＦの識別子であってもよい。テールノードは、ＢＧＰ ＭＶＰＮアドレスファミリのＣマルチキャストルートを生成し得、Ｃマルチキャストルートは、第１の識別子を搬送する。
本出願のこの実施形態では、カプセル化情報と第２の識別子との間の前述の第２の対応は、事前に生成され、テールノードによって記憶されてもよい。テールノードが第１の対応を生成する具体的な実装は、添付の図面を参照して以下に説明される。
上述のように、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、対応するカプセル化情報は、ＭＰＬＳ Ｐ２ＭＰトンネルラベルを含み得る。マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、対応するカプセル化情報は、テールノードのＢＩＦＴ－ｉｄを含み得る。マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、対応するカプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスを含んでよい。
第２の対応を確立する具体的な実装は、マルチキャストサービスを搬送する３つのトンネルについてそれぞれ以下に説明される。
図４は、本出願の一実施形態による、第２の対応を生成するための方法のシグナリング相互作用図である。
図４に示す方法は、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合に、テールノードが第２の対応を生成するシグナリング相互作用図である。図４に示す方法は、例えば、以下のステップ３０１から３０４を使用して実装してもよい。
ステップ３０１：ヘッドノードは、マルチキャストルーティングメッセージをテールノードに送信し、マルチキャストルーティングメッセージは、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子とを含む。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、およびヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子を搬送する。
ＭＰＬＳ Ｐ２ＭＰトンネルの識別子は、本出願のこの実施形態では特に限定されない。ＭＰＬＳ Ｐ２ＭＰトンネルの識別子は、マルチキャストラベル配布プロトコル（ｍｕｌｔｉｃａｓｔ ｌａｂｅｌ ｄｉｓｔｒｉｂｕｔｉｏｎ ｐｒｏｔｏｃｏｌ、ｍＬＤＰ）転送等価クラス（ｆｏｒｗａｒｄｉｎｇ ｅｑｕｉｖａｌｅｎｃｅ ｃｌａｓｓ、ＦＥＣ）、及びリソース予約プロトコルトラフィックエンジニアリング（ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｐｒｏｔｏｃｏｌ ｔｒａｆｆｉｃ ｅｎｇｉｎｅｅｒｉｎｇ、ＲＳＶＰ－ＴＥ）セッション識別子（Ｓｅｓｓｉｏｎ ＩＤ）を含む。
マルチキャストルーティングメッセージを受信した後、テールノードは、マルチキャストルーティングメッセージを解析して、ヘッドノードのＩＰｖ６アドレス、およびヘッドノードとテールノードとの間のＭＰＬＳ Ｐ２ＭＰトンネルの識別子を取得し得る。
ＭＶＰＮについて、マルチキャストルーティング情報は、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報であることを理解することができる。ＥＶＰＮの場合、マルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
ステップ３０２：テールノードは、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得する。
本出願のこの実施形態では、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子を決定した後、テールノードは、第４の対応を参照して、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子に対応するカプセル化情報を決定し得る。第４の対応は、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び対応するカプセル化情報を含み、カプセル化情報は、テールノードによってＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含む。
ステップ３０３：テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。
ステップ３０３の実装は、ステップ２０３のそれと類似することに留意されたい。本出願のこの実施形態の一実装では、ヘッドノードのＩＰｖ６アドレスを取得した後、テールノードは、ＩＰｖ６アドレスと識別子との間のマッピング関係に基づいて、１２８ビットＩＰｖ６アドレスを１２８ビット未満の第２の識別子にマッピングし得る。本出願のこの実施形態では、ＩＰｖ６アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてもよく、またはテールノードがＵＭＨノードのＩＰｖ６アドレスを決定した後に生成されてもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態のさらに別の実装では、ヘッドノードのＩＰｖ６アドレスを決定した後、テールノードは、所定の識別子生成ルールに基づいて第２の識別子を生成し得る。
本明細書では、ＩＰｖ６アドレスと識別子との間のマッピング関係は、ステップ２０３でのＩＰｖ６アドレスと識別子との間のマッピング関係と同じであることを強調するべきである。ＩＰｖ６アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてよい。ＩＰｖ６アドレスと識別子との間のマッピング関係は、テールノードがヘッドノードによって送信されたマルチキャストルーティング情報を受信する前または後に生成されてもよい。ＩＰｖ６アドレスと識別子との間のマッピング関係は、テールノードがＵＭＨノードを決定する前または後に生成されてよい。例えば、テールノードが最初にユーザ機器からマルチキャストジョイン要求を受信し、次いでヘッドノードによって送信されたＭＶＰＮルーティング情報を受信する場合、マッピング関係は、テールノードがユーザ機器からマルチキャストジョイン要求を受信した後に生成されてよい。具体的には、テールノードは、マルチキャストルーティング情報に基づいてＵＭＨノードを決定し、次いでマッピング関係を生成してもよく、またはマッピング関係を生成し、次いでＵＭＨノードを決定してもよい。別の例では、テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信し、次いで、ユーザ機器からマルチキャストジョイン要求を受信する。この場合、マッピング関係は、テールノードがマルチキャストルーティング情報を受信した後に確立されてよい。これは、本出願のこの実施形態では特に限定されない。これに対応して、ここにおける識別子生成ルール及び、ステップ２０３における識別子生成ルールは、同一のルールである。
ステップ３０４：テールノードは、カプセル化情報及び第２の識別子に基づいて第２の対応を取得する。
ヘッドノードのＩＰｖ６アドレスに対応する第２の識別子、及びＭＰＬＳ Ｐ２ＭＰトンネルの識別子に対応するカプセル化情報を決定した後、テールノードは、カプセル化情報と第２の識別子との間の第２の対応を確立し、記憶してもよく、それにより、その後にＲＰＦチェックを実行するとき、テールノードは、第２の対応に基づいて第２の識別子を決定する。
図５は、本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。
図５に示す方法は、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合に、テールノードが第２の対応を生成するシグナリング相互作用図である。図５に示す方法は、例えば、以下のステップ４０１から４０４を使用して実装してもよい。
ステップ４０１：ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し、マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス及びＢＩＥＲトンネルの識別子を含む。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、およびヘッドノードとテールノードとの間のＢＩＥＲ－ＭＰＬＳトンネルの識別子を搬送する。
ＢＩＥＲ－ＭＰＬＳトンネルの識別子は、本出願のこの実施形態では特に限定されない。ＢＩＥＲ－ＭＰＬＳトンネルの識別子は、ＢＩＥＲサブドメイン識別子（ＩＤ）を含む。
マルチキャストルーティングメッセージを受信した後、テールノードは、マルチキャストルーティングメッセージを解析して、ヘッドノードのＩＰｖ６アドレス及びＢＩＥＲトンネルの識別子を取得し得る。
ＭＶＰＮにとって、マルチキャストルーティング情報は、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報であることを理解することができる。ＥＶＰＮの場合、マルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
ステップ４０２：テールノードは、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得する。
本出願のこの実施形態では、ＢＩＥＲトンネルの識別子を決定した後、テールノードは、第５の対応を参照して、ＢＩＥＲトンネルの識別子に対応するカプセル化情報を決定し得る。第５の対応は、ＢＩＥＲトンネルの識別子及び対応するカプセル化情報を含み、カプセル化情報は、テールノードに対応するＢＩＦＴ－ｉｄを含む。
ステップ４０３：テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。
ステップ４０４：テールノードは、カプセル化情報及び第２の識別子に基づいて、第２の対応を取得する。
ステップ４０３及び４０４は、ステップ３０３及び３０４の実装に類似している。具体的な説明については、ステップ３０３及び３０４の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
図６は、本出願の一実施形態による、第２の対応を生成するための別の方法のシグナリング相互作用図である。
図６に示す方法は、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合に、テールノードが第２の対応を生成するシグナリング相互作用図である。図６に示す方法は、例えば、以下のステップ５０１から５０３を使用して実装してもよい。
ステップ５０１：ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し、マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス及びヘッドノードによって使用されるカプセル化情報を搬送する。カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである。したがって、マルチキャストルーティング情報を受信した後、テールノードは、マルチキャストルーティング情報を解析して、カプセル化情報を取得し得る。
ＭＶＰＮについて、マルチキャストルーティング情報は、ＭＶＰＮルーティング情報、例えば、ＢＧＰ ＭＶＰＮアドレスファミリルーティング情報であることを理解することができる。ＥＶＰＮの場合、マルチキャストルーティング情報は、ＥＶＰＮルーティング情報、例えば、ＢＧＰ ＥＶＰＮアドレスファミリルーティング情報である。
ステップ５０２：テールノードは、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応する。
ステップ５０３：テールノードは、カプセル化情報及び第２の識別子に基づいて、第２の対応を取得する。
ステップ５０２及び５０３は、ステップ３０３及び３０４の実装に類似している。具体的な説明については、ステップ３０３及び３０４の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
上記は、マルチキャストサービスを搬送する３つのタイプのトンネルにそれぞれ対応する第２の対応確立方法について説明した。下記は、マルチキャストサービスを搬送する３つのタイプのトンネルについての特定のシナリオを参照して、第２の対応を確立する特定の実装を別途説明する。
第１に、マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合の第２の対応を確立する具体的な実装を説明する。
マルチキャストサービスを搬送するトンネルがＭＰＬＳ Ｐ２ＭＰトンネルである場合、カプセル化情報はＭＰＬＳ Ｐ２ＭＰラベルを含むラベルスタックである。第２の対応は、ＭＰＬＳ＿Ｐ２ＭＰエントリであり、エントリは、（ＭＰＬＳ Ｐ２ＭＰラベル、ＲｏｏｔＩＰｖ６から取得された第２の識別子）として表され得る。ＭＰＬＳ Ｐ２ＭＰラベルはＭＰＬＳ Ｐ２ＭＰトンネルラベルを示し、ＲｏｏｔＩＰｖ６はヘッドノードのＩＰｖ６アドレスを示す。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、マルチキャストラベルディストリビューションプロトコル（ｍｕｌｔｉｃａｓｔＬＤＰ、ｍＬＤＰ） Ｐ２ＭＰトンネル識別子転送等価クラス（ｆｏｒｗａｒｄｉｎｇ ｅｑｕｉｖａｌｅｎｃｅ ｃｌａｓｓ、ＦＥＣ）を適用し、ＦＥＣは、ヘッドノードのＩＰｖ６アドレス１及びトンネルＩＤを含む。様々なトンネルＩＤが、同じノードの様々なｍＬＤＰ Ｐ２ＭＰトンネルに使用される。ヘッドノードは、テールノードへの包括的プロバイダマルチキャストサービスインターフェース（包括的ＰＭＳＩ、ＩＰＭＳＩ）ルートを公開する。ルートはＰＭＳＩトンネル属性（ＰＭＳＩ ｔｕｎｎｅｌ ａｔｔｒｉｂｕｔｅ、ＰＴＡ）を搬送し、ＰＴＡは適用されたＦＥＣを搬送する。ヘッドノードは、ＰＴＡを搬送するＩＰＭＳＩルートを公開し、ＰＴＡは通常、構成によってトリガされる。例えば、送信者有効（ｓｅｎｄｅｒ－ｅｎａｂｌｅ）は、このノードがヘッドノードであることを示すためにヘッドノードに対して構成される。ヘッドノードはＩＰＭＳＩトンネルで構成され、特定のタイプのＩＰＭＳＩトンネルはｍＬＤＰ等である。
ＩＰＭＳＩルーティングメッセージを受信した後、テールノードは、ＦＥＣ情報に基づいてｍＬＤＰ Ｐ２ＭＰトンネルを確立する。具体的には、テールノードは、ラベル、すなわちＭＰＬＳ Ｐ２ＭＰラベルをＦＥＣに割り当て、ＭＰＬＳ Ｐ２ＭＰラベルとヘッドノードのＩＰｖ６アドレス１の第２の識別子、すなわちＭＰＬＳ＿Ｐ２ＭＰエントリとの間の対応を確立する。加えて、テールノードは、ＦＥＣ内のヘッドノードのアドレス情報に基づいて、このアドレスのルートの次のホップを検索し、ネクストホップルータにマッピングメッセージを送信する。マッピングメッセージには、ＦＥＣ及びテールノードによって割り当てられたＭＰＬＳ Ｐ２ＭＰラベルを搬送する。ネクストホップルータは、全体の経路が確立されるまで、ＦＥＣによって識別されるヘッドノードの方向の次のホップにマッピングメッセージを送信し続ける。
以下では、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合に、第２の対応を確立する具体的な実装について説明する。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがＢＩＥＲ－ＭＰＬＳトンネルである場合、カプセル化情報は、ＢＩＥＲ転送ルータヘッドノード識別子及びＢＩＥＲ ＭＰＬＳラベルを含む。ＢＩＥＲ転送ルータヘッドノード識別子は、具体的には、ＢＩＥＲ－ＭＰＬＳヘッダのＢＩＦＴ－ｉｄフィールドに含まれるサブドメイン情報及びＢＦＩＲ－ｉｄフィールドであってもよい。対応して、第２の対応は、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリである。ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリは、（サブドメイン、ＢＦＩＲ－ｉｄ、ＲｏｏｔＩＰｖ６から取得された第２の識別子）として表され得る。エントリは、別のフィールドを有してもよい。例えば、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリは、（サブドメイン、ＢＦＩＲ－ｉｄ、ＶＰＮラベル、ＲｏｏｔＩＰｖ６から取得された第２の識別子、ＶＲＦ）として表され得る。これは、本出願のこの実施形態では特に限定されない。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、ＩＰＭＳＩルートまたは選択的プロバイダマルチキャストサービスインターフェース（Ｓｅｌｅｃｔｉｖｅ Ｐｒｏｖｉｄｅｒ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ、ＳＰＭＳＩ）ルート及びＰＴＡをテールノードに送信する。ＩＰＭＳＩまたはＳＰＭＳＩルーティング情報は、ヘッドノードのＩＰｖ６アドレス１を含み、ＰＴＡは、サブドメイン、ＢＦＲ－ｉｄ情報、及びＩＰｖ６ビット転送ルータプレフィックス（ｂｉｔ ｆｏｒｗａｒｄｉｎｇ ｒｏｕｔｅｒ ｐｒｅｆｉｘ、ＢＦＲ－ｐｒｅｆｉｘ）アドレス２を含む。加えて、ＩＰＭＳＩルートはさらに、ルートターゲット（ｒｏｕｔｅ ｔａｒｇｅｔ，ＲＴ）拡張コミュニティ属性を搬送する。ＩＰＭＳＩルートまたは選択的プロバイダマルチキャストサービスインターフェースルート及びＰＴＡを受信した後、テールノードは、ＲＴ拡張コミュニティ属性に基づいてテールノードの対応するＶＲＦを学習し、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリを確立する。ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリは、（サブドメイン、ＢＦＩＲ－ｉｄ、ＶＰＮラベル、ＲｏｏｔＩＰ＜第２の識別子＞、ＶＲＦ）として表される。ＢＦＩＲ－ｉｄは、ヘッドノードからのルーティングメッセージ内のＰＴＡのＢＦＲ－ｉｄである。サブドメイン、ＢＦＩＲ－ｉｄ、及びＶＰＮラベルは、パケットの外部カプセル化から取得され得る情報である。例えば、サブドメインは、パケットのＢＩＥＲヘッダの最初の２０ビットであるＢＩＦＴ－ｉｄフィールドから取得されてもよく、ＢＦＩＲ－ｉｄは、ＢＩＥＲヘッダ内のＢＦＩＲ－ｉｄフィールドから取得され、ＶＰＮラベルは、パケットのＢＩＥＲヘッダの後のラベルから取得される。ＲｏｏｔＩＰｖ６から取得される第２の識別子は、ヘッドノードのＩＰＭＳＩルートのルーティング情報内のＩＰｖ６アドレス１から取得される第２の識別子であり、ＢＦＲプレフィックスアドレスではない。ＲｏｏｔＩＰｖ６アドレスはまた、ＵＭＨルート選択中に選択され得るヘッドノードのアドレスである。
最後に、マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合の第２の対応を確立する具体的な実装を説明する。
マルチキャストサービスを搬送するトンネルがＢＩＥＲｖ６トンネルである場合、カプセル化情報は、外部ＩＰｖ６ヘッダ及びＩＰｖ６拡張ヘッダ内に位置するＢＩＥＲヘッダであり、第２の対応はＭＶＰＮ＿ＩＬＭＢＩＥＲｖ６エントリである。ＭＶＰＮ＿ＩＬＭＢＩＥＲｖ６エントリは、（ＭＶＰＮインスタンスを識別するＩＰｖ６アドレス、ＲｏｏｔＩＰｖ６から取得された第２の識別子）として表され得る。エントリは、別のフィールドを有し得、具体的には、（ＭＶＰＮインスタンスを識別するＩＰｖ６アドレス、ＲｏｏｔＩＰｖ６から取得された第２の識別子、ＶＲＦ）として表される。これは、本出願のこの実施形態では特に限定されない。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、ＭＶＰＮインスタンスを識別するために使用されるＩＰＭＳＩまたはＳＰＭＳＩルート、ＰＴＡ属性、及びＩＰｖ６アドレス（プレフィックス－ＳＩＤ属性内）をテールノードに送信する。ＩＰＭＳＩまたはＳＰＭＳＩルーティング情報は、ヘッドノードのＩＰｖ６アドレス１、サブドメインを搬送するＰＴＡ、ＢＦＲ－ｉｄ情報、及びＩＰｖ６ ＢＦＲ－プレフィックスアドレス２を含む。加えて、ルートはさらに、ＲＴ拡張コミュニティ属性及びプレフィックス－ＳＩＤ属性を搬送する。プレフィックス－ＳＩＤ属性は、ＶＰＮインスタンスを識別するＩＰｖ６アドレス３を含む。ＩＰＭＳまたはＳＰＭＳＩルート、ＰＴＡ属性、及びＩＰｖ６アドレスを受信した後、テールノードは、ＲＴ拡張コミュニティ属性に基づいてテールノードの対応するＶＲＦを学習し、ＭＶＰＮ＿ＩＬＭＢＩＥＲエントリを確立する。ＭＶＰＮ＿ＩＬＭＢＩＥＲｖ６エントリは、（マルチキャストインスタンスを識別するＩＰｖ６アドレス、ＲｏｏｔＩＰ＜第２の識別子＞、ＶＲＦ）として表され得る。ＭＶＰＮを識別するＩＰｖ６アドレスは、ヘッドノードからのルーティングメッセージ内のプレフィックス－ＳＩＤ属性のＩＰｖ６アドレス３、及びマルチキャストデータパケットのソースアドレス内で搬送されるアドレスである。ＲｏｏｔＩＰｖ６から取得した第２の識別子は、ヘッドノードのＩＰＭＳＩルートのルーティング情報のＩＰｖ６アドレス１に対応する第２の識別子であり、ヘッドノードを表す。例えば、同じ第２の識別子が、複数のＭＶＰＮインスタンスに対して使用されてもよい。第２の識別子はまた、ヘッドノードを識別するために使用され得、ＵＭＨルート選択中に選択される第２の識別子である。
前述の実施形態に提供されるＲＰＦチェック方法に基づいて、本出願の一実施形態は、ＲＰＦチェック装置をさらに提供し、装置は、テールノードに適用されてもよい。図７は、本出願の一実施形態によるＲＰＦチェック装置の構造の概略図である。
図７に示されるＲＰＦチェック装置７００は、前述の実施形態においてテールノードによって実行されるＲＰＦチェック方法を実行するように構成され、具体的には、方法は、図２から図６においてテールノードによって実行されるステップを含んでよい。例えば、ＲＰＦチェック装置７００は、受信ユニット７０１、取得ユニット７０２、及びＲＰＦチェックユニット７０３を含んでもよい。
受信ユニット７０１は、ヘッドノードからマルチキャストデータパケットを受信するように構成される。マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む。
取得ユニット７０２は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得するように構成される。第１の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子を含み、第１の識別子は、マルチキャストデータパケットに対応するアップストリームマルチキャストホップＵＭＨノードを識別するために使用される。
取得ユニット７０２は、カプセル化情報及び第２の対応に基づいて第２の識別子を取得するようにさらに構成される。第２の対応は、カプセル化情報及び第２の識別子を含み、第２の識別子は、ヘッドノードを識別するために使用され、第１の識別子及び第２の識別子はそれぞれ１２８ビット未満である。
ＲＰＦチェックユニット７０３は、第１の識別子及び第２の識別子に基づいてＲＰＦチェックを行うように構成される。
一実装では、受信ユニット７０１は、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成される。マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。
取得ユニット７０２は、さらに、マルチキャストソースアドレスに基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、ＵＭＨノードのＩＰｖ６アドレスに基づいて第１の識別子を取得し、第１の識別子は、ＵＭＨノードのＩＰｖ６アドレスに対応し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第１の識別子に基づいて第１の対応を取得するように構成される。
一実装では、第１の対応は、マルチキャストインスタンスの識別子をさらに含み、取得ユニット７０２は、
マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、マルチキャストソースアドレス、第３の対応、及びマルチキャストインスタンスの識別子に基づいてＵＭＨノードのＩＰｖ６アドレスを取得し、第３の対応は、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びＵＭＨノードのＩＰｖ６アドレスを含み、マルチキャストソースアドレス、マルチキャストグループアドレス、マルチキャストインスタンスの識別子、及び第１の識別子に基づいて第１の対応を取得するように特に構成される。
一実装では、マルチキャストインスタンスの識別子は、仮想ルーティング転送ＶＲＦの識別子またはイーサネット仮想プライベートネットワークＥＶＰＮインスタンスの識別子を含む。
一実装では、受信ユニット７０１は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のマルチプロトコルラベルスイッチングＭＰＬＳポイントツーマルチポイントＰ２ＭＰトンネルの識別子を含む。
取得ユニット７０２は、さらに、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得し、第４の対応は、ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードによってＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するように構成される。
一実装では、受信ユニット７０１は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、ヘッドノードのＩＰｖ６アドレス、及びヘッドノードとテールノードとの間のビットインデックス明示的レプリケーションＢＩＥＲトンネルの識別子を含み、ＢＩＥＲトンネルの識別子は、ＢＩＥＲサブドメイン識別子（ＩＤ）を含む。
取得ユニット７０２は、さらに、ＢＩＥＲトンネルの識別子及び第５の対応に基づいてカプセル化情報を取得し、第５の対応は、ＢＩＥＲトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子ＢＩＦＴ－ｉｄを含み、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子は、ヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するように構成される。
一実装では、受信ユニット７０１は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのＩＰｖ６アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられるＩＰｖ６アドレスである。
取得ユニット７０２は、さらに、ヘッドノードのＩＰｖ６アドレスに基づいて第２の識別子を取得し、第２の識別子はヘッドノードのＩＰｖ６アドレスに対応し、カプセル化情報及び第２の識別子に基づいて第２の対応を取得するように構成される。
一実装では、マルチキャストルーティング情報は、マルチキャスト仮想プライベートネットワークＭＶＰＮルーティング情報またはイーサネット仮想プライベートネットワークＥＶＰＮルーティング情報を含む。
一実装では、第１の識別子及び第２の識別子はそれぞれ、３２ビット以下の値である。
一実装では、第１の識別子及び第２の識別子は、次のアドレス範囲、
０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦまたは０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ
のうちの１つの範囲内にある。
装置７００は、前述の方法の実施形態で提供されるＲＰＦチェック方法に対応する装置であるため、装置７００の各ユニットの具体的な実装は、前述の方法の実施形態のそれと同様の概念を有する。したがって、装置７００の各ユニットの具体的な実装については、前述の方法の実施形態の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
本出願の一実施形態は、ＲＰＦチェックデバイスをさらに提供する。デバイスは、プロセッサ及びメモリを含む。
メモリは、命令を格納するように構成される。
プロセッサは、メモリ内の命令を実行し、前述の方法の実施形態では、テールノードによって実行されるＲＰＦチェック方法を実行するように構成される。
本出願のこの実施形態で提供されるＲＰＦチェックデバイスのハードウェア構造は、図８に示される構造であってもよいことに留意されたい。図８は、本出願の一実施形態によるＲＰＦチェックデバイス８００の構造の概略図である。
図８を参照されたい。ＲＰＦチェックデバイス８００は、プロセッサ８１０、通信インターフェース８２０、及びメモリ８３０を含む。デバイス８００内に１つまたは複数のプロセッサ８１０が存在し得る。図８において、１つのプロセッサが例として使用される。本出願のこの実施形態では、プロセッサ８１０、通信インターフェース８２０、及びメモリ８３０は、バスシステムを介して、または別の方法で接続されてもよい。図８では、プロセッサ８１０、通信インターフェース８２０、及びメモリ８３０がバスシステム８４０を介して接続される例が使用される。
プロセッサ８１０は、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、ネットワークプロセッサ（ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｏｒ、ＮＰ）、またはＣＰＵ及びＮＰの組み合わせであってもよい。プロセッサ８１０は、ハードウェアチップをさらに含んでもよい。ハードウェアチップは、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）、プログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、またはそれらの組み合わせであり得る。ＰＬＤは、複合プログラム可能論理デバイス（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＣＰＬＤ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、汎用アレイロジック（ｇｅｎｅｒｉｃ ａｒｒａｙ ｌｏｇｉｃ、ＧＡＬ）、またはそれらの任意の組み合わせであり得る。
メモリ８３０は、揮発性メモリ（ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば、ランダムアクセスメモリ（ｒａｎｄｏｍ－ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）を含み得る。メモリ８３０は、あるいは、不揮発性メモリ（ｎｏｎ－ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）、ハードディスクドライブ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ、ＨＤＤ）、またはソリッドステートドライブ（ｓｏｌｉｄ－ｓｔａｔｅ ｄｒｉｖｅ、ＳＳＤ）を含んでもよい。メモリ８３０は、前述のタイプのメモリの組み合わせをさらに含み得る。
メモリ８３０は、前述の実施形態において、第１の対応、第２の対応、第３の対応、第４の対応、及び第５の対応を記憶してもよい。
任意選択で、メモリ８３０は、オペレーティングシステム及びプログラム、実行可能モジュールもしくはデータ構造、またはそのサブセット、またはその拡張セットを格納する。プログラムは、様々な動作を実装するために使用される様々な動作命令を含み得る。オペレーティングシステムは、様々な基本サービスを実装し、ハードウェアベースのタスクを処理するために使用される、様々なシステムプログラムを含み得る。プロセッサ８１０は、本出願の実施形態において提供されるＲＰＦチェック方法を実装するために、メモリ８３０内のプログラムを読み取り得る。
バスシステム８４０は、周辺コンポーネント相互接続（ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ、ＰＣＩ）バス、拡張業界標準アーキテクチャ（ｅｘｔｅｎｄｅｄ ｉｎｄｕｓｔｒｙ ｓｔａｎｄａｒｄ ａｒｃｈｉｔｅｃｔｕｒｅ、ＥＩＳＡ）バスなどであってもよい。バスシステム８４０は、アドレスバス、データバス、制御バスなどに分類され得る。表現を容易にするために、図８のバスシステムを表すために、１つの太い線のみが使用されるが、これは、１つのバスのみ、または１つのタイプのバスのみがあることを意味しない。
本出願の実施形態は、命令を含むコンピュータ可読記憶媒体をさらに提供する。命令がコンピュータ上で実行されるとき、コンピュータは、テールノードによって実行され、方法の実施形態で提供されるＲＰＦチェック方法を実行することが可能である。
本出願の実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、テールノードによって実行され、方法の実施形態で提供されるＲＰＦチェック方法を実行することが可能である。
本出願の明細書、特許請求の範囲、及び添付の図面において、用語「第１の」、「第２の」、「第３の」、「第４の」等（存在する場合）は、類似のオブジェクトを区別することを意図しているが、必ずしも特定の順序または配列を示すものではない。このように呼ばれるデータは、本明細書に記載の実施形態が、本明細書に例示または記載される順序とは異なる順序で実施することができるように、適切な状況で交換可能であることを理解されたい。さらに、用語「含む（ｉｎｃｌｕｄｅ）」、「含む（ｃｏｎｔａｉｎ）」、及び任意の他の変形例は、非排他的包含、例えば、ステップまたは単位のリストを含むプロセス、方法、システム、製品、またはデバイスをカバーすることを意味し、これらのステップまたは単位に必ずしも限定されないが、そのようなプロセス、方法、製品、またはデバイスに明示的に列挙されていない、または固有の他のステップまたは単位を含み得る。
便利で簡単な説明の目的で、前述のシステム、装置、及びユニットの詳細な作業プロセスについて、前述の方法の実施形態における対応するプロセスを参照すること、及び詳細については本明細書では再度説明しないことは、当業者によって明確に理解され得る。
本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、及び方法は、他の方法で実施され得ることを理解されたい。例えば、説明した装置の実施形態は単なる例にすぎない。例えば、ユニットへの分割は、単なる論理モジュール分割であり、実際の実装中は他の分割であってもよい。例えば、複数のユニットまたはコンポーネントを組み合わせたり、別のシステムに統合したり、またはいくつかの機能を無視したり、実行しなかったりし得る。さらに、表示または説明されている相互結合または直接結合または通信接続は、いくつかのインターフェースを使用して実装し得る。装置またはユニット間の間接的な結合または通信接続は、電子的、機械的、または他の形態で実装し得る。
別個の部分として説明されるユニットは、物理的に分離されている場合とされていない場合があり、ユニットとして表示される部分は、物理ユニットである場合とそうでない場合があり、１つの位置に配置されている場合と複数のネットワークユニット上に分散されている場合がある。ユニットのいくつかまたはすべては、実施形態の解決策の目的を達成するための実際の要件に基づいて取得され得る。
さらに、本出願の実施形態におけるモジュールユニットは、１つの処理ユニットに統合され得るか、またはユニットのそれぞれが物理的に単独で存在し得るか、または２つ以上のユニットが１つのユニットに統合される。統合されたユニットは、ハードウェアの形で実装されてもよく、ソフトウェアモジュールユニットの形で実装されてもよい。
統合されたユニットがソフトウェアモジュールユニットの形で実装され、独立した製品として販売または使用される場合、統合されたユニットは、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づいて、本出願の実施形態の技術的解決策は基本的に、または先行技術に寄与する部分、または技術的解決策のすべてまたは一部は、ソフトウェア製品の形で実装され得る。コンピュータソフトウェア製品は、記憶媒体に格納され、コンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスであり得る）に、本出願の実施形態で説明された方法のステップのすべてまたはいくつかを実行するように指示するためのいくつかの命令を含む。前述の記憶媒体は、ＵＳＢフラッシュドライブ、リムーバブルハードディスク、読み取り専用メモリ（ＲＯＭ，Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ，Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク、または光ディスクなどの、プログラムコードを格納できる任意の媒体を含む。
当業者は、前述の１つ以上の実施例において、本発明に記載される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせによって実装され得ることを認識すべきである。ソフトウェアが機能を実装するために使用されるとき、機能は、コンピュータ可読媒体に記憶されてもよく、またはコンピュータ可読媒体に１つ以上の命令またはコードとして伝送されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含み、通信媒体は、コンピュータプログラムをある場所から別の場所に伝送することを可能にする任意の媒体を含む。記憶媒体は、汎用コンピュータまたは専用コンピュータにアクセス可能な任意の利用可能な媒体であり得る。
上記の特定の実装では、本発明の目的、技術的解決策、及び有益な効果をさらに詳細に説明する。上記の説明は、本発明の特定の実装に過ぎないことを理解されたい。
結論として、前述の実施形態は、本出願の技術的解決策を説明することのみを意図しており、本出願を限定することを意図していない。本出願は、前述の実施形態を参照して詳細に説明されるが、当業者は、本出願の実施形態の技術的解決策の範囲から逸脱することなく、前述の実施形態に記載された技術的解決策に修正を加え、またはそのいくつかの技術的特徴に等価な置き換えを行ってもよいことを理解すべきである。

Claims (20)

  1. リバースパス転送ＲＰＦチェック方法であって、該方法は、インターネットプロトコルバージョン６ＩＰｖ６ネットワークに適用され、
    テールノードによって、ヘッドノードからマルチキャストデータパケットを受信することであって、前記マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む、ことと、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得することであって、前記第１の対応は、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び前記第１の識別子を含み、前記第１の識別子は、前記マルチキャストデータパケットに対応するアップストリームマルチキャストネクストホップＵＭＨノードを識別するために使用される、ことと、
    前記テールノードによって、前記カプセル化情報及び第２の対応に基づいて第２の識別子を取得することであって、前記第２の対応は、前記カプセル化情報及び前記第２の識別子を含み、前記第２の識別子は、前記ヘッドノードを識別するために使用され、前記第１の識別子及び前記第２の識別子はそれぞれ１２８ビット未満である、ことと、
    前記テールノードによって、前記第１の識別子及び前記第２の識別子に基づいてＲＰＦチェックを実行することと、
    を含む方法。
  2. 前記テールノードによって、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信することであって、前記マルチキャストジョインメッセージは、前記マルチキャストソースアドレス及び前記マルチキャストグループアドレスを含む、ことと、
    前記テールノードによって、前記マルチキャストソースアドレスに基づいて前記ＵＭＨノードのＩＰｖ６アドレスを取得することと、
    前記テールノードによって、前記ＵＭＨノードの前記ＩＰｖ６アドレスに基づいて前記第１の識別子を取得することであって、前記第１の識別子は、前記ＵＭＨノードの前記ＩＰｖ６アドレスに対応する、ことと、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び前記第１の識別子に基づいて前記第１の対応を取得することと、
    をさらに含む、請求項１に記載の方法。
  3. 前記第１の対応が、マルチキャストインスタンスの識別子をさらに含み、前記テールノードによって、前記マルチキャストソースアドレスに基づいて前記ＵＭＨノードのＩＰｖ６アドレスを取得することが、
    前記テールノードによって、前記マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定することと、
    前記テールノードによって、前記マルチキャストソースアドレス、第３の対応、及び前記マルチキャストインスタンスの前記識別子に基づいて前記ＵＭＨノードの前記ＩＰｖ６アドレスを取得することであって、前記第３の対応は、前記マルチキャストソースアドレス、前記マルチキャストインスタンスの前記識別子、及び前記ＵＭＨノードの前記ＩＰｖ６アドレスを含む、ことと、を含み、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び前記第１の識別子に基づいて前記第１の対応を取得することが、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、前記マルチキャストインスタンスの前記識別子、及び前記第１の識別子に基づいて前記第１の対応を取得すること、を含む、請求項２に記載の方法。
  4. 前記マルチキャストインスタンスの前記識別子は、仮想ルーティング転送ＶＲＦの識別子またはイーサネット仮想プライベートネットワークＥＶＰＮインスタンスの識別子を含む、請求項３に記載の方法。
  5. 前記テールノードによって、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信することであって、前記マルチキャストルーティング情報は、前記ヘッドノードのＩＰｖ６アドレス、及び前記ヘッドノードと前記テールノードとの間のマルチプロトコルラベルスイッチングＭＰＬＳポイントツーマルチポイントＰ２ＭＰトンネルの識別子を含む、ことと、
    前記テールノードによって、前記ＭＰＬＳ Ｐ２ＭＰトンネルの前記識別子及び第４の対応に基づいて前記カプセル化情報を取得することであって、前記第４の対応は、前記ＭＰＬＳ Ｐ２ＭＰトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードによって前記ＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含む、ことと、
    前記テールノードによって、前記ヘッドノードの前記ＩＰｖ６アドレスに基づいて前記第２の識別子を取得することであって、前記第２の識別子は、前記ヘッドノードの前記ＩＰｖ６アドレスに対応する、ことと、
    前記テールノードによって、前記カプセル化情報及び前記第２の識別子に基づいて前記第２の対応を取得することと、
    をさらに含む、請求項１から４のいずれか１項に記載の方法。
  6. 前記テールノードによって、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信することであって、前記マルチキャストルーティング情報は、前記ヘッドノードのＩＰｖ６アドレス、及び前記ヘッドノードと前記テールノードとの間のビットインデックス明示的レプリケーションＢＩＥＲトンネルの識別子を含み、前記ＢＩＥＲトンネルの前記識別子は、ＢＩＥＲサブドメイン識別子サブドメインＩＤを含む、ことと、
    前記テールノードによって、前記ＢＩＥＲトンネルの前記識別子及び第５の対応に基づいて前記カプセル化情報を取得することであって、前記第５の対応は、前記ＢＩＥＲトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードに対応するビットインデックス転送テーブル識別子ＢＩＦＴ－ｉｄを含む、ことと、
    前記テールノードによって、前記ヘッドノードの前記ＩＰｖ６アドレスに基づいて前記第２の識別子を取得することであって、前記第２の識別子は、前記ヘッドノードの前記ＩＰｖ６アドレスに対応する、ことと、
    前記テールノードによって、前記カプセル化情報及び前記第２の識別子に基づいて前記第２の対応を取得することと、
    をさらに含む、請求項１から４のいずれか１項に記載の方法。
  7. 前記テールノードによって、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信することであって、前記マルチキャストルーティング情報は、前記カプセル化情報及び前記ヘッドノードのＩＰｖ６アドレスを含み、前記カプセル化情報は、前記ヘッドノードによって前記テールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスである、ことと、
    前記テールノードによって、前記ヘッドノードの前記ＩＰｖ６アドレスに基づいて前記第２の識別子を取得することであって、前記第２の識別子は、前記ヘッドノードの前記ＩＰｖ６アドレスに対応する、ことと、
    前記テールノードによって、前記カプセル化情報及び前記第２の識別子に基づいて前記第２の対応を取得することと、
    をさらに含む、請求項１から４のいずれか１項に記載の方法。
  8. 前記マルチキャストルーティング情報が、マルチキャスト仮想プライベートネットワークＭＶＰＮルーティング情報またはイーサネット仮想プライベートネットワークＥＶＰＮルーティング情報を含む、請求項５から７のいずれか１項に記載の方法。
  9. 前記第１の識別子及び前記第２の識別子はそれぞれ、３２ビット以下の値である、請求項１から８のいずれか１項に記載の方法。
  10. 前記第１の識別子及び前記第２の識別子が、次のアドレス範囲、
    ０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦまたは０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ
    のうちの１つの範囲内にある、請求項９に記載の方法。
  11. ＲＰＦチェック装置であって、前記装置はインターネットプロトコルバージョン６ＩＰｖ６ネットワークに適用され、前記装置は、
    ヘッドノードからマルチキャストデータパケットを受信するように構成された受信ユニットであって、前記マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む、受信ユニットと、
    前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び第１の対応に基づいて第１の識別子を取得するように構成された取得ユニットあって、前記第１の対応は、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び前記第１の識別子を含み、前記第１の識別子は、前記マルチキャストデータパケットに対応するアップストリームマルチキャストネクストホップＵＭＨノードを識別するために使用される、取得ユニットと、
    前記取得ユニットは、前記カプセル化情報及び第２の対応に基づいて第２の識別子を取得するようにさらに構成され、前記第２の対応は、前記カプセル化情報及び前記第２の識別子を含み、前記第２の識別子は、前記ヘッドノードを識別するために使用され、前記第１の識別子及び前記第２の識別子はそれぞれ１２８ビット未満であり、
    前記第１の識別子及び前記第２の識別子に基づいてＲＰＦチェックを行うように構成されたＲＰＦチェックユニットと、
    を備えた装置。
  12. 前記受信ユニットは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成され、前記マルチキャストジョインメッセージは、前記マルチキャストソースアドレス及び前記マルチキャストグループアドレスを含み、
    前記取得ユニットは、前記マルチキャストソースアドレスに基づいて前記ＵＭＨノードのＩＰｖ６アドレスを取得し、前記ＵＭＨノードの前記ＩＰｖ６アドレスに基づいて前記第１の識別子を取得し、前記第１の識別子は、前記ＵＭＨノードの前記ＩＰｖ６アドレスに対応し、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び前記第１の識別子に基づいて前記第１の対応を取得するようにさらに構成された、請求項１１に記載の装置。
  13. 前記第１の対応は、マルチキャストインスタンスの識別子をさらに含み、前記取得ユニットは、
    前記マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、前記マルチキャストソースアドレス、第３の対応、及び前記マルチキャストインスタンスの前記識別子に基づいて前記ＵＭＨノードの前記ＩＰｖ６アドレスを取得し、前記第３の対応は、前記マルチキャストソースアドレス、前記マルチキャストインスタンスの前記識別子、及び前記ＵＭＨノードの前記ＩＰｖ６アドレスを含み、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、前記マルチキャストインスタンスの前記識別子、及び前記第１の識別子に基づいて前記第１の対応を取得するように特に構成された、請求項１２に記載の装置。
  14. 前記マルチキャストインスタンスの前記識別子は、仮想ルーティング転送ＶＲＦの識別子またはイーサネット仮想プライベートネットワークＥＶＰＮインスタンスの識別子を含む、請求項１３に記載の装置。
  15. 前記受信ユニットは、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、前記マルチキャストルーティング情報は、前記ヘッドノードのＩＰｖ６アドレス、及び前記ヘッドノードと前記テールノードとの間のマルチプロトコルラベルスイッチングＭＰＬＳポイントツーマルチポイントＰ２ＭＰトンネルの識別子を含み、
    前記取得ユニットは、前記ＭＰＬＳ Ｐ２ＭＰトンネルの識別子及び第４の対応に基づいてカプセル化情報を取得し、前記第４の対応は、前記ＭＰＬＳ Ｐ２ＭＰトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードによって前記ＭＰＬＳ Ｐ２ＭＰトンネルに割り当てられたラベルを含み、前記ヘッドノードの前記ＩＰｖ６アドレスに基づいて前記第２の識別子を取得し、前記第２の識別子は、前記ヘッドノードの前記ＩＰｖ６アドレスに対応し、前記カプセル化情報及び前記第２の識別子に基づいて前記第２の対応を取得するようにさらに構成された、請求項１１から１４のいずれか１項に記載の装置。
  16. 前記受信ユニットは、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、前記マルチキャストルーティング情報は、前記ヘッドノードのＩＰｖ６アドレス、及び前記ヘッドノードと前記テールノードとの間のビットインデックス明示的レプリケーションＢＩＥＲトンネルの識別子を含み、前記ＢＩＥＲトンネルの前記識別子は、ＢＩＥＲサブドメイン識別子サブドメインＩＤを含み、
    前記取得ユニットは、前記ＢＩＥＲトンネルの前記識別子及び第５の対応に基づいて前記カプセル化情報を取得し、前記第５の対応は、前記ＢＩＥＲトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードに対応するビットインデックス転送テーブル識別子ＢＩＦＴ－ｉｄを含み、前記ヘッドノードの前記ＩＰｖ６アドレスに基づいて前記第２の識別子を取得し、前記第２の識別子は、前記ヘッドノードの前記ＩＰｖ６アドレスに対応し、前記カプセル化情報及び前記第２の識別子に基づいて前記第２の対応を取得するようにさらに構成された、請求項１１から１４のいずれか１項に記載の装置。
  17. 前記受信ユニットは、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、前記マルチキャストルーティング情報は、前記カプセル化情報及び前記ヘッドノードのＩＰｖ６アドレスを含み、前記カプセル化情報は、前記ヘッドノードによって前記テールノードのマルチキャストインスタンスに割り当てられたＩＰｖ６アドレスであり、
    前記取得ユニットは、前記ヘッドノードの前記ＩＰｖ６アドレスに基づいて前記第２の識別子を取得し、前記第２の識別子は前記ヘッドノードの前記ＩＰｖ６アドレスに対応し、前記カプセル化情報及び前記第２の識別子に基づいて前記第２の対応を取得するようにさらに構成された、請求項１１から１４のいずれか１項に記載の装置。
  18. 前記マルチキャストルーティング情報が、マルチキャスト仮想プライベートネットワークＭＶＰＮルーティング情報またはイーサネット仮想プライベートネットワークＥＶＰＮルーティング情報を含む、請求項１５から１７のいずれか１項に記載の装置。
  19. 前記第１の識別子及び前記第２の識別子はそれぞれ、３２ビット以下の値である、請求項１１から１８のいずれか１項に記載の装置。
  20. 前記第１の識別子及び前記第２の識別子が、次のアドレス範囲、
    ０ｘ７Ｆ００００００－０ｘ７ＦＦＦＦＦＦＦまたは０ｘＥ０００００００－０ｘＥＦＦＦＦＦＦＦ
    のうちの１つの範囲内にある、請求項１９に記載の装置。
JP2022518284A 2019-09-23 2020-09-23 リバースパス転送ｒｐｆチェック方法及び装置 Active JP7397178B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201910900954.0A CN111917622B (zh) 2019-09-23 2019-09-23 一种反向路径转发rpf检查方法及装置
CN201910900954.0 2019-09-23
PCT/CN2020/117112 WO2021057788A1 (zh) 2019-09-23 2020-09-23 一种反向路径转发rpf检查方法及装置

Publications (2)

Publication Number Publication Date
JP2022548987A true JP2022548987A (ja) 2022-11-22
JP7397178B2 JP7397178B2 (ja) 2023-12-12

Family

ID=73242765

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022518284A Active JP7397178B2 (ja) 2019-09-23 2020-09-23 リバースパス転送ｒｐｆチェック方法及び装置

Country Status (6)

Country Link
US (1) US11997004B2 (ja)
EP (1) EP4024774A4 (ja)
JP (1) JP7397178B2 (ja)
KR (1) KR20220062347A (ja)
CN (2) CN111917622B (ja)
WO (1) WO2021057788A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114095305A (zh) * 2020-07-21 2022-02-25 华为技术有限公司 Bier报文转发的方法、设备以及系统
US11102107B1 (en) * 2020-10-12 2021-08-24 Cisco Technology, Inc. BIER overlay signaling enhancement
CN113992565B (zh) * 2021-09-29 2023-11-07 新华三大数据技术有限公司 一种组播报文处理方法及装置
WO2024016869A1 (zh) * 2022-07-21 2024-01-25 华为技术有限公司 一种组播配置方法及装置
CN116055387B (zh) * 2022-12-29 2024-08-23 苏州盛科通信股份有限公司 组播报文处理方法、装置、服务器和介质
US12113702B1 (en) * 2023-07-14 2024-10-08 Arista Networks, Inc. Multicasting using selective advertisement of EVPN routes

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030223402A1 (en) * 2002-06-04 2003-12-04 Sanchez Juan Diego Efficient reverse path forwarding check mechanism
CN101599841A (zh) * 2008-06-03 2009-12-09 华为技术有限公司 实现组播的方法、路由器及系统
US20120163373A1 (en) * 2005-04-05 2012-06-28 Alton Lo Transporting multicast over mpls backbone using virtual interfaces to perform reverse-path forwarding checks
US8605722B1 (en) * 2009-12-10 2013-12-10 Juniper Networks, Inc. Deadlock-resistant fabric tree replication in a network device
US20150195093A1 (en) * 2014-01-09 2015-07-09 Dell Products L.P. Delayed updating of forwarding databases for multicast transmissions over telecommunications networks

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6917983B1 (en) * 1999-07-28 2005-07-12 Nortel Networks Ltd Reverse path forwarding using a multicast routing table
CN100389579C (zh) * 2004-07-29 2008-05-21 国家数字交换系统工程技术研究中心 支持IPv6单组播业务线速转发的方法及路由器
US7808993B2 (en) * 2005-10-26 2010-10-05 Cisco Technology, Inc. Bidirectional multicast protocol with upstream and downstream join messages
US7953089B1 (en) 2006-05-16 2011-05-31 Cisco Technology, Inc. Systems and methods for multicast switching in a private VLAN
CN101035009A (zh) * 2007-03-31 2007-09-12 华为技术有限公司 一种组播流量冗余保护的方法及设备
CN101060494A (zh) * 2007-05-17 2007-10-24 华为技术有限公司 一种路由选择的方法、系统及路由器
CN101330448B (zh) * 2007-06-21 2010-12-08 华为技术有限公司 一种通告链路状态信息及确定组播转发路径的方法及装置
CN101296179B (zh) * 2007-10-29 2011-01-26 清华大学 IPv6使用逆向路径转发矢量IPv4/6的方法
CN101150423B (zh) * 2007-10-31 2010-08-18 华为技术有限公司 一种建立pim邻居、组播加入的方法、组播网络及路由器
CN101232392B (zh) * 2008-02-22 2011-07-13 中兴通讯股份有限公司 一种msdp和pim间通告组播源的方法
CN101478477A (zh) * 2008-12-01 2009-07-08 北京星网锐捷网络技术有限公司 一种组播报文转发方法及装置
CN101447942B (zh) * 2008-12-25 2012-04-18 杭州华三通信技术有限公司 一种组播流量路径的控制方法和装置
WO2010110566A2 (ko) 2009-03-22 2010-09-30 엘지전자 주식회사 무선 통신 시스템에서 사운딩 참조 신호 송신 방법 및 이를 위한 장치
CN101588296B (zh) * 2009-06-16 2011-09-07 杭州华三通信技术有限公司 一种转发组播报文的方法、头节点和尾节点
CN101616015B (zh) * 2009-07-24 2011-08-10 中兴通讯股份有限公司 一种获取ip网络中组播拓扑信息的方法和装置
CN102457386B (zh) * 2010-10-25 2014-07-16 杭州华三通信技术有限公司 一种通信设备的双向pim中组播报文转发方法和通信设备
US20130003732A1 (en) * 2011-06-29 2013-01-03 Brocade Communications Systems, Inc. Abstracting accepting interface to optimize parent and child entry lookup for bidirectional pim
US8873558B2 (en) * 2011-08-03 2014-10-28 Cisco Technology, Inc. Reverse path forwarding lookup with link bundles
CN103220255B (zh) * 2012-01-18 2017-07-21 南京中兴新软件有限责任公司 一种实现单播反向路径转发urpf检查的方法及装置
CN102891758B (zh) * 2012-09-20 2015-07-08 杭州华三通信技术有限公司 一种组播数据的传输方法和设备
CN102946332B (zh) * 2012-10-25 2015-09-23 杭州华三通信技术有限公司 一种逆向路径转发检查方法和设备
US9166903B2 (en) 2012-12-18 2015-10-20 Alcatel Lucent System, method and apparatus to resolve RPF-vector attribute conflicts
CN103916905A (zh) * 2013-01-06 2014-07-09 中兴通讯股份有限公司 组播源的注册、组播路径的建立方法及装置
US20160099859A1 (en) 2014-10-06 2016-04-07 Futurewei Technologies, Inc. Reverse Path Validation for Source Routed Networks
CN109150730A (zh) 2017-06-15 2019-01-04 中兴通讯股份有限公司 组播跨域方法、装置、系统及计算机可读存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030223402A1 (en) * 2002-06-04 2003-12-04 Sanchez Juan Diego Efficient reverse path forwarding check mechanism
US20120163373A1 (en) * 2005-04-05 2012-06-28 Alton Lo Transporting multicast over mpls backbone using virtual interfaces to perform reverse-path forwarding checks
CN101599841A (zh) * 2008-06-03 2009-12-09 华为技术有限公司 实现组播的方法、路由器及系统
US8605722B1 (en) * 2009-12-10 2013-12-10 Juniper Networks, Inc. Deadlock-resistant fabric tree replication in a network device
US20150195093A1 (en) * 2014-01-09 2015-07-09 Dell Products L.P. Delayed updating of forwarding databases for multicast transmissions over telecommunications networks

Also Published As

Publication number Publication date
WO2021057788A1 (zh) 2021-04-01
CN111917622A (zh) 2020-11-10
CN113726667B (zh) 2022-11-18
CN111917622B (zh) 2021-08-03
JP7397178B2 (ja) 2023-12-12
EP4024774A1 (en) 2022-07-06
CN113726667A (zh) 2021-11-30
KR20220062347A (ko) 2022-05-16
US20220217075A1 (en) 2022-07-07
EP4024774A4 (en) 2022-11-09
US11997004B2 (en) 2024-05-28

Similar Documents

Publication Publication Date Title
US11374862B2 (en) Packet sending and processing method and apparatus, PE node, and node
JP7397178B2 (ja) リバースパス転送ｒｐｆチェック方法及び装置
US11483237B2 (en) BIER traffic engineering (BIER-TE) using unicast MPLS-TE tunnels
US10581732B2 (en) Target FEC (forwarding equivalence class) stack based FEC query in segment routing environments
EP3896923A1 (en) Bier packet sending method and apparatus
US12040965B2 (en) Supporting multicast communications
WO2019214589A1 (zh) 组播数据传输方法、相关装置及系统
US8571029B1 (en) Label switched path hierarchy for intra-area segments of inter-area point-to-multipoint label switched paths
WO2021258754A1 (zh) 报文指示方法、装置、设备和存储介质
WO2016177087A1 (zh) 一种传输bier报文的方法及装置
EP3226491A1 (en) Hot root standby support for multicast
WO2018072704A1 (zh) 报文传输方法、装置、节点和计算机存储介质
US12034631B2 (en) Loop avoidance communications method, device, and system
WO2013139270A1 (zh) 实现三层虚拟专用网络的方法、设备及系统
CN102474451B (zh) 连接内层和外层mpls标签
JP2024027107A (ja) 通信方法および関連する装置
US12113706B2 (en) Stateless multicast in multi-domain networks
WO2020244372A1 (zh) 一种实现组播的方法和装置
US20140185614A1 (en) Multiple domain addressing in message routing
WO2020021558A1 (en) Methods, apparatus and machine-readable media relating to path computation in a communication network
CN103595609B (zh) Trill网络互联方法、系统及设备
US20240048483A1 (en) PCE for BIER-TE Ingress Protection
Veselý et al. Multicast, trill and lisp extensions for inet
WO2024092288A1 (en) Segment routing (sr) binding protection
WO2024010954A1 (en) Link number distribution for multicast

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220418

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220418

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230516

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: 20231031

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231130

R150 Certificate of patent or registration of utility model

Ref document number: 7397178

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150