WO2024016869A1

WO2024016869A1 - Multicast configuration method and apparatus

Info

Publication number: WO2024016869A1
Application number: PCT/CN2023/098480
Authority: WO
Inventors: 谷丁云; 王恒; 段方红; 谢经荣; 盛成; 庞东磊
Original assignee: 华为技术有限公司
Priority date: 2022-07-21
Filing date: 2023-06-06
Publication date: 2024-01-25

Abstract

The present application relates to the field of data communications, and provides a multicast configuration method and apparatus. In the present application, a BFR prefix and parameters for identifying an SD-WAN tunnel are advertised in a VPN, so that the presence of an association relationship between a BIER and an SD-WAN can be indicated, that is, it is necessary to pass through the SD-WAN tunnel to reach a certain BFR prefix, thus facilitating forwarding a data packet in the SD-WAN on the basis of the BIER. In this way, an intermediate node in the SD-WAN can replicate and forward the packet according to a set situation of a bit string in the packet, without sensing the status of a multicast group, or establishing a multicast distribution tree for each multicast data stream. Thus, resources occupied by forwarding multicast streams in an SD-WAN scenario are saved.

Description

A multicast configuration method and device

This application claims priority to the Chinese patent application with application number 202211512828.6 and the invention title "A multicast configuration method and device" submitted on November 28, 2022, as well as the application number submitted on July 21, 2022 It is the priority of the Chinese patent application 202210865496.3 with the invention title "A method and device for configuring multicast". The entire contents of the aforementioned patent applications are incorporated by reference into this application.

Technical field

The present application relates to the field of data communications, and in particular to a multicast configuration method and device.

Background technique

Software-defined wide area network (SD-WAN) is a technology that enables data communication across wide area networks between different sites.

When multicast services are currently deployed in SD-WAN, the PIM protocol is usually deployed on the WAN interface of each network device in each site in SD-WAN. Each network device first transmits PIM control messages in the WAN based on the protocol independent multicast (PIM) protocol. Each network device establishes a multicast distribution tree for each multicast flow based on the PIM protocol, saves the status of the multicast flow, and forwards the multicast flow based on the multicast distribution tree and the status of the multicast flow. When a new multicast receiver joins, the network device delivers the join message hop by hop to the network device connected to the multicast source.

When using the above method to deploy multicast services in an SD-WAN scenario, the network device as an intermediate node needs to establish a multicast distribution tree and save the status of the multicast flow, resulting in excessive resource usage.

Contents of the invention

This application provides a multicast configuration method and device, which can save resources occupied by forwarding multicast flows in SD-WAN scenarios. The technical solution is as follows.

In a first aspect, a multicast configuration method is provided, including: a first network device in a virtual private network VPN obtains a first parameter set, the first parameter set includes the bit forwarding router prefix BFR prefix of the first network device and Parameters used to identify the software-defined wide area network SD-WAN tunnel, the first network device is the endpoint of the SD-WAN tunnel; the first network device sends the first parameter set within the VPN.

In the method provided in the first aspect above, the forwarding device can indicate the association between BIER and SD-WAN by advertising the BFR prefix and the parameters used to identify the SD-WAN tunnel in the VPN, that is, if it needs to reach a certain BFR prefix must go through the SD-WAN tunnel, so it helps forward data packets based on BIER in SD-WAN, so that the intermediate node in the SD-WAN network can implement reporting based on the bit string setting in the packet. Copy and forward messages without the need to sense the status of the multicast group or build a multicast distribution tree for each multicast data flow, thus saving the resources occupied by forwarding multicast flows in SD-WAN scenarios.

In some embodiments, the first parameter set further includes a BIER forwarding router identifier BFR-ID of the first network device.

In some implementations, the BFR prefix of the first network device is the private Internet Protocol IP address of the first network device in the VPN.

By using the private IP address in the VPN as the BFR prefix, only devices with routes that can reach the private IP address will receive the first parameter set, thereby limiting the sending range of the parameter set to the VPN.

In some embodiments, the first parameter set also includes the bit string length BSL of the first network device, the maximum set identifier max-SI of the first network device, and the ID of the BIER subdomain where the first network device is located. , one or more of the bit index forwarding table identifier BIFT-ID of the first network device and the identifier of the VPN.

In some embodiments, the parameters used to identify the SD-WAN tunnel include a first tunnel type and first information. The first tunnel type is used to identify the type of tunnel as an SD-WAN tunnel. The first information is used to determine The SD-WAN tunnel.

In some implementations, the first information includes at least one of the identity of the site where the first network device is located or the client equipment identification (CPE ID) of the first network device.

In some implementations, the first network device sends the first parameter set within the VPN, including:

The first network device sends the first parameter set to a second network device in the VPN, the second network device being the other endpoint of the SD-WAN tunnel; or,

The first network device sends the first parameter set to the route reflector RR, so that the RR reflects the first parameter set to the second network device in the VPN, and the second network device is the node of the SD-WAN tunnel. Another endpoint.

In some implementations, the first network device sends the first parameter set within the VPN, including: the first network device sends a first advertisement message within the VPN, and the first advertisement message includes a first address The family identifier and the first parameter set, the first address family identifier is used to identify the Border Gateway Protocol Ethernet Virtual Private Network BGP EVPN or the Border Gateway Protocol Virtual Private Network bit-based explicit replication BGP VPN BIER.

In some implementations, the method further includes: the first network device obtains a second parameter set, the second parameter set includes multicast source group information, the BFR prefix of the first network device and a second tunnel type, the The second tunnel type is used to identify the tunnel between the first network device and the second network device in the VPN as a VPN BIER tunnel;

The first network device sends the second parameter set to the second network device.

In some embodiments, the second parameter set also includes the bit forwarding router BFR-ID of the first network device, the identity of the VPN, the identity of the site where the second network device is located, and the CPE of the second network device. One or more of the IDs.

In some implementations, the first network device sends the second parameter set to the second network device, including: the first network device sends a second notification message to the second network device, and the second notification message Including a second address family identifier and the second parameter set, the second address family identifier is used to identify the next generation multicast virtual private network NG MVPN or BGP EVPN.

In some embodiments, the second advertisement message includes a multicast provider service interface tunnel attribute PTA attribute, the PTA attribute includes an MPLS label MPLS label field, and the MPLS label field includes an identification of the VPN.

In some implementations, before the first network device obtains the second parameter set, the method further includes: the first network device receiving a join message from the multicast receiver in the VPN, the join message including the multicast source group information; or, the first network device receives a leave message from the multicast receiver in the VPN, where the leave message includes the multicast source group information.

The second aspect provides a method for processing multicast packets, including:

The first network device in the virtual private network VPN receives the first multicast data message; the first network device obtains the second multicast data message based on the first multicast data message and the first parameter set. A parameter set includes the second The bit forwarding router prefix BFR prefix of the network device and the parameters used to identify the software-defined wide area network SD-WAN tunnel. The second network device is the endpoint of the SD-WAN tunnel. The second multicast data message includes the first message. header, a second packet header and a payload of the first multicast data packet. The first packet header includes the IP address of the second network device obtained based on the parameter used to identify the SD-WAN tunnel. The third The second message header includes a bit-based explicit copy BIER parameter obtained based on the BFR prefix of the second network device; the first network device sends the second multicast data to the second network device through the SD-WAN tunnel. message.

Through the method provided in the second aspect, the message forwarding method that combines SD-WAN and BIER multicast is realized, so that the multicast data encapsulated by BIER can be forwarded across the transmission network, and the intermediate nodes in the SD-WAN network can forward the message according to the content of the message. The setting status of the bit string enables the copy and forwarding of messages without the need to sense the status of the multicast group and the need to build a multicast distribution tree for each multicast data flow, thus saving the time of forwarding multicast in the SD-WAN scenario. The resources occupied by the stream.

In some embodiments, the first parameter set further includes: the BIER forwarding router identifier BFR-ID of the second network device, the bit string length BSL of the second network device, and the maximum set identifier of the second network device. One or more of the max-SI, the ID of the BIER subdomain where the second network device is located, the bit index forwarding table identifier BIFT-ID of the second network device, and the identifier of the VPN.

In some implementations, the BIER parameter includes a bitstring corresponding to the BFR prefix of the second network device, a BIER-MPLS label corresponding to the BFR prefix of the second network device, and a BFR prefix corresponding to the second network device. One or more of the corresponding Internet Protocol version 6 IPv6 addresses.

In some embodiments, the parameters used to identify the SD-WAN tunnel include a tunnel type and information used to determine the SD-WAN tunnel. The tunnel type is used to identify the type of the tunnel as an SD-WAN tunnel.

In some embodiments, the information used to determine the SD-WAN tunnel includes at least one of the identity of the site where the second network device is located or the CPE ID of the second network device.

In some implementations, the first message header includes a protocol type field, and the protocol type field is used to identify the second message header carrying the BIER parameter.

In some implementations, the first packet header also includes the ID of the VPN.

In a third aspect, a multicast configuration device is provided. The first network device located in the virtual private network (VPN) includes: a processing unit for obtaining a first parameter set, the first parameter set including the first network device. The bit forwarding router prefix BFR prefix and the parameters used to identify the software-defined wide area network SD-WAN tunnel, the first network device is the endpoint of the SD-WAN tunnel; the sending unit is used to send the first parameter set within the VPN .

In some implementations, the sending unit is configured to send the first parameter set to a second network device in the VPN, which is another endpoint of the SD-WAN tunnel; or, to a route reflector. The RR sends the first parameter set, so that the RR reflects the first parameter set to the second network device in the VPN, and the second network device is the other endpoint of the SD-WAN tunnel.

In some implementations, the sending unit is configured to send a first advertisement message within the VPN. The first advertisement message includes a first address family identifier and the first parameter set. The first address family identifier is used to Identifies Border Gateway Protocol Ethernet Virtual Private Network BGP EVPN or Border Gateway Protocol Virtual Private Network bit-based explicit replication BGP VPN BIER.

In some embodiments, the processing unit is also used to obtain a second parameter set, which includes multicast source group information, the BFR prefix of the first network device, and a second tunnel type. The second tunnel type Used to identify the tunnel between the first network device and the second network device in the VPN as a VPN BIER tunnel; the sending unit is used to send the second parameter set to the second network device.

In some implementations, the sending unit is configured to send a second notification message to the second network device. The second notification message includes a second address family identifier and the second parameter set. The second address family identifier Used to identify the next generation multicast virtual private network NG MVPN or BGP EVPN.

In some embodiments, the device further includes: a receiving unit, configured to receive a join message from the intra-VPN multicast receiver, where the join message includes the multicast source group information; or, receive a join message from the intra-VPN multicast receiver. The leave message includes the multicast source group information.

In the fourth aspect, a device for processing multicast messages is provided. The first network device located in the virtual private network VPN includes: a receiving unit for receiving the first multicast data message; and a processing unit for Based on the first multicast data message and the first parameter set, a second multicast data message is obtained. The first parameter set includes the bit forwarding router prefix BFR prefix of the second network device in the VPN and the software definition used to identify it. Parameters of the wide area network SD-WAN tunnel. The second network device is the endpoint of the SD-WAN tunnel. The second multicast data packet includes a first packet header, a second packet header and the first multicast data packet. The payload of the message, the first message header includes the IP address of the second network device obtained based on the parameters used to identify the SD-WAN tunnel, and the second message header includes the BFR prefix obtained based on the second network device a bit-based explicit copy BIER parameter; a sending unit configured to send the second multicast data message to the second network device through the SD-WAN tunnel.

In some embodiments, the first parameter set further includes: the BIER forwarding router identifier BFR-ID of the second network device, the bit string length BSL of the second network device, and the maximum set identifier of the second network device. max-SI, One or more of the ID of the BIER subdomain where the second network device is located, the bit index forwarding table identifier BIFT-ID of the second network device, and the identifier of the VPN.

In a fifth aspect, a network device is provided. The network device includes a processor and a network interface. The network device executes the above-mentioned first aspect or any of the optional methods provided by the first aspect through the processor and the network interface. Methods.

In a sixth aspect, a network device is provided. The network device includes a processor and a network interface. The network device executes the above second aspect or any of the optional methods provided by the second aspect through the processor and the network interface. Methods.

In a seventh aspect, a network system is provided, which system includes the device as in the third aspect or any one of the embodiments of the third aspect and the device as in the fourth aspect or any one of the embodiments of the fourth aspect.

In an eighth aspect, a network system is provided, which system includes the device as in the fifth aspect and the device as in the sixth aspect.

In a ninth aspect, a computer-readable storage medium is provided. The storage medium stores at least one instruction. When the instruction is run on a computer, it causes the computer to execute the above-mentioned first aspect or any of the optional methods of the first aspect. methods provided.

In a tenth aspect, a computer-readable storage medium is provided. The storage medium stores at least one instruction. When the instruction is run on a computer, it causes the computer to execute the above-mentioned second aspect or any of the optional methods of the second aspect. methods provided.

In an eleventh aspect, a computer program product is provided. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a computer, they cause the computer to execute the above-mentioned first aspect or aspects. Any of the optional methods provided.

In a twelfth aspect, a computer program product is provided. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a computer, the computer is caused to execute the above second aspect or the second aspect. Any of the optional methods provided.

In a thirteenth aspect, a chip is provided. The chip includes programmable logic circuits and/or program instructions. When the chip is run, it is used to implement the method provided by the above-mentioned first aspect or any alternative method of the first aspect. .

In a fourteenth aspect, a chip is provided. The chip includes programmable logic circuits and/or program instructions. When the chip is run, it is used to implement the method provided in the above-mentioned second aspect or any of the optional modes of the second aspect. .

Description of drawings

Figure 1 is a schematic diagram of an application scenario provided by an embodiment of the present application;

Figure 2 is a schematic diagram of another application scenario provided by the embodiment of the present application;

Figure 3 is a schematic diagram of a network topology provided by an embodiment of the present application;

Figure 4 is a schematic diagram of a logical function architecture provided by an embodiment of the present application;

Figure 5 is a flow chart of a multicast configuration method provided by an embodiment of the present application;

Figure 6 is a flow chart of another multicast configuration method provided by an embodiment of the present application;

Figure 7 is a flow chart of a method for processing multicast data packets provided by this application;

Figure 8 is a schematic diagram of a BGP EVPN IP prefix routing NLRI format provided by the embodiment of this application;

Figure 9 is a schematic diagram of a BGP BIER VPN prefix routing NLRI format provided by the embodiment of this application;

Figure 10 is a schematic diagram of the format of the BIER service encapsulation attribute field in the first notification message provided by the embodiment of the present application;

Figure 11 is a schematic diagram of SD-WAN encapsulated extended community attributes and color extended community attributes in a first notification message provided by an embodiment of the present application;

Figure 12 is a schematic diagram of the MVPN or EVPN routing VPN BIER PTA field format provided by the embodiment of the present application;

Figure 13 is a schematic diagram of the BGP EVPN S-PMSI A-D routing NLRI format provided by the embodiment of this application;

Figure 14 is a schematic diagram of the BGP EVPN leaf A-D routing NLRI format provided by the embodiment of this application;

Figure 15 is a schematic diagram of a BGP EVPN SMET routing NLRI format provided by the embodiment of this application;

Figure 16 is a schematic diagram of a message format used when announcing joining provided by an embodiment of the present application;

Figure 17 is a schematic diagram of another message format used when announcing joining provided by the embodiment of the present application;

Figure 18 is a schematic diagram of the encapsulation format of a multicast data message provided by an embodiment of the present application;

Figure 19 is a schematic diagram of the encapsulation format of a BIER header that meets the definition of RFC8296 provided by an embodiment of the present application;

Figure 20 is a schematic diagram of a BIERv6 encapsulation format provided by an embodiment of the present application;

Figure 21 is a schematic diagram of another BIERv6 encapsulation format provided by the embodiment of the present application;

Figure 22 is a schematic diagram of the packaging format of BIERin6 provided by the embodiment of the present application;

Figure 23 is a schematic diagram of another packaging format of BIERin6 provided by the embodiment of the present application;

Figure 24 is a schematic diagram of the encapsulation format of G-BIER provided by the embodiment of the present application;

Figure 25 is an encapsulation format of a GRE extension header provided by an embodiment of the present application;

Figure 26 is a schematic diagram of a general encapsulation format of an SD-WAN header provided by an embodiment of the present application;

Figure 27 is a schematic diagram of the encapsulation format of a VXLAN header provided by an embodiment of the present application;

Figure 28 is a schematic diagram of the encapsulation format of a VXLAN-GPE header provided by an embodiment of the present application;

Figure 29 is a schematic diagram of the packaging format of a GENEVE header provided by an embodiment of the present application;

Figure 30 is a schematic diagram of an IPsec header encapsulation format provided by an embodiment of the present application;

Figure 31 is a schematic diagram of an intra-site active and backup protection scenario provided by an embodiment of the present application;

Figure 32 is a schematic diagram of another active and backup protection scenario within a site provided by an embodiment of the present application;

Figure 33 is a schematic diagram of a network deployment scenario provided by an embodiment of the present application;

Figure 34 is a schematic diagram of another network deployment scenario provided by an embodiment of the present application;

Figure 35 is a schematic structural diagram of a multicast configuration device provided by an embodiment of the present application;

Figure 36 is a schematic structural diagram of a device for processing multicast messages provided by an embodiment of the present application;

Figure 37 is a schematic structural diagram of a network device provided by an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

Some terms and concepts involved in the embodiments of this application are explained below.

(1)SD-WAN

SD-WAN is a virtual private network (VPN) technology that applies software defined networking (SDN) technology to WAN scenarios. SD-WAN technology is designed to help users reduce WAN expenses, improve network connection flexibility, and provide safe and reliable interconnection services for enterprise networks and data center networks scattered over a wide geographical range. The typical feature of SD-WAN is to establish an end-to-end Internet protocol overlay (IP overlay) tunnel between the edge devices of the site to achieve the independence of the SD-WAN underlay (basic) transmission network. Specifically, the edge devices of each site use IP overlay tunnel technology or Layer 2 overlay tunnel technology to build an IP overlay tunnel based on the underlay transmission network. The IP overlay tunnel is called an SD-WAN tunnel. The source Internet Protocol (IP) address and destination IP address of the SD-WAN tunnel are the IP addresses of the CPEs of the two sites respectively, specifically the IP addresses configured for the WAN interface of the device. For example, an SD-WAN tunnel is established between CPE1 of site 1 and CPE2 of site 2. CPE1 of site 1 and CPE2 of site 2 are the endpoints of this SD-WAN tunnel. The source IP address of the SD-WAN tunnel is the IP address of the CPE at site 1, specifically the IP address configured for the WAN interface of the CPE at site 1. The destination IP address of the SD-WAN tunnel is the IP address of the CPE at site 2, specifically the IP address configured for the WAN interface of the CPE at site 2. Therefore, the intermediate node in the transmission network publishes the route in the transmission network through the direct link with the edge device of the site, and the tunnel message can be routed and forwarded in the transmission network to the edge device of the destination site.

(2)Transport network (TN)

TN refers to the underlay network of SD-WAN (SD-WAN basic network). TN is the wide area access network provided by operators, that is, the WAN side network. TN is used to carry the overlay network of SD-WAN to realize interconnection between sites. TN includes but is not limited to MPLS network, Internet, operator dedicated line network, long term evolution (LTE, 4G), 5G or enterprise-built network. A transport network can be identified by a transport network identification (TN ID) or by the name of the transport network.

(3)SD-WAN tunnel

An SD-WAN tunnel refers to a logical channel between edge devices at two sites. Data packets are transmitted between different sites through SD-WAN tunnels to realize interconnection between different sites. The physical outbound interface of the SD-WAN tunnel is the WAN interface on the device. The TN to which the WAN interface belongs is in the same routing domain (RD). That is, the WAN interfaces at both ends of the SD-WAN tunnel can communicate at the underlay network level. Two sites can be interconnected through multiple TNs of different operators, so multiple different SD-WAN tunnels can be established between the sites.

(4)SD-WAN overlay network

SD-WAN overlay network refers to the network composed of SD-WAN tunnels. The SD-WAN overlay network is built based on the transport network.

(5)Customer premise equipment (CPE)

CPE refers to the edge device of the site and is one of the main device roles in SD-WAN. CPE is used to establish SD-WAN tunnels based on routing and tunnel information, and forward data packets through the SD-WAN tunnel.

(6)Transport network port (TNP)

TNP is also called transport tunnel endpoint (TTE). TNP refers to the WAN interface on the CPE that is connected to the transmission network, that is, the interface of the endpoint device of the SD-WAN tunnel. TNP information mainly includes site ID, transmission network identification, IP address of WAN interface and tunnel encapsulation type, etc. SD-WAN tunnels can be established between CPEs at two sites by publishing each other's TPN information. For example, after CPE1 at site 1 receives the TNP information published by CPE2 at site 2, CPE1 saves the TNP information of CPE2 into the SD-WAN tunnel forwarding table. For example, the entry in the SD-WAN tunnel forwarding table on CPE 1 (that is, the third correspondence in the following) contains the site ID field, the outbound interface field, and the next hop field. The site ID field includes the TNP information sent by CPE2. site ID, which is the site ID of site 2. The outgoing interface field is the WAN interface in the TNP information of CPE 1. The next hop field includes the IP address in the TNP information of CPE2, that is, the IP address of the WAN interface of CPE2. In the data packet forwarding phase, when CPE1 needs to forward a data packet to CPE2 in site 2, for example, the CPE searches for the next hop field in the VPN BIER forwarding table (first correspondence) and finds the next hop in the VPN BIER forwarding table. The content of the field is not the IP address of the direct next hop, but the site ID of site 2. In order to obtain the IP address of the next hop, CPE1 uses the site ID of site 2 as an index and continues to search for other forwarding entries (the so-called iteration), then CPE1 finds that the site ID of site 2 matches the site ID field in the third correspondence, so it forwards the data packet based on the next hop field and outbound interface field in the third correspondence. For example, CPE1 encapsulates an IP header in the outer layer of the data packet. The source IP address in the IP header is the IP address in the TNP information of CPE1, that is, the IP address of CPE1's WAN interface. The destination IP address in the IP header is the TNP of CPE2. The IP address in the information is the IP address of the WAN interface of CPE2, and then CPE1 sends the data packet through the WAN interface of CPE1.

(7) Site ID

site ID is used to identify a site in the SD-WAN network. The site ID is usually a number or a series of numbers. Site IDs are assigned, for example, based on the total number of sites in the SD-WAN network. Optionally, the site ID is uniformly assigned by the controller for each site in the SD-WAN. For example, the controller assigns site IDs to each site in ascending order. For example, if an SD-WAN network includes three sites, the site IDs assigned by the controller to the three sites are, for example, 1, 2, and 3 respectively, or 111, 222, and 333 respectively. When a site includes multiple CPEs, the site ID of each CPE within the same site is usually the same.

(8)Customer premise equipment identification (CPE ID)

CPE ID, also called SD-WAN device ID (SD-WAN device identification), is used to identify a CPE in the SD-WAN network. The CPE ID is usually an IP address of the device. For example, the CPE ID is the IP address of a loopback interface on the device. For example, the CPE ID is an Internet Protocol version 4 (IPv4) address or an Internet Protocol version 6 (IPv6) address. Optionally, the CPE ID is uniformly assigned by the controller to each CPE in the SD-WAN.

(9)Transmission network port identification (TNP ID)

The TNP ID is a set that includes the site ID, CPE ID, and WAN interface IP address. For example, TNP ID consists of site ID, The CPE ID is obtained by concatenating the WAN interface IP address. For another example, the TNP ID is a hash value generated based on the site ID, CPE ID, and WAN interface IP address.

(10) Route reflector (RR)

RR is used to reflect routing information and SD-WAN tunnel information between CPEs. RR can be used as a regional controller.

(11) Routing domain (RD)

RD refers to an area composed of different transmission networks that are reachable by each other. For example, if the transmission network provided by operator A and the transmission network provided by operator B are reachable by each other, the two transmission networks are considered to be located in the same within RD. SDWAN tunnels can be established between CPEs located in the same RD or between CPEs and RRs.

(12)Tenant isolation in SD-WAN

In SD-WAN networking, VPN instances can be used to provide isolation functions for tenants. On the control plane, the Ethernet virtual private network (EVPN) routes that interact between CPEs carry VN IDs to identify private network routes of different tenants. Each VPN instance is independent of each other and has its own forwarding table and routing. surface. On the data plane: Tenants access the network through CPE, and CPE identifies the VPN to which the tenant belongs through the VPN instance associated with the interface. Search the forwarding table of the VPN instance, add SDWAN encapsulation to tenant packets, and forward the packets to the remote CPE. The SD-WAN encapsulation carries the VPN identifier, which is used to identify the VPN to which the tenant belongs. When the remote CPE receives the message, it can identify the VPN to which the message belongs based on the VPN identifier. The remote CPE searches the forwarding table of the VPN instance and forwards the packet to the tenant.

(13) Bit indexed explicit replication (BIER)

BIER is a new type of multicast forwarding technology that encapsulates the set of destination nodes for multicast messages in the form of bit strings and sends them in the header of the message. This eliminates the need for intermediate nodes in the network to sense multicast services and maintain multicast flows. state. The effects of BIER include but are not limited to: First, it has good multicast service scalability; BIFT established using BIER technology on BFR is a public forwarding table independent of specific multicast services, so that intermediate nodes in the network do not need to be aware of multicast services. , there is no need to maintain the multicast flow status of specific multicast services. Both public network multicast and private network multicast packets can be forwarded through BIFT, which has good multicast service scalability. Second, simplify business deployment and operation and maintenance. Since the intermediate nodes of the network are not aware of multicast services, the deployment of multicast services usually does not involve intermediate nodes. Changes in multicast services have little impact on intermediate nodes, simplifying network deployment and operation and maintenance. Third, it is conducive to the evolution of software-defined network (SDN) architecture networks. Specifically, deploying multicast services does not require operating network intermediate nodes. You only need to add a BIER header to multicast packets at the entry node to indicate subsequent multicast replication. The BIER header carries a bit string that identifies the multicast outlet node. The intermediate node implements multicast replication and forwarding based on the bit string, which is beneficial to the evolution of SDN architecture networks.

(14) bit forwarding router (BFR)

BFR refers to a device that supports BIER forwarding. BFR product forms include but are not limited to routers, switches, firewalls or other network equipment. BFR is divided into bit forwarding ingress router (BFIR), intermediate BFR (transit BFR) and bit forwarding egress router (BFER).

(15)BIER Network

A BIER network refers to a logical area that supports BIER forwarding. A BIER network includes multiple BFRs. Optionally, a BIER network is a BIER domain, or a BIER network is a BIER subdomain.

(16)BIER domain (BIER domain)

A BIER domain refers to the collection of all BFRs in a routing domain or management domain.

(17)BIER subdomain (BIER sub-domain).

A BIER domain can be divided into one or more BIER subdomains, and the BIER subdomain can also be referred to as SD. Each BIER subdomain is identified by a unique subdomain ID.

(18)BFIR

BFIR is the node through which multicast data flows enter the BIER network. BFIR is used to BIER encapsulate multicast data packets entering the BIER network to obtain BIER packets containing multicast data packets and BIER headers.

(19)transit BFR

transit BFR is an intermediate node for forwarding multicast data packets in the BIER network. It is used to forward BIER packets based on bit strings. transit BFR is an optional device deployed in the BIER network. In some embodiments, BFIR and BFER are deployed in the BIER network without transit BFR. For example, BFIR and BFER are physically directly connected; another example, BFIR and BFER are connected through an IP link, and BFER is the next hop of BFIR; another example, BFIR and BFER are connected through one or more hops that do not support BIER, and BFIR After sending the BIER message, the BIER message passes through the MPLS encapsulation or IPv6 unicast route in the outer layer of the BIER header and passes through the node that does not support BIER to reach the BFER.

In the embodiment of deploying transit BFR, the number of transit BFR deployed in a BIER network includes multiple situations. Two situations are given as examples below. In some embodiments, a transit BFR is deployed in a BIER network. The transit BFR is located between the BFIR and the BFER in the BIER forwarding path. BIER messages are forwarded from the BFIR to the BFER via the transit BFR. In other embodiments, two or more transit BFRs are deployed in a BIER network. There is an up-and-down hop relationship between different transit BFRs. BIER messages are forwarded from BFIR to another transit BFR via one transit BFR. Then forward it from another transit BFR to BFER. For example, if BFIR, transit BFR 1, transit BFR 2 and BFER are deployed in the BIER network, the forwarding path of BIER packets is BFIR→transit BFR 1→transit BFR 2→BFER.

transit BFR is an optional device deployed in the BIER network. In some embodiments, BFIR and BFER are deployed in the BIER network without transit BFR. For example, BFIR and BFER are physically directly connected, and BFER is the next hop of BFIR; another example, BFIR and BFER are connected through one or more hops that support BIER; another example, BFIR and BFER are connected through one or more hops that do not support BIER. nodes are connected. After BFIR sends a BIER message, the BIER message passes through the MPLS encapsulation or IPv6 unicast route in the outer layer of the BIER header and reaches BFER through the node that does not support BIER.

In the embodiment of deploying transit BFR, the number of transit BFR deployed in a BIER network includes multiple situations. Two situations are given as examples below.

In some embodiments, a transit BFR is deployed in a BIER network. The transit BFR is located between the BFIR and the BFER in the BIER forwarding path. BIER messages are forwarded from the BFIR to the BFER via the transit BFR.

In other embodiments, two or more transit BFRs are deployed in a BIER network. There is an up-and-down hop relationship between different transit BFRs. BIER messages are forwarded from BFIR to another transit BFR via one transit BFR. Then forward it from another transit BFR to BFER. For example, if BFIR, transit BFR 1, transit BFR 2, and BFER are deployed in the BIER network, the forwarding path of BIER packets is BFIR→transit BFR 1→transit BFR 2→BFER.

(20)BFER

BFER is the node through which multicast data flows out of the BIER network. It is used to decapsulate BIER packets and forward the obtained multicast data packets to multicast receivers.

(21)Edge BFR

Edge BFR refers to the BFR located at the edge of the BIER network. Edge BFR is the collective name of BFIR and BFER.

(22) bit forwarding router identifier (BFR-ID)

Regarding the role of BFR-ID, BFR-ID is used to identify the BFR located at the edge of the BIER network in a BIER network (such as a BIER subdomain or a BIER domain).

For the form of BFR-ID, BFR-ID is usually an integer, for example, a positive integer in the range of 1 to 65535.

Regarding the relationship between BFR-ID and bit string, in some embodiments, one BFR-ID corresponds to one bit in the bit string. For example, BFR-ID is 1, which corresponds to the rightmost bit (or the lowest bit) in the bit string; BFR-ID is 2, which corresponds to the second bit from right to left (or the second lowest bit) in the bit string. ; By analogy, BFR-ID is i, corresponding to the i-th bit from right to left in the bit string, where i is a positive integer.

Regarding the meaning of BFR-ID, if the bit string carried by a message contains the BFR-ID of a device, or the bit position corresponding to the BFR-ID of the device is set, it means that the device is the destination BFER of the message.

(23)BFR prefix(BFR prefix)

BFR prefix refers to an IP address of BFR. Optionally, the BFR prefix is the IP address of a loopback interface on the BFR. For example, the BFR prefix is a reachable IP address in the BIER network. For example, BFR prefix is a 32-bit IPv4 address; another example, BFR prefix is a 128-bit IPv6 address. Optionally, in the BIERv4 scenario, use an IPv4 address of the device as the BFR prefix; in the BIERv6 scenario, use an IPv6 address of the device as the BFR prefix.

(24) Set Identifier (SI)

SI refers to the identifier of the set to which the BFR-ID belongs. The form of SI is usually one or a series of numbers. For example, a BIER network includes set 0 and set 1. Set 0 includes BFRs with BFR-IDs from 1 to 256, and set 1 includes BFRs with BFR-IDs from 257 to 512. Then, among the BFRs with BFR-IDs from 1 to 256, The SI of each BFR is 0, and the SI of each BFR in BFR-IDs 257 to 512 is 1.

(25)SI maximum value (max SI, also called max-SI, MAX-SI or MAX SI)

max-SI refers to the maximum value of the set identifier (SI).

(26) bit string

The bit string is used to identify the destination BFER set of the BIER message. The bit string starts from the lowest bit (that is, the first bit from the right), and each bit corresponds to a BFR-ID. If the bit position is 1, it indicates that the BFER identified by the BFR-ID corresponding to this bit is the destination BFER of the multicast data message.

(27) Bit string length (BSL)

BSL refers to the length of the bit string. For example, if the BSL is 64, it means that the length of the bit string is 64 bits.

(28) bit index routing table (BIRT)

BIRT is used to indicate the BFR prefix of a BFER in a BIER network, the BFR-ID of the BFER and Correspondence between the next hops on the forwarding path that reach the BFER. For the detailed definition of BIRT, please refer to the introduction in Section 6.3 of RFC 8279.

(29) bit index forwarding table (BIFT)

BIFT is based on the forwarding table generated by BIER. BIFT is used to represent each BFER node that can be reached through BFR neighbors, including Nbr (BFR Neighbor, BFR neighbor) and forwarding bit mask (forwarding bit mask, F-BM). Each BIFT is usually determined by a triplet (BSL, SD, SI). For example, BIFT is generated by BFR by merging different entries in BIRT entries that pass through the same neighbor. Optionally, each BIFT entry includes a BFR neighbor and the corresponding F-BM. In some embodiments of this application, each entry of BIFT also includes site ID or CPE ID.

(30-bit Indexed Forwarding Table Identifier (BIFT-ID)

BIFT-ID is used to identify a BIFT. BIFT-ID is usually determined based on three parameters: BSL, SD and SI. For example, BIFT-ID is obtained by splicing three parameters: BSL, SD and SI. For another example, BIFT-ID is the hash value obtained by hashing the three parameters BSL, SD and SI.

(31)BFR neighbor (BFR neighbor, BFR Nbr)

The BFR neighbor represents the next hop BFR. Optionally, the BFR neighbor is represented by the BFR prefix of the next hop BFR.

(32) Forward bit mask (F-BM)

F-BM is used to indicate the set of BFERs in the BIER network that can be reached through the BFR neighbor when the BFR copies and sends multicast data packets to the BFR neighbor. F-BM is, for example, BFR obtained by ORing the bit strings of all BFERs reachable by the BFR neighbor. F-BM is represented by a bit string, and the length of the bit string used by F-BM and packet forwarding is the same. For example, the length of the bit string carried in the message is 256 bits, and the length of the F-BM is also 256 bits. During the message forwarding process, the bit string carried in the message will perform an AND operation with the F-BM.

(33)BIER forwarding method

In the BIER network, data packets are copied and forwarded based on bit strings. Specifically, when a BFR obtains a data message carrying a bit string, it performs a bitwise AND on the bit string and the F-BM in each row of entries in the BIFT, and decides the next action based on the result of the AND. For example, if there is a table entry in BIFT that the result of the AND of the F-BM and the bit string is non-zero, and the next hop corresponding to the F-BM is not itself, the datagram will be sent to the next hop corresponding to the F-BM. arts. If there are k row entries in BIFT and the result of the AND of the F-BM and the bit string is not 0, and the next hop corresponding to each F-BM among the k F-BMs is not itself, the datagram will be copied. message to obtain k copied data messages, and send the data message to the next hop corresponding to each F-BM among the k F-BMs. If the AND result of the bit string and the F-BM in a row of entries in BIFT is non-zero, and the next hop corresponding to the F-BM is itself, that is, only its own BFR-ID is set in the bit string, this If this situation indicates that this node is the BFER of the data packet, then the BIER forwarding is terminated, the BIER header in the data packet is decapsulated, and the original data packet is sent to the multicast receiver according to the multicast routing table.

During the forwarding of data packets in the BIER network, the value of the bit string carried in the data packet may be updated. For example, the bit string carried in the data packet sent by a BFR to a next hop is the result of the AND of the bit string carried in the data packet received by the BFR and the F-BM corresponding to the next hop. For example, there are two F-BMs in the BIFT of the first BFR. The first F-BM corresponds to the first next hop, and the second F-BM corresponds to the second next hop. The first BFR receives the data message 1, and the bit string carried in the data message 1 is non-zero after being ANDed with the first F-BM and the second F-BM. The first BFR copies data packet 1 and obtains two copied data packets, namely data packet 2 and data packet 1. Message 3. The bit string in data packet 2 is the result of the AND of the bit string in data packet 1 and the first F-BM, which is equivalent to removing the BFR-ID corresponding to the second next hop in the bit string. The first BFR sends data packet 2 to the first next hop. The bit string in data packet 3 is the result of the AND of the bit string in data packet 1 and the second F-BM, which is equivalent to removing the BFR-ID corresponding to the first next hop in the bit string. The first BFR sends data packet 3 to the second next hop.

(34)End.BIER address

In order to support IPv6-based packet forwarding, BIERv6 defines a new type of SID called End.BIER address. The End.BIER address serves as the IPv6 destination address and instructs the forwarding plane of the device to process the BIERv6 header in the packet. When each node receives and processes a BIERv6 message, it encapsulates the End.BIER SID of the next hop node into the IPv6 destination address in the outer layer of the BIERv6 header, and indicates the destination BFER set of the multicast message through the bit string in the BIERv6 header. End.BIER SID can also make good use of the reachability of IPv6 unicast routing across IPv6 nodes that do not support BIERv6. End.BIER SID usually consists of two parts: locator and other bits. locator represents a BIERv6 forwarding node. The locator has a positioning function. After a node is configured with a locator, the control plane device will generate a locator network segment route and spread it within the SRv6 domain through IGP. Other nodes in the network can locate this node through the locator network segment route. At the same time, all SRv6SIDs published by this node can also be reached through this locator network segment route. End.BIER SID can guide the packet to the designated BFR. The BFR receives a multicast packet, recognizes that the destination address of the packet is the local End.BIER SID, and determines that it is forwarded according to the BIERv6 process.

(35)Multicast group

A multicast group refers to a collection identified by an IP multicast address. When a multicast receiver (such as a host or other device that needs to receive multicast data packets) joins a multicast group, it becomes a member of the multicast group and can identify and receive multicast data sent to the multicast group. message.

(36)Multicast source

One multicast source can send data to multiple multicast groups at the same time, and multiple multicast sources can also send packets to one multicast group at the same time.

(37)Multicast group members

Multicast group members refer to hosts or other devices that have joined the multicast group. Members in a multicast group are dynamic. For example, a host can join or leave the multicast group at any time.

(38)Multicast router

Multicast router refers to a device with multicast forwarding function, such as a router or switch. Multicast routers are divided into root nodes, intermediate nodes and leaf nodes. The root node is connected to the multicast source and is the first hop router in the forwarding path of multicast data packets. The leaf node is connected to the multicast receiver, and the leaf node is the last hop router in the forwarding path of the multicast data packet. The intermediate node is located between the root node and the leaf nodes and is used to forward multicast data packets from the root node to the leaf nodes. In the case of multicast forwarding based on BIER, the root node is BFIR, the intermediate node is intermediate BFR, and the leaf node is BFER.

(39) Internet group management protocol (IGMP)

IGMP is the protocol responsible for IPv4 multicast member management in the TCP/IP protocol suite. IGMP is used to establish and maintain multicast group membership relationships between multicast receivers and their directly adjacent multicast routers. IGMP implements group member management functions by exchanging IGMP messages between multicast receivers and multicast routers. IGMP messages are encapsulated in IP messages. IGMP Messages include but are not limited to member report messages, member leave messages, general query messages, group-specific query messages, and source group-specific query messages. (group-and-source-specific query). The member report message refers to the report message sent by the multicast receiver to the querier, which is used to apply to join a certain multicast group or respond to the query message. The member leave message is a message that a multicast receiver actively sends to the querier when it leaves a multicast group. It is used to announce that it has left a certain multicast group. General group query messages are query messages sent by the querier to all hosts and routers on the shared network to learn which multicast groups have members. A specific group query message refers to a query message sent by the querier to a specified multicast group in the shared network segment to query whether there are members in the multicast group. The querier is usually a multicast router connected to the multicast receiver. The querier is used to send query messages and receive member report messages and member leave messages fed back by the host to learn about the network connected to the interface that receives the message. Which multicast groups have receivers (i.e. group members) on the segment.

(40)(S,G) or (*,G)

The multicast routing table is usually divided into (S, G) routing table entries or (*, G) routing table entries. S represents the multicast source. In the multicast routing table, S is usually represented by the IP address of the multicast source. G represents a multicast group (group). In the multicast routing table, G is usually represented by the multicast IP address of the multicast group. * means any. The (S, G) routing table entry indicates that the multicast group and the multicast source are known. (*, G) indicates that the multicast group is known but the multicast source entry is not known.

(41)VPN

VPN refers to a virtual private network. VPN is a private network, which can also be called user network, private network or user-side network. VPNs in the embodiments of this application include, but are not limited to, Layer 3 VPN (L3VPN) or Layer 2 VPN (L2VPN).

(42)VPN logo

The VPN identifier is used to identify a VPN. For example, the identifier of a VPN is a VPN identifier (virtual network identifier virtual network identifier, VN-ID) or a route identifier (route distinguisher, RD).

(43)VPN BIER

VPN BIER refers to a BIER network within a VPN. For example, VPN BIER is a BIER subdomain within a VPN.

(44)site

A site refers to a logical area that contains at least one device with IP connectivity. IP connectivity between different devices within a site usually does not need to be implemented through the operator's network. For example, Company A has deployed its headquarters network in Province VPN 1, deploy the headquarters network as site 1 of VPN 1, deploy the branch network as site 2 of VPN 1, site 1 and site 2 are in the same VPN, site 1 and site 2 can transmit data packets through the operator network . The relationship between site and VPN can also be understood this way: for multiple sites connected to the same operator's network, they can be divided into different sets (sets) by formulating policies. Only sites belonging to the same set can communicate with each other through the operator. For mutual network access, this collection is a VPN.

In some embodiments, one or more CPEs are deployed in the site. In the scenario where multiple CPEs are deployed in the same site, the site IDs of different CPEs in the same site are the same. Sites are also part of the SD-WAN network.

(45)Routing iteration

There needs to be a directly connected next hop in the routing table entry before it can be used to guide forwarding. However, the next hop in the routing table entry may not be directly connected. Therefore, it is necessary to calculate a directly connected next hop and the corresponding outbound interface. , this process is called routing iteration. For example, the next hop of a Border Gateway Protocol (BGP) route is generally the non-directly connected peer loopback address, which cannot guide forwarding and needs to be iterated, that is, based on the next hop learned by BGP as the destination address, the IP Search in the routing table. When a route with directly connected next hop and outbound interface information is found, fill in the directly connected next hop and outbound interface into the routing table and generate the corresponding forwarding table entry.

(46)Tunnel iteration

In order to pass private network traffic to the other end through the public network, a public network tunnel is required to carry private network traffic. Therefore, routing iteration needs to be performed based on the destination IP prefix to find a suitable tunnel. When the tunnel iteration is successful, the route is placed in the corresponding VPN instance routing table, the process of iterating routes to the corresponding tunnel is called tunnel iteration. For example, for BGP private network routing, a tunnel is required for forwarding. The next hop of the route is generally the loopback address of the edge device of the remote site. This cannot guide forwarding. Route iteration is also required, that is, finding the loopback address in the tunnel list. tunnel, fill the tunnel information into the routing table and generate the corresponding forwarding entry. In one possible implementation, when the tunnel iteration is successful, the identity of the tunnel is retained. When forwarding VPN packets, the corresponding tunnel is found based on the tunnel identifier, and then sent out through the tunnel.

(47)Tunnel

A tunnel generally refers to a virtual connection, or a virtual path, which enables data packets with the tunnel encapsulation format to be transmitted on the path. The two endpoint devices of the tunnel encapsulate and decapsulate the tunnel header of the data packet respectively. For example, for GRE encapsulation, the ingress node of the tunnel encapsulates the tunnel header for the data packet, and the egress node of the tunnel decapsulates the tunnel header and restores the original format of the data packet.

(48) Provider multicast service interface tunnel attribute (PTA)

Provider multicast service interface (PMSI) refers to the channel used to transmit private network multicast data packets in the operator network. PTA is used to carry the information required to create PMSI. In order to support next generation multicast VPN (next generation MVPN, NG MVPN over BIER), in the BGP MVPN service, a BIER type PTA can be used to carry the information required to establish a BIER forwarding path. For details of the PTA, please refer to RFC8556.

(49)Multicast routing table and multicast forwarding table

Devices in a multicast network can maintain different types of entries based on their different roles, such as multicast protocol routing tables, multicast routing tables, multicast forwarding tables, IGMP group entries, and IGMP routing tables. The multicast protocol routing table is an entry maintained by each protocol when running various multicast routing protocols. It is the basis for multicast routing and forwarding. The multicast protocol routing table targeted by the embodiments of this application is, for example, a BIER routing table (BIRT) or a BIER forwarding table (BIFT). The multicast routing table is used to store routing information selected from the routing information generated by multiple multicast protocols based on cost or other parameters when the device supports multiple multicast protocols. The multicast forwarding table is an entry generated based on the multicast routing table to guide multicast data forwarding.

(50)loopback interface

The loopback interface is a virtual interface on the forwarding device. When the loopback interface is created, unless it is closed manually interface, otherwise its physical layer is usually up. In the BGP protocol, the source interface that sends BGP messages can be configured as a loopback interface to ensure that the BGP session is not affected by physical interface failures.

(51)tunnel interface

The tunnel interface is a virtual interface on the forwarding device. The devices at both ends of the tunnel use the tunnel to send packets, identify and process packets from the tunnel. The parameters of the tunnel interface include the name of the tunnel interface, the IP address of the tunnel interface, the tunnel protocol of the tunnel interface, the source address of the tunnel, and the destination address of the tunnel.

(52) Next generation multicast virtual private network (NG MVPN)

NG MVPN is a new generation framework for IP multicast data traffic to traverse VPN. In order to enable different PEs in the same multicast VPN (multicast VPN, MVPN) to interact with control messages and create private network multicast data channels, each PEs need to discover other PEs belonging to the same MVPN. NG MVPN uses BGP to implement automatic discovery and defines a new address family, the BGP-MVPN address family. NG MVPN routing information is carried in BGP update messages. NG MVPN delivers MVPN client multicast routes and establishes public network tunnels through control messages defined by BGP-MVPN. BGP-MVPN defines 7 types of control messages. The 7 control messages represent 6 MVPN routing types. Types 6 and 7 are mainly used to initiate private network users to join and guide multicast data traffic delivery. Types 1 to 5 are mainly used to Automatically discover MVPN members and assist MPLS in establishing P2MP tunnels. Types 6 and 7 are called MVPN customers' multicast routing information (C-multicast routing, C stands for Customer), and types 1 to 5 are called leaf advertisement routes (leaf A-D routes).

(53) Leaf advertisement route (leaf A-D route)

leaf A-D route is used to respond to the Class 1 route whose flags field in the PMSI attribute is 1. The autonomous system domain contains the operator multicast service interface automatic discovery route (intra autonomous system inclusive provider multicast service interface auto discovery route, Intra-AS I-PMSI A-D route) and responds to the type 3 route S-PMSI A-D route, indicating that there is a request to establish an S-PMSI tunnel at the leaf node, assisting the root node in completing tunnel information collection.

(54)Address family identification

The address family identifier is a number used in MP-BGP to distinguish information from different network layers. The form of the address family identifier is, for example, a number or a series of numbers. The address family identifier includes, but is not limited to, one or more of an address family identifier (address family identifier, AFI) or a sub-address family identifier (subsequent address family identifier, SAFI). For example, the address family identifier includes an AFI with a value of 25 and a SAFI with a value of 70. The AFI with a value of 25 and the SAFI with a value of 70 identify the Border Gateway Protocol Ethernet Virtual Private Network (BGP). EVPN).

The application scenarios of the embodiments of this application are illustrated below with examples.

The embodiments of this application are applied to the scenario of deploying multicast services in the SD-WAN network, and are specifically applied to the scenario of deploying multicast services in the same VPN in the SD-WAN network. According to some embodiments of the present application, BIER is deployed within the VPN in the SD-WAN network, and multicast services are implemented based on BIER, thereby providing a VPN BIER mechanism based on SD-WAN, allowing multicast data flows from multicast sources in the VPN You can use BIER and SD-WAN tunnels to traverse the WAN to reach multicast receivers in the VPN.

The embodiments of this application are applicable to many networking scenarios. The following is an example of two networking scenarios.

Networking Scenario 1: Deploy root nodes and leaf nodes, but do not deploy intermediate nodes.

Figure 1 is a schematic diagram of an application scenario provided by an embodiment of the present application. The application scenario shown in Figure 1 includes forwarding device A, forwarding device B and forwarding device C. Forwarding device A, forwarding device B, and forwarding device C are located in the same BIER network (such as a BIER subdomain), and forwarding device A, forwarding device B, and forwarding device C are all located in VPN1. Forwarding device A is located at site A within VPN 1, and forwarding device A is connected to the multicast source. Forwarding device B and forwarding device C are both located at site B within VPN1. Forwarding device B accesses multicast receiver A, and forwarding device C accesses multicast receiver A and multicast receiver B. The WAN interface 211 of forwarding device A and the WAN interface 212 of forwarding device B establish an SD-WAN tunnel 21. That is, the two endpoint devices of the SD-WAN tunnel 21 are forwarding device A and forwarding device B respectively. The WAN interface 221 of forwarding device A and the WAN interface 222 of forwarding device C establish an SD-WAN tunnel 22. That is, the two endpoint devices of the SD-WAN tunnel 22 are forwarding device A and forwarding device C respectively. Optionally, an RR is also deployed, and the RR is connected to forwarding device A, forwarding device B, and forwarding device C through the network.

Networking scenario 2: Deploy root nodes, leaf nodes and intermediate nodes.

Optionally, please refer to Figure 2, which is a specific example of deploying root nodes, leaf nodes, and intermediate nodes. Figure 2 is based on the scenario shown in Figure 1 and further includes a forwarding device D. Forwarding device D is located in site C within VPN1. The WAN interface 311 of forwarding device A and the WAN interface 312 of forwarding device D establish an SD-WAN tunnel 31. The WAN interface 321 of forwarding device D and the WAN interface 322 of forwarding device B establish an SD-WAN tunnel 32. The WAN interface 331 of forwarding device D and the WAN interface 332 of forwarding device B establish an SD-WAN tunnel 33.

The definition of device roles varies in different protocols. In the BIER protocol, the roles of devices are mainly divided into three types: BFIR, transit BFR and BFER. For example, in the scenario shown in Figure 2, forwarding device A is BFIR, forwarding device D is transit BFR, and forwarding device B and forwarding device C are BFER. In the multicast protocol, the roles of devices are mainly divided into root nodes (or head nodes), intermediate nodes, and leaf nodes. For example, in the scenario shown in Figure 2, forwarding device A is the root node, forwarding device D is the intermediate node, and forwarding device B and forwarding device C are leaf nodes. In the SD-WAN protocol, the roles of devices are mainly divided into CPE and RR. For example, in the scenario shown in Figure 2, forwarding device A, forwarding device D, forwarding device B, and forwarding device C are all CPEs, or one of forwarding device A, forwarding device D, forwarding device B, and forwarding device C It is CPE and RR at the same time, and the other three devices are CPE.

The following is an example of the logical function architecture provided by the embodiment of the present application.

Figure 4 is a schematic diagram of the logical functional architecture provided by the embodiment of this application. As shown in Figure 4, the functional architecture includes an SD-WAN tunnel layer, a VPN BIER layer and a multicast private network layer.

The SD-WAN tunnel layer is the basis of the VPN BIER layer and is used to forward multicast data flows through SD-WAN forwarding.

The VPN BIER layer is used to forward multicast data packets within the VPN based on BIER. Specifically, the VPN BIER layer introduces the VPN BIER mechanism to allow multicast data traffic within the VPN to traverse the operator's network. For example, deploy the intra-VPN BIER function on the LAN side on the operator network backbone CPE and enterprise or user branch access network CPE to form a multi-tenant isolated SD-WAN overlay BIER topology, and deploy tenants' multicast services on top of the VPN BIER , realize the BIER multicast service of SD-WAN single-hop or multi-hop network service point (point of presence, POP).

The multicast private network layer is used for information exchange of multicast services on the control plane, such as through BGP MVPN or EVPN multicast channels. By transmitting overlay multicast joining information and exit information, it is used for multicast service traffic diversion and multicast VPN BIER tunnel establishment to realize one-hop joining of multicast users. One-hop joining means that the leaf node sends BGP signaling to the root node to join the multicast group through the BGP peer relationship with the root node, or the leaf node sends BGP signaling to the RR through the BGP peer relationship with the RR. , the RR then forwards BGP signaling to the root node through the BGP peer relationship with the root node to join the multicast group. Compared with PIM, the leaf node sends control signaling to the previous hop node of the leaf node, and then each hop node sends control signaling to the upstream hop by hop until the control signaling reaches the root node and joins the multicast group. In other words, since the BGP signaling indicating joining only needs to be sensed by leaf nodes and root nodes, or only leaf nodes, root nodes and RRs, and does not need to be sensed by every hop node in the forwarding path, one-hop joining is achieved, reducing the number of Forwarding is used to indicate the bandwidth occupied by the added BGP signaling.

Regarding the relationship between SD-WAN tunnels and VPN BIER tunnels, VPN BIER tunnels are BIER forwarding paths established based on SD-WAN tunnels. VPN BIER tunnel is a virtual tunnel. A VPN BIER tunnel can pass through multiple SD-WAN tunnels. SD-WAN tunnels are usually end-to-end tunnels between sites, and SD-WAN tunnels can pass through multiple nodes within the transmission network. For example, please refer to Figure 3. In the scenario shown in Figure 3, the VPN BIER tunnel refers to from forwarding device A through forwarding device D to forwarding device B. The root node of the VPN BIER tunnel is forwarding device A, the intermediate node is forwarding device D, and the leaf node is forwarding device B.

VPN BIER tunnel is established based on SD-WAN tunnel 31 and SD-WAN tunnel 32. The two endpoints of the SD-WAN tunnel 31 are forwarding device A and forwarding device D respectively. The SD-WAN tunnel 31 passes through multi-hop nodes in the transmission network 1. The two endpoints of the SD-WAN tunnel 32 are forwarding device B and forwarding device D respectively. The SD-WAN tunnel 32 passes through multi-hop nodes in the transmission network 2.

The following is an example of the method flow of the embodiment of the present application.

Some embodiments of this application involve the control plane configuration process of different layers in the above three-layer logical architecture. In order to distinguish and describe parameters related to different layers, the parameter set related to the VPN BIER layer is called the first parameter set, and the multicast private network is called the first parameter set. The layer-related parameter set is called the second parameter set, and the SD-WAN tunnel layer-related parameter set is called the third parameter set.

After parameters related to any of the above three layers are configured on a forwarding device in the VPN, the configured parameters can be advertised within the VPN. When a forwarding device in the VPN receives the parameters related to any of the above three layers advertised by another forwarding device in the VPN, it can obtain the corresponding relationship of the corresponding layer based on the received parameters, so as to receive the multicast data. Multicast data packets are forwarded through this corresponding relationship.

Optionally, the forwarding device saves the obtained correspondence in the form of a table entry. For example, a corresponding relationship is a row of entries or a collection of multiple rows of entries in a table on the forwarding device. The tables on the forwarding device are usually divided into routing information base (RIB) and forwarding information base (FIB). The specific form of the corresponding relationship may be an entry in the RIB table or an entry in the FIB table.

In order to distinguish and describe the corresponding relationships used by different layers, the embodiments of this application will later refer to the corresponding relationship related to the VPN BIER layer as the first corresponding relationship, the corresponding relationship related to the multicast private network layer as the second corresponding relationship, and the corresponding relationship to the multicast private network layer as the second corresponding relationship. The correspondence relationship related to the SD-WAN tunnel layer is called the third correspondence relationship.

Optionally, the forwarding device stores the above three corresponding relationships through different types of entries. For example, the above three correspondences are stored in three independent tables on the device. For example, the first correspondence is an entry in the BIER forwarding table (BIFT) or the BIER routing table (BIRT), and the second correspondence is an entry or group in the multicast routing table. There is an entry in the broadcast forwarding table, and the third corresponding relationship is an entry in the SD-WAN tunnel forwarding table. Alternatively, the forwarding device stores at least two of the above three correspondences through one type of table entry, that is, at least two of the above three correspondences are integrated into the same table. This embodiment does not limit whether the above three corresponding relationships are independent tables or integrated into one table.

A forwarding device can store the above three corresponding relationships at the same time, or can store only one or two corresponding relationships among the above three corresponding relationships. For example, for a forwarding device serving as an intermediate node, since the intermediate node usually does not need to maintain the status of the multicast service, the forwarding device serving as an intermediate node does not need to save the above-mentioned second corresponding relationship. The forwarding device as the root node can store the first correspondence, the second correspondence and the third correspondence, and the forwarding device as the leaf node can store the first correspondence, the second correspondence and the third correspondence.

In the case where the above three corresponding relationships are saved through different types of entries, the above three corresponding relationships can be linked together through routing iteration. For the basic concept of routing iteration, please refer to the description in the concept explanation section above. In some embodiments of the present application, routing iteration generally refers to the forwarding device querying one corresponding relationship. After obtaining the query result, the forwarding device can determine to query another corresponding relationship based on the query result.

Taking the iteration from the first correspondence to the third correspondence as an example, the first correspondence includes the next hop that matches the parameters identifying the SD-WAN tunnel, thereby achieving pointing to SD-WAN at the VPN BIER layer, so that as the root node When the intermediate node or leaf node searches for the first correspondence based on the bit string, it can determine based on the next hop that the multicast data message is to be forwarded through the SD-WAN tunnel, and then further searches for the third correspondence to obtain the outbound interface and next hop. Jump. For example, the content of the next hop field or the outbound interface field in the above first correspondence is the site ID of the site where the peer device of the SD-WAN tunnel is located. Therefore, after searching for the first correspondence, the content of the next hop field or the egress interface field is the site ID of the peer device of the SD-WAN tunnel. The site ID of the site will further find the third corresponding relationship.

Taking the iteration from the second correspondence to the first correspondence as an example, for example, the above-mentioned second correspondence includes parameters identifying the VPN BIER tunnel, thereby achieving pointing to the VPN BIER at the multicast private network layer, so that the forwarding device serving as the root node receives To the multicast data packet, when searching for the second correspondence, it can be determined according to the next hop that the multicast data packet is to be forwarded through the VPN BIER tunnel, and then the first correspondence is further searched to obtain the outgoing interface and next hop.

The following is an example of the parameter configuration of the VPN BIER layer and the process of obtaining the corresponding relationship through the embodiment shown in Figure 5. The embodiment of Figure 5 takes the process of advertising parameters in the VPN by the first forwarding device in the VPN as an example.

The role of the first forwarding device covers a variety of situations. In some embodiments, the first forwarding device is the root node. For example, in the scenario shown in Figure 2, the first forwarding device is forwarding device A. In other embodiments, the first forwarding device is a leaf node. For example, in the scenario shown in Figure 2, the first forwarding device is forwarding device B or forwarding device C. In other embodiments, the first forwarding device is an intermediate node. For example, in the scenario shown in Figure 2, the first forwarding device is forwarding device D.

The first forwarding device is the endpoint of the SD-WAN tunnel. For example, in the scenario shown in Figure 2, the first forwarding device is forwarding device A, and the first forwarding device is the entry node of the SD-WAN tunnel 31. Alternatively, the first forwarding device is forwarding device D, and the first forwarding device is an egress node of the SD-WAN tunnel 31 , an ingress node of the SD-WAN tunnel 32 , and an ingress node of the SD-WAN tunnel 33 . Alternatively, the first forwarding device is forwarding device B, and the first forwarding device is the egress node of the SD-WAN tunnel 32 .

Figure 5 is a flow chart of a multicast configuration method provided by an embodiment of the present application. The method shown in Figure 5 includes the following steps S501 to step S504.

Step S501: The first forwarding device in the VPN obtains the first parameter set.

The first parameter set includes the BFR prefix of the first forwarding device and parameters used to identify the SD-WAN tunnel.

By advertising its own BFR prefix, the first forwarding device can, firstly, identify the source of the first parameter set as the first forwarding device, so that the device that receives the first parameter set can know that the first parameter set belongs to the first forwarding device. Second, if the first forwarding device needs to send other parameters subsequently, taking the first parameter set as an example, by carrying the BFR prefix in the first parameter set, it can be indicated that the parameters in the first parameter set and the parameters in the first parameter set are The first forwarding device sends it, which is equivalent to implicitly indicating that the BFR prefix has a corresponding relationship with the parameters of the SD-WAN tunnel; third, the device that receives the BFR prefix can use the BFR prefix as the destination address and calculate the outbound interface to reach the BFR prefix. and next hop, thereby generating a route to the BFR prefix, thereby establishing neighbor relationships between nodes in the BIER network and BIER forwarding paths between nodes. Fourth, this method is compatible with BIER's standard protocol and has low implementation complexity. Specifically, the message encapsulation format for publishing BIER parameters proposed in the BIER standard protocol usually carries a reachability TLV (reachability prefix TLV) in the message, such as TLV 236 defined in RFC 5308 or TLV defined in RFC 5120 237), the BFR prefix is carried in the reachability TLV, and other parameters of BIER are carried in the sub-TLV of the reachability TLV (such as BIER info sub TLV). In some embodiments of this application, the BFR prefix can be carried in the reachability TLV in the message, and other parameters other than the BFR prefix can be carried in the sub-TLV in the reachability TLV, thereby multiplexing BIER when publishing parameters. Existing message encapsulation format.

Since the BFR prefix and SD-WAN tunnel parameters are advertised together, it can indicate that there is an association between BIER and SD-WAN. That is, if you need to reach a certain BFR prefix, you must go through the SD-WAN tunnel, thereby realizing the relationship between BIER and SD-WAN. SD-WAN integration. For example, the BFR prefix of the first forwarding device is 1.1.1.1. After the first forwarding device advertises the BFR prefix: 1.1.1.1 and the parameters of the SD-WAN tunnel in the VPN, other BFRs in the VPN receive the parameters and can know when needed When forwarding data packets to a device with 1.1.1.1 as the destination prefix, the data packets need to be forwarded through the SD-WAN tunnel.

In some implementations, the BFR prefix of the first forwarding device in the first parameter set is the private IP address of the first forwarding device in the VPN. For example, configure VPN 1 on the first forwarding device, and configure the private IP address of VPN 1 as the BFR prefix of the first forwarding device. Optionally, the BFR prefix of the first forwarding device is the private IPv4 address of the first forwarding device within the VPN, or is the private IPv6 address of the first forwarding device within the VPN.

By using the private IP address in the VPN as the BFR prefix, only devices with routes that can reach the private IP address will receive the first parameter set, thus limiting the sending range of the parameter set to the VPN. For example, if the private IP address in VPN 1 is configured as the BFR prefix of the first forwarding device, then when the first forwarding device sends a parameter set containing the BFR prefix, the BFR with routes reaching VPN 1 will receive the parameter set, and BFRs with unreachable routes to VPN 1 will not receive the parameter set.

In some embodiments, the first forwarding device is a leaf node, and the first parameter set further includes the BFR-ID of the first forwarding device as the leaf node.

The first forwarding device advertises its own BFR-ID. When the first forwarding device needs to receive a multicast data packet, it can instruct the multicast data packet by setting the bit string in the packet to the BFR-ID corresponding to the first forwarding device. The message is to be forwarded to the first forwarding device. Therefore, the intermediate node in the SD-WAN network can copy and forward the message based on the bit string without Aware of the multicast group status, there is no need to build a multicast distribution tree for each multicast data flow, thus saving the storage resources of the intermediate nodes due to the multicast table entries needed to maintain the multicast distribution tree. , and also avoid the overhead caused by the establishment of a multicast distribution tree by intermediate nodes. In addition, when the destination receiver of the multicast data flow changes, the forwarding path of the multicast data flow can be flexibly updated by updating the bit string without the need to perform undo and rebuild operations on a large number of multicast distribution trees, thereby improving network performance. scalability and flexibility.

In some embodiments, the first parameter set also includes the BSL of the first network device, the max-SI of the first network device, the ID of the BIER subdomain where the first network device is located, the BIFT-ID of the first network device, and the VPN one or more of the identifiers.

The parameters used to identify SD-WAN tunnels come in many forms. For example, the above parameter used to identify the SD-WAN tunnel is in the form of a number or a series of numbers. For example, the above parameter used to identify the SD-WAN tunnel is 1, 2 or 3, or 111, 222 or 333. For another example, the above-mentioned parameter used to identify the SD-WAN tunnel is the IP address of the first forwarding device. For example, the above-mentioned parameter used to identify the SD-WAN tunnel is an IPv4 address; or, the above-mentioned parameter used to identify the SD-WAN tunnel is IPv6 address. For example, the forwarding device is configured with a loopback interface bound to the SD-WAN tunnel. The above parameter used to identify the SD-WAN tunnel is the IP address of the loopback interface bound to the SD-WAN tunnel. For another example, the forwarding device is configured with a tunnel interface bound to the SD-WAN tunnel. The above parameter used to identify the SD-WAN tunnel is the IP address of the tunnel interface bound to the SD-WAN tunnel. For another example, the above parameter used to identify the SD-WAN tunnel is a string. For example, the above parameter used to identify the SD-WAN tunnel is the name of the tunnel interface bound to the SD-WAN tunnel, or the name of the tunnel interface bound to the SD-WAN tunnel. The name of the specified tunneling protocol. For another example, the above parameter used to identify the SD-WAN tunnel is the string "SD-WAN".

In some embodiments, the parameters used to identify the SD-WAN tunnel include a first tunnel type and first information.

The first tunnel type identifies the SD-WAN tunnel. For example, the first tunnel type is in the form of a number that represents the SD-WAN tunnel. For another example, the first tunnel type is in the form of a string, such as "SD-WAN". By advertising the first tunnel type, the first forwarding device enables the receiving end of the first parameter set to know that when forwarding the data packet to the first forwarding device, the data packet must be sent through the SD-WAN tunnel.

The first information is used to determine the SD-WAN tunnel. For example, the first information includes at least one of the identification of the site where the first forwarding device is located or the CPE ID of the first forwarding device.

Alternatively, the first information is other information capable of identifying the first forwarding device in the SD-WAN network, such as TNP information of the first forwarding device. Alternatively, the first information is a label of the SD-WAN tunnel. The label of an SD-WAN tunnel is used to identify an SD-WAN tunnel. The label of the SD-WAN tunnel can be in the form of an MPLS label, an SRv6 SID, or a combination of the source site identifier, the source TNP identifier, the destination site identifier, and the destination TNP identifier.

Regarding how the first forwarding device obtains the first parameter set, the following is an example of how the first forwarding device obtains the first parameter set through four methods.

Obtaining method 1. Static configuration

For example, the network administrator performs a configuration operation on the first forwarding device through a command line or a web interface, and inputs the above first parameter set. The first forwarding device responds to the configuration operation of the network administrator and obtains the first parameter set input by the network administrator.

Obtaining method 2: Controller delivery

For example, the controller allocates a first parameter set to the first forwarding device. The controller sends the first parameter set to the first forwarding device. The first forwarding device receives the first parameter set sent by the controller. The protocols based on which the controller sends the first parameter set include, but are not limited to, network configuration protocol (NETCOF), simple network management protocol (SNMP), telemetry (telemetry), and the declarative state transfer principle ( representational state transfer, RESTful) or BGP link state (BGP link-state, BGP-LS), etc.

Obtaining method three, root node allocation

For example, the root node allocates a corresponding parameter set to each leaf node to obtain the first parameter set of the first forwarding device serving as the leaf node. The root node sends the first parameter set to the first forwarding device. The first forwarding device receives the first parameter set sent by the controller.

Obtaining method 4: The first forwarding device automatically generates the local parameter set.

For example, the first forwarding device generates the first parameter set according to a set rule or algorithm.

The above combines the four methods to comprehensively introduce the implementation method of how to obtain the first parameter set. The following is an example of how to determine the parameters that may be included in the first parameter set. The execution subject of determining the parameters described below can be the network management The operator may also be a controller, a root node, or the first forwarding device itself. This embodiment does not limit the execution subject of determining parameters.

Regarding the implementation of determining the BFR-ID, in some embodiments, each BFER in a BIER network is assigned a corresponding BFR-ID, and different BFERs in the same BIER network have different BFR-IDs. For example, if a BIER network has three BFERs, the BFR-IDs assigned to the three BFERs are 1, 2, and 3 respectively. For transit BFR, there is usually no need to assign a BFR-ID to the transit BFR. Alternatively, assign the BFR-ID of the transit BFR to 0. For BFIR, optionally, no corresponding BFR-ID is allocated to BFIR. Alternatively, configure the BFR-ID of the BFIR to 0. Alternatively, not only BFER is assigned a corresponding BFR-ID, but also BFIR is assigned a corresponding BFR-ID. In the case where a BFR-ID is assigned to a BFIR, the BFR-ID of the BFIR is different from the BFR-ID of each BFER in the same BIER network. In some embodiments, the BFR-ID is determined based on the number of BFERs in the BIER network. For example, if the number of BFERs in the BIER network is less than 64, each BFER is assigned a BFR-ID in the range of 1-64 in turn. If the number of BFERs in the BIER network is greater than 64 and less than 128, each BFER is assigned a BFR-ID in the range of 1-128 in turn.

Regarding the implementation method of determining the BSL, in some embodiments, a value is selected as the BSL from the reference values of the BSL specified in the BIER standard protocol. Currently, the reference values of BSL in BIER's standard protocol include 64, 128, 512, 1028, 2048 and 4096. In some embodiments, the topology of the BIER network is collected, the number of BFERs is determined based on the topology of the BIER network, and a value greater than the number of BFERs is selected as the BSL. For example, from the reference values of BSL specified in the BIER standard protocol, select a value that is greater than the number of BFER and closest to the number of BFER as the BSL. For example, if the number of BFERs in the BIER network is less than 64, select 64 as the BSL; if the number of BFERs in the BIER network is greater than 64 and less than 128, select 128 as the BSL.

Regarding the implementation method of determining the BFR prefix, in some embodiments, the IP address of a loopback interface is selected as the BFR prefix from the outbound interface of the first forwarding device.

Step S502: The first forwarding device sends the first parameter set within the VPN.

By deploying the first forwarding device within the VPN and limiting the sending range of the first parameter set within the VPN, the effects that can be achieved include but are not limited to the following three aspects.

First, it helps achieve tenant isolation.

In the field of data communications, tenant isolation means that the forwarding tables of different VPNs are isolated from each other, and the device maintains an independent forwarding table for each VPN. Compared with sending the parameter set on the public network, which causes the parameter set to spread to all devices on the public network, and then requires the parameters of all devices in the public network to be considered to establish a BIER forwarding table, this embodiment sends the parameter set within the VPN. It helps to establish the BIER forwarding table corresponding to the VPN. Since the parameters of external VPN devices do not need to be considered when establishing the BIER forwarding table, the BIER forwarding tables of different VPNs are independent of each other and supports tenant-based BIER topology deployment.

Second, it helps to reduce the length of the bit string and improve forwarding performance.

When deploying a BIER network in the public network, when the BFR in the public network floods the BIER information in the public network, since the traffic of each user needs to be forwarded in the public network, a large number of devices need to be deployed in the public network, and the network scale is very large. Large, resulting in the need to assign BFR-IDs to a large number of devices. Also, in order for the bit string to be sufficient to indicate whether each device has the need to receive multicast traffic, the bit string needs to be very long. If the bit string is too long, the message overhead will be large. In addition, during the BIER forwarding process, the device usually uses each bit in the bit string to be bitwise ANDed with each bit in the F-BM. Therefore, the bit string is too long. Long will also affect the forwarding performance of the device.

In this embodiment, by limiting the deployment location of BFR to the VPN, the length of the BFR-ID and the bit string can be determined based on the number of devices in the VPN. Since the number of BFRs in a VPN is relatively small, the planning of the BFR-ID can More concentrated, the length of the bit string can be shorter, thus reducing message overhead and improving the forwarding performance of the device. For example, a user rents a VPN and deploys three sites. The multicast source is at site A, and the multicast receivers are distributed at site B and site C. In this scenario, you can configure a device in site A as BFIR, a device in site B as BFER, and a device in site C as BFER. Then there are only two BFERs in the VPN and BFR -ID can be configured as 1 and 2 respectively, and the length of the bit string can be the minimum value of BSL recommended by the protocol.

Third, the scalability is better.

Since the sending range of the parameter set is limited to the VPN, when the VPN expands, for example, when a new site is added to the VPN, the parameter set of the new site does not need to be sent to the device outside the VPN. Instead, the parameters of the new site will be sent to the device outside the VPN. It only needs to be sent to the BFR deployed in the VPN, so it is easy to expand the network and the flexibility and scalability of the network are better.

Regarding the method used to send the first parameter set, in some embodiments, the first forwarding device generates a first notification message, the first notification message includes the above-mentioned first parameter set, and the first forwarding device sends the first notification within the VPN message. That is, each parameter in the above-mentioned first parameter set is published into the VPN through a message.

Regarding the protocol based on which the first parameter set is sent, that is, the protocol type of the above-mentioned first advertisement message, in some embodiments, the above-mentioned first advertisement message is a BGP message. Further, the above-mentioned first notification message is, for example, a BGP update message.

In some embodiments, the first notification message includes a first address family identifier and a first parameter set. The first address family identifier includes, but is not limited to, one or more of AFI or SAFI. In some embodiments, the first address family identifier is used to identify the BGP EVPN. In other embodiments, the first address family identifier is used to identify the BGP VPN BIER. For the specific format of the first notification message, please refer to the description of Figures 8 to 10 below.

In the scenario where parameter sets are advertised between endpoint devices of an SD-WAN tunnel, the parameter set needs to cross the transmission network on which the SD-WAN tunnel is based from one site to another site, and IGP or private protocols do not support cross-device establishment. In the peer relationship, when using the IGP flooding parameter set, the parameter set needs to be transmitted hop by hop within the transmission network, resulting in occupied network bandwidth. In this embodiment, BGP is used to advertise the first parameter set. Since BGP allows the establishment of peer relationships across devices, that is, two devices that are not directly connected at the IP layer can establish a peer relationship through TCP and then transfer parameters based on the peer relationship. Therefore, the parameter set can cross the transmission network from one site to another site, thereby reducing the bandwidth occupied by the notification parameters on the transmission network and improving performance. In addition, since BGP provides a wealth of path attributes, in some optional embodiments of this application, path attributes can be used to implement functions such as receiving and sending control parameters, thereby adapting to richer scenarios.

In the scenario of advertising parameters between devices in a VPN, since the two address families of BGP EVPN and BGP VPN BIER are used to support advertising information within the VPN or private network information, BGP EVPN and BGP VPN are used BIER is used to notify the above first parameter set, which matches the purpose defined by the standard protocol for BGP EVPN and BGP VPN BIER, and has good compatibility.

Regarding the packet encapsulation format based on which the first parameter set is sent, in some embodiments, the above-mentioned first notification message includes an NLRI field and one or more path attribute fields, and the NLRI field carries the BFR prefix and the VPN's Identifies one or more of them. One or more path attribute fields carry one or more of BFR-ID, BSL, max-SI, BIER subdomain ID, BIFT-ID, and SD-WAN tunnel parameters. Multiple. Further, the above-mentioned path attribute is, for example, a BGP transitive path attribute (BGP transitive path attribute). Further, the above path attributes are, for example, BGP extended community attributes.

In some embodiments, BIER-related parameters and SD-WAN tunnel parameters are respectively carried through different path attribute fields. For example, the above-mentioned first notification message includes a first extended community attribute field, a second extended community attribute field, and a third extended community attribute field. The first extended community attribute field includes BFR-ID, BSL, max-SI, and subdomain-ID. and one or more BIFT-IDs, the second extended community attribute field includes the first tunnel type, and the third extended community attribute field includes the first information. The first extended community attribute field is, for example, a BIER service encapsulation attribute field. The second extended community attribute field is, for example, an SD-WAN encapsulation attribute field. The third extended community attribute field is, for example, the SD-WAN color attribute field.

The above step S502 illustrates how a forwarding device sends its own parameter set to another forwarding device in the VPN to which it belongs. In some embodiments, the forwarding device uses a flooding method to send parameters in the VPN. set. For example, the first forwarding device not only sends the first parameter set of its own device within the VPN, but if the first forwarding device receives parameter sets from other BFRs in the VPN, the first forwarding device also sends the parameter sets of other BFRs within the VPN. . For another example, the first forwarding device not only sends its first parameter set to the second forwarding device in the VPN, but also sends the first parameter set to all other BFRs in the VPN except the first forwarding device itself and the second forwarding device. By sending parameter sets by flooding, each BFR in the VPN can obtain the parameter sets of all BFRs in the VPN, so that the parameter sets of all BFRs in the VPN can obtain the topology of the BIER network in the VPN, which facilitates calculation from this node to the BIER network. The BIER forwarding path of any BFR in the VPN can be used to calculate the BIER forwarding path within the VPN.

Step S503: The second forwarding device in the VPN receives the first parameter set in the VPN.

The first forwarding device and the second forwarding device are located in the same VPN. The roles of the first forwarding device and the second forwarding device include various situations. In some embodiments, the first forwarding device is a root node, and the second forwarding device is an intermediate node or a leaf node. In other embodiments, the first forwarding device is a leaf node, and the second forwarding device is a root node or an intermediate node. In some embodiments, the first forwarding device and the second forwarding device are intermediate nodes with two different hops. This embodiment does not limit the roles of the first forwarding device and the second forwarding device.

Step S504: The second forwarding device obtains the first correspondence based on the first parameter set.

The first correspondence relationship is used to forward multicast data packets whose destination leaf nodes include the first forwarding device. For example, the first corresponding relationship is an entry in the BIFT in the second forwarding device. For another example, the first corresponding relationship is an entry in the BIRT on the second forwarding device.

In some embodiments, the first correspondence includes an F-BM matching the BFR-ID of the first forwarding device and a parameter identifying the SD-WAN tunnel. Optionally, the first corresponding relationship also includes a next hop that matches the BFR-prefix of the first forwarding device.

The form of the F-BM matched by the BFR-ID of the first forwarding device is, for example, a bit string. For example, the bit corresponding to the BFR-ID of the first forwarding device in the F-BM is set.

The data form of the next hop matching the BFR-prefix of the first forwarding device includes multiple implementation methods. For example, the next hop in the first correspondence that matches the BFR-prefix of the first forwarding device includes the identity of the site where the next hop is located, the CPE ID of the next hop, and the number of users who reach the next hop on the second forwarding device. Any one or a combination of the first outbound interface and the second outbound interface of the next hop.

The first outgoing interface is the next-hop communication interface on the second forwarding device that matches the BFR-prefix of the first forwarding device. The first outgoing interface is, for example, an interface bound to the SD-WAN tunnel. For example, the first outbound interface is the loopback interface bound to the SD-WAN tunnel on the second forwarding device, or the tunnel interface bound to the SD-WAN tunnel on the second forwarding device. For another example, the first outbound interface is the TNP corresponding to the SD-WAN tunnel on the second forwarding device. The second outgoing interface is an interface that communicates with the second forwarding device on the next hop that matches the BFR-prefix of the first forwarding device. The second outgoing interface is, for example, an interface bound to the SD-WAN tunnel. For example, the second outbound interface is the loopback interface bound to the SD-WAN tunnel on the next hop. Another example is the tunnel interface bound to the SD-WAN tunnel on the next hop. Another example is the tunnel interface bound to the SD-WAN tunnel on the next hop. Corresponding TNP.

The field where the next hop matching the BFR-prefix of the first forwarding device is located in the first correspondence relationship includes multiple methods. Optionally, the first corresponding relationship includes a BFR-NBR field, and the BFR-NBR field includes the next hop matching the BFR-prefix of the first forwarding device. Alternatively, the first correspondence relationship includes a BFR-NBR field and a first field. The BFR-NBR field includes the BFR-prefix of the next hop that matches the BFR-prefix of the first forwarding device. The first field includes the BFR-prefix of the next hop that matches the BFR-prefix of the first forwarding device. The next hop matched by BFR-prefix. For example, the first field has the field name Next Hop.

For example, the BFR-ID of the first forwarding device is 2, the BFR prefix of the first forwarding device is 10.1.1.1, and the value of the parameter identifying the SD-WAN tunnel is SD-WAN. The second forwarding device subscribes to the route according to the BFR prefix of the first forwarding device and determines that the next hop to the first forwarding device is the third forwarding device. The third forwarding device is located in site 3, and the site ID of site 3 is 333. The CPE ID of the third forwarding device is 10.3.3.3. In addition, the second forwarding device determines that the F-BM matching the BFR-ID of the first forwarding device is 0010.

In this example, the second forwarding device generates entries in BIFT including, for example, the entries shown in Table 1 below or Table 2 shows the entries. Table 1 and Table 2 are both examples of the first correspondence relationship. The meaning of Table 1 is that if the bit string in the received message is not all 0 after ANDing with F-BM (0010), it needs to pass SD -The WAN tunnel forwards the packet to the next hop with site ID 333. The meaning of Table 2 is that if the bit string in the received message is not all 0 after being ANDed with F-BM (0010), it needs to be forwarded to the next hop with CPE ID 10.3.3.3 through the SD-WAN tunnel. message.

Table 1

Table 2

The length of F-BM in the above table is 4 for simplification. The length of F-BM is usually equal to the length of the bit string. The length of F-BM on the device shall be subject to actual conditions.

Optionally, the first correspondence relationship also includes an identifier of the VPN where the first forwarding device is located. For example, the above-mentioned first parameter set also includes an identifier of the VPN where the first forwarding device is located, and the second forwarding device generates the above-mentioned first correspondence relationship according to the identifier of the VPN. For example, if the identifier of the VPN where the first forwarding device is located is 1, then the second forwarding device generates entries in BIFT including, for example, the entries shown in Table 3 below or the entries shown in Table 4 below. Tables 3 and 4 are examples of the first correspondence. The meaning of Table 3 is that if the received message includes the identifier of VPN 1 (1), and the bit string in the message is consistent with F-BM (0010 ) phase and is not all 0, then the packet needs to be forwarded to the next hop with site ID 333 through the SD-WAN tunnel. The meaning of Table 4 is that if the received message includes the identifier of VPN 1 (1), and the bit string is not all 0 after being ANDed with F-BM (0010), then it needs to be sent to the CPE with ID 10.3 through the SD-WAN tunnel. .3.3 forwards the packet to the next hop. Alternatively, the second forwarding device does not add the identification of the VPN to the first corresponding relationship, but determines the inbound interface bound to the VPN on the second forwarding device, and adds the first corresponding relationship to the inbound interface bound to the VPN. in the corresponding routing table.

table 3

Table 4

Optionally, the first corresponding relationship also includes one of the BSL of the first forwarding device, the max-SI of the first forwarding device, the ID of the BIER subdomain where the first forwarding device is located, and the BIFT-ID of the first forwarding device, or Multiple.

In the method provided in this embodiment, the forwarding device can indicate the association between BIER and SD-WAN by advertising the BFR prefix and the parameters used to identify the SD-WAN tunnel in the VPN. That is, if a certain BFR prefix needs to be reached, , it has to go through the SD-WAN tunnel, so it is helpful to forward the data packet based on BIER in SD-WAN, so that the intermediate node in the SD-WAN network can realize the packet routing based on the bit string setting in the packet. Copy and forward without being aware of the multicast group status or building a multicast distribution tree for each multicast data flow.

The configuration of the VPN BIER layer has been described above through the embodiment of Figure 5. The configuration of the multicast private network layer will be illustrated below with an example.

The configuration of the multicast private network layer involves the process of control plane interaction between the root node and leaf nodes. The root node interacts with the leaf nodes to learn which destination leaf nodes the multicast data stream needs to be sent to. The root node combines the BFR-IDs of the destination leaf nodes to obtain the bit string corresponding to the specified multicast source group information. Realize the establishment of VPN BIER tunnel.

The so-called establishment of a VPN BIER tunnel means that the root node obtains the correspondence between the multicast source group information, the tunnel type identifying the VPN BIER tunnel, and the bit string. After obtaining this correspondence, when receiving a multicast data message containing multicast source group information, the root node obtains the tunnel type and bit string that identifies the VPN BIER tunnel by looking up the correspondence. The tunnel type of the VPN BIER tunnel determines that multicast data packets are to be forwarded on the path of the VPN BIER type. According to the bit string, the BIER forwarding process is executed to guide the multicast data packets to the VPN BIER tunnel.

Furthermore, since the leaf node notifies the root node of the multicast source group information and BFR-ID together, the signaling interaction process between the leaf node and the root node is simplified, and the root node and the leaf node save time in processing and sending and receiving control plane messages. It also saves the network bandwidth occupied by transmitting control plane messages in the public network.

Specifically, in traditional multicast VPN technology (such as NG MVPN), when a leaf node receives a join message from a multicast receiver, first, C-multicast routing will be exchanged between the leaf node and the root node, so that the root node The node learns which destination leaf nodes the multicast data flow corresponding to the specified multicast source group information needs to be sent to. After that, the root node and the leaf node pass the BIER parameters (BFR-ID, BFR-prefix and subdomain identification) through the interaction Intra-AS I-PMSI A-D route, S-PMSI A-D route and leaf A-D route; after that, the root node passes the BIER parameter according to the leaf A-D route. The BIER parameters in A-D route establish the BIER forwarding path.

Analysis of this signaling interaction process shows that C-multicast routes are required to carry multicast source group information but are not required to carry BIER parameters, and leaf A-D routes are required to carry BIER parameters but usually do not carry multicast source group information. Because C-multicast routing, Intra-AS I-PMSI A-D route, S-PMSI A-D route and leaf A-D route are implemented by transmitting BGP Update messages respectively in the public network. The root node needs to exchange BGP Update messages carrying BIER parameters and BGP Update messages carrying multicast source group information with leaf nodes respectively in order to obtain the information required to establish a BIER forwarding path (multicast source group information and BIER parameters). , resulting in high overhead in processing and sending and receiving messages. In the public network, BGP Update messages carrying BIER parameters and BGP Update messages carrying multicast source group information must be transmitted successively, which also results in the occupied bandwidth resources being large. In some optional embodiments of this application, after receiving the join message, the leaf node transmits the multicast source group information and BIER parameters to the root node through the same notification message, which is equivalent to establishing the BIER forwarding path. The required information (multicast source group information and BIER parameters) are notified to the root node, so the root node and leaf nodes do not need to separately interact with Intra-AS I-PMSI A-D route, S-PMSI A-D route and leaf A-D route for transmission. BIER parameters, thereby saving signaling overhead and bandwidth resources caused by interacting with Intra-AS I-PMSI A-D route, S-PMSI A-D route and leaf A-D route.

The following is an example of the parameter configuration of the multicast private network layer and the process of obtaining the corresponding relationship through the embodiment shown in Figure 6. The embodiment of Figure 6 takes the process of advertising parameters from the first forwarding device in the VPN to the second forwarding device in the VPN as an example. describe. In the embodiment shown in Figure 6, the first forwarding device is a leaf node, the second forwarding device is a root node, and the first forwarding device and the second forwarding device are in the same VPN.

Figure 6 is a flow chart of a multicast configuration method provided by an embodiment of the present application. The method shown in Figure 6 includes the following steps S601 to S604.

Step S601: The first forwarding device in the VPN obtains the second parameter set.

The second parameter set includes multicast source group information, the BFR-ID of the first forwarding device, and the second tunnel type.

The multicast source group information is used to identify the multicast group corresponding to the multicast data flow, and optionally also identifies the multicast source of the multicast data flow. In some embodiments, the multicast source group information includes a multicast source address and an address of the multicast group. In other embodiments, the multicast source group information includes the address of the multicast rendezvous point (RP) and the address of the multicast group.

Regarding the method of obtaining multicast source group information, in some embodiments, the first forwarding device receives a join message from a multicast receiver within the VPN. The first forwarding device obtains the multicast source group information from the join message. The join message includes multicast source group information. The above-mentioned join message is, for example, an IGMP message, such as a member report message in IGMP, or a PIM message. In some other embodiments, the first forwarding device receives a leave message from the intra-VPN multicast receiver, where the leave message includes multicast source group information.

The second tunnel type is used to identify the tunnel between the first forwarding device and the first forwarding device as a VPN BIER tunnel. For example, the second tunnel type is a string, such as "VPN BIER", or a number that identifies the VPN BIER tunnel. Optionally, the first forwarding device obtains the second tunnel type according to the control plane configuration.

Optionally, the second parameter set also includes the BFR prefix of the first forwarding device.

Optionally, the second parameter set also includes one or more of the max-SI of the first forwarding device, the ID of the BIER subdomain where the first forwarding device is located, and the BSL of the first forwarding device.

Optionally, the second parameter set also includes an identifier of the VPN where the first forwarding device is located.

Optionally, the second parameter set also includes the identity of the site where the second forwarding device as the root node is located or the CPE ID of the second forwarding device.

Step S602: The first forwarding device in the VPN sends the second parameter set to the second forwarding device in the VPN.

In some embodiments, the first forwarding device generates a second notification message, the second notification message includes a second parameter set, and the first forwarding device sends the second notification message to the second forwarding device. The second advertisement message includes a second address family identifier and a second parameter set. The second address family identifier is used to identify NG MVPN or BGP EVPN. The second address family identifier includes, but is not limited to, one or more of AFI or SAFI. In some embodiments, the second address family identifier is used to identify the NG MVPN. In other embodiments, the second address family identifier is used to identify the BGP EVPN. For the specific format of the second notification message, please refer to the description of Figures 12 to 17 below.

For example, the second advertisement message includes PTA attributes and virtual router forwarding router import VRI (virtual router forwarding router import, VRF router import, VRI) attributes. The PTA attributes include the second tunnel type, the identity of the VPN where the first forwarding device is located, the BFR-ID of the first forwarding device, the max-SI of the first forwarding device, and the ID of the BIER subdomain where the first forwarding device is located. and the BSL of the first forwarding device. VRI attributes include the identity of the VPN, the identity of the site where the second forwarding device is located, or the CPE ID of the second forwarding device. Optionally, the PTA attribute includes an MPLS label field, and the MPLS label field includes the identification of the VPN.

Step S603: The second forwarding device receives the second parameter set within the VPN.

Step S604: The second forwarding device obtains the second correspondence based on the second parameter set.

In some embodiments, the second corresponding relationship includes multicast source group information, a second tunnel type, and a first bit string matching the BFR-ID of the first forwarding device. For example, the second correspondence relationship is shown in Table 5 below.

table 5

In some embodiments, the second correspondence includes entries in two separate tables. For example, the second correspondence relationship includes a fourth correspondence relationship and a fifth correspondence relationship. The fourth correspondence is an entry in the multicast forwarding table on the second forwarding device, and the fourth correspondence includes multicast source group information and the second outbound interface on the second forwarding device. The second outbound interface is a virtual outbound interface. The fifth corresponding relationship is the forwarding table bound to the second outbound interface. The fifth corresponding relationship includes the second outbound interface, the second tunnel type, and the first bit string matching the BFR-ID of the first forwarding device. For example, please refer to Table 6 and Table 7 below. Table 6 is a specific example of the fourth correspondence relationship, and Table 7 is a specific example of the fifth correspondence relationship. The meaning of Table 6 is that when a multicast data packet is received, if the multicast source address in the multicast data packet is S1 and the multicast group address is G1, the multicast data packet must be forwarded through interface 1. Interface 1 is a virtual outbound interface, and interface 1 is used to iterate to Table 7. The meaning of Table 7 is that when the outgoing interface is found to be interface 1, multicast data packets must be forwarded through the path with tunnel type VPN BIER based on bit string 0111.

Table 6

Table 7

In the method provided by this embodiment, leaf nodes carry BIER parameters when announcing joining or exiting, so that the root node can use BIER parameters to establish a VPN BIER tunnel.

The above has introduced the configuration of the control plane. The following is an example of the process of processing data packets based on the above control plane configuration.

Figure 7 is a flow chart of a method for processing multicast data packets provided by this application. The interactive subjects of the method shown in Figure 7 include multicast sources, root nodes, intermediate nodes, leaf nodes and multicast receivers. The multicast source, root node, intermediate node, leaf node, and multicast receiver are located in the same VPN. The root node is located at the first site within the VPN, the intermediate node is located at the second site within the VPN, and the leaf node is located at the third site within the VPN. The first SD-WAN tunnel exists between the root node and the intermediate nodes. There is a second SD-WAN tunnel between the intermediate node and the leaf node. In other words, the 2 endpoints of the first SD-WAN tunnel are the root node and the intermediate node. The 2 endpoints of the second SD-WAN tunnel are the intermediate node and the leaf node.

The method shown in Figure 7 includes the following steps S700 to S706.

Step S700: The multicast source sends the first multicast data message.

For example, the multicast source is inside a VPN. For another example, the multicast source is located on the public network, and the multicast source sends the first multicast data packet through the outbound interface bound to the VPN, so that the first multicast data packet reaches the BFIR.

Step S701: The BFIR in the first site in the VPN receives the first multicast data packet.

The first multicast data packet includes multicast source group information. For example, the source address in the first multicast data packet includes the multicast Source address, the destination address in the first multicast data packet includes the multicast group address.

Step S702: BFIR obtains the second multicast data packet based on the first multicast data packet.

The second multicast data packet is a data packet obtained by encapsulating the first multicast data packet through BIER encapsulation and SD-WAN tunnel encapsulation.

The second multicast data packet includes a first packet header, a second packet header and a payload of the first multicast data packet. The first header refers to the header required to be carried in SD-WAN tunnel encapsulation. The second header refers to the header required to be carried in BIER encapsulation. By encapsulating the first packet header, the multicast data packet can be forwarded from one endpoint of the SD-WAN tunnel across the transmission network to the other endpoint of the SD-WAN tunnel. By encapsulating the second packet header, the multicast data packet can reach the next hop BFR from one hop BFR. Since it carries both the first header and the second header, it is equivalent to adding two layers of tunnel encapsulation to the multicast data packet. Therefore, the multicast data packet can be transmitted through the BFR as one end of the SD-WAN tunnel. network, reaching the BFR as the other endpoint of the SD-WAN tunnel.

The following is an example of the first header and the second header in the second multicast data message. For implementation details of the encapsulation format of the second multicast data message, please refer to the following title "Multicast Data Message" Description after "Packaging Format".

1. The first message header

The first packet header can be any type of IP overlay tunnel header. For example, the first packet header includes a tunnel header and an IP header. The IP header is encapsulated in the outer layer of the tunnel header and is used for hop-by-hop forwarding within the transmission network on which the SD-WAN tunnel is based through IP routing.

The type of the first header includes various situations. For example, the first packet header includes a GRE extension header and an IP header. For another example, the first message header includes a GRE header and an IP header. For example, the first packet header includes a VXLAN header and an IP header. For example, the first packet header includes a VXLAN-GPE header and an IP header. For example, the first packet header includes a GENEVE header and an IP header. The part of the first packet header other than the IP header may also be called the SD-WAN header. For more details on the format of the first header, please refer to the description after the title "SD-WAN Header" in the following text.

The first message header includes SD-WAN related parameters. For example, the first header in the second multicast data packet contains the IP addresses of the two endpoint devices of the first SD-WAN tunnel, namely the IP address of the BFIR and the IP address of the transit BFR. For example, the first message header includes a source address field and a destination address field. The source address field in the first packet header includes the IP address of the BFIR. The destination address field in the first packet header includes the IP address of the transit BFR. For example, BFIR establishes a first SD-WAN tunnel through the first WAN interface and the second WAN interface of transit BFR. The source address in the first packet header includes the IP address of the first WAN interface of the BFIR. The destination address in the second packet header includes the IP address of the second WAN interface of the transit BFR.

Since the destination address field of the first header in the second multicast data packet carries the IP address of the transit BFR, when the packet is transmitted within the transmission network based on the first SD-WAN tunnel, the device in the transmission network is based on The IP address of the transit BFR uses IP routing to forward the second multicast data packet to the transit BFR hop by hop, allowing the second multicast data packet to traverse the transmission network.

In some embodiments, the first header in the second multicast data packet contains the IPv4 addresses of the two endpoint devices of the first SD-WAN tunnel, for example. The source address field in the first packet header includes the IPv4 address of the BFIR. The destination address field in the first packet header includes the IPv4 address of the transit BFR. In this way, the scenario where the transport network on which the first SD-WAN tunnel is based is supported is an IPv4 network, so that each IPv4 node in the transport network can be configured according to the transit BFR. The IPv4 address can forward the second multicast data packet to the transit BFR.

In some embodiments, the first header in the second multicast data packet contains the IPv6 addresses of the two endpoint devices of the first SD-WAN tunnel. For example. The source address field in the first packet header includes the IPv6 address of the BFIR. The destination address field in the first packet header includes the IPv6 address of the transit BFR. In this way, the scenario where the transmission network based on the first SD-WAN tunnel is an IPv6 network is supported, so that each IPv6 node in the transmission network can forward the second multicast data packet to the transit based on the IPv6 address of the transit BFR. BFR. The endpoint of the SD-WAN tunnel is within the site. For example, the two endpoint devices of the first SD-WAN tunnel are the BFIR in site 1 and the transit BFR in site 2.

When encapsulating the first packet header for BFIR, how does BFIR obtain the IP address of the transit BFR that the first packet header needs to carry? In some embodiments, BFIR uses the parameters used to identify the first SD-WAN tunnel and the third Corresponding relationship, obtain the IP address of transit BFR. For example, BFIR uses the parameter used to identify the first SD-WAN tunnel as an index, queries the third correspondence relationship, and obtains the destination IP address corresponding to the parameter used to identify the first SD-WAN tunnel as the first packet header. Destination IP address.

The third correspondence saved by BFIR includes parameters used to identify the first SD-WAN tunnel and the IP address of the transit BFR. For example, the third corresponding relationship includes the site ID of the transit BFR and the IP address of the transit BFR. For another example, the third corresponding relationship includes the CPE ID of the transit BFR and the IP address of the transit BFR. For another example, the third corresponding relationship includes the label of the first SD-WAN tunnel and the IP address of the transit BFR.

Take the parameter used to identify the first SD-WAN tunnel as the site ID of the transit BFR as an example. For example, the transit BFR is located at the second site, and the site ID of the second site is 2. The third corresponding relationship is as shown in Table 8 below, BFIR According to the site ID of 2 and querying Table 8, the source IP address is 10.5.5.6 and the destination IP address is 10.1.1.1. Therefore, BFIR fills in the source IP address of 10.5.5.6 in the first packet header. Fill in the destination IP address in the header with 10.1.1.1.

Table 8

Take the parameter used to identify the first SD-WAN tunnel as the CPE ID of the transit BFR as an example. For example, BFIR obtains the IP address of the transit BFR based on the CPE ID of the transit BFR and the third corresponding relationship. For example, the CPE ID of transit BFR is 10.2.2.2, and the third corresponding relationship is shown in Table 9 below. Based on the CPE ID of 10.2.2.2, BFIR queries Table 9 and obtains the source IP address as 10.5.5.6 and the destination IP address as 10.1. 1.1, so BFIR fills in 10.5.5.6 as the source IP address in the first packet header, and fills in 10.1.1.1 as the destination IP address in the first packet header.

Table 9

Taking the parameter used to identify the first SD-WAN tunnel as the label of the first SD-WAN tunnel as an example, for example, the BFIR obtains the IP address of the transit BFR based on the label of the first SD-WAN tunnel and the third corresponding relationship. For example, the label of the first SD-WAN tunnel is 201, and the third corresponding relationship is shown in Table 10 below. According to BFIR, if the label of the first SD-WAN tunnel is 201, and query Table 10, the source IP address is 10.5.5.6, and the destination IP address is 10.5.5.6. The IP address is 10.1.1.1, so BFIR fills in 10.5.5.6 as the source IP address in the first packet header, and fills in 10.1.1.1 as the destination IP address in the first packet header.

Table 10

Regarding how BFIR determines to encapsulate the first packet header, or how to determine to forward the received multicast data packet through the SD-WAN tunnel, optionally, BFIR determines the first bit string matched based on the BFR-ID of BFER and The first corresponding relationship is to obtain parameters identifying the first SD-WAN tunnel. Based on the parameters identifying the first SD-WAN tunnel, BFIR determines that the multicast data packet is to be forwarded through the first SD-WAN tunnel, or that it is to be iterated to the first SD-WAN tunnel, so BFIR encapsulates the above-mentioned first packet header. and the steps of querying the third corresponding relationship. For example, BFIR uses the first bit string to query BIFT, and uses the first bit string to perform AND operations with the F-BM in each entry in BIFT. If the result of the AND operation between F-BM and the first bit string in an entry in BIFT is not all 0, that is, the first bit string hits an entry in BIFT, then BFIR continues to read F-BM in the entry. The outbound interface and next hop corresponding to the BM are obtained from the outbound interface or next hop corresponding to the F-BM, and the above parameters identifying the first SD-WAN tunnel are obtained.

For example, the first bit string obtained by BFIR is 0110. BFIR uses the first bit string to query Table 1 above and determines that the first bit string 0110 is not all 0 after the AND of F-BM0010 in Table 1. Then continue reading the table. For the outbound interface and next hop in 1, BFIR determines that the outbound interface is "SD-WAN" and the next hop is the site ID "333" of site 3. Then BFIR queries the third corresponding relationship based on the site ID "333" of site 3. .

How BFIR obtains the first bit string matching the BFR-ID of BFER can be referred to the description below.

In some embodiments, the first packet header also includes an identifier of the VPN. For how the first packet header carries the VPN identifier, please refer to the description after the title "SD-WAN Header" below. Since the first packet header carries the VPN identifier, firstly, it identifies which VPN the multicast data packet belongs to, so that BFER can find the multicast routing table in the corresponding VPN and forward the packet, which in turn helps tenant isolation; secondly, it identifies which VPN the multicast data packet belongs to. Second, there is no need to carry the upstream VPN label in the second packet header, thus avoiding the limitations caused by carrying VPN labels. For example, it is only applicable to MPLS networks due to carrying VPN labels.

Regarding how BFIR obtains the identity of the VPN, in some embodiments, BFIR obtains the identity of the VPN based on the multicast source group information and the second corresponding relationship. For example, the second correspondence not only includes multicast source group information, the second tunnel type, and the first bit string matching the BFR-ID of BFER, but also includes the identity of the VPN. BFIR obtains the identity of the VPN by searching for the second correspondence. . Alternatively, BFIR does not obtain the VPN identity by searching for the corresponding relationship, but establishes the binding relationship between the incoming interface and the VPN. BFIR determines the identity of the VPN bound to the interface based on the interface that receives the first multicast data packet.

2. The second message header

The second message header can be any message header carrying a bit string in BIER encapsulation. For example, the second message header includes, but is not limited to, any one of the BIER header, BIERv6 header, BIERin6 header and G-BIER header defined in RFC8296. The second message header is encapsulated in the inner layer of the first message header. For more details on the format of the second header, please refer to the description after the title "BIER header" in the following text.

The second packet header in the second multicast data packet includes the first BIER parameter. For example, the first BIER parameter includes the second bit string corresponding to the BFR-ID of the BFER. Since the second packet header carries the bit string corresponding to the BFR-ID of the BFER, the transit BFR can determine to forward the packet to the BFER based on the setting of the bit string in the second packet header.

When encapsulating the second packet header for BFIR, how does BFIR obtain the second bit string that the second packet header needs to carry? In some embodiments, BFIR matches the first bit string and the first corresponding bit string based on the BFR-ID of BFER. relationship to obtain the second bit string. The second bit string is obtained based on the first bit string and the F-BM in the first correspondence. For example, the second bit string is obtained by performing an AND operation based on the first bit string and the F-BM in the first corresponding relationship.

Regarding how BFIR obtains the first bit string matching the BFR-ID of BFER, in some embodiments, BFIR obtains the multicast source group information from the first multicast data message. BFIR obtains the first bit string based on the multicast source group information and the second corresponding relationship. The second corresponding relationship includes multicast source group information, a second tunnel type, and a first bit string matching the BFR-ID of the first forwarding device.

The process of obtaining the second bit string described above is implemented, for example, by two table lookups. For example, first search the multicast forwarding table to obtain the first bit string, and then search the BIFT to obtain the second bit string. As an example, the multicast source address in the first multicast data packet is S1, and the multicast group address is G1. BFIR searches the multicast forwarding table based on the multicast source group information (S1, G1). BFIR determines that (S1, G1) hits the entry in the multicast forwarding table as shown in Table 5. Therefore, BFIR further searches for the entry in BIFT based on the first bit string 0111 in Table 5. BFIR is ANDed with the F-BM in BIFT based on the first bit string 0111 to obtain the second bit string.

Alternatively, querying BIFT and querying the multicast forwarding table on BFIR is simplified into one table lookup. For example, after finding the bit string corresponding to the multicast source group information based on the multicast source group information on BFIR, BFIR uses the bit string corresponding to the multicast source group information as the bit string to be encapsulated into the second packet header, omitting the bit string corresponding to the multicast source group information. Steps to search for BIFT in the bit string corresponding to the multicast source group information. Alternatively, BFIR does not obtain the bit string to be encapsulated into the second message header by looking up a table, but generates the bit string to be encapsulated into the second message header when receiving the multicast data message. For example, BFIR searches for the BFR-ID of each destination BFER in the destination BFER set based on the multicast source group information, generates a bit string based on the BFR-ID and bit string length of each destination BFER in the BFER set, and encapsulates the generated bit string. to the second message header.

A BFIR device may store parameters for multiple types of tunnels. For example, if the device enables multiple multicast protocols, the device may have both BIER-type tunnel parameters and PIM-type tunnel parameters. For another example, the device stores both public network BIER type tunnel parameters and VPN BIER type tunnel parameters. Regarding how to determine whether to forward multicast data packets through the VPN BIER tunnel, or how to determine whether to perform the BIER forwarding process, optionally, BFIR obtains the second tunnel type based on the multicast source group information and the second corresponding relationship. Based on the second tunnel type, BFIR determines that the tunnel type that the first multicast data packet needs to pass through is a VPN BIER tunnel, so BFIR performs the above steps of obtaining the second bit string and encapsulating the second packet header.

In some embodiments, the first BIER parameter in the second message header also includes BIFT-ID. For example, the second header in the second multicast data packet contains the BIFT-ID of the transit BFR. Since the second message header carries the BIFT-ID of the transit BFR, the transit BFR can find the corresponding BIER forwarding table based on the BIFT-ID in the second message header, so that it can match the bit string with the BIFT-ID in the BIER forwarding table. F-BM executes the BIER forwarding process.

Regarding how BFIR obtains the BIFT-ID of the transit BFR, in some embodiments, BFIR obtains the multicast source group information from the first multicast data packet. BFIR obtains the BIFT-ID of the transit BFR based on the multicast source group information and the second corresponding relationship. For example, the second correspondence includes not only the multicast source group information, the second tunnel type and the first bit string described above, but also the BIFT-ID of the transit BFR. BFIR obtains the second tunnel type by searching for the second correspondence. and the first bit string, the BIFT-ID of the transit BFR is also obtained. For another example, the second corresponding relationship not only includes The multicast source group information, second tunnel type, and first bit string described above also include the BSL of the transit BFR, the SD of the transit BFR, and the SI of the transit BFR. BFIR obtains the BSL of the transit BFR by searching for the second correspondence. , the SD of transit BFR and the SI of transit BFR, BFIR determines the BIFT-ID of transit BFR based on BSL, SD and SI.

In some embodiments, the first BIER parameter in the second message header also includes the End.BIER address. For another example, the second header in the second multicast data packet contains the End.BIER address of the transit BFR. Since the second message header carries the End.BIER address of the transit BFR, and the End.BIER address is bound to the BIER forwarding instruction saved by the transit BFR, the transit BFR uses the End.BIER address in the second message header. It can be determined that the packet should be forwarded through BIER. In addition, since the End.BIER address is in the form of an IPv6 address, the reachability of IPv6 unicast routing can be used to span IPv6 nodes that do not support BIER forwarding.

Regarding how BFIR obtains the End.BIER address of the transit BFR, in some embodiments, BFIR obtains the multicast source group information from the first multicast data packet. BFIR obtains the End.BIER address of the transit BFR based on the multicast source group information and the second corresponding relationship. For example, the second correspondence includes not only the multicast source group information, the second tunnel type and the first bit string described above, but also the End.BIER address of the transit BFR. BFIR obtains the second tunnel by searching for the second correspondence. Type and the first bit string, the End.BIER address of the transit BFR is also obtained.

The features of obtaining the second multicast data message described above can be combined arbitrarily. As an example of a combination method, when BFIR receives the first multicast data packet, it first determines the VPN bound to the incoming interface that received the first multicast data packet and the multicast value in the first multicast data packet. Source group information, search the multicast forwarding table corresponding to the VPN (second correspondence), and obtain the tunnel type, BSL, SD, SI and first bit string corresponding to the multicast source group information from the multicast forwarding table. BFIR determines that BIER forwarding is required based on the tunnel type being VPN BIER tunnel. BFIR encapsulates a second header into the first multicast data packet based on the first bit string. After that, BFIR obtains BIFT-ID based on BSL, SD, and SI. BFIR searches for the BIFT corresponding to the BIFT-ID based on the first bit string. BFIR performs an AND operation on the first bit string and the first F-BM in BIFT. BFIR determines to forward the message to the next hop corresponding to the first F-BM based on the AND of the first bit string and the first F-BM in the BIFT, and adds the bit string in the second message header. The first bit string is updated to the result of the AND of the first bit string and the first F-BM in BIFT (the second bit string). The BFIR determines that the packet is to be forwarded through the first SD-WAN tunnel based on the first F-BM corresponding to the parameter identifying the first SD-WAN tunnel in the BIFT. BFIR searches the SD-WAN tunnel connection table (third correspondence) based on the site ID, CPE ID or label of the first SD-WAN tunnel of the next hop corresponding to the first F-BM in BIFT to obtain the WAN of BFIR The IP address of the interface and the IP address of the next-hop WAN interface. BFIR encapsulates the first packet header into the outer layer of the second packet header based on the obtained IP address and VPN identifier. The source address in the first header is the IP address of the BFIR WAN interface, the destination address is the IP address of the next hop WAN interface, and carries the VPN identifier.

Step S703: BFIR sends the second multicast data message.

For example, BFIR sends the second multicast data packet through the first SD-WAN tunnel. For example, BFIR sends the second multicast data packet through the WAN interface used to establish the first SD-WAN tunnel.

Step S704: The transit BFR of the second site in the VPN receives the second multicast data packet. The second multicast data message includes a first bit string corresponding to the BFR-ID of the BFER.

For example, the transit BFR receives the second multicast data packet through the first SD-WAN tunnel. For example, the transit BFR receives the second multicast data packet through the WAN interface used to establish the first SD-WAN tunnel.

Step S705: The transit BFR obtains the third multicast data message based on the second multicast data message and the first corresponding relationship.

The third multicast data packet includes a first packet header, a second packet header and a payload of the second multicast data packet.

The first header and the second header in the third multicast data message can refer to the above description of the second multicast data message. The following focuses on the message header and the second header of the third multicast data message. The difference between the parameters carried in the header of the two multicast data packets.

The first header in the third multicast data packet contains the IP addresses of the two endpoint devices of the second SD-WAN tunnel, namely the IP address of the transit BFR and the IP address of the BFER. For example, the first message header includes a source address field and a destination address field. The source address field in the first packet header includes the IP address of the transit BFR. The destination address field in the first packet header includes the IP address of the BFER. For example, the transit BFR establishes a second SD-WAN tunnel through the third WAN interface to the fourth WAN interface of the BFER. The source address in the first header of the third multicast data packet includes the IP address of the third WAN interface of the transit BFR. The destination address in the first header of the third multicast data packet includes the IP address of the fourth WAN interface of the BFER.

Since the destination address field of the first header in the third multicast data packet carries the IP address of BFER, when the packet is transmitted within the transmission network on which the second SD-WAN tunnel is based, the devices in the transmission network are based on BFER. IP address, using IP routing, can forward the second multicast data packet to the IP address of the BFER hop by hop, enabling the third multicast data packet to traverse the transmission network.

The source address and destination address in the first header of the third multicast data packet may be IPv4 addresses or IPv6 addresses.

Optionally, the transit BFR decapsulates the first packet header in the second multicast data packet, generates a new first packet header based on the IP addresses of the two endpoint devices of the second SD-WAN tunnel, and encapsulates the generated first packet header. A message header. Alternatively, the transit BFR updates the source address and destination address of the first header in the second multicast data packet based on the IP addresses of the two endpoint devices of the second SD-WAN tunnel.

When the transit BFR encapsulates the first packet header, how does the transit BFR obtain the IP address of the BFER that the first packet header needs to carry? In some embodiments, the transit BFR uses the parameters used to identify the second SD-WAN tunnel and The third correspondence is to obtain the IP address of BFER. For example, the transit BFR uses the parameters used to identify the second SD-WAN tunnel as an index, queries the third correspondence, and obtains the destination IP address corresponding to the parameters used to identify the second SD-WAN tunnel as the first packet header. The destination IP address.

The third correspondence saved by the transit BFR includes parameters used to identify the second SD-WAN tunnel and the IP address of the BFER. For example, the third corresponding relationship includes BFER's site ID and BFER's IP address. For another example, the third corresponding relationship includes the CPE ID of BFER and the IP address of BFER. For another example, the third corresponding relationship includes the label of the second SD-WAN tunnel and the IP address of the BFER.

Take the parameter used to identify the second SD-WAN tunnel as the site ID of BFER as an example. For example, BFER is located at the third site, and the site ID of the third site is 3. The third corresponding relationship is as shown in Table 11 below. Transit BFR is based on The site ID is 3, query Table 11, and obtain the source IP address as 10.2.2.2 and the destination IP address as 10.3.3.3. Therefore, the transit BFR updates the source IP address in the first packet header to 10.2.2.2 and changes the first packet to 10.2.2.2. The destination IP address in the header is updated to 10.3.3.3.

Table 11

The second message header in the third multicast data message includes the second BIER parameter. In some embodiments, the second BIER parameter is obtained based on the first BIER parameter and the corresponding relationship saved by the transit BFR. For example, the transit BFR updates the BIER parameters originally carried in the second message header based on the BIER parameters obtained from the table lookup.

For example, the second BIER parameter includes the third bit string corresponding to the BFR-ID of the BFER. The third bit string is obtained based on the second bit string in the second header of the second multicast data message and the F-BM in the first correspondence. For example, transit BFR parses the second header in the second multicast data packet to obtain the second bit string; transit BFR searches for the first correspondence based on the second bit string, and compares the second bit string with the first correspondence. F-BM performs an AND operation to obtain the third bit string.

Regarding how the transit BFR determines to forward the received multicast data packet through the SD-WAN tunnel, optionally, the transit BFR obtains the identification of the second SD based on the second bit string matched by the BFR-ID of the BFER and the first corresponding relationship. - Parameters of the WAN tunnel. The transit BFR determines to forward the multicast data packet through the second SD-WAN tunnel according to the parameters identifying the second SD-WAN tunnel, or to iterate to the second SD-WAN tunnel, so the transit BFR performs the third corresponding query. Relationship Steps. For example, transit BFR uses the second bit string to query BIFT, and performs AND operations based on the second bit string and the F-BM in each entry in BIFT. If the result of the AND operation between F-BM in an entry in BIFT and the second bit string is not all 0, that is, the second bit string hits an entry in BIFT, then the transit BFR continues to read F in the entry. -The outbound interface and next hop corresponding to BM, obtain the above-mentioned parameters identifying the second SD-WAN tunnel from the outbound interface or next hop corresponding to F-BM.

In order to achieve tenant isolation, there may be multiple VPN forwarding tables on the transit BFR, and each forwarding table stores entries corresponding to the VPNs. For this scenario, the transit BFR can obtain the VPN identifier from the first header in the second multicast data message, and obtain the above-mentioned third bit string based on the VPN identifier and the first correspondence.

As an example, when the transit BFR receives the second multicast data packet, it first decapsulates the first packet header in the second multicast data packet, obtains the VPN identifier in the first packet header, and then parses the second packet header. Broadcast the second header in the data packet and obtain the bit string and SD in the second packet header. Then the transit BFR searches for BIFT based on the VPN identifier, uses the bit string in the second packet header to perform an AND operation with the F-BM in BIFT, and forwards the packet if the result of the AND operation is not all 0s.

Step S706, the transit BFR sends the third multicast data message.

For example, the transit BFR sends the third multicast data packet through the second SD-WAN tunnel. For example, the transit BFR sends the third multicast data packet through the WAN interface used to establish the second SD-WAN tunnel.

Step S707: The BFER of the third site in the VPN receives the third multicast data packet.

For example, BFER sends the third multicast data packet through the second SD-WAN tunnel. For example, the BFER receives the third multicast data packet through the WAN interface used to establish the second SD-WAN tunnel.

Step S708: The BFER in the third site in the VPN obtains the fourth multicast data message based on the third multicast data message.

For example, BFER decapsulates the first packet header and the second packet header in the third multicast data packet, and obtains the fourth multicast data packet.

For example, BFER first decapsulates the first packet header and obtains the VPN identifier in the first packet header. Then BFER parses the second message header and obtains the third bit string in the second message header. BFER looks for BIFT based on the VPN's identifier, using The third bit string is ANDed with the F-BM in BIFT, and it is determined that the third bit string matches the bit string corresponding to the BFR-ID of the BFER node. Then the second message header is decapsulated, and the second message header is decapsulated according to the VPN identifier and group. The source group information searches the multicast forwarding table corresponding to the VPN, obtains the outbound interface corresponding to the multicast source group information, and sends the fourth multicast data message through the outbound interface.

Step S709: BFER sends the fourth multicast data message to the multicast receiver.

The method provided in this embodiment uses a message forwarding method that combines SD-WAN and BIER multicast, so that BIER-encapsulated multicast data can traverse the transmission network (public network Internet or MPLS network) without the need for the public network to support multicast. Forward.

Encapsulation format of control plane messages

The following is an example of the packet encapsulation format based on which the notification of the first parameter set is based. The packet format described below is a specific example of the first notification packet format in the above embodiment.

Method 1: Use BGP EVPN IP prefix routing to advertise the first parameter set.

Figure 8 is a schematic diagram of a BGP EVPN IP prefix routing NLRI format provided by the embodiment of this application. The first notification message has, for example, the format shown in FIG. 8 . In the NLRI shown in Figure 8, the Route Distinguisher (RD) field includes the Route Distinguisher (RD) value configured on the L3VPN instance where BIER is deployed on the device that sends the first parameter set (that is, the VPN where the BIER network is located). The Ethernet Segment Identifier is a unique identifier defined for the connection between a PE and a CE. The IP prefix Length field includes the length of the BFR prefix configured under L3VPN. The IP prefix field includes the BFR prefix configured under L3VPN. The gateway IP address (GW IP Address) field includes the default gateway address. The MPLS label field includes the VN-ID configured for the L3VPN instance where BIER is deployed.

Method 2: Use BGP BIER VPN address family routing to advertise the first parameter set.

Figure 9 is a schematic diagram of a BGP BIER VPN prefix routing NLRI format provided by the embodiment of this application. The first notification message has, for example, the format shown in FIG. 9 . In the NLRI field shown in Figure 9, the route identifier (RD) field includes the route identifier (RD) value configured on the L3VPN instance where BIER is deployed on the device that sends the first parameter set (that is, the VPN where the BIER network is located). The IP prefix Length field includes the length of the BFR prefix within the VPN. According to RFC 8279, this value is fixed to 32 (IPv4) or 128 (IPv6). The IP prefix field includes the BFR prefix within the VPN.

Figure 10 is a specific example of the BIER service encapsulation attribute field in the first notification message. As shown in (a) of Figure 10, the BIER service encapsulation attribute field includes a sub-TLV, and the value field in the sub-TLV includes BFR-ID and sub domain-ID. The sub-TLV shown in (a) of FIG. 10 includes the sub-sub-TLV shown in (b) of FIG. 10 . sub-sub-TLV includes BSL, max-SI and BIFT-ID.

(a) in Figure 11 is a specific example of the format of the SD-WAN encapsulated extended community attribute in the first notification message. As shown in (a) of Figure 11, the SD-WAN encapsulation extended community attribute includes a tunnel type field, and the value of the tunnel type field identifies the SD-WAN tunnel. (b) in Figure 11 is a specific example of the format of the color extended community attribute in the first notification message. As shown in (b) of Figure 11, the color extended group attribute includes a color value field, and the value of the color value field is site ID or CPE ID.

The following is an example of the message encapsulation format based on which the notification of the second parameter set is based. Refer to the following methods one to three. The message format described below is a specific example of the second notification message format in the above embodiment.

Method 1: Use standard NG MVPN to advertise the second parameter set.

Deploy standard NG MVPN within the VPN. Leaf nodes use MVPN C-multicast routing to advertise overlay multicast joins to the root node. I-PMSI tunnel or S-PMSI tunnel iterates the BIER subdomain within the VPN. MVPN x-PMSI AD routes and leaf A-D routes carry the PTA field, and leaf nodes use the BIER parameters within the VPN to fill the PTA field.

For example, please refer to Figure 12, which shows a schematic diagram of the MVPN or EVPN routing VPN BIER PTA field format. The second notification message has, for example, the format shown in FIG. 12 . The key information of the PTA field in Figure 12 is filled in as follows.

The flag field includes the route identifier (RD) value of the L3VPN instance configured with BIER deployed on the device that sends the second parameter set.

tunnel type: identifies the tunnel type as VPN BIER.

MPLS label: VN-ID configured under L3VPN.

BIER subdomain identifier (sub-domain-id): Operator multicast service interface (inclusive provider multicast service interface, I-PMSI) tunnel or selective multicast service interface (selective provider multicast service interface, S-PMSI) tunnel association VPN BIER sub-domain.

BFR-ID: VPN BIER BFR-ID associated with the I-PMSI or S-PMSI tunnel.

BFR-prefix: The VPN BIER BFR-prefix address associated with the I-PMSI or S-PMSI tunnel.

Method 2: Use BGP EVPN to advertise the second parameter set.

Use extended BGP EVPN routing for Layer 3 join advertisement and tunnel establishment: x-PMSI AD routing, leaf A-D routing, or selective multicast ethernet tag route (SMET) routing. The multicast source address and multicast group address in routing NLRI are used to carry multicast source group information, and the Originator address fills in the multicast identifier of the leaf node, such as MVPN-ID or EVPN source address (EVPN source). BGP EVPN routes carry the PTA field, and the encapsulation is the same as method 1.

Figure 13 is a schematic diagram of the NLRI format of BGP EVPN S-PMSI A-D routing. Please refer to Figure 13 for the format of S-PMSI A-D routing.

Figure 14 is a schematic diagram of BGP EVPN leaf A-D routing NLRI format. The format of leaf A-D can be referred to Figure 14. The Route Key part in Figure 14 is SPMSI A-D.

Figure 15 is a schematic diagram of the NLRI format of BGP EVPN SMET routing. Please refer to Figure 15 for the format of SMET routing.

Method 3: Use the second parameter set of the new type of route advertisement extended by the NG MVPN address family.

NG MVPN address family extension adds a new type of route, which is used for C-Multicast route advertisement. Leaf-AD routing is not required. The key information of the new route is: (*,G) Keyword to add the route ) includes route identifier (RD), Source AS, RP, G and Originating Router Address; (S, G) The keywords added to the route include route identifier (RD), Source AS, S, G and Originating Router Address.

Regardless of (*,G) or (S,G), both VRI attributes and PTA (PMSI tunnel attribute) attributes need to be carried. The format of the extended route is as shown in Figure 16 or Figure 17, for example. Figure 16 is a schematic diagram of the format of the NLRI for which (*, G) is added to the route, and Figure 17 is a schematic diagram of the format of the NLRI for which (S, G) is added to the route. Extended routing adds two extended community attributes.

VRI attribute: The sent multicast route carries the VRI attribute. The contents of the VRI attribute are site ID and VNID. The value is the site ID carried by the extended community attribute of the multicast source or RP. This value does not change during BGP transmission. VNID Mark private network. The VRI attribute is used for route crossing. Only the site ID carried in the route is the same as the site ID of the upstream site. Only the upstream site can import routes into the routing table; it is used for verification when the upstream site imports routes into the multicast routing table.

The PTA field carries the subdomain identifier, BSL or BFR-ID, where the subdomain identifier, BSL or BFR-ID is used to calculate the bit string and guide the forwarding of data messages.

Encapsulation format of multicast data packets

The following is an example of the encapsulation format of the multicast data packet in the embodiment of the present application. The BIER header described below is a specific example of the second packet header, and the combination of the SD-WAN header and outer IP header described below is the first packet header. Specific examples of headers.

In some embodiments, when the multicast data packet sent by the multicast source enters the BIER network in the VPN, the root node in the BIER network adds the BIER header, SD-WAN header, and outer IP to the multicast data packet. head. When the multicast data packet reaches the BFER in the BIER network within the VPN, the leaf node decapsulates the BIER header, SD-WAN header, and outer IP header to obtain the multicast data packet.

For example, please refer to Figure 18, which is a specific example of the encapsulation format of the entire multicast data message. As shown in Figure 18, the multicast data packet includes the original multicast data packet (payload), the BIER header encapsulated in the outer layer of the original multicast data packet, the SD-WAN header encapsulated in the outer layer of the BIER header, and IP header encapsulated in the outer layer of the SD-WAN header. The following introduces each header in the multicast data packet respectively, and then gives an example of the optional parts in the multicast data packet.

1. BIER header

In the data packet encapsulation format provided by the embodiment of the present application, the BIER header can be any packet header containing a bit string. The encapsulation format of the BIER header includes multiple implementation methods. For example, the encapsulation format of the BIER header includes, but is not limited to, the BIER header that meets the encapsulation format defined by RFC8296, the BIER header in the BIERv6 encapsulation format, the BIER header in the BIERin6 encapsulation format, and the BIER header in the G-BIER encapsulation format. The following are examples of the BIER headers of these four encapsulation formats.

BIER header encapsulation format 1: BIER header that meets the encapsulation format defined by RFC8296

Figure 19 shows a schematic diagram of the encapsulation format of the BIER header that meets the definition of RFC8296. The BIER header shown in Figure 19 is a specific example of the BIER header in the multicast data packet shown in Figure 18. The meaning of each field in the BIER header shown in Figure 19 is as follows.

(1)MPLS label (MPLS label) or BIFT-ID (non MPLS label, non-MPLS label) field

When the underlying protocol that BIER is based on is MPLS, this field can include an MPLS label. The MPLS label is, for example, BIER-MPLS Label. BIER-MPLS Label refers to the label assigned based on BSL, sub-domain ID and SI, which is used to index the BIER forwarding table.

When the underlay protocol on which BIER is based is a protocol other than MPLS, this field may include the BIFT-ID used to identify the BIFT. BIFT-ID is determined based on BSL, sub-domain ID and SI.

(2)Traffic Class (TC)

The TC field is used for QoS.

(3) Label stack bottom mark (S)

The S field is a 1-bit label stack bottom identifier, which is the same as the S bit of MPLS encapsulation. For the specific use of this field, please refer to RFC3032.

(4)TTL

The TTL field is 8 bits and is used for TTL during MPLS encapsulation. For the specific use of this field, please refer to RFC3032.

(5)Nibble

The Nibble field occupies 4 bits, and the legal value is 0101. If this field of the BIER message received by BFR is not 0101, the message can be discarded.

(6)Version (ver)

The version number field occupies 4 bits and can represent the version number.

(7)BSL

The BSL field occupies 4 bits, and the value of the BSL field is, for example, 1 to 7 to represent different bit string lengths. The corresponding relationship between the value of the BSL field and the length of the bit string is as follows, for example.

When the value of the BSL field is 1, it indicates that the bit string length is 64 bits.

When the value of the BSL field is 2, it means that the bit string length is 128 bits.

When the value of the BSL field is 3, it means that the bit string length is 256 bits.

When the value of the BSL field is 4, it means that the bit string length is 512 bits.

When the value of the BSL field is 5, it means that the bit string length is 1024 bits.

When the value of the BSL field is 6, it means that the bit string length is 2048 bits.

When the value of the BSL field is 7, it means that the bit string length is 4096 bits.

(8)Entropy

The length of the Entropy field is, for example, 20 bits. Optionally, the Entropy field is used to select a path when an equivalent path exists. Optionally, packets with the same bit string and entropy value choose the same path.

(9)OAM

The length of the OAM field is, for example, 2 bits, and the default is 0. It can be used for the OAM function and does not affect forwarding and QoS.

(10) Reserved (Rsv) field

The reserved field is, for example, 2 bits, and the value of the reserved field is 0 by default.

(11)DSCP

The length of the DSCP is, for example, 6 bits, optionally indicating the priority level of the packet itself, and optionally used to determine the priority level of packet transmission.

(12)Protocol type (proto)

The protocol type field is, for example, 6 bits, and is used to identify the packet type immediately following the BIER header.

(13)BFIR ID field

The BFIR ID field occupies, for example, 16 bits, and the BFIR ID field includes the BFR-ID of the BFIR.

(14)Bit string

Each bit in the bit string corresponds to a BFR-ID of a BFER. For example, if the bit is set to 1, it means that the message should be forwarded to the corresponding BFER.

BIER header encapsulation format 2: BIER header in BIERv6 encapsulation format

In the BIERv6 encapsulation format, the outer layer of the multicast data packet is encapsulated with an IPv6 basic header and an IPv6 extension header, and the BIER header is encapsulated inside the IPv6 extension header. The IPv6 extension header containing the BIER header is also called the BIERv6 header or BIERv6 encapsulation.

The IPv6 extension header carrying the BIER header includes multiple implementation methods. Optionally, the BIER header is encapsulated inside DOH (Destination Options Header). Alternatively, the BIER header is encapsulated inside other types of IPv6 extension headers other than DOH. For example, the BIER header is packaged inside SRH or HBH.

There are many ways to carry the BIER header in the IPv6 extension header. Optionally, the BIER header is encapsulated in the options of the IPv6 extension header. For example, the BIER header is encapsulated in the DOH option. For example, DOH includes options. The options include an option type field, an option length field, and an option data field. The option data field includes a BIER header, and the option type field identifies the BIER.

Taking the BIER header encapsulated in DOH and calling the DOH containing the BIER header a BIERv6 header as an example, please refer to Figure 20. Figure 20 is a schematic diagram of a BIERv6 encapsulation format provided by this application. The BIERv6 header shown in Figure 20 is the one shown in Figure 18 A specific example of the BIER header in the multicast data packet is shown in Figure 20. The IPv6 basic header shown in Figure 20 is encapsulated in the outer layer of the BIER header and the inner layer of the SD-WAN header.

Regarding the content of the IPv6 basic header in the BIERv6 encapsulation format, the SA field in the IPv6 basic header is the source address of the VPN BIER tunnel, that is, the IP address of the BFIR within the VPN. During the forwarding of multicast data packets in the transmission network, the SA field in the IPv6 basic header optionally remains unchanged. The DA field in the IPv6 basic header is the End.BIER SID used for BIER forwarding. This address is reachable within the BIER network. In some embodiments, the BIERv6 header is the next header of the IPv6 basic header, and the value of the next header field in the IPv6 basic header is 60. 60 identifies DOH, that is, the DOH that contains the BIER header. In other embodiments, as shown in Figure 21, there are one or more IPv6 extension headers between the BIERv6 header and the IPv6 basic header, and the value of the next header field in the previous IPv6 extension header of the BIERv6 header is 60.

The meaning of each field in the BIERv6 header shown in Figure 20 or Figure 21 is as follows.

(1)Next Header

The Next Header field, for example, occupies 8 bits and is used to identify the type of the next message header.

(2)Hdr Ext Len

The Hdr Ext Len field, for example, occupies 8 bits and is used to identify the length of the IPv6 extension header, that is, the length of the BIERv6 header.

(3)Option Type

The Option Type field, for example, occupies 8 bits and is used to identify the option type as BIERv6.

(4)BIFT-ID

The BIFT-ID field occupies, for example, 20 bits and is used to uniquely identify a BIFT.

(5)Traffic Class (TC)

The TC field is used for QoS.

(6)S

The S field occupies 1 bit and is a reserved field.

(7)TTL

TTL occupies 8 bits, for example. TTL indicates the number of hops for the packet to be forwarded by BIERv6. Each time it passes through a BIERv6 forwarding node, the TTL value is reduced by 1. When the TTL is 0, the packet is discarded.

(8)Nibble

Nibble occupies 4 bits for example. The Nibble field is a reserved field, for example, filled with 0.

(9)Version

Version occupies 4 bits, for example, and identifies the version number of the BIERv6 message.

(10)BSL

(11)Entropy

(12)OAM

The length of the OAM field is, for example, 2 bits, and the default is 0. It is optionally used for the OAM function.

(13) Reserved (Rsv) field

(14)DSCP

(15)Protocol type (proto)

The protocol type field is, for example, 6 bits, and is used to identify the packet type immediately following the BIERv6 header.

(16)BFIR ID field

The BFIR ID field, for example, occupies 16 bits and is the BFR-ID of the BFIR.

(17)Bit string

BIER header encapsulation format 3: BIER header in BIERin6 encapsulation format

The BIERin6 encapsulation format encapsulates the IP header outside the BIER header, and the SA field in the IPv6 basic header includes the IP address of the BFIR within the VPN. The DA field in the IPv6 basic header includes the IPv6 link-local address of the next hop BFR, which is reachable within the BIER network.

For example, please refer to Figure 22 or Figure 23. Figure 22 and Figure 23 are both schematic diagrams of the packaging format of BIERin6. For the content of the IPv6 basic header in Figure 22, please refer to the description of BIERv6 above. In Figure 22, the BIER header is encapsulated in the inner layer of the IPv6 basic header. The value of the next header field in the IPv6 basic header indicates the BIER header.

BIER header encapsulation format 4: BIER header in G-BIER encapsulation format

G-BIER (Generalized BIER, General Bit Index Explicit Replication) is a general BIER suitable for IPv6 networks The encapsulation scheme makes adaptive modifications to the standard BIER header defined by RFC according to the characteristics of the IPv6 network, achieving better integration with IPv6.

Figure 24 is a schematic diagram of a G-BIER encapsulation format provided by an embodiment of the present application.

As shown in Figure 24, in the G-BIER encapsulation format, the outer layer of the multicast data message is encapsulated with an IPv6 basic header and an IPv6 extension header, and the BIER header is encapsulated inside the IPv6 extension header.

In the G-BIER encapsulation format, the source address in the IPv6 basic header is the multicast service source address of BFIR. The source address is generated by the prefix address of BFIR and the multicast service ID value. The prefix address of BFIR is used to identify the network location of BFIR, and the multicast service ID is used to identify different MVPN instances. During the forwarding process of multicast packets, the source address remains unchanged.

The destination address in the IPv6 basic header is the MPRA (Multicast Policy Reserved Address) used for BIER forwarding. This address is reachable within the BIER network. When the BFR receives an IPv6 packet whose destination address is the locally configured MPRA, it indicates that the packet needs to be forwarded in BIER mode.

The meaning of each field in the BIER header in the G-BIER encapsulation format shown in Figure 24 is as follows.

(1)Next Header

The Next Header field, for example, occupies 8 bits and is used to identify the type of the next header.

(2)Hdr Ext Len

The Hdr Ext Len field, for example, occupies 8 bits and is used to identify the length of the IPv6 extension header.

(3)Option Type

The Option Type field, for example, occupies 8 bits and is used to identify the option type as G-BIER.

(4)Option Length

The Option Length field, for example, occupies 8 bits and is used to identify the option length.

(5)BSL

(6)SD

The SD field occupies, for example, 8 bits, and the value of the SD field is the ID of the BIER subfield.

(7)SI

The SI field occupies, for example, 8 bits, and the value of the SI field is the set identifier to which the BFR belongs.

(8)Rsv

The Rsv field is a reserved field.

(9)TTL

The TTL field is 8 bits. The TTL field has the same meaning as the TTL in the IP packet and can be used to prevent loops.

(10) Version number (version)

The Version field occupies 4 bits, for example.

(11)Entropy

(12)OAM

(13) Reserved (Rsv) field

(14)DSCP

(15)bit string

Each bit in the bit string corresponds to a BFR-ID of a BFER.

2. SD-WAN header

In the data packet encapsulation format provided by the embodiment of this application, the SD-WAN header can be any packet header that supports L3VPN tunnel establishment. For example, the SD-WAN header includes, but is not limited to, GRE extension header or GRE header. Alternatively, the SD-WAN header can be any packet header that supports L2VPN tunnel establishment. For example, SD-WAN headers include but are not limited to Virtual Extensible Local Area Network (VXLAN) headers, headers based on VXLAN Generic Protocol Encapsulation (VXLAN-GPE) or Generic Network Virtualization Encapsulation (Generic Network Virtualization Encapsulation, GENEVE) head.

In some embodiments, the SD-WAN header includes the identification of the VPN where the BFR is located (such as VN-ID). In the case of this encapsulation format, after the BIER header (or the inner layer of the BIER header, the multicast data The outer layer of the message does not need to encapsulate the VPN label assigned by the upstream, because the VPN identifier carried in the SD-WAN header can already identify the VPN, thus helping to save message overhead.

Taking the SD-WAN header as a GRE extension header as an example, please refer to Figure 25. Figure 25 is a specific example of the encapsulation format when the SD-WAN header is a GRE extension header. The GRE extension header includes the key field and the Protocol Type field. The key field includes the VN-ID configured in the VPN bound to the SD-WAN tunnel, that is, the VN-ID of the VPN where the BFR is located. The Protocol Type field is used to identify that the encapsulation format of the inner layer of the SD-WAN header is the BIER encapsulation format. For example, when the BIER header is a BIER header that meets the encapsulation format defined by RFC8296, the Protocol Type in the GRE extension header identifies BIER. For example, when the BIER header is a BIER header in the BIERv6 encapsulation format, the Protocol Type in the GRE extension header identifies BIERv6. For example, in the case where the BIER header is a BIER header in the BIERin6 encapsulation format, the Protocol Type in the GRE extension header identifies BIERin6. For example, in the case where the BIER header is the BIER header in the G-BIER encapsulation format, the Protocol Type in the GRE extension header identifies G-BIER.

Figure 26 is a schematic diagram of another general encapsulation format of an SD-WAN header provided by an embodiment of the present application. As shown in Figure 26 The SD-WAN header includes the Type field, Length field, Protocol field and VN ID field. The Type field indicates the type of message. For example, when the value of the Type field is 1, it indicates a control packet; when the value of the Type field is 2, it indicates a data packet. The Protocol field indicates the type of data packet in the inner layer of the SDWAN header. For example, in the case where the BIER header is a BIER header that meets the encapsulation format defined by RFC8296, the Protocol field identifies the BIER. For example, in the case where the BIER header is a BIER header in the BIERv6 encapsulation format, the Protocol field identifies BIERv6. For example, in the case where the BIER header is a BIER header in the BIERin6 encapsulation format, the Protocol field identifies BIERin6. For example, in the case where the BIER header is a BIER header in the G-BIER encapsulation format, the Protocol field identifies G-BIER. The Length field indicates the length of the SDWAN header. The VN ID field indicates the ID of the VPN to which the data packet is bound, that is, the ID of the VPN where the BFR is located.

Taking the SD-WAN header as a VXLAN header as an example, please refer to Figure 27. Figure 27 is a specific example of the encapsulation format when the SD-WAN header is a VXLAN header. The VNI field in the VXLAN header includes the VPN identifier of the VPN to which the multicast data packet is bound, that is, the identifier of the VPN where the BFR is located. BIER can be indicated using the Next header field in the IPv6 basic header encapsulated in the outer layer of the VXLAN header.

Taking the SD-WAN header as a VXLAN-GPE header as an example, please refer to Figure 28. Figure 28 is a specific example of the encapsulation format of the SD-WAN header as a VXLAN-GPE header. The VNI field in the VXLAN-GPE header includes the VPN identifier of the VPN to which the multicast data packet is bound, that is, the identifier of the VPN where the BFR in the BIER network is located. The next protocol field in the VXLAN-GPE header indicates the type of data packet in the inner layer of the VXLAN-GPE header. For example, in the case where the BIER header is a BIER header that meets the encapsulation format defined by RFC8296, the Next protocol field identifies the BIER. For example, in the case where the BIER header is a BIER header in the BIERv6 encapsulation format, the Next protocol field identifies BIERv6. For example, in the case where the BIER header is a BIER header in the BIERin6 encapsulation format, the Next protocol field identifies BIERin6. For example, in the case where the BIER header is a BIER header in the G-BIER encapsulation format, the Next protocol field identifies G-BIER. The Length field indicates the length of the SDWAN header. The VN ID field indicates the ID of the VPN to which the data packet is bound, that is, the ID of the VPN where the BFR is located.

Taking the SD-WAN header as a GENEVE header as an example, please refer to Figure 29. Figure 29 is a specific example of the encapsulation format of the SD-WAN header as a GENEVE header. The VNI field in the GENEVE header includes the ID of the VPN to which the multicast data packet is bound, that is, the ID of the VPN where the BFR in the BIER network is located. The Protocol Type in the GENEVE header identifies BIER. For example, in the case where the BIER header is a BIER header in the BIERv6 encapsulation format, the Protocol Type in the GENEVE header identifies BIERv6. For example, in the case where the BIER header is a BIER header in the BIERin6 encapsulation format, the Protocol Type in the GENEVE header identifies BIERin6. For example, in the case where the BIER header is the BIER header in the G-BIER encapsulation format, the Protocol Type in the GENEVE header identifies G-BIER.

3. The outer IP header of the SD-WAN header

The source address and destination address in the outer IP header of the SD-WAN header are the IP addresses used to establish the SD-WAN tunnel. For example, if the first BFR and the second BFR establish an SD-WAN tunnel, and the first BFR wants to forward the multicast data packet to the second BFR through the SD-WAN tunnel, the multicast data packet sent by the first BFR The IP header source address of the middle and outer layers is the IP address of the WAN interface on the first BFR, that is, the IP address of the physical outgoing interface used by the first BFR when sending multicast data packets. The destination address in the outer IP header of the outer SD-WAN header is the IP address of the WAN interface on the second BFR, that is, the IP address of the physical outgoing interface used by the second BFR when receiving multicast data packets.

The IP header in the outer layer of the SD-WAN header includes but is not limited to IPv4 header or IPv6 header. Specifically, when the IP header in the outer layer of the SD-WAN header is an IPv4 header, the source address of the IPv4 header in the outer layer of the SD-WAN header is the IPv4 address of the WAN interface on the BFIR. The destination address is the IPv4 address of the WAN interface on the BFER. When the outer IP header of the SD-WAN header is an IPv6 header, the source address in the outer IPv6 header of the SD-WAN header is the IPv6 address of the WAN interface on the BFIR, and the source address in the outer IPv6 header of the SD-WAN header is The destination address is the IPv6 address of the WAN interface on the BFER.

For example, the encapsulation format of data packets includes IP header, SD-WAN header, BIER header and multicast data packets. For another example, the encapsulation format of the data packet includes an IP header, an SD-WAN header and an IPv6 packet, and the IPv6 packet includes an IPv6 header, a BIER header and a multicast data packet.

4. IPsec header and IPsec trailer

The IPsec header and IPsec trailer are optionally encapsulated parts of multicast data packets. For example, if you need to ensure the confidentiality and security of data transmitted through the SD-WAN tunnel, deploy SD-WAN over IPSec on BFIR and BFER. BFIR encapsulates the IPsec header in the outer layer of the SD-WAN header and adds it to the multicast datagram. The IPSec tail is encapsulated after the text. When SD-WAN over IPSec is not deployed on BFIR and BFER, BFIR does not need to encapsulate the IPsec header and IPSec trailer. Optionally, the IPsec header is an ESP header, and the IPsec trailer is an ESP trailer. The format of the IPsec header can be found in Figure 30.

In some embodiments of this application, methods for protecting primary and secondary traffic within the site are also provided, which will be described in detail below.

The main and backup traffic protection within the site includes the following method 1 and method 2.

Method 1: Configure different BFR-IDs and BFR prefixes for the primary CPE and backup CPE in the site.

As shown in Figure 31, multicast receiver 1 is single-homed to CPE 6, multicast receiver 2 is dual-homed to CPE 5 and CPE 6, and the access side master and backup are configured. CPE 5 and CPE 6 in site 3 are configured with different BFR-ID and BFR prefix. For example, CPE 5 in site 3 is configured with a BFR-ID of 5 and a BFR prefix of 10.5.5.5. CPE 6 in site 3 is configured with a BFR-ID of 6 and a BFR prefix of 10.6.6.6. Primary and secondary backup refers to the mutual backup of joining information between two devices in the same site. For example, after CPE 5 obtains the joining information of multicast receiver 2, CPE 5 synchronizes the joining information of multicast receiver 2 to CPE 6, so that the joining information of multicast receiver 2 is saved on both CPE 5 and CPE 6. . The link between CPE 5 and CPE 6 deploys VPN BIER over IGP. CPE 5 and CPE 6 are assigned the same BIFT-ID using SD, BSL, and SI splicing.

Method 1 includes the following steps 1 to 7.

Step 1: The multicast data packet sent to multicast receiver 1 reaches CPE 6 through the SD-WAN tunnel. After the upstream BFR in the same VPN as CPE 6 iterates the site ID, randomly select the right tunnel, or the upstream BFR in the same VPN as CPE 6 iterates the specific router ID (i.e. CPE ID), such as the loopback port of CPE 6 After receiving the IP address, the multicast data packet is sent to CPE 6. CPE 6 strips off the GRE header and BIER header, so that the multicast data packet is directly forwarded to receiver 1 after exiting the two-layer tunnel. For example, after CPE 3 receives the multicast data message in Figure 31, CPE 3 searches for BIFT based on the bit string in the multicast data message, and determines that the bit string hits the F-BM in an entry in BIFT, then CPE 3 reads The outbound interface or next hop corresponding to the F-BM in BIFT is used to obtain the site ID of site 3. After that, CPE 3 searches the SD-WAN tunnel forwarding table based on the site ID of site 3. CPE 3 hits the entry in the SD-WAN tunnel forwarding table based on the site ID of site 3, and reads the entries in the SD-WAN tunnel forwarding table that match site 3. The next hop corresponding to the site ID. site 3 The next hop corresponding to the site ID includes CPE 5 and CPE 6. CPE 3 randomly selects a next hop from CPE 5 and CPE 6, and selects CPE 6.

Step 2: The multicast data packet sent to multicast receiver 1 reaches CPE 5 through the SD-WAN tunnel. Specifically, the upstream BFR in the same VPN as CPE 5 randomly selects the left tunnel after iterating the site ID, or the upstream BFR in the same VPN as CPE 5 iterates the specific router ID (i.e. CPE ID), such as the loopback port of CPE 5 After obtaining the IP address, the multicast data packet is sent to CPE 5. After CPE 5 strips off the GRE header, it iterates the next hop to CPE 6 based on the destination BFR-ID 6 of the BIER header, and forwards it to CPE 6 via the link between CPEs in the site. After stripping off the BIER header, it searches for the MVPN customer multicast route and forwards it to the group. broadcast receiver 1.

Step 3: The multicast data packet sent to multicast receiver 2 reaches CPE 5 through the SD-WAN tunnel. Specifically, the upstream BFR in the same VPN as CPE 5 randomly selects the left tunnel after iterating the site ID, or the upstream BFR in the same VPN as CPE 5 iterates the router ID (i.e. CPE ID), such as the loopback port of CPE 5 After the IP address, the multicast data message is sent to CPE 5. After CPE 5 strips off the GRE header and BIER header, it is forwarded to multicast receiver 2 by the main link (for example, the LAN side link of CPE 5).

Step 4: The multicast data packet sent to multicast receiver 2 reaches CPE 6 through the SD-WAN tunnel. The upstream BFR in the same VPN as CPE 6 randomly selects the right tunnel after iterating the site ID, or the upstream BFR in the same VPN as CPE 6 iterates the specific router ID (i.e. CPE ID), such as the router ID of CPE 6, Send the multicast data message to CPE 6. After CPE 6 strips off the GRE header, it iterates the next hop to CPE 5 based on the destination BFR-ID 5 indicated by the bit string in the BIER header, and forwards it to CPE 5 via the link between CPEs in the site. CPE 5, after stripping off the BIER header, searches for the MVPN client multicast route and forwards it to multicast receiver 2 via the main link.

Step 5: The multicast data packet sent to multicast receiver 2 contains the bit string corresponding to the BFR-ID 6 of this node according to the BIER header. After stripping off the GRE header and BIER header, the backup path is blocked on the CPE 6 LAN side. Will not be forwarded to multicast recipients.

Step 6: After the LAN-side link failure of CPE 5 as the master device, CPE 6 becomes the master, and CPE 6 is responsible for forwarding the multicast data packets to multicast receiver 2.

Step 7: After CPE 5 as the master device fails, all multicast data packets received by the SD-WAN tunnel side reach multicast receiver 2 through CPE 6.

The switchback process is similar and will not be described in detail.

The differences between BIERv6 and the above process types are: deploying different End.BIER addresses, and deploying private network BIERv6over IGP on the link between CPE 5 and CPE 6.

Method 2: The active and standby CPEs in the site are configured with the same BFR-ID and BFR prefix.

As shown in Figure 32, multicast receiver 1 is single-homed to CPE 6, multicast receiver 2 is dual-homed to CPE 5 and CPE 6, and the access side master and backup are configured. The CPE in the site is configured with the same BFR-ID and BFR prefix. The link between CPE 5 and CPE 6 does not deploy BIER within the VPN, but deploys traditional overlay multicast, such as PIM or IGMP/MLD. Method 2 includes the following steps 1 to 3.

Step 1. Multicast data packets sent to single-homing or dual-homing receivers randomly arrive at either side of CPE 5 or CPE 6 through the upstream SD-WAN tunnel (same as method 1).

Step 2. The CPE that receives the multicast data message strips off the GRE header and BIER header and forwards it through overlay multicast. Give the peer CPE.

Step 3: The primary CPE or single-homed CPE is responsible for forwarding the multicast data packets to the LAN-side receiver.

BIERv6 is similar to the above process, except that the same End.BIER address is deployed on the primary CPE and backup CPE in the same site.

The following is an example of four examples.

Example 1

Figure 33 is a schematic diagram of the network deployment scenario of Example 1. As shown in Figure 33, the multicast source is located in the network connected to the LAN side interface of CPE100 in site 5. The multicast receiver is located in the network connected to the LAN side interface of CPE6 in site 3. The primary CPE and backup CPE in site 3 are configured with different BFR-IDs, and the primary CPE and backup CPE are configured with different BFR prefixes; VPN BIER over EVPN is used between sites to flood the BIER information of each BFR in the VPN; root node and leaf NG-MVPN implemented according to standard RFC is deployed between nodes. When a join message is received, the intra-VPN overlay multicast join information is transmitted through NG-MVPN. Example 1 includes the following steps 1 to 4.

Step 1: Underlay SD-WAN tunnel is established.

Step 1 includes the following steps (1-1) to (1-3).

Step (1-1) Deploy the SD-WAN network across the Internet or MPLS network through SD-WAN EVPN. Configure IP addresses for the WAN interfaces of each CPE in each site, and configure the IP address of the public network loopback port as the CPE ID. Use the CPE ID to establish BGP SD-WAN peers and BGP EVPN peers.

For example, the IP address of the WAN interface of CPE 5 in site 3 is configured as 10.33.33.33, and the CPE ID of CPE 5 in site 3 is configured as 33.33.33.33. The IP address of the WAN interface of CPE 6 in site 3 is configured as 10.3.3.3, and the CPE ID of CPE 6 in site 3 is configured as 3.3.3.3. The IP address of the WAN interface of CPE 4 in site 2 is configured as 10.2.2.2, and the CPE ID of CPE 4 in site 2 is configured as 2.2.2.2.

Step (1-2) Establish a DTLS management channel and a BGP control channel between the CPE and RR through the DTLS mechanism and the BGP SD-WAN address family.

Step (1-3) Establish an SD-WAN unicast service data channel (i.e. SD-WAN tunnel) between the CPE and RR through the BGP EVPN address family. Deploy L3VPN in site 5 and site 3, configure the same VN ID; both the AC interface on the LAN side and the SD-WAN tunnel interface on the WAN side are bound to this VPN.

Step 2: Overlay VPN BIER tunnel is established.

Step 2 includes the following steps (2-1) to (2-3).

Step (2-1) Deploy intra-VPN BIER on each site, and configure the intra-VPN BFR prefix and intra-VPN BFR-ID respectively. For example, the configuration of CPE5 is as follows.

Step (2-2) Deploy VPN BIER over BGP EVPN on each CPE in the VPN, and advertise the BFR prefix through the BGP EVPN IP prefix route, carrying the BIER encapsulation extended community attribute, SD-WAN encapsulation extended community attribute, and color extended community attribute. For example, the configuration of CPE5 is as follows.

Step (2-3) Each CPE uses RR to reflect the BGP EVPN BIER route to learn the BIER neighbors in the VPN, and calculate the BIER routing table with the site ID as the next hop based on the extended community attributes carried by the BGP EVPN BIER route. For example, the BIER routing table learned by CPE100 in site5 is shown in Table 12 below.

Table 12

Step 3: Join the overlay multicast.

The CPEs at each site learn their respective BFR-IDs through NG-MVPN x-PMSI routes and leaf-AD routes carrying VPN BIER type PTA attributes. Based on the multicast join message received by the LAN side interface, CPE6 in site 3 obtains the MVPN C-Multicast route and reflects it to CPE100 in site 5 through RR. CPE 100 learns the BFR-ID of CPE6 as the leaf node of the VPN BIER tunnel. Configuration examples are as follows.

Step 4: Forward multicast data packets.

Step 4 includes the following steps (4-1) to (4-3).

Step (4-1) CPE100 receives the multicast data packet in the LAN-side VPN, obtains the bit string according to the BFR-ID of the leaf node set in the VPN, encapsulates the BIER header in the multicast data packet, and searches for the bit string in the VPN. BIER forwarding table. If the next hop corresponding to the bit string in the BIER forwarding table is the site ID, use the site ID as the index to further search the SD-WAN tunnel connection table. Or, if the next hop corresponding to the bit string in the BIER forwarding table is the CPE ID, use the CPE ID as the index to further search the SD-WAN tunnel connection table. After that, the GRE header, outer IP header and MAC header are continued to be encapsulated in the outer layer of the BIER header to further forward the multicast data message. The key field in the GRE header includes the VNID configured under the VPN. If the next-hop site has a primary tunnel and a backup tunnel, one of the tunnels is randomly selected.

For example, the SD-WAN tunnel connection table of CPE100 in Site 5 is shown in Table 13 below. The source IP address in Table 13 is the IP address of the WAN interface in CPE 100, which is also the IP header encapsulated by CPE100 in the outer layer of the GRE header. Source IP address. The destination IP address in Table 13 is the IP address of the WAN interface of the CPE in the remote site that establishes the SD-WAN tunnel with CPE 100. It is also the destination IP address of CPE 100 in the IP header encapsulated in the outer layer of the GRE header.

Table 13

Step (4-2) The multicast data packet is forwarded hop by hop through IP routing according to the IP address in the outer IP header, such as IPv4 address or IPv6 address. When the multicast data packet reaches the CPE in a certain hop site, the CPE hits the corresponding SD-WAN tunnel and corresponding VPN according to the SD-WAN tunnel connection table, and further searches for the BIER forwarding table entry in the VPN. If the BFR-ID of this node does not match the F-BM in the forwarding entry, it is determined that this node is an intermediate node. After updating the bit string in the BIER header, the next hop is iterated based on BIER forwarding.

Step (4-3) After the packet reaches the leaf site, decapsulate the SD-WAN header (such as the GRE header). If the BFR-ID of the node matches the F-BM in the forwarding entry, decapsulate the BIER header and perform further searches. MVPN client multicast routing table entry forwarding within the VPN. If the BFR-ID of this node does not match the F-BM in the forwarding table, it will continue to forward the table according to the BIER in the VPN. The iterative next hop is the peer CPE in this site. After updating the bit string, GRE will no longer be encapsulated. header and forwarded directly to the peer CPE.

Example 2

Refer to Figure 33 for the network deployment scenario of Example 2. Example 2 includes the following steps 1 to 4.

Step 1: Underlay SD-WAN tunnel establishment: Same as Example 1.

Step 2: Overlay BIER VPN tunnel is established.

Use BGP BIER VPN address family routing to advertise the BFR prefix, BIER encapsulation extended community attribute, SD-WAN encapsulation extended community attribute, and color extended community attribute within the VPN.

Step 3: Overlay multicast join:

CPEs in each site learn their respective BFR-IDs through BGP EVPN IMET routing carrying PTA attributes. Based on the multicast join message received by the LAN side interface, CPE6 in site 3 obtains the BGP EVPN SMET route and reflects it to CPE100 in site 5 through RR. CPE100 learns CPE6 as the leaf node of the VPN BIER tunnel.

Step 4: Multicast data packet forwarding:

Traffic forwarding between non-leaf sites is the same as in Example 1.

When a multicast data packet reaches a leaf site, it does not matter which of the two SD-WAN tunnels it reaches the leaf site from. Any CPE in the leaf site that receives the multicast data packet will strip off the GRE header and BIER header, which is equivalent to the multicast data packet going out of a two-layer tunnel. In addition, the CPE that receives the multicast data packet will forward a multicast data packet to the opposite CPE in the same site by overlaying traditional multicast.

The primary CPE or single-homed CPE forwards the multicast data packets to the multicast receivers on the LAN side.

The above Example 1 and Example 2 can be used as the method flow in the BIER-MPLS scenario. The following is an example of the method flow in the BIERv6 scenario. See Example 3 and Example 4.

Example 3

Figure 34 is a schematic diagram of the network deployment scenario of Example 3. As shown in Figure 34, the multicast source is located in the network connected to the LAN side interface of CPE100 in site 5. The multicast receiver is located in the network connected to the LAN side interface of CPE6 in site 3. The active and backup CPEs in site 3 deploy different End.BIER addresses, BFR-IDs and BFR prefixes; VPN BIERv6over EVPN is used to flood VPN BIERv6 topology information between sites; standard NG-MVPN is deployed between the root site and leaf sites to transmit private data Network overlay multicast join information.

Step 1: Establish underlay SD-WAN tunnel. Step 1 can refer to Example 1.

Step 2: Overlay BIERv6VPN tunnel is established.

Step 2 includes the following steps (2-1) to (2-3).

Step (2-1) Deploy BIERv6 in the VPN at each site, and configure the End.BIER address, BFR prefix and BFR-ID in the VPN respectively. For example, the configuration of CPE5 in site 3 is as follows.

Step (2-2) Deploy VPN BIERv6over BGP EVPN on each CPE in the VPN, and pass the BGP EVPN IP prefix route advertisement BFR prefix carries BIER encapsulation extended community attribute, SD-WAN encapsulation extended community attribute and color extended community attribute.

For example, the configuration of CPE5 is as follows.

Step (2-3) Each CPE uses RR reflection BGP EVPN BIER routing to learn the BFR neighbors in the VPN, and calculates the BIER routing table with the site ID as the next hop (unicast routing) based on the extended community attributes carried by the route. Iterate to site ID as an example). For example, the BIER routing table learned by CPE100 in site 5 is shown in Table 14 below.

Table 14

Step 3: Join the overlay multicast, the same as instance 1.

Step 4: Forward multicast data packets.

Step 4 includes the following steps (4-1) to (4-3).

Step (4-1) When CPE100 receives the multicast data packet of the LAN-side VPN, it obtains the bit string based on the BFR-ID of the leaf node set in the VPN, encapsulates the BIER header in the multicast data packet, and searches for the BIERv6 in the VPN. BIER forwarding table. If the next hop corresponding to the bit string in the BIER forwarding table is the site ID, use the site ID as the index to further search the SD-WAN tunnel connection table. Or, if the next hop corresponding to the bit string in the BIER forwarding table is the CPE ID, then use the CPE ID as the index to further search the SD-WAN tunnel connection table shown in Table 15. After that, in the outer layer of the BIERv6 header, Continue to encapsulate the GRE header, outer IP header, and MAC header to further forward the multicast data packet. Among them, the key field in the GRE header includes the VNID configured under the VPN. If there is a primary tunnel and a backup tunnel at the next hop site, one of the tunnels is randomly selected.

Table 15

Step (4-2) The multicast data message is forwarded hop by hop based on the destination IP address in the outer IP header. After arriving at the CPE in a certain hop site, the multicast data message hits the corresponding SD-WAN decapsulation table. WAN tunnel and corresponding VPN, further search for the BIERv6 forwarding entry in the VPN. If the BFR-ID of this node does not match the F-BM in the forwarding entry, it is determined that this node is an intermediate node, and the bit string in the BIER header is updated. Afterwards, the next hop is iterated based on BIER forwarding.

Step (4-3) After the packet reaches the leaf site, the CPE in the leaf site decapsulates the SD-WAN GRE header. If the BFR-ID of this node matches the F-BM in the forwarding entry, the BIER header is decapsulated and further searches for the MVPN customer multicast routing entry in the VPN for forwarding. If the BFR-ID of this node does not match the F-BM in the forwarding entry, it will continue to forward the entry according to the BIERv6 in the VPN. The next hop of the iteration is the peer CPE in this site. After the bit string is updated, GRE will no longer be encapsulated. header and forwarded directly to the peer CPE.

Example 4

For the network deployment scenario of Example 4, please refer to Figure 34. Example 4 includes the following steps.

Step 1: Establish an underlay SD-WAN tunnel. For step 1, please refer to the description of Example 1.

Step 2: Establish overlay BIERv6VPN tunnel.

Use BGP BIER VPN address family routing to advertise the BFR prefix within the VPN, carrying BIER encapsulation extended community attributes, SD-WAN encapsulation extended community attributes, and color extended community attributes.

Step 3: Join the overlay multicast.

CPE6 in site 3 receives the multicast join message from the LAN side interface and obtains the BGP EVPN route. The route carries PTA attributes and VRI attributes and is reflected to CPE100 in site 5 through RR. CPE100 learns CPE6 as the leaf node of the VPN BIER tunnel, and calculates the bit string based on the BFR-ID carried by the PTA.

Step 4: Forward multicast data packets.

Multicast data packet forwarding between non-leaf sites is the same as Example 3.

When a multicast data packet reaches a leaf site, no matter which of the two tunnels it reaches any CPE, the CPE in the leaf site that receives the multicast data packet will strip off the GRE header and BIER header, which is equivalent to the multicast datagram. Wend out a two-story tunnel. In addition, the CPE that receives the multicast data packet will forward an original multicast data packet to the opposite CPE in the same site by overlaying traditional multicast. The primary CPE or single-homed CPE is responsible for forwarding multicast data packets to multicast receivers on the LAN side.

Figure 35 is a schematic structural diagram of a multicast configuration device 700 provided by an embodiment of the present application. The device 700 is installed on the first network device in the VPN and includes a processing unit 701 for obtaining a first parameter set. The parameter set includes the bit forwarding router prefix BFR prefix of the first network device and the parameters used to identify the software-defined wide area network SD-WAN tunnel. The first network device is the endpoint of the SD-WAN tunnel; the sending unit 702 is used to The first parameter set is sent within the VPN.

In some implementations, the sending unit 702 is configured to send the first parameter set to a second network device in the VPN, which is another endpoint of the SD-WAN tunnel; or, to route reflection The server RR sends the first parameter set, so that the RR reflects the first parameter set to the second network device in the VPN, and the second network device is the other endpoint of the SD-WAN tunnel.

In some embodiments, the sending unit 702 is configured to send a first notification message within the VPN. The first notification message includes a first address family identifier and the first parameter set. The first address family identifier is Bit-based explicit replication of BGP VPN BIER used to identify Border Gateway Protocol Ethernet Virtual Private Network BGP EVPN or Border Gateway Protocol Virtual Private Network.

In some implementations, the processing unit 701 is also used to obtain a second parameter set, which includes multicast source group information, the BFR prefix of the first network device, and a second tunnel type. The second tunnel The type is used to identify the tunnel between the first network device and the second network device in the VPN as a VPN BIER tunnel; the sending unit 702 is used to send the second parameter set to the second network device.

In some implementations, the sending unit 702 is configured to send a second notification message to the second network device. The second notification message includes a second address family identifier and the second parameter set. The second address family The identifier is used to identify the next generation multicast virtual private network NG MVPN or BGP EVPN.

In some embodiments, the device further includes:

A receiving unit configured to receive a join message from a multicast receiver in the VPN, where the join message includes the multicast source group information; or, to receive a leave message from a multicast receiver in the VPN, where the leave message includes the group information. Source group information.

The device embodiment described in Figure 35 is only illustrative. For example, the division of the above units is only a logical function division. In actual implementation, there may be other divisions. For example, multiple units or components may be combined or may be Integrated into another system, or some features can be ignored, or not implemented. Each functional unit in various embodiments of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.

Each unit in the device 700 is implemented in whole or in part by software, hardware, firmware, or any combination thereof.

Some possible implementations of using hardware or software to implement each functional unit in the device 700 are described below in conjunction with the network device 900 described below.

In the case of software implementation, for example, the above-mentioned processing unit 701 is implemented by a software functional unit generated by at least one processor 901 in FIG. 37 after reading the program code stored in the memory 902.

In the case of hardware implementation, for example, the above-mentioned units in Figure 35 are respectively implemented by different hardware in the network device. For example, the processing unit 701 is implemented by a part of the processing resources (such as multi-core) in at least one processor 901 in Figure 37 One core or two cores in the processor), or using programmable devices such as field-programmable gate array (FPGA) or co-processor. The sending unit 702 is implemented by the network interface 903 in Figure 37.

Figure 36 is a schematic structural diagram of a device 800 for processing multicast messages provided by an embodiment of the present application. The device 800 is installed on the first network device in the VPN and includes: a receiving unit 801 for receiving the first multicast data. message; the processing unit 802 is configured to obtain a second multicast data message based on the first multicast data message and a first parameter set, where the first parameter set includes the bit forwarding router of the second network device in the VPN The prefix BFR prefix and the parameters used to identify the software-defined wide area network SD-WAN tunnel. The second network device is the endpoint of the SD-WAN tunnel. The second multicast data message includes a first message header and a second message. header and the payload of the first multicast data message. The first message header includes a base The IP address of the second network device obtained from the parameter used to identify the SD-WAN tunnel, the second message header includes a bit-based explicit copy BIER parameter obtained based on the BFR prefix of the second network device;

The sending unit 803 is configured to send the second multicast data message to the second network device through the SD-WAN tunnel.

The device embodiment described in Figure 36 is only illustrative. For example, the division of the above units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or may be Integrated into another system, or some features can be ignored, or not implemented. Each functional unit in various embodiments of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.

Each unit in the device 800 is implemented in whole or in part by software, hardware, firmware, or any combination thereof.

Some possible implementations of using hardware or software to implement each functional unit in the device 800 are described below in conjunction with the network device 900 described below.

In the case of software implementation, for example, the above-mentioned processing unit 802 is implemented by a software functional unit generated by at least one processor 901 in FIG. 37 after reading the program code stored in the memory 902.

In the case of hardware implementation, for example, the above-mentioned units in Figure 36 are respectively implemented by different hardware in the network device. For example, the processing unit 802 is implemented by a part of the processing resources (such as multi-core) in at least one processor 901 in Figure 37 One core or two cores in the processor), or using programmable devices such as field-programmable gate array (FPGA) or co-processor. The receiving unit 801 and the sending unit 803 are implemented by the network interface 903 in Figure 37.

Figure 37 is a schematic structural diagram of a network device 900 provided by an embodiment of the present application.

Network device 900 includes at least one processor 901, memory 902, and at least one network interface 903.

The processor 901 is, for example, a general-purpose central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), or a neural-network processing unit (NPU). ), a data processing unit (DPU), a microprocessor, or a or A plurality of integrated circuits used to implement the solution of this application. For example, the processor 901 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. A PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a general array logic (GAL), or any combination thereof.

The memory 902 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, or a random access memory (random access memory, RAM) or a device that can store information and instructions. Other types of dynamic storage devices, such as electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage, optical discs Storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can Any other media accessed by a computer, without limitation. Optionally, the memory 902 exists independently and is connected to the processor 901 through an internal connection 904. Alternatively, memory 902 and processor 901 may optionally be integrated together.

Network interface 903 uses any transceiver-like device for communicating with other devices or communications networks. The network interface 903 includes, for example, at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface or a combination thereof. The wireless network interface is, for example, a wireless local area network (WLAN) interface, a cellular network network interface or a combination thereof.

In some embodiments, processor 901 includes one or more CPUs, such as CPU0 and CPU1 shown in Figure 37.

In some embodiments, network device 900 optionally includes multiple processors, such as processor 901 and processor 905 shown in FIG. 37 . Each of these processors is, for example, a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Processor here optionally refers to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).

In some embodiments, network device 900 also includes internal connections 904. The processor 901, the memory 902 and at least one network interface 903 are connected through an internal connection 904. Internal connections 904 include pathways that carry information between the components described above. Optionally, internal connection 904 is a single board or bus. Optionally, the internal connections 904 are divided into address bus, data bus, control bus, etc.

In some embodiments, network device 900 also includes an input and output interface 906. Input/output interface 906 is connected to internal connection 904 .

Optionally, the processor 901 implements the method in the above embodiment by reading the program code stored in the memory 902, or the processor 901 implements the method in the above embodiment by using the internally stored program code. In the case where the processor 901 implements the method in the above embodiment by reading the program code stored in the memory 902, the memory 902 stores the program code 910 that implements the method provided by the embodiment of the present application.

For more details on how the processor 901 implements the above functions, please refer to the descriptions in the previous method embodiments, which will not be repeated here.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments.

A refers to B, which means that A is the same as B or that A is a simple transformation of B.

The terms "first" and "second" in the description and claims of the embodiments of this application are used to distinguish different objects, rather than to describe a specific order of objects, and cannot be understood to indicate or imply relative importance. sex. For example, the first parameter set and the second parameter set are used to distinguish different parameter sets rather than to describe a specific order of the parameter sets, nor can it be understood that the first parameter set is more important than the second parameter set.

In the embodiments of this application, unless otherwise stated, “at least one” means one or more, and “plurality” means two or more. For example, multiple parameter sets refer to two or more parameter sets.

The above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with the embodiments of the present application are generated in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted over a wired connection from a website, computer, server, or data center (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) to another website, computer, server or data center. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center integrated with one or more available media. The available media may be magnetic media (eg, floppy disk, hard disk, tape), optical media (eg, DVD), or semiconductor media (eg, Solid State Disk (SSD)), etc.

The above embodiments are only used to illustrate the technical solutions of the present application, but are not intended to limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments. Modifications may be made to the recorded technical solutions, or equivalent substitutions may be made to some of the technical features; however, these modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the scope of the technical solutions of the embodiments of the present application.

Claims

A multicast configuration method, characterized by including:

The first network device in the virtual private network VPN obtains a first parameter set, the first parameter set includes the bit forwarding router prefix BFR prefix of the first network device and parameters used to identify the software-defined wide area network SD-WAN tunnel, The first network device is an endpoint of the SD-WAN tunnel;

The first network device sends the first parameter set within the VPN.
The method according to claim 1, characterized in that the first parameter set further includes a BIER forwarding router identifier BFR-ID of the first network device.
The method according to claim 1 or 2, characterized in that the BFR prefix of the first network device is the private Internet Protocol IP address of the first network device in the VPN.
The method according to any one of claims 1 to 3, characterized in that the first parameter set further includes the bit string length BSL of the first network device and the maximum set identifier of the first network device. One or more of max-SI, the ID of the BIER subdomain where the first network device is located, the bit index forwarding table identifier BIFT-ID of the first network device, and the identifier of the VPN.
The method according to any one of claims 1 to 4, characterized in that the parameters used to identify the SD-WAN tunnel include a first tunnel type and first information, the first tunnel type is used to identify the tunnel The type is an SD-WAN tunnel, and the first information is used to determine the SD-WAN tunnel.
The method of claim 5, wherein the first information includes at least one of an identifier of the site where the first network device is located or a CPE ID of the first network device.
The method according to any one of claims 1 to 6, characterized in that the first network device sends the first parameter set within the VPN, including:

The first network device sends the first parameter set to a second network device in the VPN, and the second network device is the other endpoint of the SD-WAN tunnel; or,

The first network device sends the first parameter set to a route reflector RR, so that the RR reflects the first parameter set to a second network device in the VPN, and the second network device is The other endpoint of the SD-WAN tunnel.
The method according to any one of claims 1 to 7, characterized in that the first network device sends the first parameter set within the VPN, including:

The first network device sends a first advertisement message within the VPN. The first advertisement message includes a first address family identifier and the first parameter set. The first address family identifier is used to identify a boundary. Gateway Protocol Ethernet Virtual Private Network BGP EVPN or Border Gateway Protocol Virtual Private Network bit-based explicit replication BGP VPN BIER.
The method of claim 1, further comprising:

The first network device obtains a second parameter set. The second parameter set includes multicast source group information, the BFR prefix of the first network device, and a second tunnel type. The second tunnel type is used to identify all The tunnel between the first network device and the second network device in the VPN is a VPN BIER tunnel;

The first network device sends the second parameter set to the second network device.
The method according to claim 9, characterized in that the second parameter set further includes the first network device One or more of the BFR-ID of the bit forwarding router of the device, the identifier of the VPN, the identifier of the site where the second network device is located, and the CPE ID of the second network device.
The method according to claim 9 or 10, characterized in that the first network device sends the second parameter set to the second network device, including:

The first network device sends a second notification message to the second network device. The second notification message includes a second address family identifier and the second parameter set. The second address family identifier is used to Identifies the next generation multicast virtual private network NG MVPN or BGP EVPN.
The method according to claim 11, characterized in that the second notification message includes a multicast provider service interface tunnel attribute PTA attribute, the PTA attribute includes an MPLS label MPLS label field, and the MPLS label field includes the The identifier of the VPN.
The method according to any one of claims 9 to 12, characterized in that before the first network device obtains the second parameter set, the method further includes:

The first network device receives a join message from the intra-VPN multicast receiver, where the join message includes the multicast source group information; or,

The first network device receives a leave message from the intra-VPN multicast receiver, where the leave message includes the multicast source group information.
A method for processing multicast messages, which is characterized by including:

The first network device in the virtual private network VPN receives the first multicast data message;

The first network device obtains a second multicast data message based on the first multicast data message and a first parameter set, where the first parameter set includes a bit forwarding router of the second network device in the VPN The prefix BFR prefix and the parameters used to identify the software-defined wide area network SD-WAN tunnel, the second network device is the endpoint of the SD-WAN tunnel, and the second multicast data message includes a first message header, a third Two message headers and a payload of the first multicast data message, where the first message header includes the IP address of the second network device obtained based on the parameter used to identify the SD-WAN tunnel, so The second message header includes a bit-based explicit copy BIER parameter obtained based on the BFR prefix of the second network device;

The first network device sends the second multicast data message to the second network device through the SD-WAN tunnel.
The method according to claim 14, characterized in that the first parameter set further includes: the BIER forwarding router identifier BFR-ID of the second network device, the bit string length BSL of the second network device, The maximum set identifier max-SI of the second network device, the ID of the BIER subdomain where the second network device is located, the bit index forwarding table identifier BIFT-ID of the second network device and the identifier of the VPN one or more of.
The method according to claim 14 or 15, characterized in that the BIER parameter includes a bit string corresponding to the BFR prefix of the second network device, and a BIER- corresponding to the BFR prefix of the second network device. One or more of the MPLS label and the Internet Protocol version 6 IPv6 address corresponding to the BFR prefix of the second network device.
The method according to any one of claims 14 to 16, characterized in that the parameters used to identify an SD-WAN tunnel include a tunnel type and information used to determine the SD-WAN tunnel, the tunnel type for identification The type of tunnel is SD-WAN tunnel.
The method of claim 17, wherein the information used to determine the SD-WAN tunnel includes an identification of a site where the second network device is located or a client device of the second network device. Identifies at least one of the CPE IDs.
The method according to any one of claims 14 to 18, characterized in that the first message header includes a protocol type field, and the protocol type field is used to identify the second message carrying the BIER parameter. head.
The method according to claim 15, characterized in that the first message header further includes the ID of the VPN.
A multicast configuration device, characterized in that the first network device provided in a virtual private network (VPN) includes:

A processing unit configured to obtain a first parameter set, the first parameter set including the bit forwarding router prefix BFR prefix of the first network device and parameters used to identify the software-defined wide area network SD-WAN tunnel, the first network The device is the endpoint of the SD-WAN tunnel;

A sending unit, configured to send the first parameter set within the VPN.
The apparatus according to claim 21, wherein the first parameter set further includes a BIER forwarding router identifier BFR-ID of the first network device.
The device according to claim 21 or 22, wherein the BFR prefix of the first network device is the private Internet Protocol IP address of the first network device in the VPN.
The apparatus according to any one of claims 21 to 23, wherein the first parameter set further includes the bit string length BSL of the first network device and the maximum set identifier of the first network device. One or more of max-SI, the ID of the BIER subdomain where the first network device is located, the bit index forwarding table identifier BIFT-ID of the first network device, and the identifier of the VPN.
The device according to any one of claims 21 to 24, characterized in that the parameters used to identify the SD-WAN tunnel include a first tunnel type and first information, the first tunnel type is used to identify the tunnel The type is an SD-WAN tunnel, and the first information is used to determine the SD-WAN tunnel.
The apparatus according to claim 25, wherein the first information includes at least one of an identifier of the site where the first network device is located or a CPE ID of the first network device.
The device according to any one of claims 21 to 26, characterized in that the sending unit is configured to send the first parameter set to a second network device in the VPN, and the second network device be another endpoint of the SD-WAN tunnel; or, send the first parameter set to the route reflector RR, so that the RR reflects the first parameter set to the second network device in the VPN , the second network device is the other endpoint of the SD-WAN tunnel.
The device according to any one of claims 21 to 27, characterized in that the sending unit is configured to send a first notification message within the VPN, and the first notification message includes a first address family The identifier and the first parameter set, the first address family identifier is used to identify the Border Gateway Protocol Ethernet Virtual Private Network BGP EVPN or the Border Gateway Protocol Virtual Private Network bit-based explicit replication BGP VPN BIER.
The device according to claim 21, characterized in that the processing unit is further configured to obtain a second parameter set, the second parameter set includes multicast source group information, the BFR prefix of the first network device and A second tunnel type, the second tunnel type is used to identify the tunnel between the first network device and the second network device in the VPN It is a VPN BIER tunnel; the sending unit is configured to send the second parameter set to the second network device.
The apparatus according to claim 29, characterized in that the second parameter set further includes a bit forwarding router BFR-ID of the first network device, an identifier of the VPN, and a location where the second network device is located. One or more of the identity of the site and the CPE ID of the second network device.
The apparatus according to claim 29 or 30, wherein the sending unit is configured to send a second notification message to the second network device, the second notification message including a second address family identifier and The second parameter set and the second address family identifier are used to identify the next generation multicast virtual private network NG MVPN or BGP EVPN.
The device according to claim 31, wherein the second notification message includes a multicast provider service interface tunnel attribute PTA attribute, the PTA attribute includes an MPLS label MPLS label field, and the MPLS label field includes the The identifier of the VPN.
The device according to any one of claims 29 to 32, characterized in that the device further includes:

A receiving unit configured to receive a join message from the intra-VPN multicast receiver, where the join message includes the multicast source group information; or, to receive a leave message from the intra-VPN multicast receiver, the The leave message includes the multicast source group information.
A device for processing multicast messages, characterized in that the first network device located in a virtual private network (VPN) includes:

The receiving unit is used to receive the first multicast data message;

A processing unit configured to obtain a second multicast data message based on the first multicast data message and a first parameter set, where the first parameter set includes the bit forwarding router prefix of the second network device in the VPN BFR prefix and parameters used to identify the software-defined wide area network SD-WAN tunnel. The second network device is the endpoint of the SD-WAN tunnel. The second multicast data message includes a first message header, a second The message header and the payload of the first multicast data message, the first message header includes the IP address of the second network device obtained based on the parameter used to identify the SD-WAN tunnel, the The second message header includes a bit-based explicit copy BIER parameter obtained based on the BFR prefix of the second network device;

A sending unit, configured to send the second multicast data message to the second network device through the SD-WAN tunnel.
The apparatus according to claim 34, wherein the first parameter set further includes: the BIER forwarding router identifier BFR-ID of the second network device, the bit string length BSL of the second network device, The maximum set identifier max-SI of the second network device, the ID of the BIER subdomain where the second network device is located, the bit index forwarding table identifier BIFT-ID of the second network device and the identifier of the VPN one or more of.
The device according to claim 34 or 35, wherein the BIER parameter includes a bitstring corresponding to the BFR prefix of the second network device, and a BIER-bitstring corresponding to the BFR prefix of the second network device. One or more of the MPLS label and the Internet Protocol version 6 IPv6 address corresponding to the BFR prefix of the second network device.
The device according to any one of claims 34 to 36, wherein the parameters used to identify an SD-WAN tunnel include a tunnel type and information used to determine the SD-WAN tunnel, the tunnel type The type used to identify the tunnel is SD-WAN tunnel.
The apparatus according to claim 37, wherein the information used to determine the SD-WAN tunnel includes an identification of a site where the second network device is located or a client device of the second network device. Identifies at least one of the CPE IDs.
The device according to any one of claims 34 to 38, characterized in that the first message header includes a protocol type field, and the protocol type field is used to identify the second message carrying the BIER parameter. head.
The device according to claim 35, wherein the first message header further includes the ID of the VPN.
A network device, characterized in that the network device includes a processor and a network interface, and the network device executes any one of claims 1 to 20 by using the processor and the network interface. A method performed by a network device.
A network system, characterized in that the system includes the device according to any one of claims 21 to 33 and the device according to any one of claims 34 to 40.
A computer-readable storage medium, characterized in that at least one instruction is stored in the storage medium, and when the instruction is run on a computer, it causes the computer to execute the method according to any one of claims 1-20.
A computer program product, characterized in that the computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a computer, they cause the computer to execute any one of claims 1-20. method described in the item.