Methods, devices, and systems for BIER message forwarding

Abstract

This application provides a method, device, and system for forwarding BIER packets. The method includes: a first network device receiving a BIER packet sent by a second network device. The BIER packet includes an IPv6 header, a BIER header, and a multicast packet. The destination address in the IPv6 header or a first field in the BIER header carries a service identifier, which is used to identify a Virtual Private Network (VPN) instance. The first network device determines a Virtual Private Network (VRF) table based on the service identifier and a first correspondence, whereby the first correspondence includes the correspondence between the service identifier and the VRF table. The first network device then sends a multicast packet to a first User Edge (CE) device listed in the VRF table. The technical solution provided by this application is relatively simple to implement when the egress edge device identifies a VPN instance.

Description

[0001] This application claims priority to Chinese Patent Application No. 202010702525.5, filed on July 21, 2020, entitled "A Multicast Forwarding Method, Device and System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of network communication, and more specifically, to a method, apparatus, and system for message forwarding. Background Technology

[0003] Internet Protocol (IP) multicast technology enables efficient point-to-multipoint data transmission in IP networks, effectively saving network bandwidth and reducing network load. To address this, the industry has proposed a new technique for constructing multicast packet forwarding paths, called bit-indexed explicit replication (BIER). This technique proposes a novel multicast architecture that does not require the construction of a multicast distribution tree.

[0004] For the egress device of the BIER domain, after receiving a BIER message, it needs to determine the virtual private network (VPN) instance to which the multicast message belongs, determine the virtual route forwarding (VRF) table corresponding to the VPN instance, and forward the multicast message to the next hop in the VRF table according to the information in the original multicast message (e.g., the destination address in the original multicast message) and the VRF table.

[0005] In one related technical solution, the service identifier (used to identify VPN instances) is carried in the MPLS label. Since the BIER packet contains an MPLS label layer, it is impossible to achieve full network de-MPLS, which adds extra complexity to the device.

[0006] Another related technical solution identifies different VPN instances using different source addresses (SAs) in the outer Internet Protocol Version 6 (IPv6) header. Using IPv6 source addresses to identify VPN instances requires the management and allocation of these IPv6 source addresses. Summary of the Invention

[0007] This application provides a method, device, and system for BIER packet forwarding, which can be implemented relatively simply when the egress edge device identifies a VPN instance.

[0008] In a first aspect, a method for packet forwarding is provided, comprising: receiving a BIER packet sent by a second network device, the BIER packet including an Internet Protocol version 6 (IPv6) header, an explicit copy BIER header based on bit indexing, and a multicast packet, wherein the destination address of the IPv6 header or a first field of the BIER header carries a service identifier, the service identifier being used to identify a Virtual Private Network (VPN) instance; the first network device determining a Virtual Routing Forwarding (VRF) table based on the service identifier and a first correspondence, the first correspondence including the correspondence between the service identifier and the VRF table; and the first network device sending the multicast packet to a first User Edge (CE) device in the VRF table according to the VRF table.

[0009] In the above technical solution, by carrying the service identifier through the destination address of the IPv6 header of the BIER packet or the first field of the BIER header, it is not necessary to manage and allocate the IPv6 source address required to identify the VPN instance, nor is it necessary to add an additional MPLS label layer. The implementation is relatively simple and reduces the complexity of device implementation.

[0010] In one possible implementation, the service identifier is carried in a portion of the destination address in the IPv6 header, the destination address being used to indicate BIER forwarding of the BIER packet.

[0011] In another possible implementation, a portion of the destination address is the argument portion of the destination address.

[0012] In another possible implementation, the first field of the BIER header is a combination of any one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field.

[0013] In another possible implementation, the method further includes: the first network device receiving a control message, the control message including the correspondence between the service identifier and the VRF table; the first network device storing the correspondence between the service identifier and the VRF table.

[0014] In another possible implementation, the first network device determines the VRF table based on the source address of the IPv6 header, the service identifier, and the first correspondence.

[0015] Secondly, a method for forwarding BIER packets is provided, the method comprising: a second network device acquiring a multicast packet; the second network device encapsulating the multicast packet according to the Virtual Private Network (VPN) instance to which the multicast packet belongs to obtain a BIER packet, the BIER packet comprising an Internet Protocol version 6 (IPv6) header, a bit-indexed explicit copy BIER header, and the multicast packet, wherein the destination address of the IPv6 header or a first field of the BIER header carries a service identifier, the service identifier being used to identify the VPN instance; and the second network device sending the BIER packet to a first network device.

[0016] In another possible implementation, the service identifier is carried in a portion of the destination address in the IPv6 header, the destination address being used to instruct the first network device to perform BIER forwarding of the BIER packet.

[0017] In another possible implementation, a portion of the destination address is the argument portion of the destination address.

[0018] In another possible implementation, the first field of the BIER header is a combination of any one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field.

[0019] In another possible implementation, the method further includes: the second network device assigning the service identifier to the VPN instance; the second network device establishing a first correspondence, the first correspondence including the correspondence between the service identifier and the VRF table corresponding to the VPN instance.

[0020] In another possible implementation, the method further includes: the second network device sending a control message to the first network device, the control message including the correspondence between the service identifier and the VRF table.

[0021] In another possible implementation, the control message is a Border Gateway Protocol (BGP) message.

[0022] The beneficial effects of the second aspect and any possible implementation of the second aspect correspond to the beneficial effects of the first aspect and any possible implementation of the first aspect, which will not be elaborated further.

[0023] Thirdly, a first network device is provided, comprising: a receiving module, a processing module, and a transmitting module.

[0024] The receiving module is used to receive BIER messages sent by the second network device. The BIER message includes an Internet Protocol version 6 (IPv6) header, an explicit copy BIER header based on bit indexing, and a multicast message. The destination address of the IPv6 header or the first field of the BIER header carries a service identifier, which is used to identify a Virtual Private Network (VPN) instance.

[0025] The processing module is configured to determine a Virtual Routing Forwarding (VRF) table based on the service identifier and a first correspondence, wherein the first correspondence includes the correspondence between the service identifier and the VRF table;

[0026] The sending module is used to send the multicast message to the first user edge CE device in the VRF table according to the VRF table.

[0027] In one possible implementation, the service identifier is carried in a portion of the destination address in the IPv6 header, the destination address being used to indicate BIER forwarding of the BIER packet.

[0028] In another possible implementation, a portion of the destination address is the argument portion of the destination address.

[0029] In another possible implementation, the first field of the BIER header is a combination of any one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field.

[0030] In another possible implementation, the receiving module is further configured to: receive a control message, the control message including the correspondence between the service identifier and the VRF table; the processing module is further configured to: save the correspondence between the service identifier and the VRF table.

[0031] In another possible implementation, the first correspondence also includes the source address, and the processing module is specifically used to: determine the VRF table based on the source address of the IPv6 header, the service identifier, and the first correspondence.

[0032] Fourthly, a second network device is provided, comprising: a receiving module, a processing module, and a transmitting module.

[0033] The receiving module is used to acquire multicast messages;

[0034] The processing module is used to encapsulate the multicast packet into a BIER packet according to the Virtual Private Network (VPN) instance to which the multicast packet belongs. The BIER packet includes an IPv6 header, an explicit copy BIER header based on bit indexing, and a multicast packet. The destination address of the IPv6 header or the first field of the BIER header carries a service identifier, which is used to identify the VPN instance.

[0035] The sending module is used to send the BIER message to the first network device.

[0036] In one possible implementation, the service identifier is carried in a portion of the destination address in the IPv6 header, the destination address being used to instruct the first network device to perform BIER forwarding of the BIER packet.

[0037] In another possible implementation, a portion of the destination address is the argument portion of the destination address.

[0038] In another possible implementation, the first field of the BIER header is a combination of any one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field.

[0039] In another possible implementation, the processing module is further configured to: assign the service identifier to the VPN instance; and establish a first correspondence, the first correspondence including the correspondence between the service identifier and the VRF table corresponding to the VPN instance.

[0040] In another possible implementation, the sending module is further configured to: send a control message to the first network device, the control message including the correspondence between the service identifier and the VRF table.

[0041] In another possible implementation, the control message is a Border Gateway Protocol (BGP) message.

[0042] Fifthly, a first network device is provided, which has the function of implementing the behavior of the first network device in the above method. The function can be implemented in hardware or in software. The hardware or software includes one or more modules corresponding to the above function.

[0043] In one possible design, the first network device includes a processor and an interface. The processor is configured to support the first network device in performing the corresponding functions in the methods described above. The interface is used to support the first network device in receiving BIER messages sent by the second network device, or to support sending multicast messages to a first user edge CE device in the VRF table according to the VRF table.

[0044] The first network device may further include a memory for coupling with a processor, which stores necessary program instructions and data for the first network device.

[0045] In another possible design, the first network device includes a processor, a transmitter, a receiver, random access memory (RAM), read-only memory (ROM), and a bus. The processor is coupled to the transmitter, receiver, RAM, and ROM via the bus. When the first network device needs to operate, it is booted by a bootloader embedded in the ROM or a basic input / output system, guiding the first network device into normal operation. After the first network device enters normal operation, an application program and operating system are run in the RAM, causing the processor to execute the methods of the first aspect or any possible implementation thereof.

[0046] Sixthly, a first network device is provided, comprising: a main control board and an interface board, and further, a switching board. The first network device is used to execute the methods of the first aspect or any possible implementation thereof. Specifically, the first network device includes modules for executing the methods of the first aspect or any possible implementation thereof.

[0047] In a seventh aspect, a first network device is provided, comprising a control module and a first forwarding sub-device. The first forwarding sub-device includes an interface board, and further may include a switching board. The first forwarding sub-device is used to perform the functions of the interface board in the sixth aspect, and further may also perform the functions of the switching board in the sixth aspect. The control module includes a receiver, a processor, a transmitter, random access memory, read-only memory, and a bus. The processor is coupled to the receiver, transmitter, random access memory, and read-only memory via the bus. When the control module needs to run, it is booted by a bootloader embedded in the read-only memory or a basic input / output system, guiding the control module into normal operation. After the control module enters normal operation, an application program and operating system run in the random access memory, enabling the processor to perform the functions of the main control board in the sixth aspect.

[0048] Understandably, in practical applications, the first network device can contain any number of interfaces, processors, or memory.

[0049] Eighthly, a second network device is provided, wherein the controller has the function of implementing the behavior of the second network device in the above method. The function can be implemented in hardware or in software executed from hardware. The hardware or software includes one or more modules corresponding to the above functions.

[0050] In one possible design, the second network device includes a processor and an interface. The processor is configured to support the second network device in performing the corresponding functions described in the above methods. The interface is used to support the second network device in acquiring multicast messages, or to support the second network device in sending the BIER message to the first network device.

[0051] The second network device may further include a memory for coupling with a processor, which stores program instructions and data necessary for the controller.

[0052] In another possible design, the second network device includes a processor, a transmitter, a receiver, random access memory (RAM), read-only memory (ROM), and a bus. The processor is coupled to the transmitter, receiver, RAM, and ROM via the bus. When the second network device needs to operate, it is booted by a bootloader embedded in the ROM or a basic input / output system, guiding the second network device into normal operation. After the second network device enters normal operation, an application program and operating system run in the RAM, causing the processor to execute the methods of the second aspect or any possible implementation thereof.

[0053] A ninth aspect provides a second network device, the second network device comprising: a main control board and an interface board, and further comprising a switching board. The second network device is used to perform the methods of the second aspect or any possible implementation thereof. Specifically, the second network device includes modules for performing the methods of the second aspect or any possible implementation thereof.

[0054] In a tenth aspect, a second network device is provided, the second network device including a control module and a first forwarding sub-device. The first forwarding sub-device includes an interface board, and further may include a switching board. The first forwarding sub-device is used to perform the functions of the interface board in the ninth aspect, and further may also perform the functions of the switching board in the ninth aspect. The control module includes a receiver, a processor, a transmitter, a random access memory, a read-only memory, and a bus. The processor is coupled to the receiver, transmitter, random access memory, and read-only memory via the bus. When the control module needs to run, it is booted by a bootloader embedded in the read-only memory or a basic input / output system, guiding the control module into normal operation. After the control module enters normal operation, an application program and operating system run in the random access memory, enabling the processor to perform the functions of the main control board in the ninth aspect.

[0055] Understandably, in practical applications, a second network device can contain any number of interfaces, processors, or memory.

[0056] Eleventhly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect or any possible execution thereof.

[0057] In a twelfth aspect, a computer program product is provided, comprising: computer program code that, when run on a computer, causes the computer to perform the methods described in the second aspect or any possible execution thereof.

[0058] In a thirteenth aspect, a computer-readable medium is provided, which stores program code that, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible execution method of the first aspect. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0059] In a fourteenth aspect, a computer-readable medium is provided that stores program code, which, when executed on a computer, causes the computer to perform the methods described in the second aspect or any possible execution method described in the second aspect. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0060] In a fifteenth aspect, a chip is provided, comprising a processor and a data interface, wherein the processor reads instructions stored in a memory through the data interface to execute the method of the first aspect or any possible implementation thereof. In specific implementation, the chip may be implemented as a central processing unit (CPU), a microcontroller unit (MCU), a microprocessor (MPU), a digital signal processor (DSP), a system-on-chip (SoC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a programmable logic device (PLD).

[0061] In a sixteenth aspect, a chip is provided, comprising a processor and a data interface, wherein the processor reads instructions stored in a memory through the data interface to execute the method of the second aspect or any possible implementation thereof. In specific implementation, the chip may be implemented as a central processing unit (CPU), a microcontroller unit (MCU), a microprocessor (MPU), a digital signal processor (DSP), a system-on-chip (SoC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a programmable logic device (PLD).

[0062] In a seventeenth aspect, a system is provided, which includes the aforementioned first network device and second network device. Attached Figure Description

[0063] Figure 1 This is a schematic network diagram of a BIER technology provided in an embodiment of this application.

[0064] Figure 2 This is a schematic diagram of a possible BIERv6 encapsulated message format provided in an embodiment of this application.

[0065] Figure 3 This is a schematic diagram of a possible BIER header format provided in an embodiment of this application.

[0066] Figure 4 This is a schematic diagram of another possible BIER header format.

[0067] Figure 5 It is a process of establishing a BIER forwarding table and forwarding BIERv6 messages based on BIER technology.

[0068] Figure 6 This is a schematic flowchart illustrating a BIER message forwarding method provided in an embodiment of this application.

[0069] Figure 7 This is a schematic flowchart illustrating another BIER message forwarding method provided in the embodiments of this application.

[0070] Figure 8This is a schematic structural diagram of a first network device 800 provided in an embodiment of this application.

[0071] Figure 9 This is a schematic structural diagram of a second network device 900 provided in an embodiment of this application.

[0072] Figure 10 This is a schematic diagram of the hardware structure of the first network device 2000 according to an embodiment of this application.

[0073] Figure 11 This is a schematic diagram of the hardware structure of another first network device 2100 according to an embodiment of this application.

[0074] Figure 12 This is a schematic diagram of the hardware structure of the second network device 2200 according to an embodiment of this application.

[0075] Figure 13 This is a schematic diagram of the hardware structure of another second network device 2300 according to an embodiment of this application. Detailed Implementation

[0076] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0077] This application will present various aspects, embodiments, or features relating to systems comprising multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches are also possible.

[0078] Furthermore, in the embodiments of this application, the words "exemplary," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0079] In the embodiments of this application, "corresponding" and "corresponding" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, their intended meanings are consistent.

[0080] The network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0081] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0082] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0083] Multicast is a data transmission method that uses a single multicast address to efficiently send data simultaneously to multiple receivers on a Transmission Control Protocol (TCP) / Internet Protocol (IP) network. A multicast source sends a multicast stream to members of a multicast group via network links, and all members of the multicast group can receive the stream. Multicast transmission establishes a point-to-multipoint data connection between the multicast source and multicast group members. Because the multicast stream only needs to be transmitted once on each network link, and is only replicated when a tributary appears on the link, multicast transmission improves data transmission efficiency and reduces the likelihood of backbone network congestion.

[0084] Internet Protocol (IP) multicast technology enables efficient point-to-multipoint data transmission in IP networks, effectively saving network bandwidth and reducing network load. Therefore, it has wide applications in real-time data transmission, multimedia conferencing, data copying, Internet Protocol Television (IPTV), gaming, and simulation. This multicast technology uses multicast protocols to build a control plane multicast tree, and then uses the multicast tree to create a logical tree structure in the network plane to achieve multicast point-to-multipoint data forwarding. This intermediate device, which focuses on building a distribution tree, requires maintaining complex multicast forwarding information states. As networks grow larger and multicast packet traffic increases daily, this multicast technology faces growing cost and operational challenges.

[0085] To address this, the industry has proposed a new technique for constructing multicast packet forwarding paths, called bit index explicit replication (BIER). This technique proposes a multicast architecture that does not require the construction of a multicast distribution tree. Figure 1 As shown, routers supporting BIER technology are called bit-forwarding routers (BFRs). A BFR that performs BIER encapsulation on user multicast packets is called a bit-forwarding ingress router (BFIR). A BFR that decapsulates user multicast packets from BIER packets is called a bit-forwarding egress router (BFER). A multicast forwarding domain composed of one or more BFIRs, one or more BFRs, and one or more BFERs is called a BIER domain. The BFIR is located at the ingress position of the BIER domain, acting as the header node for BIER packet forwarding and responsible for encapsulating BIER packets; the BFR is located in the middle position of the BIER domain, acting as the intermediate forwarding node for BIER packets and responsible for forwarding BIER packets; and the BFER is located at the egress position of the BIER domain, acting as the tail node for BIER packet forwarding and responsible for decapsulating BIER packets.

[0086] It should be understood that BFIR and BFER in the BIER domain can also be referred to as edge BFR in the BIER domain.

[0087] To facilitate understanding, the following will be combined with... Figures 2-5 This section provides a detailed description of the relevant technologies of BIER.

[0088] Within the BIER domain, each edge BFR can be configured with a globally unique bit position identifier across the entire BIER subdomain (SD). As an example, each edge BFR is configured with a value as its BFR identifier (BFR ID), which can be a value between 1 and 256. All BFR IDs within the BIER domain form a bit string.

[0089] In this embodiment, when the original multicast message needs to be transmitted in the BIER domain, it needs to be additionally encapsulated with a specific BIER header. The BIER header uses a bit string to identify all the destination devices of the original multicast message. The BFR in the BIER domain can forward the message according to the bit index forwarding table (BIFT) and the bit string carried in the BIER header, ensuring that the original multicast message can be sent to all destination addresses.

[0090] It should be understood that the original multicast message following the BIER header can be an Internet Protocol version 6 (IPv6) multicast message or an Internet Protocol version 4 (IPv4) multicast message; this application does not impose any specific limitations.

[0091] There can be various types of BIER encapsulation, and this application does not impose any specific limitations. As an example, BIER packets can be encapsulated using Multi-Protocol Label Switching (MPLS), which can be called BIER-MPLS encapsulation. As another example, BIER packets can be encapsulated based on Internet Protocol version 6 (IPv6), which can be called BIERv6 encapsulation.

[0092] The following is combined with Figure 2 This paper provides a detailed description of the BIERv6 packaging technology.

[0093] As an example, the message format under BIERv6 encapsulation is: IPv6 header + BIER header + raw multicast message. The BIER header can be included in the IPv6 extension header, while the raw multicast message serves as the payload of the outer IPv6 header.

[0094] In this encapsulation, the IPv6 header and the IPv6 extension header containing the BIER header together constitute the outer header of the inner original multicast message, which can also be referred to as the BIERv6 header in this embodiment.

[0095] This application does not specifically limit the IPv6 extension header that includes the BIER header. For example, the IPv6 extension header can be a destination option header (DOH), or it can be a routing header (RH).

[0096] Figure 2 This is a schematic block diagram of a possible BIERv6 package. See also Figure 5 The BIER header can be located in the IPv6 extension header, such as in the DOH header.

[0097] It should be understood that the options in DOH are a type, length, and value (TLV) format, where the BIER header serves as the option data in the Option TLV of DOH, its format is identified by the Option type in the Option TLV, and its length is identified by the Option length in the Option TLV.

[0098] It should be noted that in the BIERv6 encapsulation, this application embodiment does not specifically limit the format of the BIER header in the DOH, as long as the BIER header contains a bit string field. The following will explain in conjunction with... Figures 3-4 The two possible BIER header formats are described in detail.

[0099] Figure 3 This is a schematic block diagram of a possible BIER header format. For example... Figure 3As shown, the BIER header may include, but is not limited to: a 20-bit bit index forwarding table identifier (BIFT ID), a bit string length (BSL), and other 64-bit (8-byte) fields, such as the traffic class (TC), stack (S), time to live (TTL), entropy, version (Ver), nibble, protocol (proto), operation administration and maintenance (OAM), reserve (RSV), and differential service codepoints (DSCP) fields of the original multicast message following the BIER header.

[0100] The fields in the BIER header are described in detail below.

[0101] (1) BIFT ID field

[0102] With a length of 20 bits, it becomes an MPLS label (L) encapsulated in BIER (Multi-Protocol Label Switching, MPLS). This MPLS label can be called a BIER label, and its subsequent TC / S / TTL fields are in the standard label encoding format. The TC / S / TTL fields will be explained separately below, but will not be detailed here.

[0103] A BIFT ID can be a BIFT-id, which can include a combination of sub-domain (SD), bitstring length (BSL), and set identifier (SI). Different BIFT IDs can correspond to different combinations of SD / BSL / SI.

[0104] It should be understood that different BIFT IDs can map to different SD / BSL / SI combinations. Figure 2 The BIER header format shown does not directly contain the SD / BSL / SI fields. SD / BSL / SI are three implicit fields, and their values ​​need to be mapped from the BIFT ID field.

[0105] 1. Subdomain (SD)

[0106] A BIER domain can be divided and configured into different subdomains (SDs) according to the needs of actual business scenarios to support features such as multi-topology for the Interior Gateway Protocol (IGP). Each BIER domain must contain at least one subdomain, i.e., the default subdomain 0. When dividing into multiple subdomains, each BFR router in the BIER domain must be configured with all subdomains. For example, you can configure one subdomain 0 on each BFR router in the BIER domain to use the system default topology, and then configure another subdomain 1 to use a multicast topology.

[0107] Each subdomain SD is represented by a subdomain identifier (SD-ID). For example, the SD-ID has a value of [0-255] and a length of 8 bits. As an example, different SDs can be configured for different BIER domains depending on the virtual private network (VPN), and different VPNs can be configured to use different SDs. For example, VPN 1 uses SD 0, and VPN 2 uses SD 1.

[0108] It should be noted that multiple VPNs can use the same SD. Different SDs in the BIER domain can be in the same interior gateway protocol (IGP) process or topology, or they can be in different IGP processes or topologies. This application does not specifically limit this.

[0109] 2. Bit string length (BSL)

[0110] The BSL is the length of the bit string included in the BIER header. There can be various BSLs, and this application does not specifically limit them. The smallest BSL is 64 bits, and BSLs can also be 128 bits, 256 bits, 512 bits, 1024 bits, 2048 bits, with the largest BSL being 4096 bits. Specifically, it is identified in the message using 4 bits. For example, when the BSL is 64 bits, it is identified by 0001 in the message; when the BSL is 128 bits, it is identified by 0010; when the BSL is 512 bits, it is identified by 0100; when the BSL is 1024 bits, it is identified by 0101, and so on.

[0111] 3. Set Identifier (SI)

[0112] If the number of BFER devices in the network is greater than 256, to accommodate this situation, the BIER encapsulation contains not only a BitString but also a set identifier (SI). The role of the SI is to divide the BIER device number into multiple different ranges, thereby supporting larger-scale network addressing.

[0113] SI can be understood as a set of multiple edge BFRs or configured BFR IDs in the network. As an example, BSL is 256 bits, but if there are more than 256 edge BFRs or configured BFR IDs in the network, these edge BFRs or BFR IDs need to be divided into different sets. For example, the 256 edge BFRs with BFR IDs from 1 to 256 are set 0 (set index 0, or SI = 0), and the 256 edge BFRs with BFR IDs from 257 to 512 are set 1 (set index 1, or SI = 1).

[0114] After receiving a BIER message, the BFR in the BIER field can determine which SD the BIER message belongs to, the BSL it uses, and the set of SIs that the message belongs to based on the BIFT ID in the BIER header.

[0115] The following lists several possible BIFT ID combinations corresponding to SD / BSL / SI.

[0116] BIFT ID=1: corresponding to SD 0, BSL 256, SI 0 / / equivalent to SD 0 / BSL 256 / SI0

[0117] BIFT ID=2: corresponding to SD 0, BSL 256, SI 1 / / equivalent to SD 0 / BSL 256 / SI1

[0118] BIFT ID=3: corresponding to SD 0, BSL 256, SI 2 / / equivalent to SD 0 / BSL 256 / SI2

[0119] BIFT ID=4: corresponding to SD 0, BSL 256, SI 3 / / equivalent to SD 0 / BSL 256 / SI3

[0120] BIFT ID=5: corresponding to SD 0, BSL 512, SI 0 / / equivalent to SD 0 / BSL 512 / SI0

[0121] BIFT ID=6: corresponding to SD 0, BSL 512, SI 1 / / equivalent to SD 0 / BSL 512 / SI1

[0122] BIFT ID=7: corresponding to SD 1, BSL 256, SI 0 / / equivalent to SD 1 / BSL 256 / SI0

[0123] BIFT ID=8: corresponding to SD 1, BSL 256, SI 1 / / equivalent to SD 1 / BSL 256 / SI1

[0124] BIFT ID=9: corresponding to SD 1, BSL 256, SI 2 / / equivalent to SD 1 / BSL 256 / SI2

[0125] BIFT ID=10: corresponding to SD 1, BSL 256, SI 3 / / equivalent to SD 1 / BSL 256 / SI3

[0126] BIFT ID=11: corresponding to SD 1, BSL 512, SI 0 / / equivalent to SD 1 / BSL 512 / SI0

[0127] BIFT ID=12: corresponding to SD 1, BSL 512, SI 1 / / equivalent to SD 1 / BSL 512 / SI1

[0128] It should be noted that the BIFT ID field value and a<SD,BSL,SI> The triplets correspond to each other. A unique identifier can be obtained through the BIFT-id field.<SD,BSL,SI> Information. It has the following functions: obtaining the length of the BitString in the BIER header through BSL, thus knowing the length of the entire BIER header; knowing whether the BitString represents a BFR-ID of 1~256 or 257~512, etc., through BSL and SI information; and finding the corresponding forwarding table through SD information.

[0129] (2) Bit string field

[0130] Each bit in the bit string is used to identify the edge BFR. For example, the least significant (rightmost) bit in the bit string identifies the BFER with BFR-ID = 1. The second bit from the right in the bit string identifies the BFER with BFR-ID = 2. The forwarding table entries used by the forwarding plane determine which BFERs the packet should be sent to based on the bit string in the packet. When a BFR in the BIER field receives a packet header containing the BIER, it forwards the BIER packet based on the bit string and BIFT ID carried in the BIER header.

[0131] It should be noted that a bit value of 1 indicates that the message should be sent to the BFER device represented by the BFR-ID, while a bit value of 0 indicates that the message should not be sent to the BFER device represented by the BFR-ID.

[0132] Taking BIFT ID=2 as an example, after receiving the BIER message, the BFR can determine that the BIER message belongs to SD 0 based on the BIFT ID in the BIER header. The BSL used in the BIER header is 256 bits and belongs to set 1 (including the set of 256 edge BFRs with BFR IDs from 257 to 512).

[0133] (3) Traffic Class (TC) field

[0134] Identify the priority of the message.

[0135] (4) Stack (S)

[0136] S is the bottom stack marker. In the BIER header, the value of this marker is 1, which means that this MPLS label is the bottom stack marker of the entire label stack.

[0137] (5) Version number (Ver) field

[0138] It is 4 bits long and is the IP version number. A value of 4 represents IPv4 and a value of 6 represents IPv6.

[0139] (6) Entropy field

[0140] Used for load balancing. BIER forwarding may perform equal-cost load balancing, in which case load balancing must select the same path for two BIER packets with the same Entropy and BitString. That is, multiple packets belonging to the same traffic have the same entropy, while multiple packets from different traffic have different entropies. When packets are forwarded, different traffic can be distributed to different links based on entropy, while multiple packets of the same traffic will use the same link.

[0141] To ensure that different entropies identify different flows, BFIR devices are required to assign different entropy labels based on different flows when allocating entropies, and these labels cannot be duplicated.

[0142] (7) Protocol (proto) field

[0143] The upstream label is used to identify the format of the payload following the BIER header. For example, values ​​4 and 6 represent IPv4 and IPv6 packets respectively, and value 2 represents an upstream labeled MPLS packet. This is a protocol value used in multicast virtual private networks (MVPNs) over BIER. The reason for using the upstream label is that multicast is a point-to-multipoint transmission. The sending provider edge (PE) device can assign a unique label and send it to the receiving PE device through the control plane. The data packet uses the label assigned by the sending PE device and is identified by the receiving PE device. For the receiving PE device, this label is not assigned by itself but by the sending PE device; it is called the upstream label.

[0144] (8) Nibble

[0145] A fixed 4-bit value of 0101. This field is used to distinguish the services carried by MPLS, differentiating between BIER, IPv4, and IPv6. This is because in MPLS encapsulation forwarding, the IPv4 or IPv6 header behind the label stack is sometimes checked to support ECMP.

[0146] (9) BFIR-id

[0147] The BFIR-ID is used by BFIR devices to encapsulate and send BIER messages using subdomains. Therefore, the BFIR-id field needs to be filled with the BFR-ID of that device within that subdomain. The BFIR-id identifies which BFIR source the multicast stream from, uniquely identifying a multicast stream.

[0148] (10)bit string

[0149] The destination device set string of the BIER message.

[0150] Figure 3 This is a schematic diagram of another possible BIER header format. Compared to... Figure 2 Regarding the BIER header format shown, Figure 3 The BIER header format shown does not include the BIFT-ID field, but instead displays three fields: SD / BSL / SI. In other words, Figure 3 The BIER header format shown directly contains the three fields SD / BSL / SI, without needing to map the SD / BSL / SI values ​​from the BIFT ID field.

[0151] It should be noted that, Figure 3 The fields included in the BIER header format shown are the same as Figure 2 The fields contained in the BIER header format shown are similar; for specific details... Figure 3 Please refer to the descriptions of each field in the BIER header format shown. Figure 2 The explanations in the text will not be repeated here.

[0152] The fields contained in the outer IPv6 header are described in detail below.

[0153] Version number (Ver): The version number of the IP address. A value of 6 represents IPv6.

[0154] Traffic class (TC) field: identifies the priority of the packet.

[0155] The flow label (FL) field allows you to assign the same flow label to multiple packets belonging to the same traffic flow, and a different flow label value to multiple packets from different traffic flows. When packets are forwarded, the flow label can be used to distribute different traffic flows onto different links, while multiple packets of the same traffic flow will use the same link. In other words, the flow label is used to distinguish real-time traffic, and different flow labels can identify different data flows. In this way, network devices in the BIER domain can also more efficiently distinguish different data flows based on the flow label field.

[0156] The payload length (PL) field indicates the length of the message.

[0157] Next Header (NH) field: indicates the type of the next header in the message, such as representing an IPv6 extension header.

[0158] The Hop Limit (HL) field indicates the limit on the number of messages.

[0159] Source address (SA) field: Identifies the source address of the message.

[0160] Destination address (DA) field: Identifies the destination address of the message.

[0161] The following is based on Figure 5 Taking this as an example, the process of establishing a BIER forwarding table and forwarding BIER messages based on BIER technology is described in detail.

[0162] like Figure 5 The BIER domain shown can include devices A through F. Devices A, D, E, and F belong to the edge BFRs within the BIER domain, while devices B and C are intermediate forwarding devices within the BIER. Specifically, device A is located at the entry point of the BIER domain and is responsible for BIER encapsulation of the original multicast packets, corresponding to... Figure 1 In the BIER domain, devices D, E, and F are located at the exit point of the BIER domain and are responsible for decapsulating the original multicast messages from the BIER messages. Figure 1 BFER in the middle.

[0163] In this embodiment of the application, a unique BFR-ID can be assigned to each edge BFR within a BIER domain. For example, in Figure 5 In the example, the BFR-IDs configured for devices A, D, E, and F are 4, 1, 3, and 2, respectively. Intermediate forwarding BFRs, such as devices B and C, are not assigned BFR-IDs.

[0164] It should be noted that in the embodiments of this application, "ID" and "id" can sometimes be used interchangeably. It should be pointed out that when the distinction is not emphasized, their intended meanings are consistent. Specifically, BFR-ID in this application can refer to... Figure 5 The id in the middle.

[0165] When device A, acting as the ingress node in an IPv6 network, receives a multicast source (SRC) user multicast message, it encapsulates the user multicast message with a BIERv6 header. This results in an encapsulated BIERv6 message consisting of an outer IPv6 header and an IPv6 extension header containing the BIER header. The BIER header within the IPv6 extension header carries a bit string representing the set of destination devices.

[0166] The bit string encapsulated in the BIER header identifies all the destination devices for this traffic. For example, the bit string corresponding to device D with BFR-ID 1 is 0001, the bit string corresponding to device F with BFR-ID 2 is 0010, the bit string corresponding to device E with BFR-ID 3 is 0100, and the bit string corresponding to device A with BFR-ID 4 is 1000.

[0167] It should be understood that the BFR-ID value assigned to each edge BFR within a BIER domain can be flooded to other BFRs within the BIER domain via routing protocols. The flooded BIER information also includes the IP address and encapsulation information of the edge BFR. For example, the flooded BIER information for device A will carry device A's IP address and BIFR-ID. BFRs within the BIER domain (e.g., Figure 5 Device F) can create BIFT entries based on the BIER information from flooding, so as to facilitate Figure 5 After receiving the BIER message, device F in the process forwards the BIER message to the destination device according to the established BIFT table entry.

[0168] For device A, if it needs to send a BIER message to the BFERs with BFR-IDs of 1, 2, and 3, the BIER message must first be sent to device A's neighbor (device B). The edge BFR with BFR-ID 4 is itself. Therefore, the BIFT table entry established by device A is as follows:

[0169] Forwarding entry 1: Neighbor (Nbr) = B, forwarding bit mask (FBM) = 0111;

[0170] Forwarding item 2: Nbr* = A, FBM = 1000.

[0171] Among them, forwarding table entry 1 is used to indicate that when any one of the first, second, or third bits from right to left of the bit string of a BIER message is 1, the BIER message will be sent to the neighbor of device A (device B). Nbr = B indicates that the neighbor of device A is device B.

[0172] Forwarding entry 2 indicates that when the fourth bit from right to left in the bit string of a BIER message is 1, the BIER message will be sent to device A. Since device A is itself, it will remove the BIER header and forward the message according to the information in the original multicast message. It should be noted that the * symbol in forwarding entry 2 identifies the Nbr as itself; for example, for device A, Nbr* = A means that device A's neighboring device is itself. Similarly, Figure 5 Other devices in the system can also create BIFT entries based on their own neighboring devices. For details on BIFT entries created by other devices, please refer to [link to documentation]. Figure 5 This will not be elaborated upon here.

[0173] When device A, acting as the BFIR (Border Frontier Gateway) entry point in the BIER domain, receives the original multicast message, it encapsulates the original multicast message with a BIER header. For ease of description, it will be referred to as entry device A below. As an example, upon receiving the original multicast message, entry device A can determine the destination device of the original multicast message based on the BFR-ID flooded by the Border Gateway Protocol (BGP).

[0174] For example, the original multicast message is received by destination device E with BFR-ID 3, destination device F with BFR-ID 2, and destination device D with BFR-ID 1. Ingress device A encapsulates the BIER header with bit string 0111 and forwards the encapsulated BIER message to neighbor device B according to the aforementioned forwarding table entry 1. When sending, the destination address field in the IPv6 header can use B's unicast address (e.g., B::100).

[0175] After receiving the BIER message, device B determines, based on the bit string 0111 and the BIFT entry, that it needs to send the BIER message to both device C and device E. For example, when device B sends the BIER message to device C, it can perform an AND operation on the bit string (0111) in the BIER header and the FBM field corresponding to Nbr=C in the BIFT entry. In this embodiment, the result of the AND is 0011. Therefore, device B can modify the bit string in the BIER header to 0011 and send it to device C. When sending, the unicast address field in the IPv6 header can use the unicast address of C (e.g., C::100). Similarly, when device B sends the BIER message to device E, it can modify the bit string in the BIER header to 0100. When sending, the unicast address field in the IPv6 header can use the unicast address of E (e.g., E::100).

[0176] For device E, since device E determines its neighbor device E as itself based on the identifier* in the forwarding table, device E, as the BFER at the BIER domain exit, can decapsulate the original multicast message from the BIER message and forward the multicast message to customer edge 1 (CE1) based on the information in the inner original multicast message (e.g., the destination address in the original multicast message).

[0177] Similarly, device C sends the packet to D and F based on the BIER header and its bit string information. When sending, the destination address field in the IPv6 header can use the unicast address of D (e.g., D::100) and the unicast address of F (e.g., D::100).

[0178] For device D, since device D determines that its neighbor device D is itself based on the identifier * in the forwarding table, device D, as the BFER at the BIER domain exit, can decapsulate the original multicast message from the BIER message and forward the multicast message to CE2 based on the information in the inner original multicast message (e.g., the destination address in the original multicast message).

[0179] For device F, since device F determines its neighbor device F as itself based on the identifier * in the forwarding table, device F, as the BFER at the BIER domain exit, can decapsulate the original multicast message from the BIER message and forward the multicast message to CE3 based on the information in the inner original multicast message (e.g., the destination address in the original multicast message).

[0180] Specifically, for a BFER at the BIER domain exit, such as device E, after receiving a BIER message, it needs to determine the VPN instance to which the multicast message belongs, determine the virtual route forwarding (VRF) table corresponding to the VPN instance, and forward the multicast message to the next hop in the VRF table (e.g., CE1) based on the information in the original multicast message (e.g., the destination address in the original multicast message) and the VRF table.

[0181] It should be understood that a VPN is a technology for building a private network on a shared network. Private network routes are not visible on the public network, so they can be stored in a VRF table.

[0182] It should also be understood that, in the forwarding plane, the service identifier can also be called the VPN service identifier, which is used to identify a VPN instance.

[0183] In a traditional technical solution, the service identifier is carried in the MPLS label, which can also be called the VPN label. That is, when the Proto field in the BIER header is 2, it indicates that the packet following the BIER header is a VPN label + IP packet. The VPN label is a 4-byte MPLS label used to identify a mobile virtual private network (MVPN). Specifically, in the control plane, the BFIR generates the VPN label, associates the VPN label value with the VRF identifier, and sends this information along with the BFIR-ID to the BFER. After receiving the VPN label value and VRF identifier, the BFER associates it with the corresponding VRF. In the data plane, when the BFIR receives a packet that needs to be carried by an MVPN, it encapsulates the packet with a BIER header and the corresponding VPN label. When the BFER receives a packet encapsulated with a BIER header and VPN label, it matches the VPN label with the corresponding VRF table, and the VRF table forwards the packet.

[0184] In the above technical solution, because the BIER message contains an MPLS label layer, it is impossible to achieve full network de-MPLS, which adds extra complexity to the device.

[0185] In another traditional technical solution, the VPN instance is identified by the source address (SA) in the BIERv6 header. That is, the same BFIR (i.e., the ingress edge node) may be assigned multiple source IPv6 addresses, each representing a different VPN instance. In the control plane, the BFIR generates different source IPv6 addresses, called Src.DT, for different VPN instances, associates these source IPv6 addresses with VRF instances, and sends this mapping relationship to the BFIR. Upon receiving the mapping relationship, the BFIR associates it with the corresponding VRF table. In the data plane, when the BFIR receives a packet that needs to be carried by an MVPN, it encapsulates it with a BIERv6 header and identifies the VPN instance using the source address (SA) within the BIERv6 header. When the BFIR receives a packet encapsulated with a BIERv6 header, it identifies the SA in the BIERv6 header, determines the corresponding VRF table based on the VPN instance identified by the SA, and then forwards the packet using that VRF table.

[0186] In the traditional technical solutions described above, the IPv6 source address in the BIERv6 header is used to identify the VPN instance, which requires the management and allocation of the IPv6 source address needed to identify the VPN instance.

[0187] In view of this, this application proposes a method for forwarding BIER packets. By selecting an appropriate field in the BIER packet to carry the VPN service identifier, it is possible to identify VPN instances at the egress edge node without managing and allocating the IPv6 source address required to identify the VPN instance, which is relatively simple to implement.

[0188] Figure 6 This is a schematic flowchart illustrating a BIER message forwarding method provided in an embodiment of this application. See also... Figure 6 The method may include steps 610-630, which will be described in detail below with reference to steps 610-630.

[0189] Step 610: The first network device receives the BIER message sent by the second network device. The BIER message includes an IPv6 header, a BIER header, and a multicast message. The destination address in the IPv6 header or the first field of the BIER header carries the service identifier.

[0190] As an example, the first network device can correspond to Figure 5 The network equipment (e.g., equipment D, equipment E, equipment F) in the network can be the corresponding second network device. Figure 5 The entry device (e.g., device A) in the system.

[0191] The destination address in the IPv6 header of a BIER message, or the service identifier carried in the first field of the BIER header, is used to identify a Virtual Private Network (VPN) instance. It should be understood that the service identifier can also be called the VPN service identifier.

[0192] In one possible implementation, the destination address of the IPv6 header of the BIER packet carries a service identifier as an example. This destination address is used to indicate BIER forwarding of the BIER packet, and the service identifier can be carried in a portion of the destination address, for example, in the argument portion of the destination address.

[0193] The following is a detailed description of this implementation method.

[0194] Segment routing (SR) uses segment identity (segment ID) in packets to indicate instructions for operations within the network. For example, in segment routing over IPv6 (SRv6), the IPv6 address is used as an SRv6 SID, and this SRv6 SID is programmed by dividing the 128-bit SRv6 SID into three parts: Localor, Function, and Argument. The Localor is used for route addressing, the Function indicates the corresponding operation instruction, and the Argument carries the parameters needed to execute that instruction.

[0195] BIERv6 is a technology that implements BIER forwarding in the IPv6 data plane. It uses a special IPv6 destination address (called End.BIER) to instruct devices to perform BIER forwarding. End.BIER is encapsulated in the destination address DA field of the IPv6 header and is an SRv6 SID with special indication function, which instructs the device to perform BIER forwarding locally.

[0196] It should be understood that the IPv6 address used in the destination address of a BIER packet is not an ordinary IPv6 address, but a specific IPv6 address used for BIER packet processing, called End.BIER. After configuring this End.BIER address, the BFR router creates a 128-bit masked forwarding table entry for that address in the forwarding information base (FIB), and the forwarding table entry identifies this address as End.BIER. When the router receives an IPv6 packet, it first looks up the destination address in the FIB. If the FIB lookup result is an End.BIER address, it will perform End.BIER-specific actions, that is, continue processing the BIER header in the IPv6 extended header. Otherwise, if it is an ordinary IPv6 destination address, the FIB lookup result indicates that the packet is an IPv6 packet sent to this router containing a destination options extended header, and the packet may be sent to the CPU for processing, thus failing to achieve the purpose of data plane processing.

[0197] This application embodiment can extend End.BIER so that End.BIER can not only instruct BIER forwarding, but also carry VPN-related parameters, such as VPN service identifiers. Specifically, End.BIER can be divided into three parts: Localor, Function, and Argument. The Localor and Function fields indicate BIER forwarding operations, and the Argument field carries the aforementioned VPN service identifier.

[0198] It should be noted that the length of the Argument field is not specifically limited in this embodiment and can be defined according to actual needs. For example, taking a VPN service identifier as a 20-bit MPLS label value as an example, the length of the Argument field can be defined as 20 bits.

[0199] In another possible implementation, taking the service identifier carried in the first field of the BIER message as an example, this first field can be any combination of one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field. Specifically, the VPN service identifier can be carried by one field in the BIER header, or it can be carried by multiple fields in the BIER header; this application does not impose any specific limitations on this.

[0200] In this embodiment of the application, the fields in the BIER header that carry VPN service identifiers may include, but are not limited to: DSCP field, proto field, and BFIR-id field.

[0201] Step 620: The first network device determines the VRF table based on the service identifier and the first correspondence relationship, wherein the first correspondence relationship includes the correspondence between the service identifier and the VRF table.

[0202] After obtaining the service identifier, the first network device can determine the corresponding VRF table based on the first correspondence and the service identifier. The first correspondence includes the correspondence between the service identifier and the VRF table.

[0203] Prior to step 620, the method further includes: a first network device determining a first correspondence between the service identifier and the VRF table. There are various specific implementation methods, which are described in detail below.

[0204] In one possible implementation, the first network device can locally generate a corresponding service identifier for the VRF instance and save the correspondence between the service identifier and the VRF table corresponding to the VRF instance. In this implementation, the first network device can also send the locally generated service identifier for the VRF instance to the second network device, so that the second network device, upon receiving a multicast message, can encapsulate the corresponding service identifier in a BIER message according to the VRF instance to which the multicast message belongs. For the specific encapsulation method, please refer to the description in step 610, which will not be repeated here.

[0205] In another possible implementation, the first network device receives a control message, which includes a correspondence between a service identifier and a VRF table, and the first network device stores the correspondence.

[0206] Step 630: The first network device sends a multicast message to the first user edge CE device in the VRF table according to the VRF table.

[0207] The first network device, acting as the egress device, can decapsulate BIER messages to obtain inner multicast messages, and then forward the multicast messages based on the destination address of the multicast messages and the determined VRF table.

[0208] Specifically, the VRF table may include multiple VRF entries, each of which includes the next hop to the destination address. The first network device can determine the VRF entry in the VRF table based on the destination address of the multicast message and send the multicast message to the next hop in that VRF entry (e.g., the first CE device).

[0209] In the above technical solution, by carrying the service identifier through the destination address of the IPv6 header of the BIER packet or the first field of the BIER header, it is not necessary to manage and allocate the IPv6 source address required to identify the VPN instance, nor is it necessary to add an additional MPLS label layer. The implementation is relatively simple and reduces the complexity of device implementation.

[0210] The following is based on Figure 5 Taking the BIER field shown as an example, combined with Figure 7 This application provides a detailed description of a specific implementation process of the BIER message forwarding method provided in the embodiments of this application.

[0211] It should be understood that Figure 7 The examples provided are merely to help those skilled in the art understand the embodiments of this application, and are not intended to limit the embodiments to the specific numerical values ​​or specific scenarios illustrated. Those skilled in the art will understand based on the following... Figure 7 The examples can obviously be modified or changed in various ways, and such modifications and changes also fall within the scope of the embodiments of this application.

[0212] Figure 7 This is a schematic flowchart illustrating another BIER message forwarding method provided in an embodiment of this application. Figure 7 As shown, the method may include steps 710-750, which will be described in detail below.

[0213] Step 710: The entry device in the BIER domain determines and saves the mapping relationship between VPN service identifiers and VRFs.

[0214] Taking device A as the entry device of the BIER domain as an example, device A needs to generate the corresponding VPN service identifier for the VPN and generate the mapping relationship between the VPN service identifier and the VRF table.

[0215] As an example, a VPN service identifier can be a 20-bit MPLS label value, and each VPN service identifier can uniquely correspond to a VRF table on both the ingress and egress edge nodes. For example, VPN service identifier 100 can be used to represent VRF1 table on both the ingress and egress edge nodes. Similarly, VPN service identifier 101 can be used to represent VRF2 table on both the ingress and egress edge nodes.

[0216] As an example, a VPN service identifier can be a globally unique identifier. A globally unique identifier means that different VPN service identifiers are used for different multicast groups.

[0217] BFIR1 can locally store the mapping relationship between VPN service identifiers and VRF tables. As an example, Table 1 below lists one possible mapping relationship.

[0218] Table 1. Mapping Relationship between VPN Service Identifiers and VRF Tables

[0219] VPN service identifier VRF table 100 VRF1 101 VRF2 102 VRF3 … …

[0220] Optionally, if the VPN service identifier is a local identifier, the same VPN service identifier can be used for different multicast groups if the ingress or egress nodes are different. In this implementation, the BFER needs to maintain the mapping relationship between the source IPv6 address, the VPN service identifier, and the VRF table.

[0221] Step 720: The BIER domain's egress device determines and saves the mapping relationship between VPN service identifiers and VRF tables.

[0222] Taking device E as the egress device of the BIER domain as an example, there are multiple ways for device E to determine the mapping relationship between the VPN service identifier and the VRF table, and this application does not specifically limit this. Several possible implementation methods are listed below.

[0223] In one possible implementation, the mapping relationship between the VPN service identifier and the VRF table can be configured on device E. For example, if the VPN service identifier is a global identifier, the mapping relationship between the VPN service identifier and the VRF table can be configured as shown in Table 1. Alternatively, if the VPN service identifier is a local identifier, the mapping relationship can be configured as shown in Table 2.

[0224] Table 2. Mapping relationship between source IPv6 address, VPN service identifier, and VRF table.

[0225] Source IPv6 address VPN service identifier VRF table Address 1 100 VRF1 Address 1 101 VRF2 Address 1 102 VRF3 … …

[0226] In another possible implementation, after determining the mapping relationship between the VPN service identifier and the VRF table, the ingress device in the BIER domain can announce the mapping relationship to device E via a control message. For example, if the VPN service identifier is a global identifier, device E receives the mapping relationship between the VPN service identifier and the VRF table via a control message and locally stores the mapping relationship between the VPN service identifier and the VRF table as shown in Table 1. Alternatively, if the VPN service identifier is a local identifier, the control message sent by the ingress device in the BIER domain to device E also includes the IPv6 address of the ingress device in the BIER domain. Device E locally stores the mapping relationship between the source IPv6 address (the IPv6 address of BFIR1), the VPN service identifier, and the VRF table as shown in Table 2.

[0227] For example, the aforementioned control message can be a border gateway protocol (BGP) message. The ingress device in the BIER domain can use BGP messages to announce the mapping relationship between the VPN service identifier and the VRF table to device E.

[0228] Step 730: The entry device in the BIER domain encapsulates the BIER message and sends the BIER message to the BFR.

[0229] Taking device A as the entry device for the BIER domain as an example, after receiving a multicast message, device A encapsulates the multicast message with BIER according to the VPN instance to which the multicast message belongs, resulting in a BIER message. The BIER message includes an IPv6 header, a BIER header, and an inner multicast header.

[0230] The BIER message can carry a VPN service identifier, which is used to identify the aforementioned VPN instance. There are several possible implementations, and this application does not specify any particular one. One possible implementation is to carry the VPN service identifier through the destination address (DA) in the IPv6 header. Another possible implementation is to carry the VPN service identifier through a field in the BIER header.

[0231] In the implementation where the destination address (DA) carries the VPN service identifier, each BIER forwarding device needs to reserve an Argument field in the IPv6 address of the End.BIER. Specifically, when configuring the End.BIER used for BIER forwarding, each device can configure an address block to represent the Argument field.

[0232] The following example uses the Argument field carrying a 20-bit VPN service identifier. Figure 7 The configuration of the reserved Argument field on the BIER forwarding node is explained below.

[0233] On device A, the configuration is: end-bier 2001:db8:1000:: / 108arguments 20

[0234] On device B, configure: end-bier 2001:db8:1001:: / 108arguments 20

[0235] On device C, configure: end-bier 2001:db8:2000:: / 108arguments 20

[0236] Configuration on device E: end-bier 2001:db8:3000:: / 108arguments 20

[0237] Here, end-bier represents the IPv6 address (End.BIER) configured for BIER forwarding. 2001:db8:1000:: / 108 is an IPv6 address block (End.BIER) with a mask length of 108, and arguments 20 indicates that the lowest 20 bits in this address block are used to represent the Argument field.

[0238] It should be noted that in this embodiment of the application, when the VPN service identifier is carried through the Argument field of End.BIER, the Argument field changes when the VPN service identifier is different, and the IPv6 address (End.BIER) of the device will also change.

[0239] For example, if the VPN service identifier is 100, the destination address DA in the IPv6 header of the BIER packet sent by device A to device B will use the address 2001:db8:1001::64. Here, 64 is hexadecimal, which corresponds to 100 in decimal, meaning the VPN service identifier is 100.

[0240] For example, if the VPN service identifier is 101, in the BIER message sent by device A to device B, the destination address DA in the IPv6 header will use the address 2001:db8:1001::65. Here, 65 is hexadecimal, corresponding to 101 in decimal, that is, the VPN service identifier is 101.

[0241] In the implementation method that carries the VPN service identifier through fields in the BIER header, each BIER forwarding device does not need to reserve the Argument field in the IPv6 address of End.BIER. Figure 5 The BIER forwarding nodes shown can each configure an address when configuring the IPv6 address (End.BIER) used for BIER forwarding.

[0242] On device A, configure: end-bier 2001:db8:1000::1234

[0243] Configuration on device B: end-bier 2001:db8:1001::1234

[0244] Configure on device C: end-bier 2001:db8:2000::1234

[0245] Configuration on device E: end-bier 2001:db8:3000::1234

[0246] Here, end-bier represents the IPv6 address configured for BIER forwarding (End.BIER). In this example configuration, each node is configured with a full 128-bit IPv6 address.

[0247] In this implementation, the VPN service identifier is carried through a field in the BIER header, and the device's IPv6 address (End.BIER) remains unchanged.

[0248] For example, if the VPN service identifier is 100, in the BIER message sent by device A to device B, the destination address DA in the IPv6 header will use the address 2001:db8:1001::1234. That is, the VPN service identifier 100 is encapsulated in the field of the BIER header according to the method of this embodiment. Device B then copies the message and sends it to devices C and D, respectively encapsulating the addresses of devices C and D as 2001:db8:2000::1234 and 2001:db8:3000::1234. The VPN service identifier 100 in the field of the BIER header remains unchanged.

[0249] For example, if the VPN service identifier is 101, in the BIER message sent by device A to device B, the destination address DA in the IPv6 header will use the address 2001:db8:1001::1234. That is, the VPN service identifier 101 is encapsulated in the field of the BIER header according to the method of this embodiment. Device B then copies the message and sends it to devices C and D. The addresses of devices C and D are encapsulated accordingly as 2001:db8:2000::1234 and 2001:db8:3000::1234, respectively. The VPN service identifier 101 in the field of the BIER header remains unchanged.

[0250] Step 740: The BFR sends the received BIER message to the egress device of the BIER domain.

[0251] After receiving the BIER message, the BFR can send the BIER message to the egress device of the BIER domain.

[0252] Taking VPN service identifier 100 as an example, the destination address DA in the IPv6 header of the BIER packet sent by BFR to device E will use the address 2001:db8:3000::64. Here, 64 is hexadecimal, corresponding to 100 in decimal, that is, the VPN service identifier is 100.

[0253] Taking VPN service identifier 101 as an example, the destination address DA in the IPv6 header of the BIER packet sent by BFR to device E will use the address 2001:db8:3000::65. Here, 65 is hexadecimal, which corresponds to 101 in decimal, that is, the VPN service identifier is 101.

[0254] Step 750: The egress device of the BIER domain receives the BIER message and forwards the message by looking up the corresponding VRF table.

[0255] After receiving a BIER message, the egress device of the BIER domain can obtain the VPN service identifier from the BIER message. For example, the VPN service identifier is carried in a field of the BIER header, and the egress device of the BIER domain can obtain the VPN service identifier from this field. Another example is that the VPN service identifier is carried in the destination address (DA) in the IPv6 header, and the egress device of the BIER domain can obtain the VPN service identifier from the DA.

[0256] After obtaining the VPN service identifier, the egress device in the BIER domain can determine the corresponding VRF table based on the mapping relationship between the VPN service identifier and the VRF table stored locally, and forward multicast packets according to the VRF table.

[0257] For example, device E, as the egress device of the BIER domain, obtains a VPN service identifier of 100. Based on the mapping relationship shown in Table 1, it can determine that 100 corresponds to the VRF1 table. Device E can determine a specific VRF entry in the VRF table based on the destination address of the multicast message, and send the multicast message to the next hop (e.g., the first CE device) in that VRF entry.

[0258] In the above technical solution, the VPN service identifier is carried by using the IPv6 destination address encapsulated by BIER or a portion of the BIER header field. The egress edge node only needs to read the IPv6 destination address or a portion of the BIER header field to obtain the VPN service identifier. This avoids the IPv6 source address management and allocation required by traditional technical solutions that use IPv6 source addresses to identify VPN instances.

[0259] The above text combined Figures 1 to 7 This application describes in detail a BIER message forwarding method provided by an embodiment of the present application. The following will combine... Figures 8 to 13 The embodiments of the apparatus described in this application are described in detail below. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the foregoing method embodiments.

[0260] Figure 8 This is a schematic structural diagram of a first network device 800 provided in an embodiment of this application. Figure 8 The first network device 800 shown can perform the corresponding steps executed by the first network device in the method of the above embodiments. For example... Figure 8 As shown, the first network device 800 includes: a receiving module 810, a processing module 820, and a transmitting module 830.

[0261] The receiving module 810 is used to receive a BIER message sent by the second network device. The BIER message includes an Internet Protocol version 6 (IPv6) header, an explicit copy BIER header based on bit index, and a multicast message. The destination address of the IPv6 header or the first field of the BIER header carries a service identifier, which is used to identify a Virtual Private Network (VPN) instance.

[0262] Processing module 820 is configured to determine a Virtual Routing Forwarding (VRF) table based on the service identifier and a first correspondence relationship, wherein the first correspondence relationship includes the correspondence relationship between the service identifier and the VRF table;

[0263] The sending module 830 is used to send the multicast message to the first user edge CE device in the VRF table according to the VRF table.

[0264] Optionally, the service identifier is carried in a portion of the destination address in the IPv6 header, the destination address being used to indicate BIER forwarding of the BIER packet.

[0265] Optionally, a portion of the destination address is the argument portion of the destination address.

[0266] In another possible implementation, the first field of the BIER header is a combination of any one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field.

[0267] Optionally, the receiving module 810 is further configured to: receive a control message, the control message including the correspondence between the service identifier and the VRF table; the processing module 820 is further configured to: save the correspondence between the service identifier and the VRF table.

[0268] Optionally, the first correspondence may further include the source address, and the processing module 820 is specifically used to: determine the VRF table based on the source address of the IPv6 header, the service identifier, and the first correspondence.

[0269] Figure 9 This is a schematic structural diagram of a second network device 900 provided in an embodiment of this application. Figure 9 The second network device 900 shown can perform the corresponding steps executed by the second network device in the method of the above embodiments. For example... Figure 9 As shown, the second network device 900 includes: a receiving module 910, a processing module 920, and a transmitting module 930.

[0270] Receiver module 910 is used to acquire multicast messages;

[0271] The processing module 920 is used to encapsulate the multicast packet into a BIER packet according to the Virtual Private Network (VPN) instance to which the multicast packet belongs. The BIER packet includes an Internet Protocol version 6 (IPv6) header, an explicit copy BIER header based on bit indexing, and a multicast packet. The destination address of the IPv6 header or the first field of the BIER header carries a service identifier, which is used to identify the VPN instance.

[0272] The sending module 930 is used to send the BIER message to the first network device.

[0273] Optionally, the service identifier is carried in a portion of the destination address in the IPv6 header, the destination address being used to instruct the first network device to perform BIER forwarding of the BIER packet.

[0274] Optionally, a portion of the destination address is the argument portion of the destination address.

[0275] Optionally, the first field of the BIER header is a combination of any one or more of the following fields: Differential Service Code Point (DSCP) field, Bit Forwarding Ingress Router Identifier (BFIR-id) field, and Protocol (proto) field.

[0276] Optionally, the processing module 920 is further configured to: allocate the service identifier to the VPN instance; and establish a first correspondence, wherein the first correspondence includes the correspondence between the service identifier and the VRF table corresponding to the VPN instance.

[0277] Optionally, the sending module 930 is further configured to: send a control message to the first network device, the control message including the correspondence between the service identifier and the VRF table.

[0278] Optionally, the control message is a Border Gateway Protocol (BGP) message.

[0279] Figure 10 This is a schematic diagram of the hardware structure of the first network device 2000 according to an embodiment of this application. Figure 10 The first network device 2000 shown can execute the corresponding steps performed by the first network device in the method of the above embodiments.

[0280] like Figure 10 As shown, the first network device 2000 includes a processor 2001, a memory 2002, an interface 2003, and a bus 2004. The interface 2003 can be implemented wirelessly or via a wired connection; specifically, it can be a network interface card (NIC). The processor 2001, memory 2002, and interface 2003 are connected via the bus 2004.

[0281] The interface 2003 may specifically include a transmitter and a receiver, used by the first network device to perform the aforementioned sending and receiving. For example, the interface 2003 is used to receive BIER messages sent by a second network device, or to send the multicast messages to the first user edge CE device in the VRF table according to the VRF table.

[0282] The processor 2001 is used to execute the processes performed by the first network device in the above embodiments. For example, it is used to determine the virtual route forwarding (VRF) based on the service identifier and the first correspondence; and / or other processes using the techniques described herein. The memory 2002 includes an operating system 20021 and an application program 20022, used to store programs, code, or instructions, which, when executed by the processor or hardware device, can complete the processing procedures involving the first network device in the method embodiments. Optionally, the memory 2002 may include read-only memory (ROM) and random access memory (RAM). The ROM includes a basic input / output system (BIOS) or an embedded system; the RAM includes the application program and the operating system. When the first network device 2000 needs to be run, the system is booted through the BIOS embedded in the ROM or the bootloader in the embedded system, guiding the first network device 2000 into normal operation. After the first network device 2000 enters normal operation, the application program and the operating system running in the RAM complete the processing procedures involving the first network device 2000 in the method embodiments.

[0283] Understandable, Figure 10 Only a simplified design of the first network device 2000 is shown. In practical applications, the first network device can contain any number of interfaces, processors, or memory.

[0284] Figure 11 This is a schematic diagram of the hardware structure of another first network device 2100 according to an embodiment of this application. Figure 11 The first network device 2100 shown can perform the corresponding steps executed by the first network device in the method of the above embodiments.

[0285] like Figure 11 The first network device 2100 includes a main control board 2110, an interface board 2130, a switching board 2120, and an interface board 2140. The main control board 2110, interface boards 2130 and 2140, and the switching board 2120 are interconnected via a system bus and a system backplane. The main control board 2110 performs system management, device maintenance, and protocol processing functions. The switching board 2120 performs data exchange between the interface boards (also called line cards or service boards). Interface boards 2130 and 2140 provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and forward data packets.

[0286] The interface board 2130 may include a central processing unit 2131, a forwarding table entry memory 2134, a physical interface card 2133, and a network processor 2132. The central processing unit 2131 is used to control and manage the interface board and communicate with the central processing unit on the main control board. The forwarding table entry memory 2134 is used to store table entries, such as BIFT mentioned above. The physical interface card 2133 is used to receive and send traffic.

[0287] It should be understood that the operation on interface board 2140 in this embodiment is the same as the operation on interface board 2130, and will not be described again for the sake of simplicity.

[0288] It should be understood that the first network device 2100 in this embodiment may correspond to the functions and / or various steps implemented in the above method embodiments, which will not be repeated here.

[0289] Furthermore, it should be noted that there may be one or more main control boards, including a primary and a backup main control board. There may also be one or more interface boards; the stronger the data processing capability of the first network device, the more interface boards it provides. Each interface board may also have one or more physical interface cards. There may be no switching network board, or one or more; multiple boards can share the load and provide redundancy. In a centralized forwarding architecture, the first network device may not need a switching network board, as the interface boards handle the entire system's business data processing. In a distributed forwarding architecture, the first network device can have at least one switching network board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a distributed architecture first network device are greater than those of a centralized architecture device. The specific architecture adopted depends on the specific network deployment scenario, and no limitations are made here.

[0290] Figure 12 This is a schematic diagram of the hardware structure of the second network device 2200 according to an embodiment of this application. Figure 12 The second network device 2200 shown can perform the corresponding steps executed by the second network device in the method of the above embodiments.

[0291] like Figure 12 As shown, the second network device 2200 includes a processor 2201, a memory 2202, an interface 2203, and a bus 2204. The interface 2203 can be implemented wirelessly or via a wired connection; specifically, it can be a network interface card (NIC). The processor 2201, memory 2202, and interface 2203 are connected via the bus 2204.

[0292] The interface 2203 may specifically include a transmitter and a receiver for acquiring multicast packets and sending the BIER packet to the first network device. The processor 2201 is used to execute the processing performed by the second network device in the above embodiments. For example, the processor 2201 is used to encapsulate the multicast packet according to the Virtual Private Network (VPN) instance to which the multicast packet belongs to obtain the BIER packet; and / or other processes used in the techniques described herein. The memory 2202 includes an operating system 22021 and an application program 22022 for storing programs, code, or instructions that, when executed by the processor or hardware device, can complete the processing involving the second network device in the method embodiments. Optionally, the memory 2202 may include read-only memory (ROM) and random access memory (RAM). The ROM includes a basic input / output system (BIOS) or an embedded system; the RAM includes application programs and the operating system. When the second network device 2200 needs to be run, the system is booted through the BIOS embedded in ROM or the bootloader in the embedded system, guiding the second network device 2200 into normal operation. After the second network device 2200 enters normal operation, the application program and operating system running in RAM complete the processing procedures involving the second network device 2200 in the method embodiment.

[0293] Understandable, Figure 12 Only a simplified design of the second network device 2200 is shown. In practical applications, the second network device can contain any number of interfaces, processors, or memory.

[0294] Figure 13 This is a schematic diagram of the hardware structure of another second network device 2300 according to an embodiment of this application. Figure 13 The second network device 230 shown can perform the corresponding steps executed by the second network device in the method of the above embodiments.

[0295] like Figure 13The second network device 230 includes a main control board 2310, an interface board 2330, a switching board 2320, and an interface board 2340. The main control board 2310, interface boards 2330 and 2340, and the switching board 2320 are interconnected with the system backplane via a system bus. The main control board 2310 performs system management, equipment maintenance, and protocol processing functions. The switching board 2320 performs data exchange between the interface boards (also called line cards or service boards). The interface boards 2330 and 2340 provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and forward data packets.

[0296] The interface board 2330 may include a central processing unit 2331, a forwarding table entry memory 2334, a physical interface card 2333, and a network processor 2332. The central processing unit 2331 is used to control and manage the interface board and communicate with the central processing unit on the main control board. The forwarding table entry memory 2334 is used to store table entries, such as BIFT mentioned above. The physical interface card 2333 is used to receive and send traffic.

[0297] It should be understood that the operation on interface board 2340 in this embodiment is consistent with the operation on interface board 2330, and will not be described again for the sake of brevity. It should be understood that the second network device 2300 in this embodiment may correspond to the functions and / or various steps implemented in the above method embodiments, and will not be described again here.

[0298] Furthermore, it should be noted that there may be one or more main control boards, including a primary and a backup main control board. There may also be one or more interface boards; the stronger the data processing capability of the second network device, the more interface boards it provides. Each interface board may also have one or more physical interface cards. There may be no switching network board, or one or more; multiple boards can share the load for redundancy and backup. In a centralized forwarding architecture, the second network device may not need a switching network board, with the interface boards handling the entire system's business data processing. In a distributed forwarding architecture, the second network device can have at least one switching network board, enabling data exchange between multiple interface boards and providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a distributed architecture second network device are greater than those of a centralized architecture device. The specific architecture adopted depends on the specific network deployment scenario, and no limitations are made here.

[0299] This application also provides a computer-readable medium storing program code that, when executed on a computer, causes the computer to perform the method described above by the first network device. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0300] This application also provides a computer-readable medium storing program code that, when executed on a computer, causes the computer to perform the method described above by the second network device. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0301] This application embodiment also provides a chip system applied in a first network device. The chip system includes: at least one processor, at least one memory, and an interface circuit. The interface circuit is responsible for information interaction between the chip system and the outside world. The at least one memory, the interface circuit, and the at least one processor are interconnected via lines. The at least one memory stores instructions. The instructions are executed by the at least one processor to perform the operation of the first network device in the methods described in the above aspects.

[0302] In specific implementation, the chip can be implemented in the form of a central processing unit (CPU), micro controller unit (MCU), micro processing unit (MPU), digital signal processor (DSP), system on chip (SoC), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or programmable logic device (PLD).

[0303] This application also provides another chip system for use in a second network device. The chip system includes at least one processor, at least one memory, and an interface circuit. The interface circuit is responsible for information interaction between the chip system and the outside world. The at least one memory, the interface circuit, and the at least one processor are interconnected via lines. The at least one memory stores instructions. The instructions are executed by the at least one processor to perform the operation of the second network device in the methods described in the above aspects.

[0304] In specific implementation, the chip can be implemented in the form of a central processing unit (CPU), micro controller unit (MCU), micro processing unit (MPU), digital signal processor (DSP), system on chip (SoC), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or programmable logic device (PLD).

[0305] This application also provides a computer program product applied in a first network device. The computer program product includes a series of instructions, which, when executed, perform the operation of the first network device as described in the above-described aspects.

[0306] This application also provides a computer program product applied in a second network device. The computer program product includes a series of instructions, which, when executed, perform the operation of the second network device as described in the above aspects.

[0307] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0308] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0309] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0310] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0311] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0312] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0313] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0314] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for Bit-Index Explicit Replication (BIER) packet forwarding, the method comprising: The method comprises: The first network device receives a BIER packet sent by a second network device, the BIER packet comprising an Internet Protocol version 6 (IPv6) header, a Bit-Index Explicit Replication (BIER) header, and a multicast packet, a first field of the BIER header carrying a service identifier, the service identifier being used to identify a Virtual Private Network (VPN) instance to which the multicast packet belongs; The first network device determines a Virtual Routing Forwarding (VRF) table according to the service identifier and a first correspondence relationship, the first correspondence relationship comprising a correspondence relationship between the service identifier and the VRF table; The first network device sends the multicast packet to a first Customer Edge (CE) device in the VRF table according to the VRF table; The first field of the BIER header is a combination of any one or more of the following fields: a Differentiated Services Code Point (DSCP) field, a Bit-Forwarding Internet Router (BFIR-id) field, and a protocol (proto) field.

2. The method of claim 1, wherein, The method further comprises: The first network device receives a control packet, the control packet comprising a correspondence relationship between the service identifier and the VRF table; The first network device saves the correspondence relationship between the service identifier and the VRF table.

3. The method of claim 1, wherein, The first correspondence relationship further comprises a source address, The first network device determines the VRF table according to the source address of the IPv6 header, the service identifier, and the first correspondence relationship. The method comprises:

4. A method for Bit-Index Explicit Replication (BIER) packet forwarding, the method comprising: The second network device obtains a multicast packet; The second network device encapsulates the multicast packet according to a Virtual Private Network (VPN) instance to which the multicast packet belongs to obtain a BIER packet, the BIER packet comprising an Internet Protocol version 6 (IPv6) header, a Bit-Index Explicit Replication (BIER) header, and a multicast packet, a first field of the BIER header carrying a service identifier, the service identifier being used to identify the VPN instance to which the multicast packet belongs; The second network device sends the BIER packet to a first network device; The first field of the BIER header is a combination of any one or more of the following fields: a Differentiated Services Code Point (DSCP) field, a Bit-Forwarding Internet Router (BFIR-id) field, and a protocol (proto) field. The method further comprises:

5. The method of claim 4, wherein, The second network device allocates the service identifier to the VPN instance; The second network device establishes a first correspondence relationship, the first correspondence relationship comprising a correspondence relationship between the service identifier and a VRF table corresponding to the VPN instance. The method further comprises:

6. The method of claim 4, wherein, The second network device sends a control packet to the first network device, the control packet comprising a correspondence relationship between the service identifier and a VRF table corresponding to the VPN instance. The control packet is a Border Gateway Protocol (BGP) packet.

7. The method of claim 6, wherein, The method comprises:

8. A first network device, comprising: ​ The receiving module is configured to receive a BIER packet sent by a second network device, the BIER packet comprising an Internet Protocol version 6 (IPv6) header, a Bit-Index Explicit Replication (BIER) header, and a multicast packet, a first field of the BIER header carrying a service identifier, the service identifier being used to identify a Virtual Private Network (VPN) instance to which the multicast packet belongs; The processing module is configured to determine a Virtual Routing Forwarding (VRF) table according to the service identifier and a first correspondence relationship, the first correspondence relationship comprising a correspondence relationship between the service identifier and the VRF table; The sending module is configured to send the multicast packet to a first Customer Edge (CE) device in the VRF table according to the VRF table. The first field of the BIER header is a combination of any one or more of the following fields: a Differentiated Services Code Point (DSCP) field, a Bit-Forwarding Internet Router (BFIR-id) field, and a protocol (proto) field.

9. The first network device of claim 8, wherein The receiving module is further configured to receive a control packet, the control packet comprising a correspondence relationship between the service identifier and the VRF table. The processing module is further configured to save the correspondence relationship between the service identifier and the VRF table.

10. The first network device of claim 8, wherein, The first correspondence relationship further comprises a source address. The processing module is specifically configured to determine the VRF table according to the source address of the IPv6 header, the service identifier, and the first correspondence relationship.

11. A second network device, comprising: Comprise: The receiving module is configured to obtain a multicast packet. The processing module is further configured to encapsulate the multicast packet to obtain a BIER packet according to a Virtual Private Network (VPN) instance to which the multicast packet belongs, the BIER packet comprising an Internet Protocol version 6 (IPv6) header, a Bit-Index Explicit Replication (BIER) header, and a multicast packet, a first field of the BIER header carrying a service identifier, the service identifier being used to identify a VPN instance to which the multicast packet belongs. The sending module is configured to send the BIER packet to a first network device. The first field of the BIER header is a combination of any one or more of the following fields: a Differentiated Services Code Point (DSCP) field, a Bit-Forwarding Internet Router (BFIR-id) field, and a protocol (proto) field.

12. The second network device according to claim 11, characterized in that, The processing module is further configured to: allocate the service identifier to the VPN instance; establish a first correspondence relationship, the first correspondence relationship comprising a correspondence relationship between the service identifier and a VRF table corresponding to the VPN instance.

13. The second network device of claim 11, wherein, The sending module is further configured to: send a control packet to the first network device, the control packet comprising a correspondence relationship between the service identifier and a VRF table corresponding to the VPN instance.

14. The second network device according to claim 13, characterized in that, The control packet is a Border Gateway Protocol (BGP) packet.

15. A first network device, comprising: Comprise: a processor and a memory, the memory being configured to store a program, and the processor being configured to invoke and run the program from the memory to execute the method in any one of claims 1 to 3.

16. A second network device, comprising: Comprise: a processor and a memory for storing a program, the processor being configured to call and run the program from the memory to perform the method of any one of claims 4 to 7.

17. A system for BIER packet forwarding, the system comprising: comprising a first network device as claimed in any one of claims 8 to 10 and a second network device as claimed in any one of claims 11 to 14.

18. A computer-readable storage medium, characterized in that, comprising a computer program or code which, when run on a computer, causes the computer to perform the method of any one of claims 1 to 3.

19. A computer-readable storage medium, characterized in that, comprising a computer program or code which, when run on a computer, causes the computer to perform the method of any one of claims 4 to 7.

Images