CN112769745A

CN112769745A - Method and related device for transmitting multicast message

Info

Publication number: CN112769745A
Application number: CN201911416935.7A
Authority: CN
Inventors: 谢经荣
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-11-01
Filing date: 2019-12-31
Publication date: 2021-05-07
Anticipated expiration: 2039-12-31
Also published as: CN112769745B; WO2021082879A1

Abstract

The application provides a method and a related device for transmitting multicast messages, which comprises the following steps: and when the network equipment calculates the integrity check value in the authentication header, the network equipment replaces the destination address field with the IP header obtained after the preset value is replaced. In the above technical solution, the destination IP address is replaced with a preset value when the integrity check value is calculated. Thus, in the transmission process of the multicast message, the intermediate device in the network does not need to recalculate the integrity check value when forwarding the multicast message. Thus, the burden on the intermediate device can be reduced. Accordingly, the intermediate device does not need to store information such as a key for calculating the integrity check value. In this way, storage space of the intermediate device may be saved.

Description

Method and related device for transmitting multicast message

The present application claims priority of chinese patent application with application number 201911061134.3, entitled "method, device and system for transmitting multicast data packets", filed in 2019 on 11/01, and the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method and a related apparatus for transmitting a multicast packet.

Background

An Authentication Header (AH) may provide connectionless integrity, data source Authentication, and anti-replay protection services. AH may be used alone or in combination with an Internet Protocol (IP) Encapsulated Security Payload (ESP).

The Integrity Check Value (ICV) is an important field in the AH. The ICV field needs to contain an IP header when computed. However, in some scenarios, a message needs to pass through one or more intermediate nodes during transmission, and a destination IP address in an IP header of the message may change during transmission. In this case, when forwarding the packet, the intermediate node needs to calculate the ICV by reusing the IP address of the next node and update the ICV in the AH. This increases the burden on the intermediate nodes, and the intermediate nodes also need to hold the key information needed to compute the ICV.

Disclosure of Invention

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

In a first aspect, an embodiment of the present application provides a method for transmitting a multicast packet, including: the network equipment receives a first multicast message sent by source equipment; the network equipment determines an integrity check value ICV in an authentication header AH according to a first Internet protocol IP header, wherein the first IP header is obtained by replacing a destination address field of a second IP header with a preset value, and 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, wherein the second multicast message comprises the second IP header, the AH and the first multicast message; and sending the second multicast message to the destination equipment.

In the technical scheme, the ICV in the AH is replaced by a preset value when calculating. Thus, in the transmission process of the first multicast message, the intermediate device in the network does not need to recalculate the ICV when forwarding the first multicast message. Thus, the burden on the intermediate device can be reduced. Accordingly, the intermediary device need not maintain information such as keys used to compute the ICV. In this way, storage space of the intermediate device may be saved.

With reference to the first aspect, in a possible implementation manner of the first aspect, the method further includes: and the network equipment acquires indication information, wherein the indication information is used for indicating that the ICV is determined after the preset value is used for replacing the destination address field of the second IP header.

By using the technical scheme, the network equipment can directly determine whether to use the preset value to replace the destination IP address according to the indication information.

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

The technical scheme has small change on the ICV calculation mode, and is convenient for the realization of the existing network equipment. In other words, when the network device calculates the ICV, the network device only needs to use a preset value with the same length as the destination IP address to calculate the ICV instead of the destination IP address, and does not need to redesign a specific calculation method.

Optionally, in some embodiments, the preset value may be composed of a plurality of 0, and the number of 0 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 0 s. If the destination IP address in the second IP header is an IPv6 address, the preset value may be 128 0 s.

With reference to the first aspect, in a possible implementation manner of the first aspect, the encapsulating, by the network device, the first multicast message to obtain a second multicast message includes: the network equipment encapsulates the first multicast message by using a bit index-based display copy internet protocol sixth version encapsulation to obtain a second multicast message; or the network device packages the first multicast message based on the IP head end copy to obtain the second multicast message.

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

With reference to the second aspect, in a possible implementation manner of the second aspect, the method further includes: and the first network equipment acquires indication information, wherein the indication information is used for indicating that the first ICV is determined after the preset value is used for replacing the destination address field of the second IP header.

With reference to the second aspect, in a possible implementation manner 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.

With reference to the second aspect, in a possible implementation manner of the second aspect, the second multicast message is a multicast message encapsulated by a sixth version of internet protocol that is displayed and copied based on a bit index; or the second multicast message is a multicast message based on IP head end copy encapsulation.

In a third aspect, an embodiment of the present application provides a communication apparatus, which may be a network device designed to implement the method in the second aspect, or a system-on-chip provided in the network device. The communication device includes: a processor, coupled to the memory, may be configured to execute the instructions in the memory to implement the method of the first aspect or any one of the possible implementations of the first aspect. Optionally, the communication device further comprises a memory. Optionally, the communication device further comprises a communication interface, the processor being coupled to 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 system-on-chip configured in a network device, the communication interface may be an input/output interface.

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

In a fourth aspect, the present application provides a communication apparatus, which may be a network device designed to implement the method in the second aspect, or a system-on-chip provided in the network device. The communication device includes: a processor, coupled to the memory, may be configured to execute the instructions in the memory to implement the method of the second aspect or any one of the possible implementations of the second aspect. Optionally, the communication device further comprises a memory. Optionally, the communication device further comprises a communication interface, the processor being coupled to the communication interface.

Alternatively, the transceiver may be a transmit-receive circuit. Alternatively, the input/output interface may be an input/output circuit.

In a fifth aspect, an embodiment of the present application provides a network device, which includes a transceiver and a processor. Optionally, the network device further comprises a memory. The processor is configured to control the transceiver to transmit and receive signals, the memory is configured to store a computer program, and the processor is configured to call and run the computer program from the memory, so that the network device executes the method in any one of the possible implementation manners of the method design of the first aspect.

In a sixth aspect, an embodiment of the present application provides a network device, which includes a transceiver and a processor. Optionally, the network device further comprises a memory. The processor is configured to control the transceiver to transmit and receive signals, the memory is configured to store a computer program, and the processor is configured to call and run the computer program from the memory, so that the network device executes the method in any one of the possible implementation manners of the method design of the second aspect.

In a seventh aspect, an embodiment of the present application provides a computer program product, where the computer program product includes: computer program code for causing a computer to perform the method of any one of the possible implementations of the method design of the first aspect described above, when said computer program code is run on a computer.

In an eighth aspect, an embodiment of the present application provides a computer program product, where the computer program product includes: computer program code which, when run on a computer, causes the computer to perform the method of any one of the possible implementations of the method design of the second aspect described above.

In a ninth aspect, the present application provides a computer-readable medium, which stores program codes, and when the computer program codes are executed on a computer, the computer is caused to execute the method in any one of the possible implementation manners in the method design of the first aspect.

In a tenth aspect, an embodiment of the present application provides a computer-readable medium, which stores program codes, and when the computer program codes are executed on a computer, the computer is caused to execute the method in any one of the possible implementation manners of the method design of the second aspect.

Drawings

Fig. 1 is a schematic diagram of a network scenario.

Figure 2 is a schematic diagram of the encapsulation of a packet using AH with IP head end replication.

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

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

Fig. 5 is a method for transmitting a multicast packet according to an embodiment of the present application.

Fig. 6 is a method for transmitting a multicast packet according to an embodiment of the present application.

Fig. 7 is a schematic structural block diagram of a communication device according to an embodiment of the present application.

Fig. 8 is a schematic structural block diagram of a communication device according to an embodiment of the present application.

Fig. 9 is a block diagram of a network device according to an embodiment of the present invention.

Detailed Description

The technical solution in the present application will be described below with reference to the accompanying drawings.

This application is intended to present various aspects, embodiments or features around a system that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. Furthermore, a combination of these schemes may also be used.

In addition, in the embodiments of the present application, words such as "exemplary", "for example", etc. are used to mean serving as examples, illustrations or explanations. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the term using examples is intended to present concepts in a concrete fashion.

In the embodiment of the present application, datagrams (datagrams), data messages, packets, and packets may sometimes be used in a mixed manner, and it should be noted that, when differences are not emphasized, meanings to be expressed are consistent.

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

In the embodiments of the present application, "corresponding" and "corresponding" may be sometimes used in a mixed manner, and it should be noted that the intended meaning is consistent when the difference is not emphasized.

In the examples of the present application, the subscripts are sometimes as W₁It may be mistaken for a non-subscripted form such as W1, whose intended meaning is consistent when the distinction is de-emphasized.

In the embodiments of the present application, "header" (e.g., BIER header, IP header, etc.) is sometimes abbreviated as "header" (e.g., BIER header, IP header, etc.).

The network architecture and the service scenario described in the embodiment of the present application are for more clearly illustrating the technical solution of the embodiment of the present application, and do not form a limitation on the technical solution provided in the embodiment of the present application, and as a person of ordinary skill in the art knows that along with the evolution of the network architecture and the appearance of a new service scenario, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

In the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone, wherein A and B can be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or multiple.

To facilitate a better understanding of the technical solutions of the present application for those skilled in the art, a brief description will be given of some technologies or concepts related to the present application.

Bit-index-based display Replication (BIER)

The BIER technique is a bit-based (bit) multicast replication technique. Each edge node of a network based on the BIER technology (hereinafter referred to as BIER network) is configured with a BIER Forwarding Router (BFR) -Identifier (ID). The BFR-ID may be a value greater than or equal to 1 and less than or equal to 256. Configuration information for the edge nodes may be flooded in the network. For example, configuration information of an edge node may be flooded in a network using an Interior Gateway Protocol (IGP) flooding scheme. The configuration information of the edge node may also be referred to as BIER information. Each node in the BIER network may determine a corresponding node from the BFR-ID. And the nodes in the BIER network establish a forwarding table through the flooded BIER information and forward the multicast data message encapsulated by the BIER by utilizing the established forwarding table.

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

Fig. 1 is a schematic diagram of a network scenario. As shown in fig. 1, the network 100 includes six nodes, which are node a, node B, node C, node D, node E, and node F, respectively, where node a, node D, node E, and node F are BFERs. Unless otherwise specified, the messages referred to in describing fig. 1 are BIERv6 multicast messages.

Suppose node a has a BFR-ID of 4, node D has a BFR-ID of 1, node E has a BFR-ID of 2, and node F has a BFR-ID of 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. Node a may therefore build a forwarding table that includes two neighbor table entries as shown in table 1.

TABLE 1

Nbr	FBM
		B	0111
A	1000

Nbr in table 1 denotes a neighbor (Neirgbor, Nbr), and FBM denotes a Forwarding Bit Mask (BFM). In table 1, the Nbr is denoted as node a itself.

As shown in the first table entry shown in table 1, when any bit value of the 1 st, 2 nd, and 3 rd bits of the bit string of the packet received by the node a from right to left is 1, the packet is forwarded to the node B.

As shown in the second table entry shown in table 1, when the 4 th bit value of the bit string of the packet received by the node a from right to left is 1, the packet is sent to the node a. In this case, the node a will remove the BIER header of the packet and forward it according to the original multicast packet of the packet.

Similarly, the node B may establish a forwarding table entry as shown in table 2.

TABLE 2

Nbr	FBM
		C	0011
E	0100
		A	1000

The meaning of each entry shown in table 2 is similar to that of table 1. For example, as shown in table 2, the 1 st entry indicates that when any bit value of the 1 st bit and the 2 nd bit of the bit string of the packet received by the node B from right to left is 1, the packet is forwarded to the node C. As shown in table 2, the 2 nd table entry indicates that when the bit string of the packet received by the node B from right to left has the 3 rd bit value of 1, the packet is forwarded to the node E. As shown in table 2, the 3 rd entry indicates that when the 4 th bit value of the bit string of the packet received by the node B from right to left is 1, the packet is forwarded to the node a.

Node C may establish a forwarding entry as shown in table 3.

TABLE 3

Nbr	FBM
		D	0001
F	0010
		E	0100
B	1000

The meaning of each entry shown in table 3 is similar to that of table 1. For example, as shown in table 3, the 1 st entry indicates that when the bit string of the packet received by the node C from right to left has the 1 st bit value, the packet is forwarded to the node D. As shown in table 2, the 2 nd entry indicates that when the bit string of the packet received by the node B from right to left has the 2 nd bit value of 1, the packet is forwarded to the node F. As shown in table 2, the 3 rd entry indicates that when the 3 rd bit value of the bit string of the packet received by the node B from right to left is 1, the packet is forwarded to the node E. As shown in the 4 th table entry in table 2, when the 4 th bit value of the bit string of the packet received by the node B from right to left is 1, the packet is forwarded to the node B.

Node E may establish a forwarding table entry as shown in table 4.

TABLE 4

Nbr	FBM
		C	0011
E	0100
		B	1000

The meaning of each entry shown in table 4 is similar to that of table 1.

For example, as shown in table 4, the 1 st entry indicates that, when any one bit value of the 1 st bit and the 2 nd bit from right to left of the bit string of the packet received by the node E is 1, the packet is forwarded to the node C.

As shown in table 4, the 2 nd table entry indicates that when the bit string of the packet received by the node B from right to left has the 3 rd bit value of 1, the packet is forwarded to the node E. In this case, the node E will remove the BIER header of the packet and forward the packet according to the original multicast packet of the packet.

As shown in table 4, the 3 rd entry indicates that when the 4 th bit value of the bit string of the packet received by the node B from right to left is 1, the packet is forwarded to the node B.

Node D may establish a forwarding entry as shown in table 5.

TABLE 3

Nbr	FBM
		D	0001
C	1110

The meaning of each entry shown in table 5 is similar to that of table 1.

For example, as shown in the 1 st table entry shown in table 5, when the bit string of the packet received by the node D from right to left has the 1 st bit value of 1, the packet is forwarded to the node D. In this case, the node D will remove the BIER header of the packet and forward the packet according to the original multicast packet of the packet.

As shown in table 5, the 2 nd entry indicates that, when any one bit value of the 2 nd, 3 rd, and 4 th bits counted from right to left of the bit string of the packet received by the node D is 1, the packet is forwarded to the node C.

Node F may establish a forwarding table entry as shown in table 6.

TABLE 6

Nbr	FBM
		C	1101
F	0010

The meaning of each entry shown in table 6 is similar to that of table 1.

For example, as shown in table 6, the 1 st entry indicates that when any one bit value of the 1 st, 3 rd, and 4 th bits from right to left of the bit string of the packet received by the node D is 1, the packet is forwarded to the node C.

As shown in table 6, the 2 nd entry indicates that when the bit string of the packet received by the node F from right to left has the 2 nd bit value of 1, the packet is forwarded to the node F. In this case, the node F will remove the BIER header of the packet and forward the packet according to the original multicast packet of the packet.

The specific process of forwarding the message is as follows: the node a receives an IPv4 multicast packet or an IPv6 multicast packet (hereinafter, referred to as an IP multicast packet) from a host (host) or a network device (e.g., a Customer Edge (CE) device). The node A encapsulates the IP multicast message based on BIERv6 to obtain a BIERv6 multicast message. Assuming that the node a determines that the IP multicast packet needs to be sent to the node E and the node D, the node a may determine that the bit string in the BIER header of the BIERv6 multicast packet 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 sends the encapsulated packet to node B. Therefore, the node a may determine that the destination IP address in the IPv6 header of the BIERv6 multicast packet is the IPv6 address of the node B, and the source IP address is the IPv6 address of the node a.

The IPv6 header of the BIERv6 multicast packet in the embodiment of the present application refers to an IPv6 header obtained by encapsulating the received IP multicast packet by BIERv6, instead of the header of the IPv6 multicast packet. The IPv6 header of the BIERv6 multicast packet may also be referred to as the outer IPv6 header or the outer IP header of the BIERv6 multicast packet. The destination address in the outer IP header may be referred to as an outer IP destination address or an outer destination address and the source address in the outer IP header may be referred to as an outer source address or an outer source IP address. Correspondingly, the IP headers of the IPv6 multicast packet 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 may be referred to as an inner IP destination address or an inner destination address, and the source address in the inner IP header may be referred to as an inner IP source address or an inner source address.

After receiving the BIERv6 multicast packet from the node a, the node B may determine that the BIERv6 multicast packet is sent to itself according to the destination IP address in the outer IP header of the BIERv6 multicast packet. In this case, the node B may determine that the BIERv6 multicast from the node a needs to be sent to the node C and the node E according to the bit string in the BIER header of the BIERv6 multicast packet and the forwarding table shown in table 2.

Node B sums the bit string (0101) in the BIER header of the BIERv6 multicast packet from node a with the FBM (0011) of the entry of Nbr ═ C in the forwarding table shown in table 2, and the result is 0001. The node B replaces the bit string in the BIER header of the BIERv6 multicast packet from the node a with the result of the sum operation (i.e., 0001). In addition, the node B replaces the destination IP address in the outer IP header of the BIERv6 multicast message from the node A with the IPv6 address of the node C. The node B sends the BIERv6 multicast message with the destination address in the outer IP header and the bit string in the BIER header modified to the node C.

Similarly, node B sums the bit string (i.e., 0101) in the BIER header of the BIERv6 multicast packet from node a with the FBM (i.e., 0100) of the entry of Nbr ═ E in the forwarding table shown in table 2, resulting in 0100. The node B replaces the bit string in the BIER header of the BIERv6 multicast packet from the node a with the result of the sum operation (i.e., 0100). In addition, the node B replaces the destination IP address in the outer IP header of the BIERv6 multicast message from the node A with the IPv6 address of the node E. The node B sends a BIERv6 multicast message to the node E, which modifies the destination address in the outer IP header and the bit string in the BIER header.

After receiving the packet from the node B, the node E may determine that the BIERv6 multicast packet is sent to itself according to the destination IP address in the outer IP header of the BIERv6 multicast packet. In this case, node E may determine that the packet needs to be sent to node E according to the bit string in the BIER header of the packet and the forwarding table shown in table 4. In this case, the node E decapsulates the received packet and forwards the packet according to the inner IP multicast packet of the packet. For example, the node E may send the inner IP multicast packet to the host or the CE device corresponding to the destination address according to the source and the destination address of the inner IP multicast packet.

The operation after the node C receives the BIERv6 multicast packet from the node B is similar to the operation after the node B receives the BIERv6 multicast packet from the node a, and for brevity, the description is omitted here. Node C will send a BIERv6 multicast packet to node D with the destination IP address in the outer IP header and the bit string in the BIER header modified.

The operation after node D receives the BIERv6 multicast packet from node C is similar to the operation after node E receives the BIERv6 multicast packet from node B, and for brevity, is not described herein again.

It can be seen that in the above process, both node B and node 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, fig. 4 is a schematic diagram of BIERv6 multicast packet encapsulation using AH. When node B sends BIERv6 multicast message to node E, it also needs to recalculate ICV in AH. This is because the ICV in the AH header of the BIERv6 multicast packet will contain the outer destination address of the BIERv6 multicast packet when calculating. The outer destination address of the BIERv6 multicast message sent by the node a to the node B is the IPv6 address of the node B, and the outer destination address of the BIERv6 multicast message sent by the node B to the node E is the IPv6 address of the node E. Therefore, when node B forwards the BIERv6 multicast packet from node a to node E, it needs to modify the ICV in AH, in addition to modifying the outer destination address and the bit string in the BIER header in the BIERv6 multicast packet. Node B and node C need to keep information such as keys needed for computing the ICV.

IP headend Replication (Internet Protocol Ingress Replication) is another way to send multicast messages. The network structure shown in fig. 1 is also taken as an example. Suppose that node a needs to send the received IP multicast packet to node E and node D. In this case, the node a needs to encapsulate an IP header (which may be referred to as an outer IP header) with the IP address of the node a as a source address and the address of the node E as a destination address into the received IP multicast packet. And sending the packaged message to a node E. Similarly, the node a may encapsulate an outer IP header with the IP address of the node a as a source address and the IP address of the node D as a destination address in the received IP multicast packet. And sending the packaged message to a node D.

Figure 2 is a schematic diagram of the encapsulation of a packet using AH with IP head end replication. As shown in fig. 2, the node a may encapsulate the received IP multicast packet into four forms, a, b, c, and d. As shown in fig. 2, when encapsulating the received IP multicast packet, node a further adds AH.

For example, node a may encapsulate the received IP multicast packet into a packet as shown in form a. The message of the form a comprises an outer IP header, AH and an inner IP multicast message. The inner IP multicast packet is an IP multicast packet received by the node a from a source device (e.g., a host or a CE device). Assuming that the packet 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, the node a may encapsulate the received IP multicast packet into a packet shown in form b. The message of form b includes: outer IPv6 header, AH, inner IP multicast message. The inner IP multicast packet is an IP multicast packet received by the node a from the source device. Assuming that the packet 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, the node a may encapsulate the received IP multicast packet into a packet shown in the form c. The message of form c includes: an outer IPv6 header, an AH, a Generic Routing Encapsulation (GRE) header, and an inner IP multicast packet. The inner IP multicast packet is an IP multicast packet received by the node a from the source device. In this case, after receiving the IP multicast packet from the source device, the node a may perform GRE encapsulation on the IP multicast packet, add an outer IPv6 header and a GRE header, and use the IP multicast packet from the source device as a load of the GRE packet. Node a also needs to encapsulate AH in the GRE message. 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, the node a may encapsulate the received IP multicast packet into a packet shown in the form d. The message of form d includes: an outer layer IPv6 header, an AH, a User Data Packet (UDP) header, a Virtual Extensible local Area Network (VXLAN) header, and an inner layer IP multicast packet. The inner IP packet is an IP multicast packet received by the node a from the source device. In this case, after receiving the IP multicast packet from the source device, the node a may perform VXLAN encapsulation on the IP multicast packet, add an outer IPv6 header, a UDP header, and a VXLAN header, and use the IP multicast packet from the source device as a payload of the VXLAN packet. Node a also needs to encapsulate AH into the VXLAN message. The source IP address in the outer IPv6 header is the IPv6 address of the source VXLAN Tunnel Endpoint (VTEP), and the destination IP address is the IPv6 address of the destination VTEP. If the node A encapsulates that the message is sent to the node E, the source VTEP is the node A, and the destination VTEP is the node E.

When the IP head end is used for copying and sending the multicast message, if the IP multicast message needs to be sent to different outlet equipment, different messages need to be packaged, and the outer layer destination addresses in the packaged messages are different. Therefore, node a needs to compute the ICV in AH from the different destination IP address.

The specific calculation of ICV is as follows: the AH header (ICV set to 0) and all information following the AH header are used with the values of the IP header preceding the AH header and the immutable or predictable portion in the extension field. In calculating the ICV, the value of the variable portion is set to 0.

In the calculation process of the ICV based on the IPv4, the immutable part comprises the following steps: version number (Version), Internet Header Length (Internet Header Length), Total Length (Total Length), Protocol (Protocol), source address, destination address (non-loose or strict source routing). The predictable portion includes: destination address (loose or strict source routing). The variable part: differentiated Services Code Point (DSCP), Explicit Congestion Notification (ECN), Flags (Flags), slice Offset (Fragment Offset), Time To Live (TTL), and Header check (Header check).

In the calculation process of the ICV based on the IPv6, the immutable part comprises the following steps: version number (Version), Payload Length (Payload Length), Next Header (Next Header), source address, destination address (non-Routing Extension Header). The predictable portion includes: a destination address (Routing Extension Header). The variable part: DSCP, ECN, Flow label (Flow Labe), hop Limit (Hot Limit). In addition, a partial field (e.g., Option Data field) in an Extension Header (Extension Header) of the IPv6 including an Option, such as a Hop-by-Hop Options Header and a Destination Options Header, is set to 0 when calculating the ICV, and another partial field (e.g., Option Type and Option Data length) is included in the ICV when calculating the ICV.

The specific contents of the field that needs to be used and the field that needs to be set to 0 in ICV calculation may refer to the description in Request For Comment (RFC) 4302, which is not described herein again.

The finalization Algorithm used to compute the ICV may be a Keyed (Keyed) Message Authentication Code (MACs) based on a symmetric Encryption Algorithm (e.g., Advanced Encryption Standard (AES)) or a one-way Hash function (e.g., Message Digest Algorithm 5 (MD 5), Secure Hash Algorithm 1(Secure Hash Algorithm 1, SHA-1), Secure Hash Algorithm 256(Secure Hash Algorithm 256, SHA-256), etc.).

It is to be understood that AH in the packet encapsulation diagrams shown in fig. 2 or fig. 4 is used separately. The technical scheme of the application can also be applied to scenes in which AH and ESP are jointly used.

Fig. 3 is a schematic flowchart of a method for transmitting a multicast packet according to an embodiment of the present application. Fig. 3 is a diagram illustrating the present invention in conjunction with the system 100 shown in fig. 1.

301, the node a receives a first multicast packet sent by a source device.

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

The source device may be a host or a network device (e.g., a CE device).

Node a determines the ICV in the AH from the first IP header 302.

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

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 K, and K is a positive integer greater than or equal to 1. For example, K may be equal to 8, 16, 32, or 64, etc.

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

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

Alternatively, in other embodiments, the preset value may be other types of preset values. For example, the preset value may be a repetition of 01. For another example, the preset value is 0 at the front 1/2 and 1 at the back 1/2. 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 node a calculates the ICV in the same way as described above, except that the destination IP address in the second IP header is replaced with a preset value.

303, the node a encapsulates the first multicast packet to obtain a second multicast packet, where the second multicast packet includes a second IP header, an AH, and the first multicast packet.

And the node A encapsulates the outer IP head and AH of the first multicast message to obtain a second multicast message. Wherein the outer IP header is the second IP header and the ICV in the AH is the ICV determined in step 302.

304, the node a sends the second multicast packet to the node B.

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

And 305, the node B sends the received second multicast message to the node C and the node E.

It can be understood that if the second multicast packet 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 packet, and sends the multicast packet with the modified outer layer destination IP address and bit string to node C and node E. For convenience of description, however, the method shown in fig. 3 does not distinguish between multicast packets received by node B from node a and multicast packets sent by node B to node C and node E.

306, node C sends the received second multicast message to node D.

Step 306, like step 305, also does not distinguish between multicast packets received by node C from node B and multicast packets sent to node D.

307, node D computes the ICV from the first IP header. For ease of distinction, the ICV determined in step 307 will be referred to hereinafter as the first ICV and the ICV determined in step 302 will be referred to hereinafter as the second ICV. Node D computes the ICV in the same manner as node a.

Node D determines 308 whether the first ICV is the same as the second ICV. And if the first ICV is the same as the second ICV, the second multicast message passes the integrity check. In this case, the node D may decapsulate the second multicast packet to obtain the first multicast packet. And the node D determines the equipment to which the first multicast message is sent according to the destination address of the first multicast message. And if the first ICV is different from the second ICV, the second multicast message is not subjected to integrity check. In this case, the node D may delete the second multicast packet directly.

The mode of processing the received second multicast packet by the node E is the same as the mode of processing the received multicast packet by the node D, and for brevity, the description is omitted here.

The method shown in fig. 3 may be applied to BIERv 6. In this case, in step 303, the encapsulating, by the node a, the first multicast packet to obtain a second multicast packet may include: the node a encapsulates the first multicast packet by using BIERv6 to obtain a second multicast packet. In this case, the outer IP header of the second multicast packet (i.e., the second IP header) is an IPv6 header. In this case, the preset value may be 128 0 or 128 1 or other types of preset values (e.g., 0 for the front 64 bits and 1 for the back 64 bits).

The method shown in fig. 3 may be applied to IP head-end replication. In this case, in step 303, the encapsulating, by the node a, the first multicast packet to obtain a second multicast packet may include: and the node A utilizes the IP head end to copy and package the first multicast message to obtain the second multicast message. In this case, the second multicast packet obtained by the node a may be as shown in fig. 2. For example, if the second multicast packet is the multicast packet 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 0, or 128 1, or 128 other types of preset values.

If the ICV in the multicast packet transmitted in the network is determined by using the method shown in fig. 3, after receiving the multicast packet, the intermediate devices (e.g., node B and node C) in the network may not need to modify the ICV in the AH of the multicast packet. Thus, the intermediate device in the network does not need to store information such as a key required for calculating the ICV and does not need to calculate the ICV, so that the workload of the intermediate device can be reduced.

Optionally, in some embodiments, the node a may obtain an indication. The indication information is used to indicate whether the ICV can be calculated using a preset value instead of the destination IP address in the outer IP header. For example, the value of the indication information may be positive (tune) or negative (false). If the value of the indication information is positive, the node A can use a preset value to calculate the ICV; if the value of the indication is negative, the node A may use the ICV calculated by the destination IP address in the outer IP header. The intermediate device and the destination device in the network may also obtain the indication information. In this case, the intermediate device may determine whether to recalculate the ICV according to the indication information when forwarding the packet. The destination device may also determine whether to use a preset value in place of the destination IP address in the outer IP header when calculating the ICV based on the indication information when authenticating the ICV.

Optionally, in some embodiments, the node a may obtain a configuration information (e.g., Security Association (SA), Security Policy (SP), etc.). The configuration information may include indication information indicating whether the ICV can be calculated using a preset value instead of the destination IP address in the outer IP header. The indication information may also be referred to as an indication, or a destination address quiesce indication, etc. The node a may determine whether to calculate the ICV using a preset value instead of the destination IP address in the outer IP header according to the destination address silence indication in the SA or SP. The intermediate device and the destination device in the network may also acquire the SA or SP. In this case, the intermediate device may determine whether to recalculate the ICV according to the destination address silence indication in the SA or SP when forwarding the packet. 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 silence indication in the SA or the SP when verifying the ICV.

For convenience of description, hereinafter, a first scheme is used to represent a scheme of calculating an ICV using a preset value instead of a destination IP address in an outer IP header, and a second scheme is used to represent a scheme of calculating an ICV using a destination IP address in an 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 node A determines that the number of destination devices is greater than or equal to 2, node A may calculate the ICV using the first scheme. If the node A determines that the number of destination devices is 1, the node A may calculate the ICV using the second scheme. The node a may indicate the ICV computation method of the second multicast packet using a field in the outer IP header or AH or other header of the second multicast packet. In other words, a header (e.g., an IP header, or an AH or other header field) of the second multicast packet may include an indication information (which may be referred to as ICV calculation indication information) for indicating whether the ICV is determined by the first scheme or the second scheme. In this way, the intermediary may determine from the indication whether it needs to recalculate the ICV. 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 based on the indication information.

Alternatively, in other embodiments, the network devices in the network may be directly configured to compute the ICV using only the first scheme. In other words, in this case, the network devices in the network do not compute the ICV using the second scheme. The source device (i.e., node a in the method shown in fig. 3), the intermediate device, and the destination device also need not determine the method of calculating the ICV from the configuration information or the indication information.

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

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

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

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

The network equipment encapsulates the outer IP head and AH of the first multicast message to obtain a second multicast message. Wherein the outer IP header is the second IP header and the ICV in the AH is the ICV determined in step 502.

504, the second multicast packet is sent to the destination device.

The destination device may be another network device.

The network device in the method of fig. 5 may be node a in the method of fig. 3. Specific implementation and beneficial effects of each step of the method shown in fig. 5 can refer to the method shown in fig. 3, and are not described herein again.

601, 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.

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

603, the first network device determining whether a second ICV is the same as the first ICV, wherein the second ICV is the ICV in the AH.

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

The destination device may be a host or a network device (e.g., a CE device).

The first network device in the method of fig. 6 may be node D or node F in the method of fig. 3. If the first network device is node E in the method shown in fig. 3, the second network device may be node B in the method shown in fig. 3. If the first network device is node D in the method shown in fig. 3, the second network device may be node C in the method shown in fig. 3. The steps and advantages of the method shown in fig. 6 can be referred to the method shown in fig. 3, and are not described herein again.

Fig. 7 is a schematic structural block diagram of a communication device according to an embodiment of the present application. The communication apparatus 700 shown in fig. 7 may be a network device or a component (e.g., a chip, a system-on-chip, or a circuit) in the network device in the method shown in fig. 5. The communication apparatus 700 shown in fig. 7 may also be node a or a component (e.g., a chip, a system-on-chip, or a circuit, etc.) in node a in the method shown in fig. 3. As shown in fig. 7, the communication apparatus 700 includes a receiving unit 701, a processing unit 702, and a transmitting unit 703.

A receiving unit 701, configured to receive a first multicast packet sent by a source device.

A processing unit 702, configured to determine an integrity check value ICV in an authentication header AH according to a first internet protocol IP header, where the first IP header is obtained by replacing a destination address field of a second IP header with a preset value, and a 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 packet to obtain a second multicast packet, where the second multicast packet includes the second IP header, the AH, and the first multicast packet.

A sending unit 703, configured to send the second multicast packet to a destination device.

Optionally, the processing unit 702 is further configured to obtain indication information, where the indication information is used to indicate that the ICV is determined 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 processing unit 702 is specifically configured to encapsulate the first multicast packet based on BIERv6 to obtain the second multicast packet; or the first multicast message is encapsulated based on IP head end copy to obtain the second multicast message.

If the communication apparatus 700 is a network device in the method shown in fig. 5 or a 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 apparatus 700 is a component in a network device in the method shown in fig. 5 or a component in a node a in the method shown in fig. 3, the receiving unit 701 and the sending unit 703 may be implemented by an input/output interface or an input/output circuit, and the processing unit 702 may be implemented by a logic circuit.

Specific functions and advantageous effects of the receiving unit 701, the processing unit 702, and the sending unit 703 may refer to the embodiments shown in fig. 3 or fig. 5, and are not described herein again for brevity.

Fig. 8 is a schematic structural block diagram of a communication device according to an embodiment of the present application. The communication apparatus 800 shown in fig. 8 may be a first network device or a component (e.g., a chip, a system-on-chip, or a circuit, etc.) in a first network device in the method shown in fig. 6. The communication apparatus 800 shown in fig. 8 may also be a node D (or E) or a component (e.g., a chip, a system-on-chip, or a circuit, etc.) in the node D (or E) in the method shown in fig. 3. As shown in fig. 8, the communication apparatus 800 includes a receiving unit 801, a processing unit 802, and a transmitting 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.

A processing unit 802, configured to determine a first integrity check value ICV according to a first internet protocol IP header, where the first IP header is obtained by replacing a destination address field of the second IP header with a preset value, and a destination IP address in the second IP header is different from the preset value;

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

A sending unit 803, configured to send the first multicast packet to a 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 indicate that the destination address field of the second IP header is replaced by the preset value, and then the first ICV is determined.

Optionally, the second multicast message is based on a multicast message encapsulated by BIERv 6; or the second multicast message is a multicast message based on IP head end copy encapsulation.

If the communication apparatus 800 is a first network device in the method shown in fig. 6 or a 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 be implemented by a processor.

If the communication apparatus 800 is a component in a first network device in the method shown in fig. 6 or a component in a node D (or E) in the method shown in fig. 3, the receiving unit 801 and the sending unit 803 may be implemented by an input/output interface or an input/output circuit, and the processing unit 802 may be implemented by a logic circuit.

Specific functions and advantageous effects of the receiving unit 801, the processing unit 802, and the sending unit 803 may refer to the embodiments shown in fig. 3 or fig. 6, and for brevity, no further description is provided here.

Fig. 9 is a block diagram of a network device according to an embodiment of the present invention. As shown in fig. 9, network device 900 includes a processor 901, a memory 902. The processor 901 may be used for processing communication protocols and communication data, controlling network devices, executing software programs, processing data of software programs, and the like. The memory 902 is used primarily for storing software programs and data.

For ease of illustration, only one memory and processor are shown in FIG. 9. In an actual network device product, there may be one or more processors and one or more memories. The memory may also be referred to as a storage medium or a storage device, etc. The memory may be provided independently of the processor, or may be integrated with the processor, which is not limited in this embodiment.

In the embodiment of the present application, a circuit having a transceiving function may be regarded as the transceiver 903 of the network device, and a processor having a processing function may be regarded as a processing unit of the network device. A transceiver may also be referred to as a transceiver unit, transceiver, transceiving means, etc. A processing unit may also be referred to as a processor, a processing board, a processing module, a processing device, or the like. Alternatively, a device in the transceiver 903 for implementing a receiving function may be regarded as a receiving unit, and a device in the transceiver 903 for implementing a transmitting function may be regarded as a transmitting unit, that is, the transceiver 903 includes a receiving unit and a transmitting unit. A receiving unit may also be referred to as a receiver, a receiving circuit, or the like. A transmitting unit may also sometimes be referred to as a transmitter, or a transmitting circuit, etc.

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

The method disclosed in the above embodiments 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 having signal processing capabilities. In implementation, the steps of the above method may be implemented by integrated logic circuits of hardware or instructions in the form of software in the processor 901.

Optionally, in some embodiments, the memory 902 may store instructions for performing a method as performed by node a in the method illustrated in fig. 3. The processor 901 may execute the instructions stored in the memory 902 to complete the steps performed by the node a in the method shown in fig. 1 in combination with other hardware (e.g. the transceiver 903), and specific working procedures and beneficial effects may refer to the description in the embodiment shown in fig. 3.

Optionally, in some embodiments, the memory 902 may store instructions for performing a method performed by node D in the method shown in fig. 3. The processor 901 may execute the instructions stored in the memory 902 to complete the steps performed by the node D in the method shown in fig. 1 in combination with other hardware (e.g. the transceiver 903), and specific working procedures and beneficial effects may refer to the description in the embodiment shown in fig. 3.

Optionally, in some embodiments, memory 902 may store instructions for performing a method performed by node E in the method of fig. 3. The processor 901 may execute the instructions stored in the memory 902 to complete the steps performed by the node E in the method shown in fig. 3 in combination with other hardware (e.g. the transceiver 903), and specific working procedures and beneficial effects may refer to the description in the embodiment shown in fig. 3.

Optionally, in some embodiments, memory 902 may store instructions for performing a method performed by a network device, such as the method illustrated in fig. 5. The processor 901 may execute the instructions stored in the memory 902 to complete the steps performed by the network device in the method shown in fig. 5 in combination with other hardware (e.g., the transceiver 903), and specific working procedures and advantages may refer to the description in the embodiment shown in fig. 5.

Optionally, in some embodiments, the memory 902 may store instructions for performing a method performed by the first network device in the method illustrated in fig. 6. The processor 901 may execute the instructions stored in the memory 902 to complete the steps performed by the first network device in the method shown in fig. 6 in combination with other hardware (e.g., the transceiver 903), and specific working procedures and beneficial effects may refer to the description in the embodiment shown in fig. 6.

In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor. To avoid repetition, it is not described in detail here.

It should be noted that the processor in the embodiments of the present application may be an integrated circuit chip having signal processing capability. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

The chip in this embodiment of the application may be a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a system on chip (SoC), a Central Processing Unit (CPU), a Network Processor (NP), a digital signal processing circuit (DSP), a Microcontroller (MCU), a programmable logic controller (PLD), other programmable logic devices, a discrete gate or transistor logic device, a discrete hardware component, or other integrated chips.

The memory in the embodiments of the present application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), double data rate SDRAM, enhanced SDRAM, SLDRAM, Synchronous Link DRAM (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

According to the method provided by the embodiment of the present application, the present application further provides a computer program product, which includes: computer program code which, when run on a computer, causes the computer to perform the method of any of the embodiments shown in fig. 3, 5 or 6.

There is also provided a computer readable medium having program code stored thereon, which when run on a computer causes the computer to perform the method of any one of the embodiments shown in fig. 3, 5 or 6, according to the method provided by the embodiments of the present application.

According to the method provided by the embodiment of the present application, the present application further provides a system, which includes the foregoing one or more network devices.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

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

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. a method for transmitting multicast message, is characterized in that, 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 is to replace the destination address field of the second IP header with a preset After obtaining the value, the destination IP address in the second IP header is different from the preset value;

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

Send the second multicast packet to the destination device.

2 . The method according to claim 1 , further comprising: acquiring, by the network device, indication information, wherein the indication information is used to indicate that the second IP header is replaced with the preset value. 3 . The ICV is determined after the destination address field of the section.

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 encapsulates the first multicast packet to obtain a second multicast packet, comprising:

The network device encapsulates the first multicast message by using bit-index-based explicit replication Internet Protocol Version 6 encapsulation to obtain the second multicast message; or

The network device encapsulates the first multicast packet based on IP head-end replication to obtain the second multicast packet.

5. A method for transmitting multicast packets, wherein the method comprises:

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

The first network device determines the first integrity check value ICV according to the first IP header of the Internet Protocol, wherein the first IP header is to replace the destination address field of the second IP header with a predetermined value. Obtained after setting the value, 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 a destination device when the second ICV is the same as the first ICV.

6 . The method according to claim 5 , further comprising: the first network device acquiring indication information, the indication information being used to instruct to use the preset value to replace the second IP address. 7 . The first ICV is determined after the destination address field of the header.

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 based on a bit-indexed display-replicated multicast message encapsulated in the sixth edition of the Internet Protocol; or The second multicast packet is a multicast packet based on the replication and encapsulation of the IP headend.

9. A communication device, comprising:

a receiving unit, configured to receive the first multicast message 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 IP header of the Internet protocol, wherein the first IP header is to replace the destination address field of the second IP header with a predetermined value. Obtained after setting the value, 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 packet to obtain a second multicast packet, wherein the second multicast packet includes the second IP header, the AH and the the first multicast packet;

A sending unit, configured to send the second multicast packet to the destination device.

10 . The apparatus according to claim 9 , wherein the processing unit is further configured to obtain indication information, wherein the indication information is used to indicate that the preset value is used to replace the second IP header. 11 . The ICV is determined after the destination address field.

The apparatus 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 the Internet Protocol Version 6 encapsulation of bit index-based display replication to the first multicast packet is encapsulated to obtain the second multicast packet; or

The first multicast packet is encapsulated based on IP head-end replication to obtain the second multicast packet.

13. A communication device, comprising:

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;

A processing unit, configured to determine the first integrity check value ICV according to the first IP header of the Internet Protocol, wherein the first IP header is to replace the destination address field of the second IP header with a preset After obtaining 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;

A sending unit, configured to send the first multicast packet to a destination device when the second ICV is the same as the first ICV.

14. The apparatus according to claim 13, wherein the processing unit is further configured to acquire indication information, wherein the indication information is used to indicate the purpose of replacing the second IP header with the preset value The first ICV is determined after the address field.

The apparatus 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 based on a bit-indexed display-replicated Internet Protocol Version 6 encapsulated multicast message; or The second multicast packet is a multicast packet based on the replication and encapsulation of the IP headend.

17. A computer device, characterized in that it comprises: a processor, which is coupled to a memory, reads and executes instructions and/or program codes in the memory, so as to execute as claimed in claims 1-4, Alternatively, the method of any one of 5 to 8.

18. A chip system, characterized by comprising: a logic circuit, which is used for coupling with an input/output interface, and transmitting data through the input/output interface, so as to perform the steps of claims 1-4, or, The method of any one of 5 to 8.

19. A computer-readable medium, characterized in that, the computer-readable medium stores program codes, which, when the computer program codes are executed on a computer, cause the computer to execute claims 1-4, or, 5 to 5. The method of any one of 8.