WO2021082879A1 - Method for transmitting multicast message, and related apparatus - Google Patents

Abstract

Provided are a method for transmitting a multicast message, and a related apparatus. The method comprises: when calculating an integrity check value in an authentication header, a network device using an IP header obtained after a destination address field is replaced with a preset value. In the technical solution, when an integrity check value is calculated, a destination IP address is replaced with a preset value. Thus, during a multicast message transmission process, when forwarding a multicast message, an intermediate device in a network does not need to recalculate an integrity check value. Thus, the burden on the intermediate device can be reduced. Accordingly, the intermediate device also does not need to save information for calculating the integrity check value, such as a key. Thus, the storage space of the intermediate device can be saved.

Description

Method and related device for transmitting multicast message

This application claims the priority of a Chinese patent application filed with the State Intellectual Property Office of China, the application number is CN201911061134.3, and the invention title is "Methods, Equipment and System for Transmitting Multicast Data Messages" on November 1, 2019. , And required to be submitted to the State Intellectual Property Office of China on December 31, 2019, the application number is CN201911416935.7, and the title of the invention is "Method and Related Device for Multicast Message Transmission", the entire contents of which are incorporated into this application by reference .

Technical field

This application relates to the field of communication technology, and more specifically, to a method and related devices for transmitting multicast packets.

Background technique

The authentication header (Authentication Header, AH) can provide connectionless integrity, data source authentication and anti-replay protection services. AH can be used alone or in conjunction with Internet Protocol (IP) Encapsulating Security Payload (ESP).

Integrity Check Value (ICV) is an important field in AH. The ICV field needs to include the IP header when calculating. However, in some scenarios, the message needs to pass through one or more intermediate nodes during the transmission process, and the destination IP address in the IP header of the message may change during the transmission process. In this case, when the intermediate node forwards the message, it needs to re-use the IP address of the next node to calculate ICV and update the ICV in AH. This will increase the burden on the intermediate node, and the intermediate node also needs to store the key information needed to calculate the ICV.

Summary of the invention

The present application provides a method and related device for transmitting multicast messages, which can reduce the burden of intermediate devices in the network.

In a first aspect, an embodiment of the present application provides a method for transmitting a multicast packet, including: a network device receives a first multicast packet sent by a source device; the network device determines an authentication header according to the first Internet Protocol IP header The integrity check value ICV in part AH, where the first IP header is obtained by replacing the destination address field of the second IP header with a preset value, and the destination IP address in the second IP header is the same as The preset value is different; the network device encapsulates the first multicast message to obtain a second multicast message, where the second multicast message includes the second IP header, the AH, and the first multicast message. Multicast message; sending the second multicast message to the destination device.

In the above technical solution, the destination IP address of ICV in AH is replaced with a preset value during calculation. In this way, during the transmission of the first multicast packet, the intermediate device in the network does not need to recalculate the ICV when forwarding the first multicast packet. In this way, the burden on intermediate equipment can be reduced. Correspondingly, the intermediate device does not need to store information such as the key used to calculate the ICV. In this way, the storage space of intermediate devices can be saved.

With reference to the first aspect, in a possible implementation of the first aspect, the method further includes: the network device acquiring instruction information, where the instruction information is used to instruct to replace the second IP header with the preset value The ICV is determined after the destination address field.

Using the above technical solution, the network device can directly determine whether to replace the destination IP address with a preset value according to the instruction information.

With reference to the first aspect, in a possible implementation of the first aspect, the length of the preset value is the same as the length of the destination IP address in the second IP header.

The above technical solution has minor changes to the ICV calculation method, which is convenient for the implementation of existing network equipment. In other words, when calculating the ICV, the network device only needs to use the preset value with the same length as the destination IP address to replace the destination IP address to calculate the ICV, and there is no need to redesign a specific calculation method.

Optionally, in some embodiments, the preset value may consist of multiple 0s, and the number of 0s is the same as the length of the destination IP address. For example, if the destination IP address in the second IP header is an IPv4 address, the preset value may be 32 zeros. If the destination IP address in the second IP header is an IPv6 address, the preset value may be 128 zeros.

With reference to the first aspect, in a possible implementation of the first aspect, the network device encapsulates the first multicast message to obtain the second multicast message, including: the network device uses a bit index-based The Internet Protocol version 6 encapsulation of the display copy encapsulates the first multicast message to obtain the second multicast message; or the network device encapsulates the first multicast message based on IP headend replication to obtain The second multicast message.

In a second aspect, an embodiment of the present application provides a method for transmitting a multicast packet. The method includes: a first network device receives a second multicast packet sent by a second network device, and the second multicast packet includes the first network device. 2. The Internet Protocol IP header, the authentication header AH and the first multicast message; the first integrity check value ICV determined by the first network device according to the first Internet Protocol IP header, wherein the first IP header The part is obtained after replacing the destination address field of the second IP header with a preset value. The destination IP address in the second IP header is different from the preset value; the first network device determines that the second ICV is Whether the first ICV is the same, where the second ICV is the ICV in the AH; when the second ICV is the same as the first ICV, the first network device sends the first multicast packet to the destination device.

In the above technical solution, the destination IP address of ICV in AH is replaced with a preset value during calculation. In this way, during the transmission of the first multicast packet, the intermediate device in the network does not need to recalculate the ICV when forwarding the first multicast packet. In this way, the burden on intermediate equipment can be reduced. Correspondingly, the intermediate device does not need to store information such as the key used to calculate the ICV. In this way, the storage space of the intermediate device can be saved.

With reference to the second aspect, in a possible implementation of the second aspect, the method further includes: the first network device obtains instruction information, the instruction information is used to instruct to replace the second IP header with the preset value The first ICV is determined after the destination address field.

Using the above technical solution, the network device can directly determine whether to replace the destination IP address with a preset value according to the instruction information.

With reference to the second aspect, in a possible implementation of the second aspect, the length of the preset value is the same as the length of the destination IP address in the second IP header.

The above technical solution has minor changes to the ICV calculation method, which is convenient for the implementation of existing network equipment. In other words, when calculating the ICV, the network device only needs to use the preset value with the same length as the destination IP address to replace the destination IP address to calculate the ICV, and there is no need to redesign a specific calculation method.

Optionally, in some embodiments, the preset value may consist of multiple 0s, and the number of 0s is the same as the length of the destination IP address. For example, if the destination IP address in the second IP header is an IPv4 address, the preset value may be 32 zeros. If the destination IP address in the second IP header is an IPv6 address, the preset value may be 128 zeros.

With reference to the second aspect, in a possible implementation manner of the second aspect, the second multicast message is a multicast message encapsulated in Internet Protocol version 6 of the display replication based on a bit index; or the second multicast The message is a multicast message encapsulated based on IP head-end replication.

In a third aspect, an embodiment of the present application provides a communication device, which may be a network device used to implement the method design in the second aspect described above, or a chip system set in the network device. The communication device includes a processor, which is coupled to a memory, and can be used to execute instructions in the memory to implement the first aspect or the method in any one of the possible implementation manners of the first aspect. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled with the communication interface.

When the communication device is a network device, the communication interface may be a transceiver, or an input/output interface.

When the communication device is a chip system configured in a network device, the communication interface may be an input/output interface.

Optionally, the processor may be a logic circuit, and the transceiver may be a transceiver circuit. Optionally, the input/output interface may be an input/output circuit.

In a fourth aspect, an embodiment of the present application provides a communication device. The communication device may be a network device used to implement the method design in the second aspect described above, or a chip system set in the network device. The communication device includes a processor, which is coupled to a memory, and can be used to execute instructions in the memory to implement the second aspect or the method in any one of the possible implementation manners of the second aspect. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled with the communication interface.

When the communication device is a network device, the communication interface may be a transceiver, or an input/output interface.

When the communication device is a chip system configured in a network device, the communication interface may be an input/output interface.

Optionally, the processor may be a logic circuit, and the transceiver may be a transceiver circuit. Optionally, the input/output interface may be an input/output circuit.

Optionally, the transceiver may be a transceiver circuit. Optionally, the input/output interface may be an input/output circuit.

In a fifth aspect, an embodiment of the present application provides a network device, including a transceiver and a processor. Optionally, the network device further includes a memory. The processor is used to control the transceiver to send and receive signals, the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the network device executes any one of the above-mentioned method designs of the first aspect. The method in the implementation mode.

In a sixth aspect, an embodiment of the present application provides a network device, including a transceiver and a processor. Optionally, the network device further includes a memory. The processor is used to control the transceiver to send and receive signals, the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the network device executes any one of the above-mentioned method designs of the second aspect. The method in the implementation mode.

In a seventh aspect, an embodiment of the present application provides a computer program product, the computer program product includes: computer program code, when the computer program code runs on a computer, the computer executes any of the method designs in the first aspect above One possible implementation method.

In an eighth aspect, an embodiment of the present application provides a computer program product, the computer program product comprising: computer program code, when the computer program code runs on a computer, the computer executes any of the method designs in the second aspect above One possible implementation method.

In a ninth aspect, an embodiment of the present application provides a computer-readable medium, the computer-readable medium stores program code, and when the computer program code runs on a computer, the computer executes the method design of the first aspect. Any one of the possible implementation methods.

In a tenth aspect, an embodiment of the present application provides a computer-readable medium, the computer-readable medium stores program code, and when the computer program code runs on a computer, the computer executes the method design of the second aspect. Any one of the possible implementation methods.

Description of the drawings

Figure 1 is a schematic diagram of a network scenario.

Figure 2 is a schematic diagram of packet encapsulation using IP head-end duplication and using AH.

FIG. 3 is a schematic flowchart of a method for transmitting multicast packets according to an embodiment of the present application.

Figure 4 is a schematic diagram of BIERv6 multicast packet encapsulation using AH.

Fig. 5 is a method for transmitting multicast packets provided by an embodiment of the present application.

Fig. 6 is a method for transmitting multicast packets provided by an embodiment of the present application.

FIG. 7 is a schematic structural block diagram of a communication device provided by an embodiment of the present application.

FIG. 8 is a schematic structural block diagram of a communication device provided by an embodiment of the present application.

Fig. 9 is a structural block diagram of a network device provided by an embodiment of the present invention.

Detailed ways

The technical solution in this application will be described below in conjunction with the accompanying drawings.

This application will present various aspects, embodiments, or features around a system that may include multiple devices, components, modules, and the like. It should be understood and understood that each system may include additional devices, components, modules, etc., and/or may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. In addition, a combination of these schemes can also be used.

In addition, in the embodiments of the present application, words such as "exemplary" and "for example" are used as examples, illustrations, or illustrations. Any embodiment or design solution described as an "example" in this application should not be construed as being more preferable or advantageous than other embodiments or design solutions. To be precise, the term example is used to present the concept in a concrete way.

In the embodiments of the present application, datagrams, data messages, messages, data packets, and packets can sometimes be used together. It should be noted that the meanings to be expressed are the same when the differences are not emphasized.

In the embodiments of the present application, the network device and node may be a router or a network device with routing function.

In the examples of this application, "corresponding (relevant)" and "corresponding" can sometimes be used together. It should be noted that the meanings to be expressed are the same when the difference is not emphasized.

Embodiment of the present application, the subscript sometimes as W ₁ may form a clerical error at non-target as W1, while not emphasize the difference, to express their meaning is the same.

In the embodiments of this application, "header" (for example, BIER header, IP header, etc.) is sometimes abbreviated as "header" (for example, BIER header, IP header, etc.).

The network architecture and business scenarios described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Those of ordinary skill in the art will know that with the network With the evolution of the architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

References described in this specification to "one embodiment" or "some embodiments", etc. mean that one or more embodiments of the present application include a specific feature, structure, or characteristic described in conjunction with the embodiment. Therefore, the sentences "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification are not necessarily All refer to the same embodiment, but mean "one or more but not all embodiments" unless it is specifically emphasized otherwise. The terms "including", "including", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

In this application, "at least one" refers to one or more, and "multiple" refers to two or more. "And/or" describes the association relationship of the associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone, where A, B can be singular or plural. The character "/" generally indicates that the associated objects before and after are in an "or" relationship. "The following at least one item (a)" or similar expressions refers to any combination of these items, including any combination of a single item (a) or a plurality of items (a). For example, at least one item (a) of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple .

In order to facilitate those skilled in the art to better understand the technical solutions of this application, some technologies or concepts involved in this application are first briefly introduced.

Bit Indexed Display Replication (Bit Indexed Explicit Replication, BIER)

BIER technology is a bit-based multicast replication technology. Each edge node of the BIER technology-based network (hereinafter referred to as the BIER network) will be configured with a BIER Forwarding Router (BFR)-Identifier (ID). The BFR-ID can be a value greater than or equal to 1 and less than or equal to 256. The configuration information of the edge node will be flooded in the network. For example, the interior gateway protocol (Interior Gateway Protocol, IGP) flooding method can be used to flood the configuration information of the edge node in the network. The configuration information of the edge node may also be referred to as BIER information. Each node in the BIER network can determine the corresponding node according to the BFR-ID. The nodes in the BIER network establish a forwarding table through the flooded BIER information, and use the established forwarding table to forward the BIER-encapsulated multicast data message.

BIER Internet Protocol version 6 (Internet Protocol version 6, IPv6) encapsulation is a BIER encapsulation method. BIER IPv6 encapsulation can be referred to as BIERv6 encapsulation for short. The basic principle of BIERv6 encapsulation is to use a multicast data message as an IPv6 payload. The multicast data message may be an Internet Protocol version 4 (IPv4) message or an IPv6 message. For ease of description, the multicast message obtained based on BIERv6 encapsulation is referred to as a BIERv6 multicast message for short below. A BIERv6 multicast message can include an IPv6 header and a BIER header. The BIER header includes a bit string (BitString) field. The length of the bit string field can be 64, 128, 256, and so on. Each bit in the bit string can be used to identify a BIER Forwarding Edge Router (BFER). For example, the lowest bit (that is, the rightmost) bit in the bit string is used to identify the next hop node is the node corresponding to BFR-ID=1, and the second bit from right to left in the bit string is used to identify the next node It is the node corresponding to BFR-ID=2, the third bit from right to left in the bit string is used to identify the next hop node is the node corresponding to BFR-ID=3, and so on.

Figure 1 is a schematic diagram of a network scenario. As shown in FIG. 1, the network 100 includes six nodes, namely node A, node B, node C, node D, node E, and node F. Among them, node A, node D, node E, and node F are BFERs. Unless otherwise specified, the messages mentioned in the description of Figure 1 are all BIERv6 multicast messages.

Suppose that the BFR-ID of node A is 4, the BFR-ID of node D is 1, the BFR-ID of node E is 2, and the BFR-ID of node F is 3.

For node A, the next hop of the BFER with BFR-ID=1/2/3 is node B, and the BFER with BFR-ID=4 is node A. Therefore, node A can establish a forwarding table including two neighbor entries as shown in Table 1.

Table 1

Nbr	FBM
B	0111
*A*	1000

Nbr in Table 1 represents neighbors (Neirgbor, Nbr), and FBM represents forwarding bit mask (BFM). The use of * in Table 1 indicates that the Nbr is node A itself.

The first entry shown in Table 1 indicates that when the bit string of the message received by node A from right to left, any one of the first, second, and third bits has a value of 1. , The message will be forwarded to Node B.

The second entry shown in Table 1 indicates that when the fourth bit value of the bit string of the message received by node A from right to left is 1, the message will be sent to node A. In this case, node A will remove the BIER header of the message and forward it according to the original multicast message of the message.

Similarly, Node B can create forwarding entries as shown in Table 2.

Table 2

Nbr	FBM
C	0011
E	0100
A	1000

The meaning of each table item shown in Table 2 is similar to the meaning of each table item in Table 1. For example, the first entry shown in Table 2 indicates that when the bit string of the message received by node B is counted from right to left, any one of the first and second bits has a value of 1, The message will be forwarded to node C. The second entry shown in Table 2 indicates that when the value of the third bit in the bit string of the message received by node B from right to left is 1, the message will be forwarded to node E. The third entry shown in Table 2 indicates that when the value of the fourth bit in the bit string of the message received by node B from right to left is 1, the message will be forwarded to node A.

Node C can create forwarding entries as shown in Table 3.

table 3

Nbr	FBM
D	0001
F	0010
E	0100
B	1000

The meaning of each table item shown in Table 3 is similar to the meaning of each table item in Table 1. For example, the first entry shown in Table 3 indicates that when the bit string of the message received by node C is counted from right to left, the first bit value is 1, the message will be forwarded to node D . The second entry shown in Table 2 indicates that when the second bit value of the bit string of the message received by node B from right to left is 1, the message will be forwarded to node F. The third entry shown in Table 2 indicates that when the value of the third bit in the bit string of the message received by node B from right to left is 1, the message will be forwarded to node E. The fourth entry shown in Table 2 indicates that when the value of the fourth bit in the bit string of the message received by node B from right to left is 1, the message will be forwarded to node B.

Node E can create forwarding entries as shown in Table 4.

Table 4

Nbr	FBM
C	0011
*E*	0100
B	1000

The meaning of each table item shown in Table 4 is similar to the meaning of each table item in Table 1.

For example, the first entry shown in Table 4 indicates that when the bit string of the message received by node E is counted from right to left, any one of the first and second bits is 1. , The message will be forwarded to node C.

The second entry shown in Table 4 indicates that when the value of the third bit in the bit string of the message received by node B from right to left is 1, the message will be forwarded to node E. In this case, node E will remove the BIER header of the message and forward it according to the original multicast message of the message.

The third entry shown in Table 4 indicates that when the value of the fourth bit in the bit string of the message received by node B from right to left is 1, the message will be forwarded to node B.

Node D can create forwarding entries as shown in Table 5.

table 3

Nbr	FBM
*D*	0001
C	1110

The meaning of each table item shown in Table 5 is similar to the meaning of each table item in Table 1.

For example, the first entry shown in Table 5 indicates that when the bit string of the message received by node D is counted from right to left, the first bit value is 1, the message will be forwarded to node D . In this case, node D will remove the BIER header of the message and forward it according to the original multicast message of the message.

As shown in Table 5, the second entry indicates that when the bit string of the message received by node D is counted from right to left, any one of the second, third, and fourth bits is 1. , The message will be forwarded to node C.

Node F can create forwarding entries as shown in Table 6.

Table 6

Nbr	FBM
C	1101
*F*	0010

The meaning of each table item shown in Table 6 is similar to the meaning of each table item in Table 1.

For example, the first entry shown in Table 6 indicates that when the bit string of the message received by node D is counted from right to left, any one of the first, third, and fourth bits is At 1, the message will be forwarded to node C.

The second entry shown in Table 6 indicates that when the second bit value of the bit string of the message received by node F from right to left is 1, the message will be forwarded to node F. In this case, node F will remove the BIER header of the message and forward it according to the original multicast message of the message.

The specific process of packet forwarding is as follows: Node A receives IPv4 multicast packets or IPv6 multicast packets (hereinafter referred to as IP multicast) from hosts or network devices (such as Customer Edge (CE) devices) Message). Node A encapsulates the IP multicast message based on BIERv6 to obtain the BIERv6 multicast message. Assuming that node A determines that the IP multicast message needs to be sent to node E and node D, node A can determine that the bit string in the BIER header of the BIERv6 multicast message is 0101. Node A forwards according to the forwarding table shown in Table 1. According to the forwarding table shown in Table 1, node A will send the encapsulated message to node B. Therefore, node A can determine that the destination IP address in the IPv6 header of the BIERv6 multicast message is the IPv6 address of node B, and the source IP address is the IPv6 address of node A.

The IPv6 header of the BIERv6 multicast message referred to in the embodiments of the present application refers to the IPv6 header obtained after BIERv6 encapsulation of the received IP multicast message, rather than the IPv6 multicast message header. The IPv6 header of the BIERv6 multicast message may also be referred to as the outer IPv6 header or the outer IP header of the BIERv6 multicast message. The destination address in the outer IP header can be called the outer IP destination address or the outer destination address, and the source address in the outer IP header can be called the outer source address or the outer source IP address. Correspondingly, the IP header of the IPv6 multicast message that needs to be encapsulated may also be referred to as an inner IP header, an inner IPv4 header, and an inner IPv6 header. The destination address in the inner IP header can be called the inner IP destination address or the inner destination address, and the source address in the inner IP header can be called the inner IP source address or the inner source address.

After node B receives the BIERv6 multicast message from node A, it can determine that the BIERv6 multicast message is sent to itself according to the destination IP address in the outer IP header of the BIERv6 multicast message. In this case, node B can determine the need to send the BIERv6 multicast from node A to node C and according to the bit string in the BIER header of the BIERv6 multicast message and the forwarding table shown in Table 2. Node E.

Node B sums the bit string in the BIER header of the BIERv6 multicast message from node A (ie 0101) with the FBM (ie 0011) of the Nbr=C entry in the forwarding table shown in Table 2. Operation, the result is 0001. Node B replaces the bit string in the BIER header of the BIERv6 multicast message from node A with the result obtained after the sum operation (that is, 0001). In addition, node B replaces the destination IP address in the outer IP header of the BIERv6 multicast message from node A with the IPv6 address of node C. Node B sends the BIERv6 multicast message modified with the destination address in the outer IP header and the bit string in the BIER header to node C.

Similarly, node B combines the bit string in the BIER header of the BIERv6 multicast message from node A (ie 0101) and the FBM (ie 0100) of the Nbr=E entry in the forwarding table shown in Table 2. ) Perform the sum operation, and the result is 0100. Node B replaces the bit string in the BIER header of the BIERv6 multicast message from node A with the result obtained after the sum operation (that is, 0100). In addition, node B replaces the destination IP address in the outer IP header of the BIERv6 multicast message from node A with the IPv6 address of node E. Node B sends the BIERv6 multicast packet modified with the destination address in the outer IP header and the bit string in the BIER header to node E.

After node E receives the message from node B, it can determine that the BIERv6 multicast message is sent to itself according to the destination IP address in the outer IP header of the BIERv6 multicast message. In this case, the node E can determine that the message needs to be sent to the node E according to the bit string in the BIER header of the message and the forwarding table shown in Table 4. In this case, the node E will decapsulate the received message and forward it according to the inner IP multicast message of the message. For example, the node E may send the inner layer IP multicast packet to the host or CE device corresponding to the destination address according to the source and destination addresses of the inner layer IP multicast packet.

The operation after node C receives the BIERv6 multicast message from node B is similar to the operation after node B receives the BIERv6 multicast message from node A. For brevity, it will not be repeated here. Node C will send the BIERv6 multicast packet modified with the destination IP address in the outer IP header and the bit string in the BIER header to node D.

The operation after receiving D receives the BIERv6 multicast message from node C is similar to the operation of node E receiving the BIERv6 multicast message from node B. For the sake of introduction, I will not repeat it here.

It can be seen that in the above process, both nodes B and C modify the outer destination IP address in the received BIERv6 multicast message. Therefore, if AH is added to the BIERv6 multicast message. For example, Figure 4 is a schematic diagram of BIERv6 multicast packet encapsulation using AH. When node B sends a BIERv6 multicast message to node E, it also needs to recalculate the ICV in AH. This is because the ICV in the AH header of the BIERv6 multicast packet is calculated by including the outer destination address of the BIERv6 multicast packet. The outer destination address of the BIERv6 multicast packet sent by node A to node B is the IPv6 address of node B, and the outer destination address of the BIERv6 multicast packet sent by node B to node E is the IPv6 address of node E. Therefore, when node B forwards the BIERv6 multicast message from node A to node E, in addition to the outer destination address in the BIERv6 multicast message and the bit string in the BIER header, it also needs to modify the ICV. Node B and Node C need to store the secret key and other information needed to calculate ICV.

IP headend replication (Internet Protocol Ingress Replication) is another way to send multicast packets. Also take the network structure shown in Figure 1 as an example. Assume that node A needs to send the received IP multicast message to node E and node D. In this case, node A needs to encapsulate the received IP multicast packet with an IP header with the IP address of node A as the source address and the address of node E as the destination address (it can be called the outer IP header) . Send the encapsulated message to node E. Similarly, node A can encapsulate an outer IP header with the IP address of node A as the source address and the IP address of node D as the destination address for the received IP multicast packet. Send the encapsulated message to node D.

Figure 2 is a schematic diagram of packet encapsulation using IP head-end duplication and using AH. As shown in Figure 2, node A can encapsulate the received IP multicast packet into four forms: a, b, c, or d. As shown in Figure 2, when node A encapsulates the received IP multicast message, it also adds AH.

For example, node A may encapsulate the received IP multicast message into a message shown in form a. The message of form a includes an outer IP header, AH, and an inner IP multicast message. The inner IP multicast packet is the IP multicast packet received by node A from the source device (for example, the host or CE device). Assuming that the message is sent to node E, the source IP address in the outer IP header is the IPv4 address of node A, and the destination address in the outer IP header is the IPv4 address of node E.

For another example, node A may encapsulate the received IP multicast message into a message shown in form b. The message of form b includes: outer IPv6 header, AH, and inner IP multicast message. The inner IP multicast packet is the IP multicast packet received by node A from the source device. Assuming that the message is sent to node E, the source IP address in the outer IPv6 header is the IPv6 address of node A, and the destination address in the outer IP header is the IPv6 address of node E.

For another example, node A may encapsulate the received IP multicast message into a message shown in form c. The message of form c includes: outer IPv6 header, AH, Generic Routing Encapsulation (GRE) header, and inner IP multicast message. The inner IP multicast packet is the IP multicast packet received by node A from the source device. In this case, after node A receives the IP multicast packet from the source device, it can perform GRE encapsulation on the IP multicast packet and add the outer IPv6 header and GRE header, which are from the source device. IP multicast packets are used as the payload of GRE packets. In addition, node A also needs to encapsulate AH into GRE packets. The source IP address in the outer IPv6 header is the source address of the GRE tunnel, and the destination IP address is the destination address of the GRE tunnel.

For another example, node A may encapsulate the received IP multicast message into a message shown in form d. The message of form d includes: outer IPv6 header, AH, user data packet (User Datagram Protocol, UDP) header, Virtual Extensible Location Area Network (VXLAN) header, inner IP multicast message . The inner IP packet is the IP multicast packet received by node A from the source device. In this case, after node A receives the IP multicast packet from the source device, it can perform VXLAN encapsulation on the IP multicast packet, adding the outer IPv6 header, UDP header, and VXLAN header. The IP multicast packet from the source device is used as the payload of the VXLAN packet. In addition, node A also needs to encapsulate AH into VXLAN packets. The source IP address in the outer IPv6 header is the IPv6 address of the source VXLAN tunnel end point (VXLAN Tunnel End Point, VTEP), and the destination IP address is the IPv6 address of the destination VTEP. If node A encapsulates the message to be sent to node E, the source VTEP is node A, and the destination VTEP is node E.

When using IP headend replication to send multicast packets, if you need to send IP multicast packets to different egress devices, you need to encapsulate different packets, and the outer destination addresses in the encapsulated packets are all different . Therefore, node A needs to calculate the ICV in AH according to different destination IP addresses.

The specific calculation method of ICV is as follows: use the IP header before the AH header and the value of the immutable or predictable part in the extended field, the AH header (ICV is set to 0), and all the information after the AH header. When calculating ICV, the value of the variable part is set to zero.

In the ICV calculation process based on IPv4, the immutable parts include: version number (Version), Internet header length (Internet Header Length), total length (Total Length), protocol (Protocol), source address, destination address (not loose) Or strict source routing (without loose or strict source routing). The predictable part includes: Destination address (loose or strict source routing). Variable parts: Differentiated Services Code Point (DSCP), Explicit Congestion Notification (ECN), Flags, Fragment Offset, Time to Live (TTL) And Header Checksum.

In the ICV calculation process based on IPv6, the immutable parts include: version number (Version), payload length (Payload Length), next header (Next Header), source address, destination address (without Routing Extension) Header)). The predictable part includes the destination address (Routing Extension Header). Variable parts: DSCP, ECN, Flow Label (Flow Labe), Hop Limit (Hot Limit). In addition, the IPv6 extension header (Extension Header) includes option extension headers (such as Hop-by-Hop Options Header and Destination Options Header) in some fields (such as options). The data field ("Option Data" field) is set to 0 when calculating the ICV, and other fields (for example, Option Type and Option Data Length (Opt Data Len)) are included in the ICV when calculating the ICV.

For the specific content of the fields that need to be used in the ICV calculation and the fields that need to be set to 0, please refer to the description in Request For Comment (RFC) 4302, which will not be repeated here.

The completeness algorithm used to calculate the ICV can be based on a symmetric encryption algorithm (such as Advanced Encryption Standard (AES)) with a keyed message authentication code (Message Authentication Code, MACs) or one-way hash Functions (such as message digest algorithm 5 (Message-Digest Algorithm 5, MD5), secure hash algorithm 1 (Secure Hash Algorithm 1, SHA-1), secure hash algorithm 256 (Secure Hash Algorithm 256, SHA-256), etc.) .

It can be understood that the AH in the packet encapsulation diagram shown in FIG. 2 or FIG. 4 is used alone. The technical solution of this application can also be applied to a scenario where AH and ESP are used in combination.

FIG. 3 is a schematic flowchart of a method for transmitting multicast packets according to an embodiment of the present application. FIG. 3 is a description of the technical solution of the present application in conjunction with the system 100 shown in FIG. 1.

301. Node A receives a first multicast packet sent by a source device.

The first multicast message may be an IPv4 multicast message or an IPv6 multicast message, which is not limited in the embodiment of the present application.

The source device can be a host or a network device (for example, a CE device).

302. Node A determines the ICV in AH according to the first IP header.

The first IP header is the second IP header whose destination address is replaced with a preset value. The second IP header is the IP header used when encapsulating the first multicast message. It is assumed that the multicast message obtained by encapsulating the first multicast message is a second multicast message, and the second IP header is the outer IP header of the second multicast message.

The preset value is a preset fixed value. The preset value is different from the destination IP address in the second IP header.

Optionally, in some embodiments, the length of the preset value is the same as the length of the destination IP address in the second IP header. For example, if the destination IP address in the second IP header is an IPv4 address, the length of the preset value is 32 bits. If the destination IP address in the second IP header is an IPv6 address, the length of the preset value is 128 bits.

Optionally, in other embodiments, the length of the preset value is a length of K, and K is a positive integer greater than or equal to 1. For example, K can be equal to 8, 16, 32, or 64, etc.

Optionally, in some embodiments, the preset value may be all zeros. For example, if the destination IP address is an IPv6 address, the preset value may be 128 zeros. For another example, if the destination IP address is an IPv4 address, the default value can be 32 zeros.

Optionally, in other embodiments, the preset value may be all ones. For example, if the destination IP address is an IPv6 address, the preset value may be 128 ones. For another example, if the destination IP address is an IPv4 address, the preset value can be 32 ones.

Optionally, in other embodiments, the preset value may be other types of preset values. For example, the preset value may be repeated 01. For another example, the first 1/2 of the preset value is 0, and the last 1/2 is 1. For example, if the destination IP address is an IPv6 address, the first 64 bits of the AND setting are 0, and the last 64 bits are 1.

The method for node A to calculate ICV is the same as the above method for calculating ICV, except that the destination IP address in the second IP header is replaced with a preset value.

303. Node A encapsulates the first multicast message to obtain a second multicast message, where the second multicast message includes a second IP header, AH, and the first multicast message.

Node A encapsulates the outer IP header and AH on the first multicast message to obtain the second multicast message. The outer IP header is the second IP header, and the ICV in the AH is the ICV determined in step 302.

304. Node A sends the second multicast packet to node B.

Assume that the destination devices of the second multicast message are node D and node E.

305. Node B sends the received second multicast packet to node C and node E.

It can be understood that if the second multicast message is encapsulated based on BIERv6, Node B needs to modify the destination IP address in the first IP header and the bit string in the BIER header when forwarding the second multicast message, and change The multicast message with modified outer destination IP address and bit string is sent to node C and node E. However, for ease of description, the method shown in FIG. 3 does not distinguish between the multicast message received by node B from node A and the multicast message sent by node B to node C and node E.

306. Node C sends the received second multicast packet to node D.

Similar to step 305, step 306 does not distinguish between the multicast message received by node C from node B and the multicast message sent to node D.

307. Node D calculates ICV according to the first IP header. In order to facilitate the distinction, the ICV determined in step 307 is referred to as the first ICV, and the ICV determined in step 302 is referred to as the second ICV. Node D calculates ICV in the same way as node A calculates ICV.

308. The node D determines whether the first ICV is the same as the second ICV. If the first ICV is the same as the second ICV, it means that the second multicast packet passes the integrity check. In this case, node D may decapsulate the second multicast message to obtain the first multicast message. Node D determines which device to send the first multicast message to according to the destination address of the first multicast message. If the first ICV is different from the second ICV, it means that the second multicast packet fails the integrity check. In this case, node D can directly delete the second multicast message.

The manner in which the node E processes the received second multicast message is the same as the manner in which the node D processes the received multicast message. For the sake of brevity, details are not repeated here.

The method shown in Figure 3 can be applied to BIERv6. In this case, in step 303, the node A encapsulates the first multicast message to obtain the second multicast message, which may include: the node A uses BIERv6 to encapsulate the first multicast message to obtain The second multicast message. In this case, the outer IP header of the second multicast packet (that is, the second IP header) is an IPv6 header. In this case, the preset value may be 128 zeros or 128 ones or other types of preset values (for example, the first 64 bits are 0 and the last 64 bits are 1).

The method shown in Figure 3 can be applied to IP head-end replication. In this case, in step 303, the node A encapsulates the first multicast message to obtain the second multicast message, which may include: the node A uses the IP headend to copy the first multicast message Encapsulate to obtain the second multicast message. In this case, the second multicast message obtained by node A may be as shown in FIG. 2. For example, if the second multicast message is a multicast message as shown in a in FIG. 2, the preset value may be 32 0, 32 1 or 32 other types of preset values (for example, The first 16 bits are 0, and the last 16 bits are 1). For another example, if the second multicast packet is a multicast packet as shown in b in FIG. 2, the preset value may be 128 zeros or 128 ones, or 128 other types of preset values.

If the ICV in the multicast packet transmitted in the network is determined using the method shown in Figure 3, the intermediate devices in the network (such as node B and node C) may not need to modify the multicast packet after receiving the multicast packet. The ICV in the AH of the multicast packet. In this way, the intermediate device in the network does not need to store information such as the secret key required to calculate the ICV, nor does it need to calculate the ICV, thereby reducing the workload of the intermediate device.

Optionally, in some embodiments, the node A may obtain an indication information. The indication information is used to indicate whether the preset value can be used to replace the destination IP address in the outer IP header to calculate the ICV. For example, the value of the indication information may be true or false. If the value of the indication information is positive, the node A can use the preset value to calculate the ICV; if the value of the indication information is negative, the node A can use the destination IP address in the outer IP header to calculate the ICV. The intermediate device and the target device in the network can also obtain the indication information. In this case, the intermediate device may determine whether to recalculate the ICV according to the instruction information when forwarding the message. When verifying the ICV, the destination device can also determine whether to use a preset value to replace the destination IP address in the outer IP header when calculating the ICV according to the instruction information.

Optionally, in some embodiments, the node A may obtain a piece of configuration information (for example, it may be a security association (Security Association, SA) or a security policy (Security Policy, SP), etc.). The configuration information may include indication information for indicating whether the preset value can be used to replace the destination IP address in the outer IP header to calculate the ICV. The indication information may also be referred to as an indication, or a destination address silent indication, etc. The node A can determine whether to use a preset value to replace the destination IP address in the outer IP header to calculate the ICV according to the destination address silent indication in the SA or SP. The intermediate device and the destination device in the network can also obtain the SA or SP. In this case, the intermediate device may determine whether to recalculate the ICV according to the silent indication of the destination address in the SA or SP when forwarding the message. When verifying the ICV, the destination device can also determine whether to use a preset value to replace the destination IP address in the outer IP header when calculating the ICV according to the destination address silent indication in the SA or SP.

For ease of description, the following uses the first solution to represent the solution of calculating the ICV using a preset value instead of the destination IP address in the outer IP header, and using the second solution to represent the solution to calculate the ICV using the destination IP address in the outer IP header.

Optionally, in other embodiments, the node A may determine the number of destination devices. In other words, the node A determines the number of devices that need to receive and decapsulate the second multicast packet. If the node A determines that the number of destination devices is greater than or equal to 2, the node A can use the first scheme to calculate ICV. If the node A determines that the number of destination devices is 1, the node A can use the second scheme to calculate ICV. The node A may use a field in the outer IP header or AH or other headers of the second multicast packet to indicate the ICV calculation method of the second multicast packet. In other words, the header of the second multicast packet (for example, the IP header, or AH or other header fields) may include an indication information (which may be called ICV calculation indication information), and the indication information is used to indicate whether the ICV is What is determined by the first scheme is determined by the second scheme. In this way, the intermediate device can determine whether ICV needs to be recalculated according to the instruction information. The destination device may also determine whether to replace the destination IP address in the outer IP header with a preset value when calculating the ICV according to the instruction information.

Optionally, in other embodiments, the network devices in the network can be directly configured to only use the first scheme to calculate ICV. In other words, in this case, the network devices in the network will not use the second scheme to calculate ICV. The source device (that is, the node A in the method shown in FIG. 3), the intermediate device, and the destination device do not need to determine the method for calculating the ICV based on the configuration information or the instruction information.

Fig. 5 is a method for transmitting multicast packets provided by an embodiment of the present application.

501: A network device receives a first multicast packet sent by a source device.

The source device can be a host or a CE device.

502. The network device determines the ICV in AH according to the first IP header, where the first IP header is obtained by replacing the destination address field of the second IP header with a preset value, and the second IP header The destination IP address in the section is different from the preset value.

503. The network device encapsulates the first multicast message to obtain a second multicast message, where the second multicast message includes the second IP header, the AH, and the first multicast message .

The network device encapsulates the outer IP header and AH on the first multicast message to obtain the second multicast message. The outer IP header is the second IP header, and the ICV in the AH is the ICV determined in step 502.

504. Send the second multicast packet to the destination device.

The destination device can be another network device.

The network device in the method shown in FIG. 5 may be the node A in the method shown in FIG. 3. For the specific implementation and beneficial effects of each step of the method shown in FIG. 5, please refer to the method shown in FIG. 3, which will not be repeated here.

Fig. 6 is a method for transmitting multicast packets provided by an embodiment of the present application.

601. A first network device receives a second multicast packet sent by a second network device, where the second multicast packet includes a second Internet Protocol IP header, an authentication header AH, and a first multicast packet.

602. The first network device determines the first ICV according to the first IP header, where the first IP header is obtained after replacing the destination address field of the second IP header with a preset value. 2. The destination IP address in the IP header is different from the preset value.

603. The first network device determines whether the second ICV is the same as the first ICV, where the second ICV is the ICV in the AH.

604. The first network device sends the first multicast packet to the destination device when the second ICV is the same as the first ICV.

The destination device can be a host or a network device (for example, a CE device).

The first network device in the method shown in FIG. 6 may be node D or node F in the method shown in FIG. 3. If the first network device is the node E in the method shown in FIG. 3, the second network device may be the node B in the method shown in FIG. 3. If the first network device is the node D in the method shown in FIG. 3, the second network device may be the node C in the method shown in FIG. 3. The steps and beneficial effects of the method shown in FIG. 6 can be referred to the method shown in FIG. 3, which will not be repeated here.

FIG. 7 is a schematic structural block diagram of a communication device provided by an embodiment of the present application. The communication device 700 shown in FIG. 7 may be the network device in the method shown in FIG. 5 or a component (such as a chip, a chip system, or a circuit, etc.) in the network device. The communication device 700 shown in FIG. 7 may also be a node A or a component (such as a chip, a chip system, or a circuit, etc.) in the node A in the method shown in FIG. 3. As shown in FIG. 7, the communication device 700 includes a receiving unit 701, a processing unit 702, and a sending unit 703.

The receiving unit 701 is configured to receive the first multicast packet sent by the source device.

The processing unit 702 is configured to determine the integrity check value ICV in the authentication header AH according to the first Internet Protocol IP header, where the first IP header replaces the destination address field of the second IP header with a pre- After setting the value, the destination IP address in the second IP header is different from the preset value.

The processing unit 702 is further configured to encapsulate the first multicast message to obtain a second multicast message, where the second multicast message includes the second IP header, the AH, and the first multicast Message.

The sending unit 703 is configured to send the second multicast packet to the destination device.

Optionally, the processing unit 702 is further configured to obtain indication information, where the indication information is used to indicate to use the preset value to replace the destination address field of the second IP header to determine the ICV.

Optionally, the length of the preset value is the same as the length of the destination IP address in the second IP header.

Optionally, the processing unit 702 is specifically configured to encapsulate the first multicast packet based on BIERv6 to obtain the second multicast packet; or encapsulate the first multicast packet based on IP headend replication , To obtain the second multicast message.

If the communication device 700 is the network device in the method shown in FIG. 5 or the node A in the method shown in FIG. 3, the receiving unit 701 and the sending unit 703 may be implemented by a transceiver, and the processing unit 702 may be implemented by a processor.

If the communication device 700 is a component in the network device in the method shown in FIG. 5 or a component in the node A in the method shown in FIG. 3, the receiving unit 701 and the sending unit 703 can be implemented by an input/output interface or an input/output interface. Circuit implementation, the processing unit 702 can be implemented by a logic circuit.

The specific functions and beneficial effects of the receiving unit 701, the processing unit 702, and the sending unit 703 can be referred to the embodiment shown in FIG. 3 or FIG. 5. For brevity, details are not repeated here.

FIG. 8 is a schematic structural block diagram of a communication device provided by an embodiment of the present application. The communication apparatus 800 shown in FIG. 8 may be the first network device or a component (for example, a chip, a chip system, or a circuit, etc.) in the first network device in the method shown in FIG. 6. The communication device 800 shown in FIG. 8 may also be a node D (or E) or a component (such as a chip, a chip system or a circuit, etc.) in the node D (or E) in the method shown in FIG. 3. As shown in FIG. 8, the communication device 800 includes a receiving unit 801, a processing unit 802, and a sending unit 803.

The receiving unit 801 is configured to receive a second multicast packet sent by a network device, where the second multicast packet includes a second Internet Protocol IP header, an authentication header AH, and a first multicast packet.

The processing unit 802 is configured to determine a first integrity check value ICV according to a first Internet Protocol IP header, where the first IP header is to replace the destination address field of the second IP header with a preset value Obtained later, the destination IP address in the second IP header is different from the preset value;

The processing unit 802 is further configured to determine whether the second ICV is the same as the first ICV, where the second ICV is the ICV in the AH.

The sending unit 803 is configured to send the first multicast packet to the destination device when the second ICV is the same as the first ICV.

Optionally, the processing unit 802 is further configured to obtain indication information, where the indication information is used to instruct to determine the first ICV after replacing the destination address field of the second IP header with the preset value.

Optionally, the length of the preset value is the same as the length of the destination IP address in the second IP header.

Optionally, the second multicast message is a multicast message encapsulated based on BIERv6; or the second multicast message is a multicast message encapsulated based on IP headend replication.

If the communication device 800 is the first network device in the method shown in FIG. 6 or the node D (or E) in the method shown in FIG. 3, the receiving unit 801 and the sending unit 803 may be implemented by a transceiver, and the processing unit 802 may Realized by the processor.

If the communication device 800 is a component in the first network device in the method shown in FIG. 6 or a component in the node D (or E) in the method shown in FIG. The output interface or input/output circuit is implemented, and the processing unit 802 may be implemented by a logic circuit.

The specific functions and beneficial effects of the receiving unit 801, the processing unit 802, and the sending unit 803 can be referred to the embodiment shown in FIG. 3 or FIG.

Fig. 9 is a structural block diagram of a network device provided by an embodiment of the present invention. As shown in FIG. 9, the network device 900 includes a processor 901 and a memory 902. The processor 901 may be used to process communication protocols and communication data, control network devices, execute software programs, and process data of software programs, and so on. The memory 902 is mainly used to store software programs and data.

For ease of description, only one memory and processor are shown in FIG. 9. In actual network equipment products, there may be one or more processors and one or more memories. The memory may also be referred to as a storage medium or storage device. The memory may be set independently of the processor, or may be integrated with the processor, which is not limited in the embodiment of the present application.

In the embodiment of the present application, the circuit with the transceiver function can be regarded as the transceiver 903 of the network device, and the processor with the processing function can be regarded as the processing unit of the network device. The transceiver may also be referred to as a transceiver unit, transceiver, transceiver, and so on. The processing unit may also be called a processor, a processing board, a processing module, a processing device, and so on. Optionally, the device for implementing the receiving function in the transceiver 903 can be regarded as the receiving unit, and the device for implementing the sending function in the transceiver 903 as the sending unit, that is, the transceiver 903 includes a receiving unit and a sending unit. The receiving unit may sometimes be called a receiver, a receiver, or a receiving circuit. The transmitting unit may sometimes be called a transmitter, a transmitter, or a transmitting circuit.

The processor 901, the memory 902, and the transceiver 903 communicate with each other through internal connection paths to transfer control and/or data signals

The method disclosed in the foregoing embodiment of the present invention may be applied to the processor 901 or implemented by the processor 901. The processor 901 may be an integrated circuit chip with signal processing capabilities. In the implementation process, the steps of the foregoing method may be completed by an integrated logic circuit of hardware in the processor 901 or instructions in the form of software.

Optionally, in some embodiments, the memory 902 may store instructions for executing the method executed by the node A in the method shown in FIG. 3. The processor 901 can execute the instructions stored in the memory 902 in combination with other hardware (such as the transceiver 903) to complete the steps executed by the node A in the method shown in FIG. 1. For the specific working process and beneficial effects, please refer to the steps in the embodiment shown in FIG. 3 description.

Optionally, in some embodiments, the memory 902 may store instructions for executing the method executed by the node D in the method shown in FIG. 3. The processor 901 can execute the instructions stored in the memory 902 in combination with other hardware (for example, the transceiver 903) to complete the steps executed by the node D in the method shown in FIG. description.

Optionally, in some embodiments, the memory 902 may store instructions for executing the method executed by the node E in the method shown in FIG. 3. The processor 901 can execute the instructions stored in the memory 902 in combination with other hardware (for example, the transceiver 903) to complete the steps executed by the node E in the method shown in FIG. 3. For the specific working process and beneficial effects, please refer to the steps in the embodiment shown in FIG. 3 description.

Optionally, in some embodiments, the memory 902 may store instructions for executing the method executed by the network device in the method shown in FIG. 5. The processor 901 can execute the instructions stored in the memory 902 in combination with other hardware (for example, the transceiver 903) to complete the steps executed by the network device in the method shown in FIG. description.

Optionally, in some embodiments, the memory 902 may store instructions for executing the method executed by the first network device in the method shown in FIG. 6. The processor 901 can execute the instructions stored in the memory 902 in combination with other hardware (for example, the transceiver 903) to complete the steps executed by the first network device in the method shown in FIG. 6. For the specific working process and beneficial effects, please refer to the embodiment shown in FIG. 6. In the description.

In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The steps of the method disclosed in the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

It should be noted that the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capability. In the implementation process, the steps of the foregoing method embodiments can be completed by hardware integrated logic circuits in the processor or instructions in the form of software. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

The chip in the embodiment of the present application may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), or It is a central processor unit (CPU), a network processor (NP), a digital signal processing circuit (digital signal processor, DSP), or a microcontroller (microcontroller unit). , MCU), it may also be a programmable logic device (PLD), other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, or other integrated chips.

The memory in the embodiments of the present application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), and electrically available Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of exemplary but not restrictive description, many forms of RAM are available, such as static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), and synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM) ) And direct memory bus random access memory (direct rambus RAM, DR RAM). It should be noted that the memories of the systems and methods described herein are intended to include, but are not limited to, these and any other suitable types of memories.

According to the method provided by the embodiments of the present application, the present application also provides a computer program product. The computer program product includes: computer program code, which when the computer program code runs on a computer, causes the computer to execute FIG. 3, FIG. 5 or The method of any one of the embodiments shown in FIG. 6.

According to the method provided in the embodiments of the present application, the present application also provides a computer-readable medium that stores program code, and when the program code runs on a computer, the computer executes FIG. 3, FIG. 5 or The method of any one of the embodiments shown in FIG. 6.

According to the method provided in the embodiments of the present application, the present application also provides a system, which includes the aforementioned one or more network devices.

A person of ordinary skill in the art may realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed by hardware or software depends on the specific application and design constraint conditions of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and conciseness of the description, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiment, which is not repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the device embodiments described above are merely illustrative, for example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or It can be integrated into another system, or some features can be ignored or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

In addition, the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.

If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solution of the present application essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

The above are only specific implementations of this application, but the protection scope of this application is not limited to this. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application. Should be covered within the scope of protection of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (19)

1. A method for transmitting multicast messages, characterized in that it comprises:

   The network device receives the first multicast packet sent by the source device;

   The network device determines the integrity check value ICV in the authentication header AH according to the first Internet Protocol IP header, wherein the first IP header replaces the destination address field of the second IP header with a preset Obtained after the value, the destination IP address in the second IP header is different from the preset value;

   The network device encapsulates the first multicast message to obtain a second multicast message, where the second multicast message includes the second IP header, the AH, and the first multicast message. Multicast message;

   Sending the second multicast message to the destination device.
2. The method according to claim 1, wherein the method further comprises: the network device acquiring indication information, wherein the indication information is used to indicate that the preset value is used to replace the second IP header The ICV is determined after the destination address field.
3. The method according to claim 1 or 2, wherein the length of the preset value is the same as the length of the destination IP address in the second IP header.
4. The method according to any one of claims 1 to 3, wherein the network device encapsulating the first multicast message to obtain the second multicast message comprises:

   The network device encapsulates the first multicast message by using the Internet Protocol version 6 encapsulation based on bit index to display duplication to obtain the second multicast message; or

   The network device encapsulates the first multicast message based on IP headend replication to obtain the second multicast message.
5. A method for transmitting multicast messages, characterized in that the method includes:

   The first network device receives a second multicast packet sent by the second network device, where the second multicast packet includes a second Internet Protocol IP header, an authentication header AH, and the first multicast packet;

   The first network device determines the first integrity check value ICV according to the first Internet Protocol IP header, where the first IP header replaces the destination address field of the second IP header with a pre- Obtained after setting, the destination IP address in the second IP header is different from the preset value;

   The first network device determines whether the second ICV is the same as the first ICV, where the second ICV is the ICV in the AH;

   The first network device sends the first multicast packet to the destination device when the second ICV is the same as the first ICV.
6. The method according to claim 5, wherein the method further comprises: the first network device obtaining indication information, the indication information being used to instruct to replace the second IP header with the preset value The first ICV is determined after the destination address field.
7. The method according to claim 5 or 6, wherein the length of the preset value is the same as the length of the destination IP address in the second IP header.
8. The method according to any one of claims 5 to 7, wherein the second multicast message is a multicast message encapsulated in the sixth version of the Internet Protocol based on a bit index display; or the second multicast message is The second multicast message is a multicast message encapsulated based on IP head-end replication.
9. A communication device, characterized in that it comprises:

   The receiving unit is configured to receive the first multicast packet sent by the source device;

   The processing unit is configured to determine the integrity check value ICV in the authentication header AH according to the first Internet Protocol IP header, wherein the first IP header replaces the destination address field of the second IP header with a pre- Obtained after setting, the destination IP address in the second IP header is different from the preset value;

   The processing unit is further configured to encapsulate the first multicast message to obtain a second multicast message, wherein the second multicast message includes the second IP header, the AH, and The first multicast message;

   The sending unit is configured to send the second multicast message to the destination device.
10. The device according to claim 9, wherein the processing unit is further configured to obtain indication information, wherein the indication information is used to indicate to replace the destination address of the second IP header with the preset value The ICV is determined after the field.
11. The device according to claim 9 or 10, wherein the length of the preset value is the same as the length of the destination IP address in the second IP header.
12. The apparatus according to any one of claims 9 to 11, wherein the processing unit is specifically configured to use a bit index-based display duplication of Internet Protocol version 6 encapsulation for the first multicast packet Encapsulate to obtain the second multicast message; or

    Encapsulate the first multicast message based on IP headend replication to obtain the second multicast message.
13. A communication device, characterized in that it comprises:

    A receiving unit, configured to receive a second multicast message sent by a network device, where the second multicast message includes a second Internet Protocol IP header, an authentication header AH, and a first multicast message;

    The processing unit is configured to determine the first integrity check value ICV according to the first Internet Protocol IP header, wherein the first IP header replaces the destination address field of the second IP header with a preset Obtained after the value, the destination IP address in the second IP header is different from the preset value;

    The processing unit is further configured to determine whether the second ICV is the same as the first ICV, wherein the second ICV is the ICV in the AH;

    The sending unit is configured to send the first multicast packet to the destination device when the second ICV is the same as the first ICV.
14. The device according to claim 13, wherein the processing unit is further configured to obtain indication information, the indication information being used to instruct to replace the destination address field of the second IP header with the preset value Then determine the first ICV.
15. The device according to claim 13 or 14, wherein the length of the preset value is the same as the length of the destination IP address in the second IP header.
16. The apparatus according to any one of claims 13 to 15, wherein the second multicast message is a multicast message encapsulated in the sixth version of the Internet Protocol that is displayed and copied based on a bit index; or the second multicast message is The second multicast message is a multicast message encapsulated based on IP head-end replication.
17. A computer device, characterized by comprising: a processor, the processor is configured to be coupled with a memory, read and execute instructions and/or program codes in the memory, so as to execute claims 1-4, or, The method of any one of 5 to 8.
18. A chip system, characterized by comprising: a logic circuit for coupling with an input/output interface, and transmitting data through the input/output interface, so as to perform as claimed in claims 1-4, or 5 to 8. The method of any one of 8.
19. A computer-readable medium, characterized in that the computer-readable medium stores program code, and when the computer program code is run on a computer, the computer can execute claims 1-4, or 5 to 8 Any of the methods.

Images