WO2019214589A1 - Procédé de transmission de données de multidiffusion, appareil et système associés - Google Patents

Procédé de transmission de données de multidiffusion, appareil et système associés Download PDF

Info

Publication number
WO2019214589A1
WO2019214589A1 PCT/CN2019/085739 CN2019085739W WO2019214589A1 WO 2019214589 A1 WO2019214589 A1 WO 2019214589A1 CN 2019085739 W CN2019085739 W CN 2019085739W WO 2019214589 A1 WO2019214589 A1 WO 2019214589A1
Authority
WO
WIPO (PCT)
Prior art keywords
bier
domain
bfir
bfer
multicast data
Prior art date
Application number
PCT/CN2019/085739
Other languages
English (en)
Chinese (zh)
Inventor
夏怒
陈建
朱夏
韦乃文
Original Assignee
华为技术有限公司
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
Priority claimed from CN201810507664.5A external-priority patent/CN110460522B/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP19800073.9A priority Critical patent/EP3783849B1/fr
Priority to KR1020207034928A priority patent/KR102447132B1/ko
Priority to JP2020562656A priority patent/JP7123174B2/ja
Publication of WO2019214589A1 publication Critical patent/WO2019214589A1/fr
Priority to US17/090,616 priority patent/US11616656B2/en

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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission

Definitions

  • the present application relates to the field of multicast technologies, and in particular, to a multicast data transmission method, related apparatus, and system.
  • bit indexed explicit replication (BIER) technology provides a very simplified way to solve the multicast forwarding problem of the intermediate network, which can efficiently distribute multicast and solve the major problems in the multicast technology.
  • the BIER technique can be found in the IETF draft draft-ietf-bier-architecture-07.
  • Bit Index Explicit Copy (BIER) is a typical representative of stateless multicast protocols. It has the following characteristics: 1. It does not need to use the protocol for explicitly creating a multicast distribution tree; 2. It does not require intermediate nodes to maintain any per-flow state. (per-flow state).
  • BIER technology can be used with a variety of virtual private networks (VPNs) such as multicast virtual private network (MVPN), layer 3 virtual private network (L3VPN) and Ethernet virtual private
  • VPNs virtual private networks
  • MVPN multicast virtual private network
  • L3VPN layer 3 virtual private network
  • EVPN Ethernet virtual private
  • a combination of ethernet virtual private network (EVPN) can achieve complete VPN multicast.
  • MVPN surpasses the concept and shackles of traditional virtual private network (VPN), making full use of the ubiquitous Internet, providing two superior and distinct choices: virtual private intranet and virtual private WAN, which can be seamlessly implemented. Securely and simply connect regions and users. MVPN has become an important bridge for enterprises to connect and exchange in different places. Therefore, BIER is bound to need full support for MVPN.
  • the present application provides a multicast data transmission method, related device and system, which can significantly shorten the convergence time of multicast transmission and improve the timeliness of multicast transmission.
  • the present application provides a multicast data transmission method, which is applied to a Bit-Forwarding Ingress Router (BFIR) on a multicast source side, and the method may include: first in a first BIER domain.
  • the BFIR determines an identifier (BIFT-id) and a bit string (BitString) of the corresponding Bit Index Forwarding Table (BIFT) of the multicast data in the second BIER domain, wherein the BIFT-id is at least The Set Identifier (SI) to which the BFR-id of the first bit-forwarding egress router (BFER) belongs and the bit string length (BitStringLength, BSL) supported by the first BFER determine that the BitString is at least
  • the first BFER bit-forwarding router (BFR) identifier (abbreviated as BFR-id) determines that the first BFER is a BFER for receiving the multicast data in the second BIER domain.
  • the first BFIR encapsulates the multicast data into a BIER packet, and the BIER header of the BIER packet includes a BIFT-id and a bit string corresponding to the multicast data in the second BIER domain.
  • the first BFIR tags the BIER data packet, and sends the BIER data packet after the label is sent to the second BFIR, where the label is a label corresponding to the prefix of the second BFIR in the second BIER domain.
  • the first BIER domain is the BIER domain in which the sender is located
  • the second BIER domain that is, the BIER domain in which the non-transmitter is located
  • the first BFIR is the sender and is the BFIR on the multicast source side.
  • the second BFIR is the BFIR in the other BIER domains.
  • the first BFER is a BFER for receiving the multicast data in other BIER domains, that is, a BFER that is interested in the multicast group corresponding to the multicast data in other BIER domains.
  • the label may be a Multi-Protocol Label Switching (MPLS) label or a Generic Routing Encapsulation (GRE) label.
  • MPLS Multi-Protocol Label Switching
  • GRE Generic Routing Encapsulation
  • the sender performs BIER encapsulation on the multicast data to obtain a BIER packet, and then tags the BIER packet (such as an MPLS label or a GRE label) and then unicasts it to the multicast data.
  • BIER packet such as an MPLS label or a GRE label
  • the multicast data forwarding in the BIER domain follows the existing BIER mechanism forwarding mechanism.
  • the sender may specifically determine the corresponding bit string and BIFT-id of the multicast data in the second BIER domain from the first mapping table.
  • the first mapping table may include a BIFT-id, a bit string respectively corresponding to the multicast data in at least one BIER domain.
  • the at least one BIER domain includes a second BIER domain.
  • the sender may also determine the prefix of the logical next hop of the sender in the second BIER domain before tagging the BIER packet.
  • the logical next hop of the sender in the second BIER domain is the second BFIR.
  • the sender can determine the next hop (ie, the BFIR of other BIER domains as the next hop), instead of using the directly adjacent BFR (ie, BFR-NBR) as the next hop, which can be avoided.
  • the multicast data in the BIER domain is forwarded by the BFR in the BIER domain where the sender is located.
  • the BFIR can be directly sent to other BIER domains after being encapsulated by MPLS or GRE. The forwarding efficiency is higher.
  • the sender may determine, according to the corresponding BIFT-id of the multicast data in the second BIER domain, that the sender is in the second BIER domain from the second mapping table.
  • the prefix of the logical next hop of the sender in the second BIER domain is the prefix corresponding to the corresponding BIFT-id of the multicast data in the second BIER domain.
  • the second mapping table may include: a BIFT-id corresponding to the multicast data in the at least one BIER domain, and a logical next hop prefix of the first BFIR in the at least one BIER domain.
  • the sender can know which BFERs in the BIER domain are interested in the multicast group through multicast information release and feedback.
  • the sender and the BFIR and BFER in the other BIER domain form a Border Gateway Protocol (BGP) peer.
  • Multicast information release and feedback can include:
  • the sender can directly send BGP messages to the BFIR and BFER in the BIER domain through the BGP connection.
  • the BGP message carries the P-Multicast Service Interface Auto-Discovery route (PMSI AD route). Publish multicast information (such as multicast group address).
  • the Intra PMSI A-D route can carry the BIER identifier and the identifier of the multicast group corresponding to the multicast data (such as the multicast group address 232.1.1.1).
  • the BIER identifier is used to indicate that the BGP message carrying the Intra PMSI A-D route is a BIER multicast message.
  • the BFIR and the BFER in the other BIER domain can directly send the BGP message carrying the leaf auto-discovery route (Leaf AD route) to the sender through the BGP connection.
  • the sender receives the BPG message from the BFIR and BFER in the other BIER domain through the BGP connection, and the BGP message carries the Leaf A-D route.
  • the Leaf A-D route can carry the following information:
  • the Leaf AD route fed back by the BFER (ie, the first BFER) in the other BIER domain may carry the BFR-id of the first BFER, the sub-domain to which the first BFER belongs, and the SI to which the BFR-id of the first BFER belongs.
  • a field for carrying sub-domain, SI, BSL, and BFR-id may be added to the Leaf A-D route, and an extended community attribute (“Source-AS extended community") is opened to indicate the identifier of the BIER domain.
  • the sender can determine the BIFT-id according to the three parameters of sub-domain, SI, and BSL, and can generate a BitString according to the BFR-id. That is to say, the BFR-id of the BFER in the other BIER domain, the SI to which the BFR-id belongs, and the identifier of the other BIER domain can be used by the sender to determine the corresponding BIFT-id, bit of the multicast data in the other BIER domain. string. Then, the sender can generate the first mapping table by using the BIER domain identifier, BIFT-id, and BitString, as shown in the following.
  • a BIER domain is configured with only one sub-domain.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the BFER belongs is not necessarily carried in the Leaf A-D route of the first BFER feedback.
  • the BSL supported by the entire multicast domain can be consistent, that is, the sender knows the BSL without additional notification. Therefore, it is not necessary to carry the BSL in the Leaf A-D route of the first BFER feedback.
  • the leaf A-D route fed back by the BFIR (ie, the second BFIR) in the other BIER domain may carry the BFR-Prefix of the second BFIR and the identifier of the BIER domain of the second BFIR.
  • the prefix of the BFIR in the other BIER domain and the identity of the other BIER domain are used by the sender to determine the prefix of the logical next hop of the multicast data in the other BIER domain.
  • the sending convenience can generate a second mapping table of the sender according to the information, as shown in the following.
  • edge BFRs of different BIER domains are configured as BGP peers.
  • BGP messages can be directly exchanged through BGP connections to quickly release multicast information and provide fast feedback. That is to say, multicast information distribution and feedback are no longer segmented for BGP interaction, but BGP messages are directly exchanged across domains. The convergence time of multicast release and feedback is significantly shortened, and the effectiveness is high.
  • the sender determines the BIFT-id.
  • the sender can determine the corresponding BIFT-id of the specific multicast group in each BIER domain according to the sub-domain, SI, and BSL carried in the Leaf A-D route from each BIER domain.
  • BIFT-id is used for BFR (including BFIR, transit BFR) in each BIER domain to forward multicast data according to BIFT identified by BIFT-id.
  • BIFT-id is a fixed-length (such as 20 bits) index determined by three parameters: sub-domain, SI, and BSL. In a special case where only one sub-domain is configured in a BIER domain, the sub-domain is not mandatory.
  • the sender also determines the corresponding BIFT-id of the specific multicast group in other BIER domains according to the sub-domain, SI, and BSL. This means that the sender can construct a BIFT-id that can be used for BIER route forwarding in other BIER domains.
  • the entire multicast domain multiple BIER domains
  • the BIFT-id corresponding to each specific multicast group in each BIER domain is the BIFT-id corresponding to the multicast data corresponding to the specific multicast group in each BIER domain.
  • the sender can determine the BitString corresponding to each multicast group in each BIER domain according to the BFR-id carried in the Leaf A-D route from each BIER domain. BitString is used for BFR (including BFIR, transit BFR) in each BIER domain to forward multicast data to the BFER (ie, the receiver) identified by BitString.
  • BFR including BFIR, transit BFR
  • the sender generates a first mapping table.
  • the sender generates a first mapping table according to the BIER domain identifier, BIFT-id, and BitString of each BIER domain.
  • the first mapping table may include a BIFT-id, a BitString corresponding to the specific multicast data in the at least one BIER domain.
  • the at least one BIER domain may include a BIER domain in which the sender is located and a BIER domain in which the non-sender is located (ie, other BIER domains).
  • the first mapping table may be a correspondence between a multicast group identifier (such as a multicast group address) and a BIER domain identifier, a BIFT-id, and a BitString.
  • the BIER domain identifier, BIFT-id, and BitString corresponding to a multicast group identifier indicate that the multicast data corresponding to the multicast group identifier corresponds to the BIFT-id and BitString in the BIER domain indicated by the BIER domain identifier.
  • the first mapping table can be used to construct a BIER header.
  • the BIER header is constructed only on the sender side, and no intermediate device is involved in the reconstruction of the BIER header.
  • the sender generates a second mapping table.
  • the sender autonomously determines the next hop (ie, the BFIR of the other BIER domain as the next hop) instead of using the directly adjacent BFR (ie, BFR-NBR) as the next hop.
  • the next hop ie, the BFIR of the other BIER domain as the next hop
  • BFR-NBR directly adjacent BFR
  • the next hop of the sender in the BIER domain may be multiple BFIRs in the BIER domain, ie there are multiple next hops.
  • a portion of the plurality of BFIRs may be responsible for forwarding multicast data to some sub-domains in the BIER domain, and another portion of the plurality of BFIRs may be responsible for forwarding multicast data to other sub-s in the BIER domain. Domain.
  • the sender can determine the multicast data according to the corresponding BIFT-id (the BIFT-id and the sub-domain one-to-one correspondence) in the BIER domain according to the multicast data. Which BFIR is forwarded to.
  • BIFT-id can indicate the sub-domain to which the multicast data will be sent.
  • the present application is not limited, and may be referred to actual requirements.
  • the amount of data forwarding carried by each of the multiple next hops can be set from the perspective of load balancing.
  • the next hop of the sender in the BIER domain may be a BFIR in the BIER domain, ie there is only one next hop.
  • This BFIR can be responsible for forwarding multicast data to all target sub-domains in the BIER domain.
  • the target sub-domain refers to the sub-domain in which the receiver of the multicast data is located.
  • the sender may generate a second mapping table according to the autonomously determined next hop.
  • the second mapping table may include: a BIFT-id corresponding to the multicast group in the at least one BIER domain, and a BFR-Prefix of the next hop of the sender in the at least one BIER domain.
  • the at least one BIER domain may include a BIER domain in which the sender is located and a BIER domain in which the non-sender is located (ie, other BIER domains).
  • the sender's next hop may be BFR-NBR.
  • the sender's next hop may be the BFIR of other BIER domains.
  • the second mapping table may be a correspondence between a multicast group identifier (such as a multicast group address) and a BIER domain identifier, a BIFT-id, and a BFR-Prefix.
  • the BIER domain identifier, BIFT-id, and BFR-Prefix corresponding to a multicast group identifier indicate that the multicast data corresponding to the multicast group identifier corresponds to the BIFT-id and logical next hop in the BIER domain indicated by the BIER domain identifier.
  • BFR-Prefix is a correspondence between a multicast group identifier (such as a multicast group address) and a BIER domain identifier, a BIFT-id, and a BFR-Prefix.
  • the second mapping table may also be a correspondence between BIFT-id and BFR-Prefix.
  • the sender can use the BIFT-id found from the first mapping table to find the BIFT-id corresponding BFR-Prefix in the second mapping table.
  • the BIFT-id corresponding to the domain identifier of the BIER domain in the second mapping table corresponds to Multiple BFR-Prefix; in case the sender has only one next hop in the BIER domain, the BIFT-id corresponding to the domain identifier of the BIER domain in the second mapping table corresponds to a BFR -Prefix.
  • the second mapping table may be used to apply an MPLS label or a GRE label to the BIER data packet encapsulated by the multicast data to implement cross-domain (inter-domain) forwarding.
  • the sender may be configured with an egress port for sending multicast data to at least one BIER domain.
  • the second mapping table may further include: an identifier of the egress port.
  • the sender can determine the identifier of the egress port for sending the multicast data to other BIER domains from the second mapping table according to the corresponding BIFT-id of the multicast data in other BIER domains.
  • the egress port for sending the multicast data to other BIER domains may be referred to as a first port.
  • the present application provides a multicast data transmission method, which is applied to BFIR in other BIER domains.
  • the method may include: receiving, by a first BFIR in a first BIER domain, a second BFIR transmission in a second BIER domain.
  • the tagged BIER packet which is a tag corresponding to the prefix of the first BFIR
  • the BIER packet is obtained by encapsulating the multicast data by the second BFIR
  • the BIER header of the BIER packet includes the multicast data in the A corresponding BIFT-id and bit string in a BIER domain.
  • the BIFT-id is determined by at least the SI to which the BFR-id of the first BFER belongs and the bit string length supported by the first BFER, and the bit string is determined by at least the BFR-id of the first BFER.
  • the first BFER is a BFER for receiving the multicast data in the first BIER domain.
  • the first BFIR can then remove the tag to obtain the BIER packet and obtain the BIFT-id and bit string from the BIER header of the BIER packet. Finally, the first BFIR may forward the BIER packet to the first BFER according to the BIFT indicated by the BIFT-id and the bit string.
  • the first BIER domain is the BIER domain in which the non-transmitter is located
  • the second BIER domain is the BIER domain in which the sender is located.
  • the first BFIR is the BFIR in the first BIER domain.
  • the second BFIR is the sender and is the BFIR on the multicast source side.
  • the first BFER is a BFER for receiving the multicast data in the first BIER domain.
  • the above label may be an MPLS label or a GRE label.
  • the sender performs BIER encapsulation on the multicast data to obtain a BIER packet, and then unicasts the BIER packet to another BIER domain by applying an MPLS label or a GRE label.
  • BFIR BFIR
  • the multicast data forwarding in the BIER domain follows the existing BIER mechanism forwarding mechanism. Different from the existing BIER-MVPN scheme, the multicast data forwarding in this application is not segmented.
  • the BIER header is constructed only on the sender side, and no intermediate equipment is needed (such as BFIR and BFER in each BIER domain along the way). Participate in the generation of BIER headers for more efficient multicast forwarding.
  • the corresponding BIFT-id of the multicast data in the first BIER domain is also determined by the sub-domain to which the first BFER belongs.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the BFER belongs is not necessarily carried in the Leaf A-D route of the first BFER feedback.
  • a BGP peer is formed between the second BFIR and the first BFIR.
  • the method may further include: the first BFIR receives the first BGP message sent by the second BFIR through the BGP connection, and the Intra PMSI A-D route carried in the first BGP message includes a BIER identifier and an identifier of the multicast group corresponding to the multicast data.
  • the first BFIR sends a second BGP message to the second BFIR through the BGP connection, and the Leaf A-D route carried by the second BGP message includes the prefix of the first BFIR and the identifier of the first BIER domain.
  • the sending convenience can generate a second mapping table of the sender according to the information, and specifically refer to the related content described in the first aspect.
  • BFIRs between different BIER domains are configured as BGP peers, and BGP messages can be directly exchanged through BGP connections for rapid release and fast feedback of multicast information. That is to say, multicast information distribution and feedback are no longer segmented for BGP interaction, but BGP messages are directly exchanged across domains. The convergence time of multicast release and feedback is significantly shortened, and the effectiveness is high.
  • the present application provides a multicast data transmission method, which is applied to a BFER on a user equipment side.
  • the method may include: receiving, by a first BFER in a first BIER domain, a first BFIR in a first BIER domain.
  • a BIER packet obtained by encapsulating multicast data by a second BFIR in a second BIER field, the BIER header of the BIER packet including a BIFT-id and a bit string corresponding to the multicast data in the first BIER domain .
  • the BIFT-id is determined by at least the SI to which the BFR-id of the first BFER belongs and the bit string length supported by the first BFER, and the bit string is determined by at least the BFR-id of the first BFER.
  • the first BFER is a BFER for receiving the multicast data in the first BIER domain. Then, the first BFER decapsulates the BIER data packet to obtain the multicast data, and sends the multicast data to the user side device.
  • the first BIER domain is the BIER domain in which the non-transmitter is located
  • the second BIER domain is the BIER domain in which the sender is located.
  • the first BFIR is the BFIR in the first BIER domain.
  • the second BFIR is the sender and is the BFIR on the multicast source side.
  • the first BFER is a BFER for receiving the multicast data in the first BIER domain.
  • the above label may be an MPLS label or a GRE label.
  • the sender performs BIER encapsulation on the multicast data to obtain a BIER packet, and then unicasts the BIER packet to another BIER domain by applying an MPLS label or a GRE label.
  • BFIR BFIR
  • the multicast data forwarding in the BIER domain follows the existing BIER mechanism forwarding mechanism. Different from the existing BIER-MVPN scheme, the multicast data forwarding in this application is not segmented.
  • the BIER header is constructed only on the sender side, and no intermediate equipment is needed (such as BFIR and BFER in each BIER domain along the way). Participate in the generation of BIER headers for more efficient multicast forwarding.
  • a BGP peer is formed between the second BFIR and the first BFER.
  • the method may further include: the first BFER receives the first BGP message sent by the second BFIR through the BGP connection, and the Intra PMSI A-D route carried in the first BGP message includes the BIER identifier and the identifier of the multicast group corresponding to the multicast data.
  • the first BFER sends a second BGP message to the second BFIR through the BGP connection, and the Leaf AD route carried in the second BGP message includes the BFR-id of the first BFER, the SI of the first BFER BFR-id, and the first The identity of the BIER domain.
  • the first mapping table can be generated according to the information, and the related content described in the first aspect can be specifically referred to.
  • the BGP peer is configured between the sender and the BFER in the other BIER domain.
  • the BGP message can be directly exchanged through the BGP connection, and the multicast information can be quickly advertised and quickly fed back. That is to say, multicast information distribution and feedback are no longer segmented for BGP interaction, but BGP messages are directly exchanged across domains. The convergence time of multicast release and feedback is significantly shortened, and the effectiveness is high.
  • the corresponding BIFT-id of the multicast data in the first BIER domain is also determined by the sub-domain to which the first BFER belongs.
  • the leaf A-D route of the first BFER feedback may also carry the sub-domain to which the first BFER belongs. That is, the Leaf A-D route carried by the second BGP message may further include a sub-domain to which the first BFER belongs.
  • only one sub-domain is configured for one BIER domain.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the BFER belongs is not necessarily carried in the Leaf A-D route of the first BFER feedback.
  • the Leaf A-D route carried by the second BGP message may further include a BSL supported by the first BFER.
  • the BSL supported by the entire multicast domain may be consistent, that is, the sender also knows the BSL without additional notification. Therefore, it is not necessary to carry the BSL in the Leaf A-D route of the first BFER feedback.
  • the application provides a router, where the router may include multiple function modules or units for performing the multicast data transmission method provided by the first aspect, or in a possible implementation manner of the first aspect. Any of the provided multicast data transmission methods.
  • the application provides a router, where the router may include multiple function modules or units for performing the multicast data transmission method provided by the second aspect, or in a possible implementation manner of the second aspect. Any of the provided multicast data transmission methods.
  • the application provides a router, where the router may include multiple function modules or units for performing the multicast data transmission method provided by the third aspect, or in a possible implementation manner of the third aspect. Any of the provided multicast data transmission methods.
  • the application provides a router for performing the multicast data transmission method described in the first aspect.
  • the router can include a memory and a processor, transceiver coupled to the memory, wherein the transceiver is for communicating with other communication devices.
  • the memory is used to store the implementation code of the multicast data transmission method described in the first aspect
  • the processor is configured to execute the program code stored in the memory, that is, to perform the multicast data transmission method provided by the first aspect, or the first aspect may be implemented A multicast data transmission method provided by any of the modes.
  • the application provides a router for performing the multicast data transmission method described in the second aspect.
  • the router can include a memory and a processor, transceiver coupled to the memory, wherein the transceiver is for communicating with other communication devices.
  • the memory is used to store the implementation code of the multicast data transmission method described in the second aspect
  • the processor is configured to execute the program code stored in the memory, that is, to perform the multicast data transmission method provided by the second aspect, or the second aspect possible implementation A multicast data transmission method provided by any of the modes.
  • the present application provides a router for performing the multicast data transmission method described in the third aspect.
  • the router can include a memory and a processor, transceiver coupled to the memory, wherein the transceiver is for communicating with other communication devices.
  • the memory is used to store the implementation code of the multicast data transmission method described in the third aspect
  • the processor is configured to execute the program code stored in the memory, that is, to perform the multicast data transmission method provided by the third aspect, or the third aspect possible implementation A multicast data transmission method provided by any of the modes.
  • a communication system comprising: a first router and a second router.
  • the first router may be the router described in the foregoing fifth aspect
  • the second router may be the router described in the sixth aspect above.
  • the communication system may further include: a third router, which may be the router described in the fourth aspect above.
  • the first router may be the router described in the foregoing eighth aspect
  • the second router may be the router described in the foregoing ninth aspect
  • the third router may be the router described in the foregoing seventh aspect.
  • a computer readable storage medium is provided, the instructions being stored on a readable storage medium, when executed on a computer, causing the computer to perform the first aspect or the second aspect or the third aspect described above Multicast data transmission method.
  • a computer program product comprising instructions which, when run on a computer, cause the computer to perform the multicast data transmission method described in the second aspect or the third aspect above.
  • FIG. 1 is a schematic diagram of a BIER architecture involved in the present application
  • FIG. 2 is a schematic diagram of a data structure of a BIER header according to the present application.
  • FIG. 3 is an exemplary schematic diagram of a topology within a BIER domain
  • FIG. 4 is a schematic diagram of multicast information release and feedback in a BIER domain
  • FIG. 5 is a schematic diagram of BFER feedback in a BIER domain added to a multicast group
  • FIG. 6 is a schematic diagram of an application scenario of a BIER-MVPN designed according to the present application.
  • FIG. 7 is a schematic flowchart of a conventional BIER-MVPN solution
  • FIG. 8 is a schematic diagram of an existing multicast information release and feedback process
  • FIG. 9 is a schematic diagram of a data structure of an extended Intra PMSI A-D route in the present application.
  • FIG. 10 is a schematic diagram of a multicast data transmission mode in an existing MVPN framework
  • FIG. 11 is a schematic diagram of constructing a TCP connection by using an underlying label mapping in the present application.
  • FIG. 12 is a schematic diagram of constructing a BGP peer in the present application.
  • FIG. 13 is a schematic diagram of cross-domain multicast information release and feedback in the present application.
  • FIG. 14 is a schematic diagram of a multicast data transmission method provided in the present application.
  • 15 is a schematic diagram of carrying extended multicast information in an extended Intra PMSI A-D route according to the present application
  • 16 is a schematic diagram showing the data structure of an extended Leaf A-D route of receiver BFER feedback in other BIER domains
  • 17 is a schematic diagram showing the data structure of an extended Leaf A-D route of BFIR feedback in other BIER domains
  • FIG. 18 is a schematic diagram of a data structure of a BIFT-id in the present application.
  • FIG. 19 is a schematic diagram of a sender receiving BIER information from each BIER domain in the present application.
  • 21 is a schematic diagram of a second mapping table of a sender in the present application.
  • 22 is a schematic diagram of a working principle of multicast data forwarding of a sender in the present application.
  • FIG. 23 is a schematic diagram of forwarding multicast data in a multicast domain in the present application.
  • FIG. 24 is a schematic flowchart diagram of another multicast data transmission method provided by the present application.
  • 25 is a schematic structural diagram of a router provided by the present application.
  • FIG. 26 is a schematic structural diagram of a communication system and related apparatus provided by the present application.
  • FIG. 1 illustrates the BIER architecture involved in this application.
  • a router that supports BIER is called a Bit-Forwarding Router (BFR).
  • BFR Bit-Forwarding Router
  • the BIER Control Plane protocol runs in the BIER domain, allowing BFRs in the BIER domain to exchange information between BIER packets using the BIER forwarding mechanism between them.
  • a BIER domain may include the following routers: a Bit-Forwarding Ingress Router (BFIR) 101, a Bit-Forwarding Egress Router (BFER) 105, and a Transit BFR (transit BFR). 103.
  • BFIR Bit-Forwarding Ingress Router
  • BFER Bit-Forwarding Egress Router
  • Transit BFR Transit BFR
  • the multicast packet enters the BIER domain at the Bit Forwarding Ingress Router (BFIR) 101 and leaves the BIER domain at the Bit Forwarding Exit Router (BFER) 105.
  • the transit BFR is used to receive a multicast packet from another BFR in the same BIER domain and forward the multicast packet to another BFR in the same BIER domain.
  • a single BFR can be BFIR; for other multicast streams, the single BFR can also be BFER; for some multicast streams, the single The BFR can in turn be a transit BFR.
  • a BFR can be one of a BFIR and/or a transit BFR and/or a BFER corresponding to the BFR.
  • a BIER domain can contain one or more sub-domains. Each sub-domain is configured with a sub-domain identifier (denoted as sub-domain-id), and the sub-domain-id ranges from [0, 255]. For a sub-domain to which a particular BFR belongs, if the BFR can act as a BFIR/BFER, then the BFR is assigned a BFR-id, which is unique in the sub-domain. For example, if a BIER subfield contains 1,374 BFRs, each BFR can be assigned a BFR-id (ranging from 1-1374).
  • each BFR is assigned a "BFR-Prefix" in its sub-domain.
  • the BFR prefix of a BFR is the IP address (IPv4 or IPv6) of the BFR.
  • IPv4 or IPv6 IP address of the BFR.
  • a BFR prefix for a given BFR is routable in the sub-domain to which it belongs.
  • the BFIR determines which BFER sets the multicast packet will be sent to and which sub-domains the packet is to be transmitted. Once the BFIR determines the BFER set and the sub-domain for the multicast packet, the BFIR uses the BIER header to BIER encapsulate the multicast packet. That is, the multicast packet needs to be encapsulated into a BIER packet to be forwarded in the BIER domain.
  • the format of the BIER header used in the BIER package can be as shown in Figure 2: BIFT-id and BitString.
  • the BIFT-id is an identifier of a Bit Index Forwarding Table (BIFT), which is used to indicate which BIFT the BFR finds to forward the BIER packet; and the BitString (called a bit string) indicates that the multicast data is in the BIER domain.
  • BIFT Bit Index Forwarding Table
  • each bit in the BitString represents a BFR-id.
  • the BFIR can set the BFR-id of the specific BFER to the corresponding bit in the BitString. For example, BitString "0110" indicates that the receiver of the multicast group is: BFER with BFR-id of 2 BFER with a BFR-id of 3.
  • each BFER publishes its BFR-id to all other BFRs.
  • the BFR-id may be advertised by an opaque link state advertisement (opaque LSA) message, and an extension field for carrying BIER information (such as sub-domain, BFR-id, etc.) is added to the message.
  • the opaque LSA is an option to run the IBGP protocol.
  • each BFR publishes its BFR-Prefix to all other BFRs.
  • the Bit Index Routing Table is a table that maps from the BFR-id of the BFER to the BFR-Prefix of the BFER and maps to the BFR neighbor (BFR-NBR) on the path to the BFER.
  • the BFR-id of each BFR can be expressed in the format of SI:BitString.
  • SI indicates the Set Identifier to which the BFR-id belongs.
  • Both SI and Bitstring are converted by BFR-id, which is determined by the parameter "BitStringLength (BSL)". For example, assume a bit string length (BSL) of 4. If BFR-id is 1, then SI is equal to 0 and Bitstring is "0001". If BFR-id is 2, then SI is equal to 0 and Bitstring is "0010".
  • BSL bit string length
  • the topology shown in Figure 3 produces the BIRT shown in Table 1 at BFR-B.
  • the first column indicates the BFR-id of each BFER (BFER-A, BFER-E, BFER-F, BFER-D) that BFR-B can reach, and the second column indicates the BFER of each BFER that BFR-B can reach.
  • BFER-A, BFER-E, BFER-F, BFER-D BFER-A
  • BFER-F BFER-F
  • BFER-D BFER-D
  • BFER-Prefix the third column indicates BFR-NBR (ie, next hop) on the path where BFR-B arrives at each BFER.
  • BFR generates a bit index forwarding table (BIFT) according to BIRT
  • the bit mask in the BIFT can be obtained, that is, F- BM.
  • Table 2 shows the BIFT of BFR-B generated by Table 1, which is used to map from BFR-id of BFER to the corresponding F-BM and BFR-NBR.
  • F-BM indicates which BFERs are available from each BFR-NBR of BFR-B.
  • the bit mask can be obtained by logically ORing the BitString in two rows having the same SI(0) and the same BFR-NBR (BFR-C) in the BIRT shown in Table 1. ) "0011".
  • the BFIR and transit BFRs in the BIER domain can be multicast forwarded according to the BIER header in the received BIER packet.
  • the BFIR needs to know which BFERs are interested in a particular multicast group, in order to determine which BFERs to send the multicast data for the multicast group.
  • the BFER that is interested in the specific multicast group is determined by the BFIR as the receiver of the specific multicast group, and the receiver of the specific multicast group is the receiver of the multicast data corresponding to the specific multicast group.
  • both BFIR and BFER are network edge devices (Provider Edges, PEs), which exchange multicast information (such as multicast group addresses) through Border Gateway Protocol (BGP) messages.
  • Figure 4 shows the multicast information release and feedback process in the BIER domain.
  • the BFIR sends a BGP message carrying the P-Multicast Service Interface Auto-Discovery Route (PMSI AD route) to advertise a multicast to the BFER. information.
  • PMSI AD route P-Multicast Service Interface Auto-Discovery Route
  • the BFER that is interested in the multicast group represented by the multicast information is fed back by the BGP message carrying the leaf node auto-discovery route (Leaf A-D route).
  • the BFIR when the BFIR knows which receivers (BFERs) of a multicast group are, the BFIR can generate the multicast receiver table shown in Table 3.
  • Receiver indicates the Prefix of the receiver of the multicast group G1
  • the Group ID is the multicast group identifier
  • Joined indicates whether the BFER is added to a multicast group G1.
  • the BFIR can then determine the BitString based on the BFR-id of the recipient of the multicast group. For example, as shown in Table 2, the recipient of the multicast group G1 is BFER-B (BFR-id is 2) and BFER-C (BFR-id is 3). BFIR can convert the BFR-id of BFER-B to "0010", convert the BFR-id of BFER-C to "0100", and then logically OR operate "0010" and "0100" to obtain BitString "0110".
  • FIG. 6 exemplarily shows a BIER-MVPN application scenario.
  • the multicast domain may include multiple BIER domains (such as the BIER domain 100, the BIER domain 200, and the BIER domain 300).
  • the multicast data needs to be forwarded from the sender (the BFIR on the multicast source side) and undergoes multiple BIER intra-domain forwarding. BIER inter-domain forwarding, and finally to each recipient (user side BFER).
  • a BIER domain is equivalent to an autonomous system (AS).
  • ASBR autonomous system border router
  • FIG. 7 shows the existing MVPN draft using BIER technology (hereinafter referred to as the existing BIER-MVPN solution) (refer to draft-ietf-bier-mvpn) .
  • This draft provides a method for multicast data forwarding throughout the multicast domain. The following expands as follows:
  • both BFIR and BFR can generate a BIFT reaching each BFER.
  • the BFER in the BIER domain also issues the BIFT-id of the BIFT to implicitly indicate the subdomain to which the BFER belongs, the SI to which the BFR-id of the BFER belongs, and the BSL supported by the BFER. That is to say, the BIFT-id on which the multicast data is forwarded to a BFER is determined by the three parameters of the subdomain to which the BFER belongs, the SI to which the BFR-id of the BFER belongs, and the BSL supported by the BFER.
  • BFIR can also generate a correspondence table of BFR-Prefix and BFR-id for the BFER in its BIER domain.
  • BFIR and BFR in the BIER domain generate their respective BIFTs
  • BFIR and BFR can perform multicast forwarding according to BIFT-id and Bitstring in the BIER header.
  • BIFT-id is used to tell the BIER router which BIFT to find to forward multicast data.
  • BitString represents the BFR-id of all recipients (BFER) of a multicast data.
  • the BFIR in a BIER domain is used to learn which BFERs in the BIER domain are interested in the multicast group, including: multicast information distribution and feedback in the BIER domain, and multicast information release and feedback between the BIER domains.
  • Figure 8 shows the process of multicast information distribution and feedback.
  • the Resource Reservation Protocol (RSVP) and the multicast label distribution protocol (MLDP) in Figure 8 can be used to implement label distribution.
  • Ingress replication (also known as head-end replication) (Ingress Replication, IR) Protocols can be used to implement point-to-multipoint data forwarding, such as flood forwarding. specific:
  • the sender sends the Intra PMSI A-D route to the BFER in the BIER domain 100 through the intra-domain BGP message to advertise the multicast information. If the BFER in the BIER domain 100 is interested in the multicast group indicated by the multicast information, the Leaf A-D route needs to be fed back to notify the sender to join the sender's multicast tunnel.
  • the sender needs to add a BIER identifier to the PMSI Tunnel Attribute of the Intra PMSI AD route to indicate the BGP message carrying the Intra PMSI AD route. Is a BIER multicast message.
  • the intra-domain BGP message carrying the Intra PMSI AD route sent by the sender After receiving the intra-domain BGP message carrying the Intra PMSI AD route sent by the sender, if the BFER in the BIER domain 100 is interested in the multicast group indicated by the multicast information, the intra-domain BGP message will be passed.
  • the Leaf AD route is fed back to the sender, and the BFR-Prefix of the BFER is carried in the Leaf AD route.
  • the ASBR1 in the BIER domain 100 receives the Intra PMSI A-D route from the sender, the ASBR1 needs to feed the leaf A-D route to the sender through the BGP message in order to spread the multicast information to other BIER domains.
  • the BFER that is interested in the multicast group is the receiver of the multicast group.
  • the sender can find the BFR-id of the receiver according to the BFR-Prefix of the receiver, and can determine the BitString corresponding to the multicast group in the BIER domain 100 according to the BFR-id of the receiver. Further, by S101, the sender can know the BIFT-id required to transmit the multicast data to the BFER of the different BFR-id. BitString and BFIT-id are the two most important elements in the BIER header to indicate how BFRs that receive BIER packets in BIER domain 100 forward multicast group data.
  • the multicast information is released between the BIER domains.
  • ASBR1 in BIER domain 100 receives the Intra PMSI AD route sent by the sender, ASBR1 parses the Intra PMSI AD route, records the multicast group and MVPN information, and generates the BFER as the source. Inter-domain BGP message. Then, the ASBR1 sends the Inter PMSI A-D route through the inter-domain BGP message and sends it to all its external border gateway protocol (eBGP) neighbors, such as ASBR2.
  • eBGP external border gateway protocol
  • the ASBR2 After the ASBR2 receives the Inter PMSI AD route from the ASBR1, the ASBR2 needs to feed the leaf AD route to the ASBR1.
  • the Leaf AD route carries the BFR of the ASBR2. Prefix.
  • ASBR1 can generate a correspondence table between the multicast group and the receiver's BFR-Prefix, and can know which ASBRs to send the multicast data to when the multicast data arrives.
  • the inter-domain forwarding of multicast data is not performed in the BIER encapsulation, but is labeled. The subsequent content will be described in the following.
  • the ASBR2 sends an Intra PMSI A-D route to the BFER in the BIER domain 200 through the intra-domain BGP message to advertise the multicast information from the sender.
  • the multicast information distribution mechanism in the BIER domain 200 is the same as the multicast information distribution mechanism in the BIER domain 100. For details, refer to S102.
  • the BFER in the BIER domain 200 after receiving the intra-domain BGP message carrying the Intra PMSI AD route sent by the ASBR2, if the BFER in the BIER domain 200 is interested in the multicast group indicated by the multicast information, it will pass the intra-domain BGP message.
  • the sender feeds the Leaf AD route, and the Leaf AD route carries the BFR-Prefix of the BFER.
  • the BFER that is interested in the multicast group is the receiver of the multicast group.
  • ASBR2 can find the BFR-id of the receiver according to the BFR-Prefix of the receiver, and can determine the corresponding BitString of the multicast group in the BIER domain 200 according to the BFR-id of the receiver.
  • ASBR2 can know the BIFT-id required to transmit multicast data to BFERs of different BFR-ids. BitString and BFIT-id are the two most important elements in the BIER header to indicate how BFRs that receive BIER packets in BIER domain 200 forward multicast data.
  • the BFIR sends an Intra PMSI A-D route (adding a BIER identifier) to the BFER to issue multicast information;
  • the BFER that is interested in the multicast group feeds the Leaf A-D route (the prefix carrying the BFER) to the BFIR.
  • the BFIR can find the BFR-id of the BFER according to the BFR-Prefix of the BFER, and can know which BFERs in the domain are interested in the multicast group (ie, the receiver), and can determine the corresponding BitString of the multicast group in the domain.
  • BFIR can also find the BIFT-id required to send multicast groups to these recipients.
  • BIFT-id and Bitstring are the two most important elements in the BIER header. They are used to indicate how the BFR receiving the BIER packet forwards the multicast group in the domain. It can be seen that the effect of BitString is limited to the BIER domain, and can only indicate which receivers of the multicast group are in a BIER domain.
  • the BFER of a BIER domain (such as ASBR1 in BIER domain 100) sends Inter PMSI AD route (adding BIER flag) to the BFIR of another BIER domain (such as ASBR2 in BIER domain 200).
  • Inter PMSI AD route (adding BIER flag) to the BFIR of another BIER domain (such as ASBR2 in BIER domain 200).
  • the BFIR of the other BIER domain feeds the Leaf A-D route (BFR-Prefix carrying the BFIR) to the BFER of the BIER domain through the inter-domain BGP message.
  • the BFER can generate a correspondence table between the multicast group and the BFR-Prefix of the BFIR, and can know which BFIRs are sent when the multicast data corresponding to the specific multicast group arrives.
  • step 8-10 intra-domain forwarding and inter-domain forwarding
  • the multicast data Before introducing the multicast data forwarding mode in the existing BIER-MVPN solution, first introduce the segmentation cross-domain multicast transmission mode under the MVPN framework.
  • the multicast data may be encapsulated with a Multi-Protocol Label Switching (MPLS) header corresponding to the tunnel in the domain, and is in the AS100.
  • MPLS Multi-Protocol Label Switching
  • the MPLS label is forwarded to the multicast data encapsulated with the MPLS header, and the data is sent to the PE and ASBR1 in AS100.
  • MPLS Multi-Protocol Label Switching
  • the ASBR1 can parse the received multicast data encapsulated with the MPLS header, re-encapsulate the Generic Routing Encapsulation (GRE) header corresponding to the corresponding inter-domain tunnel, and encapsulate the GRE between the inter-domain pairs.
  • the header multicast data is forwarded by GRE tags, and the data is sent to ASBR2 in AS200.
  • the ASBR2 can parse the received multicast data encapsulated with the GRE header, re-encapsulate the MPLS header corresponding to the tunnel in the corresponding domain, and perform MPLS label forwarding on the multicast data encapsulated with the MPLS header in the AS200. Send the data to the recipient PE.
  • the receiver PE removes the MPLS header and forwards the multicast data to the user side device.
  • the existing BIER-MVPN scheme uses the BIER forwarding mechanism to forward multicast data in the BIER domain. Expand below:
  • the sender searches for a corresponding BitString in the BIER domain 100 of the multicast data, and the BitString has been determined in S103.
  • the sender also needs to determine the BIFT-id on which the multicast data is to be forwarded to the recipients in the BIER domain 100, which BIFT-id has been determined in S101.
  • the sender generates the BIER header by using the BitString and the BIFT-id, and performs BIER encapsulation on the multicast data to obtain a BIER packet.
  • the sender and the transit BFR in the BIER domain 100 can forward the multicast data to the recipient (eg, ASBR1) within the BIER domain 100 in accordance with the BIER forwarding mechanism based on the BIER header.
  • the ASBR1 when receiving the BIER data packet, the ASBR1 first searches for the BFR-Prefix corresponding to the multicast data in the BIER data packet, that is, the BFR-Prefix of the ASBR2, and the BFR-Prefix has been determined in step S105, and is used for Indicates to send the multicast data to ASBR2. Then, ASBR1 encapsulates the multicast data on the GRE or MPLS header and sends it to ASBR2.
  • the ASBR2 parses the received multicast data encapsulated by the GRE or the MPLS header. Then, ASBR2 looks up the corresponding BitString of the multicast data in the BIER field 200, which has been determined in S103. In addition, ASBR2 also needs to determine the BIFT-id that is required to forward multicast data to recipients within BIER domain 200, which BIFT-id has been determined in S101. Then, ASBR2 generates a BIER header by using the BitString and BIFT-id, and performs BIER encapsulation on the multicast data to obtain a BIER packet. Thus, the ASBR2 and the transit BFR in the BIER domain 200 can forward the multicast data to the recipients in the BIER domain 200 in accordance with the BIER forwarding mechanism based on the BIER header.
  • the receiver in the BIER domain 200 removes the BIER header of the BIER packet, reads the multicast data, and forwards the multicast data to the user side device.
  • the BFIR of a BIER domain first finds the corresponding BitString of the multicast data in the BIER domain and the BIFT-id according to which the multicast data is forwarded to the receiver in the BIER domain.
  • the multicast data generates a BIER header, and the BIER header is used to perform BIER encapsulation on the multicast data to obtain a BIER packet.
  • the BFIR and the transit BFR in the BIER domain are based on the BIER header, and the multicast data is forwarded to the BIER domain according to the BIER forwarding mechanism (BitString and F-BM in BIFT perform logical AND operations, specifically IETF BIER_ARCH) Receiver.
  • BIER forwarding mechanism BitString and F-BM in BIFT perform logical AND operations, specifically IETF BIER_ARCH
  • the BFER of a domain (such as ASBR1 in the BIER domain AS100) first decapsulates the BIER packet, reads the multicast data, and then looks up the BFR-Prefix corresponding to the multicast data (such as BIER).
  • the BFR-Prefix of the ASBR2 in the domain 200, and finally the MPLS label or the GRE label is applied to the multicast data by using the BFR-Prefix.
  • the BFER sends the tagged multicast data to the BFIR of the other domain indicated by the BFR-Prefix.
  • the BFIR of other domains also finds the BIByte corresponding to the BitString corresponding to the multicast data in other domains and the multicast data to be forwarded to the receivers in other BIER domains. , generating a BIER header for the multicast data.
  • the BFR in other domains performs multicast forwarding according to the BIER forwarding mechanism.
  • the present application provides a multicast data transmission method.
  • the main inventive principles of the present application can be embodied in the following two stages: 1. multicast information release and feedback; 2. multicast data forwarding.
  • phase 1 may include: constructing a BGP peer between edge BFRs (BFIRs, BFERs) in different BIER domains, and directly interacting with BGP messages through BGP connections to implement fast release of multicast information. Quick feedback.
  • edge BFRs BFIRs, BFERs
  • the main inventive principle of Phase 2 may include a unified perspective of the entire multicast domain (multiple BIER domains) to determine the BIFT-id. That is, it is the same as the sub-domain, SI, and BSL on which the BIFT-id is determined in other BIER domains, and the sender also determines the corresponding BIFT-id of the multicast data in the other BIER domain according to these parameters.
  • the BIER header is constructed only on the sender, without the need for intermediate devices to participate in the construction of the BIER header. For BIER packets sent across domains, the sender uses the BFIR BFIR-Prefix in other BIER domains for label encapsulation, and then unicasts the BFIR to other domains.
  • the multicast data forwarding in this application is not segmented. It is no longer necessary for intermediate devices (such as BFIR and BFER of each BIER domain along the way) to participate in the generation of BIER headers, which can achieve higher Efficient multicast forwarding.
  • BPG messages can be exchanged across domains.
  • the following conditions are required: 1.
  • the underlying label mapping constructs a TCP connection; 2. Manually configures a BGP peer. 3.
  • the configuration of the BGP peer is based on the configuration command provided by the related carrier. This application is not limited. For details on how to establish a BGP connection through BGP open messages, refer to RFC 1105, which is not mentioned here.
  • TCP connection is constructed with respect to the underlying tag mapping, which is exemplified below.
  • a TCP connection between edge BFRs in different BIER domains can be constructed by the following procedure:
  • the BFER in the BIER domain 200 maps the BFR-Prefix "2.2.2.2” of the BFER to the ASBR 2 in the BIER domain 200 by a label distribution protocol (LDP).
  • LDP label distribution protocol
  • the label corresponding to BFR-Prefix "2.2.2.2” can be used to encapsulate the data sent to the BFER. In this way, ASBR2 can know what label encapsulation is required for data forwarding to 2.2.2.2.
  • the ASBR1 in the BIER domain 100 and the ASBR2 in the BIER domain 200 exchange their respective BFR-Prefix based on the External Border Gateway Protocol (EBGP), and notify the other party to set the corresponding label.
  • EBGP External Border Gateway Protocol
  • ASBR1 to 2.2.2.2 that is, the BFER in BIER domain 200
  • ASBR2 the BFR-Prefix based on the External Border Gateway Protocol
  • ASBR1 directly informs the BFR-Prefix "2.2.2.2" to each boundary BFR (including the sender) in the BIER domain 100 through the Internal Border Gateway Protocol (IBGP), so that the transmission can know if it is to be
  • IBGP Internal Border Gateway Protocol
  • the data is sent to 2.2.2.2, just forward the data to ASBR1. Since the ASBR1 and the sender belong to the same BIER domain (that is, the same AS), the label forwarding mapping relationship has been established between the two. Therefore, the sender only needs to put the data with the target 2.2.2.2 on the label of the reachable ASBR1. 22".
  • ASBR1 receives the data with the target of 2.2.2.2 and is tagged with “22”
  • ASBR2 replaces the label "222” with the label “2222” and finally sends the data labeled "2222” to the BFER in the BIER field 200 of 2.2.2.2.
  • the label corresponding to the BFR-Prefix of the edge BFR in the BIER domain 200 is mapped to the edge BFR (such as the sender) in the BIER domain 100, the sender in the BIER domain 100 and the edge in the BIER domain 200.
  • BFR can establish a TCP connection.
  • the sender in the BIER domain 100 and the edge BFR in the BIER domain 200 can form an EBGP peer (ie, an EBGP peer), and the BGP message can be exchanged through the BGP connection.
  • the edge BFRs in different BIER domains can directly exchange multicast information based on the BGP protocol.
  • the sender in the BIER domain 100 directly transmits the Intra PMSI A-D route to the edge BFRs (ASBR2 and BFER) in the BIER domain 200 through BGP messages to issue multicast information.
  • the edge BFRs (ASBR2 and BFER) in the BIER domain 200 directly perform multicast information feedback to the sender Leaf A-D route through BGP messages.
  • FIG. 11 merely exemplarily illustrates a method for constructing a TCP connection by the underlying tag mapping, and should not be construed as limiting.
  • the multicast data transmission method provided by the present application is described in detail below.
  • the multicast data transmission method provided by the present application may include:
  • Phase 1 (S201): BFIR and BFR in the BIER domain generate their respective BIFT
  • both BFIR and BFR can generate a BIFT reaching each BFER.
  • BFIR can also generate a correspondence table of BFR-Prefix and BFR-id for the BFER in its BIER domain.
  • BFIR and BFR in the BIER domain generate their respective BIFTs
  • BFIR and BFR can perform multicast forwarding according to BIFT-id and Bitstring in the BIER header.
  • BIFT-id is used to tell the BIER router which BIFT to find to forward multicast data.
  • BitString represents the BFR-id of all recipients (BFER) of a multicast data.
  • the sender in the BIER domain 100 can send the Intra PMSI AD route to the BFER-D in the BIER domain 100 through the BGP message, and can directly send the Intra PMSI AD route to the BIER through the BGP message.
  • BGP peers in domain 200 such as BFIR-E, BFER-G
  • BGP peers in BIER domain 300 such as BFIR-E, BFER-G).
  • the sender forms a BGP peer with BFIR and BFER in other BIER domains.
  • other BIER domains refer to the BIER domain where the non-sender is located.
  • the sender can directly send BGP messages to the BFIR and BFER in the BIER domain through the BGP connection.
  • the Intra PMSI A-D route carried in the BGP message is used to advertise the multicast information of the multicast group (such as the multicast group address).
  • the BFIR and the BFER in the other BIER domain receive the BGP message carrying the Intra PMSI A-D route. If the multicast group advertised by the BGP message is interested, the leaf A-D route is used for feedback.
  • the Intra PMSI A-D route can carry the BIER identifier and the identifier of the multicast group (such as multicast group address 232.1.1.1).
  • the BIER identifier is used to indicate that the BGP message carrying the Intra PMSI A-D route is a BIER multicast message.
  • the BFER-D in the BIER domain 100 sends the Leaf A-D route to the sender through the BGP message to perform multicast information feedback.
  • the BGP peers in the BIER domain 200 (such as BFIR-E, BFER-G) and the BGP peers in the BIER domain 300 (such as BFIR-E and BFER-G) also send Leaf AD routes to the BGP messages through BGP messages.
  • the sender performs multicast information feedback.
  • BFIR and BFER in other BIER domains can directly send BGP messages carrying Leaf A-D routes to the sender through BGP connections.
  • the sender receives the BPG message from the BFIR and BFER in the other BIER domain through the BGP connection, and the BGP message carries the Leaf A-D route.
  • the Leaf A-D route can carry the following information:
  • the BFR-id of the BFER can be carried in the Leaf AD route of the BFER feedback in the other BIER domain, the sub-domain to which the BFER belongs, the SI to which the BFR-id of the BFER belongs, and the BFER.
  • a field for carrying sub-domain, SI, BSL, and BFR-id may be added to the Leaf A-D route, and an extended community attribute ("Source-AS extended community") is opened to indicate the identifier of the BIER domain.
  • the sender can determine the BIFT-id according to the three parameters of sub-domain, SI, and BSL, and can determine the BitString according to the BFR-id. Then, the sender can generate the first mapping table by using the BIER domain identifier, BIFT-id and BitString, as shown in the following.
  • a BIER domain is configured with only one sub-domain.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the BFER belongs is not necessarily carried in the Leaf A-D route of the BFER feedback in other BIER domains.
  • the BSL supported by the entire multicast domain can be consistent, that is, the sender knows the BSL without additional notification. Therefore, it is not necessary to carry the BSL in the Leaf A-D route of the BFER feedback in other BIER domains.
  • the leaf A-D route fed back by the BFIR (such as ASBR2) in the other BIER domain may carry the BFR-Prefix of the BFIR and the identifier of the BIER domain to which the BFIR belongs.
  • Sender can generate a second mapping table of sender according to this information, as shown in the following.
  • the edge BFRs of different BIER domains are configured as BGP peers.
  • BGP messages can be directly exchanged through BGP connections to quickly release multicast information and provide fast feedback. That is to say, multicast information distribution and feedback are no longer segmented for BGP interaction, but BGP messages are directly exchanged across domains. The convergence time of multicast release and feedback is significantly shortened, and the effectiveness is high.
  • Phase 3 Generating a correlation mapping table for multicast forwarding
  • the BIFT-id is an index of a fixed length (for example, 20 bits), which is determined by three parameters of sub-domain, SI, and BSL.
  • the sub-domain is not mandatory.
  • the sender can determine the corresponding BIFT-id of each multicast group in each BIER domain according to the sub-domain, SI, and BSL carried in the Leaf A-D route from each BIER domain. For example, the sender determines the corresponding BIFT-id of the corresponding multicast group in the BIER domain 200 according to the sub-domain, SI, and BSL carried in the Leaf A-D route from the BIER domain 200.
  • the corresponding multicast group refers to the multicast group indicated by the multicast information fed back by the Leaf A-D route.
  • bit sequences of the sub-domain, the BSL, and the SI may be sequentially spliced together to form a BIFT-id.
  • bit sequence of the subdomain is "011”
  • bit sequence of the BSL is "0000100”
  • bit sequence of the SI is "0001100100”.
  • the three bit sequences are sequentially spliced together to form a bit sequence of 20 bits in length. 01100001000001100100"
  • the bit sequence is BIFT-id.
  • the sender determines the sub-domain, SI, BSL according to the corresponding BIFT-id of the corresponding multicast group in the other BIER domain, and the sub-domain and SI on which the BIFT-id is determined in the other BIER domain. Same as BSL.
  • the sender can construct a BIFT-id that can be used for BIER route forwarding in other BIER domains.
  • the entire multicast domain multiple BIER domains
  • a BIER packet that successfully performs BIER routing forwarding.
  • a BIER domain can include at least one sub-domain.
  • the corresponding BIFT-id of a multicast group in a BIER domain refers to the BIFT-id corresponding to the multicast group in the at least one sub-domain, and the BitString corresponding to a multicast group in a BIER domain. It refers to the BitString corresponding to the multicast group in the at least one sub-domain.
  • the BIFT-id corresponding to each multicast group in each BIER domain is the BIFT-id corresponding to the multicast data corresponding to the multicast group in each BIER domain.
  • the BitString corresponding to each multicast group in each BIER domain is the BitString corresponding to the multicast data corresponding to the multicast group in each BIER domain.
  • the sender generates the first mapping table exemplarily shown in FIG. 20 according to the BIER domain identifier, BIFT-id, and BitString of each BIER domain.
  • the first mapping table may include a BIFT-id, a BitString corresponding to the multicast group in the at least one BIER domain.
  • the at least one BIER domain may include a BIER domain in which the sender is located and a BIER domain in which the non-sender is located (ie, other BIER domains).
  • the first mapping table may be a correspondence between a multicast group identifier (such as a multicast group address) and a BIER domain identifier, a BIFT-id, and a BitString.
  • the BIER domain identifier, BIFT-id, and BitString corresponding to a multicast group identifier indicate that the multicast group indicated by the multicast group identifier corresponds to the BIFT-id and BitString in the BIER domain indicated by the BIER domain identifier.
  • the corresponding BIFT-id of the multicast group in other BIER domains is the sub-domain to which the receiver of the other BIER domain belongs, the SI to which the BFR-id of the receiver belongs, and the BSL supported by the receiver. It is determined; the corresponding BitString of the multicast group in other BIER domains is determined by the BFR-id of the receiver.
  • the recipient refers to a BFER that is of interest to the multicast group in other BIER domains.
  • the first mapping table can be used to construct a BIER header.
  • its BIER header is constructed only on the sender side, without the need for intermediate devices to participate in the reconstruction of the BIER header.
  • the sender autonomously determines the next hop (ie, the BFIR of other BIER domains as the next hop), instead of using the directly adjacent BFR (ie, BFR-NBR) as the next hop.
  • the multicast data sent to other BIER domains can be forwarded through the BFR in the BIER domain where the sender is located.
  • the BFIR can be directly sent to other BIER domains after being encapsulated by MPLS or GRE. .
  • the next hop of the sender in the BIER domain may be multiple BFIRs in the BIER domain, ie there are multiple next hops.
  • a portion of the plurality of BFIRs may be responsible for forwarding multicast data to some sub-domains in the BIER domain, and another portion of the plurality of BFIRs may be responsible for forwarding multicast data to other sub-s in the BIER domain. Domain.
  • the sender can determine the multicast data according to the corresponding BIFT-id (the BIFT-id and the sub-domain one-to-one correspondence) in the BIER domain according to the multicast data. Which BFIR is forwarded to.
  • BIFT-id can indicate the sub-domain to which the multicast data will be sent.
  • the present application is not limited, and may be referred to actual requirements.
  • the amount of data forwarding carried by each of the multiple next hops can be set from the perspective of load balancing.
  • the next hop of the sender in the BIER domain may be a BFIR in the BIER domain, ie there is only one next hop.
  • This BFIR can be responsible for forwarding multicast data to all target sub-domains in the BIER domain.
  • the target sub-domain refers to the sub-domain in which the receiver of the multicast data is located.
  • the sender may generate the second mapping table exemplarily shown in FIG. 21 according to the autonomously determined next hop.
  • the second mapping table may include: a BIFT-id corresponding to the multicast group in the at least one BIER domain, and a BFR-Prefix of the next hop of the sender in the at least one BIER domain.
  • the at least one BIER domain may include a BIER domain in which the sender is located and a BIER domain in which the non-sender is located (ie, other BIER domains).
  • the sender's next hop may be BFR-NBR.
  • the sender's next hop may be the BFIR of other BIER domains.
  • the second mapping table may be a correspondence between a multicast group identifier (such as a multicast group address) and a BIER domain identifier, a BIFT-id, and a BFR-Prefix.
  • the BIER domain identifier, BIFT-id, and BFR-Prefix corresponding to a multicast group identifier indicate that the multicast group represented by the multicast group corresponds to the BIFT-id and logical next hop in the BIER domain indicated by the BIER domain identifier.
  • BFR-Prefix a multicast group identifier
  • the BIFT-id corresponding to the domain identifier of the BIER domain in the second mapping table corresponds to Multiple BFR-Prefix; in case the sender has only one next hop in the BIER domain, the BIFT-id corresponding to the domain identifier of the BIER domain in the second mapping table corresponds to a BFR -Prefix.
  • the second mapping table may be used to apply an MPLS label or a GRE label to the BIER data packet encapsulated by the multicast data to implement cross-domain (inter-domain) forwarding.
  • the sender can determine the target BIER field to which the BIER packet needs to be sent according to the BIIER-id carried in the BIER header of the BIER packet, and then the next hop of the sender in the target BIER domain can be the BIER data.
  • the packet is sent to the next hop after the MPLS label or GRE label is applied.
  • the sender may be configured with an egress port for sending multicast data to at least one BIER domain.
  • the second mapping table may further include: an identifier of the egress port. In this way, it is convenient to know which outgoing port to use to forward multicast data to a specific BIER domain.
  • the first mapping table and the second mapping table may be two independent mapping relationships, that is, two tables.
  • the first mapping table and the second mapping table may also exist in one mapping relationship, that is, two parts of one table.
  • the present application does not limit the data representation of the first mapping table and the second mapping table, and does not have to be in the form of a table.
  • Phase 4 Multicast data forwarding (S207-S211): intra-domain forwarding and inter-domain forwarding
  • the sender may determine the corresponding BIFT-id and BitString of the multicast data in the BIER domain 100 from the first mapping table.
  • the corresponding BIFT-id and BitString of the multicast data in the BIER domain 100 are the BIFT-id and BitString corresponding to the multicast group corresponding to the multicast data in the BIER domain 100, respectively.
  • This first mapping table has been generated in S205.
  • the sender can generate a BIER header by using the BitString and the BIFT-id, and perform BIER encapsulation on the multicast data to obtain a BIER packet.
  • the sender and the transit BFR in the BIER domain 100 can forward the multicast data to the recipients in the BIER domain 100 in accordance with the BIER forwarding mechanism based on the BIER header.
  • the receiver in the BIER domain 100 receives the BIER packet, and then decapsulates the BIER packet to obtain multicast data, and sends the multicast data to the user side device.
  • the sender (in the BIER domain 100) unicasts the multicast data to the BFIR in the BIER domain 200.
  • the sender may determine the corresponding BIFT-id and BitString of the multicast data in the BIER domain 200 from the first mapping table, and generate the BIER by using the BitString and the BIFT-id. Header, BIER encapsulation of the multicast data to obtain a BIER packet.
  • This first mapping table has been generated in S205.
  • the sender can determine the BFR-Prefix of the next hop of the sender in the BIER domain 200 from the second mapping table generated in S206 according to the BIFT-id in the BIER header, and can use the BFR-Prefix as the BFR-Prefix.
  • the BIER packet is tagged with an MPLS label or a GRE tag, and the tagged BIER packet is sent to the BFIR in the BIER domain 200.
  • the BFIR in the BIER domain 200 can receive the tagged BIER packet, and can remove the tag to obtain the BIER packet.
  • the BIER domain 200 forwards the multicast data based on the BIER forwarding mechanism.
  • the BFIR and the transit BFR in the BIER domain 200 can obtain the BIFT-id and the BitString from the BIER header of the BIER packet, and finally forward the BIER packet to the BIER domain 200 according to the BIFT indicated by the BIFT-id and the bit string.
  • Receiver For details, refer to S108 and S110 in the existing BIER-MVPN solution, and details are not described herein again.
  • the receiver in the BIER domain 200 receives the BIER packet, and then decapsulates the BIER packet to obtain multicast data, and sends the multicast data to the user side device.
  • S210-S211 describes a process of forwarding multicast data to a receiver in the BIER domain 300, which is the same as the process of forwarding multicast data to a receiver in the BIER domain 200, and details are not described herein.
  • Multicast data forwarding between BIER domains (S208, S210): For multicast data sent to other BIER domains, the sender performs BIER encapsulation on the multicast data to obtain a BIER packet, and then puts the BIER packet on the MPLS label. Or the BFIR sent to other BIER domains unicast after the GRE tag.
  • Multicast data forwarding in the BIER domain (S207, S209, S211): To forward multicast data according to the BIER mechanism, refer to the existing BIER-MVPN scheme.
  • the multicast data forwarding in this application is not segmented, and the BIER header is constructed only on the Sender side, and intermediate devices are no longer needed (such as BFIR of each BIER domain along the way). , BFER) participate in the generation of BIER headers, enabling more efficient multicast forwarding.
  • the key work of multicast data forwarding occurs on the sender.
  • the working principle of the sender can be exemplarily shown in FIG. 22: for multicast data sent to multiple BIER domains, the sender first copies the multicast data, and then sends the first mapping table generated in S205 to different BIERs. The domain's multicast data constructs the BIER header to get the BIER packet. Then, the sender can label the BIER data packet sent to other BIER domains according to the second mapping table generated in S206, and unicast to the next hop in the other BIER domain of the sender. For BIER packets sent to the domain (that is, the BIER domain where the sender is located), the sender forwards the multicast data based on the BIER forwarding mechanism. Refer to the existing BIER-MVPN scheme.
  • the receivers interested in the multicast group (S, G) are: BFER-D (BFR-id is 100) in the BIER domain 100, and BFER-G in the BIER domain 200. (BFR-id is 100) and BFER-J in BIER domain 300 (BFR-id is 200).
  • the label corresponding to the BFR-Prefix of the BFER-G is "200”
  • the label corresponding to the BFR-Prefix of the BFER-J is "300".
  • the sender copies the multicast data into 3 copies.
  • the sender encapsulates the BIER headers for the three pieces of multicast data based on the first mapping table.
  • the BIER header encapsulated by the multicast data sent to the BFER-D includes: a corresponding BIFT-id (ie, BIFT-100) of the multicast data in the BIER domain 100 and a BitString corresponding to the multicast data in the BIER domain 100 ( The 100th bit is 1).
  • the BIER header of the multicast data sent to the BFER-G includes: the corresponding BIFT-id (ie BIFT-200) of the multicast data in the BIER domain 200 and the BitString corresponding to the multicast data in the BIER domain 200 (100th) The bits are 1).
  • the BIER header of the multicast data sent to BFER-J includes: the corresponding BIFT-id (ie BIFT-300) of the multicast data in the BIER domain 300 and the BitString corresponding to the multicast data in the BIER domain 300 (200th) The bits are 1).
  • the BIER domain 100 forwards multicast data based on the BIER forwarding mechanism. For details, refer to the existing BIER-MVPN scheme. After the receiver in the BIER domain 100 receives the BIER packet, the BIER packet can be decapsulated, the multicast data is read, and the multicast data is forwarded to the user side device.
  • the sender signs the BIER packet "200” and unicasts the BIER packet tagged with "200" to the BFIR-E (ie ASBR2) in the BIER domain 200.
  • the BFIR-E in the BIER domain 200 receives the BFIR-E in the BIER domain 200, the label "200" can be removed to obtain the BIER packet.
  • the BIER domain 200 forwards multicast data based on the BIER forwarding mechanism. For details, refer to the existing BIER-MVPN solution. After the receiver in the BIER domain 200 receives the BIER packet, the BIER packet can be decapsulated, the multicast data is read, and the multicast data is forwarded to the user side device.
  • the sender signs the BIER packet "300” and unicasts the BIER packet tagged with "300" to BFIR-H (i.e., ASBR3) in the BIER domain 300.
  • BFIR-H i.e., ASBR3
  • the label "300” can be removed to obtain the BIER packet.
  • the BIER domain 300 forwards multicast data based on the BIER forwarding mechanism. For details, refer to the existing BIER-MVPN solution.
  • the receiver in the BIER domain 200 receives the BIER packet, the BIER packet can be decapsulated, the multicast data is read, and the multicast data is forwarded to the user side device.
  • the multicast data of the receivers sent to other BIER domains no longer need to pass through the BIER domain 100 and the BIER domain.
  • the intermediate device such as BFIR in BIER domain 200
  • the intermediate device no longer participates in the generation of BIER header, which can achieve more efficient multicast forwarding.
  • the sender may not send BGP messages to the BFIRs in other BIER domains to advertise multicast information.
  • the BFIRs in other BIER domains may sense and parse the Intra PMSI A-D routes carried in the BGP messages.
  • This extension can be as shown in Figure 24, including:
  • Phase 1 S301: BFIR and BFR in the BIER domain generate their respective BIFT
  • the sender does not send BGP messages to the BFIR in other BIER domains to advertise the multicast information, and the BFIR in other BIER domains can be perceived.
  • the Intra PMSI AD route carried in the BGP message is parsed. For details, see S302-S303.
  • the BFIR in other BIER domains can parse only the Intra PMSI AD routes of the publishable multicast information of type 1, 2, 3, and 5, and then parse the PMSI Tunnel Attribute carried in it. If the PMSI Tunnel Attribute contains the BIER identifier, the Leaf AD route is fed back to the sender.
  • the Intra PMSI A-D route including the BIER logo can be referred to FIG.
  • Phase 3 Generate a correlation mapping table for multicast forwarding
  • Phase 4 Multicast data forwarding (S308-S312): intra-domain forwarding and inter-domain forwarding
  • the router 100 is a BFR in the BIER domain, and can be implemented as a BFIR in the BIER domain, or as a transit BFR in the BIER domain, or as a BFER in the BIER domain.
  • the router 100 may include one or more processors 101, a memory 103, and a communication interface 105. These components may be connected by bus 104 or other means, and FIG. 25 is exemplified by a bus connection. among them:
  • Communication interface 105 can be used by router 100 to communicate with other communication devices, such as other routers.
  • communication interface 105 can include a wired communication interface, such as a wide area network (WAN) interface, a local area network (LAN) interface, and the like.
  • WAN wide area network
  • LAN local area network
  • communication interface 105 may also include a wireless communication interface, such as a wireless local area network (WLAN) interface or the like.
  • WLAN wireless local area network
  • Memory 103 is coupled to processor 101 for storing various software programs and/or sets of instructions.
  • memory 103 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid state storage devices.
  • the memory 103 can store an operating system (hereinafter referred to as a system) such as an embedded operating system such as uCOS, VxWorks, or RTLinux.
  • the memory 103 can also store a network communication program that can be used to communicate with one or more additional devices, one or more user time devices, one or more network devices.
  • router 100 may be implemented as a sender in the above method embodiments, such as BFIR-A in BIER domain 100 in FIG.
  • the memory 103 can be used to store an implementation program of the multicast data transmission method provided by one or more embodiments of the present application on the sender side.
  • the processor 101 can be used to read and execute computer readable instructions. Specifically, the processor 101 can be used to invoke a program stored in the memory 103, such as an implementation program of the multicast data transmission method provided by one or more embodiments of the present application on the sender side, and execute instructions included in the program.
  • a program stored in the memory 103 such as an implementation program of the multicast data transmission method provided by one or more embodiments of the present application on the sender side, and execute instructions included in the program.
  • router 100 may be implemented as BFIR in other domains in the above method embodiments (such as ASBR 2 in BIER domain 200 in FIG. 6).
  • the memory 103 can be used to store an implementation program of the multicast data transmission method provided by one or more embodiments of the present application on the BFIR side.
  • the processor 101 can be used to read and execute computer readable instructions. Specifically, the processor 101 can be used to invoke a program stored in the memory 103.
  • the multicast data transmission method provided by one or more embodiments of the present application implements the program on the BFIR side, and executes instructions included in the program.
  • the implementation of the multicast data transmission method provided by one or more embodiments of the present application on the BFIR side refer to the foregoing method embodiments.
  • router 100 may be implemented as a recipient within other domains in the above method embodiments (eg, BFER-G within BIER domain 200 in FIG. 6).
  • the memory 103 can be used to store an implementation program of the multicast data transmission method provided by one or more embodiments of the present application on the receiver side.
  • the processor 101 can be used to invoke a program stored in the memory 103, such as the implementation of the multicast data transmission method provided by one or more embodiments of the present application on the receiver side, and execute the instructions included in the program. .
  • the multicast data transmission method provided by one or more embodiments of the present application on the receiver side please refer to the foregoing method embodiment.
  • the router 100 shown in FIG. 25 is only one implementation of the embodiment of the present application. In an actual application, the router 100 may further include more or less components, which are not limited herein.
  • Communication system 200 can include communication devices: at least one first router 400 and at least one second router 500.
  • the first router 400 and the second router 500 are in the same BIER domain.
  • the first router 400 may be the BFIR in other BIER domains in the foregoing method embodiments
  • the second router 500 may be the receiver BFER in other BIER domains in the foregoing method embodiments.
  • the communication system 200 may further include at least one third router 300, where the BIER domain of the third router 300 is different from the BIER domain where the first router 400 and the second router 500 are located.
  • the third router 300 may be the sender in the above method embodiment.
  • the communication system 200 and the communication device therein can implement the multicast data transmission method described in the embodiment of FIG. 14 or FIG. The description is expanded below.
  • the third router 300 may include a processing unit 301 and a communication unit 303. among them:
  • the processing unit 301 is configured to determine, according to the first mapping table, the BIFT-id and the BitString corresponding to the multicast data in the other BIER domain, where the BIFT-id is at least the BFR of the second router 500 in the other BIER domain.
  • the SI to which the id belongs and the BSL supported by the first BFER determine that the BitString is determined by at least the BFR-id of the second router 500, and the second router 500 is used to receive the BFER of the multicast data in the other BIER domain, and the first mapping table includes the BFD-id.
  • the processing unit 301 is further configured to encapsulate the multicast data into a BIER packet, where the BIER header of the BIER packet includes a BIFT-id and a bit string corresponding to the multicast data in other BIER domains.
  • the processing unit 301 is further configured to label the BIER data packet, where the label is a label corresponding to the prefix of the BFIR in the other BIER domain.
  • the communication unit 303 can be configured to send the BIER data packet after the label is sent to the first router 400 in the other BIER domain.
  • the other BIER domains are not the BIER domains in which the third router 300 is located.
  • the above label may be an MPLS label or a GRE label.
  • the multicast data forwarding in this application is not segmented, and the BIER header is constructed only on the side of the third router 300, and no intermediate device is needed (such as each BIER along the way).
  • the BFIR and BFER of the domain participate in the generation of the BIER header, enabling more efficient multicast forwarding.
  • the processing unit 301 is further configured to: before labeling the BIER data packet, determine the second mapping table according to the corresponding BIFT-id in the other BIER domain according to the multicast data.
  • the logical next hop of the third router 300 is BFIR in other BIER domains.
  • the second mapping table includes: a BIFT-id corresponding to the multicast data in the at least one BIER domain, and a logical next hop prefix of the third router 300 in the at least one BIER domain.
  • the third router 300 can autonomously determine the next hop (ie, the BFIR of other BIER domains as the next hop), instead of using the directly adjacent BFR (ie, BFR-NBR) as the next hop.
  • the multicast data sent to other BIER domains is forwarded through the BFR in the BIER domain where the third router 300 is located.
  • the BFIR can be directly sent to other BIER domains after the multicast data is encapsulated by MPLS or GRE. .
  • the second mapping table may further include: an identifier on the third router 300 for respectively transmitting the multicast data to the port of the at least one BIER domain.
  • the processing unit 301 is further configured to determine, according to the BIFT-id of the multicast data in the other BIER domain, the identifier of the first port used for sending the multicast data to the other BIER domain from the second mapping table.
  • the communication unit 303 is further configured to send the tagged BIER data packet to the first router 400 in the other BIER domain through the first port.
  • the third router 300 forms a BGP peer with the first router 400 and the second router 500 in other BIER domains. Before forwarding the multicast data to the BFIR in other BIER domains, the third router 300 can learn from the multicast information release and feedback which BFERs in the BIER domain are interested in the multicast group. The following details:
  • the communication unit 303 is further configured to send a BGP message to the BFIR and the BFER in the other BIER domain through the BGP connection.
  • the Intra PMSI A-D route carried in the BGP message is used to advertise multicast information (such as a multicast group address).
  • the Intra PMSI A-D route can carry the BIER identifier and the identifier of the multicast group corresponding to the multicast data (such as the multicast group address 232.1.1.1).
  • the BIER identifier is used to indicate that the BGP message carrying the Intra PMSI A-D route is a BIER multicast message.
  • the communication unit 303 can also be used to directly receive BPG messages from the first router 400 and the second router 500 in other BIER domains through the BGP connection, and the BGP message carries the Leaf A-D route.
  • the Leaf A-D route can carry the following information:
  • the Leaf AD route fed back by the second router 500 in the other BIER domain may carry the BFR-id of the second router 500, the sub-domain to which the second router 500 belongs, and the SI to which the BFR-id of the second router 500 belongs.
  • a field for carrying sub-domain, SI, BSL, and BFR-id may be added to the Leaf A-D route, and an extended community attribute (“Source-AS extended community") is opened to indicate the identifier of the BIER domain.
  • the third router 300 can determine the BIFT-id according to the three parameters of sub-domain, SI, and BSL, and can determine the BitString according to the BFR-id. Then, the third router 300 can generate a first mapping table by using the identifier of the BIER domain, BIFT-id, and BitString.
  • a BIER domain is configured with only one sub-domain.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the second router 500 belongs does not have to be carried in the Leaf A-D route fed back by the second router 500 in the other BIER domain.
  • the BSL supported by the entire multicast domain may be consistent, ie, without additional notification, the third router 300 also knows the BSL. Therefore, the BSL is not necessarily carried in the Leaf A-D route fed back by the second router 500 in the other BIER domain.
  • the leaf A-D route fed back by the first router 400 in the other BIER domain may carry the BFR-Prefix of the first router 400 and the identifier of the BIER domain of the first router 400.
  • the third router 300 can generate a second mapping table based on the information.
  • edge BFRs of different BIER domains are configured as BGP peers.
  • BGP messages can be directly exchanged through BGP connections to quickly release multicast information and provide fast feedback. That is to say, multicast information distribution and feedback are no longer segmented for BGP interaction, but BGP messages are directly exchanged across domains. The convergence time of multicast release and feedback is significantly shortened, and the effectiveness is high.
  • the first router 400 may include a processing unit 401 and a communication unit 403. among them:
  • the communication unit 403 is configured to receive the labeled BIER data packet sent by the third router 300, where the label is a label corresponding to the prefix of the first router 400, and the BIER data packet is obtained by the third router 300 encapsulating the multicast data.
  • the BIER header of the BIER packet includes the corresponding BIFT-id and bit string of multicast data in other BIER domains.
  • the BIFT-id is determined by at least the SI to which the BFR-id of the second router 500 belongs and the bit string length supported by the second router 500.
  • the bit string is determined by at least the BFR-id of the second router 500.
  • the second router 500 is a BFER for receiving the multicast data in other BIER domains.
  • the processing unit 401 is configured to remove the label to obtain the BIER data packet, and obtain a BIFT-id and a bit string from a BIER header of the BIER data packet.
  • the communication unit 403 is further configured to forward the BIER data packet to the second router 500 according to the BIFT indicated by the BIFT-id and the bit string.
  • the other BIER domains are not the BIER domains in which the third router 300 is located.
  • the above label may be an MPLS label or a GRE label.
  • the corresponding BIFT-id of the multicast data in other BIER domains is also determined by the sub-domain to which the second router 500 belongs.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the BFER belongs is not necessarily carried in the Leaf A-D route fed back by the second router 500.
  • the third router 300 and the first router 400 form a BGP peer.
  • the communication unit 403 is further configured to receive the first BGP message sent by the third router 300 by using the BGP connection.
  • the Intra PMSI A-D route carried in the first BGP message includes a BIER identifier and an identifier of the multicast group corresponding to the multicast data.
  • the communication unit 403 is further configured to send a second BGP message to the third router 300 by using the BGP connection, where the Leaf AD route carried by the second BGP message includes the prefix of the first router 400 and the BIER domain of the first router 400.
  • logo the third router 300 can generate a second mapping table according to the information, and specifically refer to related content described in the first aspect.
  • the second router 500 may include a processing unit 501 and a communication unit 403. among them:
  • the communication unit 503 is configured to receive a BIER data packet sent by the third router 300, where the BIER data packet is encapsulated by the third router 300, and the BIER header of the BIER data packet includes the multicast data corresponding to the other BIER domain.
  • BIFT-id and bit string The BIFT-id is determined by at least the SI to which the BFR-id of the second router 500 belongs and the bit string length supported by the second router 500.
  • the bit string is determined by at least the BFR-id of the second router 500.
  • the second router 500 is a BFER for receiving the multicast data in other BIER domains.
  • the processing unit 501 is configured to decapsulate the BIER data packet to obtain the multicast data.
  • the communication unit 503 is further configured to send the multicast data to the user side device.
  • the other BIER domains are not the BIER domains in which the third router 300 is located.
  • the above label may be an MPLS label or a GRE label.
  • the third router 300 and the second router 500 form a BGP peer.
  • the communication unit 503 is further configured to receive the first BGP message sent by the third router 300 by using the BGP connection.
  • the Intra PMSI A-D route carried in the first BGP message includes a BIER identifier and an identifier of the multicast group corresponding to the multicast data.
  • the communication unit 503 is further configured to send the second BGP message to the third router 300 by using the BGP connection.
  • the Leaf AD route carried by the second BGP message includes the BFR-id of the second router 500 and the BFR of the second router 500. ID of the SI and other BIER domains to which the id belongs. In this way, the third router 300 can generate a first mapping table according to the information, and specifically refer to the related content described in the first aspect.
  • the corresponding BIFT-id of the multicast data in other BIER domains is also determined by the sub-domain to which the second router 500 belongs.
  • the leaf A-D route fed back by the second router 500 may further carry the sub-domain to which the second router 500 belongs. That is, the Leaf A-D route carried by the second BGP message may further include a sub-domain to which the second router 500 belongs.
  • only one sub-domain is configured for one BIER domain.
  • the BIFT-id can be determined only by the two parameters of the SI and the BSL. Therefore, the sub-domain to which the BFER belongs is not necessarily carried in the Leaf A-D route fed back by the second router 500.
  • the Leaf A-D route carried by the second BGP message may further include a BSL supported by the second router 500.
  • the BSL supported by the entire multicast domain may be consistent, that is, the third router 300 also knows the BSL without additional notification. Therefore, the BSL is not necessarily carried in the Leaf A-D route fed back by the second router 500.
  • the program can be stored in a computer readable storage medium, when the program is executed
  • the flow of the method embodiments as described above may be included.
  • the foregoing storage medium includes various media that can store program codes, such as a ROM or a random access memory RAM, a magnetic disk, or an optical disk.

Landscapes

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

Abstract

La présente invention concerne un procédé de transmission de données de multiddifusion. Le procédé peut comprendre : un premier BFIR dans un premier domaine BIER déterminant un BIFT-id et une BitString correspondant à des données de multidiffusion dans un second domaine BIER, dans lequel le BIFT-id est au moins déterminé par un SI auquel appartient un BFR-id d'un premier BFER et une BSL supportée par le premier BFER, et le premier BFER est un BFER pour recevoir les données multidiffusion dans le second domaine BIER; le premier BFIR encapsulant les données de multidiffusion dans un paquet de données BIER, dans lequel un en-tête BIER du paquet de données BIER comprend le BIFT-id et la BitString correspondant aux données de multidiffusion dans le second domaine BIER; et enfin, le premier BFIR envoyant le paquet de données BIER fourni avec une étiquette à un second BFIR, l'étiquette étant une étiquette correspondant au préfixe du second BFIR. La solution peut améliorer significativement l'opportunité de transmission en multidiffusion.
PCT/CN2019/085739 2018-05-08 2019-05-07 Procédé de transmission de données de multidiffusion, appareil et système associés WO2019214589A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP19800073.9A EP3783849B1 (fr) 2018-05-08 2019-05-07 Procédé de transmission de données de multidiffusion, appareil et système associés
KR1020207034928A KR102447132B1 (ko) 2018-05-08 2019-05-07 멀티 캐스트 데이터 전송 방법, 관련 장치 및 시스템
JP2020562656A JP7123174B2 (ja) 2018-05-08 2019-05-07 マルチキャストデータ送信方法、関連装置、およびシステム
US17/090,616 US11616656B2 (en) 2018-05-08 2020-11-05 Multicast data transmission method, related apparatus, and system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201810434350.7 2018-05-08
CN201810434350 2018-05-08
CN201810507664.5A CN110460522B (zh) 2018-05-08 2018-05-24 组播数据传输方法、相关装置及系统
CN201810507664.5 2018-05-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/090,616 Continuation US11616656B2 (en) 2018-05-08 2020-11-05 Multicast data transmission method, related apparatus, and system

Publications (1)

Publication Number Publication Date
WO2019214589A1 true WO2019214589A1 (fr) 2019-11-14

Family

ID=68467726

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/085739 WO2019214589A1 (fr) 2018-05-08 2019-05-07 Procédé de transmission de données de multidiffusion, appareil et système associés

Country Status (1)

Country Link
WO (1) WO2019214589A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112104560A (zh) * 2020-07-27 2020-12-18 深圳市风云实业有限公司 一种组播路径的定制方法
CN112491729A (zh) * 2020-09-22 2021-03-12 中兴通讯股份有限公司 一种数据处理方法、装置、存储介质及电子装置
CN112511444A (zh) * 2020-04-03 2021-03-16 中兴通讯股份有限公司 一种组播流量传输方法、装置、通信节点及存储介质
CN112511443A (zh) * 2020-03-26 2021-03-16 中兴通讯股份有限公司 消息处理方法、装置、设备、存储介质及系统
CN112995091A (zh) * 2019-12-02 2021-06-18 中兴通讯股份有限公司 数据压缩方法、装置、网络设备及存储介质
WO2021164245A1 (fr) * 2020-02-20 2021-08-26 华为技术有限公司 Procédé de partage de charge et premier dispositif de réseau
WO2021228090A1 (fr) * 2020-05-11 2021-11-18 华为技术有限公司 Procédé et appareil d'envoi de message de multidiffusion
CN113765809A (zh) * 2020-06-05 2021-12-07 华为技术有限公司 Bier组播流量的统计方法、设备以及系统
CN113992565A (zh) * 2021-09-29 2022-01-28 新华三大数据技术有限公司 一种组播报文处理方法及装置
CN115022232A (zh) * 2022-07-06 2022-09-06 中国联合网络通信集团有限公司 组播组的管理方法、装置、设备及存储介质
CN115022241A (zh) * 2022-05-31 2022-09-06 烽火通信科技股份有限公司 一种bier自动配置及管理bsl的方法和装置
EP4277228A1 (fr) * 2022-05-13 2023-11-15 Huawei Technologies Co., Ltd. Procédé de communication de multidiffusion et appareil associé
EP4277227A1 (fr) * 2022-05-13 2023-11-15 Huawei Technologies Co., Ltd. Procédé de communication de multidiffusion et appareil associé
CN112511444B (zh) * 2020-04-03 2024-06-04 中兴通讯股份有限公司 一种组播流量传输方法、装置、通信节点及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150078377A1 (en) * 2013-09-17 2015-03-19 Cisco Technology, Inc. Bit Indexed Explicit Replication
US20160087890A1 (en) * 2014-09-19 2016-03-24 Telefonaktiebolaget L M Ericsson (Publ) Automated determination of tree attributes and assignment of receiver identifiers by distributed election in multicast architectures relying on packets identifying intended receivers
US20160191372A1 (en) * 2014-12-31 2016-06-30 Juniper Networks, Inc. Bit index explicit replication (bier)forwarding for network device components
CN106209629A (zh) * 2014-11-06 2016-12-07 瞻博网络公司 确定性的且优化的比特索引显式复制（bier）转发
CN106341327A (zh) * 2015-07-08 2017-01-18 中兴通讯股份有限公司 一种bier报文的传输方法及系统
CN107592262A (zh) * 2016-07-07 2018-01-16 中兴通讯股份有限公司 报文发送方法和装置、报文跨域转发的网络架构

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150078377A1 (en) * 2013-09-17 2015-03-19 Cisco Technology, Inc. Bit Indexed Explicit Replication
US20160087890A1 (en) * 2014-09-19 2016-03-24 Telefonaktiebolaget L M Ericsson (Publ) Automated determination of tree attributes and assignment of receiver identifiers by distributed election in multicast architectures relying on packets identifying intended receivers
CN106209629A (zh) * 2014-11-06 2016-12-07 瞻博网络公司 确定性的且优化的比特索引显式复制（bier）转发
US20160191372A1 (en) * 2014-12-31 2016-06-30 Juniper Networks, Inc. Bit index explicit replication (bier)forwarding for network device components
CN106341327A (zh) * 2015-07-08 2017-01-18 中兴通讯股份有限公司 一种bier报文的传输方法及系统
CN107592262A (zh) * 2016-07-07 2018-01-16 中兴通讯股份有限公司 报文发送方法和装置、报文跨域转发的网络架构

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", INTERNET ENGINEERING TASK FORCE (IETF), 12 January 2018 (2018-01-12) - 31 January 2018 (2018-01-31), pages 1 - 24, XP015122285 *
WIJNANDS.IJ.: "Multicast VPN Using Bit Index Explicit Replication (BIER)", INTERNET ENGINEERING TASK FORCE (IETF), 30 April 2018 (2018-04-30), pages 1 - 43, XP055753750 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112995091A (zh) * 2019-12-02 2021-06-18 中兴通讯股份有限公司 数据压缩方法、装置、网络设备及存储介质
WO2021164245A1 (fr) * 2020-02-20 2021-08-26 华为技术有限公司 Procédé de partage de charge et premier dispositif de réseau
CN112511443A (zh) * 2020-03-26 2021-03-16 中兴通讯股份有限公司 消息处理方法、装置、设备、存储介质及系统
CN112511444A (zh) * 2020-04-03 2021-03-16 中兴通讯股份有限公司 一种组播流量传输方法、装置、通信节点及存储介质
CN112511444B (zh) * 2020-04-03 2024-06-04 中兴通讯股份有限公司 一种组播流量传输方法、装置、通信节点及存储介质
EP4142227A4 (fr) * 2020-05-11 2023-10-25 Huawei Technologies Co., Ltd. Procédé et appareil d'envoi de message de multidiffusion
WO2021228090A1 (fr) * 2020-05-11 2021-11-18 华为技术有限公司 Procédé et appareil d'envoi de message de multidiffusion
CN113765809A (zh) * 2020-06-05 2021-12-07 华为技术有限公司 Bier组播流量的统计方法、设备以及系统
CN112104560A (zh) * 2020-07-27 2020-12-18 深圳市风云实业有限公司 一种组播路径的定制方法
CN112491729A (zh) * 2020-09-22 2021-03-12 中兴通讯股份有限公司 一种数据处理方法、装置、存储介质及电子装置
EP4221102A4 (fr) * 2020-09-22 2024-03-27 Zte Corp Procédé et appareil de traitement de données, support de stockage et appareil électronique
CN113992565A (zh) * 2021-09-29 2022-01-28 新华三大数据技术有限公司 一种组播报文处理方法及装置
CN113992565B (zh) * 2021-09-29 2023-11-07 新华三大数据技术有限公司 一种组播报文处理方法及装置
EP4277228A1 (fr) * 2022-05-13 2023-11-15 Huawei Technologies Co., Ltd. Procédé de communication de multidiffusion et appareil associé
EP4277227A1 (fr) * 2022-05-13 2023-11-15 Huawei Technologies Co., Ltd. Procédé de communication de multidiffusion et appareil associé
CN115022241B (zh) * 2022-05-31 2023-06-09 烽火通信科技股份有限公司 一种bier自动配置及管理bsl的方法和装置
CN115022241A (zh) * 2022-05-31 2022-09-06 烽火通信科技股份有限公司 一种bier自动配置及管理bsl的方法和装置
CN115022232B (zh) * 2022-07-06 2023-05-16 中国联合网络通信集团有限公司 组播组的管理方法、装置、设备及存储介质
CN115022232A (zh) * 2022-07-06 2022-09-06 中国联合网络通信集团有限公司 组播组的管理方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
JP7123174B2 (ja) マルチキャストデータ送信方法、関連装置、およびシステム
WO2019214589A1 (fr) Procédé de transmission de données de multidiffusion, appareil et système associés
JP7208386B2 (ja) パケット転送方法、パケット送信装置、およびパケット受信装置
US8625465B1 (en) Auto-discovery of virtual private networks
US8953590B1 (en) Layer two virtual private network having control plane address learning supporting multi-homed customer networks
US8339973B1 (en) Multicast traceroute over MPLS/BGP IP multicast VPN
US8098656B2 (en) Method and apparatus for implementing L2 VPNs on an IP network
WO2016177087A1 (fr) Procédé et dispositif d'émission de paquet de réplication explicite à indexation de bits (bier)
US7626984B2 (en) Method and apparatus for providing congruent multicast and unicast routing
WO2018228490A1 (fr) Procédé, dispositif et système de traversée de domaine de multidiffusion et support de stockage lisible par ordinateur
WO2016188501A1 (fr) Procédé de mise en œuvre de réplication explicite d'indice binaire et routeur d'acheminement binaire
CN110832813A (zh) 使用分段路由的以太网虚拟专用网
US9288067B2 (en) Adjacency server for virtual private networks
WO2016198017A1 (fr) Procédé et appareil de transmission d'une adresse de multidiffusion
US20230155932A1 (en) Multicast traffic transmission method and apparatus, communication node, and storage medium
US9100201B1 (en) Inter-site PIM-dense mode and PIM-BSR support for MPLS/BGP IP VPNs
WO2018177273A1 (fr) Procédé et appareil de traitement sur la base d'informations de bier
US20230081052A1 (en) Method and apparatus for sending multicast packet
WO2020021558A1 (fr) Procédés, appareil et supports lisibles par machine se rapportant à un calcul de chemin dans un réseau de communication
WO2024007762A1 (fr) Procédé de publication de voie d'acheminement, et procédé et appareil de communication
EP3863237B1 (fr) Procédé de retransmission de paquets, dispositif de transmission de paquets et dispositif de réception de paquets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19800073

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020562656

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019800073

Country of ref document: EP

Effective date: 20201119

ENP Entry into the national phase

Ref document number: 20207034928

Country of ref document: KR

Kind code of ref document: A