JP7397178B2 - リバースパス転送rpfチェック方法及び装置 - Google Patents

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

Info

Publication number
JP7397178B2
JP7397178B2 JP2022518284A JP2022518284A JP7397178B2 JP 7397178 B2 JP7397178 B2 JP 7397178B2 JP 2022518284 A JP2022518284 A JP 2022518284A JP 2022518284 A JP2022518284 A JP 2022518284A JP 7397178 B2 JP7397178 B2 JP 7397178B2
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.)
Active
Application number
JP2022518284A
Other languages
English (en)
Other versions
JP2022548987A (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

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/70Routing based on monitoring results
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/741Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/2592Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/604Address structures or formats
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/618Details of network addresses
    • H04L2101/659Internet protocol version 6 [IPv6] addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/72Routing based on the source address

Description

本出願は、通信分野に関し、特に、リバースパス転送RPFチェック方法及び装置に関する。
本出願は、中国特許出願第CN201910900954.0は、2019年9月23日に中国国家知的財産管理局に出願され、「リバースパス転送RPFチェック方法及び装置」と題され、その全体が参照により本明細書に組み込まれる。
現在、仮想プライベートネットワーク(virtual private network、VPN)は、コアネットワーク内にあり、プロバイダによって提供されるネットワークエッジ(provider edge、PE)ノード上に展開され得る。それに応じて、VPNインスタンスを使用して、マルチキャストサービスを処理し得る。マルチキャストサービスを使用して、マルチキャストグループ内の1つのPEから1つまたは複数の他のPEにマルチキャストデータパケットを送信することができる。
実際のアプリケーションでは、マルチキャストデータパケットが1つのPEから複数の他のPEに送信されるとき、マルチキャストデータパケットを受信するPE、例えば、テールノードは、受信したマルチキャストデータパケットに対してリバースパス転送(reverse path forwarding、RPF)チェックを実行する必要がある。テールノードは、チェック結果に基づいて、マルチキャストデータパケットを転送するかどうかを決定する。RPFチェックは、マルチキャストデータパケットが、選択されたアップストリームマルチキャストホップ(upstream multicast hop、UMH)ノードから来ているかどうかを決定するためのものである。マルチキャストデータパケットが、選択されたアップストリームマルチキャストホップノードから来る場合、テールノードはマルチキャストデータパケットを転送する;または、マルチキャストデータパケットが、選択されたアップストリームマルチキャストホップノードから来ない場合、テールノードはマルチキャストデータパケットを破棄する。
VPNが展開されているプロバイダネットワークがインターネットプロトコルバージョン6(internet protocol version 6、IPv6)ネットワークである場合、マルチキャストサービスを実装するテールノードによって実行されるRPFチェックは複雑である。
本出願の実施形態は、RPFチェックを簡素化するためのRPF方法及び装置を提供する。
第1の態様によれば、本出願の一実施形態は、リバースパス転送チェック方法を提供する。ヘッドノードからマルチキャストデータパケットを受信した後、テールノードは、マルチキャストデータパケットを解析して、マルチキャストソースアドレス、マルチキャストグループアドレス、及びマルチキャストデータパケット内で搬送されるカプセル化情報を取得し得る。マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の対応に基づいて、マルチキャストデータパケットに対応するアップストリームマルチキャストホップUMHノードを識別するために使用される第1の識別子を取得し得る。第1の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子の間のマッピング関係を含む。したがって、マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、第1の対応に基づいて第1の識別子を決定し得る。加えて、テールノードは、マルチキャストデータパケットのカプセル化情報及び第2の対応に基づいて、マルチキャストデータパケットに対応するヘッドノードを識別するために使用される第2の識別子をさらに取得し得る。第1の識別子及び第2の識別子を取得した後、テールノードは、第1の識別子及び第2の識別子に基づいてRPFチェックを実行し得る。IPv6ネットワークにおいて、ノードのアドレスは、128ビットを使用して表されることが理解できる。したがって、RPFチェックを実行するとき、テールノードは2つの128ビットデータを比較する必要がある。その結果、RPFチェックは複雑である。しかしながら、本出願のこの実施形態では、第1の識別子及び第2の識別子のデータ長はそれぞれ128ビット未満である。したがって、本出願のこの実施形態では、128ビット未満の2つのデータを比較して、RPFチェックを完了し得る。従来の技術と比較して、本出願のこの実施形態で提供される解決策では、RPFチェックが簡素化されることを学ぶことができる。
一実施態様では、第1の対応は、事前にテールノードによって生成され得る。具体的には、テールノードは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信し得る。マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。マルチキャストジョインメッセージを受信した後、テールノードは、マルチキャストジョインメッセージを解析して、マルチキャストジョインメッセージ内のマルチキャストソースアドレスを取得し、マルチキャストソースアドレスに基づいてUMHノードのIPv6アドレスを取得し得る。次いで、テールノードは、UMHノードのIPv6アドレスに基づいて、UMHノードのIPv6アドレスに対応する第1の識別子を取得し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子の間の対応を確立し、言い換えれば、第1の対応を確立し、その後のRPFチェックの間の第1の対応に基づいて第1の識別子が決定される。
一実施態様では、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子に加えて、第1の対応は、マルチキャストインスタンスの識別子をさらに含み得る。マルチキャストインスタンスは、テールノードに対応する。言い換えると、マルチキャストインスタンスは、テールノードのマルチキャストインスタンスである。この場合、マルチキャストソースアドレスに基づいてUMHノードのIPv6アドレスを取得する特定の実装では、テールノードは、マルチキャストインスタンスの識別子をさらに決定し得、次いで、テールノードは、マルチキャストインスタンスの識別子及びマルチキャストソースアドレスを参照してUMHノードのIPv6アドレスを検索する。具体的には、テールノードは、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びUMHノードのIPv6アドレスを含む所定の第3の対応に基づいて、UMHノードのIPv6アドレスを決定し得る。対応して、第1の対応を確立するとき、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、第1の識別子、及びマルチキャストインスタンスの識別子の間で第1の対応をさらに確立し得る。
一実装では、MVPNの場合、マルチキャストインスタンスの識別子は、MVPNインスタンスの識別子であってよく、EVPNの場合、マルチキャストインスタンスの識別子は、EVPNインスタンスの識別子であってよい。加えて、実際の適用では、MVPNの場合、マルチキャストジョインメッセージを受信するインターフェースが属するVRFの識別子を使用して、マルチキャストインスタンスを識別し得る。したがって、MVPNの場合、マルチキャストインスタンスの識別子は、例えば、マルチキャストジョインメッセージを受信するインターフェースが属するVRFの識別子であってもよい。
一実装では、第2の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合、テールノードは、以下の方法で第2の対応を確立してもよい:テールノードは、ヘッドノードによって送信されたマルチキャストルーティングメッセージを受信する。マルチキャストルーティングメッセージは、ヘッドノードのIPv6アドレス、及びヘッドノードとテールノードとの間のMPLS P2MPトンネルの識別子を含む。テールノードは、MPLS P2MPトンネルの識別子及び第4の対応に基づいてカプセル化情報を取得する。テールノードは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応する。テールノードは、カプセル化情報及び第2の識別子に基づいて第2の対応を取得する。
一実装では、第2の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがBIERトンネルである場合、テールノードは、以下の方法で第2の対応を確立してもよい:テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信する。マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス及びBIERトンネルの識別子を含む。テールノードは、BIERトンネルの識別子及び第5の対応に基づいてカプセル化情報を取得する。テールノードは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応する。テールノードは、カプセル化情報及び第2の識別子に基づいて第2の対応を取得する。
一実装では、第2の対応は、事前にテールノードによって生成され得る。具体的には、マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合、テールノードは、以下の方法で第2の対応を確立してもよい:テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信する。マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのIPv6アドレスを含む。カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたIPv6アドレスである。テールノードは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応する。テールノードは、カプセル化情報及び第2の識別子に基づいて第2の対応を取得する。
一実装では、MVPNの場合、ヘッドノードによってテールノードに送信されたマルチキャストルーティングメッセージは、MVPNルーティング情報、例えば、BGP MVPNアドレスファミリルーティング情報である。EVPNの場合、ヘッドノードによってテールノードに送信されたマルチキャストルーティング情報は、EVPNルーティング情報、例えば、BGP EVPNアドレスファミリルーティング情報である。
一実装では、実際の適用では、IPv4ネットワーク内のノードのアドレスは、32ビットを使用して表され得、2つの32ビットデータを比較する複雑さは、通常、テールノードによって許容することができる範囲内にある。したがって、本出願のこの実施形態の一実装では、第1の識別子及び第2の識別子はそれぞれ、32ビット以下の値であり得る。
一実装では、プロバイダネットワークは、代替的に、v4v6デュアルスタックネットワークであってもよく、IPv4ネットワーク内のノードのアドレスは、32ビットを使用して表されてもよいと考えられる。第1の識別子をIPv4ネットワーク内のノードのアドレスと区別し、第2の識別子をIPv4ネットワーク内のノードのアドレスと区別するために、第1の識別子の値範囲は、IPv4ネットワーク内のノードのアドレス範囲と重複することはできず、それに応じて、第2の識別子の値範囲は、IPv4ネットワーク内のノードのアドレス範囲と重複することはできない。現在、0x7F000000-0x7FFFFFFFの範囲の値は、IPv4ネットワーク内のノードのアドレスとして使用されず、0xE0000000-0xEFFFFFFFの範囲の値は、IPv4ネットワークのノードのアドレスとして使用されない。したがって、第1の識別子及び第2の識別子は、範囲0x7F000000-0x7FFFFFFF内にあり得るか、または第1の識別子及び第2の識別子は、範囲0xE0000000-0xEFFFFFFF内にあり得る。
第2の態様によれば、本出願の一実施形態は、RPFチェック装置を提供する。装置は、マルチキャストデータパケットをヘッドノードから受信するように構成された受信ユニットであって、マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む、受信ユニットと、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の対応に基づいて第1の識別子を取得するように構成された取得ユニットであって、第1の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子を含み、第1の識別子は、マルチキャストデータパケットに対応するアップストリームマルチキャストホップUMHノードを識別するために使用され、取得ユニットは、カプセル化情報及び第2の対応に基づいて第2の識別子を取得するようにさらに構成され、第2の対応は、カプセル化情報及び第2の識別子を含み、第2の識別子は、ヘッドノードを識別するために使用され、第1の識別子及び第2の識別子はそれぞれ128ビット未満である、取得ユニットと、第1の識別子及び第2の識別子に基づいてRPFチェックを実行するように構成されたRPFチェックユニットと、を含む。
一実施態様では、受信ユニットは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成され、マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含み、取得ユニットは、マルチキャストソースアドレスに基づいてUMHノードのIPv6アドレスを取得し、UMHノードのIPv6アドレスに基づいて第1の識別子を取得し、第1の識別子は、UMHノードのIPv6アドレスに対応し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子に基づいて第1の対応を取得するようにさらに構成される。
一実施態様では、第1の対応は、マルチキャストインスタンスの識別子をさらに含み、取得ユニットは、マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、マルチキャストソースアドレス、第3の対応、及びマルチキャストインスタンスの識別子に基づいてUMHノードのIPv6アドレスを取得し、第3の対応は、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びUMHノードのIPv6アドレスを含み、マルチキャストソースアドレス、マルチキャストグループアドレス、マルチキャストインスタンスの識別子、及び第1の識別子に基づいて第1の対応を取得するように特に構成される。
一実施態様では、マルチキャストインスタンスの識別子は、仮想ルーティング転送VRFの識別子またはイーサネット仮想プライベートネットワークEVPNインスタンスの識別子を含む。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス、及びヘッドノードとテールノードとの間のマルチプロトコルラベルスイッチングMPLSポイントツーマルチポイントP2MPトンネルの識別子を含み、取得ユニットは、MPLS P2MPトンネルの識別子及び第4の対応に基づいてカプセル化情報を取得し、第4の対応は、MPLS P2MPトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードによってMPLS P2MPトンネルに割り当てられたラベルを含み、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応し、カプセル化情報及び第2の識別子に基づいて第2の対応を取得するようにさらに構成される。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス、及びヘッドノードとテールノードとの間のビットインデックス明示的レプリケーションBIERトンネルの識別子を含み、ビアトンネルの識別子は、BIERトンネルの識別子は、BIERサブドメイン識別子IDを含み、取得ユニットは、BIERトンネルの識別子及び第5の対応に基づいてカプセル化情報を取得し、第5の対応は、BIERトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子BIFT-idを含み、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応し、カプセル化情報及び第2の識別子に基づいて第2の対応を取得するようにさらに構成される。
一実施態様では、受信ユニットは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのIPv6アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたIPv6アドレスであり、取得ユニットは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応し、カプセル化情報及び第2の識別子に基づいて第2の対応を取得するようにさらに構成される。
一実施態様では、マルチキャストルーティング情報は、マルチキャスト仮想プライベートネットワークMVPNルーティング情報またはイーサネット仮想プライベートネットワークEVPNルーティング情報を含む。
一実施態様では、第1の識別子及び第2の識別子はそれぞれ、32ビット以下の値である。
一実施態様では、第1の識別子及び第2の識別子は、次のアドレス範囲、0x7F000000-0x7FFFFFFFまたは0xE0000000-0xEFFFFFFFのうちの1つの範囲内にある。
第3の態様によれば、本出願の一実施形態は、RPFチェックデバイスを提供する。デバイスは、プロセッサ及びメモリを含み、メモリは、命令を記憶するように構成され、プロセッサは、第1の態様及び第1の態様の実装のいずれか1つによる方法を実行するために、メモリ内の命令を実行するように構成される。
第4の態様によれば、本出願の一実施形態は、命令を含むコンピュータ可読記憶媒体を提供する。命令がコンピュータ上で実行されるとき、コンピュータは、第1の態様及び第1の態様の実装のいずれか1つによる方法を実行することが可能である。
第5の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、第1の態様及び第1の態様の実装のいずれか1つによる方法を実行することが可能である。
本出願の一実施形態によるマルチキャストネットワークの構造の概略図である。 本出願の一実施形態によるRPFチェック方法の概略フローチャートである。 本出願の一実施形態による、第1の対応を生成するための方法のシグナリング相互作用図である。 本出願の一実施形態による、第2の対応を生成するための方法のシグナリング相互作用図である。 本出願の一実施形態による、第2の対応を生成するための別の方法のシグナリング相互作用図である。 本出願の一実施形態による、第2の対応を生成するための別の方法のシグナリング相互作用図である。 本出願の一実施形態によるRPFチェック装置の構造の概略図である。 本出願の一実施形態によるRPFチェックデバイスの構造の概略図である。
本出願の実施形態は、VPNが展開されているプロバイダネットワークが従来技術におけるIPv6ネットワークである場合に、テールノードによって実行されたRPFチェックが複雑であるという問題を解決するためのRPFチェック方法を提供する。
わかりやすくするために、本出願の実施形態の適用シナリオを最初に説明する。
図1は、本出願の一実施形態によるマルチキャストネットワークの構造の概略図である。
図1に示すように、CE1、CE2、及びCE3は、ユーザ機器であってもよい。具体的には、CE1、CE2、及びCE3は、ユーザボーダールータであってもよい。PE1、PE1b、P1、P2、PE2、PE3は、プロバイダネットワーク内のデバイスである。CE1は、マルチキャストソースサーバに、具体的には、マルチキャストデータパケットを送信するソースノードに接続される。PE1、PE1b、PE2、PE3は、プロバイダネットワーク内のエッジノードである。CE2及びCE3は、マルチキャスト受信ノードに接続される。マルチキャスト受信ノードは、例えば、パーソナルコンピュータ(personal computer、PC)またはセットトップボックス(set top box、STB)デバイスであってもよい。CE2は、PE2からマルチキャストデータパケットを受信してよく、CE3は、PE3からマルチキャストデータパケットを受信してよい。
実際の適用では、VPNは、プロバイダネットワーク内のエッジノード上に展開され得ることに留意されたい。VPNインスタンス及びVPNインスタンスが展開されるネットワーク構造に使用されるシグナリングに基づいて、VPNは、レイヤ3仮想プライベートネットワーク(Layer-3 VPN、L3VPN)またはイーサネット仮想プライベートネットワーク(ethernet virtual private network、EVPN)であり得る。L3VPNでは、ユニキャストサービスは、ボーダーゲートウェイプロトコル(border gateway protocol、BGP)VPNv4シグナリングまたはVPNv6シグナリングに基づいて確立されてもよく、もしくはマルチキャストサービス、すなわち、MVPNサービスは、BGPマルチキャスト仮想プライベートネットワーク(multicast virtual private network、MVPN)シグナリングに基づいて確立されてもよい。EVPNでは、ユニキャストサービスは、BGP EVPNシグナリングに基づいて確立されてもよく、またはマルチキャストサービス、すなわち、EVPNマルチキャストサービスは、BGP EVPNマルチキャストシグナリングに基づいて確立されてもよい。さらに、マルチキャストサービスは、EVPNにおけるBGP MVPNシグナリングに基づいて確立されてもよく、そのようなマルチキャストサービスは、MVPNサービスとも呼ばれる。MVPN及びEVPNにおけるマルチキャストサービスを処理する同じ一般的な手順がある。本出願のこの実施形態における以下の説明では、MVPNが、説明のための例として使用される。
プロバイダのPEとユーザ機器、すなわちCEとの間のマルチキャストサービスがIPv6マルチキャストである場合、マルチキャストサービスはIPv6 MVPNと呼ばれる。プロバイダのPEとユーザ機器、すなわちCEとの間のマルチキャストサービスがIPv4マルチキャストである場合、マルチキャストサービスはIPv4 MVPNと呼ばれる。本出願のこの実施形態では、IPv6 MVPNとIPv4 MVPNの両方が適用可能であり、MVPNと総称される。
プロバイダのPE間の部分は、VPNバックボーン(VPN backbone)と呼ばれる。本出願のこの実施形態では、VPNバックボーンは、IPv6シングルプロトコルスタックが動作するネットワーク、またはIPv4及びIPv6デュアルスタック(またはv4v6デュアルスタック)が動作するネットワークであってもよい。MVPNでのマルチキャストルート選択にIPv6アドレスが使用されることを確認する必要があるだけである。IPv6シングルプロトコルスタックまたはv4v6デュアルスタックが使用されるかどうかは、本出願のこの実施形態では限定されない。
さらに、MVPNシグナリングは、VPNマルチキャスト及びパブリックネットワークマルチキャストの両方に適用できる。VPNマルチキャストは、L3VPNに基づいて確立されたVPNであっても、EVPNに基づいて確立されたVPNであってもよい。本出願のこの実施形態におけるMVPNは、パブリックネットワークマルチキャストに使用されるMVPNシグナリング方法と、VPNマルチキャストに使用されるMVPNシグナリング方法の両方を含む。これは、本出願のこの実施形態では限定されない。
確かに、プロバイダのPEとユーザ機器との間のマルチキャストネットワークは、代替的に、v4v6デュアルスタックネットワークであり得る。言い換えると、IPv4ネットワーク及びIPv6ネットワークの両方がサポートされる。本出願のこの実施形態では、プロバイダのPEとユーザ機器との間のネットワークは限定されない。
実際の適用では、包括的プロバイダマルチキャストサービスインターフェース(inclusive provider multicast service interface、IPMSI)トンネルを使用して、MVPN内でマルチキャストサービスを搬送することができる。IPMSIトンネルを使用してマルチキャストサービスを搬送する場合、マルチキャストデータパケットがトンネルを介して伝送される処理において、トンネルタイプに基づいて、マルチキャストソースからのマルチキャストデータパケットに、使用されたトンネルタイプにマッチするカプセル化情報のレイヤを追加してもよい。
IPMSIトンネルは、図1を参照して説明される。IPMSIトンネルは、例えば、PE1、PE1b、PE2、及びPE3の間に確立されたポイントツーマルチプルポイント(pointtomultipoint、P2MP)トンネル、例えば、そのルートノードがPE1であり、リーフノードがPE1b、PE2、及びPE3であるP2MPトンネルであってもよい。P2MPトンネルは、マルチキャストサービスを搬送するために使用される。例えば、PE1によって受信されたすべてのマルチキャストデータパケットは、P2MPトンネルを介してPE2及びPE3に送信されてもよい。確かに、IPMSIトンネルは、代替的に、そのルートノードがPE1bであり、リーフノードがPE1、PE2、及びPE3であるP2MPトンネルであり得る。P2MPトンネルは、マルチキャストサービスを搬送するために使用される。例えば、PE1bによって受信されたすべてのマルチキャストデータパケットは、P2MPトンネルを介してPE2及びPE3に送信されてもよい。
図1は、わかりやすくするためにのみマルチキャストネットワークを示し、マルチキャストネットワークは、代替的に別の構造であってもよく、トンネルタイプは、P2MPトンネルに限定されないことに留意されたい。別の構造のマルチキャストネットワークについては、P2MPトンネルまたはマルチプルポイントツーマルチプルポイント(multiple pointtomultipoint、MP2MP)トンネルは、マルチキャストネットワークの特定の構造に基づいて、複数のPEの間に確立され得る。これは、本出願のこの実施形態では特に限定されない。
図1に示すように、CE1は、PE1に加えてPE1bに接続されている。マルチキャストグループ(S1、G1)に対してユーザによって送信されたマルチキャストジョイン要求を受信した後、PE2は、マルチキャストソースアドレスS1のルートの次のホップを検索する。マルチキャストソースアドレスS1は、CE1に接続されているマルチキャストソースサーバのIPアドレスまたはIPv6アドレスである。MVPNが適用されるネットワークについて、マルチキャストソースアドレスS1のルートであり、PE2によって見つかるルートは、VPNプライベートネットワークルートであり得、ルートの次のホップは、BGPネクストホップである。マルチキャストソースのルートであり、MVPNのテールノードから見つかる次のホップは、「VPNバックボーンを横切る(across the VPN backbone)」次のホップであり、UMHノードとも呼ばれる。
図1に示されるように、CE1の2つの次のホップが存在してよく、それぞれ、PE1及びPE1bである。対応して、PE2はまた、クエリを通じて、マルチキャストソースアドレスS1へのルートの2つの次のホップを取得し得る。PE2は、BGPルート選択ルールに基づいて、S1に対応するマルチキャストソースのアップストリームマルチキャストホップUMHノードとして、PE1及びPE1bのうちの1つを選択する。このプロセスは、UMH選択と呼ばれる。同様に、PE3は、PE3のUMH選択を行う。例えば、PE2は、S1に対応するマルチキャストソースのUMHとしてPE1を選択し、PE3は、S1に対応するマルチキャストソースのUMHとしてPE1bを選択する。図1に示すネットワーク内でマルチキャストサービスが搬送された場合、PE1は受信したマルチキャストデータパケットをPE2及びPE3に送信する。対応して、PE1bは、受信したマルチキャストデータパケットをPE2及びPE3に送信する。CE1によって送信された1つのマルチキャストデータパケットについて、PE2は、マルチキャストデータパケットを繰り返し受信することを理解することができる。例えば、マルチキャストデータパケットは、経路CE1->PE1->P1->PE2を介してPE2に到達し得、マルチキャストデータパケットは、代替的に経路CE1->PE1b->P2->PE2を介してPE2に到達し得る。同様に、PE3は、マルチキャストデータパケットを繰り返し受信する。
この場合、PE2及びPE3はRPFチェックを行い、PE2及びPE3は選択したUMHノードからのパケットのみを転送する。例えば、PE2は、PE1からのパケットを転送し、PE1bからのパケットを破棄し、PE3は、PE1bからのパケットを転送し、PE1からのパケットを破棄する。
従来の技術では、マルチキャストデータパケットを受信した後、テールノード、例えばPE2は、マルチキャストデータパケットに対してRPFチェックを実行してもよく、言い換えれば、マルチキャストデータパケットが、選択されたUMHノードから来るかどうかを決定してもよい。具体的には、プロバイダネットワークがIPv6ネットワークである場合、IPv6ネットワーク内の各ノードのアドレスは、128ビットを使用して表される。したがって、RPFチェックを実行する必要がある場合、テールノードは、UMHノードの第1のアドレスを取得し、マルチキャストデータパケットのカプセル化情報に基づいてヘッドノードの第2のアドレスを取得し、比較を通じて、第1のアドレスが第2のアドレスと同一であるかどうかを学習して、RPFチェックを完了し得る。従来の技術では、VPNが展開されているプロバイダネットワークがIPv6ネットワークである場合に、RPFチェックを完了する必要がある場合、2つの128ビットIPv6アドレス(すなわち、第1のアドレス及び第2のアドレス)を比較する必要があることを学ぶことができる。その結果、RPFチェックは複雑である。加えて、テールノードは、UMHノードの128ビットIPv6アドレス及びヘッドノードの128ビットIPv6アドレスを格納する必要がある。したがって、対応する記憶量は大きい。
これに鑑み、本出願の一実施形態は、VPNが展開されているプロバイダネットワークがIPv6ネットワークである場合のRPFチェックを簡素化するためのRPFチェック方法を提供する。本出願のこの実施形態において提供されるRPFチェック方法を、添付の図面を参照して以下に説明する。
図2は、本出願の一実施形態によるRPFチェック方法の概略フローチャートである。
本出願のこの実施形態において提供されるRPFチェック方法は、IPv6ネットワークに適用されてもよい。IPv6ネットワークは、ヘッドノード及びテールノードを含む。ヘッドノード及びテールノードはそれぞれ、IPv6ネットワーク内のエッジノードである。ヘッドノードは、マルチキャストソースまたはマルチキャストソースに接続されたユーザ機器からマルチキャストデータパケットを受信するノードである。テールノードは、ヘッドノードからマルチキャストデータパケットを受信し、マルチキャストデータパケットをマルチキャストデータパケットの宛先ノードに転送するノードである。例えば、図1のPE1及びPE1bは、ヘッドノードであってよく、PE2及びPE3は、テールノードであってよい。
本出願のこの実施形態において提供されるRPFチェック方法は、例えば、以下のステップ101から104を使用して実装してもよい。
ステップ101:テールノードは、マルチキャストデータパケットをヘッドノードから受信し、マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む。
このステップにおけるマルチキャストデータパケットは、マルチキャストソースによってヘッドノードに送信され、ヘッドノードが対応するカプセル化情報を追加し、テールノードに送信されるパケットである。
上述のように、IPMSIトンネルは、マルチキャストサービスを搬送するために使用され得る。IPMSIトンネルがマルチキャストサービスを搬送するために使用されるとき、マルチキャストデータパケットがトンネルを介して伝送されるプロセスにおいて、ヘッドノードは、使用されたトンネルタイプに基づいて、マルチキャストソースからのマルチキャストデータパケットに、トンネルタイプにマッチするカプセル化情報のレイヤを追加し得る。具体的には、マルチキャストデータパケットを転送する前に、ヘッドノードは、マルチキャストソースからのマルチキャストデータパケットに、ヘッドノードに対応し、使用されたトンネルタイプにマッチするカプセル化情報を追加し得る。例えば、マルチキャストソースノードからマルチキャストデータパケットを受信した後、ヘッドノードは、カプセル化情報をマルチキャストデータパケットの外側カプセル化フィールドに追加し、カプセル化情報が追加されるマルチキャストデータパケットをテールノードに送信し得る。言い換えると、テールノードによって受信されたマルチキャストデータパケットは、カプセル化情報を含むパケットである。
マルチキャストデータパケットを受信した後、テールノードは、対応するユーザ機器にマルチキャストデータパケットを転送するかどうかを決定し得る。本出願のこの実施形態では、マルチキャストデータパケットは、IPv4パケットであってもよく、またはIPv6パケットであってもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態では、マルチキャストデータパケットは、マルチキャストソースアドレス及びマルチキャストグループアドレスを搬送する。マルチキャストソースアドレスは、マルチキャストソースノードのアドレスである。マルチキャストグループアドレスは、マルチキャスト宛先ノードのアドレスである。マルチキャストデータパケットを受信した後、テールノードは、マルチキャストデータパケットを解析して、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を取得し得る。
ステップ102:テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の対応に基づいて第1の識別子を取得し、第1の識別子は、マルチキャストデータパケットに対応するUMHノードを識別するために使用される。
本出願のこの実施形態では、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子の間の対応、すなわち第1の対応を予め記憶する。第1の対応は、マルチキャスト転送情報ベース(multicast forwarding information base、MFIB)テーブルのエントリに格納され得る。したがって、マルチキャストソースアドレス及びマルチキャストグループアドレスを決定した後、テールノードは、第1の対応に基づいて、マルチキャストデータパケットに対応するUMHノードを識別するために使用される第1の識別子を決定し得る。
第1の識別子は、マルチキャストデータパケットに対応するUMHノードのアドレスに類似しており、第1の識別子はまた、マルチキャストデータパケットに対応するUMHノードを一意に識別し得ることに留意されたい。しかしながら、IPv6ネットワークでは、マルチキャストデータパケットに対応するUMHノードのアドレスは128ビットデータである。しかしながら、本出願のこの実施形態では、第1の識別子は、128ビット未満である。
ステップ103:テールノードは、カプセル化情報及び第2の対応に基づいて、ヘッドノードを識別するために使用される第2の識別子を取得する。
本出願のこの実施形態では、テールノードは、カプセル化情報と第2の識別子との間の対応、すなわち第2の対応を事前に記憶する。第2の識別子は、マルチキャストデータパケットに対応するヘッドノードのアドレスに類似しており、第2の識別子はまた、マルチキャストデータパケットに対応するヘッドノードを一意に識別し得る。しかしながら、IPv6ネットワークでは、マルチキャストデータパケットに対応するヘッドノードのアドレスは128ビットデータである。しかしながら、本出願のこの実施形態では、第2の識別子は、128ビット未満である。
ステップ101で説明されるように、マルチキャストデータパケットを受信した後、テールノードは、対応するカプセル化情報を取得するために、マルチキャストデータパケットを解析し得る。解析を通じてカプセル化情報を取得した後、テールノードは、カプセル化情報及び第2の対応に基づいて、ヘッドノードに対応する第2の識別子を決定し得る。第2の対応は、例えば、(MPLS P2MPラベル=Lx、RootIP=Rx)であってもよい。カプセル化情報がLxであると決定した後、第2の識別子がRxであると決定され得る。
カプセル化情報は、マルチキャストサービスを搬送するトンネルのタイプに関するものであることに留意されたい。本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルのタイプは、MPLS P2MPトンネルであってもよく、ビットインデックス明示的レプリケーションマルチプロトコルラベルスイッチング(bit indeexplicit replication MPLS、BIER-MPLS)トンネルであってもよく、またはBIERv6トンネルであってもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合、対応するカプセル化情報は、MPLS P2MPトンネルラベルを含み得る。マルチキャストサービスを搬送するトンネルがBIER-MPLSトンネルである場合、対応するカプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子(Bit Index Forwarding Table Identifier、BIFT-id)を含んでよい。マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合、対応するカプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたIPv6アドレスを含んでよい。
ステップ104:テールノードは、第1の識別子及び第2の識別子に基づいてRPFチェックを実行する。
第1の識別子を決定した後、テールノードはUMHノードを決定し得ることが理解することができる。第2の識別子を決定した後、テールノードは、マルチキャストデータパケットを実際に転送するヘッドノードを決定する。したがって、テールノードは、第1の識別子と第2の識別子とを比較することによってRPFチェックを実行し得る。第1の識別子が第2の識別子に等しい場合、マルチキャストデータパケットがテールノードによって選択されたUMHノードからであることを示し、マルチキャストデータパケットに対して実行されたRPFチェックが成功する。さらに、テールノードは、マルチキャストデータパケットを転送し得る。第1の識別子が第2の識別子と等しくない場合、マルチキャストデータパケットがテールノードによって選択されたUMHノードからではないことを示し、マルチキャストデータパケットに対して実行されたRPFチェックが失敗する。さらに、テールノードは、マルチキャストデータパケットを破棄し得る。
前述の説明から、本出願のこの実施形態において提供される解決策によれば、第1の識別子及び第2の識別子のデータ長はそれぞれ128ビット未満であることを学ぶことができる。したがって、本出願のこの実施形態では、128ビット未満の2つのデータを比較して、RPFチェックを完了し得る。本出願のこの実施形態において提供される解決策によれば、テールノードによって実行されるRPFチェックの計算量を減らすことができることを学ぶことができる。
上述のように、第1の識別子及び第2の識別子はそれぞれ、128ビット以下の値である。実際の適用では、IPv4ネットワーク内のノードのアドレスは、32ビットを使用して表され得、2つの32ビットデータを比較することの複雑さは、通常、テールノードによって許容することができる範囲内にある。したがって、本出願のこの実施形態の一実装では、第1の識別子及び第2の識別子はそれぞれ、32ビット以下の値であり得る。マルチキャストネットワークがIPv6 MVPN(またはIPv6 EVPN)である場合、各ノードのアドレスが128ビットであるため、32ビットを使用してアドレスが記述されるノードが存在しないことを理解することができる。したがって、この場合、第1の識別子及び第2の識別子はそれぞれ、32ビット未満の任意の値を使用して表され得る。
上述のように、プロバイダネットワークは、代替的に、v4v6デュアルスタックネットワークであってもよく、IPv4ネットワーク内のノードのアドレスは、32ビットを使用して表されてもよい。この場合、第1の識別子をIPv4ネットワーク内のノードのアドレスと区別し、第2の識別子をIPv4ネットワーク内のノードのアドレスと区別するために、第1の識別子の値範囲は、IPv4ネットワーク内のノードのアドレス範囲と重複することはできず、それに応じて、第2の識別子の値範囲は、IPv4ネットワーク内のノードのアドレス範囲と重複することはできない。現在、範囲0x7F000000-0x7FFFFFFF内の値は、IPv4ネットワーク内のノードのアドレスとして使用されず、範囲0xE0000000-0xEFFFFFFF内の値は、IPv4ネットワーク内のノードのアドレスとして使用されない。したがって、本出願のこの実施形態の一実装では、第1の識別子及び第2の識別子は、範囲0x7F000000-0x7FFFFFFF内にあり得るか、または第1の識別子及び第2の識別子は、範囲0xE0000000-0xEFFFFFFF内にあり得る。
本出願のこの実施形態では、第1の対応は、事前にテールノードによって生成され得る。テールノードが第1の対応を生成する具体的な実装は、添付の図面を参照して以下に説明される。
図3は、本出願の一実施形態による、第1の対応を生成するための方法のシグナリング相互作用図である。図3の第1の対応を生成する方法は、例えば、以下のステップ201から204を用いて実装してもよい。
ステップ201:カスタマエッジノードは、マルチキャストジョインメッセージをテールノードに送信し、マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。
マルチキャストジョインメッセージは、本出願のこの実施形態では特に限定されず、マルチキャストジョインメッセージは、例えば、プロトコル非依存マルチキャスト(protocol independent multicast、PIM)メッセージであり得る。
ルチキャストジョインメッセージを受信した後、テールノードは、マルチキャストジョインメッセージを解析して、マルチキャストジョインメッセージ内のマルチキャストソースアドレスを取得し、マルチキャストソースアドレスに基づいて、続いて、UMHノードのIPv6アドレスを取得し得る。
ステップ202:テールノードは、マルチキャストソースアドレスに基づいてUMHノードのIPv6アドレスを取得する。
実際の適用では、ヘッドノードは、ルーティングメッセージをテールノードに送信し得る。ルーティングメッセージは、マルチキャストソースアドレス及びUMHノードのIPv6アドレスを搬送する。ルーティングメッセージを受信した後、テールノードは、マルチキャストソースアドレス、UMHノードのIPv6アドレス、及びマルチキャストソースアドレスとUMHノードのIPv6アドレスとの間の対応を記憶し得る。カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信し、解析を通じて、マルチキャストジョインメッセージ内で搬送されたマルチキャストソースアドレスを取得した後、テールノードは、マルチキャストソースアドレスとUMHノードのIPv6アドレスとの間の事前に記憶された対応に基づいて、UMHノードの対応するIPv6アドレスを取得し得る。
ヘッドノードによってテールノードに送信されるルーティングメッセージは、ユニキャストルーティングメッセージであってもよく、またはマルチキャストルーティングメッセージであってもよいことに留意されたい。これは、本出願のこの実施形態では特に限定されない。具体的には、ルーティングメッセージがユニキャストルーティングメッセージである場合、ルーティングメッセージに含まれるマルチキャストソースアドレスは、アドレス範囲またはマルチキャストソースアドレスを含むアドレスプレフィックスであり得る。ユニキャストルーティングメッセージは、ボーダーゲートウェイプロトコルVPNv4(border gateway protocol VPNv4、BGP-VPNv4)ルーティングメッセージ、BGP-VPNv6ルーティングメッセージ、BGP-EVPNルーティングメッセージ、BGP-IPv4-ユニキャストルーティングメッセージ、及びBGP-IPv6-ユニキャストルーティングメッセージのいずれか1つであってもよい。ルーティングメッセージがマルチキャストルーティングメッセージである場合、マルチキャストルーティングメッセージは、BGP-MVPN包括的プロバイダマルチキャストサービスインターフェースオートディスカバリ(IPMSI auto-discovery、IPMSI A-D)ルーティングメッセージ、BGP-MVPN選択的プロバイダマルチキャストサービスインターフェースオートディスカバリ(selective provider multicast service interface auto-discovery、SPMSI A-D)ルーティングメッセージ、またはBGP-EVPN包括的マルチキャストイーサネットタグ(inclusive multicast ethernet tag、IMET)ルーティングメッセージであり得る。
ステップ203:テールノードは、UMHノードのIPv6アドレスに基づいて第1の識別子を取得し、第1の識別子は、UMHノードのIPv6アドレスに対応する。
本出願のこの実施形態の一実装では、UMHノードのIPv6アドレスを取得した後、テールノードは、IPv6アドレスと識別子との間のマッピング関係に基づいて、128ビットIPv6アドレスを128ビット未満の第1の識別子にマッピングし得る。本出願のこの実施形態では、IPv6アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてもよく、またはテールノードがUMHノードのIPv6アドレスを決定した後に生成されてもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態のさらに別の実装では、UMHノードのIPv6アドレスを決定した後、テールノードは、所定の識別子生成ルールに基づいて第1の識別子を生成し得る。
ステップ204:テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子に基づいて第1の対応を取得する。
マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子を決定した後、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子の間で対応を確立してもよく、言い換えれば、第1の対応を確立してもよい。
本出願のこの実施態様の一実装では、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子に加えて、第1の対応は、マルチキャストインスタンスの識別子をさらに含み得る。マルチキャストインスタンスは、テールノードに対応する。言い換えると、マルチキャストインスタンスは、テールノードのマルチキャストインスタンスである。この場合、マルチキャストソースアドレスに基づいてUMHノードのIPv6アドレスを取得する特定の実装では、テールノードは、マルチキャストインスタンスの識別子をさらに決定し得、次いで、テールノードは、マルチキャストインスタンスの識別子及びマルチキャストソースアドレスを参照してUMHノードのIPv6アドレスを検索する。具体的には、テールノードは、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びUMHノードのIPv6アドレスを含む所定の第3の対応に基づいて、UMHノードのIPv6アドレスを決定し得る。対応して、第1の対応を確立するとき、テールノードは、マルチキャストソースアドレス、マルチキャストグループアドレス、第1の識別子、及びマルチキャストインスタンスの識別子の間で第1の対応をさらに確立し得る。
マルチキャストインスタンスの識別子は、本出願のこの実施形態では特に限定されない。MVPNの場合、マルチキャストインスタンスの識別子は、MVPNインスタンスの識別子であってよく、EVPNの場合、マルチキャストインスタンスの識別子は、EVPNインスタンスの識別子であってよい。加えて、実際の適用では、MVPNの場合、マルチキャストジョインメッセージを受信するインターフェースが属する仮想ルーティング転送(virtual routing forwarding、VRF)の識別子を使用して、マルチキャストインスタンスを識別し得る。したがって、MVPNの場合、マルチキャストインスタンスの識別子は、例えば、マルチキャストジョインメッセージを受信するインターフェースが属するVRFの識別子であってもよい。テールノードは、BGP MVPNアドレスファミリのCマルチキャストルートを生成し得、Cマルチキャストルートは、第1の識別子を搬送する。
本出願のこの実施形態では、カプセル化情報と第2の識別子との間の前述の第2の対応は、事前に生成され、テールノードによって記憶されてもよい。テールノードが第1の対応を生成する具体的な実装は、添付の図面を参照して以下に説明される。
上述のように、マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合、対応するカプセル化情報は、MPLS P2MPトンネルラベルを含み得る。マルチキャストサービスを搬送するトンネルがBIER-MPLSトンネルである場合、対応するカプセル化情報は、テールノードのBIFT-idを含み得る。マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合、対応するカプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたIPv6アドレスを含んでよい。
第2の対応を確立する具体的な実装は、マルチキャストサービスを搬送する3つのトンネルについてそれぞれ以下に説明される。
図4は、本出願の一実施形態による、第2の対応を生成するための方法のシグナリング相互作用図である。
図4に示す方法は、マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合に、テールノードが第2の対応を生成するシグナリング相互作用図である。図4に示す方法は、例えば、以下のステップ301から304を使用して実装してもよい。
ステップ301:ヘッドノードは、マルチキャストルーティングメッセージをテールノードに送信し、マルチキャストルーティングメッセージは、ヘッドノードのIPv6アドレス、及びヘッドノードとテールノードとの間のMPLS P2MPトンネルの識別子とを含む。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス、およびヘッドノードとテールノードとの間のMPLS P2MPトンネルの識別子を搬送する。
MPLS P2MPトンネルの識別子は、本出願のこの実施形態では特に限定されない。MPLS P2MPトンネルの識別子は、マルチキャストラベル配布プロトコル(multicast label distribution protocol、mLDP)転送等価クラス(forwarding equivalence class、FEC)、及びリソース予約プロトコルトラフィックエンジニアリング(resource reservation protocol traffic engineering、RSVP-TE)セッション識別子(Session ID)を含む。
マルチキャストルーティングメッセージを受信した後、テールノードは、マルチキャストルーティングメッセージを解析して、ヘッドノードのIPv6アドレス、およびヘッドノードとテールノードとの間のMPLS P2MPトンネルの識別子を取得し得る。
MVPNについて、マルチキャストルーティング情報は、MVPNルーティング情報、例えば、BGP MVPNアドレスファミリルーティング情報であることを理解することができる。EVPNの場合、マルチキャストルーティング情報は、EVPNルーティング情報、例えば、BGP EVPNアドレスファミリルーティング情報である。
ステップ302:テールノードは、MPLS P2MPトンネルの識別子及び第4の対応に基づいてカプセル化情報を取得する。
本出願のこの実施形態では、MPLS P2MPトンネルの識別子を決定した後、テールノードは、第4の対応を参照して、MPLS P2MPトンネルの識別子に対応するカプセル化情報を決定し得る。第4の対応は、MPLS P2MPトンネルの識別子及び対応するカプセル化情報を含み、カプセル化情報は、テールノードによってMPLS P2MPトンネルに割り当てられたラベルを含む。
ステップ303:テールノードは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応する。
ステップ303の実装は、ステップ203のそれと類似することに留意されたい。本出願のこの実施形態の一実装では、ヘッドノードのIPv6アドレスを取得した後、テールノードは、IPv6アドレスと識別子との間のマッピング関係に基づいて、128ビットIPv6アドレスを128ビット未満の第2の識別子にマッピングし得る。本出願のこの実施形態では、IPv6アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてもよく、またはテールノードがUMHノードのIPv6アドレスを決定した後に生成されてもよい。これは、本出願のこの実施形態では特に限定されない。
本出願のこの実施形態のさらに別の実装では、ヘッドノードのIPv6アドレスを決定した後、テールノードは、所定の識別子生成ルールに基づいて第2の識別子を生成し得る。
本明細書では、IPv6アドレスと識別子との間のマッピング関係は、ステップ203でのIPv6アドレスと識別子との間のマッピング関係と同じであることを強調するべきである。IPv6アドレスと識別子との間のマッピング関係は、事前に生成され、テールノードまたは別のメモリに記憶されてよい。IPv6アドレスと識別子との間のマッピング関係は、テールノードがヘッドノードによって送信されたマルチキャストルーティング情報を受信する前または後に生成されてもよい。IPv6アドレスと識別子との間のマッピング関係は、テールノードがUMHノードを決定する前または後に生成されてよい。例えば、テールノードが最初にユーザ機器からマルチキャストジョイン要求を受信し、次いでヘッドノードによって送信されたMVPNルーティング情報を受信する場合、マッピング関係は、テールノードがユーザ機器からマルチキャストジョイン要求を受信した後に生成されてよい。具体的には、テールノードは、マルチキャストルーティング情報に基づいてUMHノードを決定し、次いでマッピング関係を生成してもよく、またはマッピング関係を生成し、次いでUMHノードを決定してもよい。別の例では、テールノードは、ヘッドノードによって送信されたマルチキャストルーティング情報を受信し、次いで、ユーザ機器からマルチキャストジョイン要求を受信する。この場合、マッピング関係は、テールノードがマルチキャストルーティング情報を受信した後に確立されてよい。これは、本出願のこの実施形態では特に限定されない。これに対応して、ここにおける識別子生成ルール及び、ステップ203における識別子生成ルールは、同一のルールである。
ステップ304:テールノードは、カプセル化情報及び第2の識別子に基づいて第2の対応を取得する。
ヘッドノードのIPv6アドレスに対応する第2の識別子、及びMPLS P2MPトンネルの識別子に対応するカプセル化情報を決定した後、テールノードは、カプセル化情報と第2の識別子との間の第2の対応を確立し、記憶してもよく、それにより、その後にRPFチェックを実行するとき、テールノードは、第2の対応に基づいて第2の識別子を決定する。
図5は、本出願の一実施形態による、第2の対応を生成するための別の方法のシグナリング相互作用図である。
図5に示す方法は、マルチキャストサービスを搬送するトンネルがBIER-MPLSトンネルである場合に、テールノードが第2の対応を生成するシグナリング相互作用図である。図5に示す方法は、例えば、以下のステップ401から404を使用して実装してもよい。
ステップ401:ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し、マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス及びBIERトンネルの識別子を含む。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがBIER-MPLSトンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス、およびヘッドノードとテールノードとの間のBIER-MPLSトンネルの識別子を搬送する。
BIER-MPLSトンネルの識別子は、本出願のこの実施形態では特に限定されない。BIER-MPLSトンネルの識別子は、BIERサブドメイン識別子IDを含む。
マルチキャストルーティングメッセージを受信した後、テールノードは、マルチキャストルーティングメッセージを解析して、ヘッドノードのIPv6アドレス及びBIERトンネルの識別子を取得し得る。
MVPNにとって、マルチキャストルーティング情報は、MVPNルーティング情報、例えば、BGP MVPNアドレスファミリルーティング情報であることを理解することができる。EVPNの場合、マルチキャストルーティング情報は、EVPNルーティング情報、例えば、BGP EVPNアドレスファミリルーティング情報である。
ステップ402:テールノードは、BIERトンネルの識別子及び第5の対応に基づいてカプセル化情報を取得する。
本出願のこの実施形態では、BIERトンネルの識別子を決定した後、テールノードは、第5の対応を参照して、BIERトンネルの識別子に対応するカプセル化情報を決定し得る。第5の対応は、BIERトンネルの識別子及び対応するカプセル化情報を含み、カプセル化情報は、テールノードに対応するBIFT-idを含む。
ステップ403:テールノードは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応する。
ステップ404:テールノードは、カプセル化情報及び第2の識別子に基づいて、第2の対応を取得する。
ステップ403及び404は、ステップ303及び304の実装に類似している。具体的な説明については、ステップ303及び304の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
図6は、本出願の一実施形態による、第2の対応を生成するための別の方法のシグナリング相互作用図である。
図6に示す方法は、マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合に、テールノードが第2の対応を生成するシグナリング相互作用図である。図6に示す方法は、例えば、以下のステップ501から503を使用して実装してもよい。
ステップ501:ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し、マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのIPv6アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたIPv6アドレスである。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合、マルチキャストネットワークを介してマルチキャストデータパケットを伝送する前に、ヘッドノードは、マルチキャストルーティング情報をテールノードに送信し得る。マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス及びヘッドノードによって使用されるカプセル化情報を搬送する。カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられたIPv6アドレスである。したがって、マルチキャストルーティング情報を受信した後、テールノードは、マルチキャストルーティング情報を解析して、カプセル化情報を取得し得る。
MVPNについて、マルチキャストルーティング情報は、MVPNルーティング情報、例えば、BGP MVPNアドレスファミリルーティング情報であることを理解することができる。EVPNの場合、マルチキャストルーティング情報は、EVPNルーティング情報、例えば、BGP EVPNアドレスファミリルーティング情報である。
ステップ502:テールノードは、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応する。
ステップ503:テールノードは、カプセル化情報及び第2の識別子に基づいて、第2の対応を取得する。
ステップ502及び503は、ステップ303及び304の実装に類似している。具体的な説明については、ステップ303及び304の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
上記は、マルチキャストサービスを搬送する3つのタイプのトンネルにそれぞれ対応する第2の対応確立方法について説明した。下記は、マルチキャストサービスを搬送する3つのタイプのトンネルについての特定のシナリオを参照して、第2の対応を確立する特定の実装を別途説明する。
第1に、マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合の第2の対応を確立する具体的な実装を説明する。
マルチキャストサービスを搬送するトンネルがMPLS P2MPトンネルである場合、カプセル化情報はMPLS P2MPラベルを含むラベルスタックである。第2の対応は、MPLS_P2MPエントリであり、エントリは、(MPLS P2MPラベル、RootIPv6から取得された第2の識別子)として表され得る。MPLS P2MPラベルはMPLS P2MPトンネルラベルを示し、RootIPv6はヘッドノードのIPv6アドレスを示す。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、マルチキャストラベルディストリビューションプロトコル(multicastLDP、mLDP) P2MPトンネル識別子転送等価クラス(forwarding equivalence class、FEC)を適用し、FECは、ヘッドノードのIPv6アドレス1及びトンネルIDを含む。様々なトンネルIDが、同じノードの様々なmLDP P2MPトンネルに使用される。ヘッドノードは、テールノードへの包括的プロバイダマルチキャストサービスインターフェース(包括的PMSI、IPMSI)ルートを公開する。ルートはPMSIトンネル属性(PMSI tunnel attribute、PTA)を搬送し、PTAは適用されたFECを搬送する。ヘッドノードは、PTAを搬送するIPMSIルートを公開し、PTAは通常、構成によってトリガされる。例えば、送信者有効(sender-enable)は、このノードがヘッドノードであることを示すためにヘッドノードに対して構成される。ヘッドノードはIPMSIトンネルで構成され、特定のタイプのIPMSIトンネルはmLDP等である。
IPMSIルーティングメッセージを受信した後、テールノードは、FEC情報に基づいてmLDP P2MPトンネルを確立する。具体的には、テールノードは、ラベル、すなわちMPLS P2MPラベルをFECに割り当て、MPLS P2MPラベルとヘッドノードのIPv6アドレス1の第2の識別子、すなわちMPLS_P2MPエントリとの間の対応を確立する。加えて、テールノードは、FEC内のヘッドノードのアドレス情報に基づいて、このアドレスのルートの次のホップを検索し、ネクストホップルータにマッピングメッセージを送信する。マッピングメッセージには、FEC及びテールノードによって割り当てられたMPLS P2MPラベルを搬送する。ネクストホップルータは、全体の経路が確立されるまで、FECによって識別されるヘッドノードの方向の次のホップにマッピングメッセージを送信し続ける。
以下では、マルチキャストサービスを搬送するトンネルがBIER-MPLSトンネルである場合に、第2の対応を確立する具体的な実装について説明する。
本出願のこの実施形態では、マルチキャストサービスを搬送するトンネルがBIER-MPLSトンネルである場合、カプセル化情報は、BIER転送ルータヘッドノード識別子及びBIER MPLSラベルを含む。BIER転送ルータヘッドノード識別子は、具体的には、BIER-MPLSヘッダのBIFT-idフィールドに含まれるサブドメイン情報及びBFIR-idフィールドであってもよい。対応して、第2の対応は、MVPN_ILMBIERエントリである。MVPN_ILMBIERエントリは、(サブドメイン、BFIR-id、RootIPv6から取得された第2の識別子)として表され得る。エントリは、別のフィールドを有してもよい。例えば、MVPN_ILMBIERエントリは、(サブドメイン、BFIR-id、VPNラベル、RootIPv6から取得された第2の識別子、VRF)として表され得る。これは、本出願のこの実施形態では特に限定されない。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、IPMSIルートまたは選択的プロバイダマルチキャストサービスインターフェース(Selective Provider Multicast Service Interface、SPMSI)ルート及びPTAをテールノードに送信する。IPMSIまたはSPMSIルーティング情報は、ヘッドノードのIPv6アドレス1を含み、PTAは、サブドメイン、BFR-id情報、及びIPv6ビット転送ルータプレフィックス(bit forwarding router prefix、BFR-prefix)アドレス2を含む。加えて、IPMSIルートはさらに、ルートターゲット(route target,RT)拡張コミュニティ属性を搬送する。IPMSIルートまたは選択的プロバイダマルチキャストサービスインターフェースルート及びPTAを受信した後、テールノードは、RT拡張コミュニティ属性に基づいてテールノードの対応するVRFを学習し、MVPN_ILMBIERエントリを確立する。MVPN_ILMBIERエントリは、(サブドメイン、BFIR-id、VPNラベル、RootIP<第2の識別子>、VRF)として表される。BFIR-idは、ヘッドノードからのルーティングメッセージ内のPTAのBFR-idである。サブドメイン、BFIR-id、及びVPNラベルは、パケットの外部カプセル化から取得され得る情報である。例えば、サブドメインは、パケットのBIERヘッダの最初の20ビットであるBIFT-idフィールドから取得されてもよく、BFIR-idは、BIERヘッダ内のBFIR-idフィールドから取得され、VPNラベルは、パケットのBIERヘッダの後のラベルから取得される。RootIPv6から取得される第2の識別子は、ヘッドノードのIPMSIルートのルーティング情報内のIPv6アドレス1から取得される第2の識別子であり、BFRプレフィックスアドレスではない。RootIPv6アドレスはまた、UMHルート選択中に選択され得るヘッドノードのアドレスである。
最後に、マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合の第2の対応を確立する具体的な実装を説明する。
マルチキャストサービスを搬送するトンネルがBIERv6トンネルである場合、カプセル化情報は、外部IPv6ヘッダ及びIPv6拡張ヘッダ内に位置するBIERヘッダであり、第2の対応はMVPN_ILMBIERv6エントリである。MVPN_ILMBIERv6エントリは、(MVPNインスタンスを識別するIPv6アドレス、RootIPv6から取得された第2の識別子)として表され得る。エントリは、別のフィールドを有し得、具体的には、(MVPNインスタンスを識別するIPv6アドレス、RootIPv6から取得された第2の識別子、VRF)として表される。これは、本出願のこの実施形態では特に限定されない。このエントリを確立するプロセスは次のとおりである。
ヘッドノードは、MVPNインスタンスを識別するために使用されるIPMSIまたはSPMSIルート、PTA属性、及びIPv6アドレス(プレフィックス-SID属性内)をテールノードに送信する。IPMSIまたはSPMSIルーティング情報は、ヘッドノードのIPv6アドレス1、サブドメインを搬送するPTA、BFR-id情報、及びIPv6 BFR-プレフィックスアドレス2を含む。加えて、ルートはさらに、RT拡張コミュニティ属性及びプレフィックス-SID属性を搬送する。プレフィックス-SID属性は、VPNインスタンスを識別するIPv6アドレス3を含む。IPMSまたはSPMSIルート、PTA属性、及びIPv6アドレスを受信した後、テールノードは、RT拡張コミュニティ属性に基づいてテールノードの対応するVRFを学習し、MVPN_ILMBIERエントリを確立する。MVPN_ILMBIERv6エントリは、(マルチキャストインスタンスを識別するIPv6アドレス、RootIP<第2の識別子>、VRF)として表され得る。MVPNを識別するIPv6アドレスは、ヘッドノードからのルーティングメッセージ内のプレフィックス-SID属性のIPv6アドレス3、及びマルチキャストデータパケットのソースアドレス内で搬送されるアドレスである。RootIPv6から取得した第2の識別子は、ヘッドノードのIPMSIルートのルーティング情報のIPv6アドレス1に対応する第2の識別子であり、ヘッドノードを表す。例えば、同じ第2の識別子が、複数のMVPNインスタンスに対して使用されてもよい。第2の識別子はまた、ヘッドノードを識別するために使用され得、UMHルート選択中に選択される第2の識別子である。
前述の実施形態に提供されるRPFチェック方法に基づいて、本出願の一実施形態は、RPFチェック装置をさらに提供し、装置は、テールノードに適用されてもよい。図7は、本出願の一実施形態によるRPFチェック装置の構造の概略図である。
図7に示されるRPFチェック装置700は、前述の実施形態においてテールノードによって実行されるRPFチェック方法を実行するように構成され、具体的には、方法は、図2から図6においてテールノードによって実行されるステップを含んでよい。例えば、RPFチェック装置700は、受信ユニット701、取得ユニット702、及びRPFチェックユニット703を含んでもよい。
受信ユニット701は、ヘッドノードからマルチキャストデータパケットを受信するように構成される。マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む。
取得ユニット702は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の対応に基づいて第1の識別子を取得するように構成される。第1の対応は、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子を含み、第1の識別子は、マルチキャストデータパケットに対応するアップストリームマルチキャストホップUMHノードを識別するために使用される。
取得ユニット702は、カプセル化情報及び第2の対応に基づいて第2の識別子を取得するようにさらに構成される。第2の対応は、カプセル化情報及び第2の識別子を含み、第2の識別子は、ヘッドノードを識別するために使用され、第1の識別子及び第2の識別子はそれぞれ128ビット未満である。
RPFチェックユニット703は、第1の識別子及び第2の識別子に基づいてRPFチェックを行うように構成される。
一実装では、受信ユニット701は、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成される。マルチキャストジョインメッセージは、マルチキャストソースアドレス及びマルチキャストグループアドレスを含む。
取得ユニット702は、さらに、マルチキャストソースアドレスに基づいてUMHノードのIPv6アドレスを取得し、UMHノードのIPv6アドレスに基づいて第1の識別子を取得し、第1の識別子は、UMHノードのIPv6アドレスに対応し、マルチキャストソースアドレス、マルチキャストグループアドレス、及び第1の識別子に基づいて第1の対応を取得するように構成される。
一実装では、第1の対応は、マルチキャストインスタンスの識別子をさらに含み、取得ユニット702は、
マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、マルチキャストソースアドレス、第3の対応、及びマルチキャストインスタンスの識別子に基づいてUMHノードのIPv6アドレスを取得し、第3の対応は、マルチキャストソースアドレス、マルチキャストインスタンスの識別子、及びUMHノードのIPv6アドレスを含み、マルチキャストソースアドレス、マルチキャストグループアドレス、マルチキャストインスタンスの識別子、及び第1の識別子に基づいて第1の対応を取得するように特に構成される。
一実装では、マルチキャストインスタンスの識別子は、仮想ルーティング転送VRFの識別子またはイーサネット仮想プライベートネットワークEVPNインスタンスの識別子を含む。
一実装では、受信ユニット701は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス、及びヘッドノードとテールノードとの間のマルチプロトコルラベルスイッチングMPLSポイントツーマルチポイントP2MPトンネルの識別子を含む。
取得ユニット702は、さらに、MPLS P2MPトンネルの識別子及び第4の対応に基づいてカプセル化情報を取得し、第4の対応は、MPLS P2MPトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードによってMPLS P2MPトンネルに割り当てられたラベルを含み、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応し、カプセル化情報及び第2の識別子に基づいて第2の対応を取得するように構成される。
一実装では、受信ユニット701は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、ヘッドノードのIPv6アドレス、及びヘッドノードとテールノードとの間のビットインデックス明示的レプリケーションBIERトンネルの識別子を含み、BIERトンネルの識別子は、BIERサブドメイン識別子IDを含む。
取得ユニット702は、さらに、BIERトンネルの識別子及び第5の対応に基づいてカプセル化情報を取得し、第5の対応は、BIERトンネルの識別子及びカプセル化情報を含み、カプセル化情報は、テールノードに対応するビットインデックス転送テーブル識別子BIFT-idを含み、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子は、ヘッドノードのIPv6アドレスに対応し、カプセル化情報及び第2の識別子に基づいて第2の対応を取得するように構成される。
一実装では、受信ユニット701は、ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成される。マルチキャストルーティング情報は、カプセル化情報及びヘッドノードのIPv6アドレスを含み、カプセル化情報は、ヘッドノードによってテールノードのマルチキャストインスタンスに割り当てられるIPv6アドレスである。
取得ユニット702は、さらに、ヘッドノードのIPv6アドレスに基づいて第2の識別子を取得し、第2の識別子はヘッドノードのIPv6アドレスに対応し、カプセル化情報及び第2の識別子に基づいて第2の対応を取得するように構成される。
一実装では、マルチキャストルーティング情報は、マルチキャスト仮想プライベートネットワークMVPNルーティング情報またはイーサネット仮想プライベートネットワークEVPNルーティング情報を含む。
一実装では、第1の識別子及び第2の識別子はそれぞれ、32ビット以下の値である。
一実装では、第1の識別子及び第2の識別子は、次のアドレス範囲、
0x7F000000-0x7FFFFFFFまたは0xE0000000-0xEFFFFFFF
のうちの1つの範囲内にある。
装置700は、前述の方法の実施形態で提供されるRPFチェック方法に対応する装置であるため、装置700の各ユニットの具体的な実装は、前述の方法の実施形態のそれと同様の概念を有する。したがって、装置700の各ユニットの具体的な実装については、前述の方法の実施形態の説明箇所を参照されたい。詳細については、ここでは再度説明しない。
本出願の一実施形態は、RPFチェックデバイスをさらに提供する。デバイスは、プロセッサ及びメモリを含む。
メモリは、命令を格納するように構成される。
プロセッサは、メモリ内の命令を実行し、前述の方法の実施形態では、テールノードによって実行されるRPFチェック方法を実行するように構成される。
本出願のこの実施形態で提供されるRPFチェックデバイスのハードウェア構造は、図8に示される構造であってもよいことに留意されたい。図8は、本出願の一実施形態によるRPFチェックデバイス800の構造の概略図である。
図8を参照されたい。RPFチェックデバイス800は、プロセッサ810、通信インターフェース820、及びメモリ830を含む。デバイス800内に1つまたは複数のプロセッサ810が存在し得る。図8において、1つのプロセッサが例として使用される。本出願のこの実施形態では、プロセッサ810、通信インターフェース820、及びメモリ830は、バスシステムを介して、または別の方法で接続されてもよい。図8では、プロセッサ810、通信インターフェース820、及びメモリ830がバスシステム840を介して接続される例が使用される。
プロセッサ810は、中央処理装置(central processing unit、CPU)、ネットワークプロセッサ(network processor、NP)、またはCPU及びNPの組み合わせであってもよい。プロセッサ810は、ハードウェアチップをさらに含んでもよい。ハードウェアチップは、特定用途向け集積回路(application-specific integrated circuit、ASIC)、プログラマブル論理デバイス(programmable logic device、PLD)、またはそれらの組み合わせであり得る。PLDは、複合プログラム可能論理デバイス(complex programmable logic device、CPLD)、フィールドプログラマブルゲートアレイ(field-programmable gate array、FPGA)、汎用アレイロジック(generic array logic、GAL)、またはそれらの任意の組み合わせであり得る。
メモリ830は、揮発性メモリ(volatile memory)、例えば、ランダムアクセスメモリ(random-access memory、RAM)を含み得る。メモリ830は、あるいは、不揮発性メモリ(non-volatile memory)、例えば、フラッシュメモリ(flash memory)、ハードディスクドライブ(hard disk drive、HDD)、またはソリッドステートドライブ(solid-state drive、SSD)を含んでもよい。メモリ830は、前述のタイプのメモリの組み合わせをさらに含み得る。
メモリ830は、前述の実施形態において、第1の対応、第2の対応、第3の対応、第4の対応、及び第5の対応を記憶してもよい。
任意選択で、メモリ830は、オペレーティングシステム及びプログラム、実行可能モジュールもしくはデータ構造、またはそのサブセット、またはその拡張セットを格納する。プログラムは、様々な動作を実装するために使用される様々な動作命令を含み得る。オペレーティングシステムは、様々な基本サービスを実装し、ハードウェアベースのタスクを処理するために使用される、様々なシステムプログラムを含み得る。プロセッサ810は、本出願の実施形態において提供されるRPFチェック方法を実装するために、メモリ830内のプログラムを読み取り得る。
バスシステム840は、周辺コンポーネント相互接続(peripheral component interconnect、PCI)バス、拡張業界標準アーキテクチャ(extended industry standard architecture、EISA)バスなどであってもよい。バスシステム840は、アドレスバス、データバス、制御バスなどに分類され得る。表現を容易にするために、図8のバスシステムを表すために、1つの太い線のみが使用されるが、これは、1つのバスのみ、または1つのタイプのバスのみがあることを意味しない。
本出願の実施形態は、命令を含むコンピュータ可読記憶媒体をさらに提供する。命令がコンピュータ上で実行されるとき、コンピュータは、テールノードによって実行され、方法の実施形態で提供されるRPFチェック方法を実行することが可能である。
本出願の実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、テールノードによって実行され、方法の実施形態で提供されるRPFチェック方法を実行することが可能である。
本出願の明細書、特許請求の範囲、及び添付の図面において、用語「第1の」、「第2の」、「第3の」、「第4の」等(存在する場合)は、類似のオブジェクトを区別することを意図しているが、必ずしも特定の順序または配列を示すものではない。このように呼ばれるデータは、本明細書に記載の実施形態が、本明細書に例示または記載される順序とは異なる順序で実施することができるように、適切な状況で交換可能であることを理解されたい。さらに、用語「含む(include)」、「含む(contain)」、及び任意の他の変形例は、非排他的包含、例えば、ステップまたは単位のリストを含むプロセス、方法、システム、製品、またはデバイスをカバーすることを意味し、これらのステップまたは単位に必ずしも限定されないが、そのようなプロセス、方法、製品、またはデバイスに明示的に列挙されていない、または固有の他のステップまたは単位を含み得る。
便利で簡単な説明の目的で、前述のシステム、装置、及びユニットの詳細な作業プロセスについて、前述の方法の実施形態における対応するプロセスを参照すること、及び詳細については本明細書では再度説明しないことは、当業者によって明確に理解され得る。
本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、及び方法は、他の方法で実施され得ることを理解されたい。例えば、説明した装置の実施形態は単なる例にすぎない。例えば、ユニットへの分割は、単なる論理モジュール分割であり、実際の実装中は他の分割であってもよい。例えば、複数のユニットまたはコンポーネントを組み合わせたり、別のシステムに統合したり、またはいくつかの機能を無視したり、実行しなかったりし得る。さらに、表示または説明されている相互結合または直接結合または通信接続は、いくつかのインターフェースを使用して実装し得る。装置またはユニット間の間接的な結合または通信接続は、電子的、機械的、または他の形態で実装し得る。
別個の部分として説明されるユニットは、物理的に分離されている場合とされていない場合があり、ユニットとして表示される部分は、物理ユニットである場合とそうでない場合があり、1つの位置に配置されている場合と複数のネットワークユニット上に分散されている場合がある。ユニットのいくつかまたはすべては、実施形態の解決策の目的を達成するための実際の要件に基づいて取得され得る。
さらに、本出願の実施形態におけるモジュールユニットは、1つの処理ユニットに統合され得るか、またはユニットのそれぞれが物理的に単独で存在し得るか、または2つ以上のユニットが1つのユニットに統合される。統合されたユニットは、ハードウェアの形で実装されてもよく、ソフトウェアモジュールユニットの形で実装されてもよい。
統合されたユニットがソフトウェアモジュールユニットの形で実装され、独立した製品として販売または使用される場合、統合されたユニットは、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づいて、本出願の実施形態の技術的解決策は基本的に、または先行技術に寄与する部分、または技術的解決策のすべてまたは一部は、ソフトウェア製品の形で実装され得る。コンピュータソフトウェア製品は、記憶媒体に格納され、コンピュータデバイス(パーソナルコンピュータ、サーバ、またはネットワークデバイスであり得る)に、本出願の実施形態で説明された方法のステップのすべてまたはいくつかを実行するように指示するためのいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、読み取り専用メモリ(ROM,Read-Only Memory)、ランダムアクセスメモリ(RAM,Random Access Memory)、磁気ディスク、または光ディスクなどの、プログラムコードを格納できる任意の媒体を含む。
当業者は、前述の1つ以上の実施例において、本発明に記載される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせによって実装され得ることを認識すべきである。ソフトウェアが機能を実装するために使用されるとき、機能は、コンピュータ可読媒体に記憶されてもよく、またはコンピュータ可読媒体に1つ以上の命令またはコードとして伝送されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を含み、通信媒体は、コンピュータプログラムをある場所から別の場所に伝送することを可能にする任意の媒体を含む。記憶媒体は、汎用コンピュータまたは専用コンピュータにアクセス可能な任意の利用可能な媒体であり得る。
上記の特定の実装では、本発明の目的、技術的解決策、及び有益な効果をさらに詳細に説明する。上記の説明は、本発明の特定の実装に過ぎないことを理解されたい。
結論として、前述の実施形態は、本出願の技術的解決策を説明することのみを意図しており、本出願を限定することを意図していない。本出願は、前述の実施形態を参照して詳細に説明されるが、当業者は、本出願の実施形態の技術的解決策の範囲から逸脱することなく、前述の実施形態に記載された技術的解決策に修正を加え、またはそのいくつかの技術的特徴に等価な置き換えを行ってもよいことを理解すべきである。

Claims (20)

  1. リバースパス転送RPFチェック方法であって
    テールノードによって、ヘッドノードからマルチキャストデータパケットを受信することであって、前記マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス、及びカプセル化情報を含む、ことと、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、及び第1の対応に基づいて第1の識別子を取得することであって、前記第1の対応は、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス及び前記第1の識別子を含み、前記第1の識別子は、前記マルチキャストデータパケットに対応するアップストリームマルチキャストホップUMHノードを識別するために使用される、ことと、
    前記テールノードによって、前記カプセル化情報及び第2の対応に基づいて第2の識別子を取得することであって、前記第2の対応は、前記カプセル化情報及び前記第2の識別子を含み、前記第2の識別子は、前記ヘッドノードを識別するために使用される、ことと、
    前記テールノードによって、前記第1の識別子及び前記第2の識別子に基づいてRPFチェックを実行することと、
    を含む方法。
  2. 前記テールノードによって、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信することであって、前記マルチキャストジョインメッセージは、前記マルチキャストソースアドレス及び前記マルチキャストグループアドレスを含む、ことと、
    前記テールノードによって、前記マルチキャストソースアドレスに基づいて前記UMHノードのアドレスを取得することと、
    前記テールノードによって、前記UMHノードの前記アドレスに基づいて前記第1の識別子を取得することであって、前記第1の識別子は、前記UMHノードの前記アドレスに対応する、ことと、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス及び前記第1の識別子に基づいて前記第1の対応を取得することと、
    をさらに含む、請求項1に記載の方法。
  3. 前記第1の対応が、マルチキャストインスタンスの識別子をさらに含み、前記テールノードによって、前記マルチキャストソースアドレスに基づいて前記UMHノードのアドレスを取得することが、
    前記テールノードによって、前記マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定することと、
    前記テールノードによって、前記マルチキャストソースアドレス、第3の対応及び前記マルチキャストインスタンスの前記識別子に基づいて前記UMHノードの前記アドレスを取得することであって、前記第3の対応は、前記マルチキャストソースアドレス、前記マルチキャストインスタンスの前記識別子及び前記UMHノードの前記アドレスを含む、ことと、を含み、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス及び前記第1の識別子に基づいて前記第1の対応を取得することが、
    前記テールノードによって、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、前記マルチキャストインスタンスの前記識別子及び前記第1の識別子に基づいて前記第1の対応を取得すること、を含む、請求項2に記載の方法。
  4. 前記マルチキャストインスタンスの前記識別子は、仮想ルーティング転送VRFの識別子またはイーサネット仮想プライベートネットワークEVPNインスタンスの識別子を含む、請求項3に記載の方法。
  5. 前記テールノードによって、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信することであって、前記マルチキャストルーティング情報は、前記ヘッドノードのアドレス、及び前記ヘッドノードと前記テールノードとの間のマルチプロトコルラベルスイッチングMPLSポイントツーマルチポイントP2MPトンネルの識別子を含む、ことと、
    前記テールノードによって、前記MPLS P2MPトンネルの前記識別子及び第4の対応に基づいて前記カプセル化情報を取得することであって、前記第4の対応は、前記MPLS P2MPトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードによって前記MPLS P2MPトンネルに割り当てられたラベルを含む、ことと、
    前記テールノードによって、前記ヘッドノードの前記アドレスに基づいて前記第2の識別子を取得することであって、前記第2の識別子は、前記ヘッドノードの前記アドレスに対応する、ことと、
    前記テールノードによって、前記カプセル化情報及び前記第2の識別子に基づいて前記第2の対応を取得することと、
    をさらに含む、請求項1から4のいずれか1項に記載の方法。
  6. 前記テールノードによって、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信することであって、前記マルチキャストルーティング情報は、前記ヘッドノードのアドレス、及び前記ヘッドノードと前記テールノードとの間のビットインデックス明示的レプリケーションBIERトンネルの識別子を含み、前記BIERトンネルの前記識別子は、BIERサブドメイン識別子IDを含む、ことと、
    前記テールノードによって、前記BIERトンネルの前記識別子及び第5の対応に基づいて前記カプセル化情報を取得することであって、前記第5の対応は、前記BIERトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードに対応するビットインデックス転送テーブル識別子BIFT-idを含む、ことと、
    前記テールノードによって、前記ヘッドノードの前記アドレスに基づいて前記第2の識別子を取得することであって、前記第2の識別子は、前記ヘッドノードの前記アドレスに対応する、ことと、
    前記テールノードによって、前記カプセル化情報及び前記第2の識別子に基づいて前記第2の対応を取得することと、
    をさらに含む、請求項1から4のいずれか1項に記載の方法。
  7. 前記テールノードによって、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信することであって、前記マルチキャストルーティング情報は、前記カプセル化情報及び前記ヘッドノードのアドレスを含み、前記カプセル化情報は、前記ヘッドノードによって前記テールノードのマルチキャストインスタンスに割り当てられたアドレスである、ことと、
    前記テールノードによって、前記ヘッドノードの前記アドレスに基づいて前記第2の識別子を取得することであって、前記第2の識別子は、前記ヘッドノードの前記アドレスに対応する、ことと、
    前記テールノードによって、前記カプセル化情報及び前記第2の識別子に基づいて前記第2の対応を取得することと、
    をさらに含む、請求項1から4のいずれか1項に記載の方法。
  8. 前記マルチキャストルーティング情報が、マルチキャスト仮想プライベートネットワークMVPNルーティング情報またはイーサネット仮想プライベートネットワークEVPNルーティング情報を含む、請求項5から7のいずれか1項に記載の方法。
  9. 前記第1の識別子及び前記第2の識別子はそれぞれ、32ビット以下の値である、請求項1から8のいずれか1項に記載の方法。
  10. 前記第1の識別子及び前記第2の識別子が、次のアドレス範囲、
    0x7F000000-0x7FFFFFFFまたは0xE0000000-0xEFFFFFFF
    のうちの1つの範囲内にある、請求項9に記載の方法。
  11. リバースパス転送(RPFチェック装置であって、
    ヘッドノードからマルチキャストデータパケットを受信するように構成された受信ユニットであって、前記マルチキャストデータパケットは、マルチキャストソースアドレス、マルチキャストグループアドレス及びカプセル化情報を含む、受信ユニットと、
    前記マルチキャストソースアドレス、前記マルチキャストグループアドレス及び第1の対応に基づいて第1の識別子を取得するように構成された取得ユニットあって、前記第1の対応は、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス及び前記第1の識別子を含み、前記第1の識別子は、前記マルチキャストデータパケットに対応するアップストリームマルチキャストホップUMHノードを識別するために使用される、取得ユニットと、
    前記取得ユニットは、前記カプセル化情報及び第2の対応に基づいて第2の識別子を取得するようにさらに構成され、前記第2の対応は、前記カプセル化情報及び前記第2の識別子を含み、前記第2の識別子は、前記ヘッドノードを識別するために使用され
    前記第1の識別子及び前記第2の識別子に基づいてRPFチェックを行うように構成されたRPFチェックユニットと、
    を備えた装置。
  12. 前記受信ユニットは、カスタマエッジノードによって送信されたマルチキャストジョインメッセージを受信するようにさらに構成され、前記マルチキャストジョインメッセージは、前記マルチキャストソースアドレス及び前記マルチキャストグループアドレスを含み、
    前記取得ユニットは、前記マルチキャストソースアドレスに基づいて前記UMHノードのアドレスを取得し、前記UMHノードの前記アドレスに基づいて前記第1の識別子を取得し、前記第1の識別子は、前記UMHノードの前記アドレスに対応し、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス及び前記第1の識別子に基づいて前記第1の対応を取得するようにさらに構成された、請求項11に記載の装置。
  13. 前記第1の対応は、マルチキャストインスタンスの識別子をさらに含み、前記取得ユニットは、
    前記マルチキャストジョインメッセージを受信するインターフェースが属するマルチキャストインスタンスの識別子を決定し、前記マルチキャストソースアドレス、第3の対応及び前記マルチキャストインスタンスの前記識別子に基づいて前記UMHノードの前記アドレスを取得し、前記第3の対応は、前記マルチキャストソースアドレス、前記マルチキャストインスタンスの前記識別子及び前記UMHノードの前記アドレスを含み、前記マルチキャストソースアドレス、前記マルチキャストグループアドレス、前記マルチキャストインスタンスの前記識別子及び前記第1の識別子に基づいて前記第1の対応を取得するように構成された、請求項12に記載の装置。
  14. 前記マルチキャストインスタンスの前記識別子は、仮想ルーティング転送VRFの識別子またはイーサネット仮想プライベートネットワークEVPNインスタンスの識別子を含む、請求項13に記載の装置。
  15. 前記受信ユニットは、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、前記マルチキャストルーティング情報は、前記ヘッドノードのアドレス、及び前記ヘッドノードと前記テールノードとの間のマルチプロトコルラベルスイッチングMPLSポイントツーマルチポイントP2MPトンネルの識別子を含み、
    前記取得ユニットは、前記MPLS P2MPトンネルの識別子及び第4の対応に基づいてカプセル化情報を取得し、前記第4の対応は、前記MPLS P2MPトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードによって前記MPLS P2MPトンネルに割り当てられたラベルを含み、前記ヘッドノードの前記アドレスに基づいて前記第2の識別子を取得し、前記第2の識別子は、前記ヘッドノードの前記アドレスに対応し、前記カプセル化情報及び前記第2の識別子に基づいて前記第2の対応を取得するようにさらに構成された、請求項11から14のいずれか1項に記載の装置。
  16. 前記受信ユニットは、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、前記マルチキャストルーティング情報は、前記ヘッドノードのアドレス、及び前記ヘッドノードと前記テールノードとの間のビットインデックス明示的レプリケーションBIERトンネルの識別子を含み、前記BIERトンネルの前記識別子は、BIERサブドメイン識別子IDを含み、
    前記取得ユニットは、前記BIERトンネルの前記識別子及び第5の対応に基づいて前記カプセル化情報を取得し、前記第5の対応は、前記BIERトンネルの前記識別子及び前記カプセル化情報を含み、前記カプセル化情報は、前記テールノードに対応するビットインデックス転送テーブル識別子BIFT-idを含み、前記ヘッドノードの前記アドレスに基づいて前記第2の識別子を取得し、前記第2の識別子は、前記ヘッドノードの前記アドレスに対応し、前記カプセル化情報及び前記第2の識別子に基づいて前記第2の対応を取得するようにさらに構成された、請求項11から14のいずれか1項に記載の装置。
  17. 前記受信ユニットは、前記ヘッドノードによって送信されたマルチキャストルーティング情報を受信するようにさらに構成され、前記マルチキャストルーティング情報は、前記カプセル化情報及び前記ヘッドノードのアドレスを含み、前記カプセル化情報は、前記ヘッドノードによって前記テールノードのマルチキャストインスタンスに割り当てられたアドレスであり、
    前記取得ユニットは、前記ヘッドノードの前記アドレスに基づいて前記第2の識別子を取得し、前記第2の識別子は前記ヘッドノードの前記アドレスに対応し、前記カプセル化情報及び前記第2の識別子に基づいて前記第2の対応を取得するようにさらに構成された、請求項11から14のいずれか1項に記載の装置。
  18. 前記マルチキャストルーティング情報が、マルチキャスト仮想プライベートネットワークMVPNルーティング情報またはイーサネット仮想プライベートネットワークEVPNルーティング情報を含む、請求項15から17のいずれか1項に記載の装置。
  19. 前記第1の識別子及び前記第2の識別子はそれぞれ、32ビット以下の値である、請求項11から18のいずれか1項に記載の装置。
  20. 前記第1の識別子及び前記第2の識別子が、次のアドレス範囲、
    0x7F000000-0x7FFFFFFFまたは0xE0000000-0xEFFFFFFF
    のうちの1つの範囲内にある、請求項19に記載の装置。
JP2022518284A 2019-09-23 2020-09-23 リバースパス転送rpfチェック方法及び装置 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 JP2022548987A (ja) 2022-11-22
JP7397178B2 true 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 リバースパス転送rpfチェック方法及び装置

Country Status (6)

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

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114095305A (zh) * 2020-07-21 2022-02-25 华为技术有限公司 Bier报文转发的方法、设备以及系统
CN113992565B (zh) * 2021-09-29 2023-11-07 新华三大数据技术有限公司 一种组播报文处理方法及装置
WO2024016869A1 (zh) * 2022-07-21 2024-01-25 华为技术有限公司 一种组播配置方法及装置

Citations (4)

* 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
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 (21)

* 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
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 杭州华三通信技术有限公司 一种组播流量路径的控制方法和装置
CN101588296B (zh) * 2009-06-16 2011-09-07 杭州华三通信技术有限公司 一种转发组播报文的方法、头节点和尾节点
CN101616015B (zh) * 2009-07-24 2011-08-10 中兴通讯股份有限公司 一种获取ip网络中组播拓扑信息的方法和装置
US8605722B1 (en) * 2009-12-10 2013-12-10 Juniper Networks, Inc. Deadlock-resistant fabric tree replication in a network device
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 杭州华三通信技术有限公司 一种逆向路径转发检查方法和设备
CN103916905A (zh) * 2013-01-06 2014-07-09 中兴通讯股份有限公司 组播源的注册、组播路径的建立方法及装置

Patent Citations (4)

* 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 华为技术有限公司 实现组播的方法、路由器及系统
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
US20220217075A1 (en) 2022-07-07
CN113726667B (zh) 2022-11-18
WO2021057788A1 (zh) 2021-04-01
EP4024774A1 (en) 2022-07-06
CN111917622A (zh) 2020-11-10
CN111917622B (zh) 2021-08-03
CN113726667A (zh) 2021-11-30
EP4024774A4 (en) 2022-11-09
KR20220062347A (ko) 2022-05-16
JP2022548987A (ja) 2022-11-22

Similar Documents

Publication Publication Date Title
US11374862B2 (en) Packet sending and processing method and apparatus, PE node, and node
JP7208386B2 (ja) パケット転送方法、パケット送信装置、およびパケット受信装置
JP7397178B2 (ja) リバースパス転送rpfチェック方法及び装置
EP3896923A1 (en) Bier packet sending method and apparatus
JP6189942B2 (ja) 個別管理方式を使用する仮想転送インスタンスの遠端アドレスへのvlanタグ付きパケットのルーティング
US20210243111A1 (en) Supporting multicast communications
WO2021258754A1 (zh) 报文指示方法、装置、设备和存储介质
US11627070B2 (en) Data packet processing method and apparatus, storage medium, and electronic device
WO2019214589A1 (zh) 组播数据传输方法、相关装置及系统
US20070147372A1 (en) Method for Implementing Multicast in Virtual Router-Based Virtual Private Network
JP7405923B2 (ja) 通信方法、デバイス、及びシステム
JP2006197613A (ja) Mplsマルチキャストの高速再経路設定装置及び方法
US20210119906A1 (en) Loop Avoidance Communications Method, Device, and System
WO2020024828A1 (zh) 通信方法、通信设备和通信系统
KR20220093155A (ko) 패킷 전달 방법, 제1 네트워크 디바이스 및 제1 디바이스 그룹
WO2017036384A1 (zh) 运营商边缘设备及数据转发方法
WO2021143279A1 (zh) 段路由业务处理方法和装置、路由设备及存储介质
CN112702251B (zh) 报文检测方法、连通性协商关系建立方法以及相关设备
WO2020021558A1 (en) Methods, apparatus and machine-readable media relating to path computation in a communication network
US11979322B2 (en) Method and apparatus for providing service for traffic flow
WO2023284675A1 (zh) 转发表的查找方法及装置、存储介质及电子装置
Veselý et al. Multicast, trill and lisp extensions for inet
WO2024010954A1 (en) Link number distribution for multicast
JP2024027107A (ja) 通信方法および関連する装置
WO2014187367A1 (zh) 标签查找方法及装置

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