WO2019214589A1

WO2019214589A1 - Multicast data transmission method, related apparatus and system

Info

Publication number: WO2019214589A1
Application number: PCT/CN2019/085739
Authority: WO
Inventors: 夏怒; 陈建; 朱夏; 韦乃文
Original assignee: 华为技术有限公司
Priority date: 2018-05-08
Filing date: 2019-05-07
Publication date: 2019-11-14

Abstract

Disclosed is a multicast data transmission method. The method can comprise: a first BFIR in a first BIER domain determining a BIFT-id and a BitString corresponding to multicast data in a second BIER domain, wherein the BIFT-id is at least determined by an SI to which a BFR-id of a first BFER belongs and a BSL supported by the first BFER, and the first BFER is a BFER for receiving the multicast data in the second BIER domain; the first BFIR encapsulating the multicast data into a BIER data packet, wherein a BIER header of the BIER data packet comprises the BIFT-id and the BitString corresponding to the multicast data in the second BIER domain; and finally, the first BFIR sending the BIER data packet provided with a tag to a second BFIR, wherein the tag is a tag corresponding to a prefix of the second BFIR. The solution can significantly improve the timeliness of multicast transmission.

Description

Multicast data transmission method, related device and system

Technical field

The present application relates to the field of multicast technologies, and in particular, to a multicast data transmission method, related apparatus, and system.

Background technique

With the development of large video services such as Internet video services, virtual reality (VR), and augmented reality (AR), traffic replication, backup, and distribution within and between data centers (DCs) For storage applications, the demand for multicast services has exploded. Traditional multicast technology has brought about an explosive growth of intermediate network multicast tables and multicast states, and has become the most complex and uncontrollable part of multicast networks.

The 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 A combination of ethernet virtual private network (EVPN) can achieve complete VPN multicast. Among them, 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.

However, in the existing scheme combining BIER technology and MVPN, multicast transmission has a problem of long convergence time and poor timeliness.

Summary of the invention

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.

In a first aspect, 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. Then, 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. Finally, 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.

In the first aspect, the first BIER domain is the BIER domain in which the sender is located, and the second BIER domain, that is, the BIER domain in which the non-transmitter is located, may be referred to as another BIER domain. 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.

It can be seen that, for multicast data sent to other BIER domains, 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. BFIR of other BIER domains.

Then, the multicast data forwarding in the BIER domain follows the existing BIER mechanism forwarding mechanism. Refer to the existing BIER-MVPN scheme described in the IETF draft draft-ietf-bier-mvpn-08. It can be understood that, unlike the existing BIER-MVPN solution, the multicast data forwarding in this application is not segmented, and the BIER header is constructed only on the sender side, and no intermediate device is needed (such as each BIER domain along the way). BFIR, BFER) participate in the generation of BIER headers, enabling more efficient multicast forwarding.

In a first aspect, in some optional embodiments, 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. Here, 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.

In conjunction with the first aspect, in some alternative embodiments, 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. In this way, for other BIER domains, 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.

In a first aspect, in some optional embodiments, 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 in . 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. Here, 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.

Next, how the above BIFT-id, the above-mentioned BitString, the first mapping table, and the second mapping table are determined will be described.

(1) First, the sender can know which BFERs in the BIER domain are interested in the multicast group through multicast information release and feedback. In this application, 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:

1. Multicast information release

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). Here, the BIER identifier is used to indicate that the BGP message carrying the Intra PMSI A-D route is a BIER multicast message.

2. Multicast information feedback

Correspondingly, if the multicast group is interested, 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. . Correspondingly, 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.

In order for the sender to know which BFERs in the BIER domain are interested in the multicast group and know how to forward the multicast data to these BFERs, the Leaf A-D route can carry the following information:

First, 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. The BSL supported by the first BFER and the identifier of the BIER domain to which the first BFER belongs. Specifically, 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. In this way, 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.

In one possible case, a BIER domain is configured with only one sub-domain. For this case, 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.

In one possible case, 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.

Second, 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. In this way, the sending convenience can generate a second mapping table of the sender according to the information, as shown in the following.

It can be seen that 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.

(2) The sender determines the BIFT-id.

Specifically, 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.

It can be seen that, like other parameters in the BIER domain to determine the BIFT-id, 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) can be used to determine the BIFT-id, which enables the sender to generate other BIER domains. A BIER packet that successfully performs BIER routing forwarding.

It should be noted that 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.

(3) The sender determines the BitString.

Specifically, 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.

(4) The sender generates a first mapping table.

Specifically, 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.

In the present application, the first mapping table can be used to construct a BIER header. For the multicast data of a multicast group, the BIER header is constructed only on the sender side, and no intermediate device is involved in the reconstruction of the BIER header.

(5) The sender generates a second mapping table.

For other BIER domains, 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.

For a particular second BIER domain, 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. In this way, for the multicast data sent to the BIER 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. Because BIFT-id can indicate the sub-domain to which the multicast data will be sent. Regarding which sub-domain(s) each of the BFIRs is responsible for forwarding the multicast data, the present application is not limited, and may be referred to actual requirements. For example, the amount of data forwarding carried by each of the multiple next hops can be set from the perspective of load balancing.

For a particular other BIER domain, 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. Here, 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). In the BIER domain where the sender is located, referring to the existing BIER-MVPN scheme, the sender's next hop may be BFR-NBR. In other BIER domains, the sender's next hop may be the BFIR of other BIER domains.

Optionally, 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.

Optionally, the second mapping table may also be a correspondence between BIFT-id and BFR-Prefix. In this way, 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.

For a specific other BIER domain, in the case that the sender has multiple next hops in the BIER domain, 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.

In the present application, 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.

Optionally, 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, 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. Here, the egress port for sending the multicast data to other BIER domains may be referred to as a first port.

In a second aspect, 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, and 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.

In the second aspect, the first BIER domain is the BIER domain in which the non-transmitter is located, and 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.

It can be seen that, for multicast data sent to other BIER domains, 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.

Then, 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.

With reference to the second aspect, in some optional embodiments, 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. Optionally, in one possible case, only one sub-domain is configured for one BIER domain. For this case, 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.

In conjunction with the second aspect, in some optional embodiments, 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. Correspondingly, 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. In this way, 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.

That is to say, 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.

In a third aspect, 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.

In the third aspect, the first BIER domain is the BIER domain in which the non-transmitter is located, and 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.

In conjunction with the third aspect, in some optional embodiments, 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. Correspondingly, 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. In this way, 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.

That is to say, 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.

In conjunction with the third aspect, in some optional embodiments, 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. Optionally, 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. Optionally, in one possible case, only one sub-domain is configured for one BIER domain. For this case, 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.

With reference to the third aspect, in some optional embodiments, the Leaf A-D route carried by the second BGP message may further include a BSL supported by the first BFER. Optionally, 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.

In a fourth aspect, 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.

In a fifth aspect, 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.

In a sixth aspect, 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.

In a seventh aspect, 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.

In an eighth aspect, 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.

In a ninth aspect, 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.

In a tenth aspect, a communication system is provided, the communication system comprising: a first router and a second router. The first router may be the router described in the foregoing fifth aspect, and 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.

Optionally, 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, and the third router may be the router described in the foregoing seventh aspect.

In an eleventh 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.

According to a twelfth aspect, there is provided 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.

DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background art, the drawings to be used in the embodiments of the present application or the background art will be described below.

1 is a schematic diagram of a BIER architecture involved in the present application;

2 is a schematic diagram of a data structure of a BIER header according to the present application;

3 is an exemplary schematic diagram of a topology within a BIER domain;

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;

6 is a schematic diagram of an application scenario of a BIER-MVPN designed according to the present application;

7 is a schematic flowchart of a conventional BIER-MVPN solution;

8 is a schematic diagram of an existing multicast information release and feedback process;

9 is a schematic diagram of a data structure of an extended Intra PMSI A-D route in the present application;

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; FIG.

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;

18 is a schematic diagram of a data structure of a BIFT-id in the present application;

19 is a schematic diagram of a sender receiving BIER information from each BIER domain in the present application;

20 is a schematic diagram of a first mapping table 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.

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.

detailed description

The terms used in the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

Figure 1 illustrates the BIER architecture involved in this application. In the BIER architecture, a router that supports BIER is called a Bit-Forwarding Router (BFR). 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.

As shown in FIG. 1 , 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. Specifically, 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. For some multicast traffic, 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. In fact, for a given data packet, 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). If a particular BFR belongs to multiple subdomains, then the BFR may have a different BFR-id in these multiple subdomains (although this need not be the case). In addition, 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. A BFR prefix for a given BFR is routable in the sub-domain to which it belongs.

When a multicast packet arrives outside the BIER domain at the BFIR, 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. The receiver, each bit in the BitString represents a BFR-id. To indicate the specific BFER that will be added to the multicast group, 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.

The following are the key technical points involved in the multicast forwarding mechanism in the BIER domain: BIFT and BitString.

(1) BIFT

1. Release of BFR-id and BFR-Prefix

In a BIER domain, each BFER publishes its BFR-id to all other BFRs. For example, 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. Similarly, each BFR publishes its BFR-Prefix to all other BFRs.

2.BFR Mr. Bit Index Routing Table (BIRT)

The Bit Index Routing Table (BIRT) 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.

Take the BIER topology shown in Figure 3 as an example. In FIG. 3, 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". Here, if the SI is not larger than the BSL, the SI is equal to 0. The examples are merely illustrative of the application and should not be construed as limiting.

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. -Prefix, the third column indicates BFR-NBR (ie, next hop) on the path where BFR-B arrives at each BFER.

Table 1

3. BFR generates a bit index forwarding table (BIFT) according to BIRT

Assuming that there are several rows in the BIRT with the same SI and BFR-NBR, by performing a logical OR operation on the BitString corresponding to the BFR-id in these rows, the bit mask in the BIFT can be obtained, that is, F- BM.

For example, 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. Among them, F-BM indicates which BFERs are available from each BFR-NBR of BFR-B. It can be seen that the bit mask (F-BM) 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".

Table 2

Once all the BFIRs and transit BFRs in the BIER domain generate their respective BIFTs, the BFIR and transit BFRs in the BIER domain can be multicast forwarded according to the BIER header in the received BIER packet.

(2) BitString

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.

In MVPN, 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. As shown in Figure 4, in a 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. Correspondingly, 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).

For example, as shown in FIG. 5, when the BFIR knows which receivers (BFERs) of a multicast group are, the BFIR can generate the multicast receiver table shown in Table 3. In the multicast group 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, and Joined indicates whether the BFER is added to a multicast group G1.

ReceiverReceiver	Group IDGroup ID	JoinedJoined
BB	G1G1	是Yes
CC	G1G1	是Yes
DD	G1G1	否no

table 3

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".

For the BIER technology, the parts not mentioned in the above can refer to IETF BIER_ARCH, which will not be described here.

In order to become the next generation of widely used multicast protocols, BIER technology needs to provide comprehensive support for MVPN. 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). From the perspective of the entire multicast domain, a BIER domain is equivalent to an autonomous system (AS). The BFIR and BFER between the BIER domains may also be referred to as an autonomous system border router (ASBR).

Taking the BIER-MVPN application scenario shown in Figure 6 as an example, Figure 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:

(1) Phase 1 (S101): BFIR and BFR in the BIER domain generate their respective BIFT

According to the key technology point "BIFT" introduced in the above content, in a BIER domain, 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.

In addition, BFIR can also generate a correspondence table of BFR-Prefix and BFR-id for the BFER in its BIER domain.

Since BFIR and BFR in the BIER domain generate their respective BIFTs, after receiving the BIER packet, BFIR and BFR can perform multicast forwarding according to BIFT-id and Bitstring in the BIER header. Among them, 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.

(2) Phase 2 (S102-S107): Multicast information release and feedback

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:

S102. The multicast information in the BIER domain 100 is released.

As shown in FIG. 8, 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.

In the existing BIER-MVPN solution, as shown in FIG. 9, 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.

S103, multicast feedback in the BIER domain 100.

As shown in Figure 8, 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. In particular, after 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. Here, the BFER that is interested in the multicast group is the receiver of the multicast group.

In this way, 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.

S104. The multicast information is released between the BIER domains.

As shown in Figure 8, after 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.

S105. Multicast information feedback between BIER domains.

As shown in Figure 8, 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. In this way, 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. Note that, unlike the BIER domain forwarding, 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.

S106, multicast distribution in the BIER domain 200.

As shown in FIG. 8, 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.

S107, multicast feedback in the BIER domain 200.

As shown in Figure 8, 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. Here, the BFER that is interested in the multicast group is the receiver of the multicast group.

In this way, 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. In addition, by S101, 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.

Comprehensive S102-S107, multicast information release and feedback are summarized as follows:

1. Multicast information release and feedback in the BIER domain (S102-S103, S106-S107)

a. Through the intra-domain BGP message, the BFIR sends an Intra PMSI A-D route (adding a BIER identifier) to the BFER to issue multicast information;

b. Through the intra-domain BGP message, the BFER that is interested in the multicast group feeds the Leaf A-D route (the prefix carrying the BFER) to the BFIR. In this way, 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. . In addition, through step 1, 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.

2. Multicast information release and feedback between BIER domains (S104-S105)

a. Through the inter-domain BGP message, 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). To publish multicast;

b. 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. In this way, 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.

It can be seen that in the existing BIER-MVPN scheme, multicast information distribution and feedback are segmented. For the same multicast information, different BIER domains need to generate BGP messages to advertise the multicast information to the BFER of each domain. The convergence time of the multicast advertisement & feedback is long and the effectiveness is poor.

(3) Multicast data forwarding (step 8-10): intra-domain forwarding and inter-domain forwarding

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. For example, as shown in FIG. 10, when the sender has multicast data to be sent, 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. 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. Then, 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. Then, 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. Finally, the receiver PE removes the MPLS header and forwards the multicast data to the user side device.

Different from the segmentation cross-domain multicast transmission mode in the MVPN framework, the existing BIER-MVPN scheme uses the BIER forwarding mechanism to forward multicast data in the BIER domain. Expand below:

S108, multicast data forwarding in the BIER domain 100.

Specifically, when a certain multicast data arrives, the sender searches for a corresponding BitString in the BIER domain 100 of the multicast data, and the BitString has been determined in S103. In addition, 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. Then, 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. Thus, 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.

S109. Forwarding multicast data between BIER domains.

Specifically, 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.

S110. Forwarding multicast data in the BIER domain 200.

Specifically, 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.

Finally, 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.

Based on S108-S110, the forwarding of multicast data is summarized as follows:

1. Multicast data forwarding in the BIER domain (S108, S110)

a. When the multicast data arrives, 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.

b. 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.

2. Multicast data forwarding between BIER domains (S109)

a. When receiving a BIER packet, 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.

b. The BFER sends the tagged multicast data to the BFIR of the other domain indicated by the BFR-Prefix. In this way, after receiving the tagged multicast data, 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. Finally, the BFR in other domains performs multicast forwarding according to the BIER forwarding mechanism.

It can be seen that in the existing BIER-MVPN scheme, multicast data forwarding is segmented. The multicast data from the sender to the receiver PE in other BIER domains requires multiple devices (such as BFIR and BFER in each BIER domain along the way) to participate in the generation of the BIER header, which is inefficient and time-sensitive.

For the problems existing in the existing BIER-MVPN solution, 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.

(A) The main inventive principle of 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.

(B) 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. Different from the existing BIER-MVPN solution, 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.

In phase 1, in order to implement edge BFR in different BIER domains, 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. Establish a BGP connection through BGP open messages. It can be understood that once a BGP connection is established between edge BFRs of different BIER domains, BGP messages can be directly exchanged, and multicast information can be distributed and fed back across domains without using the segmentation in the existing BIER-MVPN scheme. Multicast information release and feedback.

Here, 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.

The TCP connection is constructed with respect to the underlying tag mapping, which is exemplified below. For example, as shown in FIG. 11, a TCP connection between edge BFRs in different BIER domains can be constructed by the following procedure:

1. 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). 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.

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. For example, the data sent by ASBR1 to 2.2.2.2 (that is, the BFER in BIER domain 200) needs to be labeled "222" and sent to ASBR2.

3. 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 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". Correspondingly, after ASBR1 receives the data with the target of 2.2.2.2 and is tagged with "22", it replaces the tag "22" with the tag "222" and sends the data of the tag "222" to ASBR2. ASBR2 then 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.

Through the above-mentioned underlying label mapping, 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. In this way, as shown in FIG. 12, 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.

Based on the architecture shown in FIG. 12, as shown in FIG. 13, the edge BFRs in different BIER domains can directly exchange multicast information based on the BGP protocol. Specifically, 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.

Based on the above-mentioned main inventive principle and the application scenario shown in FIG. 6, the multicast data transmission method provided by the present application is described in detail below. As shown in FIG. 14, the multicast data transmission method provided by the present application may include:

(1) Phase 1 (S201): BFIR and BFR in the BIER domain generate their respective BIFT

It can be seen from the key technology point "BIFT" introduced in the foregoing that in a BIER domain, both BFIR and BFR can generate a BIFT reaching each BFER. In addition, BFIR can also generate a correspondence table of BFR-Prefix and BFR-id for the BFER in its BIER domain.

(2) Phase 2 (S202-S203): Multicast information release and feedback

S202. The multicast information is released.

Specifically, as shown in FIG. 14, 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) and BGP peers in BIER domain 300 (such as BFIR-E, BFER-G).

That is to say, the sender forms a BGP peer with BFIR and BFER in other BIER domains. Here, 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). Correspondingly, 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.

As shown in Figure 15, 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). Here, the BIER identifier is used to indicate that the BGP message carrying the Intra PMSI A-D route is a BIER multicast message.

S203. Multicast information feedback.

Specifically, as shown in FIG. 14, 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. For details, refer to S103 in the existing BIER-MVPN solution. 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.

That is to say, BFIR and BFER in other BIER domains can directly send BGP messages carrying Leaf A-D routes to the sender through BGP connections. Correspondingly, 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.

In order to let the sender know which BFERs in the BIER domain are interested in the multicast group, and know how to forward the multicast data corresponding to the multicast group to these BFERs, the Leaf A-D route can carry the following information:

For example, as shown in FIG. 16, 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. The supported BSL and the identity of the BIER domain to which the BFER belongs. Specifically, 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. In this way, 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.

In one possible case, a BIER domain is configured with only one sub-domain. For this case, 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.

In one possible case, 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.

Second, as shown in FIG. 17, 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. In this way, Sender can generate a second mapping table of sender according to this information, as shown in the following.

As shown in Figure S202-S203, in this application, 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.

(3) Phase 3 (S204-S206): Generating a correlation mapping table for multicast forwarding

S204, determining a BIFT-id.

Specifically, as shown in FIG. 18, 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. In a special case where only one sub-domain is configured in a BIER domain, the sub-domain is not mandatory.

As shown in FIG. 19, 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. Here, the corresponding multicast group refers to the multicast group indicated by the multicast information fed back by the Leaf A-D route.

Specifically, the bit sequences of the sub-domain, the BSL, and the SI may be sequentially spliced together to form a BIFT-id. Assume that the bit sequence of the subdomain is "011", the bit sequence of the BSL is "0000100", and the bit sequence of the SI is "0001100100". Then, 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.

It can be seen that 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. 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) can be used to determine the BIFT-id, which enables the sender to generate other BIER domains. A BIER packet that successfully performs BIER routing forwarding.

A BIER domain can include at least one sub-domain. In this regard, 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. This means that for multicast data addressed to the BIER domain, the sender needs to construct a BIER header for each of the at least one sub-domain, and then encapsulate the BIER packet with the at least one sub-domain, respectively, and the different sub-domains correspond to Different BIER heads.

In this application, 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.

S205. Generate a first mapping table.

Specifically, 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. As shown in FIG. 20, 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.

In the first mapping table, 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. Here, the recipient refers to a BFER that is of interest to the multicast group in other BIER domains.

In the present application, the first mapping table can be used to construct a BIER header. For a multicast group, 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.

S206. Generate a second mapping table of the sender.

In the present application, for other BIER domains, 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. In this way, 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. .

For a particular other BIER domain, 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. In this way, for the multicast data sent to the BIER 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. Because BIFT-id can indicate the sub-domain to which the multicast data will be sent. Regarding which sub-domain(s) each of the BFIRs is responsible for forwarding the multicast data, the present application is not limited, and may be referred to actual requirements. For example, the amount of data forwarding carried by each of the multiple next hops can be set from the perspective of load balancing.

In the present application, 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. As shown in FIG. 21, 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). In the BIER domain where the sender is located, referring to the existing BIER-MVPN scheme, the sender's next hop may be BFR-NBR. In other BIER domains, 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.

In this application, 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. For example, 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 examples are only used to explain the present application, and may be specifically referred to in the following, and will not be described here.

Optionally, 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.

Optionally, 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.

(4) Phase 4: Multicast data forwarding (S207-S211): intra-domain forwarding and inter-domain forwarding

S207. Forwarding multicast data in the BIER domain 100.

Specifically, when a certain multicast data arrives, 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.

Then, 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. Thus, 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.

Correspondingly, 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.

S208. The sender (in the BIER domain 100) unicasts the multicast data to the BFIR in the BIER domain 200.

Specifically, when a certain multicast data arrives, 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.

Then, 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.

Correspondingly, the BFIR in the BIER domain 200 can receive the tagged BIER packet, and can remove the tag to obtain the BIER packet.

S209. 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.

Correspondingly, 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.

Based on S207-S211, the forwarding of multicast data is summarized as follows:

1. 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.

2. 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.

It can be seen that, unlike the existing BIER-MVPN solution, 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.

In this application, 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 specific implementation of the multicast data forwarding method provided by the present application is illustrated by way of example below.

In the example shown in FIG. 23, it is assumed that 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", and the label corresponding to the BFR-Prefix of the BFER-J is "300". As shown in Figure 23, when the multicast data corresponding to the multicast group (S, G) arrives, the forwarding process is as follows:

1. The sender copies the multicast data into 3 copies.

2. 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).

3. 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.

4. 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. When 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.

5. 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. After the BFIR-H in the BIER domain 300 receives the BFIR-H in the BIER domain 300, 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. 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.

As can be seen from the example shown in FIG. 23, unlike the existing BIER-MVPN scheme, the multicast data of the receivers sent to other BIER domains (such as the BIER domain 200) no longer need to pass through the BIER domain 100 and the BIER domain. In the layer forwarding of BFR in 200, the intermediate device (such as BFIR in BIER domain 200) no longer participates in the generation of BIER header, which can achieve more efficient multicast forwarding.

Expansion plan

In some optional embodiments, 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:

(1) Phase 1 (S301): BFIR and BFR in the BIER domain generate their respective BIFT

For details, refer to S201 in the embodiment of FIG. 14 , and details are not described herein again.

(2) Phase 2 (S302-S304): Multicast information release and feedback

Different from the multicast information distribution and feedback (S202-S203) in the embodiment of FIG. 14, 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.

To narrow the scope, 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.

(3) Phase 3 (S305-S307): Generate a correlation mapping table for multicast forwarding

For details, refer to S204-S206 in the embodiment of FIG. 14 , and details are not described herein again.

(4) Phase 4: Multicast data forwarding (S308-S312): intra-domain forwarding and inter-domain forwarding

For details, refer to S307-S311 in the embodiment of FIG. 14 , and details are not described herein again.

Referring to Figure 25, there is shown a router 100 provided by some embodiments of the present application. 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. As shown in FIG. 25, 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. In particular, 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. Without being limited to a wired communication interface, in some possible embodiments, communication interface 105 may also include a wireless communication interface, such as a wireless local area network (WLAN) interface or the like.

Memory 103 is coupled to processor 101 for storing various software programs and/or sets of instructions. In particular, 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.

In some embodiments of the present application, 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. For the implementation of the multicast data transmission method provided by one or more embodiments of the present application on the sender side, please refer to the foregoing method embodiment.

In some embodiments of the present application, 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. For example, 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. For 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.

In some embodiments of the present application, 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. Specifically, 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. . For the implementation of 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.

It is to be understood that 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.

Referring to Figure 26, Figure 26 illustrates another communication system and associated apparatus provided by the present application. 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, and the second router 500 may be the receiver BFER in other BIER domains in the foregoing method embodiments. Optionally, 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.

As shown in FIG. 26, 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 BIFT-id and bit string corresponding to the multicast data in at least one BIER domain.

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.

Here, 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.

It can be understood that, unlike the existing BIER-MVPN solution, 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.

In some optional embodiments, 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 prefix of the logical next hop of the three routers 300 in other BIER domains. 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.

In this way, for other BIER domains, 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. .

In some optional embodiments, 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. Specifically, 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. Then, 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.

In the present application, 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). Here, 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.

In order for the third router 300 to know which BFERs in the BIER domain are interested in the multicast group and know how to forward the multicast data to these BFERs, the Leaf A-D route can carry the following information:

For example, 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. The BSL supported by the second router 500 and the identifier of the BIER domain to which the second router 500 belongs. Specifically, 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. In this way, 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.

In one possible case, a BIER domain is configured with only one sub-domain. For this case, 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.

In one possible case, 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.

Second, 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. In this way, the third router 300 can generate a second mapping table based on the information.

For a specific implementation of the respective functional units of the third router 300, reference may be made to the method embodiment corresponding to FIG. 14 or FIG. 24, and details are not described herein again.

As shown in FIG. 26, 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.

In some optional embodiments, 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. Optionally, in one possible case, only one sub-domain is configured for one BIER domain. For this case, 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.

In some optional embodiments, 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. Correspondingly, 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. In this way, 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.

For a specific implementation of the various functional units of the first router 400, reference may be made to the method embodiment corresponding to FIG. 14 or FIG. 24, and details are not described herein again.

As shown in FIG. 26, 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.

In some optional embodiments, 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. Correspondingly, 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.

In some optional embodiments, 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. Optionally, 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. Optionally, in one possible case, only one sub-domain is configured for one BIER domain. For this case, 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.

In some optional embodiments, the Leaf A-D route carried by the second BGP message may further include a BSL supported by the second router 500. Optionally, 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.

For a specific implementation of the respective functional units of the second router 500, reference may be made to the method embodiment corresponding to FIG. 14 or FIG. 24, and details are not described herein again.

In summary, implementing the technical solution provided by the present application can significantly shorten the convergence time of multicast transmission and improve the timeliness of multicast transmission.

One of ordinary skill in the art can understand all or part of the process of implementing the above embodiments, which can be completed by a computer program to instruct related hardware, 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.

Claims

A multicast data transmission method, comprising:

The first bit forwarding explicitly replicates the first forwarding ingress router BFIR in the BIER domain to determine the identity BIFT-id of the corresponding bit string and bit index forwarding table of the multicast data in the second BIER domain; the BIFT-id is at least The bit identifier ID of the bit forwarding router identifier BFR-id to which the first bit forwarding router BFER belongs and the bit string length supported by the first BFER are determined; the bit string is at least the BFR-id of the first BFER Determining; 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, the label is a label corresponding to the prefix of the second BFIR in the second BIER domain, and sends the label after the label is sent to the second BFIR. Said BIER data package.
The method of claim 1 wherein said first bit index explicitly replicates a first bit forwarding ingress router BFIR in the BIER domain to determine a corresponding bit string and bit of the multicast data in the second BIER domain. The identifier BIFT-id of the index forwarding table includes:

Determining, by the first BFIR, a bit string and a BIFT-id corresponding to the multicast data in the second BIER domain from a first mapping table; the first mapping table includes the multicast data in at least one The corresponding BIFT-id and bit string in the BIER domain.
The method of claim 1 or 2, wherein before the first BFIR tags the BIER packet, the method further comprises:

Determining, by the first BFIR, a prefix of a logical next hop of the first BFIR in the second BIER domain; a logical next hop of the first BFIR in the second BIER domain is the Two BFIR.
The method according to claim 3, wherein the first BFIR determines a prefix of the logical next hop of the first BFIR in the second BIER domain, and specifically includes:

Determining, by the first BFIR, a prefix of a logical next hop of the first BFIR in the second BIER domain from a second mapping table; the first BFIR being logical under the second BIER domain The prefix of one hop is a prefix corresponding to the corresponding BIFT-id of the multicast data in the second BIER domain; the second mapping table includes: the multicast data respectively corresponding to at least one BIER domain BIFT-id, a prefix of the logical next hop of the first BFIR in the at least one BIER domain.
The method of any of claims 1-4, wherein the method further comprises:

The first BFIR sends a first BGP message to the BFIR and the BFER in the second BIER domain through a BGP connection, and the internal P multicast service interface carried in the first BGP message automatically discovers the route Intra PMSI AD route includes BIER Identifying an identifier of the multicast group corresponding to the multicast data;

The first BFIR receives the second BGP message sent by the second BFIR through a BGP connection, and the leaf node automatically discovers that the leaf AD route includes the prefix of the second BFIR and the second The identity of the BIER domain;

The first BFIR receives the third BGP message sent by the first BFER through the BGP connection, and the Leaf AD route carried by the third BGP message includes the BFR-id of the first BFER and the BFR of the first BFER. The ID to which the -id belongs and the identifier of the second BIER domain.
The method according to claim 5, wherein the Leaf A-D route carried by the third BGP message further includes a sub-domain sub-domain to which the first BFER belongs.
The method according to claim 5 or 6, wherein the Leaf A-D route carried by the third BGP message further includes a bit string length supported by the first BFER.
The method according to any one of claims 1 to 7, wherein the corresponding BIFT-id of the multicast data in the second BIER domain is further determined by the sub-domain to which the first BFER belongs .
A multicast data transmission method, comprising:

The first bit forwarding explicit copying of the first forwarding ingress router BFIR in the BIER domain receives the tagged BIER packet sent by the second BFIR in the second BIER domain; the tag is a prefix corresponding to the first BFIR The BIER packet is obtained by the second BFIR encapsulating multicast data, and the BIER header of the BIER packet includes a bit string and a bit index of the multicast data in the first BIER domain. The published identifier BIFT-id; the BIFT-id is determined by at least a subset identifier SI to which the bit forwarding router identifier BFR-id of the first forwarding egress router BFER belongs and a bit string length supported by the first BFER; The string is determined by at least a BFR-id of the first BFER; the first BFER is a BFER for receiving the multicast data in the first BIER domain;

Determining, by the first BFIR, the label to obtain the BIER data packet, and obtaining a BIFT-id and a bit string from a BIER header of the BIER data packet;

The first BFIR forwards the BIER packet to the first BFER according to the BIFT indicated by the BIFT-id and the bit string.
The method of claim 9 wherein the method further comprises:

The first BFIR receives the first BGP message sent by the second BFIR through a BGP connection, and the internal P multicast service interface automatically discovers the route Intra PMSI AD route included in the first BGP message, including the BIER identifier, the group The identifier of the multicast group corresponding to the broadcast data;

In response to the first BGP message, the first BFIR sends a second BGP message to the second BFIR through a BGP connection, and the leaf node automatically discovers a route Leaf AD route carried by the second BGP message, including the first BFIR The prefix and the identifier of the first BIER domain.
The method according to claim 9 or 10, wherein the corresponding BIFT-id of the multicast data in the first BIER domain is further determined by a sub-domain sub-domain to which the first BFER belongs.
A multicast data transmission method, comprising:

The first BGP message sent by the second forwarding forwarding router BFIR in the second BIER domain is received by the first forwarding egress router BFER in the BIER domain through the border gateway protocol BGP connection, the first BGP message. The internal P multicast service interface carried in the automatic discovery of the Intra PMSI AD route includes the BIER identifier and the identifier of the multicast group corresponding to the multicast data.

The first BFER determines to receive the multicast data according to the identifier of the multicast group corresponding to the multicast data, and sends a second BGP message to the second BFIR by using a BGP connection, where the second BGP message is carried. The leaf node automatic discovery route Leaf AD route includes a BFR-id of the first BFER, an SI to which the BFR-id of the first BFER belongs, and an identifier of the first BIER domain;

The first BFER receives a BIER packet sent by the first BFIR in the first BIER domain; the BIER packet is obtained by encapsulating the multicast data by the second BFIR, and the BIER header of the BIER packet includes An identifier BIFT-id of the corresponding bit string and bit index forwarding table of the multicast data in the first BIER domain; the BIFT-id is at least a sub-forward of the first BFER bit identifier router identifier BFR-id a set identifier SI and a bit string length supported by the first BFER; the bit string is determined at least by a BFR-id of the first BFER;

The first BFER decapsulates the BIER data packet to obtain the multicast data, and sends the multicast data to a user side device.
The method according to claim 12, wherein the Leaf A-D route carried by the second BGP message further includes a sub-domain sub-domain to which the first BFER belongs.
The method according to any one of claims 12 to 13, wherein the Leaf A-D route carried by the second BGP message further includes a bit string length supported by the first BFER.
The method according to any one of claims 12 to 14, wherein the corresponding BIFT-id of the multicast data in the first BIER domain is further determined by the sub-domain to which the first BFER belongs .
A router that is in a first-bit index explicit replication BIER domain, and is characterized by:

a processing unit, configured to determine an identifier BIFT-id of the corresponding bit string and the bit index forwarding table of the multicast data in the second BIER domain; the BIFT-id is identified by at least a bit forwarding router identifier of the first forwarding egress router BFER a subset identifier SI to which the BFR-id belongs and a bit string length supported by the first BFER; the bit string is determined by at least a BFR-id of the first BFER; the first BFER is the second BIER a BFER for receiving the multicast data in the domain;

The processing unit is further configured to encapsulate the multicast data into a BIER data packet, where a BIER header of the BIER data packet includes a BIFT-id and a bit string corresponding to the multicast data in the second BIER domain. ;

The processing unit is further configured to: label, by the first BFIR, the BIER data packet, where the label is a label corresponding to a prefix of a second BFIR in the second BIER domain;

a communication unit, configured to send, to the second BFIR, the BIER data packet after the label is marked.
The router according to claim 16, wherein the processing unit is configured to determine, from the first mapping table, a bit string and a BIFT-id corresponding to the multicast data in the second BIER domain. The first mapping table includes a BIFT-id and a bit string respectively corresponding to the multicast data in at least one BIER domain.
The router according to claim 16 or 17, wherein the processing unit is further configured to determine a prefix of a logical next hop of the first BFIR in the second BIER domain; The logical next hop of the BFIR in the second BIER domain is the second BFIR.
The router according to claim 18, wherein the processing unit is specifically configured to determine, from a second mapping table, a prefix of a logical next hop of the first BFIR in the second BIER domain; The prefix of the logical next hop of the first BFIR in the second BIER domain is a prefix corresponding to the corresponding BIFT-id of the multicast data in the second BIER domain; the second mapping table includes The BIFT-id corresponding to the multicast data in the at least one BIER domain and the logical next hop prefix of the first BFIR in the at least one BIER domain.
The router according to any one of claims 16 to 19, wherein the communication unit is further configured to send a first BGP message to the BFIR and the BFER in the second BIER domain by using a BGP connection, where The internal P multicast service interface that is carried in the first BGP message automatically discovers the route of the Intra PMSI AD route, including the BIER identifier and the identifier of the multicast group corresponding to the multicast data.

The communication unit is further configured to receive, by using a BGP connection, a second BGP message that is sent by the second BFIR, where the leaf node automatically discovers that the leaf AD route includes the prefix and the second BFIR The identifier of the second BIER domain;

The communication unit is further configured to receive, by using a BGP connection, a third BGP message that is sent by the first BFER, where the Leaf AD route that is carried by the third BGP message includes a BFR-id of the first BFER, the first The SI to which the BFR-id of the BFER belongs, and the identifier of the second BIER domain.
The router according to claim 20, wherein the Leaf A-D route carried by the third BGP message further includes a sub-domain sub-domain to which the first BFER belongs.
The router according to claim 20 or 21, wherein the Leaf A-D route carried by the third BGP message further includes a bit string length supported by the first BFER.
The router according to any one of claims 16 to 22, wherein the corresponding BIFT-id of the multicast data in the second BIER domain is further determined by the sub-domain to which the first BFER belongs. .
A router that is in a first-bit index explicit replication BIER domain, and is characterized by:

a communication unit, configured to receive the labeled BIER data packet sent by the second forwarding ingress router BFIR in the second BIER domain; the label is a label corresponding to the prefix of the first BFIR; The second BFIR encapsulates the multicast data, and the BIER header of the BIER packet includes an identifier BIFT-id of the corresponding bit string and bit index forwarding table of the multicast data in the first BIER domain; The BIFT-id is determined by at least a subset identifier SI to which the bit forwarding router identifier BFR-id of the first forwarding egress router BFER belongs and a bit string length supported by the first BFER; the bit string is at least by the first BFER Determining, by the BFR-id, that the first BFER is a BFER for receiving the multicast data in the first BIER domain;

a processing unit, 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 is further configured to forward the BIER data packet to the first BFER according to the BIFT indicated by the BIFT-id and the bit string.
The router according to claim 24, wherein the communication unit is further configured to receive, by using a BGP connection, a first BGP message sent by the second BFIR, and an internal P multicast carried in the first BGP message. The service interface automatically discovers the route Intra PMSI AD route, including the BIER identifier, and the identifier of the multicast group corresponding to the multicast data.

The communication unit is further configured to send, by using a BGP connection, a second BGP message to the second BFIR by using a BGP connection, where the leaf node automatically discovers the route Leaf AD route includes the The prefix of the first BFIR and the identifier of the first BIER domain.
The router according to claim 24 or 25, wherein the corresponding BIFT-id of the multicast data in the first BIER domain is further determined by a sub-domain sub-domain to which the first BFER belongs.
A router that is in a first-bit index explicit replication BIER domain, and is characterized by:

The communication unit is configured to receive the first BGP message sent by the second forwarding ingress router BFIR in the second BIER domain by using the border gateway protocol BGP connection, and the internal P multicast service interface carried in the first BGP message automatically discovers the route Intra The PMSI AD route includes a BIER identifier and an identifier of the multicast group corresponding to the multicast data.

The communication unit is further configured to send a second BGP message to the second BFIR by using a BGP connection, where the leaf node automatically discovers that the leaf AD route includes the BFR-id of the first BFER, An SI to which the BFR-id of the first BFER belongs, and an identifier of the first BIER domain;

The communication unit is further configured to receive a BIER data packet sent by the first BFIR in the first BIER domain; the BIER data packet is obtained by encapsulating the multicast data by the second BFIR, and the BIER of the BIER data packet The header includes an identifier BIFT-id of the corresponding bit string and bit index forwarding table of the multicast data in the first BIER domain; the BIFT-id is at least by the first BFER bit forwarding router BFR-id The associated subset identifier SI and the bit string length supported by the first BFER are determined; the bit string is determined by at least a BFR-id of the first BFER; and the first BFER is used in the first BIER domain Receiving a BFER of the multicast data;

a processing unit, configured to decapsulate the BIER data packet to obtain the multicast data;

The communication unit is further configured to send the multicast data to the user side device.
The router according to claim 27, wherein the Leaf A-D route carried by the second BGP message further includes a sub-domain sub-domain to which the first BFER belongs.
The router according to any one of claims 27 to 28, wherein the Leaf A-D route carried by the second BGP message further includes a bit string length supported by the first BFER.
The router according to any one of claims 27 to 29, wherein the corresponding BIFT-id of the multicast data in the first BIER domain is further determined by the sub-domain to which the first BFER belongs. .
A communication system, comprising: a first router and a second router, wherein:

The first router is the router according to any one of claims 24-26; the second router is the router according to any one of claims 27-30.
The communication system of claim 31, further comprising: a third router, said third router being the router of any one of claims 16-23.
A computer readable storage medium, comprising: the computer readable storage medium having instructions stored thereon, the computer executing any one of claims 1-15 when the instructions are run on a computer The method described.
A computer program product, comprising: when the computer program product is run on a computer, the computer performs the method of any one of claims 1-15.