Method and device for determining forwarding path

Abstract

This application provides a method and apparatus for determining a forwarding path, belonging to the field of network technology. When a P2MP path needs to be determined for a specific multicast stream, this application eliminates the need to recalculate the entire P2MP path. Instead, the P2MP path for the multicast stream is determined based on the P2P path corresponding to the destination leaf node of the multicast stream in the existing P2MP path. This significantly reduces the computational effort required to determine the P2MP path, saves calculation overhead, and facilitates efficient and rapid P2MP path calculation.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a method and device for determining a forwarding path. Background Art

[0002] Multicast technology enables point-to-multipoint data transmission in Internet Protocol (IP) networks and is widely used in scenarios such as live video streaming, online education, and video conferencing. Multicast technology requires computing point-to-multipoint (P2MP) paths so that network devices can forward multicast streams to multiple leaf nodes along these paths.

[0003] In related technologies, when a P2MP path for a multicast stream needs to be calculated, the P2MP path is calculated based on the multicast stream's destination leaf node and the multicast stream's required service-level agreement (SLA). Subsequently, whenever a leaf node joins or leaves, or a link changes, the multicast stream's leaf node is re-determined, and the P2MP path is recalculated based on the multicast stream's new destination leaf node and the multicast stream's required SLA. This approach results in a computationally intensive path calculation, resulting in significant overhead. Summary of the Invention

[0004] The present application provides a method, apparatus, device, and storage medium for determining a forwarding path, which can reduce the overhead of determining a P2MP path. The technical solution is as follows.

[0005] In a first aspect, a method for determining a forwarding path is provided. The method is applied to a root node of a first point-to-multipoint (P2MP) path, comprising: obtaining n point-to-point (P2P) paths based on the first P2MP path and n leaf nodes for receiving a first multicast stream, where the first P2MP path includes n P2P paths, where n is a positive integer less than or equal to the number of leaf nodes in the first P2MP path; and obtaining a second P2MP path based on the n P2P paths, where the second P2MP path is used to forward the first multicast stream to the n leaf nodes.

[0006] By using this method, when a root node needs to determine a P2MP path for a specific multicast stream, it does not need to recalculate the entire P2MP path. Instead, it determines the P2MP path for the multicast stream based on the P2P path corresponding to the destination leaf node in the existing P2MP path. This greatly reduces the computation required to determine the P2MP path, saves path calculation overhead, and facilitates efficient and rapid P2MP path calculation.

[0007] In a possible implementation, the first node of any P2P path among the n P2P paths is the root node of the first P2MP path, and the last node of any P2P path among the n P2P paths is a leaf node of the first P2MP path.

[0008] By adopting the above implementation method, since a P2MP path (first P2MP path) passing through all possible leaf nodes of the multicast stream is pre-established, the P2P path in the pre-established P2MP path can be reused in various scenarios such as when the destination leaf node of the multicast stream joins or leaves, without the need to recalculate the entire path. This further saves path calculation overhead and helps meet path calculation requirements in various scenarios such as when the destination leaf node of the multicast stream joins or leaves.

[0009] In one possible implementation, the process of the root node obtaining the second P2MP path for the first multicast stream specifically includes: obtaining a bit string corresponding to each of the n P2P paths; and obtaining a bit string corresponding to the second P2MP path based on the bit string corresponding to each of the n P2P paths, where the bit string corresponding to the second P2MP path is a result of performing an OR operation on the bit strings corresponding to all the P2P paths included in the n P2P paths.

[0010] The above implementation method provides a specific implementation method for path calculation in the BIER tree engineering (BIER-TE) scenario, which can support the efficient calculation of P2MP paths in the BIER-TE scenario.

[0011] In one possible implementation, the process of the root node obtaining the second P2MP path for the first multicast stream specifically includes: obtaining a segment list corresponding to each of the n P2P paths; and obtaining a segment list corresponding to the second P2MP path based on the segment list corresponding to each of the n P2P paths, where the segment list corresponding to the second P2MP path includes segment identifiers in the segment lists corresponding to all P2P paths included in the n P2P paths.

[0012] The above implementation provides a specific implementation method for path calculation in a segment routing (SR) P2MP scenario, and can support efficient calculation of P2MP paths in the SR P2MP scenario.

[0013] In one possible implementation, the first P2MP path is a path established based on a preset service-level agreement (SLA) requirement and m preset leaf nodes. The SLA requirement of the first multicast stream is the same as the preset SLA requirement, and m is the number of leaf nodes included in the first P2MP path.

[0014] In the above implementation, a P2MP path (first P2MP path) is determined in advance based on the preset SLA requirements and a preset set of leaf nodes. When a P2MP path needs to be determined for a multicast group that requires a specific SLA, a P2MP path that meets the SLA requirements can be determined based on the pre-established P2MP path, thereby meeting the service's SLA requirements.

[0015] In a possible implementation, the first P2MP path is a path before multicast joining or multicast exit in the multicast group corresponding to the first multicast stream.

[0016] Through the above implementation, in the scenario where the leaf node changes due to the addition or removal of the destination receiver of the multicast stream, a new P2MP path can be obtained by combining the P2P path corresponding to the current leaf node in the original P2MP path without recalculating the path based on the entire network topology, thereby improving the efficiency of path calculation in the scenario where the destination receiver of the multicast stream joins or leaves.

[0017] In a possible implementation, the first P2MP path is used to forward a second multicast stream, and an SLA requirement of the second multicast stream is the same as an SLA requirement of the first multicast stream.

[0018] With the above implementation, when multiple multicast streams require the same SLA, the P2MP path of one multicast stream can be reused to determine the P2MP path of another multicast stream, without having to recalculate the P2MP path for each multicast stream. This improves the efficiency of path calculation in scenarios with multiple multicast streams.

[0019] In one possible implementation, after obtaining the second P2MP path based on the n P2P paths, the method further includes: if a first P2P path included in the second P2MP path fails, obtaining a third P2MP path based on the second P2MP path, where the third P2MP path includes a backup path of the first P2P path and P2P paths other than the first P2P path among the n P2P paths.

[0020] With the above implementation, when a fault occurs in a P2MP path, an updated P2P path can be obtained by switching the P2P path at the fault point to the corresponding backup path without having to switch every P2P path. This helps to quickly update the path, improves system stability, and saves the overhead of updating the P2MP path, thereby improving the efficiency of updating the P2MP path.

[0021] In a possible implementation, before obtaining n point-to-point P2P paths based on the first P2MP path and the n leaf nodes for receiving the first multicast stream, the method further includes:

[0022] A multicast policy is acquired based on the SLA requirement of the first multicast stream, where the multicast policy includes information of the n P2P paths and information for identifying the SLA requirement.

[0023] By adopting the above implementation, since the multicast policy includes information about multiple P2P paths in the P2MP path and the SLA requirements, when a P2MP path needs to be determined for a multicast stream requiring a specific SLA, the P2P path can be obtained by searching for a multicast policy that matches the SLA. This eliminates the need to temporarily split the P2MP path into P2P paths during path calculation, thereby further improving path calculation efficiency.

[0024] In a possible implementation, the information of the n P2P paths in the multicast strategy includes a bit string or a segment list corresponding to each of the n P2P paths.

[0025] By adopting the above implementation, only one multicast policy is required to be issued for multiple P2P paths corresponding to multiple leaf nodes in a P2MP path, without issuing a multicast policy for each P2P path corresponding to each leaf node, thereby avoiding frequent policy issuance.

[0026] In a possible implementation, the information of the n P2P paths in the multicast strategy further includes a bit string or segment list corresponding to a backup path of each of the n P2P paths.

[0027] By adopting the above implementation, when a P2P path fails, the backup path of the P2P path can be found from the multicast strategy so that the P2P path can be switched to the backup path, thereby reducing the delay of switching paths when a failure occurs and improving stability.

[0028] In a second aspect, a device for determining a forwarding path is provided, wherein the device has the function of implementing the first aspect or any optional method of the first aspect. The device includes at least one unit configured to implement the method provided in the first aspect or any optional method of the first aspect.

[0029] In some embodiments, the units in the forwarding path determination apparatus are implemented via software, and the units in the forwarding path determination apparatus are program modules. In other embodiments, the units in the forwarding path determination apparatus are implemented via hardware or firmware. Specific details of the forwarding path determination apparatus provided in the second aspect can be found in the first aspect or any of the optional embodiments of the first aspect, and are not further described here.

[0030] In a third aspect, a routing device is provided. The routing device is provided as a root node of a P2MP path. The routing device includes a processor coupled to a memory. The memory stores at least one computer program instruction. The at least one computer program instruction is loaded and executed by the processor to cause the routing device to implement the method provided in the first aspect or any optional embodiment of the first aspect. Specific details of the routing device provided in the third aspect can be found in the first aspect or any optional embodiment of the first aspect, and are not further described here.

[0031] In a fourth aspect, a routing device is provided, which serves as a root node of a P2MP path. The routing device includes a main control board and an interface board. The main control board includes a first processor and a first memory. The interface board includes a second processor, a second memory, and an interface card. The main control board and the interface board are coupled.

[0032] The first memory may be used to store program code, and the first processor is used to call the program code in the first memory to perform the following operations: obtaining n point-to-point P2P paths based on the first P2MP path and n leaf nodes for receiving the first multicast stream, where the first P2MP path includes the n P2P paths, where n is a positive integer less than or equal to the number of leaf nodes of the first P2MP path; and obtaining a second P2MP path based on the n P2P paths.

[0033] The second memory may be used to store program codes, and the second processor is used to call the program codes in the second memory to trigger the interface card to perform the following operations: forwarding the first multicast stream to the n leaf nodes through the second P2MP path.

[0034] In a possible implementation, an inter-process communication (IPC) channel is established between the main control board and the interface board, and the main control board and the interface board communicate with each other through the IPC channel.

[0035] In a fifth aspect, a computer-readable storage medium is provided, which stores at least one instruction. When the instruction is executed on a computer, the computer executes the method provided by the first aspect or any optional method of the first aspect.

[0036] In a sixth aspect, a computer program product is provided, which includes one or more computer program instructions. When the computer program instructions are loaded and run by a computer, the computer executes the method provided by the first aspect or any optional method of the first aspect.

[0037] In the seventh aspect, a chip is provided, comprising a memory and a processor, wherein the memory is used to store computer instructions, and the processor is used to call and run the computer instructions from the memory to execute the method in the above-mentioned first aspect and any possible implementation of the first aspect.

[0038] In an eighth aspect, a network system is provided, comprising the routing device of the third or fourth aspect, and further comprising a controller. The controller is configured to send a multicast policy to the routing device, the multicast policy including information about multiple P2P paths in a P2MP path and information identifying SLA requirements corresponding to the P2MP paths. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 2 This is a schematic diagram of the encoding structure of a segment list of a P2MP path provided in an embodiment of the present application;

[0041] Figure 3 This is a schematic diagram of a segment list of a P2MP path provided in an embodiment of the present application;

[0042] Figure 4 This is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0043] Figure 5 This is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0044] Figure 6 This is a schematic diagram of an implementation environment provided by an embodiment of the present application;

[0045] Figure 7This is a flow chart of a method for determining a forwarding path provided by an embodiment of the present application;

[0046] Figure 8 This is a schematic diagram of a failure occurring in a P2MP path provided by an embodiment of the present application;

[0047] Figure 9 This is an architecture diagram of a BIER-TE network provided in an embodiment of the present application;

[0048] Figure 10 This is a schematic diagram of merging P2P paths in a BIER-TE network provided in an embodiment of the present application;

[0049] Figure 11 This is an architecture diagram of an SR P2MP network provided in an embodiment of the present application;

[0050] Figure 12 This is a schematic diagram of merging P2P paths in an SR P2MP network provided by an embodiment of the present application;

[0051] Figure 13 This is a schematic diagram of the structure of a multicast strategy provided by an embodiment of the present application;

[0052] Figure 14 This is a schematic diagram of an implementation environment provided by an embodiment of the present application;

[0053] Figure 15 6 is a schematic structural diagram of a forwarding path determination device 600 provided in an embodiment of the present application;

[0054] Figure 16 This is a schematic diagram of the structure of a routing device provided in an embodiment of the present application;

[0055] Figure 17 This is a structural diagram of another routing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0057] Some embodiments of the present application use the form of "<identity of each node that the path passes through>" to simply represent a specific path, for example<P1,P2,P3> Represents a path passing through node P1, node P2 and node P3. In some embodiments of the present application, the message explicitly indicates the forwarding path of the message by carrying a bit string (BitString) or a segment list (segments list). The form of the bit string is, for example, a digital sequence containing 0 or 1, and more details of the bit string can be found in the introduction below. The form of the segment list is, for example, a sequence containing multiple segment identifiers (segment IDs, SIDs), and the form of the SID includes but is not limited to Internet Protocol version 6 (IPv6) addresses or multi-protocol label switching (MPLS) labels. More details of the segment list can be found in the introduction below.

[0058] The following is an explanation of some terminology concepts involved in the embodiments of this application.

[0059] (1) Multicast segment identifier (multicast SID)

[0060] A multicast SID (segment identifier, SID) is also called a replication SID or a multicast SID. In a domain that supports segment routing (SR) multicast, each node typically has a multicast node SID, and each adjacency of each node typically has a multicast adjacency SID. A multicast SID of a node on an SR P2MP path is associated with the SIDs of multiple next-hop (or downstream) nodes of the node. When a node receives a message containing its own multicast SID, the node replicates the message and forwards it to each of the multiple next-hop nodes based on the SIDs of the multiple next-hop nodes. The parameter fields of the multicast SID include the number of branches under the node (N-branches) and the number of SIDs under the node (N-SIDs).

[0061] (2)N-branches

[0062] N-branches is a parameter carried by the multicast SID. N-branches indicates how many child nodes the node to which the multicast SID belongs has. In other words, N-branches is equal to the number of next-hop nodes (or branches) of the node to which the multicast SID belongs on the P2MP path. For example, in Figure 1In the topology shown, N-branches in the multicast SID of node P1 is 2. When node P1 receives a packet carrying its multicast SID, node P1 sends the packet to its two next-hop nodes (nodes P2 and P3) based on N-branches being 2.

[0063] (3) Encoding structure of segment lists for point-to-multipoint (P2MP) paths

[0064] The segment list of a P2MP path is encoded according to the hierarchical structure of the P2MP tree. Specifically, if a node i that the P2MP path passes through has B next-hop nodes, then the SID of node i in the segment list is followed by the SIDs of each of the B next-hop nodes, followed by the SIDs of the subtrees of each next-hop node, where B is an integer greater than or equal to 1. Figure 2 A schematic diagram of the encoding structure of the segment list of the P2MP path is shown, Figure 2 As shown, node i is equivalent to the root node of the P2MP tree, or the first-level node in the P2MP tree. The SID of node i ( Figure 2 The SIDi in the segment list is the first SID. The B next-hop nodes of node i are equivalent to the second-level nodes of the P2MP tree, or the B branches of the root node. Figure 2 As shown, the SID of node i in the segment list ( Figure 2 The SID of the first child node of node i is followed by the SID of B next-hop nodes. Figure 2 SIDi1 in ), followed by the SID of the second child of node i ( Figure 2 SIDi2 in ), followed by the SID of the third child of node i ( Figure 2 Not shown), and so on, followed by the SID of the last child node of node i ( Figure 2 The next hop node of the next hop node of node i (also called the child node of the child node of node i) is equivalent to the third-level node of the P2MP tree, or the subtree from the child node of node i. Figure 2 As shown, after the SIDs of B next-hop nodes, the first is the subtree of the first child node of node i ( Figure 2 SegSeq1 in ), then the subtree of the second child of node i ( Figure 2 SegSeq2 in ), and so on, until the subtree of the last child node of node i ( Figure 2 SegSeqBi in ).

[0065] Combine Figure 1 According to the topology shown, Figure 1The encoding structure of the segment list of the P2MP path in the shown topology may be optionally as follows: Figure 3 Please refer to Figure 3 , Figure 1 The P2MP path shown can be viewed as a tree with node P1 as the root. Node P1 belongs to the first level of the tree. The two child nodes of node P1, namely node P2 and node P3, belong to the second level of the tree, and so on. Figure 1 The hierarchical structure of the P2MP path in is encoded Figure 3 Middle list. Figure 3 As shown, the multicast SIDs in the segment list are arranged in order from the first layer to the last layer, starting with the SID of the first layer node ( Figure 3 P1 in ), followed by the SID of the second-layer node ( Figure 3 P2 and P3 in ), followed by the SID sequence corresponding to the subtree of the second-level nodes.

[0066] (4) Bit-indexed explicit replication (BIER)

[0067] BIER is a new technology for forwarding multicast data packets. The typical feature of BIER technology is that the destination node set of the multicast data packet is encapsulated in the message header in the form of a bit string (BitString) for transmission, so that the intermediate nodes in the network do not need to establish a multicast tree for each multicast stream and save the multicast stream status, thereby reducing resource usage. The basic process of forwarding based on BIER technology is that when a multicast data packet enters the BIER domain, the bitforwarding ingress router (BFIR) determines the set of bitforwarding egress routers (BFER) to which the message needs to be sent. BFIR encapsulates the BIER option (also called BIER header) into the message. The BIER option contains BitString. BFIR can also be called the entry node in the BIER domain. BFER can also be called the egress node in the BIER domain.

[0068] In some embodiments of the present application, BIER generally refers to a method of encapsulating and forwarding messages based on BitString, that is, the sending end encapsulates BitString into the message, and the routing device receives the message containing the BitString and copies the message to the destination node based on the BitString. In some embodiments of the present application, the BIER message reuses the original BIER message format.

[0069] (5)BitString

[0070] BitString is used to identify one or more nodes or one or more links on the forwarding path of the message. BitString includes multiple bits (bit positions, BP). Each bit in the BitString corresponds to a node or a link. Each set bit in the BitString is used to identify a node or a link that the message will pass through. The nodes identified by the set bits in the BitString include but are not limited to intermediate nodes or destination nodes (in some embodiments, the destination node is also called a tail node or a leaf node or BFER). The value of the set bit in the BitString is, for example, 1, and the value of the unset bit in the BitString is, for example, 0. For example, the network contains five nodes, namely node P1, node P2...node P5, and the forwarding path of the message is<P1,P2,P3> The BitString corresponding to the forwarding path is, for example, 00111. In the BitString, the bit corresponding to node P1 (for example, the first bit from the right), the bit corresponding to node P2 (for example, the second bit from the right), and the bit corresponding to node P3 (for example, the third bit from the right) are all set, thereby indicating that the message needs to be forwarded to node P1, node P2, and node P3.

[0071] The BitString in the embodiment of the present application is not only used to identify multiple destination BFERs (i.e., leaf nodes on the forwarding path) of the message in the BIER domain. When the BitString is only used to identify multiple destination BFERs (i.e., leaf nodes on the forwarding path) of the message in the BIER domain, each bit in the BitString corresponds to a BFER. The bits set in the BitString are a set of identifiers of the destination BRER nodes of the message. When the BFIR needs to forward the message to a specified group of BFERs through an intermediate node, the BFIR will set all the bits corresponding to the specified group of BFERs in the BIER option so that the intermediate node can copy and forward according to the setting of the BitString. For example, the BIER domain contains 4 edge nodes, and the identifiers of these 4 edge nodes are, for example, 1, 2, 3, and 4. When the BFIR needs to forward the message to an edge node with a BFR ID of 1 and an edge node with a BFRID of 2, the BFIR can carry a BitString represented by 0011 in the BIER option.

[0072] The bit string in the embodiments of the present application can also be expressed as bitstring, bit string, Bit string, BitString, etc. The embodiments of the present application are not limited to the above-mentioned specific expressions of BitString.

[0073] (6) BIER forwarding router (BFR)

[0074] BFR refers to nodes that support BIER forwarding. BFR includes BFIR, BFER, and transit BFR. BFIR and BFER are collectively referred to as edge nodes in the BIER domain. Transit BFR is an intermediate forwarding node in the BIER domain.

[0075] (7) BIER forwarding router Identifier (BFR-ID)

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

[0077] (8) Bit Index Forwarding Table (BIFT)

[0078] BIFT is a table entry used by each BFR in the BIE domain when forwarding multicast packets. BIFT is used to represent the BFER nodes that can be reached through the BFR neighbor, including the BFR neighbor (Nbr) and the forwarding bitmask (FBM).

[0079] (9) BIER tree engineering (BIER-TE)

[0080] Compared with BIER, the main changes of BIER-TE include but are not limited to the following two points.

[0081] First, in BIER, the bits in the bit string in the BIER option indicate a BFER. On the control plane of BIER, the bits in the BIFT are used to determine the next hop to reach the BFER. In BIER-TE, the bits in the bit string in the BIER option indicate an adjacency or a node in the BFER-TE topology. For example, the BFR located upstream in the adjacency fills bits in the local BIFT. On the forwarding plane of BIER-TE, when the BFR receives a data packet, it will search for the filled bits in the BIFT based on the set bits in the bit string in the data packet, and copy the packet based on the adjacency relationship type corresponding to the bits in the BIFT.

[0082] Second, in BIER, each node in the network usually performs distributed path calculation based on the shortest path algorithm, while in BIER-TE, the controller usually calculates an explicit path and sends it to the head node.

[0083] (10) Traffic engineering (TE) policy based on Internet Protocol version 6 for segment routing (SRv6)

[0084] SRv6 TE policy leverages the source routing mechanism of segment routing (SR) to guide packets traversing the network by encapsulating an ordered list of instructions (i.e., a segment list) at the headnode. The SRv6 TE policy workflow can be summarized in five steps: 1. The forwarder (intermediate node or headnode) reports network topology information to the network controller using the Border Gateway Protocol (BGP) link state (BGP-LS) protocol. This topology information includes nodes, links, and TE attributes such as link cost, bandwidth, and latency. 2. Based on this collected topology information, the controller calculates a path based on service requirements to ensure compliance with the service-level agreement (SLA). 3. The controller uses the BGP SR-policy extension to send this path information to the network headnode, which then generates an SRv6 TE policy. This generated SRv6 TE policy includes key information such as the headend address, destination address, and color. 4. The network headend selects an appropriate SRv6 TE Policy for the service to guide forwarding. 5. When forwarding data, the forwarder must execute the instructions of the SID it has issued. SRv6 TE Policy technology, by encapsulating a segment list in the SRH, explicitly directs packets to be forwarded along a planned path. This enables fine-grained end-to-end control of the forwarding path, meeting service SLA requirements such as low latency, high bandwidth, and high reliability. If the service's destination address matches the EndPoint of the SRv6 TEPolicy, and the service's preference (identified by the color extended community attribute of the route) is consistent with the SRv6 TEPolicy, the service traffic can be forwarded using the specified SRv6 TE Policy. SRv6 leverages the programmability of the 128-bit IPv6 address to expand the range of network functions expressed by SRv6 instructions. In addition to instructions for identifying forwarding paths, SRv6 instructions can also identify value-added service devices such as firewalls, application acceleration, or user gateways. SRv6 also boasts powerful extensibility. Supporting a new network function requires only defining a new command, without changing protocol mechanisms or deployment. This significantly shortens the delivery cycle for innovative network services. Therefore, SRv6 TE Policy can meet end-to-end service requirements and is the primary mechanism for implementing SRv6 network programming.

[0085] (11) Segment Routing Header (SRH)

[0086] To implement segment routing based on the IPv6 forwarding plane, a new type of IPv6 routing extension header, called the SRH, was added. This extension header specifies an explicit IPv6 path and stores IPv6 path constraint information (segments list). The head node adds an SRH extension header to the IPv6 packet, and intermediate nodes forward the packet according to the path information contained in the SRH extension header.

[0087] (12)SID

[0088] In SR-MPLS, the SID is usually a 20-bit MPLS label. SID types include prefix segments used to identify the destination address prefix, adjacency segments used to identify adjacencies, and node segments used to identify nodes.

[0089] In SRv6, a SID is typically a 128-bit IPv6 address. An SRv6 SID consists of two main parts: a locator and a function. The function part can also contain an optional parameter segment (arguments). The locator performs a positioning function. After a node is configured with a locator, the system generates a locator network segment route and propagates it within the SRv6 domain via the IGP. Other nodes in the network can locate this node using the locator network segment route. Furthermore, all SRv6 SIDs advertised by this node can also be reached using this locator network segment route. A function represents a device instruction, which is pre-set by the device. The function part instructs the node generating the SRv6 SID to perform the corresponding functional operation. The function is explicitly represented by the Operation Code (Opcode). Both the function and arguments are definable, which reflects the SRv6 SID structure's ease of network programming.

[0090] SRv6 SIDs primarily include End SIDs and End.X SIDs. End SIDs represent endpoint SIDs and are used to identify a destination node in the network. For example, by configuring a locator on each node and then configuring a function Opcode for the node, the combination of the locator and the function Opcode yields a SID that represents the node itself, called the End SID. End.X SIDs represent the endpoint SIDs of a Layer 3 cross-connect and are used to identify a link in the network. For example, by configuring a locator on a node and then configuring a function Opcode for each adjacency in each direction, the combination of the locator and the function Opcode yields a SID that represents an adjacency. End.X SIDs represent the endpoint SIDs of a Layer 3 cross-connect and are used to identify a link in the network. End SIDs and End.X SIDs represent nodes and adjacencies, respectively, and are both path SIDs. Combining the two to create a SID stack is sufficient to represent any network path. The SID stack represents the path constraints and is carried in the IPv6 SRH. SRv6 implements Traffic Engineering (TE) in this way.

[0091] (13) OR operation (also called OR operation)

[0092] Performing an OR operation on multiple bit strings means that, for the same bit, if the value of that bit in any of the multiple bit strings is 1, the value of that bit in the result of the OR operation is 1; if the value of that bit in all of the multiple bit strings is 0, the value of that bit in the result of the OR operation is 0. For example, if bit string 1 is 0001 and bit string 2 is 1000, the result of the OR operation on bit strings 1 and 2 is 1001.

[0093] SRv6 is a protocol designed based on source routing for forwarding IPv6 datagrams on networks. Based on IPv6 forwarding technology, SRv6 extends the IPv6 extension header to implement label-based forwarding. SRv6 defines some IPv6 addresses as instantiated SRv6 SIDs. Each SRv6 SID has its own distinct role and function. By combining different SRv6 SIDs, simplified virtual private networks (VPNs) and flexible path planning can be implemented.

[0094] An SRv6 SID consists of two main parts: a locator field and a function field. The locator occupies the high-order bits of the SRv6 SID, while the function field occupies the remainder. Optionally, an SRv6 SID also includes an arguments (arg) field. An SRv6 SID is optionally represented as locator:function:arguments, where locator can also be represented as B:N. B represents the IPv6 subnet assigned by the carrier to the SRv6 SID, and N is the identifier of the parent node that instantiated the SID. Therefore, an SRv6 SID can also be represented as B:N:function:arguments. After a node is configured with a locator, the system generates a locator network segment route and propagates it within the SR domain via an interior gateway protocol (IGP) or BGP. Because the locator portion of the SRv6 SID assigned to this node is the same, all other nodes can find the configured SRv6 SID through the locator route. The function part is used to instruct the node generating the SRv6 SID to perform the corresponding functional operation. The arguments field can define some message flow and service information.

[0095] Stateless SRv6 P2MP is proposed in the draft "draft-chen-pim-srv6-p2mp-path". Stateless SRv6 P2MP means that for an SR P2MP path from an ingress node to multiple egress nodes, a segment list is used to represent the SRP2MP path. Data packets are forwarded to multiple egress nodes based on the segment list encapsulated at the ingress node, and there is usually no state in the network core. Figure 1 This article uses an example to illustrate the stateless SRv6 P2MP solution. Figure 1 The middle node R is the entry node, nodes L1, L2, L3, and L4 are egress nodes (i.e., leaf nodes), and nodes P1, P2, P3, and P4 are forwarding nodes (i.e., intermediate nodes) in the P2MP path. The draft defines a new SID, called multicast SID. In an SR domain that supports SR multicast, each node has a multicast node SID; each node's adjacency has a multicast adjacency SID. It is represented by a segment list. Figure 1Medium P2MP path<P1,P2,P3,L1,L2,P4,L3,L4> In a multicast SID, a parameter N-branches indicates the number of child nodes under the current node, and another parameter N-SIDs indicates the number of SIDs under the current node. The encoded segment list is shown in Table 1 below.

[0096] Table 1

[0097]

[0098] The encoding of the segment list is done according to the level of the P2MP tree. Figure 1 For example, Figure 1 The P2MP path shown can be viewed as a tree with node P1 as its root. Node P1 belongs to the first level of the tree. Node P1's children, nodes P2 and P3, belong to the second level, and so on. The multicast SIDs in the segment list are arranged in order from the first level to the last level.

[0099] When node P1 receives a data packet carrying the aforementioned segment list, it discovers that the first SID in the segment list is the multicast SID advertised by node P1. Node P1 then parses the first SID in the segment list to determine N-branches and N-SIDs. Based on N-branches, node P1 determines that the following SIDs within the first SID in the segment list are the SIDs of node P1's child nodes. Node P1 then copies the data packet and sends it to nodes P2 and P3, respectively. The segment list in the data packet sent to node P2 is shown in Table 2 below.

[0100] Table 2

[0101]

[0102] The segment list of the data message sent to node P3 is shown in Table 3 below.

[0103] Table 3

[0104]

[0105] BIER encapsulates the set of multicast message destination nodes in the form of a BitString in the message header before sending it. This eliminates the need for intermediate network nodes to establish a multicast tree for each multicast stream and maintain multicast stream state. Intermediate nodes only need to copy and forward data packets based on the set of destination nodes corresponding to the BitString carried in the message header. BIER-TE introduces new semantics for bit positions (BPs) to indicate adjacent locations. BPs are used in BIER to indicate BFERs. In BIER-TE, the BIFT of each BFR is typically populated only with BPs adjacent to BFRs in the BIER-TE topology. Table 4 describes the BIER-TE topology and the BIFTs of each BFR. p1…p14 are the used BPs. All BFRs can function as BFIRs, and BFR1, BFR3, BFR4, and BFR6 can also function as BFERs. Forward_connected() represents the adjacency name for the network subnet adjacency, and Local_decap() is the adjacency name for decapsulating BIER-TE packets and passing their payload to higher layers for processing.

[0106] Table 4

[0107]

[0108]

[0109] For example, if a data packet needs to travel from BFR1 to BFR6 via BFR4, the data packet must carry the bit string corresponding to (p2, p8, p10, p12, p15). When the data packet carrying the bit string (p2, p8, p10, p12, p15) is forwarded to BFR1, BFR1 searches BFR1's BIFT based on the bit string in the data packet and forwards it. As shown in Table 4, the correspondence between bits and actions indicates that because bit p2 in the bit string is set, BFR1 sends the packet to BFR2. BFR2 then searches its local BIFT for forwarding. The packet is then forwarded from BFR2 to BFR4, then to BFR5, and finally to BFR6. Finally, BFR6 receives and decapsulates the data packet based on p15.

[0110] When a message needs to be sent not only to BFR4 but also to BFR3, the message carries the BitString corresponding to (p2, p5, p8, p10, p12, p13, p15). The method for obtaining the BitString corresponding to (p2, p5, p8, p10, p12, p13, p15) can be found in the BitString introduction above and will not be repeated here. When BFR2 receives the message carrying this BitString, since bits p5 and p8 in the BitString are both set, BFR2 makes a copy of the message and sends it to BFR3 and BFR4.

[0111] Related technologies calculate the P2MP path for multicast services as a whole. Each P2MP path calculation is based on the destination leaf node and the service SLA. This means that P2MP path calculation is not incremental and does not reuse existing results.

[0112] For example, combined with Figure 5 In the scenario shown, for example, there is a multicast stream 1 that needs to be sent to Figure 5 When calculating the P2MP path of multicast stream 1, the related technology will calculate P2MP path 1 based on the leaf nodes (N1 and N2) and the service level agreement (SLA) requirements (SLA1) of the service of multicast stream 1; there is also a multicast stream 2, which needs to be sent to Figure 5 Nodes N2 and N3 in the network. When calculating the P2MP path for multicast stream 2, the related technology calculates P2MP path 2 based on the leaf nodes (N2 and N3) and the SLA requirement (SLA2) of the service for multicast stream 2. There is also a multicast stream 3, which needs to be sent to nodes N2 and N3. When calculating the P2MP path for multicast stream 3, the related technology calculates P2MP path 3 based on the leaf nodes (N2 & N3) and the SLA requirement (SLA3) of the service for multicast stream 3. In addition, if multicast stream 3 needs to be sent not only to nodes N2 and N3, but also to node N1, the related technology recalculates P2MP path 3 based on the entire network topology.

[0113] However, when this method of calculating the P2MP path as a whole is used, since the P2MP path is calculated as a whole, every time a leaf node dynamically joins or leaves, or a link in the original path changes, the entire P2MP path needs to be recalculated, which is too expensive. Figure 5From this perspective, when multicast stream 3 needs to be sent to node N1 in addition to node N2 and node N3, there is actually no need to recalculate the entire P2MP path. Instead, it is only necessary to calculate the P2P path from node R1 to node N1 and then combine it with the original P2MP path to calculate a P2MP path to node N2, node N3 and node N1. In addition, when Figure 5 When a failure occurs in the path from node R3 to node N3, the above method needs to recalculate the P2MP paths of multicast streams 2 and 3, which results in a large amount of calculation.

[0114] In view of this, this embodiment provides a method for determining a P2MP path. This method is equivalent to converting the P2MP path calculation process into a process of splitting an existing P2MP path into multiple P2P paths and then recombining the P2P paths according to specific scenarios. This eliminates the need to recalculate the entire P2MP path each time a path is calculated. This reduces the amount of computation required to determine the P2MP path, saves calculation overhead, and facilitates efficient and rapid P2MP path calculation.

[0115] Figure 6 This is a schematic diagram of the architecture of a network system provided in an embodiment of the present application. Figure 6 The network system shown in the figure includes a multicast source S1, multiple network nodes, and multiple multicast receivers. Figure 6 Each device is described with examples.

[0116] (1) Multicast source S1

[0117] Multicast source S1 is a source device that generates and sends multicast messages. The destination address of the multicast messages sent by multicast source S1 is the IP multicast address of the multicast group. Optionally, multicast source S1 is deployed in a user network. Multicast source S1 is connected to head node R1 via a wired or wireless network. Multicast source S1 includes, but is not limited to, a server or user device. User devices include, but are not limited to, personal computers, mobile phones, laptops, IP phones, cameras, tablet computers, wearable devices, and the like.

[0118] (2) Network nodes

[0119] Network nodes include but are not limited to routers, switches, firewalls, etc. Figure 6 The network nodes shown include the head node R1, intermediate node P1, intermediate node P2, intermediate node P3, intermediate node P4, intermediate node P5, intermediate node P6, intermediate node P7, leaf node L1, leaf node L2, leaf node L3, leaf node L4, leaf node L5, leaf node L6, leaf node L7 and leaf node L8.

[0120] In the multicast forwarding process, the initiator R1 receives multicast messages from the multicast source S1, encapsulates the multicast message with information about the forwarding path or the destination leaf node, and then forwards the message to an intermediate node. Upon receiving the multicast message, the intermediate node forwards it to the designated destination leaf node based on the information encapsulated by the initiator R1.

[0121] For example, when using BIER technology to forward multicast messages, the first node R1 acts as a BFIR, encapsulating the multicast message in a BitString. The set bits in the BitString represent each destination node on the forwarding path. Intermediate nodes act as BFRs and forward the message to the next node based on the BitString. Leaf nodes act as BFERs. When they detect that the bit corresponding to their BFR ID in the BitString is set, they query routing information and forward the multicast message to the corresponding multicast receiver.

[0122] For example, when using SRv6 to forward multicast packets, the first node R1 acts as the headend and encapsulates a segment list with the multicast packet. The segment list includes the multicast SID of each node along the forwarding path. The intermediate node forwards the packet to the next node based on the SID in the segment list.

[0123] Optionally, Figure 6 The network nodes shown are located in the same routing domain, and the multiple network devices learn each other's routing information based on the routing protocol. The routing domain includes but is not limited to the BIER domain or the SR domain.

[0124] Optionally, the head node R1 and each leaf node are all PE nodes, and each intermediate node is a P node.

[0125] (3) Multicast Receiver

[0126] A multicast receiver is a destination device that receives multicast messages based on an IP multicast address. A multicast receiver can join a multicast group, becoming a member, or leave a multicast group. Multicast receivers include, but are not limited to, servers or user devices. Figure 6 The multicast receivers shown include multicast receiver D1, multicast receiver D2, multicast receiver D3, multicast receiver D4, multicast receiver D5, multicast receiver D6, and multicast receiver D7. Figure 6 Different multicast receivers are distributed in different locations in the network.

[0127] Figure 7 This is a flowchart of a method for determining a forwarding path provided in an embodiment of the present application. Figure 7 The method shown is applied to the root node of the P2MP path. Figure 7The method shown is about how to determine another P2MP path based on a P2MP path. In order to distinguish different P2MP paths, "first P2MP path" and "second P2MP path" are used to distinguish and describe multiple different P2MP paths. Figure 7 In the method shown, different P2MP paths can be optionally used to forward different multicast streams. In order to distinguish different multicast streams, "first multicast stream" and "second multicast stream" are used to distinguish and describe multiple different multicast streams. Figure 7 The network deployment scenario based on the method shown is optionally as described above. Figure 6 For example, combining Figure 6 Come and see, Figure 7 The root node in the method shown is Figure 6 R1 in Figure 7 The first P2MP path in the method shown is Figure 6 The path from R1 to L1, L2, L3...L8, Figure 7 The n leaf nodes in the method shown are Figure 6 The four leaf nodes L1, L2, L3 and L4, Figure 7 In the method shown, n P2P paths are Figure 6 There are four paths: the path from R1 to L1, the path from R1 to L2, the path from R1 to L3, and the path from R1 to L4. Figure 7 The method shown is optionally applied to a BIER-TE network or an SR P2MP network. Figure 6 As shown, Figure 7 In the method shown, the root node and leaf nodes are deployed at the edge of the BIER-TE network or SR P2MP network, where the root node is the entry node of the BIER-TE network or SR P2MP network, and the leaf node is the exit node of the BIER-TE network or SR P2MP network. Figure 7 The method shown includes the following steps S201 to S202.

[0128] Step S201: The root node obtains n P2P paths based on the first P2MP path and n leaf nodes for receiving a first multicast stream.

[0129] Optionally, the first P2MP path is a path that includes all edge nodes in the network, and each edge node in the network is a leaf node on the first P2MP path. For example, in a BIER scenario, the first P2MP path may be a path that includes all BFERs in the BIER domain, and each BFER in the BIER domain is a leaf node on the first P2MP path. For another example, in an IP backbone network, the first P2MP path may be a path that includes all PEs in the IP backbone network.

[0130] Optionally, the first P2MP path is a pre-established path. The root node stores information representing the first P2MP path. When determining the forwarding path for the first multicast stream, the root node obtains the first P2MP path based on the stored information. The establishment of the first P2MP path can occur in a variety of scenarios. For example, a controller may perform path calculation to obtain the first P2MP path, which the controller then sends to the root node, which then receives the first P2MP path from the controller. Alternatively, a network administrator may statically configure the first P2MP path on the root node. Alternatively, the root node may perform path calculation to obtain the first P2MP path.

[0131] Optionally, the first P2MP path is a path established based on a preset SLA requirement and m preset leaf nodes. m is the number of leaf nodes included in the first P2MP path, and m is a positive integer greater than or equal to n. Optionally, m is greater than or equal to 3.

[0132] Pre-set SLA requirements include, but are not limited to, latency below a threshold, packet loss rate below a threshold, and bandwidth above a threshold. Optionally, a network administrator can pre-configure SLA requirements using static configuration. Optionally, pre-set SLA requirements are color-coded. For example, color 123 indicates an SLA requirement for latency below a threshold, and color 456 indicates an SLA requirement for bandwidth above a threshold.

[0133] There are many ways to obtain m leaf nodes. For example, a network administrator pre-configures m leaf nodes using static configuration. For another example, each of the m leaf nodes sends its own node identifier to a controller or a root node, and the controller or the root node receives the node identifier sent by each of the m leaf nodes, thereby determining the m leaf nodes. In one possible implementation, each of the m leaf nodes reports its own node identifier to the controller based on the BGP protocol, so that the controller obtains m leaf nodes and calculates the above-mentioned first P2MP path. The identifier of the leaf node includes but is not limited to the SID of the leaf node (such as a multicast SID) or the BFR ID of the leaf node.

[0134] The n leaf nodes are target receivers of the first multicast stream. n represents the number of leaf nodes of the first multicast stream.

[0135] There are various scenarios for leaf nodes. In one possible implementation, each of the n leaf nodes is a routing device, connected to one or more destination hosts of the first multicast stream, and configured to forward the received first multicast stream to the destination hosts to which it is connected. In another possible implementation, each of the n leaf nodes is a destination host of the first multicast stream.

[0136] The n leaf nodes mentioned above belong to the m leaf nodes in the first P2MP path. The n leaf nodes can be part or all of the m leaf nodes. For example, the leaf nodes of the first P2MP path include seven BFERs: BFER 1, BFER 2, BFER 3, ..., BFER 7, where m is 7. The leaf nodes of the first multicast stream include three BFERs: BFER 1, BFER 2, and BFER 3, where n is 3.

[0137] There are multiple implementations for how the root node determines the n leaf nodes mentioned above. In one possible implementation, the root node determines the n leaf nodes for receiving the first multicast stream based on a received multicast join message or multicast exit message. Specifically, when a network device wants to receive the first multicast stream, the network device sends a multicast join message for the first multicast stream to the root node. After the root node receives the multicast join message, the root node determines the network device as a leaf node of the first multicast stream based on the multicast join message. When a network device wants to stop receiving the first multicast stream, the network device sends a multicast exit message for the first multicast stream to the root node. After the root node receives the multicast exit message, the root node deletes the network device from the leaf nodes of the first multicast stream based on the multicast exit message.

[0138] Any of the n P2P paths is used to forward the first multicast stream to a corresponding leaf node among the n leaf nodes. Optionally, the tail node (also called an egress node or terminating node) of any of the n P2P paths is a leaf node for receiving the first multicast stream. The head node (also called an ingress node, head node, or starting node) of each of the n P2P paths is the root node of the first P2MP path.

[0139] Each of the n P2P paths is a path included in the first P2MP path. For any P2P path among the n P2P paths, all nodes on the P2P path are nodes on the first P2MP path, and all links on the P2P path are links on the first P2MP path.

[0140] In some embodiments, the specific process of obtaining n P2P paths includes: the root node obtains m P2P paths split from the first P2MP path, and the root node selects n P2P paths from the m P2P paths based on n leaf nodes receiving the first multicast stream.

[0141] In some embodiments, the m P2P paths are obtained by splitting the first P2MP path based on leaf nodes. Specifically, the path from the root node to a leaf node in the first P2MP path is divided into a P2P path, resulting in m P2P paths. The first node of any P2P path among the m P2P paths is the root node of the first P2MP path. The last node of any P2P path among the m P2P paths is a leaf node of the first P2MP path.

[0142] The entity responsible for splitting the first P2MP path can be implemented in various scenarios. In some embodiments, a controller splits the first P2MP path to obtain m P2P paths. The controller sends the m P2P paths to the root node, which receives the m P2P paths from the controller. In other embodiments, the root node splits the first P2MP path to obtain m P2P paths.

[0143] In some embodiments, the process of selecting n P2P paths from m P2P paths specifically includes: for each P2P path among the m P2P paths, the root node determines whether a leaf node of the P2P path is a leaf node for receiving the first multicast stream; if the leaf node of the P2P path is a leaf node for receiving the first multicast stream, selecting the P2P path to obtain the second P2MP path.

[0144] Step S202: The root node obtains a second P2MP path based on the n P2P paths.

[0145] The second P2MP path is a forwarding path for the first multicast stream and is used to forward the first multicast stream from the root node to the n leaf nodes.

[0146] The second P2MP path includes the n P2P paths. Optionally, the root node of the second P2MP path is the same as the head node of any one of the n P2P paths. Optionally, the leaf nodes of the second P2MP path include the leaf nodes of each of the n P2P paths. Optionally, the nodes on the second P2MP path include all nodes and all links on each of the n P2P paths.

[0147] The second P2MP path is a path included in the first P2MP path. In some embodiments, the root node of the second P2MP path is the same as the root node of the first P2MP path. The leaf nodes of the second P2MP path are some or all of the leaf nodes of the first P2MP path. Optionally, the second P2MP path is a subtree of the first P2MP path.

[0148] The method provided in this embodiment treats an existing P2MP path as a combination of multiple P2P paths. Based on the P2P paths corresponding to the leaf nodes of the specific multicast stream, the P2MP path for the specific multicast stream is determined without recalculating the entire P2MP path. This reduces the computational effort required to determine the P2MP path, saves calculation overhead, and facilitates efficient and rapid P2MP path calculation.

[0149] Optionally, after obtaining the second P2MP path, the root node forwards the first multicast stream to n leaf nodes via the second P2MP path. In an exemplary embodiment, the root node creates a correspondence between the multicast source of the first multicast stream, the multicast group of the first multicast stream, and the second P2MP path, and the root node saves the correspondence in the root node's forwarding table. When the root node receives a multicast message for the first multicast stream, the root node queries the forwarding table for the correspondence based on the multicast source and multicast group of the multicast message to obtain the second P2MP path. The root node forwards the message via the second P2MP path. For example, in a BIER-TE scenario, the root node encapsulates the BitString of the second P2MP path into the multicast message and then forwards the multicast message carrying the BitString to an intermediate node. The intermediate node forwards the multicast message based on the BitString carried by the multicast message, so that the multicast message is forwarded along the second P2MP path. For example, in an SR-P2MP scenario, the root node encapsulates the segment list of the second P2MP path into a multicast message and then forwards the multicast message carrying the segment list to an intermediate node. The intermediate node then forwards the multicast message based on the segment list carried in the multicast message, ensuring that the multicast message is forwarded along the second P2MP path.

[0150] The method provided in this embodiment supports efficient calculation of P2MP paths in various scenarios. Some application scenarios are described below with examples.

[0151] Scenario 1: The leaf node of the multicast stream is updated.

[0152] When a member joins or leaves the multicast group corresponding to a multicast stream, the leaf nodes on the P2MP path are updated. Using the method provided in this embodiment, the root node can reuse the original P2MP path to calculate the updated P2MP path for the leaf nodes without having to recalculate the entire P2MP path.

[0153] For example, combining the above Figure 7 According to the method shown, Figure 7 In the illustrated method, the first P2MP path is the path before the leaf nodes of the first multicast stream are updated, and the second P2MP path is the path after the leaf nodes of the first multicast stream are updated. n refers to the number of leaf nodes after the update.

[0154] For example, the root node executes Figure 7 The method shown. Figure 7 In the method shown, the first P2MP path is the path before the multicast joins the multicast group corresponding to the first multicast stream. The second P2MP path is the path after the multicast joins the multicast group corresponding to the first multicast stream, and n refers to the number of leaf nodes after the multicast joins. For example, after the first P2MP path has been established for the first multicast stream with m leaf nodes, a member joins the multicast group corresponding to the first multicast stream. The m leaf nodes become n leaf nodes due to the addition of new leaf nodes. The n leaf nodes include the original m leaf nodes and the newly added leaf nodes. Among them, n is greater than m, and the difference between n and m is the number of newly added leaf nodes. In this case, the root node executes Figure 7 The method shown thereby calculates a new P2MP path (the second P2MP path) for the first multicast flow having n leaf nodes.

[0155] For example, the root node executes Figure 7 The method shown, Figure 7 In the method shown, the first P2MP path is the path before the multicast exits in the multicast group corresponding to the first multicast stream. The second P2MP path is the path after the multicast exits in the multicast group corresponding to the first multicast stream, and n refers to the number of leaf nodes after the multicast exits. For example, after the first P2MP path has been established for the first multicast stream with m leaf nodes, a member exits the multicast group corresponding to the first multicast stream, and the m leaf nodes become n leaf nodes due to the exit of some leaf nodes. The n leaf nodes are the leaf nodes excluding the exited leaf nodes among the m leaf nodes. Among them, m is greater than n, and the difference between m and n is the number of exited leaf nodes. In this case, the root node executes Figure 7 The method shown thereby calculates a new P2MP path (the second P2MP path) for the first multicast flow having n leaf nodes.

[0156] To summarize the method flow for scenario 1, when a leaf node on a P2MP path is updated, a new P2MP path can be generated by utilizing the P2P path corresponding to the updated leaf node and the original path, without having to recalculate the entire P2MP path. This significantly reduces the complexity and overhead of P2MP path calculation, improving its efficiency. Furthermore, it avoids the need to re-issue policies to generate P2MP paths each time a leaf node dynamically joins or leaves, thus avoiding frequent policy issuance and reducing the communication overhead of policy transmission.

[0157] Scenario 2: Multiple multicast streams have the same SLA requirements and share a common leaf node.

[0158] If a P2MP path has been calculated for multicast stream 1, for multicast stream 2, if the SLA requirement of multicast stream 2 is the same as that of multicast stream 1, and multicast stream 2 has common leaf nodes with multicast stream 1, for example, all leaf nodes of multicast stream 2 happen to be leaf nodes of multicast stream 1, or some leaf nodes of multicast stream 2 are leaf nodes of multicast stream 1 while other leaf nodes are not, the root node can use the method provided in this embodiment to reuse the P2MP path of multicast stream 1 to calculate the P2MP path of multicast stream 2 without having to recalculate the entire P2MP path for multicast stream 2. This greatly reduces the complexity of P2MP path calculation, saves P2MP path calculation overhead, and improves the efficiency of P2MP path calculation.

[0159] For example, combining the above Figure 7 According to the method shown, Figure 7 In the illustrated method, the first P2MP path is the forwarding path of the second multicast stream (multicast stream 1 in the example in the previous section). Figure 7 In the illustrated method, n refers to the number of leaf nodes in the first multicast stream (corresponding to multicast stream 2 in the previous example) that have the same SLA requirements as the second multicast stream. The second P2MP path is the forwarding path for the first multicast stream, used to forward the first multicast stream from the root node to n leaf nodes. The SLA requirements for the second multicast stream are the same as those for the first multicast stream.

[0160] Scenario 3: The leaf nodes of the multicast stream are a subset of the preset leaf node set, and the SLA requirement of the multicast stream is the same as the preset SLA requirement.

[0161] Specifically, a set of leaf nodes and an SLA requirement are pre-set, and a P2MP path is pre-established based on the pre-set set of leaf nodes and the pre-set SLA requirement. Subsequently, for any multicast stream that is a subset of the pre-set set of leaf nodes and whose SLA requirement matches the pre-set SLA requirement, the method provided in this embodiment allows the pre-established P2MP path to be reused without recalculating the entire P2MP path. This significantly reduces the complexity of P2MP path calculation and improves its efficiency.

[0162] Optionally, multiple SLA requirements are pre-set, and a P2MP path is pre-established based on each of the multiple SLA requirements and a preset set of leaf nodes, thereby obtaining multiple P2MP paths. Furthermore, a correspondence is established between the multiple P2MP paths and the multiple SLA requirements. Subsequently, for any multicast stream, based on the SLA requirement of the multicast stream and the pre-established correspondence, the pre-established P2MP path corresponding to the SLA requirement of the multicast stream is obtained. This pre-established P2MP path is then reused to obtain the P2MP path for the multicast stream.

[0163] Scenario 4: Switching to a P2MP path when a P2MP path fails.

[0164] If a link or a node in a P2MP path fails, when the method provided in this embodiment is used to switch the P2MP path, the root node updates the P2P path that passes through the failure point in the P2MP path to obtain an updated P2P path. This eliminates the need to update P2P paths that do not pass through the failure point or recalculate the entire P2MP path. This facilitates rapid path switching, improves system stability, and reduces P2MP path update overhead, thereby increasing P2MP path update efficiency.

[0165] For example, combining the above Figure 7 According to the method shown, Figure 7 In the method shown, a failure of the second P2MP path is taken as an example. For example, a first P2P path included in the second P2MP path fails, and the root node obtains a third P2MP path based on the second P2MP path.

[0166] The first P2P path refers to a P2P path among the n P2P paths. The failure of the first P2P path includes but is not limited to failure of one or more nodes on the first P2P path or failure of one or more links through which the first P2P path passes.

[0167] There are multiple implementations for how the root node determines that the first P2P path has a fault. In one possible implementation, the root node performs a status check on each P2P path in the second P2MP path, and determines that the first P2P path has a fault based on the result of the status check. Optionally, the root node uses a status detection mechanism in unicast technology to perform a status check on the P2P path. For example, the root node uses two-way active measurement protocol (TWAMP), bidirectional forwarding detection (BFD), in-situ flow information telemetry (iFit) based on Internet Protocol data flow, operations, administration, and maintenance (OAM), and other methods in unicast technology to detect the path status from the current node to the tail node of the first P2P path, thereby determining that the first P2P path has a fault. In another possible implementation, the tail node of the first P2P path performs a status check on the first P2P path. When the tail node discovers that a fault occurs on the first P2P path, the tail node sends a notification message to the root node. The root node determines that a fault occurs on the first P2P path according to the notification message from the tail node.

[0168] The third P2MP path refers to the P2MP path after the switch. The third P2MP path includes the backup path of the first P2P path and the P2P paths other than the first P2P path among the n P2P paths. That is, in the third P2MP path, the failed P2P path (the first P2P path) is switched to the backup path, and the remaining P2P paths do not need to be switched.

[0169] In some embodiments, the switched path is obtained by merging the backup path of the P2P path at the fault point with other P2P paths. Taking the process of obtaining the third P2MP path described above as an example, when a first P2P path fails, the root node obtains the backup path of the first P2P path and merges the P2P paths other than the first P2P path among the n P2P paths with the backup path of the first P2P path to obtain the third P2MP path. Specifically, when using the first merging method described above, the root node obtains the BitString of the backup path of the first P2P path and the BitString of the P2P paths other than the first P2P path among the n P2P paths. Based on the BitString of the backup path of the first P2P path and the BitString of the P2P paths other than the first P2P path among the n P2P paths, the root node obtains the BitString corresponding to the third P2MP path. The BitString corresponding to the third P2MP path is the result of an OR operation between the BitString of the backup path of the first P2P path and the BitString of the P2P paths other than the first P2P path among the n P2P paths. When the second merging method is used, the root node obtains the segment list of the backup path of the first P2P path and the segment list of P2P paths other than the first P2P path among the n P2P paths; based on the segment list of the backup path of the first P2P path and the segment list of P2P paths other than the first P2P path among the n P2P paths, the root node obtains the segment list corresponding to the third P2MP path, where the segment list corresponding to the third P2MP path includes the SID in the segment list of the backup path of the first P2P path and the SID in the segment list of P2P paths other than the first P2P path among the n P2P paths.

[0170] In some embodiments, the root node obtains a backup path for the first P2P path based on a multicast policy. In one possible implementation, for each of the n P2P paths, the multicast policy includes not only the primary path of the P2P path but also the backup path of the P2P path. For example, the multicast policy includes weights for the P2P paths, where the weight of the P2P path serving as the primary path is higher than the weight of the P2P path serving as the backup path. When the first P2P path fails, the root node selects the P2P path with the next highest weight from the multicast policy to obtain the backup path for the first P2P path.

[0171] In some embodiments, the multicast policy includes a BitString or segment list corresponding to a backup path of each of the n P2P paths. The root node obtains the BitString or segment list corresponding to the backup path of the first P2P path from the multicast policy, and then merges the paths based on the BitString or segment list.

[0172] The following combination Figure 8 The network topology shown illustrates a method for switching P2MP paths.

[0173] like Figure 8 As shown in the figure, when the link between the intermediate node P2 and the intermediate node P4 fails, the P2P path from the root node R1 to the leaf node L1 and the P2P path from the root node R1 to the leaf node L2 are affected. In this case, the root node will connect the paths corresponding to the leaf nodes L1 and L2.<P1,P2,P4,L1,L2> Switch to path<P1’,P2’,P4’,L1,L2> There is no need to switch the P2P path corresponding to the leaf node L3, the P2P path corresponding to the leaf node L4, and the P2P path corresponding to the leaf node L5, thereby improving the stability of the system.

[0174] To summarize the method flow in Scenario 4, when a node or link in the P2MP path fails, the P2P path passing through the failure point is updated to obtain the updated P2P path. This achieves granular protection for the P2P path, allowing the entire P2MP path status to be monitored using existing unicast technology. Furthermore, since the pre-failure path can be reused when a P2MP path fails, eliminating the need to recalculate the entire P2MP path, this avoids the need to re-issue policies to generate the P2MP path each time a failure occurs. This reduces the frequent policy issuance, saves communication overhead for policy transmission, and reduces the processing overhead for calculating the P2MP path.

[0175] In one possible implementation, the root node merges n P2P paths to obtain a second P2MP path. In other words, the second P2MP path is the path formed by merging n P2P paths. There are multiple implementations for merging n P2P paths. Two merging methods are described below. In any of the above scenarios 1 through 4, either of the two merging methods described below can be used.

[0176] Merging method 1: The root node merges n P2P paths based on their BitStrings.

[0177] Merging method 1 is applied in the BIER-TE network. For example, the root node of the first P2MP path is the BFIR in the BIER-TE network, and the P2P path is, for example, the path from the BFIR to a BFER in the BIER-TE network. The n P2P paths correspond to n BFERs in the BIER-TE network, and the n BFERs are, for example, n network devices that support BIER forwarding.

[0178] In a BIER-TE network, paths are represented by BitStrings. When merging n P2P paths, the root node obtains the BitString corresponding to each of the n P2P paths. Based on the BitString corresponding to each of the n P2P paths, the root node obtains the BitString corresponding to the second P2MP path. The second P2MP path is the path from the BFIR to the n BFERs.

[0179] The BitString corresponding to the P2P path includes at least one set bit. Each set bit of the BitString represents a destination node of the P2P path, an intermediate node in the P2P path, or an adjacency relationship between two adjacent nodes in the P2P path. The set bit corresponds to the BFR ID of the current node or the ID of the outbound interface on the current node. Optionally, the adjacency relationship identified by the set bit is a unidirectional adjacency relationship, that is, an adjacency relationship from the current node to the next-hop node. N P2P paths correspond to n BitStrings. Optionally, the length of the BitString of each P2P path in the n P2P paths is the same.

[0180] There are multiple implementation methods for obtaining the BitString corresponding to each of the n P2P paths. In some embodiments, a controller sends a multicast policy to a root node, the multicast policy including the BitString corresponding to each P2P path. The root node receives the multicast policy sent by the controller and obtains the BitString corresponding to each P2P path from the multicast policy. Optionally, the multicast policy includes one or more candidate paths, each corresponding to a P2MP path, and each candidate path including one or more BitStrings. The root node first obtains the candidate path corresponding to the first P2MP path from the multicast policy, and then obtains the BitString corresponding to each of the n P2P paths from the candidate path corresponding to the first P2MP path. In other embodiments, the root node obtains the BitString corresponding to each P2P path through static configuration. For example, a network administrator configures a correspondence between the identifier of the first P2MP path and the BitString corresponding to each of the n P2P paths. The root node then obtains the BitString corresponding to each P2P path based on the identifier of the first P2MP path and the pre-configured correspondence.

[0181] The BitString corresponding to the second P2MP path includes multiple set bits, where each set bit of the BitString represents a destination node of the second P2MP path, an intermediate node traversed by the second P2MP path, or an adjacency relationship between two adjacent nodes traversed by the second P2MP path. Optionally, the length of the BitString corresponding to the second P2MP path is the same as the length of the BitString corresponding to each of the n P2P paths.

[0182] The BitString corresponding to the second P2MP path is the result of an OR operation on the BitStrings corresponding to all the P2P paths included in the n P2P paths. For example, the value of the i-th bit in the BitString corresponding to the second P2MP path is the result of an OR operation on the value of the i-th bit in the first BitString, the value of the i-th bit in the second BitString, and so on, and the value of the i-th bit in the n-th BitString.

[0183] Because the BitString corresponding to the second P2MP path is obtained through an OR operation, the BitString corresponding to the second P2MP path retains the set bits in all the BitStrings of the n P2P paths. For example, if the i-th bit in the BitString of the j-th P2P path is set, then the i-th bit in the BitString corresponding to the second P2MP path is also set. Because the set bits identify the nodes or links that the P2P path passes through, this merging method ensures that the merged P2MP path contains all the nodes or links on the n P2P paths before the merge.

[0184] The following combination Figure 9 The BIER-TE network shown here is used Figure 7 The method shown is used to calculate the P2MP path as an example.

[0185] Figure 9 This is an architecture diagram of a BIER-TE network provided in an embodiment of the present application. The BIER-TE network includes 17 BFRs, namely BFR1, BFR2, BFR3...BFR17.

[0186] like Figure 9As shown in the figure, BFR1 is connected to BFR2 through the network. BFR1 is preconfigured with bit P1. P1 represents the outbound interface on BFR1 connected to BFR2 and is used to identify the adjacency between BFR1 and BFR2. BFR1's BIFT stores the correspondence between P1 and the packets forwarded to adjacent BFR2.

[0187] BFR2 is connected to BFR1, BFR3, and BFR6 through the network. Bits P2, P3, and P4 are preconfigured on BFR2. P2 represents the outbound interface on BFR2 connected to BFR1 and is used to identify the adjacency between BFR2 and BFR1. P3 represents the outbound interface on BFR2 connected to BFR3 and is used to identify the adjacency between BFR2 and BFR3. P4 represents the outbound interface on BFR2 connected to BFR6 and is used to identify the adjacency between BFR2 and BFR6. BFR2's BIFT stores the correspondence between P2 and forwarding to adjacent BFR1, P3 and forwarding to adjacent BFR3, and P4 and forwarding to adjacent BFR6.

[0188] BFR3 is connected to BFR2, BFR4, and BFR9 through the network. Bits P5, P6, and P12 are preconfigured on BFR3. P5 represents the outbound interface on BFR3 connected to BFR2 and is used to identify the adjacency between BFR3 and BFR2. P6 represents the outbound interface on BFR3 connected to BFR4 and is used to identify the adjacency between BFR3 and BFR4. P12 represents the outbound interface on BFR3 connected to BFR9 and is used to identify the adjacency between BFR3 and BFR9.

[0189] BFR4 is connected to BFR3, BFR10, and BFR11 through the network. Bits P7, P8, and P10 are preconfigured on BFR4. P7 indicates the outbound interface on BFR4 connected to BFR3 and is used to identify the adjacency between BFR4 and BFR3. P8 is the outbound interface on BFR4 connected to BFR10 and is used to identify the adjacency between BFR4 and BFR10. P10 indicates the outbound interface on BFR4 connected to BFR11 and is used to identify the adjacency between BFR4 and BFR11.

[0190] BFR9 is connected to BFR3, BFR12, and BFR13 through the network. Bits P13 and P14 are preconfigured on BFR9. P13 indicates the outbound interface on BFR9 connected to BFR3 and is used to identify the adjacency between BFR9 and BFR3. P14 is the outbound interface on BFR9 connected to BFR12 and is used to identify the adjacency between BFR9 and BFR12.

[0191] BFR6 is connected to BFR2, BFR7, and BFR8 through the network. Bits P15, P18, and P24 are preconfigured on BFR6. P15 indicates the outbound interface on BFR6 connected to BFR2 and is used to identify the adjacency between BFR6 and BFR2. P18 indicates the outbound interface on BFR6 connected to BFR7 and is used to identify the adjacency between BFR6 and BFR7. P24 indicates the outbound interface on BFR6 connected to BFR8 and is used to identify the adjacency between BFR6 and BFR8.

[0192] BFR7 is connected to BFR6, BFR14, and BFR15 through the network. Bits P19, P20, and P22 are preconfigured on BFR7. P19 indicates the outbound interface on BFR7 connected to BFR6 and is used to identify the adjacency between BFR7 and BFR6. P20 indicates the outbound interface on BFR7 connected to BFR14 and is used to identify the adjacency between BFR7 and BFR14. P22 indicates the outbound interface on BFR7 connected to BFR15 and is used to identify the adjacency between BFR7 and BFR15.

[0193] BFR8 is connected to BFR16 and BFR17 through the network. Bits P25, P26, and P28 are preconfigured on BFR8. P25 indicates the outbound interface on BFR8 connected to BFR6 and is used to identify the adjacency between BFR8 and BFR6. P26 indicates the outbound interface on BFR8 connected to BFR16 and is used to identify the adjacency between BFR8 and BFR16. P28 indicates the outbound interface on BFR8 connected to BFR17 and is used to identify the adjacency between BFR8 and BFR17.

[0194] BFR10 is connected to BFR4 through the network. Bits P9 and P30 are configured on BFR10. P9 represents the outbound interface on BFR10 connected to BFR4 and identifies the adjacency between BFR10 and BFR4. P30 represents the local node (BFR10). BFR10's BIFT stores the correspondence between P9 and forwarding to adjacent BFR4, and between P30 and locally decapsulated packets.

[0195] BFR11 is connected to BFR4 through the network. Bits P11 and P31 are configured on BFR11. P11 indicates the outbound interface on BFR11 connected to BFR4 and identifies the adjacency between BFR11 and BFR4. P31 represents the local node (BFR11). BFR11's BIFT stores the correspondence between P11 and packets forwarded to adjacent BFR4, and between P31 and locally decapsulated packets.

[0196] BFR12 is connected to BFR9 via the network. Bits P16 and P32 are configured on BFR12. P16 indicates the outbound interface on BFR12 connected to BFR9 and identifies the adjacency between BFR12 and BFR9. P32 indicates the local node (BFR12). BFR12's BIFT stores the correspondence between P16 and packets forwarded to the adjacent BFR9, and between P32 and locally decapsulated packets.

[0197] BFR13 is connected to BFR9 via the network. Bits P17 and P33 are configured on BFR13. P17 indicates the outbound interface on BFR13 connected to BFR9 and identifies the adjacency between BFR13 and BFR9. P33 indicates the local node (BFR13). BFR13's BIFT stores the correspondence between P17 and packets forwarded to the adjacent BFR9, and between P33 and locally decapsulated packets.

[0198] BFR14 is connected to BFR7 via the network. Bits P21 and P34 are configured on BFR14. P21 indicates the outbound interface on BFR14 connected to BFR7 and identifies the adjacency between BFR14 and BFR7. P34 represents the local node (BFR14). BFR14's BIFT stores the correspondence between P21 and packets forwarded to the adjacent BFR7, and between P34 and locally decapsulated packets.

[0199] BFR15 is connected to BFR7 through the network. Bits P23 and P35 are configured on BFR15. P23 indicates the outbound interface on BFR15 connected to BFR7 and identifies the adjacency between BFR15 and BFR7. P35 represents the local node (BFR15). BFR15's BIFT stores the correspondence between P23 and packets forwarded to the adjacent BFR7, and between P35 and locally decapsulated packets.

[0200] BFR16 is connected to BFR8 via the network. Bits P27 and P36 are configured on BFR16. P27 indicates the outbound interface on BFR16 connected to BFR8 and identifies the adjacency between BFR16 and BFR8. P36 represents the local node (BFR16). BFR16's BIFT stores the correspondence between P27 and packets forwarded to adjacent BFR8, and between P36 and locally decapsulated packets.

[0201] BFR17 is connected to BFR8 through the network. Bits P29 and P37 are configured on BFR17. P29 indicates the outbound interface on BFR17 connected to BFR8 and identifies the adjacency between BFR17 and BFR8. P37 represents the local node (BFR17). BFR17's BIFT stores the correspondence between P29 and packets forwarded to adjacent BFR8, and between P37 and locally decapsulated packets.

[0202] In topology such as Figure 9 In the BIER-TE network shown, BFR1 is the root node (head node / ingress node), and BFR10, BFR11, BFR12, BFR13, BFR14, BFR15, BFR16, and BFR17 are the preset leaf node sets. The SLA requirement is represented by color1, for example. The P2MP path calculated by the controller based on color1 and the leaf node set is<P2,P5,P7,P9,P11,P13,P16,P17,P15,P19,P21,P23,P25,P27,P29,P30,P31,P32,P33,P34,P35,P36,P37> .

[0203] The controller splits the P2MP path into multiple P2P paths according to the leaf nodes. The multiple P2P paths obtained by splitting are shown in Table 5 below.

[0204] Table 5

[0205]

[0206]

[0207] Among them, P30, P31, P32... to P37 represent nodes, corresponding to the BFR-ID of BFER in BIER. For example, the role of P30 is equivalent to the BFR ID of BFR10. When the bit corresponding to P30 in the BitString is in position, it indicates that the destination nodes of the message include BFR10. P1, P2... to P29 represent a specified output interface on this node, which is equivalent to the identifier of the adjacency relationship between the two BFRs. For example, P3 identifies the output interface on BFR2 for connecting to BFR3, corresponding to the adjacency on BFR2 pointing to BFR3. When the bit corresponding to P3 in the BitString is in position, it is used to instruct BFR2 to forward the message to BFR3. For example, there is multicast stream 1. When BFR10, BFR12, BFR13 and BFR15 send join messages to BFR1 in turn, and indicate that they want to receive multicast stream 1 through the join message, the P2MP path change process of multicast stream 1 is as follows: Figure 10 shown.

[0208] When only BFR10 joins at the beginning, the P2MP path is the P2P path from BFR1 to BFR10. Figure 10 As shown, the P2MP path is<P2,P5,P7,P9,P30> , the bits corresponding to nodes P2, P5, P7, P9, and P30 in the BitString carried by the message forwarded through the P2MP path are set. When BFR12 joins, BFR1 performs an OR operation on the BitString of the P2P path corresponding to BFR10 and the BitString of the P2P path corresponding to BFR12, that is, retains the set bits in the BitString. Figure 10 As shown, the P2P path corresponding to BFR10 is<P2,P5,P7,P9,P30> , the P2P path corresponding to BFR12 is<P2,P5,P13,P16,P32> , BFR1 performs an OR operation on the BitStrings corresponding to the two P2P paths and obtains the BitString as<P2,P5,P7,P9,P13,P16,P30,P32> The corresponding BitString path<P2,P5,P7,P9,P13,P16,P30,P32> The P2MP path corresponding to the two leaf nodes BFR10 and BFR12, the bits corresponding to nodes P2, P5, P7, P9, P13, P16, P30 and P32 in the BitString carried by the message forwarded through this path are set to the same bit position, that is,<P2,P5,P7,P9,P13,P16,P30,P32> The bits corresponding to nodes P2, P5, P7, P9, P13, P16, P30, and P32 in the corresponding BitString are set.

[0209] The joining process of BFR13 and BFR15 is similar to that of BFR12. Specifically, when BFR13 joins, BFR1 performs an OR operation on the BitString of the P2MP paths corresponding to BFR10 and BFR12 and the BitString of the P2P path corresponding to BFR13 to obtain the P2MP paths corresponding to the three leaf nodes BFR10, BFR12, and BFR13. Figure 10 As shown, BFR1 pathway<P2,P5,P7,P9,P13,P16,P30,P32> Corresponding BitString and path<P2,P5,P13,P17,P33> Perform OR operation on the corresponding BitString to get the path<P2,P5,P7,P9,P13,P16,P17,P30,P32,P33> The corresponding BitString.

[0210] When BFR15 joins, BFR1 performs an OR operation on the BitString of the P2MP paths corresponding to BFR10, BFR12, and BFR13 and the BitString of the P2P path corresponding to BFR15 to obtain the P2MP paths corresponding to the four leaf nodes BFR10, BFR12, BFR13, and BFR15. Figure 10 As shown, BFR1 pathway<P2,P5,P7,P9,P13,P16,P17,P30,P32,P33> Corresponding BitString and path<P2,P15,P19,P23,P35> Perform OR operation on the corresponding BitString to get the path<P2,P5,P7,P9,P13,P15,P16,P17,P19,P23,P30,P32,P33,P35> The corresponding BitString.

[0211] After BFR10, BFR12, BFR13, and BFR15 are added as leaf nodes for the multicast stream, the BFR-ID list for multicast group (S, G) on BFR1 includes the BFR IDs of BFR10, BFR12, BFR13, and BFR15. If BFR13 sends a quit message to BFR1, BFR1 deletes BFR13 from the BFR-ID list for multicast group (S, G). The updated BFR-ID list includes the BFR IDs of BFR10, BFR12, and BFR15. BFR1 then re-updates the P2MP path.

[0212] Merging method 2: The root node merges n P2P paths based on the segment lists of n P2P paths.

[0213] Merging method 2 is applied in SR-P2MP networks. For example, the root node of the first P2MP path is the head node in the SR-P2MP network. The P2P path is the path from the head node to an end node (or endpoint) in the SR-P2MP network. N P2P paths correspond to n end nodes in the SR-P2MP network. These n end nodes are, for example, n network devices that support SR.

[0214] In an SR-P2MP network, paths are represented by segment lists. When merging n P2P paths, the root node obtains the segment list corresponding to each of the n P2P paths. Based on the segment list corresponding to each of the n P2P paths, the root node obtains the segment list corresponding to the second P2MP path. The second P2MP path is the path from the head node to the n tail nodes.

[0215] The segment list corresponding to the P2P path includes multiple SIDs arranged in order. Each SID in the segment list represents a node or a link that the P2P path passes through. The order of the SIDs in the segment list represents the direction of the P2P path. For example, the SIDs in the segment list are arranged in order from the head node to the tail node, or in order from the tail node to the head node. N P2P paths correspond to n segment lists. Optionally, each SID in the segment list corresponding to the P2P path is a multicast SID. For the specific concept of multicast SID, please refer to the introduction of the terminology concept explanation part (1) in this article.

[0216] Optionally, the segment list corresponding to the P2P path includes the SIDs of all nodes on the P2P path. Alternatively, the segment list corresponding to the P2P path includes the SIDs of some nodes in the P2P path, for example, the segment list does not include the SID of the head node, or the segment list does not include the SIDs of some intermediate nodes.

[0217] There are multiple implementation methods for obtaining a segment list corresponding to each of n P2P paths. In some embodiments, a controller sends a multicast policy to a root node, where the multicast policy includes a segment list corresponding to each of the n P2P paths. The root node receives the multicast policy sent by the controller and obtains a segment list corresponding to each of the n P2P paths from the multicast policy. In other embodiments, the root node obtains a segment list corresponding to each of the n P2P paths through static configuration. For example, a network administrator configures a correspondence between an identifier of a first P2MP path and a segment list corresponding to each of the n P2P paths. The root node then obtains a segment list corresponding to each of the n P2P paths based on the identifier of the first P2MP path and the pre-configured correspondence.

[0218] The segment list corresponding to the second P2MP path is used to represent the second P2MP path.

[0219] Includes multiple SIDs arranged in order. Each SID in the segment list represents a node or a

[0220] Specifically, the segment list corresponding to the second P2MP path includes all P2P path corresponding segments included in the n P2P paths.

[0221] Optionally, each SID in the segment list corresponding to the second P2MP path is a multicast SID.

[0222] In some embodiments, the segment list corresponding to the second P2MP path is encoded according to the hierarchy of the P2MP tree, and the arrangement order of the SIDs in the segment list corresponding to the second P2MP path represents the hierarchy order of the P2MP tree.

[0223] Optionally, the SIDs in the segment list corresponding to the second P2MP path are arranged sequentially from the first level of the P2MP tree (e.g., the root node) to the last level of the P2MP tree (e.g., the n leaf nodes described above). The SIDs of nodes in the next level of the P2MP tree are arranged after the SIDs of nodes in the previous level. For example, the first SID in the segment list corresponding to the second P2MP path is the SID of the root node (the first level node), followed by the SIDs of all child nodes of the root node (the second level nodes), then the SID sequence of the subtree of the first child node of the root node (the third level nodes), then the SID of the subtree of the second child node of the root node (the third level nodes), and so on, until the SID of the subtree of the last child node.

[0224] Alternatively, the segment list corresponding to the second P2MP path is encoded in reverse order, and the SIDs in the segment list corresponding to the second P2MP path are arranged sequentially from the last layer of the P2MP tree (e.g., the n leaf nodes) to the first layer of the P2MP tree (e.g., the root node). The SIDs of nodes in the next layer of the P2MP tree are arranged before the SIDs of nodes in the previous layer.

[0225] For more details on the encoding structure of the segment list corresponding to the second P2MP path, please refer to the description in the terminology explanation section (3) above.

[0226] The following combination Figure 11 The SR P2MP network shown here adopts Figure 7 The method shown is used to calculate the P2MP path as an example.

[0227] Figure 11 This is an architecture diagram of an SR P2MP network provided in an embodiment of the present application. The SR P2MP network includes root node R1, intermediate node P1, intermediate node P2, intermediate node P3, intermediate node P4, intermediate node P5, intermediate node P6, intermediate node P7, leaf nodes L1, leaf node L2, leaf node L3, leaf node L4, leaf node L5, leaf node L6, leaf node L7, and leaf node L8. Root node R1 is connected to intermediate node P1 via the network. Intermediate node P1 is connected to intermediate nodes P2 and P3 via the network. Intermediate node P2 is connected to intermediate nodes P4 and P5 via the network. Intermediate node P3 is connected to intermediate nodes P6 and P7 via the network. Intermediate node P4 is connected to leaf nodes L1 and L2 via the network. Intermediate node P5 is connected to leaf nodes L3 and L4 via the network. Intermediate node P6 is connected to leaf nodes L5 and L6 via the network. The intermediate node P7 is connected to the leaf nodes L7 and L8 through the network.

[0228] In topology such as Figure 11In the SR P2MP network shown in the figure, the controller calculates the P2MP path based on the preset SLA requirements and the preset leaf node set.<P1,P2,P3,P4,P5,L1,L2,L3,L4,P6,P7,L5,L6,L7,L8> The segment list carried in the message forwarded along this P2MP path includes the SID of each of the following nodes: Node P1, Node P2, Node P3, Node P4, Node P5, Node L1, Node L2, Node L3, Node L4, Node P6, Node P7, Node L5, Node L6, Node L7, and Node L8. The controller splits the P2MP path into multiple P2P paths based on the leaf nodes. The resulting multiple P2P paths are shown in Table 6 below.

[0229] Table 6

[0230] P2P path First Node tail node <P1,P2,P4,L1> R1 L1 <P1,P2,P4,L2> R1 L2 <P1,P2,P5,L3> R1 L3 <P1,P2,P5,L4> R1 L4 <P1,P3,P6,L5> R1 L5 <P1,P3,P6,L6> R1 L6 <P1,P3,P7,L7> R1 L7 <P1,P3,P7,L8> R1 L8

[0231] When multicast stream 2 exists, when leaf nodes L1, L2, L5, and L6 send join messages to root node R1 in sequence, the P2MP path change process corresponding to the multicast group of multicast stream 2 is as follows: Figure 12 The process of updating the P2MP path when a leaf node joins an SR P2MP network is consistent with the basic process of updating the P2MP path when a leaf node joins a BIER-TE network, but there are differences in the specific merging algorithms.

[0232] When root node R1 merges two P2P paths based on two segment lists, since the root nodes of the two P2P paths are the same, root node R1 compares the child nodes of the root nodes in the two P2P paths to see if they are the same. If the child nodes of the root nodes in the two P2P paths are the same, root node R1 then compares the child nodes of the child nodes in the two P2P paths to see if they are the same. If the child nodes of the root nodes in the two P2P paths are different, root node R1 adds the current child node and its subtree to the first segment list. A node is, for example, an SR-capable device in an SR P2MP network, and each SID in the segment list represents a node.

[0233] Figure 12 This is a schematic diagram of a merged segment list provided in an embodiment of the present application. Figure 12As shown, the head node R1 has a session with the tail node L1, tail node L2, tail node L5 or tail node L6. The head node R1 stores the P2P path to the tail node L1.<P1,P2,P4,L1> Corresponding segment list, P2P path to the tail node L2<P1,P2,P4,L2> Corresponding segment list and P2P path to the tail node L5<P1,P3,P6,L5> The corresponding segment list and the P2P path to the tail node L6<P1,P3,P6,L6> The corresponding segment list. Figure 12 The corresponding segment list merging process is introduced.

[0234] First, the tail node L1 sends a join message to the head node R1. The forwarding path is<P1,P2,P4,L1> After the tail node L1 joins the multicast, the tail node L2 sends a join message to the head node R1. After the head node R1 receives the join message from the tail node L2, the head node R1<P1,P2,P4,L1> The path corresponding to the tail node L2<P1,P2,P4,L2> The merging process of the segment list or path includes: the head node R1 starts from the second node to find whether the current node exists, and if it exists, it continues to find the next node; if it does not exist, it inserts the current node. For example, the head node R1 starts from the path<P1,P2,P4,L2> Starting from the second node P2, search for the path<P1,P2,P4,L1> Does node P2 exist in the path?<P1,P2,P4,L1> Node P2 is found in the path, then the head node R1 is found in the path<P1,P2,P4,L2> Get the third node P4 and continue to search for the path<P1,P2,P4,L1> Does node P4 exist in the path?<P1,P2,P4,L1> Node P4 is found in the path, then the head node R1 is found in the path<P1,P2,P4,L2> Get the fourth node L2 and continue to search for the path<P1,P2,P4,L1> Is there a node L2 in the path?<P1,P2,P4,L1> If node L2 is not found, go to path<P1,P2,P4,L1> Insert node L2 to get the path<P1,P2,P4,L1,L2> ,path<P1,P2,P4,L1,L2> represents the P2MP path from the head node R1 to the nodes L1 and L2.<P1,P2,P4,L1,L2> The segment list conforms to the hierarchical structure of the P2MP tree. For example, the SIDs of the two nodes (L1 and L2) under P4 are both arranged after the SID of P4.<P1,P2,P4,L1,L2> Afterwards, when receiving the multicast message of multicast stream 2, the head node adds the path<P1,P2,P4,L1,L2> The corresponding segment list enables the multicast message to be forwarded to node L1 and node L2 through the segment list.

[0235] After the tail nodes L1 and L2 join the multicast, the tail node L5 sends a join message to the head node R1. After the head node R1 receives the join message from the tail node L5, the head node R1<P1,P2,P4,L1,L2> The path corresponding to the tail node L5<P1,P3,P6,L5> Merge. The merging process of the segment list or path includes: comparing the second node P3 with the child node under the current P1. If it is found, continue to compare the next layer of nodes; if it is not found, insert the node into P1 as a child node. According to the number of subtrees in the SID of the existing child node P2, skip the subtree of P2 and insert the subtree of P3. Specifically, due to the path<P1,P2,P4,L1,L2> and path<P1,P3,P6,L5> If the root nodes are the same, the comparison starts from the child nodes.<P1,P3,P6,L5> Get the child node P3 of node P1, and the path<P1,P2,P4,L1,L2> The child node of the middle node P1 is P2. Since the current child node P3 does not belong to the path<P1,P2,P4,L1,L2> The head node inserts node P3 into the path.<P1,P2,P4,L1,L2> The specific way to insert node P3 is to add<P1,P2,P4,L1,L2> Node P3 is inserted after the existing child node P2 of node P1, making P3 a child node of node P1.<P1,P3,P6,L5> Get the subtree of node P3<P6,L5> , to the path<P1,P2,P4,L1,L2> Insert subtree<P6,L5> Insert subtree<P6,L5> The specific way is to start from the path<P1,P2,P4,L1,L2> The number of subtrees of the child node P2 is obtained from the N-branches field of the SID of the child node P2 already in the node P1. According to the number of subtrees of the child node P2, the subtree of the child node P2 is skipped and the subtree of the node P3 is added.<P6,L5> Inserted to the back of the entire tree, the merged P2MP path is<P1,P2,P3,P4,L1,L2,P6,L5> .path<P1,P2,P3,P4,L1,L2,P6,L5> The hierarchical coding structure of the P2MP tree is consistent with that of the P2MP tree. For example, P1 is the first-level node in the P2MP tree, P2 and P3 are the second-level nodes in the P2MP tree, P4, L1 and L2 are subtrees of P2 (or nodes under P2), P6, L5 and L6 are subtrees of P3 (or nodes under P3), and the path<P1,P2,P3,P4,L1,L2,P6,L5> The corresponding segment list is, in order from front to back, the SID of P1, the SID of each node in P2 and P3, P4, the SID of each node in L1 and L2, and P6, the SID of each node in L5 and L6.Head node obtains path<P1,P2,P3,P4,L1,L2,P6,L5> Afterwards, when receiving the multicast message of multicast stream 2, the head node adds the path<P1,P2,P3,P4,L1,L2,P6,L5> The corresponding segment list enables the multicast message to be forwarded to the node L1, the node L2 and the node L5 through the segment list.

[0236] After the tail nodes L1, L2, and L5 join the multicast, the tail node L6 sends a join message to the head node R1. After the head node R1 receives the join message from the tail node L6, the head node R1<P1,P2,P3,P4,L1,L2,P6,L5> The path corresponding to the tail node L6<P1,P3,P6,L6> When merging the segment list, due to the path<P1,P3,P6,L6> P1, P3, and P6 are all on the path<P1,P2,P3,P4,L1,L2,P6,L5> Found in, and the path<P1,P3,P6,L6> L6 is not in the path<P1,P2,P3,P4,L1,L2,P6,L5> Found, so L6 is inserted into the path<P1,P2,P3,P4,L1,L2,P6,L5> In the , get the path<P1,P2,P3,P4,L1,L2,P6,L5,L6> .

[0237] In some embodiments, the first P2MP path and / or the n P2P paths are obtained by the root node based on a multicast policy.

[0238] A multicast policy indicates a P2MP path that meets SLA requirements. Optionally, the root node stores one or more multicast policies, each corresponding to an SLA requirement. When determining a P2MP path for a first multicast stream, the root node searches for a multicast policy that matches the SLA requirements of the first multicast stream from among the one or more stored multicast policies. Based on the multicast policies that match the SLA requirements of the first multicast stream, the root node obtains n P2P paths. Optionally, the multicast policy also includes a color that indicates the SLA requirement.

[0239] In some embodiments, the content of the multicast policy includes information about multiple P2P paths, which are obtained by splitting the pre-established P2MP paths. When it is necessary to determine a P2MP path for a multicast stream, the P2P paths in the multicast policy are merged to obtain a P2MP path that includes the receiver of this multicast stream. For example, Figure 7In the illustrated method, the controller splits the first P2MP path to obtain m P2P paths. The controller generates a multicast policy containing information about the m P2P paths and sends it to the root node. After the root node finds the multicast policy based on the SLA requirements of the first multicast stream, it searches for n P2P paths corresponding to n leaf nodes from the m P2P paths in the multicast policy, based on the n leaf nodes receiving the first multicast stream. The root node then merges the n P2P paths to obtain a second P2MP path for forwarding the first multicast stream.

[0240] Optionally, the root node obtains the multicast policy based on a controller-generated policy. Specifically, the controller generates and sends the multicast policy to the root node, and the root node receives the policy from the controller. Alternatively, the root node obtains the multicast policy based on a static configuration. Specifically, the root node obtains the multicast policy based on a configuration operation.

[0241] The structure of the multicast policy is described in detail below.

[0242] The multicast policy includes information about n P2P paths. For example, the multicast policy includes a BitString or a segment list corresponding to each of the n P2P paths.

[0243] For example, for the BIER-TE scenario, for each of the n P2P paths, the multicast strategy includes one or more BitStrings of the P2P path. Optionally, the multicast strategy includes a weight corresponding to each BitString. The weight is used to indicate whether the corresponding BitString plays the primary or backup role. For example, for the P2P path from the head node to the leaf node A, the multicast strategy includes multiple BitStrings of the P2P path and the weight of each BitString. The BitString with the highest weight represents the primary P2P path from the head node to the leaf node A, and the BitString with the second highest weight represents the backup P2P path from the head node to the leaf node A.

[0244] As another example, for the SR-P2MP scenario, for each of the n P2P paths, the multicast policy includes one or more segment lists of the P2P path. Optionally, the multicast policy includes a weight corresponding to each segment list. The weight is used to indicate whether the role of the corresponding segment list is primary or backup. For example, for the P2P path from the head node to the leaf node A, the multicast policy includes multiple segment lists of the P2P path and the weight of each segment list. The segment list with the highest weight represents the primary P2P path from the head node to the leaf node A, and the segment list with the second highest weight represents the backup P2P path from the head node to the leaf node A.

[0245] Optionally, the multicast policy further includes an SLA requirement corresponding to each of the n P2P paths or an SLA requirement corresponding to the first P2MP path.

[0246] Optionally, the multicast policy further includes an identifier of a root node of the first P2MP path or an identifier of a head node of each of the n P2P paths.

[0247] In one possible implementation, the multicast policy includes SLA requirements (represented by color or other data), at least one candidate path, the priority (preference) of each candidate path, at least one BitString (or segment list), and the weight of each BitString (or segment list). Among them, the candidate path with the highest priority is the P2MP path serving as the primary path in the multicast policy, and the candidate path with the second highest priority is the P2MP path serving as the backup path in the multicast policy. Each candidate path includes BitStrings or segment lists for multiple P2P paths. The endpoints corresponding to different BitStrings or segment lists under the same candidate path may be the same or different. Taking BitString as an example, the BitStrings corresponding to different endpoints represent P2P paths from the head node to different leaf nodes. The BitString with the highest weight among the different BitStrings corresponding to the same endpoint is the BitString of the primary P2P path.

[0248] Combine Figure 7 According to the illustrated method, when the multicast policy adopts the above-described structure, the specific process for the root node to obtain n P2P paths includes: based on the SLA requirements of the first multicast stream, the root node searches for a multicast policy whose SLA requirements match the SLA requirements of the first multicast stream from multiple multicast policies stored by the root node. The root node selects the candidate path with the highest priority from the multicast policies that match the SLA requirements of the first multicast stream. Based on the identifier of each leaf node among the n leaf nodes, the root node searches for a path with the same endpoint identifier as the leaf node from the candidate paths with the highest priority, thereby obtaining n P2P paths. The process of searching for a multicast policy, for example, includes using color as an index and matching the color corresponding to the SLA requirement of the first multicast stream with the color in the multicast policy, thereby searching for the multicast policy.

[0249] The following combination Figure 13 An example is given to illustrate the structure of a multicast policy.

[0250] Figure 13 This is a structural diagram of a multicast policy provided in an embodiment of the present application. The definition of a multicast policy is similar to that of a unicast policy. The definition of a unicast policy generally includes three elements: a head end, a color, and an endpoint. Optionally, the definition of a multicast policy also includes three elements: a root node, a color, and an endpoint. The endpoint in the multicast policy is meaningless. For example, the endpoint in the multicast policy is defined as 0.0.0.0 / ::. Alternatively, the definition of a multicast policy includes two elements: a root node and a color.

[0251] Each candidate path in a multicast policy represents a P2MP path. The P2MP paths represented by different candidate paths in a multicast policy have a primary and backup relationship. The candidate path with the highest preference value in the multicast policy is the primary path. Each candidate path contains multiple or one P2P paths. P2P paths can be represented in two ways: bit string and segment list. Compared to the segment list in a unicast policy, a multicast policy contains multiple P2P paths. A P2P path in a multicast policy is a path from the head node to a leaf node. The endpoints of P2P paths in a multicast policy can vary. In one case, two P2P paths have different endpoints, such as paths from the head node to two different leaf nodes. In another case, two P2P paths have the same endpoint, such as one P2P path being the primary path and the other being the backup path. Other candidate paths in a multicast policy can serve as backup paths (P2MP paths) for the primary path.

[0252] use Figure 13 In the multicast policy shown, because multiple P2P paths with the same endpoint exist under a candidate path, when a P2P path fails, the backup path is obtained by selecting the P2P path with the next largest weight from the candidate paths in the current policy, and the original P2P path is switched to the backup path.

[0253] The following combination Figure 14 The illustrated application scenario illustrates how to use this embodiment to implement stateless P2MP forwarding path calculation and control.

[0254] Figure 14 This is a schematic diagram of an application scenario provided in an embodiment of the present application. Figure 14The illustrated application scenario includes a controller, multicast source S1, head node A, intermediate node B, intermediate node C, intermediate node E, leaf node D, leaf node F, multicast receiver 1, and multicast receiver 2. Multicast source S1 is connected to head node A via a network, head node A is connected to intermediate node B via a network, intermediate node B is connected to intermediate nodes C and intermediate nodes E via a network, intermediate node C is connected to leaf nodes D and leaf nodes F via a network, leaf node D is connected to multicast receiver 1 via a network, and leaf node F is connected to multicast receiver 2 via a network.

[0255] Figure 14 The following example uses the BIER-TE scenario as an example. Each of the aforementioned head node A, intermediate node B, intermediate node C, intermediate node E, leaf node D, and leaf node F is a BFR. Leaf nodes D and F are configured with their own BFR IDs. The BFR ID for leaf node D is 2. The BFR ID for leaf node F is 3.

[0256] The controller calculates the P2MP path based on the preset SLA requirements and the preset leaf node set 1. The preset SLA requirements can be configured on the controller. The preset leaf node set can be configured on the controller or on the leaf nodes (such as Figure 14 The leaf nodes D and F in the configuration are reported to the controller by the leaf nodes through the BGP-LS protocol. Figure 14 As shown, leaf node D reports its BFR ID (i.e., 2) to the controller via the BGP-LS protocol, and leaf node F reports its BFR ID (i.e., 3) to the controller via the BGP-LS protocol. The controller receives the BFR ID of leaf node D and the BFR ID of leaf node F from leaf node D and leaf node F, respectively. Based on the BFR ID of leaf node D and the BFR ID of leaf node F, the controller determines that the preset leaf node set includes leaf node D and leaf node F.

[0257] The controller sends the calculated P2MP path to the head node (such as Figure 14 The controller can send the P2MP path through BGP or PECP. Alternatively, the P2MP path information can be directly configured on the head node. The controller splits the calculated P2MP path into multiple P2P paths from the head node to the leaf nodes, such as Figure 14The P2P path from headnode A to leaf node D and the P2P path from headnode A to leaf node F are shown in Figure 1. Furthermore, the headnode can statically configure the mapping between multicast groups and SLA requirements. Alternatively, the controller can send the mapping between multicast groups and SLA requirements to the headnode. Based on this mapping between multicast groups and SLA requirements, the headnode can find the corresponding multicast policy based on the SLA requirements of the multicast groups.

[0258] For multicast stream 1, when a member joins the multicast group of multicast stream 1, the leaf node (egress node) sends a join message to the head node (ingress node). Figure 14 For example, when multicast receiver 1 wants to receive multicast data from multicast group G1, it sends a report message to leaf node D, which then sends a join message to head node A. When multicast receiver 2 wants to receive multicast data from multicast group G1, it sends a report message to leaf node F, which then sends a join message to head node A.

[0259] The report message sent by the multicast receiver is, for example, an IGMP membership report message. Figure 14 In the report(*, G1), “*” represents any multicast source and G1 represents the multicast group. The join message sent by the leaf node can be simplified as join(S, G, leaf<BFR ID> ), where S represents the multicast source, G represents the multicast group, and (S,G) represents the multicast group G whose multicast source is S. leaf<BFR ID> Indicates the BFR ID of the leaf node. The join message sent by leaf node D includes the identifier of multicast source S1, the identifier of multicast group G1, and the BFR ID of leaf node D (2). The join message sent by leaf node F includes the identifier of multicast source S1, the identifier of multicast group G1, and the BFR ID of leaf node F (3).

[0260] After the head node (ingress node) receives the join message sent by the leaf node (egress node), the head node updates the local BFR ID list according to the join message. Based on the updated BFR ID list, the head node selects the P2P path from the ingress node to the egress node with the largest weight value under the candidate path with the largest preference value in the multicast strategy, and then merges multiple P2P paths into a P2MP path (for specific merging methods, please refer to Figure 7 The head node sends the P2MP path to the forwarding table of (S, G) to guide the forwarding of the multicast message.

[0261] The BFR ID list includes the BFR IDs of all destination leaf nodes for a multicast stream. For the scenario where leaf node D joins, the head node updates the BFR ID list as follows: Based on the join message sent by leaf node D, the head node obtains the identifier of multicast source S1, the identifier of multicast group G1, and the BFR ID of leaf node D. The head node searches the BFR ID list corresponding to multicast source S1 and multicast group G1 and adds the BFR ID of leaf node D to the BFR ID list corresponding to multicast source S1 and multicast group G1. Similarly, for the scenario where leaf node F joins, the head node obtains the identifier of multicast source S1, the identifier of multicast group G1, and the BFR ID of leaf node F based on the join message sent by leaf node F. The head node searches the BFR ID list corresponding to multicast source S1 and multicast group G1 and adds the BFR ID of leaf node F to the BFR ID list corresponding to multicast source S1 and multicast group G1.

[0262] Each BFR ID in the BFR ID list is used to select a P2P path. Specifically, when selecting a P2P path based on the BFR ID list, the head node first finds the multicast policy that matches the color corresponding to the SLA requirement of multicast stream 1. It then selects the candidate path with the highest preference from the multicast policy. Using the BFR-ID of each leaf node in the BFR ID list as an index, it searches the candidate paths for P2P paths whose endpoints match the leaf node's BFR-ID. The found P2P paths are then merged.

[0263] Similarly, if leaf node D subsequently exits the multicast, it will send a leave message to the head node. This message includes the identifier of multicast source S1, the identifier of multicast group G1, and the BFR ID of leaf node D. Upon receiving the leave message from leaf node D, the head node removes leaf node D's BFR ID from the BFR ID list, thereby updating the BFR ID list. After updating the BFR ID list, the head node obtains multiple P2P paths corresponding to the BFR IDs from the multicast strategy based on the BFR IDs in the updated BFR ID list. The head node then merges these multiple P2P paths to obtain a new P2MP path that does not pass through leaf node D.

[0264] The above describes the calculation and control method of the P2MP path using the BIER-TE scenario as an example. This method can also be applied to the SR P2MP scenario. In the SR P2MP scenario, the above BFR ID can be replaced with a SID (for example, a multicast SID). In the step of selecting the P2P path by the head node, searching for the P2P path based on the BFR-ID can be replaced with searching for the P2P path based on the SID.

[0265] Figure 15 6 is a schematic diagram of a forwarding path determination device 600 provided in an embodiment of the present application. The device 600 is provided at the root node of the first P2MP path, and includes an acquisition unit 601 and a processing unit 602. The acquisition unit 601 is used to support the device 600 to execute Figure 7 S201. The processing unit 602 is used to support the device 600 to execute Figure 7 Optionally, the apparatus 600 further includes a receiving unit configured to support the apparatus 600 in receiving the first multicast stream. Optionally, the apparatus 600 further includes a sending unit configured to support the apparatus 600 in forwarding the first multicast stream to the n leaf nodes.

[0266] Optionally, combined Figure 1 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 1 The device 600 is used to support the root node R in Figure 1 The root node R in the process determines another P2MP path to at least two of the leaf nodes L1, L2, L3, and L4 based on a P2MP path to the leaf nodes L1, L2, L3, and L4.

[0267] Optionally, combined Figure 4 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 4 On BFR1 in.

[0268] Optionally, combined Figure 5 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 5 Device 600 is used to support R1. Figure 5 When the leaf node L3 joins the multicast, the root node R1 determines a new path for the multicast stream 3 to reach the leaf nodes L1, L2 and L3 based on the original path for the multicast stream 3 to reach the leaf nodes L1 and L2.

[0269] Optionally, combined Figure 6 From the application scenario shown, Figure 15The device 600 shown is located at Figure 6 For example, the device 600 is used to support Figure 6 The root node R in the process determines a P2MP path from the leaf node L1 to the leaf node L4 for the first multicast flow based on the P2MP path from the leaf node L1 to the leaf node L8.

[0270] Optionally, combined Figure 7 According to the method flow shown, Figure 15 The apparatus 600 shown is used to perform Figure 7 The method flow is shown.

[0271] Optionally, combined Figure 8 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 8 For example, the device 600 is used to support the root node R1. Figure 8 When a link between the node P2 and the node P4 fails, the root node R1 switches the two P2P paths in the P2MP path that reach the leaf node L1 and the leaf node L2 to the corresponding backup paths.

[0272] Optionally, combined Figure 9 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 9 For example, the device 600 is used to support the entry node BFR1 of the BIER-TE network. Figure 9 Node BFR1 in FIG determines a P2MP path to BFR10, BFR11, and BFR12 for a multicast flow whose destination leaf nodes are BFR10, BFR11, and BFR12 based on the P2MP path including BFR10, BFR11 to BFR17.

[0273] Optionally, combined Figure 11 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 11 For example, the device 600 is used to support the entry node R1 in the SRP2MP network. Figure 11 The ingress node R1 in the example determines the P2MP paths to L1, L2, L3 and L4 for the multicast flows whose destination leaf nodes are L1, L2, L3 and L4 according to the P2MP paths including nodes L1, L2 to L8.

[0274] Optionally, combined Figure 14 From the application scenario shown, Figure 15 The device 600 shown is located at Figure 14 On the head node A in.

[0275] Figure 15The device embodiments described are merely illustrative. For example, the division of the above units is merely a logical functional division. In actual implementation, there may be other division methods, such as 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 the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0276] Each unit in the apparatus 600 is implemented in whole or in part by software, hardware, firmware, or any combination thereof.

[0277] In the case of software implementation, for example, the processing unit 602 and the acquisition unit 601 are composed of Figure 16 At least one processor 701 reads the program code stored in the memory 702 and generates a software function unit to implement it.

[0278] In the case of hardware implementation, for example, Figure 15 Each of the above units is implemented by different hardware in the routing device, for example, the processing unit 602 is implemented by Figure 16 The acquisition unit 601 is implemented by a portion of the processing resources of at least one processor 701 (for example, one core or two cores in a multi-core processor). Figure 16 The remaining processing resources of at least one processor 701 (such as other cores in a multi-core processor) can be completed by using a field-programmable gate array (FPGA) or a programmable device such as a coprocessor. Figure 15 (not shown) by Figure 16 The network interface 703 in is implemented.

[0279] In the case of a combination of software and hardware, for example, the processing unit 602 is implemented by a hardware programmable device, and the acquisition unit 601 is a software functional unit generated by the CPU after reading the program code stored in the memory.

[0280] The following is an example of the basic hardware structure of the root node in the above method embodiment.

[0281] Figure 16 7 is a structural diagram of a routing device 700 provided in an embodiment of the present application. Figure 16 The illustrated routing device 700 may be provided as a root node in the above method embodiment. The routing device 700 includes at least one processor 701 , a memory 702 , and at least one network interface 703 .

[0282] Optionally, combined Figure 1 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 1 The root node R in .

[0283] Optionally, combined Figure 4 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 4 BFR1 in.

[0284] Optionally, combined Figure 5 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 5 R1 in.

[0285] Optionally, combined Figure 6 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 6 R1 in.

[0286] Optionally, combined Figure 7 According to the method flow shown, Figure 16 The routing device 700 is shown for performing Figure 7 The method flow is shown.

[0287] Optionally, combined Figure 8 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 8 The root node R1 in .

[0288] Optionally, combined Figure 9 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 9 The entry node BFR1 of the BIER-TE network.

[0289] Optionally, combined Figure 11 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 11 The entry node R1 in the SRP2MP network.

[0290] Optionally, combined Figure 14 From the application scenario shown, Figure 16 The routing device 700 shown is Figure 14 The head node A in .

[0291] Optionally, combined Figure 15 From the forwarding path determination device 600 shown in FIG. Figure 15 The device 600 is provided in Figure 16The processing unit 602 and the obtaining unit 601 in the apparatus 600 are connected to the routing device 700. Figure 16 The receiving unit and the sending unit ( Figure 16 not shown) by Figure 16 The network interface 703 in is implemented.

[0292] The processor 701 is, 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 solution of the present application. For example, the processor 701 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0293] The memory 702 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. Optionally, the memory 702 exists independently and is connected to the processor 701 via an internal connection 704. Alternatively, the memory 702 and the processor 701 are optionally integrated together.

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

[0295] In some embodiments, the processor 701 includes one or more CPUs, such as Figure 16 CPU0 and CPU1 are shown in the figure.

[0296] In some embodiments, the routing device 700 optionally includes multiple processors, such as Figure 16 , processor 701 and processor 705 are shown in FIG. Each of these processors is, for example, a single-CPU or a multi-CPU. A processor herein optionally refers to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0297] In some embodiments, routing device 700 further includes internal connections 704. Processor 701, memory 702, and at least one network interface 703 are connected via internal connections 704. Internal connections 704 include pathways that transmit information between these components. Optionally, internal connections 704 are boards or buses. Optionally, internal connections 704 are divided into address buses, data buses, control buses, and the like.

[0298] In some embodiments, the routing device 700 further includes an input / output interface 706 , which is connected to the internal connection 704 .

[0299] Optionally, the processor 701 implements the method in the above embodiment by reading the program code 710 stored in the memory 702, or the processor 701 implements the method in the above embodiment by internally stored program code. In the case where the processor 701 implements the method in the above embodiment by reading the program code 710 stored in the memory 702, the memory 702 stores the program code that implements the method provided in the embodiment of the present application.

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

[0301] See also Figure 17 , Figure 17 This is a structural diagram of a routing device provided in an embodiment of the present application. Figure 17 The routing device 800 shown in the figure can be provided as a root node in the above method embodiment. The routing device 800 includes: a main control board 810 and an interface board 830.

[0302] Optionally, combined Figure 1 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 1 The root node R in .

[0303] Optionally, combined Figure 4 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 4 BFR1 in.

[0304] Optionally, combined Figure 5 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 5 R1 in.

[0305] Optionally, combined Figure 6 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 6 R1 in.

[0306] Optionally, combined Figure 7 According to the method flow shown, Figure 17 The routing device 800 is shown for performing Figure 7 The method flow is shown.

[0307] Optionally, combined Figure 8 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 8 The root node R1 in .

[0308] Optionally, combined Figure 9 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 9 The entry node BFR1 of the BIER-TE network.

[0309] Optionally, combined Figure 11 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 11 The entry node R1 in the SRP2MP network.

[0310] Optionally, combined Figure 14 From the application scenario shown, Figure 17 The routing device 800 shown is Figure 14 The head node A in .

[0311] Optionally, combined Figure 15 From the forwarding path determination device 600 shown in FIG. Figure 15 The device 600 is provided in Figure 17 The processing unit 602 and the obtaining unit 601 in the apparatus 600 are connected to the routing device 700. Figure 17 The second P2MP path determined by the apparatus 600 is sent by the main control board 810 to the interface board 830 in the form of a forwarding table entry. The interface board 830 stores the forwarding table entry in the memory 834 and forwards the multicast stream through the physical interface card 833.

[0312] The main control board (810), also known as the main processing unit (MPU) or route processor card, is used to control and manage the various components in routing device 800, including routing calculation, device management, device maintenance, and protocol processing. It includes a central processing unit (CPU) 811 and memory 812.

[0313] Interface board 830 is also known as a line processing unit (LPU), line card, or service board. It provides various service interfaces and implements data packet forwarding. Service interfaces include, but are not limited to, Ethernet interfaces and POS (packet over SONET / SDH) interfaces. Ethernet interfaces, for example, are interfaces for flexible Ethernet clients (FlexE clients). Interface board 830 includes a central processing unit (CPU) 831, a network processor (NPU) 832, a forwarding table memory (FMM) 834, and a physical interface card (PIC) 833.

[0314] The central processing unit 831 on the interface board 830 is used to control and manage the interface board 830 and communicate with the central processing unit 811 on the main control board 810 .

[0315] The network processor 832 is used to implement message forwarding processing. The network processor 832 can be in the form of a forwarding chip, for example. Specifically, the network processor 832 is used to forward received messages based on the forwarding table stored in the forwarding table memory 834. If the destination address of the message is the address of the routing device 800, the message is sent to the CPU (such as the central processing unit 811) for processing. If the destination address of the message is not the address of the routing device 800, the next hop and outgoing interface corresponding to the destination address are searched in the forwarding table based on the destination address, and the message is forwarded to the outgoing interface corresponding to the destination address. The processing of uplink messages includes: processing of the message input interface and forwarding table search; processing of downlink messages includes forwarding table search, etc.

[0316] Physical interface card 833 implements physical layer connectivity. Raw traffic enters interface board 830 through this card, and processed messages are sent from this physical interface card 833. Physical interface card 833, also known as a daughter card, can be installed on interface board 830. It converts optical and electrical signals into messages, performs a validity check on these messages, and then forwards them to network processor 832 for processing. In some embodiments, a central processing unit (CPU) can also perform the functions of network processor 832, such as implementing software forwarding based on a general-purpose CPU. This eliminates the need for network processor 832 in physical interface card 833.

[0317] Optionally, the routing device 800 includes multiple interface boards. For example, the routing device 800 further includes an interface board 840 . The interface board 840 includes a central processing unit 841 , a network processor 842 , a forwarding table entry memory 844 , and a physical interface card 843 .

[0318] Optionally, the routing device 800 further includes a switching fabric board 820. The switching fabric board 820 is also referred to as a switch fabric unit (SFU). If the routing device has multiple interface boards 830, the switching fabric board 820 is used to exchange data between the interface boards. For example, the interface board 830 and the interface board 840 communicate via the switching fabric board 820.

[0319] The main control board 810 and the interface board 830 are coupled. For example, the main control board 810, the interface board 830, the interface board 840, and the switching network board 820 are connected to the system backplane via a system bus to achieve intercommunication. In one possible implementation, an inter-process communication (IPC) channel is established between the main control board 810 and the interface board 830, and communication between the main control board 810 and the interface board 830 is performed via the IPC channel.

[0320] Logically, routing device 800 includes a control plane and a forwarding plane. The control plane includes a main control board 810 and a central processing unit (CPU) 831. The forwarding plane includes various components that perform forwarding, such as a forwarding table entry memory 834, a physical interface card 833, and a network processor 832. The control plane performs routing functions, generates forwarding tables, processes signaling and protocol messages, and configures and maintains device status. The control plane sends the generated forwarding tables to the forwarding plane. On the forwarding plane, the network processor 832 forwards messages received by the physical interface card 833 based on the forwarding tables sent by the control plane. The forwarding tables sent by the control plane are stored, for example, in the forwarding table entry memory 834. In some embodiments, the control plane and forwarding plane are completely separate and not located on the same device.

[0321] The operations on interface board 840 are consistent with those on interface board 830 and are not described in detail here for the sake of brevity. It should be understood that routing device 800 of this embodiment may correspond to the root node in each of the above-mentioned method embodiments. The main control board 810, interface board 830, and / or 840 in routing device 800, for example, implement the functions and / or various steps performed by the root node in each of the above-mentioned method embodiments. For the sake of brevity, these details are not described here in detail.

[0322] There may be one or more main control boards, including, for example, a primary and a backup main control board. There may be one or more interface boards. The stronger the data processing capabilities of a routing device, the more interface boards it provides. An interface board may also have one or more physical interface cards. There may be no switching fabric board, one or more switching fabric boards, and multiple switching fabric boards can collectively implement load balancing and redundant backup. In a centralized forwarding architecture, routing devices may not require switching fabric boards; the interface boards handle the entire system's service data processing. In a distributed forwarding architecture, routing devices may have at least one switching fabric board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, routing devices with a distributed architecture have greater data access and processing capabilities than those with a centralized architecture. Alternatively, a routing device can consist of a single card, without a switching fabric board. The functions of the interface board and the main control board are integrated on this single card. 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 on this card to perform the combined functions of the two. This type of device has lower data exchange and processing capabilities (for example, low-end routing devices such as switches or routers). The specific architecture used depends on the specific networking deployment scenario and is not specified here.

[0323] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0324] A refers to B, which means that A is the same as B or A is a simple variant of B.

[0325] The terms "first" and "second" in the description and claims of the embodiments 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, the terms "first P2MP path" and "second P2MP path" are used to distinguish different P2MP paths, not to describe a specific order of P2MP paths, and should not be construed as implying that the first P2MP path is more important than the second P2MP path.

[0326] In the embodiments of the present application, unless otherwise specified, "at least one" means one or more, and "a plurality" means two or more. For example, "a plurality of P2P paths" means two or more P2P paths.

[0327] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in accordance with the embodiment of the present application is generated in whole or in part. 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 computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. 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 includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0328] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for determining a forwarding path, characterized in that: The root node applied to the first point-to-multipoint P2MP path includes: Obtain m point-to-point P2P paths split from the first P2MP path, where m is the number of leaf nodes included in the first P2MP path; Selecting n P2P paths from the m P2P paths according to the n leaf nodes for receiving the first multicast stream, where n is a positive integer less than or equal to m; A second P2MP path is obtained based on the n P2P paths, where the second P2MP path is used to forward the first multicast stream to the n leaf nodes, and the leaf nodes of the second P2MP path are some or all of the leaf nodes of the first P2MP path.

2. The method according to claim 1, characterized in that The first node of any P2P path among the n P2P paths is the root node of the first P2MP path, and the last node of any P2P path among the n P2P paths is a leaf node of the first P2MP path.

3. The method according to claim 1 or 2, characterized in that The obtaining of a second P2MP path based on the n P2P paths includes: Obtaining a bit string corresponding to each of the n P2P paths; Based on the bit string corresponding to each of the n P2P paths, a bit string corresponding to the second P2MP path is obtained, where the bit string corresponding to the second P2MP path is a result of performing an OR operation on the bit strings corresponding to all the P2P paths included in the n P2P paths.

4. The method according to claim 1 or 2, characterized in that The obtaining of a second P2MP path based on the n P2P paths includes: Obtain a segment list corresponding to each of the n P2P paths; Based on the segment list corresponding to each of the n P2P paths, a segment list corresponding to the second P2MP path is obtained, where the segment list corresponding to the second P2MP path includes segment identifiers in segment lists corresponding to all P2P paths included in the n P2P paths.

5. The method according to claim 1 or 2, characterized in that The first P2MP path is a path established according to a preset service level agreement SLA requirement and the preset m leaf nodes, and the SLA requirement of the first multicast stream is the same as the preset SLA requirement.

6. The method according to claim 1 or 2, characterized in that The first P2MP path is a path before multicast joining or multicast exiting in the multicast group corresponding to the first multicast stream.

7. The method according to claim 1 or 2, characterized in that The first P2MP path is used to forward a second multicast stream, and the SLA requirement of the second multicast stream is the same as the SLA requirement of the first multicast stream.

8. The method according to claim 1 or 2, characterized in that After obtaining the second P2MP path based on the n P2P paths, the method further includes: A first P2P path included in the second P2MP path fails, and a third P2MP path is obtained based on the second P2MP path. The third P2MP path includes a backup path of the first P2P path and P2P paths other than the first P2P path among the n P2P paths.

9. The method according to claim 1 or 2, characterized in that Before obtaining the m point-to-point P2P paths obtained by splitting the first P2MP path, the method further includes: A multicast policy is acquired based on the SLA requirement of the first multicast stream, where the multicast policy includes information about the n P2P paths and information for identifying the SLA requirement.

10. The method according to claim 9, characterized in that The information of the n P2P paths in the multicast strategy includes a bit string or a segment list corresponding to each of the n P2P paths.

11. The method according to claim 10, characterized in that The information of the n P2P paths in the multicast strategy further includes a bit string or a segment list corresponding to a backup path of each of the n P2P paths.

12. A device for determining a forwarding path, characterized in that: include: an acquiring unit, configured to acquire m point-to-point P2P paths obtained by splitting the first P2MP path, and select n P2P paths from the m P2P paths based on n leaf nodes used to receive the first multicast stream, where m is the number of leaf nodes included in the first P2MP path, and n is a positive integer less than or equal to m; A processing unit is configured to obtain a second P2MP path based on the n P2P paths, where the second P2MP path is used to forward the first multicast stream to the n leaf nodes, and the leaf nodes of the second P2MP path are some or all of the leaf nodes of the first P2MP path.

13. The device according to claim 12, characterized in that The first node of any P2P path among the n P2P paths is the root node of the first P2MP path, and the last node of any P2P path among the n P2P paths is a leaf node of the first P2MP path.

14. The device according to claim 12 or 13, characterized in that The processing unit is configured to obtain a bit string corresponding to each of the n P2P paths; and obtain a bit string corresponding to the second P2MP path based on the bit string corresponding to each of the n P2P paths, where the bit string corresponding to the second P2MP path is a result of performing an OR operation on the bit strings corresponding to all the P2P paths included in the n P2P paths.

15. The device according to claim 12 or 13, characterized in that The processing unit is configured to obtain a segment list corresponding to each of the n P2P paths; and obtain a segment list corresponding to the second P2MP path based on the segment list corresponding to each of the n P2P paths, where the segment list corresponding to the second P2MP path includes segment identifiers in the segment lists corresponding to all P2P paths included in the n P2P paths.

16. The device according to claim 12 or 13, characterized in that The first P2MP path is a path established according to a preset service level agreement SLA requirement and the preset m leaf nodes, and the SLA requirement of the first multicast stream is the same as the preset SLA requirement.

17. The device according to claim 12 or 13, characterized in that The first P2MP path is a path before multicast joining or multicast exiting in the multicast group corresponding to the first multicast stream.

18. The device according to claim 12 or 13, characterized in that The first P2MP path is used to forward a second multicast stream, and the SLA requirement of the second multicast stream is the same as the SLA requirement of the first multicast stream.

19. The device according to claim 12 or 13, characterized in that The processing unit is further configured to, if a first P2P path included in the second P2MP path fails, obtain a third P2MP path based on the second P2MP path, where the third P2MP path includes a backup path of the first P2P path and P2P paths other than the first P2P path among the n P2P paths.

20. The device according to claim 12 or 13, characterized in that The acquisition unit is further configured to acquire a multicast policy based on the SLA requirement of the first multicast stream, where the multicast policy includes information about the n P2P paths and information for identifying the SLA requirement.

21. The device according to claim 12 or 13, characterized in that The device is located at the root node of the first P2MP path.

Images