Packet forwarding method and apparatus

Abstract

The application provides a message forwarding method and device, and belongs to the technical field of communication. The application combines the hop-by-hop changing information in the BIER message and the information in the BIER message that is specially used for load sharing, regenerates a new load sharing factor, and then uses the new load sharing factor for load sharing. Since the hop-by-hop changing information in the BIER forwarding process is added as a component of the load sharing factor, the load sharing factor used by each hop BFR is different, thereby increasing the balance of load sharing, helping to solve the problem of uneven load sharing, and improving the load sharing effect.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a message forwarding method and apparatus. Background Technology

[0002] Bit-indexed explicit replication (BIER) is a widely used technique in communications for constructing multicast message forwarding paths because it eliminates the need to build a multicast distribution tree. BIER can be implemented using either Multi-Protocol Label Switching (MPLS) or Internet Protocol version 6 (IPv6). The IPv6-based BIER is simply referred to as BIERv6 (bit-indexed explicit replication over IPv6 data plane).

[0003] In related technologies, when forwarding BIER MPLS packets, network devices use the entropy in the BIER header for load balancing; when forwarding BIERv6 packets, network devices use the entropy in the BIER encapsulation or the flow label in the IPv6 header for load balancing.

[0004] However, using only entropy or flow labels for load balancing can lead to uneven load distribution. Summary of the Invention

[0005] This application provides a message forwarding method and apparatus that can improve the load balancing effect of BIER broadcast forwarding. The technical solution is as follows.

[0006] Firstly, a message forwarding method is provided, which includes:

[0007] The network device receives a first BIER message, which includes a first load sharing factor and first information.

[0008] The network device generates a second load-sharing factor based on the first load-sharing factor and the first information;

[0009] The network device determines the first interface from a plurality of interfaces based on the second load-sharing factor;

[0010] The network device sends a second BIER message through the first interface. The second BIER message is obtained by updating the first BIER message by the network device. The second BIER message includes the first load sharing factor and second information. The second information is obtained by updating the first information by the network device.

[0011] In the above method, the characteristic that BIERv6 or BIER MPLS packets contain hop-by-hop changing information is utilized. The hop-by-hop changing information (i.e., the first information) in the BIER packet is combined with the information in the BIER packet specifically used for load balancing (i.e., the first load balancing factor) to regenerate a new load balancing factor (i.e., the second load balancing factor). Then, the new load balancing factor is used for load balancing. Since the information changing at each hop during the BIER forwarding process is added as a component of the load balancing factor, the load balancing factor used by each hop BFR is different, thereby increasing the balance of load balancing, helping to solve the problem of uneven load balancing, and improving the load balancing effect.

[0012] Optionally, the first information includes the identifier of the network device, and the second information includes the identifier of the next-hop BFR of the network device.

[0013] Optionally, the first information may further include the functional information of the network device, and the second information may further include the functional information of the next-hop network frame (BFR) of the network device.

[0014] Optionally, the first BIER message includes the End.BIER address of the network device, and the first information is all or part of the content of the End.BIER address in the first BIER message.

[0015] Optionally, the first information is the content of bits 64 to 84 of the End.BIER address in the first BIER message; or,

[0016] The first information is bits 64 to 96 of the End.BIER address stated in the first BIER message; or,

[0017] The first information is bits 64 to 128 of the End.BIER address stated in the first BIER message; or,

[0018] The first information is the End.BIER address in the first BIER message.

[0019] In the above implementation, by utilizing the hop-by-hop change of End.BIER in the BIERv6 multicast, all or part of End.BIER is calculated with a factor specifically used for load balancing (such as Flow Label) during load balancing to balance the load balancing effect, optimize the load balancing effect, make full use of network link resources, and improve network utilization.

[0020] Optionally, the first information includes the MPLS label assigned by the network device, and the second information includes the MPLS label assigned by the next-hop BFR of the network device.

[0021] Optionally, the first information indicates at least one of the following: the subdomain to which the network device belongs in the BIER domain, the BSL used by the network device, and the SI to which the network device's BFR ID belongs.

[0022] Optionally, the first information is the content of the BIFT ID field in the first BIER message.

[0023] Optionally, the first load-sharing factor includes the flow identifier of the multicast stream to which the first BIER message belongs.

[0024] In the above implementation, by utilizing the independent allocation of BFIT values ​​in packets by each node in BIER MPLS multicast and the characteristic of label changes during forwarding, BFIT is calculated with a factor specifically used for load balancing (such as Entropy) during load balancing to balance the load balancing effect and optimize the load balancing effect.

[0025] Optionally, the first load-sharing factor is the content of the flow label field in the IPv6 header of the first BIER packet; or,

[0026] The first load-sharing factor is the content of the entropy field in the first BIER message.

[0027] Optionally, the first information includes the identifier of the destination BFER set of the first BIER message.

[0028] Optionally, the first information is the content carried by the bit string field in the first BIER message.

[0029] In the above implementation, by taking advantage of the hop-by-hop change of the bit string value in the packet during forwarding in BIER MPLS and BIERv6 multicast, the bit string is calculated with a factor specifically used for load sharing during load sharing to balance the load sharing and optimize the load sharing effect.

[0030] Optionally, the first information includes TTL or hop limit.

[0031] Optionally, the first BIER message is a BIERv6 message or a BIER MPLS message.

[0032] Optionally, the network device generates a second load-sharing factor based on the first load-sharing factor and the first information, including:

[0033] The network device generates random numbers;

[0034] The network device generates a second load-sharing factor based on the first load-sharing factor, the first information, and the random number.

[0035] Secondly, a message forwarding apparatus is provided, which has the function of implementing the first aspect or any optional method of the first aspect. The message forwarding apparatus includes at least one unit, which is used to implement the method provided by the first aspect or any optional method of the first aspect.

[0036] In some embodiments, the units in the packet forwarding device are implemented in software, and the units in the packet forwarding device are program modules. In other embodiments, the units in the packet forwarding device are implemented in hardware or firmware. Specific details of the packet forwarding device provided in the third aspect can be found in the first aspect or any optional embodiment of the first aspect described above, and will not be repeated here.

[0037] Thirdly, a network device is provided, comprising a processor coupled to a memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the network device to implement the method provided by the first aspect or any alternative embodiment of the first aspect. Specific details of the network device provided in the third aspect can be found in the first aspect or any alternative embodiment of the first aspect, and will not be repeated here.

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

[0039] Fifthly, a computer-readable storage medium is provided, which stores at least one instruction that, when executed on a computer, causes the computer to perform the method provided in the first aspect or any alternative method of the first aspect.

[0040] In a sixth aspect, a chip is provided, including a memory and a processor, the memory for storing computer instructions, and the processor for calling and executing the computer instructions from the memory to perform the methods described in the first aspect and any possible implementation thereof. Attached Figure Description

[0041] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application;

[0042] Figure 2 This is a flowchart of a message forwarding method provided in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram of the format of a BIERv6 message provided in this embodiment;

[0044] Figure 4 This is a schematic diagram of an IPv6 address format provided in this embodiment;

[0045] Figure 5 This embodiment provides a flowchart of a network device's process for load balancing by forwarding BIERv6 packets.

[0046] Figure 6 This is a schematic diagram of a BIER MPLS encapsulation format provided in this embodiment;

[0047] Figure 7 This is a schematic diagram of the structure of a message forwarding device 500 provided in an embodiment of this application;

[0048] Figure 8 This is a schematic diagram of the structure of a network device provided in an embodiment of this application;

[0049] Figure 9 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0051] The following explains some terms and concepts involved in the embodiments of this application.

[0052] (1) BIER forwarding router (BFR)

[0053] BFR refers to a node that supports BIER forwarding. Depending on the network deployment location, BFRs are divided into bit forwarding ingress routers (BFIR, i.e., the ingress node of a BIER domain or BIER subdomain), bit forwarding egress routers (BFER, i.e., the egress node of a BIER domain or BIER subdomain), and BFRs that act as intermediate nodes. BFIRs and BFERs are collectively referred to as edge nodes.

[0054] (2) BIER / BIERv6

[0055] BIER / BIERv6 is a multicast forwarding technology based on explicit replication using bit indexes. Within a BIER subdomain, edge routers BFIR and BFER are assigned unique identifiers, known as BIER forwarding router identifiers (BFR IDs). The BFR ID is an integer ranging from 1 to 65535. During BIER forwarding, the BFIR must explicitly specify which BFER nodes to send the multicast message to. Within a subdomain, the set of BFERs to which the multicast message is sent is represented by a bit string. The position or index of each bit in the bit string represents the BFR ID of an edge node. The BFIR encapsulates this bit string in the BIER header of the multicast message, and the BFR replicates the message based on this bit string, ultimately delivering it to the BFER nodes in the subdomain.

[0056] When BIER / BIERv6 carries multicast services, it establishes BGP neighbors between BFIR and BFER via the Border Gateway Protocol (BGP), establishes BIER forwarding tunnels through BGP, and transmits user multicast requests. When an end user wants to watch a multicast channel program, it sends a channel group join request to its upstream BIER multicast leaf node. Specifically, in the case of Internet Protocol version 4 (IPv4), this join request is an Internet Group Management Protocol (IGMP) message; in the case of Internet Protocol version 6 (IPv6), this join request is a multicast listener (MLD) message. If the multicast leaf node does not have the channel data requested by the end user, it sends the join request to BFIR via the BGP protocol. After receiving the multicast leaf node's join request, BFIR sets a bit in the bit string corresponding to the leaf node's BFR ID to 1, thus generating the bitstring for sending the multicast channel data.

[0057] BFIR sends the multicast message encapsulated with a bitstring to downstream nodes based on the bit index forwarding table (BIFT). Downstream nodes' BFRs parse the bitstring and copy the message according to their own BIFT tables, sending it hop-by-hop to the BFER nodes. The BFER nodes parse the bitstring, check if it matches the destination node of their own BIER multicast, remove the outer encapsulation containing BIER information, and continue searching the user's multicast forwarding table. Based on the search result, they forward the original multicast message to the requesting user.

[0058] Traditional BIER is implemented based on multi-protocol label switching (MPLS). The biggest difference between BIERv6 and traditional BIER is that BIERv6 eliminates MPLS labels and is a multicast scheme based on native IPv6. BIERv6 inherits the core design concept of BIER, using bit strings to copy multicast packets to designated receivers. Intermediate nodes do not need to build multicast forwarding trees, achieving stateless forwarding. Building on this, BIERv6 technology uses IPv6 extension headers to carry the information required for BIER forwarding, thus eliminating the need for MPLS label forwarding mechanisms. The mechanism of using IPv6 extension headers also facilitates the evolution and overlay of subsequent new features, such as IPv6 packet fragmentation and reassembly, multicast network slicing, and flow detection. Since services are only deployed at the head and tail nodes, intermediate nodes are unaware of changes in multicast services. Therefore, when the network topology changes, there is no need to perform undo and rebuild operations on a large number of multicast trees, greatly simplifying operation and maintenance. BIERv6 utilizes IPv6 extension headers to implement its functionality. The destination address in the IPv6 packet identifies the IPv6 address of the BIER forwarding node, i.e., the End.BIER address, indicating that BIERv6 forwarding processing needs to be performed at this node. The source address in the IPv6 packet identifies the origin of the BIERv6 packet. BIERv6 uses IPv6 extension headers (such as the Destination Options header) to carry BIER options, which, together with the IPv6 header, form the BIERv6 packet header. The BFR reads the bit string in the BIER options, copies and forwards it according to the BIFT, and updates the bit string.

[0059] (3) Bit string

[0060] A bit string is used to represent a group of BFERs in the BIER field, with each bit in the bit string corresponding to one BFER. The set bits in the bit string represent the set of identifiers for the destination BFER node of the message. When the BFIR needs to forward a message through intermediate nodes to a specified group of BFERs, the BFIR sets all the bits in the BIER option corresponding to that specified group of BFERs, so that intermediate nodes can copy and forward messages according to the bit string settings. For example, if the BIER field contains four edge nodes, identified as 1, 2, 3, and 4, and the BFIR needs to forward a message to both the edge node with BFR ID 1 and the edge node with BFR ID 2, the BFIR can include the bit string 0011 in the BIER option.

[0061] (4) BIER forwarding router identifier (BFR ID)

[0062] BFR ID is the identifier of a BFER node. BFR ID is represented by an integer in the range of 1 to 65535. For example, in a network with 256 edge nodes, each edge node needs to be configured with a unique value from 1 to 256, and the destination node set is represented by a 256-bit (or 32-byte) bit string, where the position or index of each bit in the bit string represents an edge node.

[0063] (5) Entropy

[0064] In the BIER multicast forwarding domain, the multicast root node generates an entropy and encapsulates it in the BIER header. The entropy is used to identify a multicast stream. According to the BIER architecture definition in RFC8279, BIER can perform load balancing during forwarding. The key factor for load balancing is the entropy in the BIER header, as detailed in the relevant sections below.

[0065] When a network device needs to send a packet to a specific BFR-NBR, load balancing may be applied if the network device is connected to that BFR-NBR through multiple parallel interfaces. If the packet encapsulation contains an entropy field, the entropy field must be taken into account during load balancing; packets with the same entropy field value should be sent out from the same interface.

[0066] In some cases, the underlying routing may provide multiple equal-cost paths (through different BFR neighbors (BFR-neighbor, BFR-NBR)) to a given BFER, which is called equal-cost multi-path (ECMP).

[0067] The BIER packaging standard RFC8296 describes the entropy in the BIER header package as follows.

[0068] The 20-bit field `entropy` specifies an "entropy" value that can be used for load balancing. The BIER forwarding process may perform equal-cost load balancing, in which the same path is chosen for two packets containing the same entropy value and the same bitstring.

[0069] (6) Flow label

[0070] The flow label is generated by the multicast root node and encapsulated in the IPv6 header of the BIERv6 packet to identify a multicast flow.

[0071] (7) Load sharing factor

[0072] The load-sharing factor represents the parameters used by network devices when performing load balancing algorithms during packet forwarding. If two packets have the same load-sharing factor value while the load-sharing algorithm remains unchanged, the device will calculate the same outgoing interface for both packets and send them out from the same interface.

[0073] (8) Endpoint BIER (End.BIER) address

[0074] The End.BIER address, abbreviated as End.BIER, is also known as the End.BIER segment ID (SID). An End.BIER address refers to the IPv6 address of a device node that supports BIERv6. End.BIER is a type of SID in a BIERv6 network. When a packet destined for a device's End.BIER address arrives at this node, the packet needs to undergo BIER forwarding. End.BIER typically uses the same locator as Internet Protocol version 6 (SRv6) segment routing (SRv6) locator.

[0075] In End.BIER, bits 64-84 are typically used for the node identifier (node ​​ID) of a device. The node ID identifies a specific device. For example, in a metropolitan area network (MAN), a user access device is located in the access portion of the MAN and is numbered 2. If the device is numbered 10 in this access network, then the node ID is a value concatenated from 2 and 10.

[0076] (9) BIFT

[0077] BIFT is an entry used by each BFR in the BIERv6 domain when forwarding multicast messages. The bit index forwarding table represents all BFER nodes reachable through its BFR neighbor, including the BFR neighbor (Nbr) and the forwarding bit mask (FBM). Each BFR in BIERv6 advertises its local BFR prefix, sub-domain (SD) ID, BFR ID, bit string length (BSL), and path calculation algorithm to other BFR nodes via the interior gateway protocol (IGP). Each BFR node uses path calculation to determine its BFR neighbors to each BFER.

[0078] (10) Bit index forwarding table identifier (BIFTID)

[0079] The BIFT ID represents a specific Bit Index Forwarding Table (BIFT), essentially an index to a specific BIFT entry. The BIFT ID is carried in the BIFT-id field of the BIER header. In MPLS networks, the BIFT ID is an MPLS label. In non-MPLS networks, the BIFT ID is a numerical value that retrieves a specific BIFT entry. The BIFT ID (implicitly) identifies a set identifier (SI, also called a set index), an SD, and a BSL. If a packet is sent to a specific BFR-NBR, the BIFT ID must be modified to match the SI, subfields, and BSL published by that BFR-NBR. If the BIER MPLS encapsulation format is used, modifying the BIFT ID is essentially an MPLS label switching operation.

[0080] (11)Subdomain

[0081] A BIER domain can be configured into different subdomains according to the actual business needs, with each subdomain represented by an SDID. For example, the SD ID value ranges from [0-255] and is 8 bits long. As an example, a BIER domain can be divided into different SDs based on business requirements. For instance, VPN 1 uses SD 0, and VPN 2 uses SD 1.

[0082] (12) Bit String Length (BSL)

[0083] BSL refers to the length of the bit string included in the BIER header.

[0084] (13) Set Identifier (SI)

[0085] SI can be understood as a set of multiple edge BFRs or configured BFR IDs in the network. As an example, if BSL is 256, and there are more than 256 edge BFRs or configured BFR IDs in the network, then 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 assigned to set 0 (set index 0, or SI = 0), and the 256 edge BFRs with BFR IDs from 257 to 512 are assigned to set 1 (set index 1, or SI = 1).

[0086] (14) Scrambling factor

[0087] The scrambling factor represents additional values ​​added to the original load balancing factor during packet forwarding to achieve a more balanced load distribution. By combining the original load balancing factor and the scrambling factor, a new load balancing factor is obtained. The load balancing algorithm uses this new load balancing factor for calculation, resulting in a more balanced packet load distribution during forwarding.

[0088] (15) Ethernet link aggregation (ethernet-trunk, ETH-trunk) interface

[0089] Trunk is a bundling technology. It combines multiple physical interfaces into a single logical interface, called a trunk interface, and each physical interface bundled together is called a member interface. Using trunk technology to bundle multiple interfaces together can meet the demand for increased interface bandwidth at a relatively low cost. For example, bundling three 100Mbit / s full-duplex interfaces together can achieve a maximum bandwidth of 300Mbit / s. ETH-trunk bundles multiple Ethernet interfaces into a single logical interface, called an Eth-trunk interface, and each Ethernet interface bundled together is called a member interface. Eth-trunk interfaces can achieve increased bandwidth, improved reliability, and load balancing.

[0090] (16) BIER MPLS forwarding process

[0091] For example, the process of BFR forwarding a BIER MPLS-encapsulated message is shown below.

[0092] Step 1: Determine the SI, BSL, and subfields of the message.

[0093] Step 2: If the bit string consists entirely of 0s, discard the message; the forwarding process is now complete. If the bit string is not entirely of 0s, continue to Step 3.

[0094] Step 3: Find the least significant bit (i.e., the rightmost bit) among the set bits in the bit string of the message, and denote it as bit k.

[0095] Step 4: If the BFR identified by bit k is the node that received the message, then copy the message and forward it to the overlay layer of the multicast stream (such as the destination user). Then, clear bit k in the original message and proceed to step 2. If bit k does not identify the current node, proceed to step 5.

[0096] Step 5: Use the value of k, SI, subdomain, and BSL as the index for finding BIFT.

[0097] Step 6: Extract F-BM and BFR-NBR from BIFT.

[0098] Step 7: Copy the message. Use the F-BM to perform a bitwise AND operation with the bit string in the message copy to update the bit string in the message copy. Then, forward the updated message copy to the BFR-NBR. If the BFR-NBR is empty, discard the copy. Note that when a message is forwarded to a specific BFR-NBR, the bit string in the message only identifies the BFERs that will be reached through that BFR-NBR.

[0099] Step 8: Perform a bitwise AND operation between the bitwise inverted value of F-BM and the bit string in the original message to update the bit string in the original message. This operation clears the bits of the BFER to which the message copy was sent in Step 7, and then proceeds to Step 2.

[0100] By executing the above forwarding process, it is ensured that the packet is forwarded to a specific BFR-NBR only once. The number of BIFT lookups is the same as the number of BFR-NBRs to which the packet needs to be forwarded.

[0101] When a message is sent to a specific BFR-NBR, the bit string is not the only part of the BIER header that needs to be modified. If the BIER header contains a Time to Live (TTL) field, the TTL will need to be decremented.

[0102] Furthermore, when using BIER MPLS encapsulation, the BIFT-id field may need to be modified. Whether to modify the BIFT-id field depends on the signaling of the BFR-NBR from which the packet originates. The BIFT-id field implicitly identifies an SI, a subdomain, and a BSL. If the packet is sent to a specific BFR-NBR, the BIFT-id field is changed to the same values ​​as the SI, subdomain, and BSL already published by that BFR-NBR.

[0103] The following examples illustrate the application scenarios of this embodiment.

[0104] Figure 1 This is a schematic diagram illustrating an application scenario of BIER provided in this embodiment. Figure 1 The scenario shown includes a multicast source, a root node, intermediate node A, intermediate node B, leaf node A, leaf node B, multicast receiver A, and multicast receiver B.

[0105] A multicast source is used to provide multicast service data to be forwarded. Specifically, a multicast source is used to generate and send multicast streams. A multicast stream consists of a series of multicast packets. Multicast packets include, but are not limited to, IPv4 packets or IPv6 packets. Multicast packets contain service data to be delivered to multicast receivers. Multicast sources include, but are not limited to, servers, hosts, and terminals. The service data generated by a multicast source includes, but is not limited to, multimedia data, such as audio or video streams. Multicast sources can optionally be deployed in a local area network (LAN).

[0106] Each of the root node, intermediate node A, intermediate node B, leaf node A, and leaf node B is a forwarding node for multicast packets. Each of the root node, intermediate node A, intermediate node B, leaf node A, and leaf node B is a network device, such as a router or switch. The root node, intermediate node A, intermediate node B, leaf node A, and leaf node B can optionally be deployed in the backbone network.

[0107] The root node, intermediate node A, intermediate node B, leaf node A, and leaf node B may optionally reside in the same BIER domain or BIER subdomain. The root node is BFIR. Intermediate nodes A and B are both BFR. Leaf nodes A and B are both BFER.

[0108] The root node receives multicast messages from the multicast source, encapsulates them into BIER messages, and copies and forwards the BIER messages to intermediate nodes A and B. The BIER message consists of a bit string, where the bits corresponding to leaf node A and leaf node B are all set. BIER messages include, but are not limited to, BIERv6 messages and BIER MPLS messages.

[0109] Intermediate node A forwards BIER messages to leaf node A based on the BIFT stored on intermediate node A. Intermediate node B forwards BIER messages to leaf node B based on the BIFT stored on intermediate node B.

[0110] After receiving a BIER message from intermediate node A, leaf node A finds that the bit corresponding to its own BFR ID in the bit string is set. Leaf node A then removes the BIER encapsulation, restores the BIER message to its original multicast message, queries the multicast forwarding table, and forwards the multicast message to multicast receiver A based on the lookup result. Similarly, after receiving a BIER message from intermediate node B, leaf node B finds that the bit corresponding to its own BFR ID in the bit string is set. Leaf node B then removes the BIER encapsulation, restores the BIER message to its original multicast message, queries the multicast forwarding table, and forwards the multicast message to multicast receiver B based on the lookup result.

[0111] In related technologies, BIER packet forwarding uses the entropy in the BIER header for load balancing. BIERv6 packets can use either the entropy in the BIER encapsulation or the flow label in the IPv6 header for load balancing. The values ​​of entropy or flow label are set at the root node and remain fixed for each flow. Therefore, when packets are forwarded in the network, uneven load distribution can occur because different nodes use the same load balancing factor (entropy or flow label) when performing load balancing calculations.

[0112] This embodiment addresses the issue of uneven load distribution between BIER and BIERv6 by optimizing the system to ensure that the load of each node is evenly distributed across different links or different member port links of the ETH-trunk. The method flow provided in this embodiment is illustrated below.

[0113] Figure 2 This is a flowchart of a message forwarding method provided in an embodiment of this application. Figure 2 The method shown is executed by a network device, which can be any hop node on the multicast path. For example, combined with... Figure 1 Let's take a look. Figure 2 The network device in the method shown is, for example, Figure 1 The root node, intermediate node A, intermediate node B, leaf node A, and leaf node B are any one of the following nodes: root node, intermediate node A, intermediate node B, leaf node A, and leaf node B.

[0114] Figure 2 The method shown involves the process of updating BIER messages internally within the device. In order to distinguish between different BIER messages, the BIER message received by the device is described as "first BIER message", and the BIER message sent out by the device is described as "second BIER message".

[0115] Optionally, Figure 2 The method shown is used for load balancing in BIER MPLS multicast scenarios. Figure 2 In the method shown, both the first BIER message and the second BIER message are BIER MPLS messages.

[0116] Optionally, Figure 2 The method shown is used for load balancing in BIERv6 multicast scenarios. Figure 2 In the method shown, both the first BIER message and the second BIER message are BIERv6 messages.

[0117] Figure 2The method shown involves the application of hop-by-hop updated information in BIER messages. To distinguish between the original information before the device update and the updated information, the original information before the device update is described by "first information," and the information obtained after the device update is described by "second information."

[0118] Figure 2 The method shown includes the following steps S101 to S104.

[0119] S101, The network device receives the first BIER message.

[0120] The first BIER message includes the first load-sharing factor and the first information.

[0121] The first load balancing factor refers to information specifically used for load balancing during BIER forwarding. Optionally, the first load balancing factor is information that remains constant throughout the BIER packet forwarding process. In other words, the first load balancing factor remains unchanged at each hop in the BFR (Browser First Free) path of the first BIER packet. Optionally, the first load balancing factor is information allocated by the BFIR (Browser First Free) system.

[0122] Optionally, the first load-sharing factor includes the flow identifier of the multicast flow to which the first BIER packet belongs. In one possible implementation, the first load-sharing factor is the flow label of the multicast flow. For example, if the first BIER packet includes an IPv6 header, the first load-sharing factor is the content of the flow label field in the IPv6 header of the first BIER packet. In another possible implementation, the first load-sharing factor is an entropy. Specifically, the first BIER packet includes a BIER header, and the first load-sharing factor is the content of the entropy field in the BIER header.

[0123] The first information refers to the information that changes hop-by-hop during the BIER forwarding process. In other words, the first information is the information that is updated at each hop of the BFR (Browser Free Frame) along the BIER forwarding path. The first information is the content carried in the first BIER packet. Network devices parse the first BIER packet to obtain the first information.

[0124] Optionally, the first information includes the identifier of the network device. For example, the first information includes the network device's number in the network.

[0125] Optionally, the first information includes not only the network device's identifier but also the network device's function information. The function information is used to indicate the operation the network device is to perform in response to the first BIER message.

[0126] Optionally, the first information is all or part of the content of the network device's End.BIER address. Specifically, the IPv6 header in the first BIER packet includes a destination address field, which carries the network device's End.BIER address, and the first information is all or part of the bits in the destination address field of the IPv6 header of the first BIER packet.

[0127] Optionally, the first information is the content of bits 64 to 84 of the End.BIER address in the first BIER message, and the first information is 20 bits in total.

[0128] Optionally, the first information is the content of bits 64 to 96 of the End.BIER address in the first BIER message, and the first information is 32 bits in total.

[0129] Optionally, the first information is the content of bits 64 to 128 of the End.BIER address in the first BIER message, and the first information is 64 bits in total.

[0130] Optionally, the first information is the End.BIER address in the first BIER message. That is, the first information is the entire 128-bit End.BIER address.

[0131] It should be understood that the various bit ranges listed above are just examples, and the first information mentioned above includes, but is not limited to, the above choices. For example, the first information mentioned above can be any X bit to Y bit in End.BIER.

[0132] Optionally, the first information includes the MPLS label assigned by the network device.

[0133] Optionally, the first information indicates at least one of the following: the subdomain to which the network device belongs in the BIER domain, the BSL used by the network device, and the SI to which the network device's BFR ID belongs.

[0134] Optionally, the first information includes a BIFT ID. For example, the BIER header in the first BIER message includes a BIFT ID field, and the first information is the content of that BIFT ID field.

[0135] Optionally, the first information includes the identifier of the destination BFER set of the first BIER message.

[0136] Optionally, the first information includes a bit string. Specifically, the first BIER message includes a BIER header, which includes a bit string field, and the first information is the content carried by the bit string field in the first BIER message.

[0137] Optionally, the first information includes TTL or hop limit.

[0138] In other embodiments, the first information is not the information carried in the BIER message, but rather some kind of information pre-stored on the network device. For example, the first information is a scrambling factor configured on the network device for load balancing during BIER forwarding.

[0139] In other embodiments, the first information is a unicast scrambled random number.

[0140] S102. The network device generates a second load-sharing factor based on the first load-sharing factor and the first information.

[0141] The second load-sharing factor refers to the load-sharing factor regenerated by the network device based on the load-sharing factor carried in the packet and the hop-by-hop changing information.

[0142] There are several specific implementation methods for network devices to generate the second load sharing factor. The following examples illustrate the possible implementation methods for generating the second load sharing factor, using implementation methods 1 to 3 as examples.

[0143] Implementation method 1: Sequential splicing

[0144] For example, the network device concatenates the first load-sharing factor and the first information, and uses the concatenated information as the second load-sharing factor. For instance, the first load-sharing factor is a 20-bit flow label, and the first information is bits 64 to 84 of the End.BIER address. The network device concatenates the 20-bit flow label with the 20-bit content of the End.BIER address to form a 40-bit string, which is then used as the second load-sharing factor.

[0145] Implementation Method 2: Addition, Subtraction, Multiplication, and Division

[0146] For example, the network device adds the first load-sharing factor and the first information, and uses the sum as the second load-sharing factor. Alternatively, the network device subtracts the first load-sharing factor from the first information, and uses the difference as the second load-sharing factor. Another option is to multiply the first load-sharing factor and the first information, and use the product as the second load-sharing factor. Finally, the network device divides the first load-sharing factor and the first information, and uses the ratio as the second load-sharing factor.

[0147] Implementation method 3: Logical AND, logical OR, and other logical operations

[0148] For example, the network device performs AND, OR, XOR, or other logical operations on the first load sharing factor and the first information, and uses the result as the second load sharing factor.

[0149] The above implementation methods 1 to 3 are illustrative. In some embodiments, the network device offsets the first load-sharing factor by a predetermined number of bits, then concatenates it with the first information, or performs addition, subtraction, multiplication, division, logical AND, logical OR, or other operations, and uses the result as the second load-sharing factor. In some embodiments, the network device extracts a portion of the first load-sharing factor and performs operations with the first information to obtain the second load-sharing factor. In some embodiments, the network device fills the first load-sharing factor with a predetermined number of 0s or 1s, making the length of the first load factor the same as the length of the first information, and then performs operations with the first information using the padded first load-sharing factor to obtain the second load-sharing factor. This embodiment does not limit the specific implementation method used by the network device to generate the second load-sharing factor.

[0150] Optionally, the network device generates a random number; the network device generates a second load-sharing factor based on the first load-sharing factor, the first information, and the random number.

[0151] S103. The network device determines the first interface from multiple interfaces of the network device based on the second load sharing factor.

[0152] The first interface refers to the outgoing interface found after load balancing calculation based on the second load balancing factor. The first interface is connected to the next-hop BFR via a link. There are various specific implementation methods for network devices to determine the first interface. The following examples, using scenarios 1 and 2, illustrate the possible implementation methods for determining the first interface.

[0153] Scenario 1: Load sharing based on equal-cost routing.

[0154] For example, multiple forwarding equivalent paths exist between the network device and the next-hop BFR. The routing table stored on the network device contains routing information indicating these multiple equivalent paths, where the destination address in the routing information is the address of the next-hop BFR. This routing information contains multiple outgoing interfaces, each corresponding to an equivalent path. After performing load balancing calculations based on a second load balancing factor, the network device selects the outgoing interface corresponding to the calculation result from the multiple outgoing interfaces leading to the next-hop BFR, based on the routing information, as the aforementioned first interface.

[0155] Scenario 2: Load sharing based on trunking.

[0156] For example, the outgoing interface on the network device leading to the next-hop BFR is a trunk interface, which includes multiple member ports. After performing load balancing calculations based on the second load balancing factor, the network device selects the member port corresponding to the calculation result from the multiple member ports of the trunk interface leading to the next-hop BFR, and uses it as the aforementioned first interface.

[0157] There are several ways network devices can select the first interface through load balancing calculations. For example, a network device might use a hash algorithm to calculate the second load balancing factor and select the interface corresponding to the hash value as the first interface. Hash algorithms include, but are not limited to, Message-Digest Algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA-1), SHA-256, and SHA-512. Another approach is to perform a modulo operation on the second load balancing factor and select the interface corresponding to the remainder as the first interface.

[0158] S104. The network device sends a second BIER message through the first interface.

[0159] The second BIER message is obtained by updating the first BIER message from the network device. The second BIER message includes the first load sharing factor and second information.

[0160] The second information is the information obtained by the network device after updating the first information. Optionally, the first information is information related to the local network device, and the second information is information related to the network device's next-hop BFR.

[0161] For example, when using device identifiers to generate load sharing factors, the first information includes the identifier of the network device, and the second information includes the identifier of the network device's next-hop BFR.

[0162] For example, when generating load sharing factors using device identification and functional information, the first information includes the identification and functional information of the network device, and the second information also includes the identification and functional information of the next-hop BFR of the network device.

[0163] For example, when using the End.BIER address to generate the load balancing factor, the first information mentioned above is the End.BIER address of the network device, and the second information is the End.BIER address of the network device's next-hop BFR. The process by which the network device updates the first information is the operation of updating the destination address field in the IPv6 header using the End.BIER address of the next-hop BFR during BIERv6 forwarding.

[0164] For example, when using MPLS labels to generate load-sharing factors, the first information includes the MPLS label assigned by the network device, and the second information includes the MPLS label assigned by the network device's next-hop BFR. The process by which the network device updates the first information is the MPLS label switching operation during the MPLS forwarding process.

[0165] For example, when using BIFT ID to generate load sharing factor, the first information mentioned above is the BIFT ID of the network device, and the second information is the BIFT ID of the next-hop BFR of the network device.

[0166] For example, when using bit strings to generate load sharing factors, the first information mentioned above is the bit string corresponding to the network device, while the second information is the bit string corresponding to the next-hop BFR of the network device.

[0167] There are several ways for network devices to obtain the aforementioned second information. In one possible implementation, during the route advertisement phase, the next-hop BFR advertises the second information, and the network device receives the second information advertised by the next-hop BFR and saves it to the routing table. During the packet forwarding phase, the network device obtains the second information from the routing table. In another possible implementation, the second information is configured on the network device through static configuration.

[0168] In another possible implementation, the network device subtracts 1 from the first information and uses the result as the second information. For example, in the case of generating a load-sharing factor using TTL, both the first and second information are TTL values, and the value of the second information is 1 less than the value of the first information. The process of the network device updating the first information includes the operation of updating the TTL during IPv4 forwarding.

[0169] For example, when using hop limits to generate load-sharing factors, both the first and second pieces of information mentioned above are hop limits, with the value of the second piece of information being 1 less than the value of the first piece of information. The process of network devices updating the first piece of information includes the operation of updating the hop limit during IPv6 forwarding.

[0170] This embodiment does not limit the order in which the first BIER message is updated and the second load-sharing factor is generated. Optionally, they can be processed one after the other, or concurrently. Optionally, the second load-sharing factor can be generated first, and then the first BIER message can be updated, or the first BIER message can be updated first and then the second load-sharing factor can be generated.

[0171] The method provided in this embodiment utilizes the characteristic that BIERv6 or BIER MPLS packets contain hop-by-hop changing information. It combines the hop-by-hop changing information (i.e., the first information) in the BIER packet with the information in the BIER packet specifically used for load balancing (i.e., the first load balancing factor) to regenerate a new load balancing factor (i.e., the second load balancing factor). Then, the new load balancing factor is used for load balancing. Since the information changing at each hop during the BIER forwarding process is added as a component of the load balancing factor, the load balancing factor used for each hop BFR is different, thereby increasing the balance of load balancing, helping to solve the problem of uneven load balancing, and improving the load balancing effect.

[0172] The following examples illustrate... Figure 2 The method is illustrated with examples. In the following examples, both flow label and entropy refer to... Figure 2 The example illustrating the first load-sharing factor in the method shown below illustrates that, in the following examples, part or all of the content of End.BIER, BFIT ID (MPLS tag), bit string, TTL, hop limit, and device-generated random number are all... Figure 2 An example illustrating the first piece of information in the method shown.

[0173] Example 1

[0174] Example 1 is a solution for balanced load sharing of BIERv6 multicast streams: using the flow label and a portion of End.BIER as load sharing factors.

[0175] The flow label is assigned by the root node BFIR. The flow label carried by each multicast stream remains fixed during forwarding; therefore, the load balancing calculation result obtained by each device based on the flow label is deterministic during forwarding. The End.BIER changes with each hop during forwarding; therefore, adding End.BIER as a component of the load balancing factor increases load balancing balance. For ease of calculation and performance improvement, the 20 bits most likely to change in End.BIER can be selected. Figure 3 This is a schematic diagram of a BIERv6 message format provided in this embodiment. The positions of the flow label and End.BIER in the message can be found in the following diagram. Figure 3 .like Figure 3 As shown, the load sharing factor is generated using the 20-bit flow label in the IPv6 header and the 20 bits in the End.BIER field carried in the destination address field. The specific steps are as follows.

[0176] Figure 4This is a schematic diagram of an IPv6 address format provided in this embodiment. For example... Figure 4 As shown, an IPv6 address consists of 128 bits. The first 64 bits of an IPv6 address are the prefix and subnet portions. The last 64 bits of an IPv6 address are the interface ID portion, which uniquely identifies the device and varies from device to device.

[0177] End.BIER and SRv6 locator typically use the same locator.

[0178] In End.BIER, bits 64-84 are typically the node ID of the device. The node ID identifies a specific device. The function is followed by the node ID. Therefore, optionally, 20 bits (64-84 bits) from End.BIER can be used to perform calculations with the flow label, and the result of this calculation can be used for load balancing. In this way, the load balancing factor is different for each node, and the load balancing result can be effectively balanced.

[0179] Of course, the load balancing factor can also be obtained by operating on bits 64-96 (32 bits) of End.BIER with the flow label. Alternatively, it can be obtained by operating on bits 64-128 (64 bits) of End.BIER with the flow label, or by operating on the entire 128-bit End.BIER with the flow label. Since the main changing part of the 128-bit End.BIER address is bits 64-128, using bits 64-128 with the flow label to obtain the load balancing factor is a relatively efficient method. Bits 64-84 of End.BIER usually represent the device identifier and also change hop by hop. Therefore, considering the need for computational simplification, bits 64-84 of End.BIER can be used with the flow label to obtain the load balancing factor. Bits 64-96 of End.BIER usually represent the device identifier and some functions, which introduces more changes. Therefore, using bits 64-96 of End.BIER to obtain the load balancing factor is also a choice for computational simplification. The entire 128-bit End.BIER changes hop-by-hop. However, since the first few bits are mainly used to delineate large networks and regions, in most scenarios, the first few bits of the End.BIER of adjacent devices do not change when packets are forwarded in the network, unless the adjacent devices are in different regions and this region is identified by the first few bits. Therefore, the scrambling factor can ignore the first few bits. According to IPv6 address partitioning, the first 64 bits of an IPv6 address typically represent the subnet, and the last 64 bits represent the Interface ID. Here, we take the 64 bits of the IPv6 address as is commonly used.

[0180] Because the End.BIER information changes with each hop, the load-sharing factor is different for each hop. Using this changing load-sharing factor for load balancing calculation can more effectively distribute the load and balance the use of network link bandwidth. Load-sharing calculation methods can include hash algorithms (e.g., MD5, SHA-1, SHA-256, SHA-512) or simple modulo / remainder operations on a given value.

[0181] During packet forwarding, if an equivalent forwarding path exists, the load balancing factor can be used to distribute the packet load across different links using a load balancing algorithm. For example, if a packet is forwarded from device A to device B, there are two equivalent paths. The interfaces corresponding to these two equivalent paths on device A are interface 1 and interface 2. Device A calculates the load balancing for multicast stream (S, G1) using a load balancing algorithm (not limited to a specific algorithm, such as modulo, remainder, or other algorithms), and the calculated load balancing result is interface 1. Device A then forwards the multicast group traffic (S, G1) destined for device B through interface 1. Similarly, if device A calculates the load balancing for multicast stream (S, G2) using interface 2, it forwards the multicast group traffic (S, G2) destined for device B through interface 2. This effectively distributes the load across different multicast streams. Here, (S, G) represents the multicast source group information (Source, Group).

[0182] During message forwarding, if the outgoing interface corresponding to the message on the device is the ETH-trunk interface, the device selects a member port from the ETH-trunk interface and forwards the message through the selected member port.

[0183] For example, a message is forwarded from device A to device B. The outgoing interface for the message on device A is ETH-trunk1, which has two member ports: port 1 and port 2. If device A calculates the load balancing of the multicast stream (S, G1) using a load balancing algorithm (which can be modulo, remainder, or other algorithms), and the calculated load balancing result is member port 1 on the ETH-trunk interface, then device A will forward the multicast group traffic (S, G1) destined for device B through member port 1 on the ETH-trunk interface. Similarly, if device A calculates the load balancing of the multicast stream (S, G2) to member port 2 on the ETH-trunk interface, then device A will forward the multicast group traffic (S, G2) destined for device B through member port 2 on the ETH-trunk interface. This distributes the load of different multicast streams across the links corresponding to the different member ports on the ETH-trunk interface.

[0184] Figure 5 This embodiment provides a flowchart of a network device's load balancing process for forwarding BIERv6 packets. Figure 5 As shown, the network device load balancing process includes the following steps S401 to S407.

[0185] S401, The network device received a BIERv6 message.

[0186] S402. The network device checks the destination address (DA, i.e., the destination IP address of the IP datagram) field in the BIERv6 packet to determine that the content of the DA field is the End.BIER address of this node.

[0187] S403. The network device obtains the flow label in the BIERv6 message and the value carried in bits 64-84 of DA (End.BIER).

[0188] S404 The network device performs calculations on the 64-84 bit values ​​of the flow label and DA (End.BIER) to obtain a new load sharing factor.

[0189] S405. The network device queries the BIFT table based on the BIFT ID carried in the BIFT ID field of the BIERv6 message, forwards the data sequentially according to the bit string, and updates the DA field to the End.BIER address of the next-hop BFR before forwarding, and updates the bit string. Afterwards, if load balancing is configured on the network device and there is an equivalent path between the network device and the next-hop BFR, proceed to S406. If the outgoing interface is an Eth-trunk or other bundled interface, proceed to S407.

[0190] S406. The device performs load sharing calculations based on the new load sharing calculation factor and forwards the packets to the corresponding interfaces according to the results.

[0191] S407. The device performs load sharing calculations based on the new load sharing calculation factor and forwards the packets to the corresponding member ports according to the results.

[0192] Figure 5 The described implementation involves first obtaining End.BIER, calculating the load-sharing factor, and then performing BIER forwarding processing. In other embodiments, End.BIER can be updated first during BIER forwarding processing, and then the updated End.BIER can be used to calculate the new load-sharing factor.

[0193] Example 2

[0194] Example 2 is a solution for load balancing of BIER MPLS multicast streams: the load balancing factor is obtained by calculating the BIFT ID (BIER MPLSlabel) and entropy, and the load balancing result can be effectively balanced by using this factor for load balancing calculation.

[0195] Entropy is assigned by the root node BFIR. The entropy carried by each multicast stream remains constant during forwarding; therefore, the load balancing calculation result obtained by each device based on the entropy is fixed during forwarding. In a BIER MPLS forwarding scenario, the BIFT ID is a label assigned to the device and is forwarded hop-by-hop with BIER packets. Typically, different devices assign different labels (BIFT IDs), meaning the BIFT ID changes with each hop during forwarding. Additionally, the TTL (Time-To-Live) for each hop also changes during BIER MPLS packet forwarding. Therefore, adding the BIFT ID or TTL as a component of the load balancing factor increases load balancing balance.

[0196] Figure 6 This is a schematic diagram of a BIER MPLS encapsulation format provided in this embodiment. The BIFT ID and its location within the message can be found in [reference needed]. Figure 6 .

[0197] Example 3

[0198] For both BIERv6 and BIER MPLS, the changed portion of the packet during forwarding can be combined with the load-sharing value (flow label or entropy) carried in the packet to regenerate a new load-sharing factor, ensuring effective load sharing at each hop during forwarding. Since the bit string changes with each hop in BIERv6 and BIER MPLS packet forwarding, the bit string can also be calculated with the load-sharing factor carried in the original packet to obtain a new load-sharing factor. Optionally, upon receiving a packet, the bit string can be calculated with the original load-sharing factor to obtain a new load-sharing factor; alternatively, BIER forwarding can be performed first to update the bit string, and then the updated bit string can be calculated with the original load-sharing factor when forwarding the packet to obtain a new load-sharing factor before load-sharing calculation and forwarding. This embodiment does not limit the use of either processing order; a suitable processing order can be chosen based on implementation convenience.

[0199] Similar to the previous embodiments, the specific method for performing operations on bit strings and flow labels / entropy can be addition, subtraction, multiplication, division, shifting, addition, logical AND, logical OR, etc.

[0200] Example 4

[0201] For BIERv6 and BIER MPLS, other variable fields can also be selected as load balancing scrambling factors. During BIERv6 packet forwarding, the hop limit in the IPv6 header changes hop-by-hop; therefore, the hop limit can also be used as a load balancing scrambling factor, merging it with the original load balancing factor (flow label) to form a new load balancing factor, thus enhancing the load balancing balance of BIERv6. During BIER MPLS packet forwarding, the TTL (Time-To-Live) also changes with each hop. Therefore, TTL can be selected as a load balancing scrambling factor, merging it with the original load balancing factor (entropy) to form a new load balancing factor, further enhancing the load balancing balance of BIER MPLS.

[0202] In addition, in unicast forwarding scenarios, TTL also changes hop by hop as the packet is forwarded. Therefore, TTL can also be used as a scrambling factor for unicast load balancing to enhance the balance of unicast load balancing.

[0203] Example 5

[0204] For BIERv6 and BIER MPLS, a separate scrambling factor can be configured. At each node, a random number is generated and combined with the original load-sharing value (flow label or entropy) carried in the packet to regenerate a new load-sharing factor, ensuring effective load sharing at each hop during forwarding. This method requires configuration on each node, making deployment complex and consuming more hardware resources. Alternatively, the load-sharing effect of BIERv6 and BIER MPLS can be balanced by reusing unicast scrambling random numbers. This method relies on unicast configuration, is also complex to deploy, and adjustments to this parameter to modify load-sharing can lead to interference between unicast and multicast.

[0205] In summary, in the BIERv6 multicast scenario, by utilizing the hop-by-hop change of End.BIER in the message, during load balancing, all or part of End.BIER is calculated with the flow label specifically used for load balancing to balance the load balancing, optimize the load balancing effect, and make full use of network link resources to maximize network utilization.

[0206] In BIER MPLS multicast scenarios, the BFIT ID in the packet is independently allocated by each node and the label changes during forwarding. During load balancing, the BFIT ID is calculated with the entropy specifically used for load balancing to balance the load and optimize the load balancing effect.

[0207] In BIER MPLS and BIERv6 multicast scenarios, the characteristic of the bit string value in the packet changing hop by hop during forwarding is utilized. During load sharing, the bit string is calculated with the flow label (SRv6) / entropy (BIERMPLS) specifically used for load sharing to balance the load sharing and optimize the load sharing effect.

[0208] In BIER MPLS multicast scenarios, the TTL in the packet changes hop-by-hop during forwarding. In BIERv6 multicast scenarios, the hop limit in the IPv6 header changes hop-by-hop during forwarding. During load balancing, the TTL (BIER MPLS) or hop limit (BIERv6) is used as a scrambling factor for load balancing. This factor is then combined with the original load balancing factor entropy (BIER MPLS) or flow label (BIERv6) to form a new load balancing factor, thereby enhancing the load balancing balance between BIER MPLS and BIERv6.

[0209] In BIER MPLS and BIERv6 multicast scenarios, a scrambling factor can be added by configuration to calculate the original load sharing value flow label (SRv6) / entropy (BIER MPLS) carried by the packet with the scrambling factor, thereby balancing the load sharing and optimizing the load sharing effect.

[0210] In summary, the beneficial effects of the above embodiments include, but are not limited to: solving the problem of uneven load sharing in BIER MPLS / BIERv6 multicast forwarding without additional configuration, enabling full utilization of network link resources and maximizing the overall network utilization.

[0211] Examples 1 to 5 above are illustrative. Load balancing is not limited to using the values ​​described in Examples 1 to 5 above for calculation. Any part that changes during the packet forwarding process can be used to calculate with the original load balancing value flow label (SRv6) / entropy (BIER MPLS) carried in the packet to obtain a new load balancing factor and optimize the load balancing result.

[0212] Furthermore, load balancing methods are not limited to multicast; some solutions are also applicable to unicast. For example, using the TTL (Time To Live) in the packet as a load-sharing scrambling factor is also suitable for unicast scenarios. However, the other methods mentioned above, which use fields specific to BIER MPLS / BIERv6 packets as scrambling factors, cannot be applied to unicast. If TTL is used as the scrambling factor for unicast, the calculation of the scrambling factor and the load-sharing factor to obtain a new load-sharing factor for load balancing achieves the same effect as multicast processing.

[0213] In addition to load balancing for BIER MPLS and BIERv6 multicast packet forwarding, other multicast packets can also use the per-hop change value carried in the packet as a scrambling factor to further balance the load. For example, protocol-independent multicast (PIM) multicast can use the TTL field in the packet header as a scrambling factor, and next-generation multicast virtual private network (NGMVPN) multicast packet forwarding based on MPLS can also use the TTL field in the MPLS encapsulation as a scrambling factor.

[0214] Appendix Figure 7 This is a schematic diagram of the structure of a message forwarding device 500 provided in an embodiment of this application. The device 500 includes a receiving unit 501, a processing unit 502, and a sending unit 503.

[0215] Optionally, in conjunction with the appendix Figure 1 From the application scenarios shown, attached Figure 7 The device 500 shown is provided in the attached Figure 1 The root node, intermediate node A, intermediate node B, leaf node A, and leaf node B are any one of the following nodes: root node, intermediate node A, intermediate node B, leaf node A, and leaf node B.

[0216] Optionally, in conjunction with the appendix Figure 2 Let's take a look, attached Figure 7 The device 500 shown is provided in the attached Figure 2 The network device in the process. The receiving unit 501 is used to support the device 500 in executing S101. The processing unit 502 is used to support the device 500 in executing S102 to S103. The sending unit 503 is used to support the device 500 in executing S104.

[0217] Optionally, in conjunction with the appendix Figure 5 Let's take a look, attached Figure 7 The device 500 shown is provided in the attached Figure 5 The device in question. The receiving unit 501 supports the device 500 in executing S401. The processing unit 502 supports the device 500 in executing S402 to S407. The sending unit 503 supports the device 500 in executing the steps of forwarding messages to the interface in S406 and S407.

[0218] Appendix Figure 7The described device embodiments are merely illustrative. For example, the division of the units described above is only a logical functional division. 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. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0219] Each unit in device 500 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof.

[0220] In the case of software implementation, for example, the aforementioned processing unit 502 is provided by an attached... Figure 8 The software functional unit generated by at least one processor 801 reads the program code stored in memory 802 and implements it.

[0221] In the case of hardware implementation, for example, attached Figure 7 The aforementioned units are implemented by different hardware components within the device. For example, the processing unit 502 is implemented by an attached... Figure 8 The receiving unit 501 and the transmitting unit 503 are implemented using a portion of the processing resources of at least one processor 801 (e.g., one or two cores of a multi-core processor), or by using a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Figure 8 The network interface is implemented in 803.

[0222] Appendix Figure 8 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. The network device 600 includes at least one processor 601, a memory 602, and at least one network interface 603.

[0223] Optionally, in conjunction with the appendix Figure 1 From the application scenarios shown, attached Figure 7 The network device 600 shown is an accessory. Figure 1 The root node, intermediate node A, intermediate node B, leaf node A, and leaf node B are any one of the following nodes: root node, intermediate node A, intermediate node B, leaf node A, and leaf node B.

[0224] Optionally, in conjunction with the appendix Figure 2 Let's take a look, attached Figure 7 The network device 600 shown is an accessory. Figure 2 The network device 600 is configured to support network device 600 in executing S101 and S104. The processor 601 is configured to support network device 600 in executing S102 to S103.

[0225] Optionally, in conjunction with the appendix Figure 5 Let's take a look, attached Figure 7 The network device 600 shown is located in the attached Figure 5 The network interface 603 is used to support the network device 600 in executing S401. The processor 601 is used to support the network device 600 in executing S402 to S407. The network interface 603 includes the output interface in S406 and the bonding interface in S407.

[0226] Processor 601 may be, for example, a general-purpose central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the embodiments of this application. For example, processor 601 may include an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. A PLD may be, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0227] Memory 602 may be, for example, read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Optionally, memory 602 exists independently and is connected to processor 601 via internal connection 604. Alternatively, memory 602 and processor 601 may be integrated together.

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

[0229] In some embodiments, processor 601 includes one or more CPUs, as shown in the appendix. Figure 8 CPU0 and CPU1 are shown in the diagram.

[0230] In some embodiments, the network device 600 may optionally include a plurality of processors, as shown in the appendix. Figure 8 The processors 601 and 605 are shown. Each of these processors is, for example, a single-core processor (CPU) or a multi-core processor (CPU). A processor here may optionally refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0231] In some embodiments, the network device 600 further includes an internal connection 604. The processor 601, memory 602, and at least one network interface 603 are connected via the internal connection 604. The internal connection 604 includes pathways for transmitting information between the aforementioned components. Optionally, the internal connection 604 is a single board or a bus. Optionally, the internal connection 604 may be divided into an address bus, a data bus, a control bus, etc.

[0232] In some embodiments, network device 600 further includes an input / output interface 606. The input / output interface 606 is connected to internal connection 604.

[0233] Optionally, the processor 601 implements the method in the above embodiments by reading the program code 610 stored in the memory 602, or the processor 601 implements the method in the above embodiments by internally stored program code. When the processor 601 implements the method in the above embodiments by reading the program code 610 stored in the memory 602, the memory 602 stores program code that implements the method provided in the embodiments of this application.

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

[0235] See appendix Figure 9 , attached Figure 9 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. The network device 700 includes: a main control board 710 and an interface board 730.

[0236] Optionally, in conjunction with the appendix Figure 1 From the application scenarios shown, attached Figure 9 The network device 700 shown is an accessory. Figure 1 The root node, intermediate node A, intermediate node B, leaf node A, and leaf node B are any one of the following nodes: root node, intermediate node A, intermediate node B, leaf node A, and leaf node B.

[0237] Optionally, in conjunction with the appendix Figure 2 Let's take a look, attached Figure 9 The network device 700 shown is an accessory. Figure 2 The network device in the system. Interface board 730 is used to support network device 700 in performing S101 to S104.

[0238] Optionally, in conjunction with the appendix Figure 5 Let's take a look, attached Figure 9 The network device 700 shown is located in the attached Figure 5 The interface board 730 is used to support network device 700 in performing S401 to S407. The interface board 730 includes the outgoing interface in S406 and the bonding interface in S407.

[0239] The main control board, also known as the main processing unit (MPU) or route processor card, is used to control and manage the various components in the network device 700, including route calculation, device management, device maintenance, and protocol processing functions. The main control board 710 includes a central processing unit 711 and a memory 712.

[0240] Interface board 730, also known as line processing unit (LPU), linecard, or service board, provides various service interfaces and enables packet forwarding. Service interfaces include, but are not limited to, Ethernet interfaces, POS (packet over SONET / SDH) interfaces, and, for example, flexible Ethernet clients (FlexE clients). Interface board 730 includes: a central processing unit 731, a network processor 732, a forwarding table entry memory 734, and a physical interface card (PIC) 733.

[0241] The central processing unit 731 on the interface board 730 is used to control and manage the interface board 730 and communicate with the central processing unit 711 on the main control board 710.

[0242] Network processor 732 is used to implement packet forwarding processing. Network processor 732 can be, for example, a forwarding chip. Specifically, network processor 732 forwards received packets based on the forwarding table stored in forwarding table entry memory 734. If the destination address of the packet is the address of network device 700, the packet is sent to the CPU (such as central processing unit 711) for processing; if the destination address of the packet is not the address of network device 700, the next hop and outgoing interface corresponding to the destination address are looked up in the forwarding table according to the destination address, and the packet is forwarded to the outgoing interface corresponding to the destination address. Uplink packet processing includes: packet ingress interface processing, forwarding table lookup; downlink packet processing includes forwarding table lookup, etc.

[0243] The physical interface card 733 is used to implement physical layer interfacing functions. Raw traffic enters the interface board 730 through this card, and processed packets are sent out from the physical interface card 733. The physical interface card 733, also called a daughter card, can be installed on the interface board 730. It is responsible for converting photoelectric signals into packets, performing validity checks on the packets, and forwarding them to the network processor 732 for processing. In some embodiments, the central processing unit can also perform the functions of the network processor 732, such as implementing software forwarding based on a general-purpose CPU, thus eliminating the need for a network processor 732 in the physical interface card 733.

[0244] Optionally, the network device 700 includes multiple interface boards. For example, the network device 700 also includes an interface board 740, which includes a central processing unit 741, a network processor 742, a forwarding table entry memory 744, and a physical interface card 743.

[0245] Optionally, the network device 700 also includes a switching fabric board 720. The switching fabric board 720 is also referred to, for example, as a switch fabric unit (SFU). In cases where the network device has multiple interface boards 730, the switching fabric board 720 is used to perform data exchange between the interface boards. For example, interface boards 730 and 740 communicate, for instance, through the switching fabric board 720.

[0246] The main control board 710 and the interface board 730 are coupled. For example, the main control board 710, interface board 730, interface board 740, and switching network board 720 communicate with each other via a system bus connected to the system backplane. In one possible implementation, an inter-process communication (IPC) channel is established between the main control board 710 and the interface board 730, and the main control board 710 and the interface board 730 communicate with each other through the IPC channel.

[0247] Logically, network device 700 includes a control plane and a forwarding plane. The control plane includes a main control board 710 and a central processing unit 731, while the forwarding plane includes various components that perform forwarding, such as a forwarding table entry memory 734, a physical interface card 733, and a network processor 732. The control plane performs functions such as router operation, generating forwarding tables, processing signaling and protocol messages, and configuring and maintaining the device's status. The control plane distributes the generated forwarding tables to the forwarding plane. In the forwarding plane, the network processor 732 looks up the packets received by the physical interface card 733 based on the forwarding tables distributed by the control plane before forwarding them. The forwarding tables distributed by the control plane are stored, for example, in the forwarding table entry memory 734. In some embodiments, the control plane and the forwarding plane are, for example, completely separate and not on the same device.

[0248] The operation on interface board 740 is the same as that on interface board 730, so for the sake of simplicity, it will not be described again.

[0249] A network device may have one or more main control boards, including primary and backup boards. It may also have one or more interface boards; the more powerful the network device's data processing capabilities, the more interface boards it provides. Each interface board may also have one or more physical interface cards. A switching board may or may not exist; multiple boards can share the load and provide redundancy. In a centralized forwarding architecture, the network device may not need a switching board, as the interface boards handle the entire system's business data processing. In a distributed forwarding architecture, the network device can have at least one switching 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 network device are greater than those of a centralized architecture device. Alternatively, the network device can also be a single board, without a switching board. The functions of the interface board and the main control board are integrated on this one board. In this case, the central processing unit (CPU) on the interface board and the CPU on the main control board can be combined into a single CPU to perform the combined functions. This type of device has lower data exchange and processing capabilities (e.g., low-end switches or routers). The specific architecture used depends on the specific network deployment scenario, and no restrictions are imposed here.

[0250] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0251] A references B, which means that A is the same as B or A is a simple variation of B.

[0252] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects, and should not be construed as indicating or implying relative importance. For example, "first load sharing factor" and "second load sharing factor" are used to distinguish different load sharing factors, not to describe a specific order of load sharing factors, and should not be construed as the first load sharing factor being more important than the second load sharing factor.

[0253] In the embodiments of this application, unless otherwise stated, "at least one" means one or more, and "multiple" means two or more.

[0254] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0255] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A message forwarding method, characterized in that, The method includes: The network device receives a first bit-based explicit copy BIER message. The first BIER message includes a first load-sharing factor and first information. The first load-sharing factor refers to information used for load balancing during BIER forwarding, and the first information refers to information that changes hop by hop during BIER forwarding. The network device generates a second load-sharing factor based on the first load-sharing factor and the first information; The network device determines the first interface from a plurality of interfaces based on the second load-sharing factor; The network device sends a second BIER message through the first interface. The second BIER message is obtained by updating the first BIER message by the network device. The second BIER message includes the first load sharing factor and second information. The second information is obtained by updating the first information by the network device.

2. The method according to claim 1, characterized in that, The first information includes the identifier of the network device, and the second information includes the identifier of the next-hop BIER forwarding router (BFR) of the network device.

3. The method according to claim 2, characterized in that, The first information also includes the functional information of the network device, and the second information also includes the functional information of the next-hop network frame (BFR) of the network device.

4. The method according to any one of claims 1 to 3, characterized in that, The first BIER message includes the End.BIER address of the network device, and the first information is all or part of the content of the End.BIER address in the first BIER message.

5. The method according to claim 4, characterized in that, The first information is bits 64 to 84 of the End.BIER address stated in the first BIER message; or, The first information is bits 64 to 96 of the End.BIER address stated in the first BIER message; or, The first information is bits 64 to 128 of the End.BIER address stated in the first BIER message; or, The first information is the End.BIER address in the first BIER message.

6. The method according to claim 1, characterized in that, The first information includes a Multiprotocol Label Switching (MPLS) label assigned by the network device, and the second information includes an MPLS label assigned by the network device's Next Hop BFR.

7. The method according to claim 1 or 6, characterized in that, The first information indicates at least one of the following: the subdomain to which the network device belongs in the BIER domain, the bit string length (BSL) used by the network device, and the set identifier (SI) to which the BIER forwarding router identifier (BFR ID) of the network device belongs.

8. The method according to claim 6 or 7, characterized in that, The first information is the content of the BIFT ID field of the bit index forwarding table in the first BIER message.

9. The method according to claim 1, characterized in that, The first load-sharing factor includes the flow identifier of the multicast stream to which the first BIER message belongs.

10. The method according to claim 9, characterized in that, The first load-sharing factor is the content of the flow label field in the IPv6 header of the first BIER message; or, The first load-sharing factor is the content of the entropy field in the first BIER message.

11. The method according to claim 1, characterized in that, The first information includes the identifier of the destination bit forwarding egress router BFER set of the first BIER message.

12. The method according to claim 1 or 11, characterized in that, The first information is the content carried by the bit string field in the first BIER message.

13. The method according to claim 1, characterized in that, The first piece of information includes Time To Live (TTL) or Hop Limit.

14. The method according to any one of claims 1 to 13, characterized in that, The first BIER message is either a BIERv6 message or a BIER MPLS message based on the IPv6 data plane.

15. The method according to claim 1, characterized in that, The network device generates a second load-sharing factor based on the first load-sharing factor and the first information, including: The network device generates random numbers; The network device generates a second load-sharing factor based on the first load-sharing factor, the first information, and the random number.

16. A message forwarding device, characterized in that, The device is located on a network device, and the device includes: The receiving unit is configured to receive a first BIER message, the first BIER message including a first load-sharing factor and first information, the first load-sharing factor being information used for load balancing during BIER forwarding, and the first information being information that changes hop-by-hop during BIER forwarding. The processing unit is configured to generate a second load-sharing factor based on the first load-sharing factor and the first information; and determine a first interface from multiple interfaces of the network device based on the second load-sharing factor. The sending unit is configured to send a second BIER message through the first interface. The second BIER message is obtained by the network device updating the first BIER message. The second BIER message includes the first load sharing factor and second information, which is obtained by the network device updating the first information.

17. A network device, characterized in that, The network device includes: a processor coupled to a memory, the memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the network device to implement the method of any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, which, when executed on a computer, causes the computer to perform the method as described in any one of claims 1-15.

19. A computer program product, characterized in that, The computer program product includes one or more computer program instructions that, when loaded and run by a computer, cause the computer to perform the method of any one of claims 1-15.

Images