WO2024016869A1 - Procédé et appareil de configuration de multidiffusion - Google Patents

Procédé et appareil de configuration de multidiffusion Download PDF

Info

Publication number
WO2024016869A1
WO2024016869A1 PCT/CN2023/098480 CN2023098480W WO2024016869A1 WO 2024016869 A1 WO2024016869 A1 WO 2024016869A1 CN 2023098480 W CN2023098480 W CN 2023098480W WO 2024016869 A1 WO2024016869 A1 WO 2024016869A1
Authority
WO
WIPO (PCT)
Prior art keywords
network device
tunnel
vpn
bier
multicast
Prior art date
Application number
PCT/CN2023/098480
Other languages
English (en)
Chinese (zh)
Inventor
谷丁云
王恒
段方红
谢经荣
盛成
庞东磊
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202211512828.6A external-priority patent/CN117478503A/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2024016869A1 publication Critical patent/WO2024016869A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing

Definitions

  • the present application relates to the field of data communications, and in particular to a multicast configuration method and device.
  • SD-WAN Software-defined wide area network
  • the PIM protocol 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.
  • PIM protocol independent multicast
  • 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.
  • 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.
  • a multicast configuration method 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.
  • 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.
  • the first parameter set further includes a BIER forwarding router identifier BFR-ID of the first network device.
  • the BFR prefix of the first network device is the private Internet Protocol IP address of the first network device in the VPN.
  • 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.
  • 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.
  • 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.
  • CPE ID client equipment identification
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second advertisement message includes a multicast provider service interface tunnel attribute PTA attribute
  • the PTA attribute includes an MPLS label MPLS label field
  • the MPLS label field includes an identification of the VPN.
  • the method 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.
  • 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 are examples of the stream.
  • 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.
  • the max-SI 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.
  • 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.
  • 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.
  • 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.
  • the first message header includes a protocol type field
  • the protocol type field is used to identify the second message header carrying the BIER parameter.
  • the first packet header also includes the ID of the VPN.
  • a multicast configuration 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 .
  • the first parameter set further includes a BIER forwarding router identifier BFR-ID of the first network device.
  • the BFR prefix of the first network device is the private Internet Protocol IP address of the first network device in the VPN.
  • 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.
  • 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.
  • 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.
  • CPE ID client equipment identification
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second advertisement message includes a multicast provider service interface tunnel attribute PTA attribute
  • the PTA attribute includes an MPLS label MPLS label field
  • the MPLS label field includes an identification of the VPN.
  • 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.
  • a device for processing multicast messages 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first message header includes a protocol type field
  • the protocol type field is used to identify the second message header carrying the BIER parameter.
  • the first packet header also includes the ID of the VPN.
  • a network device in a fifth aspect, 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.
  • a network device in a sixth aspect, 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.
  • a network system 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.
  • a network system which system includes the device as in the fifth aspect and the device as in the sixth aspect.
  • a computer-readable storage medium stores at least one instruction.
  • the 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.
  • a computer-readable storage medium stores at least one instruction.
  • the 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.
  • a computer program product includes one or more computer program instructions.
  • the 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.
  • a computer program product includes one or more computer program instructions.
  • the 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.
  • a chip in a thirteenth aspect, 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. .
  • a chip in a fourteenth aspect, 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. .
  • 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;
  • FIG. 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.
  • FIG. 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.
  • FIG. 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.
  • 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.
  • IP overlay Internet protocol overlay
  • 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.
  • IP Internet Protocol
  • 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.
  • TN refers to the underlay network of SD-WAN (SD-WAN basic network).
  • 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.
  • 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.
  • 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.
  • CPE Customer premise equipment
  • 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.
  • TNP Transport network port
  • 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.
  • the entry in the SD-WAN tunnel forwarding table on CPE 1 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the site ID is uniformly assigned by the controller for each site in the SD-WAN.
  • 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.
  • the site ID of each CPE within the same site is usually the same.
  • CPE ID Customer premise equipment identification
  • CPE ID also called SD-WAN device ID (SD-WAN device identification)
  • SD-WAN device ID is used to identify a CPE in the SD-WAN network.
  • the CPE ID is usually an IP address of the device.
  • the CPE ID is the IP address of a loopback interface on the device.
  • the CPE ID is an Internet Protocol version 4 (IPv4) address or an Internet Protocol version 6 (IPv6) address.
  • IPv4 Internet Protocol version 4
  • IPv6 Internet Protocol version 6
  • the CPE ID is uniformly assigned by the controller to each CPE in the SD-WAN.
  • the TNP ID is a set that includes the site ID, CPE ID, and WAN interface IP address.
  • TNP ID consists of site ID
  • the CPE ID is obtained by concatenating the WAN interface IP address.
  • the TNP ID is a hash value generated based on the site ID, CPE ID, and WAN interface IP address.
  • RR is used to reflect routing information and SD-WAN tunnel information between CPEs. RR can be used as a regional controller.
  • 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.
  • VPN instances can be used to provide isolation functions for tenants.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • BFIR bit forwarding ingress router
  • TIR intermediate BFR
  • BFER bit forwarding egress router
  • a BIER network refers to a logical area that supports BIER forwarding.
  • a BIER network includes multiple BFRs.
  • a BIER network is a BIER domain, or a BIER network is a BIER subdomain.
  • a BIER domain refers to the collection of all BFRs in a routing domain or management 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.
  • 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.
  • 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.
  • 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.
  • the number of transit BFR deployed in a BIER network includes multiple situations. Two situations are given as examples below.
  • 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.
  • 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.
  • BFIR and BFER are deployed in the BIER network without transit BFR.
  • 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.
  • 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.
  • the number of transit BFR deployed in a BIER network includes multiple situations. Two situations are given as examples below.
  • 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.
  • 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.
  • 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.
  • Edge BFR refers to the BFR located at the edge of the BIER network. Edge BFR is the collective name of BFIR and BFER.
  • 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).
  • BFR-ID is usually an integer, for example, a positive integer in the range of 1 to 65535.
  • one BFR-ID corresponds to one bit in the bit string.
  • 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.
  • BFR-ID is i, corresponding to the i-th bit from right to left in the bit string, where i is a positive integer.
  • 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.
  • BFR prefix refers to an IP address of BFR.
  • the BFR prefix is the IP address of a loopback interface on the BFR.
  • the BFR prefix is a reachable IP address in the BIER network.
  • BFR prefix is a 32-bit IPv4 address; another example, BFR prefix is a 128-bit IPv6 address.
  • BIERv4 scenario use an IPv4 address of the device as the BFR prefix
  • BIERv6 use an IPv6 address of the device as the BFR prefix.
  • 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.
  • a BIER network includes set 0 and set 1.
  • Set 0 includes BFRs with BFR-IDs from 1 to 256
  • set 1 includes BFRs with BFR-IDs from 257 to 512.
  • the SI of each BFR is 0, and the SI of each BFR in BFR-IDs 257 to 512 is 1.
  • max-SI refers to the maximum value of the set identifier (SI).
  • 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.
  • 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.
  • 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.
  • BIER BIER-ID
  • BIRT Correspondence between the next hops on the forwarding path that reach the BFER.
  • 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.
  • BIFT-ID is used to identify a BIFT.
  • BIFT-ID is usually determined based on three parameters: BSL, SD and SI.
  • BIFT-ID is obtained by splicing three parameters: BSL, SD and SI.
  • BIFT-ID is the hash value obtained by hashing the three parameters BSL, SD and SI.
  • the BFR neighbor represents the next hop BFR.
  • the BFR neighbor is represented by the BFR prefix of the next hop BFR.
  • 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.
  • bit strings 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.
  • 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.
  • the value of the bit string carried in the data packet may be updated.
  • 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.
  • the first F-BM corresponds to the first next hop
  • 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.
  • 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.
  • 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.
  • 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.
  • a multicast group refers to a collection identified by an IP multicast address.
  • 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.
  • 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.
  • 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.
  • 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.
  • the root node is BFIR
  • the intermediate node is intermediate BFR
  • the leaf node is BFER.
  • 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.
  • the multicast routing table is usually divided into (S, G) routing table entries or (*, G) routing table entries.
  • S represents the multicast source.
  • G represents a multicast group (group).
  • 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.
  • 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).
  • L3VPN Layer 3 VPN
  • L2VPN Layer 2 VPN
  • the VPN identifier is used to identify a VPN.
  • the identifier of a VPN is a VPN identifier (virtual network identifier virtual network identifier, VN-ID) or a route identifier (route distinguisher, RD).
  • VPN BIER refers to a BIER network within a VPN.
  • VPN BIER is a BIER subdomain within a VPN.
  • 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.
  • 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.
  • one or more CPEs are deployed in the site.
  • the site IDs of different CPEs in the same site are the same. Sites are also part of the SD-WAN network.
  • next hop in the routing table entry There needs to be a directly connected next hop in the routing table entry before it can be used to guide forwarding.
  • 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.
  • 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.
  • 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.
  • the route is placed in the corresponding VPN instance routing table, the process of iterating routes to the corresponding tunnel is called tunnel iteration.
  • 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.
  • the tunnel iteration when the tunnel iteration is successful, the identity of the tunnel is retained.
  • the corresponding tunnel is found based on the tunnel identifier, and then sent out through the 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.
  • the ingress node of the tunnel encapsulates the tunnel header for the data packet
  • the egress node of the tunnel decapsulates the tunnel header and restores the original format of the data packet.
  • PMSI Provider multicast service interface
  • PTA is used to carry the information required to create PMSI.
  • next generation multicast VPN next generation MVPN, NG MVPN over BIER
  • NG MVPN over BIER next generation MVPN
  • a BIER type PTA can be used to carry the information required to establish a BIER forwarding path.
  • RFC8556 details of the PTA.
  • 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.
  • the loopback interface is a virtual interface on the forwarding device.
  • the loopback interface is created, unless it is closed manually interface, otherwise its physical layer is usually up.
  • 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.
  • 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.
  • NG MVPN is a new generation framework for IP multicast data traffic to traverse VPN.
  • MVPN multicast VPN
  • BGP 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).
  • 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.
  • 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).
  • AFI address family identifier
  • SAFI sub-address family identifier
  • 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 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.
  • 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.
  • FIG. 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
  • 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.
  • 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.
  • Figure 2 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.
  • the roles of devices are mainly divided into three types: BFIR, transit BFR and BFER.
  • forwarding device A is BFIR
  • forwarding device D is transit BFR
  • forwarding device B and forwarding device C are BFER.
  • the roles of devices are mainly divided into root nodes (or head nodes), intermediate nodes, and leaf nodes.
  • forwarding device A is the root node
  • forwarding device D is the intermediate node
  • forwarding device B and forwarding device C are leaf nodes.
  • the roles of devices are mainly divided into CPE and RR.
  • 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.
  • FIG 4 is a schematic diagram of the logical functional architecture provided by the embodiment of this application.
  • 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.
  • 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).
  • point of presence, POP point of presence
  • 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.
  • 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.
  • the leaf node 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.
  • 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.
  • 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.
  • 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.
  • Some embodiments of this application involve the control plane configuration process of different layers in the above three-layer logical architecture.
  • the parameter set related to the VPN BIER layer is called the first parameter set
  • the multicast private network is called the first parameter set.
  • the layer-related parameter set is called the second parameter set
  • the SD-WAN tunnel layer-related parameter set is called the third parameter set.
  • the configured parameters can be advertised within the VPN.
  • 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.
  • the forwarding device saves the obtained correspondence in the form of a table entry.
  • 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.
  • 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.
  • the forwarding device stores the above three corresponding relationships through different types of entries.
  • the above three correspondences are stored in three independent tables on the device.
  • the first correspondence is an entry in the BIER forwarding table (BIFT) or the BIER routing table (BIRT)
  • the second correspondence is an entry or group in the multicast routing table.
  • the third corresponding relationship is an entry in the SD-WAN tunnel forwarding table.
  • 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
  • the forwarding device as the leaf node can store the first correspondence, the second correspondence and the third correspondence.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 first forwarding device covers a variety of situations.
  • the first forwarding device is the root node.
  • the first forwarding device is forwarding device A.
  • the first forwarding device is a leaf node.
  • the first forwarding device is forwarding device B or forwarding device C.
  • the first forwarding device is an intermediate node.
  • the first forwarding device is forwarding device D.
  • the first forwarding device is the endpoint of the SD-WAN tunnel.
  • the first forwarding device is forwarding device A
  • the first forwarding device is the entry node of the SD-WAN tunnel 31.
  • the first forwarding device is forwarding device D
  • 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 .
  • 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.
  • 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.
  • 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).
  • a reachability TLV reachability prefix TLV
  • 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 Existing message encapsulation format.
  • the BFR prefix of the first forwarding device is 1.1.1.1.
  • 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.
  • 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.
  • 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.
  • the private IP address in the VPN 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.
  • the first forwarding device is a leaf node
  • 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.
  • 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.
  • 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.
  • 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.
  • the above parameter used to identify the SD-WAN tunnel is in the form of a number or a series of numbers.
  • the above parameter used to identify the SD-WAN tunnel is 1, 2 or 3, or 111, 222 or 333.
  • the above-mentioned parameter used to identify the SD-WAN tunnel is the IP address of the first forwarding device.
  • 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.
  • 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.
  • 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.
  • the above parameter used to identify the SD-WAN tunnel is a string.
  • 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".
  • 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.
  • the first tunnel type is in the form of a number that represents the SD-WAN tunnel.
  • the first tunnel type is in the form of a string, such as "SD-WAN".
  • the first information is used to determine the SD-WAN tunnel.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • transit BFR there is usually no need to assign a BFR-ID to the transit BFR.
  • assign the BFR-ID of the transit BFR to 0.
  • no corresponding BFR-ID is allocated to BFIR.
  • 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.
  • 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.
  • a value is selected as the BSL from the reference values of the BSL specified in the BIER standard protocol.
  • the reference values of BSL in BIER's standard protocol include 64, 128, 512, 1028, 2048 and 4096.
  • 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.
  • 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.
  • the effects that can be achieved include but are not limited to the following three aspects.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the above-mentioned first advertisement message is a BGP message.
  • the above-mentioned first notification message is, for example, a BGP update message.
  • 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.
  • the first address family identifier is used to identify the BGP EVPN.
  • the first address family identifier is used to identify the BGP VPN BIER.
  • the parameter set 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.
  • 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.
  • 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.
  • path attributes can be used to implement functions such as receiving and sending control parameters, thereby adapting to richer scenarios.
  • 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.
  • 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.
  • the above-mentioned path attribute is, for example, a BGP transitive path attribute (BGP transitive path attribute).
  • the above path attributes are, for example, BGP extended community attributes.
  • 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
  • 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.
  • the forwarding device uses a flooding method to send parameters in the VPN. set.
  • 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.
  • 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.
  • 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.
  • the first forwarding device is a root node
  • the second forwarding device is an intermediate node or a leaf node.
  • the first forwarding device is a leaf node
  • the second forwarding device is a root node or an intermediate node.
  • 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.
  • the first corresponding relationship is an entry in the BIFT in the second forwarding device.
  • the first corresponding relationship is an entry in the BIRT on the second forwarding device.
  • the first correspondence includes an F-BM matching the BFR-ID of the first forwarding device and a parameter identifying the SD-WAN tunnel.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the BFR-ID of the first forwarding device is 2
  • the BFR prefix of the first forwarding device is 10.1.1.1
  • 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.
  • the second forwarding device determines that the F-BM matching the BFR-ID of the first forwarding device is 0010.
  • 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.
  • 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.
  • the first correspondence relationship also includes an identifier of the VPN where the first forwarding device is located.
  • 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.
  • Table 3 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.
  • Table 4 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the leaf node 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.
  • NG MVPN traditional multicast VPN technology
  • 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.
  • 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.
  • C-multicast routes are required to carry multicast source group information but are not required to carry BIER parameters
  • leaf A-D routes are required to carry BIER parameters but usually do not carry multicast source group information.
  • 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.
  • 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.
  • the leaf node 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 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.
  • the first forwarding device is a leaf node
  • the second forwarding device is a root node
  • 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.
  • the multicast source group information includes a multicast source address and an address of the multicast group.
  • the multicast source group information includes the address of the multicast rendezvous point (RP) and the address of the multicast group.
  • 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.
  • 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.
  • the second tunnel type is a string, such as "VPN BIER", or a number that identifies the VPN BIER tunnel.
  • the first forwarding device obtains the second tunnel type according to the control plane configuration.
  • the second parameter set also includes the BFR prefix of the first forwarding device.
  • 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.
  • the second parameter set also includes an identifier of the VPN where the first forwarding device is located.
  • 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.
  • the first forwarding device generates a second notification message
  • the second notification message includes a second parameter set
  • 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.
  • the second address family identifier is used to identify the NG MVPN.
  • 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.
  • 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.
  • 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.
  • 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 second correspondence relationship is shown in Table 5 below.
  • the second correspondence includes entries in two separate tables.
  • 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.
  • Table 6 is a specific example of the fourth correspondence relationship
  • Table 7 is a specific example of the fifth correspondence relationship.
  • Table 6 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the multicast source is inside a VPN.
  • 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.
  • 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.
  • the first packet header can be any type of IP overlay tunnel header.
  • 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.
  • the first packet header includes a GRE extension header and an IP header.
  • the first message header includes a GRE header and an IP header.
  • the first packet header includes a VXLAN header and an IP header.
  • the first packet header includes a VXLAN-GPE header and an IP header.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first header in the second multicast data packet contains the IPv6 addresses of the two endpoint devices of the first SD-WAN tunnel.
  • 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.
  • the endpoint of the SD-WAN tunnel is within the site.
  • the two endpoint devices of the first SD-WAN tunnel are the BFIR in site 1 and the transit BFR in site 2.
  • 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.
  • the third corresponding relationship includes the site ID of the transit BFR and the IP address of the transit BFR.
  • the third corresponding relationship includes the CPE ID of the transit BFR and the IP address of the transit BFR.
  • the third corresponding relationship includes the label of the first SD-WAN tunnel and the IP address of the transit BFR.
  • 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.
  • BFIR obtains the IP address of the transit BFR based on the CPE ID of the transit BFR and the third corresponding relationship.
  • the CPE ID of transit BFR is 10.2.2.2
  • the third corresponding relationship is shown in Table 9 below.
  • 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.
  • the label of the first SD-WAN tunnel is 201
  • the third corresponding relationship is shown in Table 10 below.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. .
  • the first packet header also includes an identifier of the VPN.
  • 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.
  • BFIR obtains the identity of the VPN based on the multicast source group information and the second corresponding relationship.
  • 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. .
  • 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.
  • the second message header can be any message header carrying a bit string in BIER encapsulation.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the multicast source address in the first multicast data packet is S1
  • 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.
  • 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.
  • 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.
  • the first BIER parameter in the second message header also includes BIFT-ID.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first BIER parameter in the second message header also includes the End.BIER address.
  • 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.
  • 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.
  • 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.
  • BFIR 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.
  • 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
  • Step S703 BFIR sends the second multicast data message.
  • BFIR sends the second multicast data packet through the first SD-WAN tunnel.
  • 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.
  • the transit BFR receives the second multicast data packet through the first SD-WAN tunnel.
  • 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 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.
  • 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.
  • 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.
  • the destination address field of the first header in the third multicast data packet carries the IP address of BFER
  • 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.
  • 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 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.
  • 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.
  • the third corresponding relationship includes BFER's site ID and BFER's IP address.
  • the third corresponding relationship includes the CPE ID of BFER and the IP address of BFER.
  • the third corresponding relationship includes the label of the second SD-WAN tunnel and the IP address of the BFER.
  • 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.
  • the second message header in the third multicast data message includes the second BIER parameter.
  • the second BIER parameter is obtained based on the first BIER parameter and the corresponding relationship saved by the transit BFR.
  • the transit BFR updates the BIER parameters originally carried in the second message header based on the BIER parameters obtained from the table lookup.
  • 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.
  • 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.
  • 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.
  • 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.
  • each forwarding table stores entries corresponding to the VPNs.
  • 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.
  • the transit BFR 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.
  • the transit BFR sends the third multicast data packet through the second SD-WAN tunnel.
  • 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.
  • BFER sends the third multicast data packet through the second SD-WAN tunnel.
  • 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.
  • BFER decapsulates the first packet header and the second packet header in the third multicast data packet, and obtains the fourth multicast data packet.
  • 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.
  • 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.
  • FIG. 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 .
  • 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.
  • FIG. 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 12 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.
  • RD route identifier
  • 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.
  • I-PMSI provider multicast service interface
  • S-PMSI selective multicast service interface
  • VPN BIER 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.
  • 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.
  • FIG. 16 is a schematic diagram of the format of the NLRI for which (*, G) is added to the route
  • 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.
  • 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.
  • the root node in the BIER network adds the BIER header, SD-WAN header, and outer IP to the multicast data packet. head.
  • the leaf node decapsulates the BIER header, SD-WAN header, and outer IP header to obtain the multicast data packet.
  • 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.
  • the BIER header can be any packet header containing a bit string.
  • the encapsulation format of the BIER header includes multiple implementation methods.
  • 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
  • FIG 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.
  • MPLS label MPLS label
  • BIFT-ID non MPLS label, non-MPLS label
  • 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.
  • this field may include the BIFT-ID used to identify the BIFT.
  • BIFT-ID is determined based on BSL, sub-domain ID and SI.
  • the TC field is used for QoS.
  • the S field is a 1-bit label stack bottom identifier, which is the same as the S bit of MPLS encapsulation.
  • RFC3032 For the specific use of this field, please refer to RFC3032.
  • the TTL field is 8 bits and is used for TTL during MPLS encapsulation.
  • RFC3032 For the specific use of this field, please refer to RFC3032.
  • 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.
  • the version number field occupies 4 bits and can represent the version number.
  • 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.
  • bit string length is 128 bits.
  • bit string length is 256 bits.
  • bit string length is 512 bits.
  • bit string length is 1024 bits.
  • bit string length is 2048 bits.
  • bit string length is 4096 bits.
  • the length of the Entropy field is, for example, 20 bits.
  • the Entropy field is used to select a path when an equivalent path exists.
  • packets with the same bit string and entropy value choose the same path.
  • 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.
  • the reserved field is, for example, 2 bits, and the value of the reserved field is 0 by default.
  • 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.
  • the protocol type field is, for example, 6 bits, and is used to identify the packet type immediately following the BIER header.
  • the BFIR ID field occupies, for example, 16 bits, and the BFIR ID field includes the BFR-ID of the BFIR.
  • 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
  • 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.
  • the BIER header is encapsulated inside DOH (Destination Options Header).
  • the BIER header is encapsulated inside other types of IPv6 extension headers other than DOH.
  • the BIER header is packaged inside SRH or HBH.
  • the BIER header is encapsulated in the options of the IPv6 extension header.
  • the BIER header is encapsulated in the DOH option.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 Next Header field occupies 8 bits and is used to identify the type of the next message header.
  • the Hdr Ext Len field occupies 8 bits and is used to identify the length of the IPv6 extension header, that is, the length of the BIERv6 header.
  • the Option Type field for example, occupies 8 bits and is used to identify the option type as BIERv6.
  • the BIFT-ID field occupies, for example, 20 bits and is used to uniquely identify a BIFT.
  • the TC field is used for QoS.
  • the S field occupies 1 bit and is a reserved field.
  • 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.
  • Nibble occupies 4 bits for example.
  • the Nibble field is a reserved field, for example, filled with 0.
  • Version occupies 4 bits, for example, and identifies the version number of the BIERv6 message.
  • 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.
  • bit string length is 128 bits.
  • bit string length is 256 bits.
  • bit string length is 512 bits.
  • bit string length is 1024 bits.
  • bit string length is 2048 bits.
  • bit string length is 4096 bits.
  • the length of the Entropy field is, for example, 20 bits.
  • the Entropy field is used to select a path when an equivalent path exists.
  • packets with the same bit string and entropy value choose the same path.
  • the length of the OAM field is, for example, 2 bits, and the default is 0. It is optionally used for the OAM function.
  • the reserved field is, for example, 2 bits, and the value of the reserved field is 0 by default.
  • 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.
  • the protocol type field is, for example, 6 bits, and is used to identify the packet type immediately following the BIERv6 header.
  • the BFIR ID field for example, occupies 16 bits and is the BFR-ID of the BFIR.
  • 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 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.
  • Figure 22 and Figure 23 are both schematic diagrams of the packaging format of BIERin6.
  • the content of the IPv6 basic header in Figure 22 please refer to the description of BIERv6 above.
  • 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
  • RFC Real-Time Transport Stream
  • Figure 24 is a schematic diagram of a G-BIER encapsulation format provided by an embodiment of the present application.
  • 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.
  • 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.
  • 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.
  • MPRA Multicast Policy Reserved Address
  • the Next Header field occupies 8 bits and is used to identify the type of the next header.
  • the Hdr Ext Len field occupies 8 bits and is used to identify the length of the IPv6 extension header.
  • the Option Type field for example, occupies 8 bits and is used to identify the option type as G-BIER.
  • the Option Length field for example, occupies 8 bits and is used to identify the option length.
  • 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.
  • bit string length is 128 bits.
  • bit string length is 256 bits.
  • bit string length is 512 bits.
  • bit string length is 1024 bits.
  • bit string length is 2048 bits.
  • bit string length is 4096 bits.
  • the SD field occupies, for example, 8 bits, and the value of the SD field is the ID of the BIER subfield.
  • the SI field occupies, for example, 8 bits, and the value of the SI field is the set identifier to which the BFR belongs.
  • the Rsv field is a reserved field.
  • 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.
  • the Version field occupies 4 bits, for example.
  • the length of the Entropy field is, for example, 20 bits.
  • the Entropy field is used to select a path when an equivalent path exists.
  • packets with the same bit string and entropy value choose the same path.
  • the length of the OAM field is, for example, 2 bits, and the default is 0. It is optionally used for the OAM function.
  • the reserved field is, for example, 2 bits, and the value of the reserved field is 0 by default.
  • 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.
  • Each bit in the bit string corresponds to a BFR-ID of a BFER.
  • the SD-WAN header can be any packet header that supports L3VPN tunnel establishment.
  • the SD-WAN header includes, but is not limited to, GRE extension header or GRE header.
  • the SD-WAN header can be any packet header that supports L2VPN tunnel establishment.
  • 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.
  • VXLAN Virtual Extensible Local Area Network
  • VXLAN-GPE VXLAN Generic Protocol Encapsulation
  • GENEVE Generic Network Virtualization Encapsulation
  • the SD-WAN header includes the identification of the VPN where the BFR is located (such as VN-ID).
  • VN-ID the identification of the VPN where the BFR is located
  • 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.
  • the Protocol Type in the GRE extension header identifies BIERv6.
  • the Protocol Type in the GRE extension header identifies BIERin6.
  • the Protocol Type in the GRE extension header identifies G-BIER.
  • FIG. 26 is a schematic diagram of another general encapsulation format of an SD-WAN header provided by an embodiment of the present application.
  • 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.
  • the Protocol field identifies BIERv6.
  • the Protocol field identifies BIERin6.
  • 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.
  • 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.
  • FIG. 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.
  • the Next protocol field identifies BIERv6.
  • the Next protocol field identifies BIERin6.
  • 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.
  • 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.
  • the Protocol Type in the GENEVE header identifies BIERin6.
  • the Protocol Type in the GENEVE header identifies G-BIER.
  • 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.
  • 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.
  • the source address in the outer IPv6 header of the SD-WAN header is the IPv6 address of the WAN interface on the BFIR
  • 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.
  • the encapsulation format of data packets includes IP header, SD-WAN header, BIER header and multicast data packets.
  • 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.
  • 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.
  • the IPsec header is an ESP header
  • the IPsec trailer is an ESP trailer.
  • the format of the IPsec header can be found in Figure 30.
  • 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.
  • 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.
  • 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.
  • 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.
  • CPE ID the specific router ID
  • CPE 3 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.
  • CPE ID the specific router ID
  • Step 3 The multicast data packet sent to multicast receiver 2 reaches CPE 5 through the SD-WAN tunnel.
  • 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
  • the multicast data message is sent to CPE 5.
  • 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.
  • CPE ID the specific router ID
  • 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.
  • BIERv6 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.
  • 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.
  • Figure 33 is a schematic diagram of the network deployment scenario of Example 1.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the BIER routing table learned by CPE100 in site5 is shown in Table 12 below.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • SD-WAN header such as the GRE header
  • 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.
  • 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.
  • a multicast data packet 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.
  • 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.
  • Figure 34 is a schematic diagram of the network deployment scenario of Example 3.
  • 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.
  • 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.
  • CPE5 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.
  • 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.
  • 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.
  • 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 includes the following steps.
  • Step 1 Establish an underlay SD-WAN tunnel.
  • step 1 please refer to the description of Example 1.
  • Step 2 Establish overlay BIERv6VPN tunnel.
  • 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.
  • 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.
  • 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.
  • the first parameter set further includes a BIER forwarding router identifier BFR-ID of the first network device.
  • the BFR prefix of the first network device is the private Internet Protocol IP address of the first network device in the VPN.
  • 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.
  • 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.
  • 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.
  • CPE ID client equipment identification
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second advertisement message includes a multicast provider service interface tunnel attribute PTA attribute
  • the PTA attribute includes an MPLS label MPLS label field
  • the MPLS label field includes an identification of the VPN.
  • 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 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.
  • the device embodiment described in Figure 35 is only illustrative.
  • the division of the above units is only a logical function division. In actual implementation, there may be other divisions.
  • 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.
  • 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.
  • the above-mentioned units in Figure 35 are respectively implemented by different hardware in the network device.
  • 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.
  • FIG 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 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.
  • the max-SI 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.
  • 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.
  • 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.
  • 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.
  • the first message header includes a protocol type field
  • the protocol type field is used to identify the second message header carrying the BIER parameter.
  • the first packet header also includes the ID of the VPN.
  • the device embodiment described in Figure 36 is only illustrative.
  • the division of the above units is only a logical function division. In actual implementation, there may be other division methods.
  • 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.
  • 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.
  • the above-mentioned units in Figure 36 are respectively implemented by different hardware in the network device.
  • 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.
  • 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.
  • ROM read-only memory
  • RAM random access memory
  • 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.
  • the memory 902 exists independently and is connected to the processor 901 through an internal connection 904.
  • 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.
  • WLAN wireless local area network
  • processor 901 includes one or more CPUs, such as CPU0 and CPU1 shown in Figure 37.
  • network device 900 optionally includes multiple processors, such as processor 901 and processor 905 shown in FIG. 37 .
  • processors are, 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).
  • 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.
  • internal connection 904 is a single board or bus.
  • the internal connections 904 are divided into address bus, data bus, control bus, etc.
  • network device 900 also includes an input and output interface 906.
  • Input/output interface 906 is connected to internal connection 904 .
  • 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.
  • the memory 902 stores the program code 910 that implements the method provided by the embodiment of the present application.
  • A refers to B, which means that A is the same as B or that A is a simple transformation of B.
  • 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.
  • 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.
  • “at least one” means one or more, and “plurality” means two or more.
  • 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.
  • software 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.
  • the computer program 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.

Landscapes

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

Abstract

La présente demande, qui relève du domaine des communications de données, concerne un procédé et un appareil de configuration de multidiffusion. Dans la présente demande, un préfixe BFR et des paramètres pour identifier un tunnel SD-WAN sont annoncés à un réseau VPN de sorte que la présence d'une relation d'association entre une réplication BIER et un réseau SD-WAN peut être indiquée, c'est-à-dire, il est nécessaire de passer par le tunnel SD-WAN pour atteindre un certain préfixe BFR, ce qui facilite le transfert d'un paquet de données dans le réseau SD-WAN sur la base de la réplication BIER. De cette façon, un nœud intermédiaire dans le réseau SD-WAN peut répliquer et transférer le paquet selon une situation définie d'une chaîne de bits dans le paquet, sans détecter l'état d'un groupe de multidiffusion ou établir un arbre de distribution de multidiffusion pour chaque flux de données de multidiffusion. Ainsi, des ressources occupées par un transfert de flux de multidiffusion dans un scénario de réseau SD-WAN sont économisées.
PCT/CN2023/098480 2022-07-21 2023-06-06 Procédé et appareil de configuration de multidiffusion WO2024016869A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202210865496 2022-07-21
CN202210865496.3 2022-07-21
CN202211512828.6A CN117478503A (zh) 2022-07-21 2022-11-28 一种组播配置方法及装置
CN202211512828.6 2022-11-28

Publications (1)

Publication Number Publication Date
WO2024016869A1 true WO2024016869A1 (fr) 2024-01-25

Family

ID=89616961

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/098480 WO2024016869A1 (fr) 2022-07-21 2023-06-06 Procédé et appareil de configuration de multidiffusion

Country Status (1)

Country Link
WO (1) WO2024016869A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109995634A (zh) * 2017-12-29 2019-07-09 中兴通讯股份有限公司 一种组播虚拟专用网络的承载方法和设备
CN111147383A (zh) * 2018-11-02 2020-05-12 华为技术有限公司 报文转发的方法、发送报文的装置和接收报文的装置
US20200245206A1 (en) * 2017-03-06 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Bit indexed explicit replication based multicast for locator identifier separation protocol
CN111917622A (zh) * 2019-09-23 2020-11-10 华为技术有限公司 一种反向路径转发rpf检查方法及装置
CN114095305A (zh) * 2020-07-21 2022-02-25 华为技术有限公司 Bier报文转发的方法、设备以及***
CN114465920A (zh) * 2020-11-09 2022-05-10 华为技术有限公司 确定对应关系的方法、装置以及***

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200245206A1 (en) * 2017-03-06 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Bit indexed explicit replication based multicast for locator identifier separation protocol
CN109995634A (zh) * 2017-12-29 2019-07-09 中兴通讯股份有限公司 一种组播虚拟专用网络的承载方法和设备
CN111147383A (zh) * 2018-11-02 2020-05-12 华为技术有限公司 报文转发的方法、发送报文的装置和接收报文的装置
CN111917622A (zh) * 2019-09-23 2020-11-10 华为技术有限公司 一种反向路径转发rpf检查方法及装置
CN114095305A (zh) * 2020-07-21 2022-02-25 华为技术有限公司 Bier报文转发的方法、设备以及***
CN114465920A (zh) * 2020-11-09 2022-05-10 华为技术有限公司 确定对应关系的方法、装置以及***

Similar Documents

Publication Publication Date Title
JP7208386B2 (ja) パケット転送方法、パケット送信装置、およびパケット受信装置
CN109218178B (zh) 一种报文处理方法及网络设备
WO2021063232A1 (fr) Procédé, appareil et système d'établissement d'élément de table d'acheminement bier
US10135627B2 (en) System for avoiding traffic flooding due to asymmetric MAC learning and achieving predictable convergence for PBB-EVPN active-active redundancy
CN108574630B (zh) Evpn报文处理方法、设备及***
WO2020182086A1 (fr) Procédé et appareil d'envoi de paquets bier
WO2019105462A1 (fr) Procédé et appareil d'envoi de paquet, procédé et appareil de traitement de paquet, nœud pe et nœud
US9148300B2 (en) Method and system for telecommunications including self-organizing scalable Ethernet using IS-IS hierarchy
US8717934B2 (en) Multicast source move detection for layer-2 interconnect solutions
CN103139037B (zh) 用于实现灵活的虚拟局域网的方法和装置
US8553581B2 (en) Method and apparatus for provisioning a network element
CN107612808B (zh) 隧道建立方法和装置
CN106572021B (zh) 一种实现网络虚拟化叠加的方法与网络虚拟化边缘节点
CN108964940A (zh) 消息发送方法及装置、存储介质
CN113132235B (zh) 基于虚电路的数据报文处理方法、转发表项的构建方法
US20230155932A1 (en) Multicast traffic transmission method and apparatus, communication node, and storage medium
WO2018058639A1 (fr) Procédé et appareil de partage de charge de pseudo-câble
EP3716529A1 (fr) Tunnelisation de paquets de multidiffusion de protocole internet sans état interdomaines
WO2020098611A1 (fr) Procédé et appareil pour acquérir des informations de routage
WO2022117018A1 (fr) Procédé et appareil de transmission de paquet
CN113037883B (zh) 一种mac地址表项的更新方法及装置
CN117478503A (zh) 一种组播配置方法及装置
US20210126812A1 (en) Anycast address configuration for extended local area networks
WO2024016869A1 (fr) Procédé et appareil de configuration de multidiffusion
WO2021103744A1 (fr) Procédé et système de communication de réseau hétérogène, et contrôleur

Legal Events

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

Ref document number: 23841936

Country of ref document: EP

Kind code of ref document: A1