WO2023206165A1

WO2023206165A1 - Multicast data message sending method and apparatus, and device and storage medium

Info

Publication number: WO2023206165A1
Application number: PCT/CN2022/089652
Authority: WO
Inventors: 刘淑英; 段方红; 谢经荣; 卢延辉; 耿雪松
Original assignee: 华为技术有限公司
Priority date: 2022-04-27
Filing date: 2022-04-27
Publication date: 2023-11-02

Abstract

The embodiments of the present application belong to the technical field of multicasting. Disclosed are a multicast data message sending method and apparatus, and a device and a storage medium. The method is applied to a leaf node in a BIER domain. The method comprises: receiving a first multicast data message by means of a first path, wherein the first multicast data message comprises a first parameter, and the first parameter is used for measuring a performance index; obtaining a first performance index according to the first parameter; and determining, on the basis of the first performance index, that the first path does not meet a performance requirement, and then receiving a second multicast data message by means of a second path. By using the present application, a SLA quality requirement of a multicast service can be met without affecting the forwarding of a unicast service message.

Description

Methods, devices, equipment and storage media for sending multicast data messages

Technical field

The present application relates to the field of multicast technology, and in particular to a method, device, equipment and storage medium for sending multicast data messages.

Background technique

Bit-indexed explicit replication (BIER) technology is currently a widely used multicast technology.

In order to meet the Service Level Agreement (SLA) quality requirements of multicast data flow, if the BIER forwarding router (Bit-Forwarding Router, BFR) in the BIER domain detects an error in the multicast data flow received by an interface, If the code rate is too high, it indicates that there is a problem with the link where the interface is located. In this case, adjust the interface to the down state. In this way, the interface no longer performs the reception of any data flow, so that the multicast data flow does not pass through this problematic link.

However, directly adjusting the interface status to down will cause the link where the interface is located to no longer receive any data streams, causing all data streams originally transmitted by this link to be switched to other links for transmission. This is very likely to cause other links to The road load is too high.

Contents of the invention

Embodiments of the present application provide a method, device, equipment and storage medium for sending multicast data packets, which can meet the SLA of the multicast service without adjusting the router interface status. The technical solutions are as follows:

The first aspect provides a method for sending multicast data packets, which is applied to leaf nodes in the BIER domain. The method includes:

The leaf node receives the first multicast data packet through the first path. The first multicast data message includes a first parameter, and the first parameter is used to detect performance indicators. The leaf node obtains the first performance index according to the first parameter. The leaf node determines that the first path does not meet the performance requirements based on the first performance index, and receives the second multicast data message through the second path.

In the solution shown in the embodiment of this application, the leaf node can receive the multicast data packet through the first path and the second path. In an ideal state, the multicast service data carried in the multicast data packet transmitted by the first path and the multicast service data carried in the multicast data packet transmitted by the second path are the same. Under normal circumstances, the leaf The node can only receive and send multicast data packets sent by the first path. In this way, when the leaf node detects that the first path does not meet the performance indicators, it can no longer receive and send multicast data packets sent by this path, but switch to receive and send multicast data packets sent by another path. It can be seen that this method is a method for multicast services. This method can enable multicast services to avoid paths whose performance does not meet the requirements, so that the multicast service data received and sent by leaf nodes is transmitted by paths with better performance. In this way, the SLA of multicast services can be guaranteed without affecting the unicast services carried on the network. This solution can meet the SLA requirements of the multicast service without changing the interface status. Therefore, the problem of excessive link load caused by setting the interface status down will not occur.

In a possible implementation, the first multicast data packet includes a BIER header and an In-situ Flow Information Telemetry (IFIT) header, and the IFIT header is used to carry the first parameter.

In the solution shown in the embodiment of this application, the multicast data packet transmitted by the first path is a BIER packet. The IFIT technology may be used to determine the performance index of the first path based on the first parameter carried in the IFIT header of the first multicast data message. In this way, the performance indicators are detected based on actual multicast data packets, with higher accuracy. In addition, IFIT technology only requires the root node and leaf nodes to configure the IFIT function. There are few devices that need to be configured, and the configuration is relatively simple.

In a possible implementation, the first multicast data packet includes a BIER header and a Real-time Transport Protocol (RTP) header, and the RTP header is used to carry the first parameter. Alternatively, the first multicast data message includes a BIER header and a transport stream TS header, and the TS header is used to carry the first parameter.

In the solution shown in the embodiment of this application, the enhanced media delivery index (EMDI) technology can be used to determine the first parameter carried in the RTP header or TS header of the first multicast data message. Performance indicators of a path. In this way, the performance indicators are detected based on actual multicast data packets, with higher accuracy. In addition, EMDI technology only requires the root node and leaf nodes to configure the EMDI function. There are few devices that need to be configured, and the configuration is relatively simple.

In a possible implementation, the first multicast data packet is a BIER packet encapsulated based on Internet Protocol Version 6 (IPv6), and the BIER header in the first multicast data packet is used to Carry the first parameter.

In the solution shown in the embodiment of this application, when the multicast data message is a BIER message encapsulated based on IPv6, the original field in the BIER header can be used to carry the first parameter, and there is no need to extend the BIER header.

In a possible implementation, when the multicast data packet is a BIER packet encapsulated based on IPv6, the following field in the BIER header can be used to carry the first parameter:

The entropy field in the BIER header, or the BIER forwarding ingress router ID (BFIR ID) field in the BIER header, or the traffic level field in the BIER header, the field used to identify the bottom of the label stack, and survival The time field, or the field and lifetime field in the BIER header used to identify the bottom of the label stack.

In a possible implementation, the first multicast data packet is a BIER packet encapsulated based on Multi-Protocol Label Switching (MPLS), and the BIER header in the first multicast data packet is used to Carry the first parameter.

In the solution shown in the embodiment of this application, when the multicast data message is a BIER message based on MPLS encapsulation, the BIER header is extended and the extension field is used to carry the first parameter.

In a possible implementation, the first parameter includes a sending timestamp. Correspondingly, the process of determining the performance index can be as follows:

Performance metrics can be calculated by the controller and sent to leaf nodes. Correspondingly, the processing can be as follows:

After receiving the first multicast data packet, the leaf node determines the reception timestamp of the first multicast data packet and obtains the sending timestamp carried in the IFIT header of the first multicast data packet. The leaf node then sends the send timestamp and receive timestamp to the controller. The controller can calculate at least one of the transmission delay and delay jitter based on the sending timestamp and receiving timestamp sent by the leaf node, and sends it to the leaf node.

Since the calculation of performance indicators is uniformly performed by the controller, the computing performance requirements for leaf nodes are low.

In a possible implementation, the first parameter includes the first sequence number. Correspondingly, the process of determining the performance index can be as follows:

After receiving the first multicast data packet, the leaf node obtains the first sequence number carried in the RTP header or TS header of the first multicast data packet and sends the first sequence number to the controller. It can indicate the sending order of the first multicast data packet. The controller calculates performance indicators such as packet loss rate and out-of-order based on the multiple sequence numbers received, and sends them to the leaf nodes.

In a possible implementation, the performance index can be calculated by the leaf nodes themselves. Correspondingly, when the first parameter includes the sending timestamp, the process of determining the performance index can be as follows:

After receiving the first multicast data packet, the leaf node determines the reception timestamp of the first multicast data packet and obtains the sending timestamp carried in the IFIT header of the first multicast data packet. Then, the leaf node sending timestamp and receiving timestamp can calculate at least one of the transmission delay and delay jitter.

When there are a large number of leaf nodes, if all performance indicators are calculated by the controller, it may cause excessive computational burden on the controller, resulting in low computational efficiency. Calculating performance indicators by leaf nodes can reduce the calculation amount of the controller and improve calculation efficiency.

In a possible implementation, the performance index can be calculated by the leaf nodes themselves. Correspondingly, when the first parameter includes the first serial number, the process of determining the performance index may be as follows:

After receiving the first multicast data packet, the leaf node obtains the first sequence number carried in the RTP header or TS header of the first multicast data packet. Then, the leaf node calculates performance indicators such as packet loss rate and reordering based on the multiple sequence numbers received.

In a possible implementation, in order to avoid switching to a path with worse performance, while detecting the performance index of the first path, the performance index of the second path can also be detected, and after determining the performance index indicated by the second path When the performance is better than the performance indicated by the performance index of the first path, if the first path does not meet the performance requirements, it can be switched to receive multicast data packets of the second path.

In a possible implementation, in order to prevent the switched second path from containing the faulty link in the first path, the first path and the second path may be non-overlapping paths obtained by planning of the controller. Or, the first path and the second path belong to different flexible algorithm (Flex Algo) slices and are non-overlapping paths. Non-overlapping means that they do not contain the same links.

In a second aspect, a method for sending multicast data messages is provided. The method is applied to the root node in the BIER domain. The method includes:

Obtain a multicast data message, the multicast data message includes a first parameter, and the first parameter is used to detect performance indicators;

Send the multicast data message to the leaf node through the first path.

In a possible implementation manner, the multicast data message includes a BIER header and an IFIT header, and the IFIT header is used to carry the first parameter.

In a possible implementation, the multicast data message includes a BIER header and an RTP header, and the RTP header is used to carry the first parameter; or

The first multicast data message includes a BIER header and a TS header, and the TS header is used to carry the first parameter.

In a possible implementation manner, the multicast data packet is a BIER packet based on IPv6 encapsulation, and the BIER header in the multicast data packet is used to carry the first parameter.

In a possible implementation, the entropy field in the BIER header is used to carry the first parameter; or

The BFIR ID field in the BIER header is used to carry the first parameter; or

The TC field, S field and TTL field in the BIER header carry the first parameter; or

The S field and TTL field in the BIER header are used to carry the first parameter.

In a possible implementation manner, the multicast data packet is a BIER packet based on MPLS encapsulation, and the BIER header in the first multicast data packet is used to carry the first parameter.

In a possible implementation, the first parameter includes at least one of a sending timestamp and a first sequence number.

A third aspect provides a device for sending multicast data messages, which device is provided on a leaf node in the first aspect or any optional method of the first aspect. The message forwarding device includes at least one module, and the at least one module is used to implement the method provided by the above-mentioned first aspect or any optional manner of the first aspect. In some embodiments, the multicast data message sending provided by the third aspect is implemented by a module in the device through software, and the unit in the message forwarding device is a program module. In other embodiments, the modules in the packet forwarding device provided in the third aspect are implemented by hardware or firmware. For specific details of the device for sending multicast data messages provided in the third aspect, please refer to the above-mentioned first aspect or any optional method of the first aspect, and will not be described again here.

A fourth aspect provides a device for sending multicast data messages, which device is provided on a leaf node in the second aspect or any optional mode of the second aspect. The message forwarding device includes at least one module, and the at least one module is used to implement the method provided in the above second aspect or any optional manner of the second aspect. In some embodiments, the multicast data message sending provided in the fourth aspect is implemented by a module in the device through software, and the unit in the message forwarding device is a program module. In other embodiments, the modules in the message forwarding apparatus provided in the fourth aspect are implemented by hardware or firmware. For specific details of the device for sending multicast data packets provided in the fourth aspect, please refer to the above-mentioned second aspect or any optional method of the second aspect, and will not be described again here.

In a fifth aspect, a network device is provided. The network device includes a processor and a memory. At least one instruction is stored in the memory. The at least one instruction is loaded and executed by the processor to implement the first step described above. method provided by the aspect or any optional method of the first aspect. The specific details of obtaining the network device provided in the fifth aspect can be found in the above-mentioned first aspect or any optional method of the first aspect, and will not be described again here.

In a sixth aspect, a network device is provided. The network device includes a processor and a memory. At least one instruction is stored in the memory. The at least one instruction is loaded and executed by the processor to implement the second step described above. The method provided by any optional method of the aspect or the second aspect. The specific details of obtaining the network equipment provided in the sixth aspect can be found in the above-mentioned second aspect or any optional method of the second aspect, and will not be described again here.

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

In an eighth aspect, a computer-readable storage medium is provided. At least one instruction is stored in the storage medium. When the instruction is run on a network device, the network device causes the network device to execute the above second aspect or any one of the second optional aspects. method provided.

In a ninth aspect, a computer program product is provided. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a network device, the network device causes the network device to execute the first aspect. Or the method provided by any optional method in the first aspect.

In a tenth aspect, a computer program product is provided. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a network device, the network device causes the network device to execute the above second aspect. Or the method provided by any optional method in the second aspect.

In an eleventh aspect, a chip is provided, including a memory and a processor. The memory is used to store computer instructions. The processor is used to call and run the computer instructions from the memory to execute the above first aspect and any possibility of the first aspect. method in the implementation.

In a twelfth aspect, a chip is provided, including a memory and a processor. The memory is used to store computer instructions. The processor is used to call and run the computer instructions from the memory to execute the above second aspect or any one of the second aspects. Optional methods provided.

A thirteenth aspect provides a communication system, which includes the network device described in the fifth aspect and the network device described in the sixth aspect.

Description of the drawings

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

Figure 2 is a schematic diagram of multicast data flow switching provided by an embodiment of the present application;

Figure 3 is a schematic flowchart of a method for sending multicast data messages provided by an embodiment of the present application;

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

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

Figure 6 is a schematic flowchart of a method for sending multicast data messages provided by an embodiment of the present application;

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

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

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

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

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

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

Figure 13 is a schematic flowchart of a method for sending multicast data messages provided by an embodiment of the present application;

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

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

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

Figure 17 is a schematic flowchart of a method for sending multicast data messages provided by an embodiment of the present application;

Figure 18 is a schematic flowchart of a method for sending multicast data messages provided by an embodiment of the present application;

Figure 19 is a schematic structural diagram of a device for sending multicast data messages provided by an embodiment of the present application;

Figure 20 is a schematic structural diagram of a device for sending multicast data messages provided by an embodiment of the present application;

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

Detailed ways

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

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

(1) Bit indexed explicit replication (BIER)/bit indexed explicit replication over ipv6 (BIERv6)

BIER/BIERv6 is a multicast forwarding technology that performs explicit replication based on bit indexing. In the BIER domain, the edge router is assigned a unique identifier, that is, the BIER forwarding router identifier (BFR ID). BFR ID is an integer ranging from 1 to 65535. Edge routers include BIER forwarding ingress router (bit forwarding ingress router, BFIR) and BIER forwarding egress router (bit forwarding egress router, BFER). During the forwarding process, BFIR needs to know which BIER nodes to send multicast data packets to. In a BIER domain, the BFER set to which multicast data packets are sent is represented by a set bit in a bit string. The offset position of a certain bit in the bit string corresponds to the offset position in the bit string. The BFR ID of an edge router. BFIR encapsulates the bit string corresponding to at least one BFER in the BIER header of the multicast data message. The intermediate BFR between BFIR and BFER can copy and forward based on the bit string in the received multicast data message, so that Multicast data packets can be forwarded to the corresponding BFER.

When BIER/BIERv6 carries multicast services, BGP neighbors are established between BFIR and BFER through the border gateway protocol (BGP), and the BGP interaction information is used to establish a BIER forwarding tunnel to achieve interaction. When an end user wants to watch a multicast channel program, a channel group join request is sent to its upstream BFER. Among them, in the case of Internet protocol version 4 (IPv4), the join request is an Internet group management protocol (Internet group management protocol, IGMP) message. In the case of Internet protocol version 6 (IPv6), the join request is a multicast listener (MLD) message; if BFER does not have the channel data requested by the end user, the join request will be The request is sent to BFIR via BGP protocol. After receiving the join request from BFER, BFIR sets the bit in the bit string corresponding to the BFR ID of this BFER to 1, thus generating the bit string required to send the multicast data of the channel.

BFIR sends the multicast data message encapsulated with bit string to the downstream BFR according to the bit index forwarding table (BIFT). The downstream BFR parses the bit string and copies the multicast data message according to the entries in BIFT. Send, so that the multicast data packet encapsulated with bit string is forwarded to the corresponding BFER. BFER parses the bit string, checks the destination node that matches the multicast data message, then deletes the outer encapsulation including the BIER header, continues to search the user multicast forwarding table, and forwards the multicast data message to the requesting user based on the search results.

Traditional BIER is implemented based on multi-protocol label switching (MPLS). The biggest difference between BIERv6 and traditional BIER is that BIERv6 no longer uses MPLS labels and is a multicast solution based on native IPv6 (native IPv6). BIERv6 inherits the core design concept of BIER. It uses bit strings to copy multicast data messages to designated recipients. The intermediate BFR does not need to establish a multicast forwarding tree to achieve stateless forwarding. On this basis, BIERv6 technology uses the IPv6 extension header to carry the information required for BIER forwarding, eliminating the need to use MPLS labels. The use of IPv6 extension headers also facilitates subsequent network evolution and overlay, such as fragmentation and reassembly of IPv6 packets, multicast network slicing, and flow detection, etc. Since the service is only deployed on the head node and the tail node, the intermediate nodes do not sense when the multicast service changes. Therefore, when the network topology changes, there is no need to perform undo and rebuild operations on a large number of multicast trees, which greatly simplifies operation and maintenance work. BIERv6 uses IPv6 extension headers to implement its functions. BIERv6 uses the IPv6 extension header to carry BIER options (also called BIER headers), which together with the IPv6 header form the BIERv6 message header. The intermediate BFR reads the bit string in the BIER option, copies, forwards and updates the bit string according to BIFT.

(2) Root node and leaf node

BFIR can also be called the root node, and BFER can also be called the leaf node. In order to realize the backup of multicast data packets, for a multicast source, any multicast service data of the multicast source can be copied and then entered into the BIER domain through two root nodes for forwarding. The two root nodes here include a primary root node and a backup root node. Leaf nodes can determine the primary root node and backup root node based on the routing priorities of the two root nodes. Specifically, a BGP neighbor is established between the root node and the leaf node, and the leaf node can select the root node with the highest routing priority as the primary root node, and the root node with the second highest routing priority as the backup root node.

(3) Ethernet link aggregation (ethernet-trunk, ETH-trunk) bundled interface

Trunk is a bundling technology. Multiple physical interfaces are bundled into a logical interface. This logical interface is called a trunk bundled interface, and each physical interface bundled together is called a member interface. Using trunk bundling technology to bundle multiple physical interfaces together can meet the need to increase interface bandwidth at a lower cost. For example, bundling three 100Mbit/s full-duplex interfaces together can achieve a maximum bandwidth of 300Mbit/s. ETH-trunk bundles multiple Ethernet interfaces into a logical interface. This logical interface is called an Eth-trunk bundled interface, and each Ethernet interface bundled together is called a member interface. Eth-trunk bundled interfaces can increase bandwidth, improve reliability and load sharing.

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

Figure 1 is a schematic diagram of an implementation scenario of BIER provided by an embodiment of the present application. The implementation scenario shown in Figure 1 includes multicast source A, root node A, root node B, intermediate node A, intermediate node B, intermediate node C, Intermediate node D, leaf node A, leaf node B, leaf node C, leaf node D, multicast receiving device A, multicast receiving device B, multicast receiving device C and multicast receiving device D. Multicast sources include but are not limited to servers, terminals, etc. Multicast source A is used to generate and send multicast service data. The multicast service data generated by multicast source A includes but is not limited to audio data, video data, etc. Root node A, root node B, intermediate node A, intermediate node B, intermediate node C, intermediate node D, leaf node A, leaf node B, leaf node C, and leaf node D are deployed in the same BIER domain. These nodes can be network devices such as routers, switches, etc. Root node A and root node B are the BFIR of the BIER domain. Leaf node A, leaf node B, leaf node C, and leaf node D are BFERs of the BIER domain. For any leaf node among leaf node A, leaf node B, leaf node C, and leaf node D, one of root node A and root node B is the main root node, and the other is the backup root node.

Root node A and root node B receive the same multicast service data from multicast source A, and perform BIER MPLS encapsulation or BIERv6 encapsulation on the received multicast service data to obtain a multicast data packet, in which the multicast data packet Included is the BIER header. Then, root node A and root node B send the multicast data message encapsulated in the bit string to the next hop according to the bit index forwarding table (BIFT). The next hop can be an intermediate node or a leaf node.

The intermediate node is used to forward multicast data packets to leaf nodes based on the saved BIFT. Correspondingly, without considering the bit errors in multicast data packets caused during the transmission process, leaf nodes can receive multicast data packets from the primary root node and multicast data packets from the backup root node.

After the leaf node receives the multicast data message sent by the intermediate node or the root node, it determines that the bit corresponding to its own BFR ID in the bit string of the BIER header is 1. The leaf node determines whether the multicast data packet comes from the main root node or the backup root node. If it is determined that the multicast data packet comes from the main root node, the multicast data packet is stripped of the BIER MPLS encapsulation or BIERv6 encapsulation, and the multicast forwarding table is queried, and the multicast service data after the BIER MPLS encapsulation or BIERv6 encapsulation is stripped is forwarded to The corresponding multicast receiving device; if it is determined that the multicast data packet comes from the backup root node, the received multicast data packet can be discarded. The following explains how leaf nodes determine which root node a multicast data packet comes from:

When the multicast data message is encapsulated using BIER MPLS, the BFIR-ID in the BIER header of the multicast data message is the BFR ID of the root node that sends the multicast data message; when the multicast data message is When BIERv6 encapsulation is used, the source address in the outer IPv6 header of the multicast data packet is the address of the root node that sends the multicast data packet.

In order to achieve SLA guarantee for multicast services without affecting unicast services, in the embodiment of this application, the leaf node determines the performance index of the first path by obtaining the parameters carried in the multicast data packet transmitted by the first path. , where the first path is the path between the leaf node and the main root node. When the performance index of the first path does not meet the performance requirements, the leaf node switches to receive and forward the multicast data packets from the second path, where the second path is the path between the leaf node and the backup root node. The following describes the switching of multicast data packets by leaf nodes based on path performance with reference to Figure 2.

Referring to Figure 2, assume that the main root node and backup root node corresponding to leaf node B are: root node A and root node B respectively. Multicast data packets are transmitted between root node A and leaf node B through the first path, and multicast data packets are transmitted between root node B and leaf node B through the second path. Under normal circumstances, leaf node B receives and forwards multicast data packets on the first path, while multicast data packets on the second path can be discarded. Leaf node B can determine the performance index of the first path based on the parameters carried in the multicast data packet transmitted by the first path. When the performance index of the first path does not meet the performance requirements, leaf node B switches to receive and Forward multicast data packets on the second path.

In the embodiments of this application, there may be multiple methods for determining the performance index, and in different methods, the parameters based on which the performance index is determined may also be different. The method for sending multicast data packets provided by the embodiments of this application will be described below in combination with different methods for determining performance indicators.

Method 1 for determining performance indicators: Determine the performance indicators of the path based on in-situ flow information telemetry (IFIT) technology:

Referring to Figure 3, when method 1 is used to determine performance indicators, the processing flow of multicast data message sending in the embodiment of the present application may include the following steps. The following is combined with the implementation scenario shown in Figure 2, with root node A as leaf node B. The main root node of , root node B is the backup root node of leaf node B as an example. The steps shown in Figure 3 are explained:

Step 301: Enable the IFIT detection function on the main root node and leaf nodes.

In order to implement IFIT detection, the IFIT detection function can be configured on root node A and leaf node B in advance. For example, root node A receives an IFIT detection instruction to determine to perform IFIT detection. The IFIT detection command may include multicast source information, and the multicast source information is used to instruct IFIT detection on the multicast service data of multicast source A. After receiving the multicast service data sent by multicast source A, root node A can encapsulate the IFIT header for the multicast service data, so that the generated multicast data packet includes an IFIT header. Leaf node B receives the IFIT detection instruction and enables the IFIT detection function. After receiving the multicast data message including the IFIT header, leaf node B can perform IFIT detection based on the parameters carried in the IFIT header. The above IFIT detection instructions can be implemented by the configuration issued by the controller or statically configured. For example, the controller can issue IFIT detection instructions based on network configuration protocol (NETCONF), simple network management protocol (simple network management protocol), etc. In addition, when implemented based on NETCONF, NETCONF combined with the YANG model (a data modeling language) can be used to implement the issuance of IFIT detection instructions.

Step 302: The main root node forwards the multicast data packet through the first path.

For example, after receiving the multicast service data sent by multicast source A, root node A encapsulates the multicast service data to obtain a multicast data message. Specifically, root node A can perform BIER MPLS encapsulation or BIERv6 encapsulation on the received multicast service data. In addition, because the IFIT detection function is enabled on root node A, the multicast service data must be IFIT encapsulated. In this way, the encapsulated multicast data packet includes a BIER header and an IFIT header. After completing the encapsulation, root node A forwards the encapsulated multicast data message to intermediate node A through the first path according to the saved entry in BIFT.

The following describes the format of the multicast data message that combines BIER MPLS encapsulation and IFIT encapsulation:

Referring to Figure 4, the multicast data packet combined with BIER MPLS encapsulation and IFIT encapsulation includes an Ethernet header, a BIER header, an IFIT header and an Internet Protocol multicast payload (IP multicast payload). The IP multicast payload is from the multicast source. Multicast service data. Among them, the IFIT header has multiple possible formats. In Figure 4, two of the possible formats are exemplarily shown. Referring to Table 1, the following fields can be included in Format 1 of the IFIT header:

Table 1

字段Field	描述describe
FlowMonID(20bits)FlowMonID(20bits)	被监测的业务流标识，设备内唯一The identifier of the monitored business flow, unique within the device
L(1bit)L(1bit)	丢包检测染色标识Packet loss detection dyeing mark
D(1bit)D(1bit)	时延检测染色标识Time delay detection dyeing mark
HTI(8bits)HTI(8bits)	标识扩展头的类型Identifies the type of extension header
NodeMonID(20bits)NodeMonID(20bits)	流监测的设备节点标识Device node ID for flow monitoring
F(1bit)F(1bit)	业务流方向标识Business flow direction identifier
P(3bits)P(3bits)	测量周期Measurement period
T(2bits)T(2bits)	标识检测类型Identification detection type
Ext FM Type(16bits)Ext FM Type(16bits)	扩展流检测类型标识Extended flow detection type identification
R(1bit)/Rsv(6bits)/Reversed(16bits)R(1bit)/Rsv(6bits)/Reversed(16bits)	保留字段reserved text

Compared with format one of the IFIT header, format two of the IFIT header has an additional field timestamp: indicating the sending timestamp of the multicast data packet.

The following describes the format of the multicast data message that combines BIERv6 encapsulation and IFIT encapsulation:

Referring to Figure 5, the multicast data message combining BIERv6 encapsulation and IFIT encapsulation can include an IPv6 header, an IPv6 extension header including a BIER header, an IPv6 extension header including an IFIT header, and an IP multicast payload. Corresponding to the multiple possible formats of the IFIT header, the IPv6 extension header containing the IFIT header also has multiple possible formats. In Figure 5, two possible formats are exemplarily shown.

When root node A performs IFIT encapsulation of multicast service data from multicast source A, it adds corresponding values to the L field and D field in the IFIT header to detect performance indicators such as transmission delay and packet loss rate.

The rules for adding values in the L field and D field are explained below.

1. Rules for adding values in the L field:

After receiving the multicast service data sent by multicast source A, root node A determines that the current packet loss detection period is the Eth packet loss detection period. If E is an odd number, the multicast service data is processed again. When performing IFIT encapsulation, add the value "1" to the L field; if E is an even number, add the value "0" to the L field when performing IFIT encapsulation of the multicast service data. In this way, the values of the L field in the multicast data packets sent in adjacent packet loss detection periods can be different, while the values of the L field in the multicast data packets sent in the same packet loss detection period can be the same.

In addition, at the end of the E-th packet loss detection cycle, root node A may also send the cycle identifier of the E-th packet loss detection cycle and the first number of messages corresponding to the E-th packet loss detection cycle to the controller. The number of first packets represents the number of multicast data packets with payloads from multicast source A sent in the E-th packet loss detection cycle.

2. Rules for adding values in the D field (if the value in the D field is 1, it means that the multicast data packet can be used for delay detection):

There are two implementation options for the rules for adding values in the D field:

Solution 1: Set the delay detection period:

After receiving the multicast service data sent by multicast source A, root node A determines whether the multicast service data is the multicast service data received from multicast source A within the current delay detection period. If the currently received multicast service data is the G-th received multicast service data from multicast source A within the current delay detection period, when performing IFIT encapsulation of the multicast service data, in the D field Add the value "1"; if the currently received multicast service data is not the multicast service data received from multicast source A for the Gth time within the current delay detection period, IFIT encapsulation is performed on the multicast service data. When , add the value "0" in the D field. Among them, G is a preset value, such as G=3.

In addition, after root node A forwards the encapsulated multicast data message, if the D field value of the IFIT header in the multicast data message is 1, it will add the cycle identifier of the current delay detection cycle and the The sending timestamp of the multicast data packet is sent to the controller. The period identifier of the delay detection period is used to indicate which delay detection period the corresponding delay detection period is.

Option 2: Do not set the delay detection period:

In the second solution, the IFIT header format may adopt an IFIT header format including a timestamp field, for example, the IFIT header format one shown in Figure 4 or 5.

After receiving the multicast service data sent by multicast source A, when root node A performs IFIT encapsulation of the multicast service data, it adds the value "1" to the D field and adds the sending time to the timestamp field in the IFIT header. stamp. Among them, the added sending timestamp can be the current timestamp obtained when executing IFIT encapsulation, or it can be the sending timestamp obtained by adding the current timestamp obtained when executing IFIT encapsulation plus the preset delay time, and the preset delay time is preset Set the time elapsed from IFIT encapsulation to sending the corresponding multicast data message.

In the second solution, since the IFIT header carries the sending timestamp of the multicast data message, root node A no longer needs to send the sending timestamp of the multicast data message to the controller.

Step 303: The leaf node receives the multicast data message through the first path between the leaf node and the main root node.

For example, after receiving the multicast data message sent by intermediate node A, intermediate node B parses the bit string in the multicast data message and updates the bit string according to the entry in BIFT. The updated Only the bit corresponding to leaf node B in the bit string is 1. Then, the intermediate node B sends the updated multicast data message to the leaf node B through the first path. Furthermore, the leaf node B can receive the multicast data message sent by the intermediate node B through the first path.

Step 304: The leaf node determines the performance index of the first path based on the IFIT header in the multicast data packet received through the first path.

For example, after receiving the multicast data packet, leaf node B determines that the multicast data packet comes from the root node based on the BFIR-ID in the BIER header or the source address in the IPv6 header in the multicast data packet. A. Then, packet loss detection and/or delay detection is performed based on the IFIT header in the multicast data message. The following describes packet loss detection and delay detection respectively:

1. Packet loss detection:

After confirming that the multicast data packet comes from root node A, leaf node B determines that the current packet loss detection period is the Qth packet loss detection period. If Q is an odd number, determine whether the value of the L field in the IFIT header of the multicast data packet is 1. If it is determined that the value of the L field is 1, then determine the number of packets corresponding to the Qth packet loss detection cycle recorded plus one. When Q is an odd number, the number of packets corresponding to the Q-th packet loss detection cycle indicates: the IP multicast payload carried from root node A and carried by the Q-th packet loss detection cycle is from multicast source A, The number of multicast data packets whose L field value is 1. If Q is an even number, determine whether the value of the L field in the IFIT of the multicast data packet is 0. If it is determined that the value of the L field is 0, then add the number of packets corresponding to the recorded Qth packet loss detection period. one. When Q is an even number, the number of packets corresponding to the Q-th packet loss detection cycle indicates: the IP multicast payload carried by root node A and carried from multicast source A has been received in the Q-th packet loss detection cycle. The number of multicast data packets whose L field value is 0.

After the Qth packet loss detection cycle ends, leaf node B can send the currently counted cycle identifier of the Qth packet loss detection cycle and the second number of messages corresponding to the Qth packet loss detection cycle to the controller.

After receiving the cycle identifier and the second message number of the Qth packet loss detection cycle sent by leaf node B, the controller queries the third message number corresponding to the Qth packet loss detection cycle sent by root node A. Then, the controller calculates the number of packet losses on the first path based on the number of second packets and the number of third packets. In addition, the controller can also calculate the packet loss rate based on the calculated number of lost packets and the number of third packets. Then, the controller can send the number of packets lost and/or the packet loss rate corresponding to the Qth packet loss detection cycle to leaf node B.

2. Delay detection:

Depending on whether the IFIT header carries a transmission timestamp, the delay detection method can also be different1.

(1) The IFIT header does not carry the sending timestamp

After leaf node B determines that the multicast data packet comes from root node A, if it determines that the value of the D field in the IFIT header of the multicast data packet is 1, it obtains the reception timestamp of the multicast data packet. And determine that the current delay detection period is the W-th delay detection period. Then, leaf node B sends the obtained reception timestamp and the cycle identifier of the W-th delay detection cycle to the controller.

After receiving the cycle identifier and reception timestamp of the W-th delay detection cycle sent by leaf node B, the controller queries the sending timestamp corresponding to the W-th delay detection cycle sent by root node A. Then, the controller calculates the time difference between the sending timestamp and the receiving timestamp as the first transmission delay of the first path in the W-th delay detection period. In addition, the controller can also obtain the second transmission delay of the first path in the W-1th delay detection period, and calculate the time difference between the first transmission delay and the second transmission delay as the first path's second transmission delay. Delay jitter. Then, the controller may send the calculated first transmission delay and/or delay jitter to the leaf node B.

(2) The IFIT header carries the sending timestamp

After leaf node B determines that the multicast data message comes from root node A, if it determines that the value of the D field in the IFIT header of the multicast data message is 1, it obtains the sending timestamp carried in the IFIT header and obtains The reception timestamp of this multicast data packet. Then, leaf node B calculates the time difference between the sending timestamp and the receiving timestamp as the third transmission delay of the first path. In addition, leaf node B can also obtain the last calculated fourth transmission delay of the first path, and calculate the time difference between the third transmission delay and the fourth transmission delay as the delay jitter of the first path.

In a possible implementation, when the IFIT header carries a transmission timestamp, the controller can also calculate the transmission delay and/or delay jitter of the first path. Correspondingly, in this case, the processing of leaf node B and the controller can be as follows:

After leaf node B determines that the multicast data packet comes from the corresponding main root node (root node A), if it determines that the value of the D field in the IFIT header of the multicast data packet is 1, it obtains the value carried in the IFIT header. Send the timestamp and obtain the reception timestamp of the multicast data packet. Then, leaf node B sends the sending timestamp and receiving timestamp to the controller. After receiving the sending timestamp and receiving timestamp sent by leaf node B, the controller calculates the time difference between the sending timestamp and the receiving timestamp as the third transmission delay of the first path. In addition, the controller can also obtain the last calculated fourth transmission delay of the first path, and calculate the time difference between the third transmission delay and the fourth transmission delay as the delay jitter of the first path. Then, the controller sends the calculated third transmission delay and/or delay jitter to leaf node B.

Step 305: If it is determined that the first path does not meet the performance requirements according to the performance index of the first path, the leaf node receives the multicast data message sent by the backup root node through the second path.

If the leaf node B determines that the first path does not meet the performance requirements based on the performance index of the first path, it can start receiving multicast data packets sent by the root node B through the second path. And strip the BIER MPLS encapsulation or BIERv6 encapsulation of the multicast data packets received through the second path to obtain the corresponding multicast service data. Then, the obtained multicast service data is forwarded to multicast receiving device B. In addition, leaf node B may discard multicast data packets received through the first path. There are many ways for leaf node B to determine whether the first path meets the performance requirements. Several of them are listed below for explanation:

Method 1: Determine whether the first path meets the performance requirements based on the currently obtained performance index of the first path.

For example, when the performance indicator includes the number of packet losses, after leaf node B obtains the number of packet losses of the first path, if it determines that the number of packet losses is greater than the packet loss threshold, it determines that the first path does not meet the performance requirements. For another example, when the performance index includes the packet loss rate, after leaf node B obtains the packet loss rate of the first path, if it determines that the packet loss rate is greater than the packet loss rate threshold, it determines that the first path does not meet the performance requirements. . For another example, when the performance index includes transmission delay, after leaf node B obtains the transmission delay of the first path, if it determines that the transmission delay is greater than the delay threshold, it determines that the first path does not meet the performance requirements. For another example, when the performance index includes delay jitter, after leaf node B obtains the delay jitter of the first path, if it determines that the delay jitter is greater than the jitter threshold, it determines that the first path does not meet the performance requirements.

Method 2: Based on the performance indicators of the first path obtained multiple times in a row, comprehensively determine whether the first path meets the performance requirements.

Method 2 can be implemented in a variety of ways. Two of them are listed below for explanation:

Implementation method one:

For example, when the performance index includes the number of packet losses, after leaf node B obtains the number of packet losses of the first path, it can obtain the number of packet losses of the first path obtained K times consecutively before this time, and Based on the number of packet losses of the first path obtained this time and the number of packet losses of the first path obtained K times before this time, calculate the average number of packet losses. If the average number of packet losses is greater than the packet loss threshold, then determine The first path does not meet performance requirements. For another example, when the performance index includes the packet loss rate, after leaf node B obtains the packet loss rate of the first path, it can obtain the packet loss rate of the first path obtained K times consecutively before this time. And based on the packet loss rate of the first path and the packet loss rate of the first path obtained K times before this time, the average packet loss rate is calculated. If the average packet loss rate is greater than the packet loss rate threshold, the first path is determined Does not meet performance requirements. For another example, when the performance index includes transmission delay, after leaf node B obtains the transmission delay of the first path, it can obtain the transmission delay of the first path obtained K times consecutively before this time. And based on the transmission delay of the first path obtained this time and the transmission delay of the first path obtained K times before this time, the average transmission delay is calculated. If the average transmission delay is greater than the delay threshold, then determine The first path does not meet performance requirements. For another example, when the performance index includes delay jitter, after leaf node B obtains the delay jitter of the first path, it can obtain the delay jitter of the first path obtained K times consecutively before this time. And based on the delay jitter of the first path and the delay jitter of the first path obtained K times before this time, the average delay jitter is calculated. If the average delay jitter is greater than the jitter threshold, it is determined that the first path does not meet the Performance requirements. Among them, K is a positive integer greater than or equal to 1, which can be configured by technicians according to actual needs.

Implementation method two:

For example, when the performance index includes the number of packet losses, after leaf node B obtains the number of packet losses of the first path, it can obtain the number of packet losses of the first path obtained K times consecutively before this time. If The packet loss number of the first path obtained K+1 consecutive times is greater than the packet loss threshold, and it is determined that the first path does not meet the performance requirements. For another example, when the performance index includes the packet loss rate, after leaf node B obtains the packet loss rate of the first path, it can obtain the packet loss rate of the first path obtained K times consecutively before this time. If the packet loss rate of the first path obtained for K+1 consecutive times is greater than the packet loss rate threshold, it is determined that the first path does not meet the performance requirements. For another example, when the performance index includes transmission delay, after leaf node B obtains the transmission delay of the first path, it can obtain the transmission delay of the first path obtained K times consecutively before this time. If the transmission delays of the first path obtained for K+1 consecutive times are greater than the delay threshold, it is determined that the first path does not meet the performance requirements. For another example, when the performance index includes delay jitter, after leaf node B obtains the delay jitter of the first path, it can obtain the delay jitter of the first path obtained K times consecutively before this time. If the delay jitter of the first path obtained for K+1 consecutive times is greater than the jitter threshold, it is determined that the first path does not meet the performance requirements.

Method 3: Determine whether the first path meets the performance requirements based on the performance index of the first path obtained within a single flow switching detection cycle.

Leaf node B can be configured with a flow switching detection period, and the length of this single flow switching detection period can be longer than a single delay detection period and a single packet loss detection period. Leaf node B can collect statistics on the performance indicators obtained during a single flow switching detection cycle. The statistical methods for different performance indicators can be different. For example, if the performance index includes the number of packet losses, then each time a flow switching detection is completed, leaf node B can accumulate the number of packet losses on the first path obtained during the flow switching detection period. For another example, if the performance index includes packet loss rate, then each time a flow switching detection is completed, leaf node B can average the packet loss rate of the first path obtained during the flow switching detection period. For another example, if the performance index includes transmission delay, then each time a flow switching detection is completed, leaf node B can average the transmission delay of the first path obtained during the flow switching detection period. For another example, if the performance index includes delay jitter, then, whenever a flow switching detection is completed, leaf node B can average the delay jitter obtained during the flow switching detection period.

Whenever a flow switching detection is completed, if leaf node B determines that at least one of the performance indicators of the first path obtained from the statistics of the flow switching detection cycle is greater than the corresponding threshold value of the item, it determines that the first path does not meet the performance requirements.

For example, performance indicators include packet loss number, packet loss rate, transmission delay, delay jitter, etc. Each of the packet loss number, packet loss rate, transmission delay, delay jitter, etc. has a corresponding threshold. Whenever a flow switching detection is completed, if leaf node B determines that at least one of the packet loss number, packet loss rate, transmission delay, and delay jitter of the first path counted during the flow switching detection period is greater than the corresponding threshold, Then it is determined that the first path does not meet the performance requirements.

Method 4: Determine whether the first path meets the performance requirements based on the performance indicators of the first path obtained during multiple consecutive flow switching detection cycles.

Whenever a flow switching detection is completed, leaf node B performs statistics on the performance indicators of the first path obtained during the flow switching detection period, and obtains the statistics of Y consecutive flow switching detection periods before the flow switching detection period. Performance indicators of the first path. If leaf node B determines that each of the Y+1 flow switching detection periods has at least one performance index greater than the corresponding threshold, it determines that the first path does not meet the performance requirements. Among them, Y is a positive integer greater than or equal to 1, which can be configured by technical personnel according to actual needs.

Alternatively, whenever a flow switching detection is completed, leaf node B can make statistics on the performance indicators of the first path obtained during the flow switching detection period, and obtain the Y consecutive flow switching detection periods before the flow switching detection period, respectively. The performance indicators of the first path obtained by statistics. Then, leaf node B performs comprehensive statistics on the performance indicators obtained from the Y+1 flow switching detection cycles. If at least one of the performance indicators obtained by comprehensive statistics of Y+1 flow switching detection cycles is greater than the corresponding threshold of the item, it is determined that the first path does not meet the performance requirements. The following is an example of the above “comprehensive statistics”.

For example, if the performance index includes the number of lost packets, leaf node B can accumulate the number of lost packets obtained from Y+1 flow switching detection cycles. For another example, if the performance index includes the packet loss rate, then leaf node B can average the packet loss rates obtained from Y+1 flow switching detection cycles. For another example, if the performance index includes transmission delay, then leaf node B can average the transmission delays obtained from Y+1 flow switching detection cycles. For another example, if the performance index includes delay jitter, then leaf node B can average the delay jitter obtained by counting Y+1 consecutive flow switching detection cycles.

Optionally, for the second path between the backup root node and the leaf node, the leaf node can also determine the performance index of the second path. The specific determination method is the same as the method of determining the performance index of the first path in steps 301-304 above. are the same and will not be repeated here. In addition, determining the performance index of the second path and determining the performance index of the first path may be performed simultaneously.

In this case, before the above step 305 is performed, the following steps may be performed: determine whether the performance indicated by the performance index of the second path is better than the performance indicated by the performance index of the first path. If the performance of the second path is better If the performance of the first path is insufficient, step 305 is continued.

For example, leaf node B determines the performance index of the first path and determines the performance index of the second path. If it is determined that each item in the performance index of the second path is smaller than the performance index of the first path, it is determined that the performance of the second path is better than the performance of the first path.

Optionally, in order to avoid frequent switching between receiving the multicast data stream from the primary root node and receiving the multicast data stream from the backup root node, the following steps can also be performed after performing step 305: Determine the second path Whether the performance indicators meet the performance requirements. If the performance indicators of the second path do not meet the performance requirements, after the first period of time, the multicast data packets received through the first path will be re-received, and the multicast data received through the first path will be processed. The message strips off the BIER MPLS encapsulation or BIERv6 encapsulation, obtains the corresponding multicast service data, and forwards the obtained multicast service data to the corresponding multicast receiving device. Among them, the first duration can be pre-configured in the leaf node by technicians according to actual needs.

Optionally, if within the second period of time, the number of times a leaf node switches between receiving multicast data packets through the first path and receiving multicast data through the second path reaches the alarm threshold, the leaf node reports to the network management device. Alarm information, for example, the second duration is 1 hour and the alarm threshold is 5. The alarm information is used to indicate that both the first path and the second path are faulty, so as to prompt relevant personnel to locate and repair the fault as soon as possible. Both the second duration and the alarm threshold can be pre-configured in the leaf nodes by technicians based on actual needs.

Optionally, the controller may also present a first path between the main root node and the leaf nodes, and a second path between the backup root node and the leaf nodes. After receiving the alarm signal reported by the leaf node, relevant personnel can quickly locate the fault and perform repairs through the overlap between the first path and the second path presented by the controller.

Combining IFIT technology to realize multicast data flow switching, only the IFIT detection related processing is performed on the root node and leaf node, without the participation of intermediate nodes, and IFIT detection is based on the actual multicast data flow, and the performance indicators obtained by the detection are more accurate. .

Method 2 for determining performance indicators: Obtain the performance indicators of the path based on the enhanced media delivery quality index (EMDI) technology:

Referring to Figure 6, when Method 2 is used to determine performance indicators, the processing flow of multicast data message sending in the embodiment of the present application may include the following steps. The following is combined with the implementation scenario shown in Figure 2, with root node A as leaf node B. The main root node of , root node B is the backup root node of leaf node B as an example. The steps shown in Figure 3 are explained:

Step 401: Enable the EMDI detection function on the main root node and leaf nodes.

In order to implement EMDI detection, the EMDI detection function can be configured on root node A and leaf node B in advance. For example, root node A receives an EMDI detection command. The EMDI detection command may include multicast source information. The multicast source information is used to instruct the primary root node to perform EMDI detection on the multicast service data of multicast source A. In this way, after root node A receives the multicast service data sent by multicast source A, when performing BIER MPLS encapsulation or BIERv6 encapsulation of the multicast service data, it can add the value "1" to the specified bit in the BIER header. To indicate that the corresponding multicast data packet can be used for EMDI detection. The specified bit may be any unused bit in the Operation and Maintenance (OAM) field or the Reserved (RSV) field in the BIER header. Leaf node B receives the EMDI detection command and enables the EMDI detection function. In this way, after leaf node B receives a multicast data packet with the specified bit in the BIER header being 1, it can perform EMDI detection based on the multicast data packet. It should be noted that the above-mentioned EMDI detection instructions can be implemented by a configuration issued by a controller (controller) or configured statically. When the controller issues the configuration, the EMDI detection instructions can be issued based on the network configuration protocol (network configuration protocol, NETCONF), simple network management protocol (simple network management protocol), etc. In addition, when implemented based on NETCONF, NETCONF combined with the YANG model can be used to implement the issuance of EMDI detection instructions.

Step 402: The primary root node forwards the multicast data packet through the first path, where the multicast data packet includes a Real-time Transport Protocol (RTP) header and/or a transport stream (TS) head.

For example, the multicast service data sent by multicast source A to root node A may be encapsulated based on the RTP protocol and/or TS protocol. Then, the data received by root node A and root node B includes the RTP header and/or TS. multicast service data in the header. Root node A receives multicast service data from multicast source A. Then, BIER MPLS encapsulation or BIERv6 encapsulation is performed on the received multicast service data to obtain the multicast data message. In this way, the obtained multicast data message includes a BIER header, an RTP header (and/or a TS header). After completing the encapsulation, root node A forwards the obtained multicast data message to intermediate node A through the first path according to the saved entry in BIFT.

Referring to Figure 7, a format of a multicast data message based on BIER MPLS encapsulation and including an RTP header but not a TS header is shown, including an Ethernet header, a BIER header and an IP multicast payload, where the IP multicast payload includes the Internet Protocol (internet protocol) header, user datagram protocol (UDP) header/transmission control protocol (TCP) header, payload and cyclic redundancy check (CRC) data. Referring to Table 2, the RTP header can include the following fields:

Table 2

Referring to Figure 8, a format of a multicast data message based on BIERv6 encapsulation and including an RTP header but not a TS header is shown. In this case, the format of the RTP header is the same as the format of the RTP header in Figure 7. Here No longer.

Referring to Figure 9, a format of a multicast data message based on BIER MPLS encapsulation that includes a TS header but does not include an RTP header is shown. Usually, a multicast data message can include multiple TS packets (packets). Each TS packet includes a TS header and payload. Referring to Table 3, the TS header can include the following fields:

table 3

字段Field	描述describe
sync_bytesync_byte	同步字节sync byte
transport_error_indicatortransport_error_indicator	传输错误指示信息Transmission error indication information
payload_unit_start_indicatorpayload_unit_start_indicator	净荷单元起始指示Payload unit start indication
transport_prioritytransport_priority	传输优先级Transmission priority
PIDPID	Packet标识号码Packet identification number
transport_scrambling_controltransport_scrambling_control	传送加扰控制transmission scrambling control
adaptation_field_controladaptation_field_control	自适应字段控制Adaptive field control
continuity_countercontinuity_counter	连续计数器Continuous counter
adaptation_fieldadaptation_field	自适应字段adaptive fields

Referring to Figure 10, a format of a multicast data message based on BIERv6 encapsulation and including a TS header but not an RTP header is shown. In this case, the format of the TS header is the same as the format of the TS header in Figure 9. Here No longer.

Referring to Figure 11, a format of a multicast data message based on BIER MPLS encapsulation and including an RTP header and a TS header is shown. In this case, the format of the TS header is the same as the format of the TS header in Figure 9. The RTP header The format is the same as the format of the RTP header shown in Figure 7, and will not be described again here.

Referring to Figure 12, a format of a multicast data message based on BIERv6 encapsulation and including an RTP header and a TS header is shown. In this case, the format of the TS header is the same as the format of the TS header in Figure 9. The RTP header The format is the same as the format of the RTP header shown in Figure 7, and will not be described again here.

Step 403: The leaf node receives the multicast data message through the first path between the leaf node and the main root node.

Step 404: The leaf node determines the performance index of the first path based on the RTP header or TS header in the multicast data packet received through the first path.

The following explains how to determine the performance indicators of the first path based on the RTP header:

1. Determine the number of packets lost and the packet loss rate

After leaf node B receives the multicast data packet through the first path, it determines that the value of the specified bit in the BIER header is 1, indicating that EMDI detection is to be performed on the multicast data packet. Leaf node B obtains the first sequence number in the RTP header of the multicast data message, and obtains the second sequence number in the RTP header of the previous multicast data message received through the first path. Leaf node B calculates the absolute value of the difference between the first sequence number and the second sequence number, and then subtracts one from the calculated absolute value of the difference to obtain the number of lost packets between the two multicast data packets. Among them, the multicast data packet received through the first path refers to the multicast data packet sent by the main root node (root node A) and the IP multicast payload comes from multicast source A.

In addition, leaf node B can also be configured with a flow switching detection period. Whenever a flow switching detection period ends, leaf node B counts the total number of lost packets of multicast data packets received through the first path during the flow switching detection period, and obtains the actual number of packets lost through the first path during the flow switching detection period. The actual number of multicast data packets received. Then, the sum of the above total number of lost packets and the above actual number of packets is calculated as the expected number of multicast data packets expected to be received through the first path during the flow switching detection period. Then, by calculating the ratio of the total number of packets lost to the expected number of packets, the packet loss rate of the first path within the flow switching detection period can be obtained.

2. Determine the out-of-order number and out-of-order rate:

Combined with the above process of determining the number of packets lost and the packet loss rate, after leaf node B obtains the first sequence number in the RTP header of the multicast data message, it obtains the multicast data received through the first path during the current flow switching detection period. The maximum sequence number carried in the packet is compared with the size of the first sequence number and the maximum sequence number. If the first sequence number is smaller than the maximum sequence number, it is determined that there is disorder, and the flow is switched to detect the disorder of the first path in the cycle. Count plus one. When a flow switching detection cycle ends, calculate the ratio of the number of out-of-order packets on the first path in the flow switching detection cycle to the number of expected packets, and then the out-of-order rate of the first path in the flow switching detection cycle can be obtained.

The following explains how to determine the performance index of the first path based on the TS header:

1. Determine the number of packets lost and the packet loss rate

After leaf node B receives the multicast data packet through the first path, it determines that the value of the specified bit in the BIER header is 1, indicating that EMDI detection is to be performed on the multicast data packet. Leaf node B sequentially obtains and records the first count value of the continuity_counter field in the TS header of the multicast data packet (the count value may also be called the sequence number). Here, the order of acquisition can be: the order of TS headers in the multicast data packet from front to back. In the multicast data packet, the TS headers in the front are leafed out before the TS headers in the back. Node B receives it. Then, obtain the second count value of the TS in the previous TS packet received through the first path, and calculate the absolute value of the difference between the first count value and the second count value to obtain the loss ratio between the two TS packets. Number of packages. Among them, the previous TS packet received through the first path may belong to the same multicast data packet as the TS packet where the first count value is located, or may belong to different multicast data packets. The TS packet received through the first path refers to the TS packet sent by multicast source A and entering the BIER domain with the main root node (root node A) as the BIER entry router.

Whenever a flow switching detection period ends, leaf node B counts the total number of packet losses of TS packets received through the first path during the flow switching detection period, and obtains the actual number of TS packets received through the first path during the flow switching detection period. The actual number of packages. Then, the sum of the total number of lost packets and the actual number of packets is calculated as the expected number of TS packets expected to be received through the first path during the flow switching detection period. Then, by calculating the ratio of the total number of packets lost and the number of expected packets, the packet loss rate of the first path within the flow switching detection period can be obtained.

2. Determine the out-of-order number and out-of-order rate

Leaf node B sequentially obtains and records the first count value of the continuity_counter field in the TS header of the multicast data packet. Whenever the first count value in a TS header is obtained and recorded, the maximum count value in the TS header received through the first path within the current stream switching detection period is obtained. Compare the first count value and the maximum count value. If the first count value is less than the maximum count value, it is determined that there is an out-of-order sequence, and the out-of-order number of the first path in the flow switching detection period is increased by one. When a flow switching detection period ends, the ratio of the number of out-of-order packets on the first path in the flow switching detection period and the number of expected packets is calculated to obtain the out-of-order rate of the first path in the flow switching detection period.

Step 405: If it is determined that the first path does not meet the performance requirements according to the performance index of the first path, the leaf node receives the multicast data message sent by the backup root node through the second path.

Method 1: Whenever a flow switching detection period ends, if leaf node B determines that at least one of the performance indicators of the first path during the flow switching detection period is greater than the corresponding threshold, it determines that the first path does not meet the performance requirements. need.

For example, performance indicators include packet loss number, packet loss rate, out-of-order number, out-of-order rate, etc. Each of the number of packet loss, packet loss rate, out-of-order number, out-of-order rate, etc. has a corresponding threshold. Whenever a flow switching detection is completed, if leaf node B determines that at least one of the packet loss number, packet loss rate, out-of-order number, and out-of-order rate of the first path counted during the flow switching detection cycle is greater than the corresponding threshold, Then it is determined that the first path does not meet the performance requirements.

Method 2: Whenever a flow switching detection is completed, leaf node B calculates the performance index of the first path obtained during the flow switching detection period, and obtains the Y consecutive flow switching detection periods before the flow switching detection period, respectively. The calculated performance index of the first path. If leaf node B determines that each of the Y+1 flow switching detection periods has at least one performance index greater than the corresponding threshold, it determines that the first path does not meet the performance requirements.

Alternatively, whenever a flow switching detection is completed, leaf node B can calculate the performance index of the first path obtained during the flow switching detection period, and obtain the Y consecutive flow switching detection periods before the flow switching detection period, respectively. The calculated performance index of the first path. Then, leaf node B performs comprehensive statistics on the performance indicators obtained from the Y+1 flow switching detection cycles. If at least one of the performance indicators obtained by comprehensive statistics of Y+1 flow switching detection cycles is greater than the corresponding threshold of the item, it is determined that the first path does not meet the performance requirements. The following is an example of the above “comprehensive statistics”.

For example, if the performance index includes the number of packet losses, then leaf node B can calculate the average of the number of packet losses obtained from Y+1 flow switching detection cycles. For another example, if the performance index includes the packet loss rate, then leaf node B can average the packet loss rates calculated separately in Y+1 flow switching detection cycles. For another example, if the performance index includes the out-of-order number, then leaf node B can accumulate the out-of-order numbers calculated separately in Y+1 flow switching detection cycles. For another example, if the performance index includes the out-of-order rate, then leaf node B can average the out-of-order rates calculated for Y+1 consecutive flow switching detection cycles.

Optionally, for the second path between the backup root node and the leaf node, the leaf node can also determine the performance index of the second path. The specific determination method is the same as the method of determining the performance index of the first path in steps 401-404 above. are the same and will not be repeated here. In addition, determining the performance index of the second path and determining the performance index of the first path may be performed simultaneously.

In this case, before performing the above-mentioned step 405, the following steps may be performed: determine whether the performance indicated by the performance index of the second path is better than the performance indicated by the performance index of the first path. If the performance of the second path is better, If the performance of the first path is insufficient, step 405 is continued.

Optionally, in order to avoid frequent switching between receiving the multicast data stream from the primary root node and receiving the multicast data stream from the backup root node, the following steps can also be performed after performing step 405: Determine the second path Whether the performance indicators meet the performance requirements. If the performance indicators of the second path do not meet the performance requirements, after the first period of time, the multicast data packets received through the first path will be re-received, and the multicast data received through the first path will be processed. The message strips off the BIER MPLS encapsulation or BIERv6 encapsulation, obtains the corresponding multicast service data, and forwards the obtained multicast service data to the corresponding multicast receiving device. Among them, the first duration can be pre-configured in the leaf node by technicians according to actual needs.

Combining EMDI technology to realize multicast data flow switching, only the root node and leaf nodes need to perform EMDI detection-related processing without the participation of intermediate nodes.

Method 3 for determining performance indicators: Intermediate node statistics and the number of lost packets on the link between upstream nodes are carried by the multicast data packet to the leaf node. The leaf node obtains the root node and the number of lost packets carried in the multicast data packet. The number of lost packets on the first path between leaf nodes.

Referring to Figure 13, when method three is used to determine the performance index, the processing flow of multicast data message sending in the embodiment of the present application may include the following steps. The following is combined with the implementation scenario shown in Figure 2, with root node A as leaf node B. The main root node of , root node B is the backup root node of leaf node B as an example. The steps shown in Figure 13 are explained:

Step 501: The main root node sends the multicast data message through the first path.

For example, after receiving the multicast service data sent by multicast source A, root node A encapsulates the multicast service data to obtain the first multicast data message. Then, the root node A forwards the first multicast data message to the intermediate node A through the first path according to the saved entry in the BIFT.

Specifically, root node A can perform BIER MPLS encapsulation or BIERv6 encapsulation on the received multicast service data to obtain the first multicast data message, which includes a BIER header. When root node A performs BIER MPLS encapsulation or BIERv6 encapsulation, it adds an initial value to the field used to carry the number of lost packets in the BIER header. The initial value can also be different depending on the field used to carry the number of lost packets. In the following description The initial values added to the different fields carrying the number of lost packets will be explained. The following describes the fields used to carry the number of lost packets in the BIER header under the two types of encapsulation.

1. BIER MPLS encapsulation:

Referring to Figure 14, a BIER header format under BIER MPLS encapsulation is shown. Referring to Table 4, the BIER header can include the following fields:

Table 4

When BIER MPLS encapsulation is used, the BIER header needs to be extended to carry the number of lost packets in the extension field. For example, as shown in Figure 14, 4 bytes can be extended in front of the bit string field, and multiple bits can be selected from the extended 4 bytes to carry the number of packet loss. For example, the last one or two bytes among these four bytes can be selected to carry the packet loss number. When one of the bytes is selected to carry the number of lost packets, in order to express a larger number of lost packets, the actual number of lost packets can be divided by the specified coefficient and rounded, and then carried in this byte. Among them, the specified coefficient can be configured by technicians according to actual needs. For example, the specified coefficient is 20.

2. BIERv6 encapsulation:

Referring to Figure 15, a multicast data message format under BIERv6 encapsulation is shown. The BIERv6 encapsulated multicast data message mainly consists of an IPv6 header, an IPv6 extension header including a BIER header, and an IP multicast payload. Referring to Table 5, the following fields can be included in the IPv6 header:

table 5

字段Field	描述describe
versinVersin	版本Version
traffic classtraffic class	流类型stream type
flow labelflow label	流标签stream tag
payload lengthpayload length	净荷长度Payload length
next heardernext hearder	下一个头next head
hop limithop limit	跳数限制Hop limit
source addresssource address	源地址source address
destination addressdestination address	目的地址Destination address

The IPv6 extension header can include the BIER header and the fields shown in Table 6 below:

Table 6

字段Field	描述describe
Next headerNext header	下一个头next head
Hdr Ext LenHdr Ext Len	选项报头的长度The length of the options header
option typeoption type	选项类型option type
option lengthoption length	选项长度option length

When using BIERv6 encapsulation, you can select TC+S+TTL or entropy or BFIR-ID to carry the number of lost packets.

For example, a total of 12 bits of TS+S+TTL can be used to carry the actual number of lost packets. For another example, S+TTL can be used to identify the number of lost packets. When S is 0, the TTL value represents the actual number of packets lost; when S is 1, the TTL value multiplied by the specified coefficient represents the actual number of packets lost. For example, the specified coefficient may be 20. As another example, 20 bits of Entropy can be used to carry the actual number of lost packets. For another example, 16 bits of BFIR-ID are used to carry the actual number of lost packets.

When root node A performs BIER MPLS encapsulation or BIERv6 encapsulation, except for the S field, the initial values of the other fields used to carry the number of lost packets can be 0. For the S field, if configured to carry the actual number of lost packets, , then set the initial value of the S field to 0. If configured not to carry the actual number of lost packets, set the initial value of the S field to 1.

Step 502: The intermediate node records the number of lost packets on the link between the intermediate node and the upstream node.

Among them, the upstream node may be an intermediate node or a root node.

For example, the incoming interface of intermediate node A performs Cyclic Redundancy Check (CRC) on received packets (including multicast data packets, unicast packets, etc.), and counts the incoming interface based on the check results. Corresponding to the number of packet losses on the link, the number of packet losses counted for each incoming interface is always accumulated. For each incoming interface, whenever a statistical period is reached, the multicast service module of intermediate node A obtains the current statistical first packet loss number from the incoming interface, and calculates the first packet loss number and the number obtained in the previous statistical period. The difference between the second number of lost packets counted by the incoming interface is obtained to obtain the new number of lost packets on the incoming interface. Then, the multicast service module sends the new packet loss number of the incoming interface to the forwarding chip of the intermediate node. The forwarding chip records the number of new lost packets on the incoming interface. Among them, the multicast service module is a software module that performs multicast services.

Similarly, the incoming interface of intermediate node B also performs Cyclic Redundancy Check (CRC) on the received packets (including multicast data packets, unicast packets, etc.), and counts the incoming packets based on the check results. The number of packet losses for the link corresponding to the interface. The number of packet losses counted for each incoming interface is always accumulated. For each incoming interface, whenever a statistical period is reached, the multicast service module of intermediate node B obtains the current third packet loss number from the incoming interface, and calculates the third packet loss number and the number obtained in the previous statistical period. The difference between the fourth number of lost packets counted by the incoming interface is obtained, and the new number of lost packets on the incoming interface is obtained. Then, the multicast service module sends the new packet loss number of the incoming interface to the forwarding chip of the intermediate node. The forwarding chip records the number of new lost packets on the incoming interface.

In addition, leaf node B also records the number of packet losses in the link with the upstream node (intermediate node B) according to the processing of step 502.

Step 503: The intermediate node receives the multicast data packet, and updates the value in the field used to carry the number of lost packets in the BIER header of the multicast data packet.

For example, intermediate node A receives the first multicast data packet through the first incoming interface. Then, the forwarding chip of intermediate node A queries whether the number of new packet losses on the first incoming interface is recorded. If the number of new packet losses on the first incoming interface is recorded, the number of new lost packets on the first incoming interface is recorded. The number is accumulated into the field used to carry the packet loss number in the BIER header of the first multicast data packet to obtain the second multicast data packet. In addition, the forwarding chip pair deletes the recorded number of new packet losses on the first incoming interface. Then, the intermediate node A sends the second multicast data message to the intermediate node B according to the entry in the BIFT.

The intermediate node B receives the second multicast data message through the second incoming interface. Then, the forwarding chip of intermediate node B queries whether the number of new packet losses on the second incoming interface is recorded. If the number of new packet losses on the second incoming interface is recorded, the recorded number of new packet losses on the second incoming interface is recorded. The number is accumulated into the field used to carry the number of lost packets in the BIER header of the second multicast data packet to obtain the third multicast data packet. In addition, the forwarding chip pair deletes the recorded number of new packet losses on the first incoming interface. Then, the intermediate node A sends the third multicast data message to the leaf node B according to the entry in the BIFT.

It should be noted that if the BIER header carries the actual number of lost packets, the newly queried number of lost packets can be directly accumulated into the field used to carry the number of lost packets in the BIER header; if the BIER header carries the number of packets lost, divide by the specified For the number of lost packets after the coefficient, the newly queried number of lost packets must be divided by the specified coefficient and rounded up, and then accumulated into the field used to carry the number of lost packets in the BIER header.

Step 504: The leaf node receives the multicast data message through the first path, and determines the number of lost packets on the first path based on the number of lost packets carried in the BIER header of the multicast data message.

For example, leaf node B receives the third multicast data packet through the third incoming interface. Obtain the number of lost packets carried in the BIER header of the third multicast data packet, and query the number of new lost packets on the third incoming interface. Based on the number of lost packets carried and the number of new lost packets queried, determine the first The number of packet losses on the path. In addition, after calculating the number of packet losses on the first path, the recorded number of new packet losses on the third incoming interface can be deleted. Specifically, if the BIER header carries the actual number of lost packets, the carried number of lost packets and the newly queried number of lost packets can be directly added together as the number of lost packets on the first path; if the BIER header carries the number of lost packets divided by the specified For the number of lost packets after the coefficient, you can add the number of lost packets carried and the new number of lost packets queried, and then multiply them by the specified coefficient to obtain the number of lost packets on the first path.

In a possible implementation, leaf node B can be configured with a flow switching detection period, and accordingly, leaf node B can count the number of packet losses on the first path according to the flow switching detection period.

For example, each time leaf node B receives a multicast data packet through the third incoming interface, it obtains and records the first packet loss number carried in the BIER header of the multicast data packet. Whenever a flow switching detection period ends, the first number of packet losses recorded in the flow switching detection period and the new second number of packet losses recorded in the third reception period recorded in the flow switching detection period are added to obtain the Number of packets lost on the first path during the flow switching detection period. In addition, after calculating the number of packet losses on the first path, the recorded number of newly added packet losses on the third incoming interface can be deleted.

Step 505: If the performance of the first path does not meet the performance requirements, the leaf node receives the multicast data packet sent by the backup root node through the second path.

For example, when the flow switching detection period is not configured on leaf node B, the method for determining whether the performance of the first path meets the performance requirements can be as follows:

After obtaining the packet loss number of the first path, leaf node B determines that the packet loss number is greater than the packet loss threshold, and then determines that the first path does not meet the performance requirements.

Alternatively, after leaf node B obtains the number of packet losses of the first path, it can obtain the number of packet losses of the first path calculated K times consecutively before this time. And based on the number of packet losses of the first path calculated this time and the number of packet losses of the first path calculated K times before this time, the average number of packet losses is calculated. If the average number of packet losses is greater than the packet loss threshold, it is determined that the first path does not meet the performance requirements.

When leaf node B is configured with a flow switching detection period, the method to determine whether the performance of a path meets the performance requirements can be as follows:

Whenever a flow switching detection period ends, leaf node B calculates the number of packets lost on the first path during the flow switching detection period. If it is determined that the number of packets lost is greater than the packet loss threshold, it is determined that the first path does not meet the performance requirements.

Or, whenever a flow switching detection period ends, leaf node B calculates the number of packet losses on the first path during the flow switching detection period, and obtains the calculated number of consecutive Y flow switching detection periods before the flow switching detection period. Number of lost packets on the first path. Then, leaf node B calculates the average number of packet losses based on the number of packet losses calculated during Y+1 flow switching detection cycles. If the average number of packet losses is greater than the packet loss threshold, it is determined that the first path does not meet the performance requirements.

Or, whenever a flow switching detection period ends, leaf node B calculates the number of packet losses on the first path during the flow switching detection period, and obtains the Y consecutive flow switching detection periods before the flow switching detection period and calculates them respectively. The number of packet losses on the first path. If the number of packet losses calculated during these Y+1 flow switching detection cycles is greater than the packet loss threshold, it is determined that the first path does not meet the performance requirements.

In this case, before executing step 505 above, the following steps may be performed: determine whether the performance of the second path is better than the performance of the first path, and if the performance of the second path is better than the performance of the first path, continue execution. Step 505.

For example, leaf node B determines the number of packet losses on the first path and determines the number of packet losses on the second path. If it is determined that the number of packet losses of the second path is less than the number of packet losses of the first path, it is determined that the performance of the second path is better than the performance of the first path.

Optionally, in order to avoid frequent switching between receiving the multicast data stream from the primary root node and receiving the multicast data stream from the backup root node, the following steps can also be performed after performing step 505: Determine the second path Whether the performance indicators meet the performance requirements. If the performance indicators of the second path do not meet the performance requirements, after the first period of time, the multicast data packets received through the first path will be re-received, and the multicast data received through the first path will be processed. The message strips off the BIER MPLS encapsulation or BIERv6 encapsulation, obtains the corresponding multicast service data, and forwards the obtained multicast service data to the corresponding multicast receiving device. Among them, the first duration can be pre-configured in the leaf node by technicians according to actual needs.

Combined with the multicast data flow switching implemented by method three of determining performance indicators, multicast data packets are used as the carrier of performance indicators. The performance indicators of the path between the root node and the leaf node are calculated from all the messages transmitted on the path. These packets include not only multicast data packets but also unicast packets, which can detect path failures in a more timely manner and switch multicast data flows in a timely manner.

In a possible implementation, in order to avoid faulty links as much as possible after multicast data flow switching, when planning the first path and the second path, there can be no connection between the first path and the second path. Same link. There are many specific planning methods, some of which are listed below for explanation:

Method 1: When planning the first path between a leaf node and the main root node and the second path to the backup root node, you can configure it on each node in the BIER domain one by one. During the configuration, specify the destination node as the leaf node. The outbound interface and next hop destination address for forwarding multicast data packets. Through such hop-by-hop configuration, the first path and the second path can be strictly planned so that the two paths do not have the same link.

Method 2: You can specify a path between the main root node and leaf nodes and a second path between the backup root node and leaf nodes on the controller interface, and uniformly issue configurations to each node on the path through the controller.

The controller uniformly specifies paths and automatically delivers configurations, making it more operable and deployable for users.

Method 3: The network topology of the BIER domain can be collected by the controller. The controller automatically calculates the path based on the network topology, the location of the main root node, the location of the backup root node, and the location of the leaf nodes. When calculating the path, the first path and the second path are constrained. The same link does not exist. Then, configure the calculated first path and the second path to each node that the path passes through through automatic configuration.

Method 4: Implemented through flexible algorithm (FlexAlgo).

Create two non-overlapping FlexAlgo slices in the network topology of the BIER domain. One FlexAlgo slice carries multicast data packets from the main root node to the leaf nodes. That is, the first path between the main root node and the leaf nodes belongs to this FlexAlgo slice. Another FlexAlgo slice carries multicast data packets from the backup root node to the leaf nodes. That is, the second path between the backup root node and the leaf nodes belongs to this FlexAlgo slice.

When creating each FlexAlgo slice, you can set the metric type (Metric-Type), calculation type (Calc-Type) and constraints (constraint). Among them, Metric-Type represents the metric value when calculating paths in FlexAlgo slices, such as delay, cost, etc. Calc-Type represents the algorithm used when calculating paths in FlexAlgo slices, such as the Shortest Path First (SPF) algorithm. Constraint can be a link constraint, which restricts the links included in FlexAlgo slices. Below combined with Figure 16, two FlexAlgo slicing examples are listed:

1. Definition of FlexAlgo slice 128 (Definition of Flex-Algo 128):

Metric-type: cost;

Calc-Type: SPF;

Constraint: includes link 1, link 2, link 3, link 4, link 5, link 6, and link 7 in Figure 16;

2. Definition of Flex-Algo 129:

metric type: delay;

calc-type: SPF;

constraint: includes link 11, link 12, link 13, link 14, link 15, link 16, and link 17 in Figure 16;

The above two FlexAlgo slices do not contain the same link, so the first path and the second path respectively calculated on the topology of the two FlexAlgo slices do not contain the same link.

The embodiment of the present application also provides a method for sending multicast data messages. In this method, two adjacent nodes in the BIER domain can detect the performance indicators of each connected link, and calculate the performance of a certain link. When the indicator does not meet the performance requirements, multicast data packets will not be forwarded through the link. In addition, even if it is detected that the performance indicator of the link does not meet the performance requirements, the interface corresponding to the link on the upstream node does not need to be closed. In this way , which can not only not affect the forwarding of unicast data packets through this interface, but also meet the SLA requirements of multicast data packets.

Depending on the execution subject that determines whether the performance indicators meet the performance requirements, the execution steps of this method may also be different.

Method 1: Use the upstream node as the execution subject to determine whether the performance indicators meet the performance requirements. Combined with the implementation scenario shown in Figure 2, the upstream nodes can be other nodes in the BIER domain except leaf node A, leaf node B, leaf node C and leaf node D, and the downstream nodes can be other nodes in the BIER domain except root node A and root node Nodes other than B. For example, if the upstream node is root node A, then the corresponding downstream node is intermediate node A; for another example, if the upstream node is intermediate node A, then the corresponding downstream node is intermediate node B; for another example, if the upstream node is intermediate node B, then The corresponding downstream node is leaf node B.

Referring to Figure 17, referring to Figure 17, the method may include the following processing steps:

Step 901: The downstream node detects the performance index of the link between the upstream node and the downstream node, and reports the detected performance index to the upstream node.

Among them, the downstream node can be an intermediate node or a leaf node, and the upstream node can be a root node or an intermediate node. The performance indicators may include at least one of packet loss rate, transmission delay, delay jitter, out-of-order, etc.

In the implementation, when there are multiple equal-cost paths between the upstream node and the downstream node, the downstream node can use the Bidirectional Forwarding Detection (BFD) to periodically detect and detect the equal-cost paths between the upstream nodes. Performance. Then, the performance indicators of each detected equal-cost path are reported to the upstream node through the corresponding interface.

When there is an ETH-Trunk bundled interface between the upstream node and the downstream node, the downstream node can periodically detect the performance indicators of the links where each member interface of the ETH-Trunk bundled interface is located through BFD. Then, the detected performance indicators are reported to the upstream node through the corresponding member interface.

When reporting performance indicators, the performance indicators can be carried in BFD messages and reported to the upstream node.

Step 902: The upstream node determines whether the received performance indicators meet the performance requirements.

In the implementation, after the upstream node receives the performance indicator, it determines whether the performance indicator meets the performance requirements. For example, performance indicators include packet loss rate, transmission delay, delay jitter, out-of-order, etc. Each performance indicator corresponds to a threshold. If the performance indicator is greater than the corresponding threshold, it is determined that the performance indicator does not meet the performance requirements.

Step 903: When forwarding multicast data packets, the upstream node avoids links that do not meet performance requirements.

In the implementation, when there are multiple equal-cost paths between the upstream node and the downstream node, the upstream node can query multiple outbound interfaces when forwarding multicast data packets, and each outbound interface corresponds to an equal-cost path. The upstream node determines whether among the multiple interfaces queried, there is an outbound interface whose link does not meet the performance requirements. If it is determined that there is an outbound interface whose link does not meet the performance requirements, then among the outbound interfaces other than the outbound interface, Select an outbound interface as the outbound interface for sending multicast data packets.

When there is an ETH-Trunk bundled interface between the upstream node and the downstream node, when the upstream node forwards multicast data packets, if the outbound interface is queried to be an ETH-Trunk bundled interface, it will determine the ETH-Trunk bundled interface. Among the member interfaces, is there a member interface whose link does not meet the performance requirements? If it is determined that the link of a certain member interface does not meet the performance requirements, select a member interface among the member interfaces other than the member interface as The outbound interface for multicast data packets.

Method 2: Use the downstream node as the execution subject to determine whether the performance indicators meet the performance requirements.

Referring to Figure 18, the method may include the following processing steps:

Step 1001. Detect downstream nodes and perform performance indicators of links between upstream nodes.

Step 1002: The downstream node determines that the link does not meet the performance requirements, and sends link failure indication information to the upstream node through the link.

Among them, the link fault indication information is used to indicate that the link does not meet the performance requirements.

In the implementation, the downstream node determines whether the link meets the performance requirements based on the detected performance indicators. When it is determined that the link does not meet the performance requirements, link failure indication information is sent to the upstream node through the link. Specifically, the link failure indication information can be carried in the BFD message and reported to the upstream node.

Step 1003: When forwarding multicast data packets, the upstream node avoids links that do not meet performance requirements.

It should be noted that the method of detecting performance indicators in step 1001 is the same as the method of detecting performance indicators in step 901. The method of judging whether the performance requirements are met in step 1002 is the same as the method of judging whether the performance requirements are met in step 902. The processing of step 1003 is the same as that of step 903. The processing is the same and will not be described again here.

Through the above method, there is no need to change the status of the interface, but only avoid links that do not meet performance requirements when forwarding multicast data packets. This can meet the SLA requirements of multicast services without affecting unicast services.

Based on the same technical concept, the embodiment of the present application also provides a device for sending multicast data messages. The device 1900 can be applied to the above-mentioned leaf node B as shown in Figure 2. As shown in Figure 19, the Device 1900 includes:

The receiving module 1910 is configured to receive the first multicast data message through the first path. The first multicast data message includes a first parameter, and the first parameter is used to detect performance indicators; specifically, the above step 303 can be implemented. , the receiving function in 403, 504, and other implicit steps.

The acquisition module 1920 is used to obtain the first performance index according to the first parameter; specifically, the acquisition function in the

above steps

304, 404, and 504 can be implemented, as well as other implicit steps.

The receiving module 1910 is also configured to determine that the first path does not meet the performance requirements based on the first performance index, and receive the second multicast data message through the second path. Specifically, the acquisition functions in the

above steps

305, 405, and 505 can be implemented, as well as other implicit steps.

In a possible implementation manner, the first multicast data message includes a BIER header and an IFIT header, and the IFIT header is used to carry the first parameter.

In a possible implementation, the first multicast data message includes a BIER header and an RTP header, and the RTP header is used to carry the first parameter; or

In a possible implementation manner, the first multicast data packet is a BIER packet based on IPv6 encapsulation, and the BIER header in the first multicast data packet is used to carry the first parameter.

The BFIR ID field in the BIER header is used to carry the first parameter; or

In a possible implementation manner, the first multicast data packet is a BIER packet based on MPLS encapsulation, and the BIER header in the first multicast data packet is used to carry the first parameter.

In a possible implementation, the first parameter includes a sending timestamp, and the obtained module 1920 is used to:

Determine the reception timestamp of the first multicast data message;

Send the sending timestamp and the receiving timestamp to the controller;

Receive the first performance index sent by the controller, where the first performance index is used to represent at least one of transmission delay and delay jitter of the first path.

In a possible implementation, the first parameter includes a first serial number, and the obtaining module 1920 is used to:

Send the first serial number to the controller;

Receive the first performance index sent by the controller, where the first performance index is used to represent at least one of packet loss rate and out-of-order of the first path.

In a possible implementation, the first parameter includes a sending timestamp, and the obtaining module 1920 is used to:

Determine the reception timestamp of the first multicast data message;

The first performance index is generated based on the sending timestamp and the receiving timestamp, and the first performance index is used to represent at least one of transmission delay and delay jitter of the first path.

A first performance index is generated based on the first sequence number, and the first performance index is used to represent at least one of packet loss rate and disorder of the first path.

In a possible implementation, the second multicast data message further includes a second parameter, and the obtaining module 1920 is also used to:

A second performance index is obtained based on the second parameter, and the performance indicated by the second performance index is better than the performance indicated by the first performance index.

In a possible implementation, the first path and the second path are non-overlapping paths obtained by planning of the controller; or

The first path and the second path belong to different FlexAlgo slices and are not overlapping paths.

It should be noted that when the device for sending multicast data packets provided in the above embodiments performs multicast data packet sending, only the division of the above functional modules is used as an example. In practical applications, the above mentioned functions can be used as needed. Function allocation is completed by different functional modules, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device for sending multicast data packets provided in the above embodiments and the method embodiment for sending multicast data packets belong to the same concept. Please refer to the method embodiments for the specific implementation process, which will not be described again here.

Based on the same technical concept, the embodiment of the present application also provides a device for sending multicast data messages. The device 2000 can be applied to the above-mentioned root node A and root node B as shown in Figure 2, as shown in Figure 20 As shown, the device 2000 includes:

The acquisition module 2010 is used to obtain a multicast data message. The multicast data message includes a first parameter, and the first parameter is used to detect performance indicators; specifically, the acquisition functions in the

above steps

302, 402, and 501 can be implemented. , and other implicit steps.

The sending module 2020 is configured to send the multicast data message to the leaf node through the first path. Specifically, the method functions in the

above steps

302, 402, and 501 can be implemented, as well as other implicit steps.

In a possible implementation manner, the multicast data message includes a BIER header and a flow detection IFIT header, and the IFIT header is used to carry the first parameter.

The first multicast data message includes a BIER header and a transport stream TS header, and the TS header is used to carry the first parameter.

In a possible implementation manner, the multicast data message is a BIER message encapsulated based on Internet Protocol version 6, IPv6, and the BIER header in the multicast data message is used to carry the first parameter.

The BIER forwarding entry router identification BFIR ID field in the BIER header is used to carry the first parameter; or

In a possible implementation manner, the multicast data message is a BIER message encapsulated based on multi-protocol label switching, and the BIER header in the first multicast data message is used to carry the first parameter.

Figure 21 is a schematic structural diagram of a network device provided by an embodiment of the present application. Network device 700 includes at least one processor 701, memory 702, and at least one network interface 703.

The processor 701 is, for example, a general central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), or a neural network processor (NPU). ), a data processing unit (DPU), a microprocessor or one or more integrated circuits used to implement 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. PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a general array logic (GAL), or any combination thereof.

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

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

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

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

In some embodiments, network device 700 also includes internal connections 704. The processor 701, the memory 702, and the at least one network interface 703 are connected via an internal connection 704. Internal connections 704 include pathways that carry information between the components described above. Optionally, internal connection 704 is a single board or bus. Optionally, the internal connections 704 are divided into address bus, data bus, control bus, etc.

In some embodiments, network device 700 also includes input and output interfaces 706. Input/output interface 706 is connected to internal connection 704 .

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 using the 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 by the embodiment of the present application.

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.

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

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

Claims

A method for sending multicast data messages, characterized in that the method is applied to explicit copying of leaf nodes in a BIER domain based on bit indexes, and the method includes:

Receive a first multicast data message through a first path, where the first multicast data message includes a first parameter, and the first parameter is used to detect performance indicators;

Obtain a first performance index according to the first parameter;

Based on the first performance index, it is determined that the first path does not meet the performance requirement, and the second multicast data message is received through the second path.
The method according to claim 1, characterized in that the first multicast data message includes a BIER header and a flow detection IFIT header, and the IFIT header is used to carry the first parameter.
The method according to claim 1, characterized in that the first multicast data message includes a BIER header and a real-time transfer protocol RTP header, and the RTP header is used to carry the first parameter; or

The first multicast data message includes a BIER header and a transport stream TS header, and the TS header is used to carry the first parameter.
The method according to claim 1, characterized in that the first multicast data message is a BIER message encapsulated based on Internet Protocol version 6 IPv6, and the BIER header in the first multicast data message is to carry the first parameter.
The method according to claim 4, characterized in that the entropy field in the BIER header is used to carry the first parameter; or

The BIER forwarding entry router identification BFIR ID field in the BIER header is used to carry the first parameter; or the traffic level TC field, the S field used to identify the bottom of the label stack and the time-to-live TTL field in the BIER header are carried the first parameter; or

The S field and TTL field in the BIER header are used to carry the first parameter.
The method according to claim 1, characterized in that the first multicast data message is a BIER message encapsulated based on multi-protocol label switching MPLS, and the BIER header in the first multicast data message is used to Carrying the first parameter.
The method according to any one of claims 1 to 6, characterized in that the first parameter includes a sending timestamp, and obtaining the first performance index according to the first parameter includes:

Determine the reception timestamp of the first multicast data message;

Send the sending timestamp and the receiving timestamp to the controller;

Receive the first performance index sent by the controller, where the first performance index is used to represent at least one of transmission delay and delay jitter of the first path.
The method according to any one of claims 1 to 6, characterized in that the first parameter includes a first serial number, and obtaining the first performance index according to the first parameter includes:

Send the first serial number to the controller;

Receive the first performance index sent by the controller, where the first performance index is used to represent at least one of packet loss rate and out-of-order of the first path.
The method according to any one of claims 1 to 6, characterized in that the first parameter includes a sending timestamp, and obtaining the first performance index according to the first parameter includes:

Determine the reception timestamp of the first multicast data message;

The first performance index is generated based on the sending timestamp and the receiving timestamp, and the first performance index is used to represent at least one of transmission delay and delay jitter of the first path.
The method according to any one of claims 1 to 6, characterized in that the first parameter includes a first serial number, and obtaining the first performance index according to the first parameter includes:

A first performance index is generated based on the first sequence number, and the first performance index is used to represent at least one of packet loss rate and disorder of the first path.
The method according to any one of claims 1 to 10, characterized in that the second multicast data message further includes a second parameter, and the method further includes:

A second performance index is obtained based on the second parameter, and the performance indicated by the second performance index is better than the performance indicated by the first performance index.
The method according to any one of claims 1 to 11, characterized in that the first path and the second path are non-overlapping paths obtained by planning of the controller; or

The first path and the second path belong to different flexible algorithm FlexAlgo slices and do not overlap.
A method for sending multicast data messages, characterized in that the method is applied to the root node in the BIER domain, and the method includes:

Obtain a multicast data message, the multicast data message includes a first parameter, and the first parameter is used to detect performance indicators;

Send the multicast data message to the leaf node through the first path.
The method according to claim 13, characterized in that the multicast data message includes a BIER header and an IFIT header, and the IFIT header is used to carry the first parameter.
The method according to claim 13, characterized in that the multicast data message includes a BIER header and an RTP header, and the RTP header is used to carry the first parameter; or

The first multicast data message includes a BIER header and a TS header, and the TS header is used to carry the first parameter.
The method according to claim 13, characterized in that the multicast data message is a BIER message encapsulated based on IPv6, and the BIER header in the multicast data message is used to carry the first parameter.
The method according to claim 16, characterized in that the entropy field in the BIER header is used to carry the first parameter; or

The BFIR ID field in the BIER header is used to carry the first parameter; or

The TC field, S field and TTL field in the BIER header carry the first parameter; or

The S field and TTL field in the BIER header are used to carry the first parameter.
The method according to claim 13, characterized in that the multicast data message is a BIER message based on MPLS encapsulation, and the BIER header in the first multicast data message is used to carry the first parameter .
The method according to any one of claims 13 to 18, wherein the first parameter includes at least one of a sending timestamp and a first sequence number.
A device for sending multicast data messages, characterized in that the device is set at a leaf node in the BIER domain, and the device includes:

A receiving module, configured to receive a first multicast data message through a first path, where the first multicast data message includes a first parameter, and the first parameter is used to detect performance indicators;

An acquisition module, configured to obtain a first performance index according to the first parameter;

The receiving module is further configured to determine that the first path does not meet performance requirements based on the first performance index, and receive the second multicast data message through the second path.
The device according to claim 20, wherein the first multicast data message includes a BIER header and an IFIT header, and the IFIT header is used to carry the first parameter.
The device according to claim 20, wherein the first multicast data message includes a BIER header and an RTP header, and the RTP header is used to carry the first parameter; or

The first multicast data message includes a BIER header and a TS header, and the TS header is used to carry the first parameter.
The device according to claim 20, characterized in that the first multicast data message is a BIER message based on IPv6 encapsulation, and the BIER header in the first multicast data message is used to carry the third multicast data message. One parameter.
The device according to claim 23, wherein an entropy field in the BIER header is used to carry the first parameter; or

The BFIR ID field in the BIER header is used to carry the first parameter; or

The TC field, S field and TTL field in the BIER header carry the first parameter; or

The S field and TTL field in the BIER header are used to carry the first parameter.
The device according to claim 20, characterized in that the first multicast data message is a BIER message based on MPLS encapsulation, and the BIER header in the first multicast data message is used to carry the first multicast data message. One parameter.
The device according to any one of claims 20 to 25, characterized in that the first parameter includes a sending timestamp, and the obtained module is used for:

Determine the reception timestamp of the first multicast data message;

Send the sending timestamp and the receiving timestamp to the controller;

Receive the first performance index sent by the controller, where the first performance index is used to represent at least one of transmission delay and delay jitter of the first path.
The device according to any one of claims 20 to 25, wherein the first parameter includes a first serial number, and the acquisition module is configured to:

Send the first serial number to the controller;

Receive the first performance index sent by the controller, where the first performance index is used to represent at least one of packet loss rate and out-of-order of the first path.
The device according to any one of claims 20 to 25, wherein the first parameter includes a sending timestamp, and the acquisition module is configured to:

Determine the reception timestamp of the first multicast data message;

The first performance index is generated based on the sending timestamp and the receiving timestamp, and the first performance index is used to represent at least one of transmission delay and delay jitter of the first path.
The device according to any one of claims 20 to 25, wherein the first parameter includes a first serial number, and the acquisition module is configured to:

A first performance index is generated based on the first sequence number, and the first performance index is used to represent at least one of packet loss rate and disorder of the first path.
The device according to any one of claims 20 to 29, characterized in that the second multicast data message further includes a second parameter, and the acquisition module is also used to:

A second performance index is obtained based on the second parameter, and the performance indicated by the second performance index is better than the performance indicated by the first performance index.
The device according to any one of claims 20 to 30, wherein the first path and the second path are non-overlapping paths obtained by planning of the controller; or

The first path and the second path belong to different FlexAlgo slices and are not overlapping paths.
A device for sending multicast data messages, characterized in that the device is installed at the root node in the BIER domain, and the device includes:

An acquisition module, configured to obtain a multicast data message, where the multicast data message includes a first parameter, and the first parameter is used to detect performance indicators;

A sending module, configured to send the multicast data message to the leaf node through the first path.
The device according to claim 32, characterized in that the multicast data message includes a BIER header and a flow detection IFIT header, and the IFIT header is used to carry the first parameter.
The device according to claim 32, wherein the multicast data message includes a BIER header and an RTP header, and the RTP header is used to carry the first parameter; or

The first multicast data message includes a BIER header and a transport stream TS header, and the TS header is used to carry the first parameter.
The device according to claim 32, characterized in that the multicast data message is a BIER message encapsulated based on Internet Protocol version 6 IPv6, and the BIER header in the multicast data message is used to carry the The first parameter.
The device according to claim 35, characterized in that the entropy field in the BIER header is used to carry the first parameter; or

The BIER forwarding entry router identification BFIR ID field in the BIER header is used to carry the first parameter; or

The TC field, S field and TTL field in the BIER header carry the first parameter; or

The S field and TTL field in the BIER header are used to carry the first parameter.
The device according to claim 32, characterized in that the multicast data message is a BIER message encapsulated based on multi-protocol label switching, and the BIER header in the first multicast data message is used to carry the The first parameter.
The device according to any one of claims 32 to 37, wherein the first parameter includes at least one of a sending timestamp and a first sequence number.
A network device, characterized in that the network device includes a processor and a memory, at least one instruction is stored in the memory, and the at least one instruction is loaded and executed by the processor to implement claims 1 to 19 Any of the methods described above for sending multicast data messages.
A computer-readable storage medium, characterized in that at least one instruction is stored in the computer-readable storage medium, and when the at least one instruction is run on a network device, the network device causes the network device to execute claims 1 to 19 The method for sending multicast data messages according to any one of the above.