Packet transmission methods, network devices, and systems

Abstract

The present application discloses a packet transmission method, a network device, and a system. After receiving a first packet, the first network device obtains a tunnel header corresponding to the first packet. The first network device encapsulates the tunnel header in an IPv6 header by encapsulating the IPv6 header in the first packet to obtain a second packet. Since the first network device transmits the second packet to a second network device, the second network device forwards the packet based on the tunnel header included in the IPv6 header. In the present application, the IPv6 header is used to carry the tunnel header. No additional UDP header needs to be encapsulated to carry the tunnel header. This reduces the amount of data for packet encapsulation and improves the efficiency of packet transmission.

Description

Technical Field

[0001] This application claims the priority of Chinese Patent Application No. 202111672776.4, titled "METHOD FOR IMPLEMENTING VXLAN AND GTP BASED ON IPv6", filed with the China National Intellectual Property Administration on December 31, 2021, which is incorporated herein by reference in its entirety. This application claims the priority of Chinese Patent Application No. 202210229154.2, titled "PACKET TRANSMISSION METHOD, NETWORK DEVICE, AND SYSTEM", filed on March 8, 2022, which is incorporated herein by reference in its entirety.

[0002] This application generally relates to the field of communication technologies, and specifically to packet transmission methods, network devices, and systems.

Background Art

[0003] A virtual extensible local area network (VXLAN) is an overlay network technology. To implement cross-region Layer II interconnection, a Layer II Ethernet tunnel can be established over a Layer III network. VXLAN technology uses an encapsulation format in which the original Ethernet packet is encapsulated within a User Datagram Protocol (UDP) data packet, with the original Layer II data frame and VXLAN header encapsulated together in the UDP data packet. Because UDP is used as a transmission method at an outer layer, the original Ethernet packet can be transmitted over a Layer II or Layer III network. The VXLAN header includes a VXLAN network identifier (VNI), which occupies 24 bits in the data packet. Therefore, up to 16 million VXLANs can coexist, allowing for large-scale tenant deployments.

[0004] With the development and deployment of Internet Protocol version 6 (IPv6) technology, traffic from various tenants may need to traverse IPv6 networks. Therefore, there is an urgent need to deploy VXLAN technology on IPv6 networks. However, because UDP encapsulation is used in VXLAN, the encapsulation efficiency on IPv6 networks is low, affecting packet transmission efficiency. [Overview of the project] [Means for solving the problem]

[0005] This application provides a packet transmission method, network device, and system for reducing the amount of data required for packet encapsulation when packets travel through an IPv6 network, improving the efficiency of packet encapsulation, and further improving the efficiency of packet transmission.

[0006] A packet transmission method is provided according to a first aspect of this application. This method includes: a first network device receiving a first packet and obtaining a tunnel header based on the first packet; the first network device encapsulating an IPv6 header in the first packet to receive a second packet; the IPv6 header carrying the tunnel header; the IPv6 header being used to carry the tunnel header; no additional UDP headers need to be encapsulated to carry the tunnel header; this reduces the amount of data for packet encapsulation and improves the efficiency of packet encapsulation; in addition, including the tunnel header in the IPv6 header provides a novel way for packets to travel through an IPv6 network; this method does not require the use of a UDP header to carry the tunnel header; since the IPv6 header is the basic packet encapsulation method when packets are forwarded over an IPv6 network, this method improves the flexibility of packet encapsulation.

[0007] In one possible implementation, the tunnel header may include one or more of the following: VXLAN header, general packet radio service tunneling protocol (GTP) header, generic routing encapsulation (GRE) header, IP-in-IP header, intra-site automatic tunnel addressing protocol (ISATAP) header, Internet Protocol version 4 over IPv6 (IPv4 over IPv6) header, network virtualization using generic routing encapsulation (NVGRE), layer two tunneling protocol version 3 (L2TPv3) header, and multi-protocol label switching in GRE (MPLS in GRE) header.

[0008] In one possible implementation, the IP header is an IPv6 extension header, and the IPv6 extension header includes a destination option header (DOH). Optionally, encapsulating the IPv6 header in a first packet for a first network device to receive a second packet includes: the first network device encapsulates the IPv6 extension header and the IPv6 base header in the first packet; the DOH in the IPv6 extension header carries the tunnel header, and the IPv6 base header is used for packet forwarding.

[0009] In one possible implementation, the DOH includes a type-length-value (TLV), and the type field of the TLV indicates that the DOH carries the tunnel header.

[0010] In one possible implementation, when the tunnel header is a VXLAN header or a GTP header, the IPv6 extension header further includes a segment routing header (SRH). The length of the VXLAN header or GTP header (e.g., 64 bits) is shorter than the length of another tunnel header (e.g., 128 bits). Therefore, the segment routing header (SRH) can be used to carry the VXLAN header or GTP header.

[0011] In one possible implementation, the tunnel header is carried in the segment identifier (SID) list of the SRH. Optionally, the tunnel header is carried in the SID corresponding to the second network device in the SRH's segment list (SID list). In IPv6 forwarding plane-based segment routing (SRv6) application scenarios, when some or all of a path needs to be explicitly specified, the SRH may be included in the packet to indicate the explicit path by using the SID list within the SRH. The length of each SID in the SID list is defined as 128 bits. In the packet forwarding process, the information about the SID used for packet forwarding is usually only a portion of the 128 bits, or the SID advertised by the network device may be a compressed SID, which occupies only a portion of the 128 bits, for example, only 64 bits. In this way, the VXLAN header or GTP header is included in the SID of the second network device in the SID list, which is not occupied, and the segment identifier list in the segment routing header of the IPv6 extension header is multiplexed. No additional encapsulation is required to carry the VXLAN or GTP header. This improves the efficiency of packet encapsulation.

[0012] In one possible implementation, the SID of a second network device instructs the second network device to forward packets based on the tunnel header carried in the SID. The SID of the second network device includes a locator field and a function field. Optionally, the SID of the second network device may further include an argument field.

[0013] In one possible implementation, the VXLAN header or GTP header may be carried in the functional field of the SID of a second network device.

[0014] In one possible implementation, when the tunnel header is a VXLAN header or a GTP header, the IPv6 header is an IPv6 basic header. The IPv6 basic header contains basic packet forwarding information, including, for example, a source address field and a destination address field. The source address field is used to carry the source address of the packet, and the destination address field is used to carry the destination address of the packet.

[0015] In one possible implementation, the tunnel header is carried in the destination address field of the IPv6 base header. Since the destination address field of the IPv6 base header is 128 bits, the prefix information or SRv6 locator used for packet forwarding in the packet forwarding process typically occupies only a portion of these 128 bits, for example, the first 64 bits. In this way, the VXLAN header or GTP header is included in the bits within the destination address field that are not occupied by the prefix information or SRv6 locator, thus multiplexing the destination address field of the IPv6 base header. No additional encapsulation is required to carry the VXLAN header or GTP header. This improves the efficiency of packet encapsulation.

[0016] In one possible implementation, bits 65 through 128 of the endpoint address field carry the tunnel header.

[0017] In one possible implementation, the destination address in the destination address field instructs a second network device to forward the packet based on the tunnel header carried in the destination address field.

[0018] In one possible implementation, the flow label field in the IPv6 header carries the port number.

[0019] In one possible implementation, the port number is used to perform load balancing in the forwarding process of the second packet, or to indicate the type of the second packet. For example, when the tunnel header is a VXLAN header, the port number indicates that the second packet is a VXLAN packet.

[0020] In one possible implementation, the port number carried in the flow label may be obtained through a calculation based on the payload in the first packet to ensure that the load balancing effect achieved in the forwarding process of the second packet matches the load balancing effect achieved by using the UDP source port number. The calculation method used to calculate the port number based on the payload in the first packet may reuse the calculation method for the UDP source port number.

[0021] In one possible implementation, the acquisition of a tunnel header by a first network device based on a first packet includes: the first network device acquiring a tunnel header based on the interface for receiving the first packet; and the tunnel header corresponding to the interface for receiving the first packet.

[0022] In one possible implementation, the Next Header of the IPv6 header indicates that the next header adjacent to the IPv6 header in the second packet is an Ethernet header. The IPv6 header is used to carry the tunnel header, and it is not necessary to use a UDP header to carry the tunnel header in the packet. Therefore, the next header of the IPv6 header is set to the Ethernet (ETH) type. This can thus improve the efficiency of packet processing in the forwarding process of the second packet.

[0023] According to a second aspect of the present application, a packet transmission method is provided. This method includes the following. A second network device receives a second packet from a first network device. The second packet is encapsulated using an Internet Protocol Version 6 (IPv6) header, and the IPv6 header carries a tunnel header. The second network device obtains the tunnel header from the IPv6 header. The second network device decapsulates the second packet to obtain a first packet. The first packet does not include an IPv6 header. The second network device forwards the first packet based on the tunnel header.

[0024] In a possible implementation, the tunnel header includes one or more of a VXLAN header, a GTP header, a GRE header, an IP-in-IP header, an ISATAP header, an IPv4 over IPv6 header, an NVGRE header, an L2TPv3 header, and an MPLS in GRE header.

[0025] In a possible implementation, the IP header is an IPv6 extension header, and the IPv6 extension header includes an Endpoint Option Header DOH.

[0026] In a possible implementation, the Options portion included in the DOH carries the tunnel header.

[0027] In a possible implementation, when the tunnel header is a VXLAN header or a GTP header, the IPv6 extension header further includes a Segment Routing Header SRH.

[0028] In a possible implementation, the tunnel header is carried in the SID list of the SRH.

[0029] In a possible implementation, the tunnel header is carried in the SID corresponding to the second network device in the SID list of the SRH.

[0030] In one possible implementation, the second network device obtaining a tunnel header from the IPv6 header includes the following. The second network device determines that the destination address field of the second packet includes the SID of the second network device. In response to the determination that the destination address field of the second packet includes the SID of the second network device, the second network device obtains a tunnel header from the SID of the second network device.

[0031] In one possible implementation, the type of the SID of the second network device is a virtual network endpoint (Endpoint with decapsulation and VXLAN table lookup use, END.VN) type. The SID is an SRv6 SID. The locator part of the SID includes the address of the tunnel endpoint, and the function part of the SID includes the tunnel header. The forwarding operation corresponding to the behavior of the SID includes the following. After receiving a packet, the destination tunnel endpoint obtains the corresponding instance's forwarding table based on the tunnel header in the SID in the packet, decapsulates the packet, searches the forwarding table based on the MAC address in the Payload, etc., and forwards the packet. Decapsulating the packet includes removing the IPv6 base header encapsulated in the second packet to obtain the first packet, or removing the IPv6 base header and IPv6 extension headers encapsulated in the second packet to obtain the first packet.

[0032] Optionally, the SID corresponding to the address of the second network device is an END.VN type SID.

[0033] Optionally, the SID corresponding to the address of the second network device is the SRv6 locator of the second network device. In one possible implementation, before the second network device receives the second packet from the first network device, the method further includes: the second network device advertises its SID to the first network device.

[0034] In one possible implementation, the method further includes: A second network device establishes a forwarding entry. The forwarding entry includes the SID of the second network device. The second network device decapsulates the second packet based on the forwarding entry to obtain the first packet and forwards the first packet based on the VNI.

[0035] In one possible implementation, when the tunnel header is a VXLAN header or a GTP header, the IPv6 header is an IPv6 basic header.

[0036] In one possible implementation, the tunnel header is carried in the destination address field of the IPv6 base header.

[0037] In one possible implementation, for a second network device to obtain the tunnel header from the IPv6 header includes: The second network device determines that the destination address field contains the address of the second network device. In response to the determination that the destination address field contains the address of the second network device, the second network device obtains the tunnel header from the destination address field.

[0038] A third aspect of this application provides a method for transmitting VXLAN packets. This method includes: A first network device receives a first packet and obtains a VNI based on the first packet. The first network device encapsulates an IPv6 header in the first packet to obtain a second packet. The IPv6 header carries the VNI. The first network device transmits the second packet to a second network device. After obtaining the VNI corresponding to the first packet, the first network device encapsulates an IPv6 header in the first packet, and it is found that the IPv6 header includes the VNI. No additional UDP header needs to be encapsulated to carry the VNI. This reduces the amount of data for packet encapsulation and improves the efficiency of packet encapsulation. In addition, including the VNI in the IPv6 header provides a novel way for VXLAN packets to traverse an IPv6 network. This method does not require the use of a UDP header to carry the VNI. Since the IPv6 header is the basic packet encapsulation method when packets are forwarded over an IPv6 network, this method improves the flexibility of VXLAN packet encapsulation.

[0039] In one possible implementation, the way the IPv6 header carries the VNI may be by adding the VNI to the IPv6 header, or by encapsulating the VXLAN header in the IPv6 header.

[0040] In one possible implementation, the IPv6 header is the IPv6 basic header.

[0041] In one possible implementation, the VNI is carried in the destination address field of the IPv6 base header. Since the destination address field of the IPv6 base header is 128 bits, the prefix information or SRv6 locator used for packet forwarding in the packet forwarding process typically occupies only a portion of these 128 bits, for example, the first 64 bits. In this way, the VNI is included in the bits within the destination address field that are not occupied by the prefix information or SRv6 locator, thus multiplexing the destination address field of the IPv6 base header. No additional header is required to encapsulate the VNI. This improves the efficiency of packet encapsulation.

[0042] In one possible implementation, bits 65 through 128 of the endpoint address field carry the VNI.

[0043] In one possible implementation, the destination address field includes the VXLAN header, which carries the VNI. Since the VXLAN header occupies 64 bits, it can be carried entirely in the destination address field. In addition to the VNI, the VXLAN header further includes some directive information used for VXLAN packet forwarding. Because the complete VXLAN header is carried in the destination address field, packet forwarding reliability is improved.

[0044] In one possible implementation, bits 65 through 128 of the destination address field carry the VXLAN header.

[0045] In one possible implementation, the destination address in the destination address field instructs a second network device to forward the packet based on the VNI information carried in the destination address field.

[0046] In one possible implementation, the IPv6 header is an IPv6 extension header, and the IPv6 extension header contains either a DOH or SRH. Optionally, encapsulating the IPv6 header in a first packet for a first network device to receive a second packet includes: the first network device encapsulating the IPv6 extension header and the IPv6 base header in the first packet; the IPv6 extension header carries the VNI, and the IPv6 base header is used for packet forwarding.

[0047] In one possible implementation, the DOH contains a type-length value TLV, and the type field of the TLV indicates that the DOH carries a VNI.

[0048] In one possible implementation, the DOH is used to carry the VNI, or the DOH is used to carry the VXLAN header, and the VXLAN header carries the VNI.

[0049] In one possible implementation, the VNI is carried in the SID list of the SRH. Optionally, the VNI is carried in the SID corresponding to a second network device in the SID list. In IPv6 forwarding plane-based segment routing SRv6 application scenarios, when some or all of a path needs to be explicitly specified, the SRH may be included in the packet to indicate the explicit path by using the SID list within the SRH. The length of each SID in the SID list is defined as 128 bits. Information about the SID used for packet forwarding in the packet forwarding process is usually only a portion of the 128 bits, or the SID advertised by the network device may be a compressed SID, which occupies only a portion of the 128 bits, for example, only 64 bits. In this way, the VNI is included in the SID of the second network device in the SID list, in the unused bits, and the segment identifier list in the segment routing header of the IPv6 extension header is multiplexed. No additional headers are required to encapsulate the VNI. This improves the efficiency of packet encapsulation.

[0050] In one possible implementation, the SID of the second network device includes a VXLAN header, and the VXLAN header carries the VNI.

[0051] In one possible implementation, the SID of a second network device instructs the second network device to forward packets based on the VNI carried in the SID. After receiving the second packet, the second network device determines, based on the SID carried in the second packet, that it is the terminal node on a clear path and forwards the packet based on the VNI in the second packet. The SID of the second network device includes a locator field and a function field. Optionally, the SID of the second network device may further include an argument field.

[0052] In one possible implementation, the VNI is carried in the function field of the SID of the second network device.

[0053] In one possible implementation, the function field in the SID of the second network device contains a VXLAN header, and the VXLAN header carries the VNI.

[0054] In one possible implementation, the flow label in the IPv6 header carries the port number corresponding to the VXLAN packet.

[0055] In one possible implementation, the port number is used to perform load balancing in the forwarding process of the second packet, or the port number is used to determine that the second packet contains a VXLAN packet.

[0056] In one possible implementation, the source port number of a VXLAN packet is obtained through a calculation based on the payload of the VXLAN packet, for example, by performing a hash on the payload of the VXLAN packet using a hash algorithm. The port number value obtained from the VXLAN packet may be carried in the flow label of a second packet. The method for calculating the value of the flow label of the second packet is the same as the method for calculating the UDP source port number used for load balancing in the VXLAN packet. That is, the port number carried in the flow label is also obtained through a calculation based on the payload of the first packet to ensure that the load balancing effect achieved in the forwarding process of the second packet matches the load balancing effect achieved by using the conventional UDP source port number of the VXLAN packet.

[0057] In one possible implementation, the IPv6 header further includes VXLAN flags, which include flags indicating that the second packet carries a valid VNI.

[0058] In one possible implementation, the IPv6 header carries the VXLAN header, and the VXLAN header carries the VNI.

[0059] In one possible implementation, the Next Header of the IPv6 header indicates that the next header adjacent to the IPv6 header in the second packet is an Ethernet header. The IPv6 header is used to carry the VNI, and there is no need to use a UDP header to carry the VNI in the packet. Therefore, the next header of the IPv6 header is set to the Ethernet (ETH) type. This can thus improve the efficiency of packet processing in the forwarding process of the second packet.

[0060] In one possible implementation, a first network device obtaining a VNI based on a first packet includes: the first network device obtaining a VNI based on the interface for receiving the first packet; the VNI corresponds to the interface for receiving the first packet.

[0061] A fourth aspect of this application provides a method for transmitting VXLAN packets. This method includes: A second network device receives a second packet from a first network device. The second packet is encapsulated using an IPv6 header, the IPv6 header carrying a VNI. The second network device obtains the VNI from the IPv6 header. The second network device decapsulates the second packet to obtain the first packet. The first packet does not contain an IPv6 header. The second network device forwards the first packet based on the VNI.

[0062] In one possible implementation, the way the IPv6 header carries the VNI may be by adding the VNI to the IPv6 header, or by encapsulating the VXLAN header in the IPv6 header, where the VXLAN header includes the VNI.

[0063] In one possible implementation, the IPv6 header is the IPv6 basic header.

[0064] In one possible implementation, the VNI is carried in the destination address field of the IPv6 base header.

[0065] In one possible implementation, the destination address field includes a VXLAN header, and the VXLAN header carries the VNI.

[0066] In one possible implementation, bits 65 through 128 of the endpoint address field carry the VNI.

[0067] In one possible implementation, bits 65 through 128 of the endpoint address field carry the VXLAN header.

[0068] In one possible implementation, for a second network device to obtain a VNI from an IPv6 header includes: The second network device determines that the destination address field contains the address of the second network device. In response to the determination that the destination address field contains the address of the second network device, the second network device obtains a VNI from the destination address field.

[0069] In one possible implementation, before the second network device receives the second packet from the first network device, the method further includes: the second network device advertises its address to the first network device instructing the first network device to include the VNI of the VXLAN packet to be sent to the second network device in the second network device's address.

[0070] In one possible implementation, the IPv6 header is an IPv6 extension header, and the IPv6 extension header includes either a DOH or SRH.

[0071] In one possible implementation, the DOH contains a TLV, and the TLV's type field indicates that the DOH carries a VNI.

[0072] In one possible implementation, the DOH includes a VXLAN header, and the VXLAN header carries the VNI.

[0073] In one possible implementation, the VNI is carried in the SRH's SID list.

[0074] In one possible implementation, the VNI is carried in the SID corresponding to the second network device in the SRH's SID list.

[0075] In one possible implementation, the SID of the second network device includes a VXLAN header, and the VXLAN header carries the VNI.

[0076] In one possible implementation, for a second network device to obtain a VNI from an IPv6 header includes: The second network device determines that the destination address field of the second packet contains the SID of the second network device. In response to the determination that the destination address field of the second packet contains the SID of the second network device, the second network device obtains a VNI from the SID of the second network device.

[0077] In one possible implementation, the SID type of the second network device is of type END.VN. The SID is an SRv6 SID. The locator portion of the SID contains the address of the VXLAN tunnel endpoint (VTEP) of the VXLAN packet, and the function portion of the SID contains the VXLAN header. The forwarding operation corresponding to the behavior of the SID includes the following: After receiving the packet, the destination VTEP node retrieves the forwarding table of the corresponding VXLAN instance based on the VNI in the packet's SID, decapsulates the packet, searches the forwarding table based on the MAC address in the payload, etc., and forwards the packet. Decapsulating the packet includes removing the IPv6 basic header encapsulated in the second packet in order to obtain the first packet, or removing the IPv6 basic header and IPv6 extension header encapsulated in the second packet in order to obtain the first packet.

[0078] Optionally, the SID corresponding to the address of the second network device is of type END.VN.

[0079] Optionally, the SID corresponding to the address of the second network device is the SRv6 locator of the second network device.

[0080] In one possible implementation, before the second network device receives the second packet from the first network device, the method further includes: the second network device advertises its SID to the first network device in order to instruct the first network device to include the VNI of the VXLAN packet to be sent to the second network device in the second network device's SID.

[0081] In one possible implementation, the method further includes: A second network device establishes a forwarding entry. The forwarding entry includes the SID of the second network device. The second network device decapsulates the second packet based on the forwarding entry to obtain the first packet and forwards the first packet based on the VNI.

[0082] In one possible implementation, the flow label in the IPv6 header carries the port number corresponding to the VXLAN packet. Optionally, the port number is used to perform load balancing in the second packet forwarding process.

[0083] In one possible implementation, the IPv6 header further includes VXLAN flags, which include flags indicating that the second packet carries a valid VNI.

[0084] A fifth aspect of this application provides a method for transmitting GTP packets. This method includes: A first network device receives a first packet and obtains a tunnel endpoint identifier (TEID) based on the first packet. The first network device encapsulates an IPv6 header in the first packet to obtain a second packet. The IPv6 header carries the TEID. The first network device transmits the second packet to a second network device. That is, after obtaining the TEID corresponding to the first packet, the first network device encapsulates an IPv6 header in the first packet, including the TEID in the IPv6 header. No additional UDP header needs to be encapsulated to carry the TEID. This reduces the amount of data for packet encapsulation and improves the efficiency of packet encapsulation. In addition, including the TEID in the IPv6 header provides a new way for GTP packets to traverse an IPv6 network. This method does not require the use of a UDP header to carry the TEID. Since the IPv6 header is the basic packet encapsulation method when packets are forwarded over an IPv6 network, this method improves the flexibility of GTP packet encapsulation.

[0085] In one possible implementation, the way the IPv6 header carries the TEID may be by adding the TEID to the IPv6 header, or by encapsulating the GTP header in the IPv6 header, where the GTP header contains the TEID.

[0086] In one possible implementation, the IPv6 header is the IPv6 basic header.

[0087] In one possible implementation, the TEID is carried in the destination address field of the IPv6 base header. Since the destination address field of the IPv6 base header is 128 bits, the prefix information or SRv6 locator used for packet forwarding in the packet forwarding process typically occupies only a portion of these 128 bits, for example, the first 64 bits. In this way, the TEID is included in the bits within the destination address field that are not occupied by the prefix information or SRv6 locator, thus multiplexing the destination address field of the IPv6 base header. No additional header is required to encapsulate the TEID. This improves the efficiency of packet encapsulation.

[0088] In one possible implementation, the destination address field includes a GTP header, which carries the TEID. Since the GTP header occupies 64 bits, it can be carried entirely within the destination address field. In addition to the TEID, the GTP header further contains several directive information used for GTP packet forwarding. Because the complete GTP header is carried within the destination address field, packet forwarding reliability is improved.

[0089] In one possible implementation, the destination address in the destination address field instructs a second network device to forward the packet based on the TEID information carried in the destination address field.

[0090] In one possible implementation, the IPv6 header is an IPv6 extension header, and the IPv6 extension header contains either a DOH or SRH. Optionally, encapsulating the IPv6 header in a first packet for a first network device to receive a second packet includes: the first network device encapsulating the IPv6 extension header and the IPv6 base header in the first packet; the IPv6 extension header carries the VNI, and the IPv6 base header is used for packet forwarding.

[0091] In one possible implementation, the DOH contains a TLV, and the TLV's type field indicates that the DOH carries a TEID.

[0092] In one possible implementation, the DOH is used to carry the TEID, or the DOH is used to carry the GTP header, and the GTP header carries the TEID.

[0093] In one possible implementation, the TEID is carried in the SID list of the SRH. Optionally, the TEID is carried in the SID corresponding to a second network device in the SID list. In IPv6 forwarding plane-based segment routing SRv6 application scenarios, when some or all of a path needs to be explicitly specified, the SRH may be included in the packet to indicate the explicit path by using the SID list within the SRH. The length of each SID in the SID list is defined as 128 bits. Information about the SID used for packet forwarding in the packet forwarding process is usually only a portion of the 128 bits, or the SID advertised by the network device may be a compressed SID, which occupies only a portion of the 128 bits, for example, only 64 bits. In this way, the TEID is included in the SID of the second network device in the SID list, in the unused bits, and the segment identifier list in the segment routing header of the IPv6 extension header is multiplexed. No additional headers are required to encapsulate the TEID. This improves the efficiency of packet encapsulation.

[0094] In one possible implementation, the SID of the second network device includes a GTP header, which carries the TEID.

[0095] In one possible implementation, the SID of a second network device instructs the second network device to forward packets based on the TEID carried in the SID. After receiving the second packet, the second network device determines, based on the SID carried in the second packet, that it is the terminal node on a clear path and forwards the packet based on the TEID in the second packet. The SID of the second network device includes a locator field and a function field. Optionally, the SID of the second network device may further include an argument field.

[0096] In one possible implementation, the TEID is carried in the function field of the SID of the second network device.

[0097] In one possible implementation, the function field in the SID of the second network device contains a GTP header, and the GTP header carries the TEID.

[0098] In one possible implementation, the flow label in the IPv6 header carries the port number corresponding to the GTP packet.

[0099] In one possible implementation, the port number is used to perform load balancing in the forwarding process of the second packet, or the port number is used to determine whether the second packet contains a GTP packet.

[0100] In one possible implementation, the port number carried in the flow label may be obtained through a calculation based on the payload in the first packet to ensure that the load balancing effect achieved in the forwarding process of the second packet matches the load balancing effect achieved by using the UDP source port number. The calculation method used to calculate the port number based on the payload in the first packet may reuse the calculation method for the UDP source port number.

[0101] In one possible implementation, the IPv6 header also includes a TEID flag, which indicates that the second packet will carry the TEID.

[0102] In one possible implementation, the IPv6 header carries the GTP header, and the GTP header carries the TEID.

[0103] In one possible implementation, the Next Header of the IPv6 header indicates that the next header adjacent to the IPv6 header in the second packet is an Ethernet header. The IPv6 header is used to carry the TEID, and there is no need to use a UDP header to carry the TEID in the packet. Therefore, the next header of the IPv6 header is set to the Ethernet (ETH) type. Thus, the efficiency of packet processing in the forwarding process of the second packet can be improved.

[0104] In one possible implementation, the acquisition of a TEID by a first network device based on a first packet includes: The first network device acquires a TEID based on the interface for receiving the first packet. The TEID corresponds to the interface for receiving the first packet.

[0105] A sixth aspect of this application provides a method for transmitting a GTP packet. This method includes: A second network device receives a second packet from a first network device. The second packet is encapsulated using an IPv6 header, the IPv6 header carrying the TEID. The second network device obtains the TEID from the IPv6 header. The second network device decapsulates the second packet to obtain the first packet. The first packet does not contain an IPv6 header. The second network device forwards the first packet based on the TEID.

[0106] In one possible implementation, the way the IPv6 header carries the TEID may be by adding the TEID to the IPv6 header, or by encapsulating the GTP header in the IPv6 header, where the GTP header contains the TEID.

[0107] In one possible implementation, the IPv6 header is the IPv6 basic header.

[0108] In one possible implementation, the TEID is carried in the destination address field of the IPv6 base header.

[0109] In one possible implementation, the endpoint address field includes a GTP header, which carries the TEID.

[0110] In one possible implementation, for a second network device to obtain the TEID from the IPv6 header includes: The second network device determines that the destination address field contains the address of the second network device. In response to the determination that the destination address field contains the address of the second network device, the second network device obtains the TEID from the destination address field.

[0111] In one possible implementation, before the second network device receives the second packet from the first network device, the method further includes: the second network device advertises its address to the first network device instructing the first network device to include the TEID of the GTP packet to be sent to the second network device in the address of the second network device.

[0112] In one possible implementation, the IPv6 header is an IPv6 extension header, and the IPv6 extension header includes either a DOH or SRH.

[0113] In one possible implementation, the DOH contains a TLV, and the TLV's type field indicates that the DOH carries a TEID.

[0114] In one possible implementation, the DOH includes a GTP header, and the GTP header carries the TEID.

[0115] In one possible implementation, TEID is carried in the SRH's SID list.

[0116] In one possible implementation, the TEID is carried in the SID corresponding to the second network device in the SRH's SID list.

[0117] In one possible implementation, the SID of the second network device includes a GTP header, which carries the TEID.

[0118] In one possible implementation, for a second network device to obtain the TEID from the IPv6 header includes: The second network device determines that the destination address field of the second packet contains the SID of the second network device. In response to the determination that the destination address field of the second packet contains the SID of the second network device, the second network device obtains the TEID from the SID of the second network device.

[0119] In one possible implementation, the SID type of the second network device is of type END.VN. The SID is an SRv6 SID. The locator portion of the SID contains the address of the tunnel endpoint of the GTP packet, and the function portion of the SID contains the GTP header. The forwarding operation corresponding to the behavior of the SID includes the following: After receiving the packet, the destination tunnel endpoint retrieves the forwarding table of the corresponding instance based on the TEID in the SID, decapsulates the packet, searches the forwarding table based on the MAC address in the payload, etc., and forwards the packet. Decapsulating the packet includes removing the IPv6 basic header encapsulated in the second packet in order to obtain the first packet, or removing the IPv6 basic header and IPv6 extension header encapsulated in the second packet in order to obtain the first packet.

[0120] Optionally, the SID corresponding to the address of the second network device is of type END.VN.

[0121] Optionally, the SID corresponding to the address of the second network device is the SRv6 locator of the second network device.

[0122] In one possible implementation, before the second network device receives the second packet from the first network device, the method further includes: the second network device advertises its SID to the first network device instructing the first network device to include the TEID of the GTP packet to be sent to the second network device in the second network device's SID.

[0123] In one possible implementation, the method further includes: A second network device establishes a forwarding entry. The forwarding entry includes the SID of the second network device. The second network device decapsulates the second packet based on the forwarding entry to obtain the first packet and forwards the first packet based on the TEID.

[0124] In one possible implementation, the flow label in the IPv6 header carries the port number corresponding to the GTP packet. Optionally, the port number is used to perform load balancing in the second packet forwarding process.

[0125] In one possible implementation, the IPv6 header also includes a TEID flag, which indicates that the second packet will carry the TEID.

[0126] According to a seventh aspect of this application, a first network device is provided, configured to implement a method according to the first aspect or one of possible implementations of the first aspect, a method according to the third aspect or one of possible implementations of the third aspect, or a method according to the fifth aspect or one of possible implementations of the fifth aspect. Specifically, the first network device includes a unit configured to implement a method according to the first aspect or one of possible designs of the first aspect, a unit configured to implement a method according to the third aspect or one of possible implementations of the third aspect, or a unit configured to implement a method according to the fifth aspect or one of possible implementations of the fifth aspect.

[0127] According to an eighth aspect of this application, a second network device is provided, configured to implement a method according to the second aspect or one of possible implementations of the second aspect, a method according to the fourth aspect or one of possible implementations of the fourth aspect, or a method according to the sixth aspect or one of possible implementations of the sixth aspect. Specifically, the second network device includes a unit configured to implement a method according to the second aspect or one of possible designs of the second aspect, a unit configured to implement a method according to the fourth aspect or one of possible implementations of the fourth aspect, or a unit configured to implement a method according to the sixth aspect or one of possible implementations of the sixth aspect.

[0128] A ninth aspect of this application provides a network system for transmitting GTP packets. The network system includes a first network device and a second network device. The first network device is configured to implement a method according to one of the first aspect or a possible design of the first aspect, a method according to one of the third aspect or a possible implementation of the third aspect, or a method according to one of the fifth aspect or a possible implementation of the fifth aspect. The second network device is configured to implement a method according to one of the second aspect or a possible design of the second aspect, a method according to one of the fourth aspect or a possible implementation of the fourth aspect, or a method according to one of the sixth aspect or a possible implementation of the sixth aspect.

[0129] A network device is provided according to a tenth aspect of this application. The device includes a processor and memory. The memory is configured to store instructions or program code. The processor is configured to execute instructions or program code in memory in order to enable the network device to implement a method according to any one of the first aspect or a possible design of the first aspect, a method according to any one of the second aspect or a possible design of the second aspect, a method according to any one of the third aspect or a method according to any one of the third aspect, a method according to any one of the fourth aspect or a method according to any one of the fourth aspect, a method according to any one of the fifth aspect or a method according to any one of the fifth aspect, or a method according to any one of the sixth aspect or a method according to any one of the sixth aspect.

[0130] According to an eleventh aspect of this application, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions. When instructions are executed on a processor, a computer or network device is made capable of carrying out a method according to any one of the first aspect or a possible design thereof, a method according to the second aspect or a possible design thereof, a method according to the third aspect or a possible design thereof, a method according to the fourth aspect or a possible design thereof, a method according to the fifth aspect or a possible design thereof, or a method according to the sixth aspect or a possible design thereof.

[0131] A computer program product is provided according to a twelfth aspect of this application. The computer program product includes a program. When the program is executed on a processor, a computer or network device is made capable of carrying out a method according to any one of the first aspect or a possible design thereof, a method according to the second aspect or a possible design thereof, a method according to the third aspect or a possible design thereof, a method according to the fourth aspect or a possible design thereof, a method according to the fifth aspect or a possible design thereof, or a method according to the sixth aspect or a possible design thereof.

[0132] According to a thirteenth aspect of this application, a chip is provided which includes an interface circuit and a processor. The interface circuit is connected to the processor. The processor is configured to enable the chip to implement a method according to any one of the first aspect or a possible design of the first aspect, a method according to any one of the second aspect or a possible design of the second aspect, a method according to any one of the third aspect or a possible design of the third aspect, a method according to any one of the fourth aspect or a possible design of the fourth aspect, a method according to any one of the fifth aspect or a possible design of the fifth aspect, or a method according to any one of the sixth aspect or a possible design of the sixth aspect.

[0133] To more clearly illustrate the technical measures of the embodiments of this application and the existing technology, the accompanying drawings used to illustrate the embodiments or the existing technology are briefly introduced below. It is clear that the accompanying drawings in the following description show only some of the embodiments recorded in this application, and those skilled in the art can still derive other drawings from these accompanying drawings without creative effort. [Brief explanation of the drawing]

[0134] [Figure 1a] This is a schematic diagram of an application scenario for a VXLAN network according to one embodiment of this application. [Figure 1b] This is a schematic diagram of a VXLAN packet encapsulation structure according to one embodiment of this application. [Figure 1c] This is a schematic diagram of a GTP packet encapsulation structure according to one embodiment of this application. [Figure 2] This is a flowchart of a packet transmission method according to one embodiment of this application. [Figure 3a] This is a schematic diagram of the DOH format according to one embodiment of the present application. [Figure 3b] This is a schematic diagram of encapsulating a GRE header in a DOH according to one embodiment of this application. [Figure 3c] This is a schematic diagram of the format of a GRE header according to one embodiment of this application. [Figure 4a] This is a schematic diagram of the TLV format according to one embodiment of the present application. [Figure 4b] This is a schematic diagram illustrating the encapsulation of a GRE header by using a TLV according to one embodiment of this application. [Figure 5a] This is a schematic diagram of the SRH format according to one embodiment of the present application. [Figure 5b] This is a schematic diagram of the SID format according to one embodiment of the present application. [Figure 5c] This is a schematic diagram illustrating the encapsulation of a GTP header by using SID according to one embodiment of this application. [Figure 6a] This is a schematic diagram of the format of the IPv6 basic header according to one embodiment of this application. [Figure 6b] This is a schematic diagram illustrating how a GTP header is encapsulated by using a destination address field, according to one embodiment of this application. [Figure 7] This is a flowchart of a VXLAN packet transmission method according to one embodiment of this application. [Figure 8a] This is a schematic diagram of encapsulating a VNI in a destination address field according to one embodiment of the present application. [Figure 8b] This is another schematic diagram of encapsulating a VNI in a destination address field according to one embodiment of the present application. [Figure 8c] This is a schematic diagram of encapsulating a VXLAN header in a destination address field according to one embodiment of the present application. [Figure 9a] This is a schematic diagram of encapsulating VNI in DOH according to one embodiment of this application. [Figure 9b] This is a schematic diagram of encapsulating a VXLAN header in a DOH according to one embodiment of this application. [Figure 9c]This is another schematic diagram of encapsulating VNI in DOH according to one embodiment of the present application. [Figure 10a] This is a schematic diagram illustrating the encapsulation of a VNI by using a TLV according to one embodiment of this application. [Figure 10b] This is another schematic diagram of encapsulating a VXLAN header by using a TLV according to one embodiment of the present application. [Figure 11a] This is a schematic diagram of encapsulating a VNI in an SRH according to one embodiment of this application. [Figure 11b] This is a schematic diagram of encapsulating a VXLAN header in an SRH according to one embodiment of this application. [Figure 11c] This is another schematic diagram of encapsulating a VNI in an SRH according to one embodiment of the present application. [Figure 12] This is a schematic diagram of an application scenario according to one embodiment of this application. [Figure 13] This is a schematic diagram of the structure of a network device for GTP packet transmission according to one embodiment of the present application. [Figure 14] This is a schematic diagram of the structure of a network device for packet transmission according to one embodiment of the present application. [Figure 15] This is a schematic diagram of the structure of another network device for packet transmission according to one embodiment of the present application. [Figure 16] This is a schematic diagram of the structure of a network system for packet transmission according to one embodiment of the present application. [Figure 17] This is a schematic diagram of the structure of a network device according to one embodiment of this application. [Figure 18] This is a schematic diagram of the structure of another network device according to one embodiment of this application. [Modes for carrying out the invention]

[0135] To enable those skilled in the art to understand the methods provided in this application, the technical methods of the embodiments of this application will be clearly described below with reference to the accompanying drawings of the embodiments of this application. It will be clear that the embodiments described are only a selection, and not all, of the embodiments of this application.

[0136] Before describing specific technical measures, important terms and technologies in the embodiments of this application will be explained first.

[0137] VXLAN is a virtual tunneling technology. A logical tunnel is established over an Internet Protocol (IP) network between a source network device and a destination network device, and user packets are forwarded through that tunnel after specific encapsulation. For example, as shown in Figure 1a, a tunnel is established between two switches via VXLAN. Switch 1 encapsulates the original data frame sent by the source server, so the original data frame can be transmitted over the bearer network. After reaching Switch 2, which is connected to the destination server, the original data frame exits the VXLAN tunnel, is deconstructed, and forwarded to the destination server.

[0138] In a VXLAN network, the device that encapsulates and decapsulates the original data frame is the VTEP. The VTEP is an edge device in the VXLAN network and is the source and destination of the VXLAN tunnel. In Figure 1a, Switch 1 and Switch 2 are VTEPs. The VTEP may be an independent network device or a virtual switch within a server. The original data frame sent by the source server is encapsulated as a VXLAN packet on the VTEP and sent to other VTEPs in the IP network. The original data frame is restored through decapsulation and finally forwarded to the destination server.

[0139] A VNI is similar to a Virtual Local Area Network (VLAN) identifier (ID) and is used to distinguish VXLAN segments. Virtual machines in different VXLAN segments cannot communicate directly with each other at Layer 2. A VNI can also be understood as a user identifier. A VNI represents a tenant, and tenants belonging to different VNIs cannot communicate directly with each other at Layer 2. As shown in Figure 1a, when a VXLAN packet is encapsulated, a 24-bit length space is allocated to the VNI, so a VNI can support the isolation of many tenants. Specifically, VTEP encapsulates the VXLAN header, UDP header, external IP header, and external media access control (MAC) header in the original data sent by the source server.

[0140] Figure 1b is a schematic diagram of the structure including the VXLAN header and UDP header. The VXLAN header is 8 bytes long and contains a 24-bit VNI field for carrying the VNIs of different tenants in a VXLAN network. In addition, it contains a VXLAN flags field and two spare fields. The VXLAN flags field occupies 8 bits and can have a value of 00001000. The two spare bits occupy 24 bits and 8 bits, respectively.

[0141] The VXLAN header and the original data frame are used together as UDP data. The UDP header occupies 8 bytes. The UDP header includes the source port number, destination port number, UDP length, and UDP checksum. Each field occupies 16 bits. Optionally, the destination port number is fixed at 4789, and the source port number is determined by performing a hash algorithm on the original data frame.

[0142] The source IP address field in the external IP header carries the IP address of the VTEP connected to the source server, and the destination IP address field is the IP address of the VTEP connected to the destination server. The external IP header includes an external Internet Protocol version 4 (IPv4) header or an external IPv6 header. The external IPv6 header may also be called the IPv6 base header. The source address field and destination address field in the IPv6 base header each occupy 128 bits.

[0143] The external MAC header is an encapsulated external Ethernet header. The source MAC address field carries the MAC address of the VTEP connected to the source server, and the destination MAC address field is the MAC address of the next-hop device on the path to the destination VTEP.

[0144] GTP is primarily used in core networks to provide tunnels for signaling and user data transmission between serving GPRS support nodes (SGSNs) and gateway GPRS support nodes (GGSNs). In GTP, data frames or data packets of another protocol can be re-encapsulated and transmitted through the tunnel. The GTP header, including the TEID, is encapsulated in the encapsulated packet to perform packet forwarding. In a GTP network, the device that encapsulates and decapsulates the original data frame is the SGSN or GGSN. SGSNs and GGSNs are edge devices in a GTP network and can be used as the start and end points of a GTP tunnel. In Figure 1a, switch 1 is the SGSN and switch 2 is the GGSN. Specifically, the SGSN encapsulates the original data sent by the source server, including the GTP header, UDP header, external IP header, and external media access control (MAC) header.

[0145] Figure 1c is a schematic diagram of the structure including the GTP and UDP headers. The length of the GTP header is 8 bytes, including a 32-bit TEID field for carrying the TEID of different tunnels in the GTP network. In addition, it further includes a TEID flag field, a Version field, a Message Type field, and a Total Length field. The TEID flag occupies 1 bit. If this bit is set to 1, it indicates that the TEID field is present. The Version field occupies 3 bits and indicates the version number of the GPT protocol. The Message Type field occupies 8 bits and indicates the type of GTP message. The Total Length field occupies 16 bits and indicates the length of the message body.

[0146] The GTP header and the original data frame are used together as UDP data. The UDP header occupies 8 bytes. The UDP header includes the source port number, destination port number, UDP length, and UDP checksum. Each field occupies 16 bits. Optionally, the destination port number is fixed at 2152, and the source port number is determined by performing a hash algorithm on the original data frame.

[0147] From the above explanation, it can be seen that when VXLAN or GTP packets are transmitted over an IPv6 network, if the VXLAN or GTP header is encapsulated using UDP encapsulation, an additional UDP header also needs to be encapsulated. As a result, the amount of data encapsulated is large, the encapsulation efficiency is low, and this affects the efficiency of packet transmission.

[0148] Based on this, embodiments of the present application provide a packet transmission method. When a packet is transmitted over an IPv6 network, the tunnel header corresponding to the packet is encapsulated in the IPv6 header, and there is no need to encapsulate an additional UDP header. This improves the efficiency of encapsulation.

[0149] To facilitate understanding of the technical measures provided in the embodiments of this application, the technical measures will be described below with reference to the accompanying drawings.

[0150] Figure 2 is a flowchart of a packet transmission method according to one embodiment of the present application. As shown in Figure 2, the method includes the following steps.

[0151] S201: The first network device receives the first packet.

[0152] S202: The first network device obtains the tunnel header based on the first packet.

[0153] In this embodiment, the first network device may be switch 1 in Figure 1a. The first network device may receive a first packet transmitted by the host or source server in Figure 1a, or the first network device may generate a first packet. After the first packet is received, a tunnel header corresponding to the first packet is obtained based on the first packet. Specifically, after receiving the first packet, the first network device may obtain a tunnel header corresponding to the first packet based on the interface for receiving the first packet. The tunnel header corresponds to the interface for receiving the first packet. For example, the tunnel header may be pre-configured on the interface of the first network device. After receiving the first packet through the interface, the first network device obtains the tunnel header based on the mapping between the interface and the tunnel header. Alternatively, after receiving the first packet, the first network device may obtain a tunnel header corresponding to the first packet based on the address (source address) in the first packet. For example, the mapping between the address and the tunnel header may be pre-configured on the first network device. After receiving the first packet, the first network device determines the tunnel header corresponding to the address based on the address and mapping of the first packet.

[0154] The tunnel header includes one or more of the following: VXLAN header, GTP header, GRE header, IP-in-IP header, ISATAP header, IPv4 over IPv6 header, NVGRE header, L2TPv3, and MPLS in GRE header.

[0155] S203: The first network device encapsulates the IPv6 header in the first packet in order to receive the second packet.

[0156] After determining the tunnel header corresponding to the first packet, the first network device encapsulates the IPv6 header in the first packet, and the tunnel header is carried in the IPv6 header to retrieve the second packet. The IPv6 header may include the IPv6 base header and the IPv6 extensions header. Some tunnel headers, such as the VXLAN header and the GTP header, may occupy only a few bits and may be carried by using the IPv6 base header. Tunnel headers that occupy a large number of bits cannot be carried by using the IPv6 base header and are therefore carried by using the IPv6 extensions header.

[0157] (1) The IPv6 header is an IPv6 extension header.

[0158] When the IPv6 header is optionally encapsulated in the first packet, the first network device may encapsulate the IPv6 basic header and the IPv6 extension header in the first packet.

[0159] When an IPv6 header is an IPv6 extension header, it can be used to carry the tunnel header. IPv6 extension headers may include a hop-by-hop option header (HBH), a DOH, a routing header (RH), and an SRH. The format of a DOH is shown in Figure 3a. A DOH includes a Next Header field, an HDR Ext Lens field, and an Options field.

[0160] In some implementations, the tunnel header is carried in the DOH of the IPv6 extension header. When the DOH is used to carry the tunnel header, the optional fields within the DOH are used to carry the tunnel header. As shown in Figure 3b, the optional fields are used to carry the GRE header, which occupies 128 bits. As shown in Figure 3c, the GRE header includes the check bit C, the key bit K, the Reserved0 field, the Recursion layer number field, the flags field, the Version field, the Protocol Type field, the Checksum field, the Reserved1 field, the Key field, and the Sequence Number field.

[0161] Optionally, the "Options" field within the DOH includes a type-length-value (TLV), where the type field indicates that the DOH carries a tunnel header. For example, it may be specified that when the type field T is 1, it indicates that the DOH carries a tunnel header. After receiving a second packet, another network device may determine, based on T=1, that the second packet contains a tunnel header.

[0162] Optionally, the “Options” in the DOH includes a TLV, and the TLV’s type field indicates that the DOH carries the tunnel header. The TLV may be an augmented TLV. As shown in Figure 4a, the TLV includes an Option Type field, an Option Data Length field, and an Options Data field.

[0163] Optionally, the optional data field and optional data length field each occupy 8 bits, and the optional data field occupies 128 bits.

[0164] Optionally, the tunnel header may be carried in an optional data field, as shown in Figure 4b. Specifically, the tunnel header may be copied entirely into the optional data field.

[0165] In some application scenarios, packets may be forwarded based on some or all of a pre-specified path. The segment routing (SR) protocol is a source routing protocol. The source node specifies the path for the application packet, translates the path into an ordered list of segments, and encapsulates the list in a header. When SR is deployed on the IPv6 data plane, it is called SRv6. In SRv6 applications, forwarding path information is carried in an SRH, which includes an SID list. The SID list contains multiple sequentially ordered segment lists, each representing multiple segments. Each segment is an instruction or set of instructions for packet processing. The SRH is encapsulated in the packet, and the list of segment identifiers in the SRH carries the process of how the SR network processes the packet. For example, in the application scenario shown in Figure 1a, the specified path includes switch 1 and switch 2. In this case, the SID corresponding to switch 1 and the SID corresponding to switch 2 are added to the SID list carried in the SRH.

[0166] In another implementation, when the tunnel header is a VXLAN header or a GTP header, the IPv6 extension header may further include a segment routing header (SRH), and the tunnel header may be carried in the segment identifier list (SID list) of the SRH. The format of the SRH is shown in Figure 5a. The SRH includes a Next Header field, a Header Ext Len field, a Routing Type field, a Segment Left field, a Last Entry field, a Flags field, a Tag field, and an SID list. The SID list contains multiple sequentially arranged elements from segment list[0] to segment list[n-1]. Each element is a SID, and each element has a length of 128 bits. In Figure 5a, segment list[0] corresponds to the first segment to be executed, and segment list[n-1] corresponds to the last segment to be executed.

[0167] The format of an SID is shown in Figure 5b. An SID may include a locator field and a function field. An SID may further include an argument field and / or a padding field following the function field. The contents of the locator field, sometimes abbreviated as locator, are identifiers assigned to a network node in the network topology, identifying that network node within the network topology. The contents of the function field, sometimes abbreviated as function, indicate an instruction or set of instructions for packet processing, equivalent to the arithmetic code of a computer instruction. When the instruction or set of instructions indicated by function is executed on a network node, the network node is enabled to perform the corresponding forwarding behavior. The contents of the argument field, sometimes abbreviated as argument, indicate the parameters used in the execution of the instruction or set of instructions indicated by function.

[0168] The following are possible cases where a VXLAN header or GTP header is carried in the SID list:

[0169] Case 1:

[0170] The tunnel header is carried in the SID corresponding to the second network device in the SID list. Specifically, the tunnel header is carried in the function field of the second network device's SID. The SID of the second network device may be used to carry the tunnel header when it is used to carry the tunnel header. As shown in Figure 5c, the SID list includes SIDs 1 through n, and the SID of the second network device is SID n. SID n includes the locator and GTP headers. The locator is the address of the second network device, and the tunnel header may occupy bits 64 through 128 of the second network device's SID. The SID of the second network device instructs the second network device to forward the packet based on the tunnel header carried in the SID.

[0171] Case 2:

[0172] The tunnel header is carried in the segment list where the SIDs of network devices other than the second network device are located. For example, if the SID of the second network device in the SID list is SID 3, the tunnel header is carried in SID 4 in the SID list. That is, the tunnel header is carried in a different SID. In this case, another SID may be used to carry the tunnel header. See Figure 5c for the carrying method. The SID of the second network device reads the tunnel header from another SID and instructs the second network device to forward the packet based on the tunnel header.

[0173] In this embodiment, since the second network device needs to forward packets based on the tunnel header, when advertising the SID of the second network device, the second network device may indicate that the type of the SID of the second network device is END.VN. The SID is an SRv6 SID. The locator portion of the SID contains the address of the destination tunnel endpoint, and the function portion of the SID contains the tunnel header. The forwarding behavior corresponding to the behavior of the SID includes the following: After receiving the packet, the destination tunnel endpoint retrieves the forwarding table of the corresponding instance based on the tunnel header in the SID, decapsulates the packet, looks up the forwarding table based on the MAC address in the payload, etc., and forwards the packet. Optionally, the SID corresponding to the address of the second network device is an END.VN type SID. Optionally, the SID corresponding to the address of the second network device is the SRv6 locator of the second network device.

[0174] In a specific implementation, after establishing an Interior Gateway Protocol (IGP) or Border Gateway Protocol (BGP) session with a first network device, the second network device may advertise its SID and the corresponding type to the SID to the first network device using IGP or BGP. The first network device stores the SID of the second network device and the corresponding type. When it is necessary to forward a VXLAN or GTP packet to the second network device, the first network device may encapsulate the tunnel header corresponding to the packet in an IPv6 header based on the type of the second network device's SID. When advertising the SID, the second network device establishes a forwarding table locally, which includes a matching entry and an action entry. The matching entry includes the SID of the second network device. The action entry instructs the second network device to decapsulate the packet and forward it based on the tunnel header carried in the packet.

[0175] (2) The IPv6 header is the IPv6 basic header.

[0176] When the tunnel header is a VXLAN header or a GTP header, the IPv6 header can be an IPv6 base header. That is, the VXLAN header or GTP header can be carried in the destination address field of the IPv6 base header. Typically, the destination address field in the IPv6 base header is 128 bits long and is used to carry the address of the destination network device. Optionally, in the packet forwarding process, the prefix information of the destination network device does not usually need to occupy the entire destination address field. For example, the prefix information of the destination network device only needs to occupy 64 bits of the destination address field. Optionally, the address of the destination network device may be compressed to 64 bits, occupying bits 1 through 64. In this way, the VXLAN header or GTP header may occupy bits 65 through 128 of the destination address field. The position in the destination address field occupied by the tunnel header can be determined based on the actual application. This is not limited to this embodiment.

[0177] Figure 6a shows the packet format of the IPv6 basic header. The IPv6 basic header includes the Version field, Traffic Type field, Flow Label field, Payload Length field, Next Header field, Hop Limit field, Source Address (SA) field, and Destination Address (DA) field. The Source Address field and Destination Address field each occupy 128 bits. The Source Address field contains the source address, and the Destination Address field contains the destination address.

[0178] Optionally, the destination address field may include the destination address and the tunnel header. As shown in Figure 6b, the destination address field includes the destination address and the GTP header.

[0179] The destination address field is typically used to carry the destination address of a packet. After receiving a packet, the destination network device indicated by the destination address reads the destination address from the destination address field and forwards the packet based on the destination address. In this embodiment, the destination address field includes not only the destination address but also the tunnel header. The tunnel header instructs the destination network device to forward the packet. In order to enable the destination network device to forward the packet based on the tunnel header after receiving the packet, the device indicated by the destination address in the destination address field (a second network device) needs to be notified in advance to forward the second packet based on the tunnel header carried in the destination address field after receiving the packet.

[0180] From the above explanation, it is clear that either the IPv6 basic header or the IPv6 extensions header may be used to carry the tunnel header. In either case, no additional UDP headers need to be encapsulated. This reduces the amount of data required for packet encapsulation and improves the efficiency of packet encapsulation.

[0181] In addition, the flow label in the IPv6 header may correspond to the packet's port number. The port number is not only used to perform load balancing in the forwarding process of the second packet, but it can also determine the type of the second packet. For example, if the port number carried in the flow label is 4789, it can be determined from the port number that the received packet contains a VXLAN packet. The port number may be a pre-configured fixed port number, or it may be a port number obtained through dynamic calculation based on the payload of the first packet.

[0182] To implement in-situ flow information telemetry (IFIT) functionality, when the IPv6 header is encapsulated in the first packet, an IFIT instruction may be carried in the IPv6 header to perform hop-by-hop network in-situ flow information telemetry, or network in-situ flow information telemetry for a specified node or destination node. Specifically, the IFIT instruction may be carried in the IPv6 extension header.

[0183] S204: The first network device sends the second packet to the second network device.

[0184] In this embodiment, after obtaining the second packet by encapsulating the IPv6 header in the first packet, the first network device sends the second packet to the second network device. The second network device may be a terminal node in the network. For example, the second network device is switch 2 in Figure 1a. The destination address field in the IPv6 header of the second packet contains the address of the second network device or the SRv6 locator of the second network device, rather than a host address. For example, in Figure 1a, the destination address field in the IPv6 header of the second packet contains the address of switch 2 or the SRv6 locator of switch 2.

[0185] S205: The second network device receives the second packet and retrieves the tunnel header from the IPv6 header of the second packet.

[0186] From the previous explanation, it is clear that some tunnel headers may be carried in the IPv6 basic header, and some tunnel headers may be carried in the IPv6 extension header. When tunnel headers are carried in different IPv6 headers, the second network device obtains the tunnel header from the IPv6 header in different ways.

[0187] When the tunnel header is a VXLAN header or a GTP header, the tunnel header may be carried in the destination address field of the IPv6 base header. After receiving a second packet transmitted by the first network device, the second network device determines whether the destination address field contains the address of the second network device. If the destination address field contains the address of the second network device, the tunnel header is obtained from the destination address field.

[0188] Note that since the address of the second network device needs to be encapsulated in the second packet, the second network device must advertise its address to the first network device before it can receive the second packet sent by the first network device. The address of the second network device instructs the second network device to forward the packet based on the tunnel header, which is carried in the destination address field when it receives the second packet. When the second network device advertises its address to the first network device, it establishes a forwarding entry locally, which may include a matching item and an action item. The matching item includes the address of the second network device. The action item indicates that, after successful matching using the matching item, the tunnel header is taken from the destination address field, the second packet is decapsulated, and the decapsulated packet is forwarded based on the tunnel header.

[0189] When the tunnel header is carried in the IPv6 extension header's DOH, after receiving the second packet sent by the first network device, the second network device determines whether the destination address field contains the address of the second network device. If the destination address field contains the address of the second network device, it determines whether the type field of the TLV in the DOH indicates that the tunnel header is carried. If the type field of the TLV indicates that the tunnel header is carried, the tunnel header is retrieved from the DOH. When the tunnel header is carried in the DOH, the second network device may retrieve the tunnel header by parsing the DOH.

[0190] When the tunnel header is carried in the SID corresponding to the second network device in the SRH SID list within the IPv6 extension header, after receiving the second packet, the second network device determines whether the destination address field of the second packet contains the SID of the second network device. If the destination address field of the second packet contains the SID of the second network device, the second network device obtains the tunnel header from the SID of the second network device carried in the second packet.

[0191] When a tunnel header is carried in a different corresponding SID (the SID of a network device other than the second network device) in the SID list of the SRH in the IPv6 extension header, after receiving the second packet, the second network device determines whether the destination address field of the second packet contains the SID of the second network device. If the destination address field of the second packet contains the SID of the second network device, the second network device obtains the tunnel header from a different SID carried in the second packet. For example, a field in the SRH or a new field may be used to instruct the second network device to obtain the tunnel header from a specified SID, or it may be predetermined that the tunnel header will be carried in the next SID adjacent to the SID of the second network device. In this case, after receiving the second packet, the second network device reads the next SID from the SID list and obtains the tunnel header from the next SID.

[0192] Since the SID of the second network device needs to be encapsulated in the second packet, it should be noted that the second network device must advertise its SID to the first network device before it receives the second packet sent by the first network device. In addition, the type of the second network device's SID may be further advertised. The type corresponding to the second network device's SID may be defined as END.VN, instructing the second network device to retrieve the tunnel header from the packet after receiving the corresponding packet, decapsulate the packet, look up the forwarding table based on the tunnel header, and forward the decapsulated packet based on the forwarding table. The SID of the second network device may also be the address of the second network device, or the corresponding address obtained after the address of the second network device may be compressed.

[0193] When advertising the SID of a second network device to a first network device, the second network device may further establish a forwarding entry locally. The forwarding entry includes a match item and an action item. The match item includes the SID of the second network device, and the action item indicates the action that should be performed when the match is successful. For example, the action item instructs the second network device to decapsulate the packet when the match is successful and to forward the decapsulated packet based on the tunnel identifier in the tunnel header.

[0194] S206: The second network device decapsulates the second packet in order to obtain the first packet.

[0195] In this embodiment, after obtaining a tunnel, if the second network device determines, based on the information in the encapsulated IPv6 header, that the second network device is the termination node, the second network device decapsulates the second packet, removes the encapsulated IPv6 header, and obtains the first packet. For example, if the second network device determines that the destination address field in the IPv6 header of the second packet contains the SID of the second network device, the second network device decapsulates the second packet based on the operation item in the forwarding entry in order to obtain the first packet. Decapsulating a packet includes removing the IPv6 basic header encapsulated in the second packet in order to obtain the first packet, or removing the IPv6 basic header and IPv6 extension header encapsulated in the second packet in order to obtain the first packet.

[0196] The execution order of S205 and S206 is not limited in this embodiment. S206 may be performed before S205, S205 may be performed before S206, or S205 and S206 may be performed simultaneously.

[0197] S207: The second network device forwards the first packet based on the tunnel header.

[0198] After receiving the first packet, the second network device determines the forwarding path based on the tunnel header and forwards the first packet based on the forwarding path. Specifically, the second network device retrieves the corresponding forwarding table from the tunnel header, searches the forwarding table for a forwarding entry based on the destination address in the first packet, and forwards the first packet based on the forwarding entry. Note that when the first packet is a Layer 2 packet, the corresponding destination address is a MAC address, and the retrieved forwarding table is either a MAC address or a MAC table. When the first packet is a Layer 3 packet, the corresponding destination address is an IP address, and the retrieved forwarding table is a routing table.

[0199] Figure 7 is a flowchart of a VXLAN packet transmission method according to one embodiment of the present application. As shown in Figure 7, the method includes the following steps.

[0200] S701: The first network device receives the first packet.

[0201] S702: The first network device obtains the VNI based on the first packet.

[0202] In this embodiment, the first network device may be switch 1 in Figure 1a. The first network device may receive a first packet transmitted by the host or source server in Figure 1a, or the first network device may generate the first packet. After the first packet is received, a VNI corresponding to the first packet is obtained based on the first packet. The VNI is a tenant identifier corresponding to the device that sent the first packet. Specifically, after receiving the first packet, the first network device may obtain the VNI corresponding to the first packet based on the interface for receiving the first packet. The VNI corresponds to the interface for receiving the first packet. For example, the VNI may be pre-configured on the interface of the first network device. After receiving the first packet through the interface, the first network device obtains the VNI based on the mapping between the interface and the VNI. Alternatively, after receiving the first packet, the first network device may obtain the VNI corresponding to the first packet based on the address (source address) in the first packet. For example, the mapping between addresses and VNIs is pre-configured on the first network device. After receiving the first packet, the first network device determines the VNI corresponding to the address based on the address and mapping of the first packet.

[0203] S703: The first network device encapsulates the IPv6 header in the first packet in order to receive the second packet.

[0204] After determining the VNI corresponding to the first packet, the first network device encapsulates the IPv6 header in the first packet, and the VNI is carried in the IPv6 header to retrieve the second packet. There are two ways in which the IPv6 header carries the VNI. In one method, the IPv6 header directly carries the VNI. In the other method, the IPv6 header includes a VXLAN header, and the VXLAN header includes the VNI.

[0205] Optionally, the IPv6 header can be either an IPv6 base header or an IPv6 extension header, and the VNI can be carried in either the IPv6 base header or the IPv6 extension header. Alternatively, the VXLAN header can be carried in either the IPv6 base header or the IPv6 extension header. The IPv6 base header contains basic packet forwarding information and is 40 bytes long.

[0206] (1) The IPv6 header is the IPv6 basic header.

[0207] When the IPv6 header is an IPv6 base header, the VNI can be carried in the destination address field of the IPv6 base header. Typically, the destination address field in an IPv6 base header is 128 bits long and is used to carry the address of the destination network device. Optionally, in the packet forwarding process, the prefix information of the destination network device does not usually need to occupy the entire destination address field. For example, the prefix information of the destination network device only needs to occupy 64 bits of the destination address field. Optionally, the address of the destination network device may be compressed to 64 bits, occupying bits 1 through 64. In this way, the VNI may occupy bits 65 through 128 of the destination address field. Alternatively, the VNI may occupy bits 80 through 128 of the destination address field. The position occupied by the VNI in the destination address field may be determined based on the actual application context. This is not limited to this embodiment.

[0208] Optionally, the destination address field may include the destination address and VNI, as shown in Figure 8a.

[0209] In addition, the IPv6 header may also include VXLAN flags, which include a flag indicating that the second packet will carry a valid VNI. The VXLAN flags are 8 bits long, with the fifth bit indicating that the packet will carry a valid VNI. For example, when the fifth bit is 1, it indicates that the second packet will carry a valid VNI. The VXLAN flags may be carried in the destination address field. As shown in Figure 8b, the destination address field includes the destination address, the VXLAN flags, and the VNI.

[0210] In addition to the VNI being carried in the destination address field of the IPv6 base header, there is an alternative method of carrying the VNI. Specifically, the destination address field includes a VXLAN header, and the VXLAN header carries the VNI. That is, the VXLAN header is encapsulated in the destination address field of the IPv6 base header. The length of the VXLAN header is 64 bits. The destination address usually occupies bits 1 through 64 of the destination address field. In this way, the VXLAN header can occupy bits 65 through 128 of the destination address field. The VXLAN header contains VXLAN flags. Specifically, as shown in Figure 8c, the destination address field in the IPv6 base header contains the destination address and the VXLAN header, and the VXLAN header contains the VNI and VXLAN flags.

[0211] The destination address field is typically used to carry the destination address of a packet. After receiving a packet, the destination network device indicated by the destination address reads the destination address from the destination address field and forwards the packet based on the destination address. In this embodiment, the destination address field includes not only the destination address but also the VNI. The VNI instructs the destination network device to forward the packet. In order for the destination network device to forward the packet based on the VNI after receiving the packet, the device indicated by the destination address in the destination address field (a second network device) needs to be notified in advance to forward the second packet based on the VNI carried in the destination address field after receiving the packet.

[0212] (2) The IPv6 header is an IPv6 extension header.

[0213] When the IPv6 header is optionally encapsulated in the first packet, the first network device may encapsulate the IPv6 basic header and the IPv6 extension header in the first packet.

[0214] When the IPv6 header is an IPv6 extension header, the IPv6 extension header can be used to carry the VNI. The IPv6 extension header may include HBH, DOH, RH, SRH, etc. The format of DOH is shown in Figure 3a.

[0215] In some implementations, the VNI is carried in the DOH of the IPv6 extension header. As shown in Figure 9a, when the DOH is used to carry the VNI, an option field within the DOH may be used to carry the VNI directly. Alternatively, as shown in Figure 9b, the option field within the DOH may be used to carry the VXLAN header, which carries the VNI. As shown in Figure 9c, when the IPv6 extension header also contains VXLAN flags, an option field within the DOH may be used to carry the VXLAN flags directly. Alternatively, the option field within the DOH may be used to carry the VXLAN header, which carries both the VNI and the VXLAN flags. Specifically, the VXLAN header may be entirely copied into the option field.

[0216] Optionally, the "Options" in the DOH includes a type-length value TLV, where the type field of the TLV indicates that the DOH is carrying a VNI. For example, it may be specified that when the type field T is 1, it indicates that the DOH is carrying a VNI. After receiving a second packet, another network device may determine, based on T=1, that the second packet contains a VNI.

[0217] Optionally, the "Options" field within the DOH includes a TLV, and the TLV type indicates that the DOH carries a VXLAN header. The TLV may be an enhanced VXLAN TLV, which is sometimes also called a VN option TLV. A VN (VXLAN) option TLV includes an Option Type field, an Option Data Length field, and an Option Data field. See Figure 4a for the specific structure. The Option Type field identifies that the TLV is a VN option, and in particular, identifies that the VN option carries a VNI, or that the VN option carries a VXLAN header.

[0218] Optionally, the VNI may be carried in an optional data field, as shown in Figure 10a.

[0219] Optionally, the VXLAN header may be carried in an optional data field, as shown in Figure 10b.

[0220] In another implementation, when the VNI is carried in the SRH, the VNI may be carried in the SID list of the SRH. The format of the SRH is shown in Figure 5a, and the format of the SID is shown in Figure 5b.

[0221] When a VNI is transported in the SID list, the following cases may be included.

[0222] Case 1:

[0223] The VNI is carried in the SID corresponding to the second network device in the SID list. Specifically, the VNI is carried in the function field of the second network device's SID. When the second network device's SID is used to carry the VNI, the second network device's SID can also be used to carry the VNI directly. As shown in Figure 11a, the SID list includes SIDs 1 through n, and the SID of the second network device is SID n. SID n includes a locator and a VNI. The locator includes the address of the second network device. For example, the VNI occupies bits 64 through 128 of the second network device's SID, or bits 80 through 128 of the second network device's SID. When SID n also includes an argument, SID n includes the locator, VNI, and argument. In this case, the VNI occupies bits 64 through 87 of the second network device's SID.

[0224] Alternatively, the SID of the second network device is used to carry the VXLAN header, which includes the VNI. As shown in Figure 11b, the SID of the second network device is SID n, which includes the locator and the VXLAN header. Specifically, the VXLAN header may occupy bits 64 through 128 of the SID of the second network device. The SID of the second network device instructs the second network device to forward the packet based on the VNI carried in the SID.

[0225] Case 2:

[0226] The VNI is carried in the segment list where the SIDs of network devices other than the second network device are located. For example, if the SID of the second network device in the SID list is SID 3, the VNI is carried in SID 4 in the SID list. That is, the VNI is carried in a different SID. In this case, the other SID may be used to carry the VNI directly. See Figure 11a for the carrying scheme. Alternatively, the other SID may be used to carry the VXLAN header, which includes the VNI. See Figure 11b for the carrying scheme. The SID of the second network device reads the VNI from the other SID and instructs the second network device to forward packets based on the VNI.

[0227] In this embodiment, since the second network device needs to forward packets based on the VNI, when advertising the SID of the second network device, the second network device may indicate that the type of the SID of the second network device is of type END.VN. The SID is an SRv6 SID. The locator portion of the SID includes the VTEP address or the SRv6 locator of the VTEP corresponding to the VXLAN packet, and the function portion of the SID includes the VNI or VXLAN header. The forwarding operation corresponding to the behavior related to the SID includes, after the packet reaches the destination VTEP node, retrieving the forwarding table of corresponding VXLAN instances based on the VNI carried in the packet's SID, decapsulating the packet, searching the forwarding table based on the MAC address in the payload, etc., and forwarding the packet. Optionally, the SID corresponding to the address of the second network device is an END.VN type SID. Optionally, the SID corresponding to the address of the second network device is the SRv6 locator of the second network device.

[0228] In a specific implementation, after establishing an IGP or BGP session with a first network device, the second network device may advertise its SID and the type corresponding to the SID to the first network device using IGP or BGP. The first network device stores the SID and the type corresponding to the SID of the second network device. When it is necessary to forward a VXLAN packet to the second network device, the first network device may encapsulate the VNI corresponding to the packet in the IPv6 header based on the type of the second network device's SID. When advertising the SID, the second network device establishes a forwarding table locally, which includes a match entry and an action entry. The match entry includes the SID of the second network device. The action entry instructs the second network device to decapsulate the packet and forward it based on the VNI carried in the packet.

[0229] When the IPv6 header further includes VXLAN flags, the flags may be carried in the SID of a second network device, for example, the flags and VNI are encapsulated in SID n in Figure 11c. When SID n further includes arguments, SID n includes the locator, VXLAN flags, VNI, and argument.

[0230] From the above explanation, it is clear that either the IPv6 basic header or the IPv6 extensions header may be used to carry the VNI. In either case, no additional UDP header is required for encapsulation. This reduces the amount of data required for packet encapsulation and improves the efficiency of packet encapsulation.

[0231] In addition, the flow label in the IPv6 header may correspond to the destination port number of the VXLAN packet. The destination port number is not only used to perform load balancing in the forwarding process of the second packet, but it can also determine whether the second packet contains a VXLAN packet. For example, if the port number carried in the flow label is 4789, it can be determined from the port number that the received packet contains a VXLAN packet. The port number may be a pre-configured fixed port number, or it may be a port number obtained through dynamic calculation based on the payload of the first packet. Optionally, the method for calculating the flow label of the second packet may be the same as the method for calculating the UDP source port used for load balancing in the VXLAN packet, and the port number value obtained from the VXLAN packet may be carried in the flow label of the second packet.

[0232] To implement the IFIT function, when the IPv6 header is encapsulated in the first packet, an IFIT instruction may be carried in the IPv6 header to perform hop-by-hop network field flow information telemetry, or network field flow information telemetry for a specified node or destination node. Specifically, the IFIT instruction may be carried in the IPv6 extension header.

[0233] S704: The first network device sends the second packet to the second network device.

[0234] In this embodiment, after obtaining the second packet by encapsulating the IPv6 header in the first packet, the first network device sends the second packet to the second network device. The second network device may be a terminal node in a VXLAN network. For example, the second network device is switch 2 in Figure 1a. The destination address field in the IPv6 header of the second packet contains the address of the second network device or the SRv6 locator of the second network device. For example, in Figure 1a, the destination address field in the IPv6 header of the second packet contains the address of switch 2 or the SRv6 locator of switch 2.

[0235] S705: The second network device receives the second packet and obtains the VNI from the IPv6 header of the second packet.

[0236] From the above explanation, it can be seen that VNIs can be carried in either the IPv6 basic header or the IPv6 extension header. When a VNI is carried in different IPv6 headers, the second network device will obtain the VNI from the IPv6 header in a different way.

[0237] When a VNI is carried in the destination address field of the IPv6 basic header, after receiving a second packet sent by the first network device, the second network device determines whether the destination address field contains the address of the second network device. If the destination address field contains the address of the second network device, the VNI is obtained from the destination address field. When a VNI is carried directly in the destination address field, the second network device can obtain the VNI by parsing the destination address field. When a VNI is carried in the VXLAN header, and the VXLAN header is carried in the destination address field, the second network device must first parse the destination address field to obtain the VXLAN header and then read the VNI from the VXLAN header.

[0238] Note that since the address of the second network device needs to be encapsulated in the second packet, the second network device must advertise its address to the first network device before it can receive the second packet sent by the first network device. The address of the second network device instructs the second network device to forward the packet based on the VNI carried in the destination address field when it receives the second packet. When the second network device advertises its address to the first network device, it establishes a forwarding entry locally, which may include a matching item and an action item. The matching item includes the address of the second network device. The action item indicates that, after successful matching using the matching item, the VNI is obtained from the destination address field, the second packet is decapsulated, and the decapsulated packet is forwarded based on the VNI.

[0239] When a VNI is carried in the DOH of the IPv6 extension header, after receiving a second packet sent by the first network device, the second network device determines whether the destination address field contains the address of the second network device. If the destination address field contains the address of the second network device, it determines whether the type field of the TLV in the DOH indicates that a VNI is being carried. If the type field of the TLV indicates that a VNI is being carried, the VNI is retrieved from the DOH. When a VNI is carried directly in the DOH, the second network device can retrieve the VNI by parsing the DOH. When a VNI is carried in the VXLAN header and the VXLAN header is carried in the DOH, the second network device must first parse the DOH to retrieve the VXLAN header and then read the VNI from the VXLAN header.

[0240] When a VNI is carried in the SID corresponding to the second network device in the SRH SID list in the IPv6 extension header, after receiving the second packet, the second network device determines whether the destination address field of the second packet contains the SID of the second network device. If the destination address field of the second packet contains the SID of the second network device, the second network device obtains the VNI from the SID of the second network device carried in the second packet.

[0241] When a VNI is carried in another corresponding SID (the SID of a network device other than the second network device) in the SID list of the SRH in the IPv6 extension header, after receiving the second packet, the second network device determines whether the destination address field of the second packet contains the SID of the second network device. If the destination address field of the second packet contains the SID of the second network device, the second network device obtains the VNI from another SID carried in the second packet. For example, a field in the SRH or a new field may be used to instruct the second network device to obtain the VNI from a specified SID, or it may be predetermined that the VNI will be carried in the next SID adjacent to the SID of the second network device. In this case, after receiving the second packet, the second network device reads the next SID from the SID list and obtains the VNI from the next SID.

[0242] Since the SID of the second network device needs to be encapsulated in the second packet, it should be noted that the second network device must advertise its SID to the first network device before it receives the second packet sent by the first network device. In addition, the type of the second network device's SID may be further advertised. The type corresponding to the second network device's SID may be defined as the END.VN type, instructing the second network device to retrieve the VNI from the packet after receiving the corresponding packet, decapsulate the packet, look up the forwarding table based on the VNI, and forward the decapsulated packet based on the forwarding table. The SID of the second network device may also be the address of the second network device, or the corresponding address obtained after the address of the second network device may be compressed.

[0243] When advertising the SID of a second network device to a first network device, the second network device may further establish a forwarding entry locally. The forwarding entry includes a match item and an action item. The match item includes the SID of the second network device, and the action item indicates the action that should be performed when the match is successful. For example, the action item instructs the second network device to decapsulate the packet when the match is successful and to forward the decapsulated packet based on the VNI.

[0244] S706: The second network device decapsulates the second packet in order to obtain the first packet.

[0245] In this embodiment, after obtaining a VNI, if the second network device determines, based on the information in the decapsulated IPv6 header, that the second network device is the terminal node, the second network device decapsulates the second packet, removes the encapsulated IPv6 header, and obtains the first packet. For example, if the second network device determines that the destination address field in the IPv6 header of the second packet contains the SID of the second network device, the second network device decapsulates the second packet based on the operation item in the forwarding entry in order to obtain the first packet. Decapsulating a packet includes removing the IPv6 basic header encapsulated in the second packet in order to obtain the first packet, or removing the IPv6 basic header and IPv6 extension header encapsulated in the second packet in order to obtain the first packet.

[0246] The execution order of S705 and S706 is not limited in this embodiment. S706 may be performed before S705, S705 may be performed before S706, or S705 and S706 may be performed simultaneously.

[0247] S707: The second network device forwards the first packet based on the VNI.

[0248] After receiving the first packet, the second network device determines the forwarding path based on the VNI and forwards the first packet based on the forwarding path. Specifically, the second network device retrieves the forwarding table for the corresponding VXLAN example based on the VNI, searches the forwarding table for the VXLAN example for a forwarding entry based on the destination address in the first packet, and forwards the first packet based on the forwarding entry. Note that when the first packet is a Layer 2 packet, the corresponding destination address is a MAC address, and the retrieved forwarding table is either a forwarding table or a MAC table. When the first packet is a Layer 3 packet, the corresponding destination address is an IP address, and the retrieved forwarding table is a routing table.

[0249] For ease of understanding, please refer to the schematic diagram of the application scenario shown in Figure 12. An example application scenario including a source server, a destination server, VTEP 1, VTEP 2, and a transmitting device RR is used for explanation. The source server's IPv4 address is 10.1.1.1 and its MAC address is 1-1-1. The destination server's IPv4 address is 10.1.1.2 and its MAC address is 2-2-2. VTEP 1's IPv6 address is 10::1 and its MAC address is AA-1-1. VTEP 2's IP address is 10::2 and its MAC address is CC-1-1. The transmitting device RR's MAC address is BB-1-1. A VXLAN tunnel is established between VTEP 1 and VTEP 2. The VNI corresponding to VTEP 1 and VTEP 2 is 1001. In Figure 6, the forwarding of a Layer 2 service packet is used as an example for explanation. Specifically, after receiving packet 1 sent by the source server, VTEP 1 determines the tenant identifier VNI 1001 corresponding to the source server based on information about the port connected between VTEP 1 and the source server, and encapsulates the VNI in the destination address field of the IPv6 basic header. The destination address field further includes the address 10::2 of the tunnel endpoint VTEP 2. The source address field includes the address 10::1 of the tunnel endpoint VTEP 1. In addition, the external MAC header is encapsulated. The MAC header includes the source MAC address AA-1-1 and the destination MAC address BB-1-1. VTEP 1 retrieves packet 2 after encapsulation and sends packet 2 to the sending device RR. After receiving packet 2, the transmitting device RR determines the MAC address of the next-hop network device based on the Layer 2 forwarding table, updates the source and destination MACs in the outer MAC header to obtain packet 3, namely updating the source MAC to BB-1-1 and the destination MAC to CC-1-1, and forwards packet 3 to VTEP 2. Based on the destination address 10::2, VTEP 2 finds that it is the tunnel endpoint.In this case, VTEP 2 obtains VNI:1001 from the destination address field in the IPv6 basic header of packet 3, looks up the corresponding forwarding table based on the VNI, decapsulates the IPv6 basic header in packet 3 to obtain packet 4, and forwards packet 4 to the destination server based on the forwarding table.

[0250] Figure 13 is a flowchart of a GTP packet transmission method according to one embodiment of the present application. As shown in Figure 13, the method includes the following steps:

[0251] S1301: The first network device receives the first packet.

[0252] S1302: The first network device obtains the TEID based on the first packet.

[0253] In this embodiment, the first network device may be switch 1 in Figure 1a. The first network device may receive a first packet transmitted by the host or source server in Figure 1a, or the first network device may generate the first packet. After the first packet is received, a TEID corresponding to the first packet is obtained based on the first packet. The TEID is a tenant identifier corresponding to the device that sent the first packet. Specifically, after receiving the first packet, the first network device may obtain a TEID corresponding to the first packet based on the interface for receiving the first packet. The TEID corresponds to the interface for receiving the first packet. For example, the TEID may be pre-configured on the interface of the first network device. After receiving the first packet through the interface, the first network device obtains a TEID based on the mapping between the interface and the TEID. Alternatively, after receiving the first packet, the first network device may obtain a TEID corresponding to the first packet based on the address (source address) in the first packet. For example, the mapping between addresses and TEIDs is pre-configured on the first network device. After receiving the first packet, the first network device determines the TEID corresponding to the address based on the address and mapping of the first packet.

[0254] S1303: The first network device encapsulates the IPv6 header in the first packet in order to receive the second packet.

[0255] After determining the TEID corresponding to the first packet, the first network device encapsulates the IPv6 header in the first packet, and the TEID is carried in the IPv6 header to retrieve the second packet. There are two ways in which the IPv6 header carries the TEID. In one method, the IPv6 header carries the TEID directly. In the other method, the IPv6 header includes a GTP header, and the GTP header includes the TEID.

[0256] Optionally, the IPv6 header can be either an IPv6 base header or an IPv6 extension header, and the TEID may be carried in either the IPv6 base header or the IPv6 extension header. Alternatively, the GTP header may be carried in either the IPv6 base header or the IPv6 extension header. The IPv6 base header contains basic packet forwarding information and is 40 bytes long.

[0257] (1) The IPv6 header is the IPv6 basic header.

[0258] When the IPv6 header is an IPv6 basic header, the TEID may be carried in the destination address field of the IPv6 basic header. Typically, the destination address field in an IPv6 basic header is 128 bits long and is used to carry the address of the destination network device. Optionally, in the packet forwarding process, the prefix information of the destination network device does not usually need to occupy the entire destination address field. For example, the prefix information of the destination network device only needs to occupy 64 bits of the destination address field. Optionally, the address of the destination network device may be compressed to 64 bits, occupying bits 1 through 64. In this way, the TEID may occupy bits 65 through 128 of the destination address field. Alternatively, the TEID may occupy bits 80 through 128 of the destination address field. The position occupied by the TEID in the destination address field may be determined based on the actual application context. This is not limited to this embodiment.

[0259] Optionally, the destination address field may include the destination address and TEID. For specific transport methods, please refer to Figure 8a.

[0260] In addition, the IPv6 header may also include a TEID flag, which indicates that the second packet will carry the TEID. The flag is 1 bit long. When the bit is 1, it indicates that the second packet will carry the TEID. The TEID flag may be carried in the destination address field. See Figure 8b for specific carrying methods. The destination address field contains the destination address, the TEID flag, and the TEID.

[0261] In addition to the TEID being carried in the destination address field of the IPv6 base header, there is an alternative method of carrying the TEID. Specifically, the destination address field includes a GTP header, and the GTP header carries the TEID. That is, the GTP header is encapsulated in the destination address field of the IPv6 base header. The length of the GTP header is 64 bits. The destination address usually occupies bits 1 through 64 of the destination address field. In this way, the GTP header can occupy bits 65 through 128 of the destination address field. The GTP header includes a TEID flag. Specifically, the destination address field in the IPv6 base header includes the destination address and the GTP header, and the GTP header includes the TEID and the TEID flag.

[0262] The destination address field is typically used to carry the destination address of a packet. After receiving a packet, the destination network device indicated by the destination address reads the destination address from the destination address field and forwards the packet based on the destination address. In this embodiment, the destination address field includes not only the destination address but also the TEID. The TEID instructs the destination network device to forward the packet. In order for the destination network device to forward the packet based on the TEID after receiving the packet, the device indicated by the destination address in the destination address field (a second network device) needs to be notified in advance to forward the second packet based on the TEID carried in the destination address field after receiving the packet.

[0263] (2) The IPv6 header is an IPv6 extension header.

[0264] When the IPv6 header is optionally encapsulated in the first packet, the first network device may encapsulate the IPv6 basic header and the IPv6 extension header in the first packet.

[0265] When the IPv6 header is an IPv6 extension header, the IPv6 extension header may be used to carry the TEID. The IPv6 extension header may include HBH, DOH, RH, SRH, etc. The format of DOH is shown in Figure 3a.

[0266] In some implementations, the TEID is carried in the DOH of the IPv6 extension header. When the DOH is used to carry the TEID, an optional field within the DOH may be used to directly carry the TEID. See Figure 9a for specific carrying methods. Alternatively, the optional field within the DOH may be used to carry the GTP header, which carries the TEID. See Figure 9b for carrying methods. When the IPv6 extension header also includes a TEID flag, an optional field within the DOH may be used to directly carry the flag. See Figure 9c for carrying methods. Alternatively, the optional field within the DOH may be used to carry the GTP header, which carries the TEID flag and the TEID. Specifically, the GTP header may be entirely copied into the optional field.

[0267] Optionally, the "Options" in the DOH includes a type-length value TLV, where the type field indicates that the DOH is carrying a TEID. For example, when the type field T is 1, it may be specified that the DOH is carrying a TEID. After receiving a second packet, another network device may determine, based on T=1, that the second packet contains a TEID.

[0268] Optionally, the "Options" in the DOH include a TLV, and the TLV type indicates that the DOH carries a GTP header. The TLV may be an enhanced GTP TLV. See Figure 4a for the structure of an enhanced GTP TLV.

[0269] Optionally, TEID can be transported in an optional data field. See Figure 10a for details on the transport method.

[0270] Optionally, the GTP header can be transported in an optional data field. See Figure 10b for details on the transport method.

[0271] In another implementation, when the TEID is carried in the SRH, the TEID can be carried in the SID list of the SRH. The format of the SRH is shown in FIG. 5a, and the format of the SID is shown in FIG. 5b.

[0272] The case where the TEID is carried in the SID list may include the following cases.

[0273] Case 1:

[0274] The TEID is carried in the SID corresponding to the second network device in the SID list. Specifically, the TEID is carried in the function field of the SID of the second network device. When the SID of the second network device is used to carry the TEID, the SID of the second network device can be used to directly carry the TEID. For the transfer method, refer to FIG. 11a. The SID list includes SID 1 to SID n, and the SID of the second network device is SID n. SID n includes a locator and a TEID. The locator includes the address of the second network device. For example, the TEID occupies bits 64 to 128 of the SID of the second network device, or occupies bits 80 to 128 of the SID of the second network device. When SID n further includes an argument, SID n includes a locator, a TEID, and an argument. In this case, the TEID occupies bits 64 to 87 of the SID of the second network device.

[0275] Alternatively, the SID of the second network device is used to carry the GTP header, which includes the TEID. For the carrying method, refer to FIG. 11b. The SID of the second network device is SID n, and SID n includes a locator and a GTP header. Specifically, the GTP header may occupy bits 64 to 128 of the SID of the second network device. The SID of the second network device instructs the second network device to forward packets based on the TEID carried in the SID.

[0276] Case 2:

[0277] The TEID is carried in the segment list where the SID of the network device other than the second network device is located. For example, if the SID of the second network device in the SID list is SID 3, the TEID is carried in SID 4 in the SID list. That is, the TEID is carried in another SID. In this case, another SID can be used to directly carry the TEID. For the carrying method, refer to FIG. 11a. Alternatively, another SID may be used to carry the GTP header, which includes the TEID. For the carrying method, refer to FIG. 11b. The SID of the second network device reads the TEID from another SID and instructs the second network device to forward packets based on the TEID.

[0278] In this embodiment, since the second network device needs to forward packets based on the TEID, when advertising the SID of the second network device, the second network device may indicate that the type of the SID of the second network device is of type END.VN. The SID is an SRv6 SID. The locator portion of the SID contains the address of the destination tunnel endpoint corresponding to the GTP packet, and the function portion of the SID contains the TEID or GTP header. The forwarding operation corresponding to the behavior of the SID includes the following: After receiving the packet, the destination tunnel endpoint retrieves the forwarding table of corresponding instances based on the TEID carried in the packet's SID, decapsulates the packet, looks up the forwarding table based on the MAC address in the payload, etc., and forwards the packet. Optionally, the SID corresponding to the address of the second network device is an END.VN type SID. Optionally, the SID corresponding to the address of the second network device is the SRv6 locator of the second network device.

[0279] In a specific implementation, after establishing an IGP or BGP session with a first network device, the second network device may advertise its SID and the type corresponding to the SID to the first network device using IGP or BGP. The first network device stores the SID and the type corresponding to the SID of the second network device. When it is necessary to forward a GTP packet to the second network device, the first network device may encapsulate the TEID corresponding to the packet in the IPv6 header, based on the type of the second network device's SID. When advertising the SID, the second network device establishes a forwarding table locally, which includes a matching entry and an action entry. The matching entry includes the SID of the second network device. The action entry instructs the second network device to decapsulate the packet and forward it based on the TEID carried in the packet.

[0280] When the IPv6 header further includes a TEID flag, the TEID flag may also be carried in the SID of a second network device, for example, the TEID flag and TEID are encapsulated in SID n. When SID n further includes a parameter (argument), SID n includes a locator, a TEID flag, TEID, and an argument.

[0281] From the above explanation, it can be seen that either the IPv6 basic header or the IPv6 extension header may be used to carry the TEID. In either case, no additional UDP header is required for encapsulation. This reduces the amount of data required for packet encapsulation and improves the efficiency of packet encapsulation.

[0282] In addition, the flow label in the IPv6 header may correspond to the destination port number of the GTP packet. The destination port number is not only used to perform load balancing in the forwarding process of the second packet, but it may also determine that the second packet contains a GTP packet. The port number may be a pre-configured fixed port number, or it may be a port number obtained through dynamic calculation based on the payload of the first packet. Optionally, the method for calculating the flow label of the second packet may be the same as the method for calculating the UDP source port used for load balancing in the GTP packet, and the port number value obtained from the GTP packet may be carried in the flow label of the second packet.

[0283] To implement the Field Flow Information Telemetry (IFIT) function, when the IPv6 header is encapsulated in the first packet, an IFIT instruction may be carried in the IPv6 header to perform hop-by-hop network field flow information telemetry, or network field flow information telemetry for a specified node or destination node. Specifically, the IFIT instruction may be carried in the IPv6 extension header.

[0284] S1304: The first network device sends the second packet to the second network device.

[0285] In this embodiment, after obtaining the second packet by encapsulating the IPv6 header in the first packet, the first network device sends the second packet to the second network device. The second network device may be a terminal node in a VXLAN network. For example, the second network device is switch 2 in Figure 1a. The destination address field in the IPv6 header of the second packet is the address of the second network device or the SRv6 locator of the second network device. For example, in Figure 1a, the destination address field in the IPv6 header of the second packet contains the address of switch 2 or the SRv6 locator of switch 2.

[0286] S1305: The second network device receives the second packet and obtains the TEID from the IPv6 header of the second packet.

[0287] From the above explanation, it can be seen that the TEID can be carried in either the IPv6 basic header or the IPv6 extension header. When the TEID is carried in different IPv6 headers, the second network device obtains the TEID from the IPv6 header using a different method. For implementations of how the second network device obtains the TEID from the IPv6 header, please refer to the relevant explanation in S705.

[0288] Note that since the SID of the second network device needs to be encapsulated in the second packet, the second network device must advertise its SID to the first network device before it receives the second packet sent by the first network device. In addition, the type of the second network device's SID may be further advertised. The type corresponding to the second network device's SID may be defined as an END.VN type, instructing the second network device to retrieve the TEID from the packet after receiving the corresponding packet, decapsulate the packet, look up the forwarding table based on the TEID, and forward the decapsulated packet based on the forwarding table. The SID of the second network device may also be the address of the second network device, or the corresponding address obtained after the address of the second network device may be compressed.

[0289] When advertising the SID of a second network device to a first network device, the second network device may further establish a forwarding entry locally. The forwarding entry includes a match item and an action item. The match item includes the SID of the second network device, and the action item indicates the action that should be performed when the match is successful. For example, the action item instructs the second network device to decapsulate the packet when the match is successful and to forward the decapsulated packet based on the TEID.

[0290] S1306: The second network device decapsulates the second packet in order to obtain the first packet.

[0291] In this embodiment, after obtaining the TEID, if the second network device determines, based on the information in the encapsulated IPv6 header, that the second network device is the terminal node, the second network device decapsulates the second packet, removes the encapsulated IPv6 header, and obtains the first packet. For example, if the second network device determines that the destination address field in the IPv6 header of the second packet contains the SID of the second network device, the second network device decapsulates the second packet based on the operation item in the forwarding entry in order to obtain the first packet. Decapsulating a packet includes removing the IPv6 basic header encapsulated in the second packet in order to obtain the first packet, or removing the IPv6 basic header and IPv6 extension header encapsulated in the second packet in order to obtain the first packet.

[0292] The execution order of S1305 and S1306 is not limited in this embodiment. S1306 may be performed before S1305, S1305 may be performed before S1306, or S1305 and S1306 may be performed simultaneously.

[0293] S1307: The second network device forwards the first packet based on the TEID.

[0294] After receiving the first packet, the second network device determines the forwarding path based on the TEID and forwards the first packet based on the forwarding path.

[0295] Based on embodiments of the methods described above, one embodiment of the present application further provides a network device for packet transmission. This is described below with reference to the accompanying drawings.

[0296] Figure 14 is a schematic diagram of a possible structure of a network device in an embodiment of the method described above. Network device 1400 may implement the functions of the first network device in the embodiments shown in Figure 2, Figure 7, or Figure 13. Alternatively, network device 1400 may implement the functions of switch 1 in the embodiment shown in Figure 1a and VTEP 1 in the embodiment shown in Figure 12. See Figure 14. Network device 1400 includes an acquisition unit 1401, a processing unit 1402, and a transmission unit 1403. These units may implement the corresponding functions of the first network device in the examples of the method described above.

[0297] The acquisition unit 1401 is configured to assist the network device 1400 when implementing S201 in FIG. 2, S701 in FIG. 7, or S1301 in FIG. 13. The processing unit 1402 is configured to assist the network device 700 when implementing S202 and S203 in FIG. 2, S702 and S703 in FIG. 7, or S1302 and S1303 in FIG. 13. The transmission unit 703 is configured to assist the network device 1400 when implementing S204 in FIG. 2, S704 in FIG. 7, or S1304 in FIG. 13, and / or when implementing other processes performed by the first network device in the technology described herein. For example, the acquisition unit 1401 is configured to perform the operation of acquiring the first packet by the first network device in the embodiment of the foregoing method. The processing unit 1402 is configured to perform various processing operations performed by the first network device in the embodiment of the foregoing method. The transmission unit 1403 is configured to perform the operation of transmitting a packet by the first network device in the embodiment of the foregoing method. For example, the processing unit 1402 is configured to obtain a tunnel header based on the first packet and encapsulate an IPv6 header in the first packet to obtain a second packet. The transmission unit 1403 is configured to transmit the second packet to the second network device. For the specific execution process, refer to the detailed description of the corresponding steps in the embodiments shown in FIG. 2, FIG. 7, or FIG. 13. Details will not be described again here.

[0298] Optionally, the processing unit 1402 is specifically configured to obtain a tunnel header based on an interface for receiving the first packet. The tunnel header corresponds to the interface for receiving the first packet.

[0299] It should be noted that in this embodiment of the present application, the unit division is illustrative and merely represents a logical division of function. In actual implementations, other division methods may be used. The functional units in this embodiment of the present application may be integrated into a single processing unit, or each unit may exist physically independently, or two or more units may be integrated into a single unit. For example, in the embodiment described above, the processing unit and the transmission unit may be the same unit or different units. The integrated unit may be implemented in hardware form or in the form of a software functional unit.

[0300] Figure 15 is a schematic diagram of a possible structure of a network device in an embodiment of the method described above. The network device 1500 may implement the functions of the second network device in the embodiments shown in Figure 2, Figure 7, or Figure 13. Alternatively, the network device 1500 may implement the functions of switch 2 in the embodiment shown in Figure 1a and VTEP 2 in the embodiment shown in Figure 12. See Figure 15. The network device 1500 includes a receiving unit 1501, a processing unit 1502, and a transmitting unit 1503. These units may perform the corresponding functions of the second network device in the examples of the method described above. The receiving unit 1501 is configured to assist the network device 1500 when performing S205 in Figure 2, S705 in Figure 7, or S1305 in Figure 13. The processing unit 1502 is configured to assist the network device 1500 when performing S205 and S206 in Figure 2, S705 and S706 in Figure 7, or S1305 and S1306 in Figure 13. The transmitting unit 1503 is configured to assist the network device 1500 when performing S207 in Figure 2, S707 in Figure 7, or S1307 in Figure 13, and / or when performing other processing performed by the second network device in the techniques described herein. For example, the receiving unit 1501 is configured to perform the operation of the second network device receiving a second packet in the embodiments of the method described above. The processing unit 1502 is configured to perform various processing operations performed by the second network device in the embodiments of the method described above. The transmitting unit 1503 is configured to perform the operation of the second network device forwarding a first packet in the embodiments of the method described above. For example, the processing unit 1502 is configured to obtain the tunnel header from the IPv6 header of the second packet and decapsulate the second packet in order to obtain the first packet. The transmission unit 1503 is configured to forward the first packet.For specific execution processes, please refer to the detailed descriptions of the corresponding steps in the embodiments shown in Figures 2, 7, or 13. Further details are not provided here.

[0301] Optionally, the processing unit 1502 is configured to determine that the destination address field contains the address of a second network device, and in response to this determination, to retrieve the tunnel header from the destination address field.

[0302] Optionally, the processing unit 1502 is configured to determine that the destination address field of the second packet contains the SID of the second network device, and in response to this determination, to obtain the tunnel header from the SID of the second network device.

[0303] Optionally, the transmitting unit 1503 is further configured to advertise the SID of the second network device to the first network device before the receiving unit 1501 receives the second packet from the first network device.

[0304] Optionally, the processing unit 1502 is configured to further establish a forwarding entry which includes a matching item and an action item, the matching item includes the SID of a second network device, decapsulates the second packet based on the action item, and forwards the first packet based on the tunnel header.

[0305] It should be noted that in this embodiment of the present application, the unit division is illustrative and merely represents a logical division of function. In actual implementations, other division methods may be used. The functional units in this embodiment of the present application may be integrated into a single processing unit, or each unit may exist physically independently, or two or more units may be integrated into a single unit. For example, in the embodiment described above, the processing unit and the transmission unit may be the same unit or different units. The integrated unit may be implemented in hardware form or in the form of a software functional unit.

[0306] Refer to Figure 16. One embodiment of the present application provides a network system 1600 for packet transmission. The system 1600 is configured to implement a packet transmission method in an embodiment of the method described above. The system 1600 includes network devices 1601 and 1602. Network device 1601 may implement the functions of the first network device in the embodiment shown in Figure 2, Figure 7, or Figure 13, or the functions of network device 1400 in Figure 14. Network device 1602 may implement the functions of the second network device in the embodiment shown in Figure 2, Figure 7, or Figure 13, or the functions of network device 1500 in Figure 15. Network device 1601 may further implement the functions of switch 1 in the embodiment shown in Figure 1a, or the functions of VTEP 1 in the embodiment shown in Figure 12. Network device 1602 may further implement the functions of switch 2 in the embodiment shown in Figure 1a, or the functions of VTEP 2 in the embodiment shown in Figure 12. For specific execution processes, please refer to the detailed descriptions of the corresponding steps in the embodiments shown in Figures 2, 7, or 13. Further details are not provided here.

[0307] Figure 17 is a schematic diagram of the structure of a network device according to one embodiment of the present application. The network device may be, for example, the first network device or the second network device in the embodiment of the method described above. Alternatively, the network device 1400 in Figure 14 and the network device 1500 in Figure 15 may be implemented by using the device shown in Figure 17.

[0308] Please refer to Figure 17. The network device 1700 includes a processor 1710, a communication interface 1720, and memory 1730. The network device 1700 may have one or more processors 1710. In Figure 17, one processor is used as an example. In this embodiment of the present application, the processor 1710, the communication interface 1720, and the memory 1730 may be connected by using a bus system or by other means. In Figure 17, for example, a bus system 1740 is used for connection.

[0309] The processor 1710 may be a CPU, an NP, or a combination of a CPU and an NP. The processor 1710 may further include hardware chips. The hardware chips may be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or a combination thereof. The PLDs may be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof.

[0310] When the network device is the first network device, the processor 1710 may perform the relevant functions in the embodiments of the method described above, for example, receiving a first packet, obtaining the tunnel header corresponding to the first packet, and encapsulating the IPv6 header in the first packet in order to obtain a second packet.

[0311] The communication interface 1720 is configured to receive and transmit packets. Specifically, the communication interface 1720 may include a receiving interface and a transmitting interface. The receiving interface may be configured to receive packets, and the transmitting interface may be configured to transmit packets. There may be one or more communication interfaces 1720.

[0312] Memory 1730 may include volatile memory, such as random access memory (RAM). Memory 1730 may further include non-volatile memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD). Memory 1730 may further include combinations of the aforementioned types of memory. Memory 1730 may store, for example, user-related information as described above.

[0313] Optionally, memory 1730 stores an operating system, a program, an executable module, or a data structure, or a subset thereof, or an extension thereof. A program may contain a variety of operation instructions for performing a variety of actions. An operating system may contain a variety of system programs and be configured to perform a variety of basic services and handle hardware-based tasks. The processor 1710 may read a program from memory 1730 in order to carry out the method provided in the embodiments of this application.

[0314] The memory 1730 may be a storage device within the network device 1700, or it may be a storage device independent of the network device 1700.

[0315] Bus system 1740 can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or other similar buses. Bus system 1740 can be further classified into address buses, data buses, control buses, etc. For simplicity, only a single thick line is used to represent buses in Figure 17; however, this does not mean that there is only one bus or only one type of bus.

[0316] Figure 18 is a schematic diagram of the structure of another network device 1800 according to one embodiment of the present application. The network device 1800 may be configured as the first or second network device in the embodiments of the method described above. Alternatively, the network device 1400 in Figure 14 and the network device 1500 in Figure 15 may be implemented by using the device shown in Figure 18.

[0317] The network device 1800 includes a main control panel 1810 and an interface panel 1830.

[0318] The main control panel 1810 is also called the main processing unit (MPU) or route processor card. The main control panel 1810 controls and manages the components of the network device 1800, including functions for routing calculation, device management, device maintenance, and protocol processing. The main control panel 1810 includes the central processing unit 1818 and memory 1812.

[0319] The interface panel 1830 is also called a line processing unit (LPU), line card, or service panel. The interface panel 1830 is configured to provide various service interfaces and forward data packets. Service interfaces include, but are not limited to, Ethernet interfaces and POS (Packet over SONET / SDH) interfaces. An example of an Ethernet interface is a flexible Ethernet client interface (FlexE Clients). The interface panel 1830 includes a central processing unit 1831, a network processor 1832, a forwarding entry memory 1834, and a physical interface card (PIC) 1833.

[0320] The central processing unit 1831 on the interface panel 1830 is configured to control and manage the interface panel 1830 and to communicate with the central processing unit 1811 on the main control panel 1810.

[0321] The network processor 1832 is configured to perform packet forwarding processing. The network processor 1832 may take the form of a forwarding chip. Specifically, the processing of uplink packets includes processing the packet's inbound interface and looking up the forwarding table. The processing of downlink packets includes looking up the forwarding table, etc.

[0322] The physical interface card 1833 is configured to implement physical layer interconnection functionality. Original traffic enters the interface board 1830 through the physical interface card 1833, and processed packets are sent out through the physical interface card 1833. The physical interface card 1833 includes at least one physical interface, which is also called a physical port. The physical interface card 1833 is also called a subcard and may be mounted on the interface board 1830, and is responsible for converting optical / electrical signals into packets, performing validation on packets, and forwarding packets to the network processor 1832 for processing. In some embodiments, the central processing unit 1831 of the interface board 1803 may also perform the functions of the network processor 1832, for example, performing software forwarding based on a general-purpose CPU. Therefore, the network processor 1832 is not required in the physical interface card 1833.

[0323] Optionally, the network device 1800 includes multiple interface boards. For example, the network device 1800 further includes an interface board 1840. The interface board 1840 includes a central processing unit 1841, a network processor 1842, a transfer entry memory 1844, and a physical interface card 1843.

[0324] Optionally, the network device 1800 may further include a switching panel 1820. The switching panel 1820 may also be called a switch fabric unit (SFU). When the network device has multiple interface panels 1830, the switching panel 1820 is configured to complete data exchange between the interface panels. For example, interface panel 1830 may communicate with interface panel 1840 via the switching panel 1820.

[0325] The main control panel 1810 is coupled to the interface panel 1830. For example, the main control panel 1810, interface panel 1830, interface panel 1840, and switching panel 1820 are connected to the system backplane via a system bus to perform communication. In one possible implementation, an inter-process communication (IPC) channel is established between the main control panel 1810 and the interface panel 1830, and the main control panel 1810 communicates with the interface panel 1830 through the IPC channel.

[0326] Logically, the network device 1800 includes a control plane and a forwarding plane. The control plane includes a main control panel 1810 and a central processing unit 1831. The forwarding plane includes components that perform forwarding, such as a forwarding entry memory 1834, a physical interface card 1833, and a network processor 1832. The control plane performs functions such as router functionality, generating forwarding tables, signaling and processing protocol packets, and configuring and maintaining the device status. The control plane delivers the generated forwarding tables to the forwarding plane. On the forwarding plane, the network processor 1832 searches the forwarding tables delivered by the control plane to forward packets received by the physical interface card 1833. The forwarding tables delivered by the control plane may be stored in the forwarding entry memory 1834. In some embodiments, the control plane and the forwarding plane may be completely separate and not the same device.

[0327] It should be understood that the processing unit 1402 of the network device 1400 may be equivalent to the central processing unit 1811 or the central processing unit 1831 of the network device 1800.

[0328] In this embodiment of the present application, it should be understood that the operations performed on interface panel 1840 are consistent with the operations performed on interface panel 1830. For brevity, details are not described. It should be understood that the network device 1800 in this embodiment may correspond to the first or second network device in the embodiments of the method described above. The main control panel 1810, interface panel 1830, and / or interface panel 1840 of the network device 1800 may perform the functions and / or various steps performed by the first or second network device in the embodiments of the method described above. For brevity, details are again not described here.

[0329] It should be understood that there may be one or more main control panels. When there are multiple main control panels, the main control panels may include an active main control panel and a backup main control panel. There may be one or more interface panels, and network devices with stronger data processing capabilities will provide more interface panels. There may be one or more physical interface cards on an interface panel. There may be no switching panels, or there may be one or more switching panels. When there are multiple switching panels, load sharing and redundant backups may be implemented together. In a centralized transport architecture, a network device may not require switching panels, and the interface panels provide the functionality to handle system-wide service data. In a distributed transport architecture, a network device may have at least one switching panel, and data exchange between multiple interface panels is performed using switching panels to provide high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of network devices in a distributed architecture are higher than those of devices in a centralized architecture. Optionally, a network device may contain only one card, i.e., no switching panels. The functions of the interface panels and main control panels are integrated onto the card. In this case, the central processing unit on the interface panel and the central processing unit on the main control panel can be combined into a single central processing unit on a card to perform the functions obtained after the two central processing units are combined. This form of device (for example, network devices such as low-end switches or routers) has low data exchange and processing capabilities. The specific architecture to be used depends on the specific networking deployment scenario.

[0330] In some possible embodiments, the first or second network device may be implemented as a virtualization device. For example, the virtualization device may be a virtual machine (VM) on which a program having packet transmission capabilities is executed, and the virtual machine is deployed on a hardware device (e.g., a physical server). The virtual machine is a software-simulated full computer system that has all the hardware system functions and runs in a completely isolated environment. The virtual machine may be configured as the first or second network device. For example, the first or second network device may be implemented on a general-purpose physical server in combination with network function virtualization (NFV) technology. The first or second network device may be a virtual host, a virtual router, or a virtual switch. Those skilled in the art will be able to read this application to virtualize the first or second network device having the aforementioned functions on a general-purpose physical server in combination with NFV technology. Further details are again not described here.

[0331] It should be understood that the network device in the aforementioned product form separately has any functions implemented by the first or second network device in the embodiment of the method described above. Further details will not be explained here.

[0332] One embodiment of this application further provides a chip including a processor and an interface circuit. The interface circuit is configured to receive instructions and transmit instructions to the processor. The processor may be configured to implement the packet transmission method described above. The processor is coupled to memory. The memory is configured to store a program or instructions. When the program or instructions are executed by the processor, the chip system is enabled to implement the method in any one of the embodiments of the method described above.

[0333] Optionally, a chip system may include one or more processors. A processor may be implemented using hardware or using software. When implemented using hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented using software, the processor may be a general-purpose processor, implemented by reading software code stored in memory.

[0334] Optionally, the chip system may also include one or more memories. The memories may be integrated with the processor or disposed separately from the processor. This is not limited in this application. For example, the memory may be non-temporary memory, such as read-only memory (ROM). The memory and processor may be integrated on the same chip or disposed separately on different chips. The type of memory and the arrangement of the memory and processor are not limited in this embodiment of this application.

[0335] For example, a chip system could be a field programmable gate array (FPGA), application-specific integrated circuit (ASIC), system on chip (SoC), central processing unit (CPU), network processor (NP), digital signal processor (DSP), microcontroller unit (MCU), programmable logic device (PLD), or another integrated chip.

[0336] One embodiment of this application further provides a computer-readable storage medium containing instructions and computer programs. When the computer-readable storage medium is executed on a computer, the computer is enabled to implement the packet transmission method of the above-described embodiment.

[0337] One embodiment of this application further provides a computer program product, which includes instructions or a computer program. When the computer program product is executed on a computer, the computer is enabled to implement the packet transmission method of the above-described embodiment.

[0338] In the specification, claims, and accompanying drawings of this application, terms such as “first,” “second,” “third,” and “fourth” (if any) are intended to distinguish similar objects but do not necessarily indicate a particular order or permutation. Since data used in such a manner are interchangeable in appropriate circumstances, it should be understood that embodiments described herein may be carried out in an order other than that shown or described herein. In addition, the terms “includes” and “have,” and any other variations thereof, are intended to include non-exclusive inclusion. For example, a process, method, system, product, or device including a list of steps or units is not necessarily limited to those explicitly listed steps or units, and may include other steps or units that are not explicitly listed or are specific to such process, method, product, or device.

[0339] For the sake of clarity and to keep the explanation concise, it will be readily apparent to those skilled in the art that the detailed operating processes of the aforementioned systems, apparatus, and units can be described by referring to the corresponding processes in the embodiments of the methods described above, and the details are not described again here.

[0340] In some embodiments provided in this application, it should be understood that the disclosed systems, apparatus, and methods may be implemented in other ways. For example, the embodiments of the apparatus described above are merely illustrative. For example, the division of units is merely a logical division of services, and other divisions may be used in actual implementations. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. In addition, the mutual coupling, direct coupling, or communication connection shown or discussed may be implemented through some interface. Indirect coupling or communication connection between apparatus or units may be implemented electrically, mechanically, or in other ways.

[0341] Units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, may be located in one place, or may be distributed across multiple network units. Some or all of the units may be selected based on the actual requirements for achieving the objectives of the embodiment's strategy.

[0342] In addition, the service units in the embodiments of this application may be integrated into a single processing unit, or each unit may exist physically independently, or two or more units may be integrated into a single unit. The integrated unit may be implemented in the form of hardware, or in the form of a software service unit.

[0343] When an integrated unit is implemented in the form of a software service unit and sold or used as a standalone product, the integrated unit may be stored on a computer-readable storage medium. Based on such understanding, the portion of the technical measures of this application that contributes fundamentally to or to existing technology, or all or part of the technical measures, may be implemented in the form of a software product. A computer software product is stored on a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, server, or network device) to perform all or part of the steps of the method described in the embodiments of this application. The storage medium includes any medium capable of storing program code, such as a USB flash drive, removable hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0344] Those skilled in the art should recognize that, in one or more of the examples described above, the services described in this application may be implemented by using hardware, software, firmware, or any combination thereof. When implemented by using software, the services may be stored on a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable medium includes computer storage media and communication media. Communication media include any medium that enables a computer program to be transmitted from one place to another. Storage media may be any available medium accessible to a general-purpose computer or a dedicated computer.

[0345] The objectives, technical measures, and beneficial effects of this application will be described in more detail in the specific implementations described above. It should be understood that the above description represents only a specific implementation of this application.

[0346] In conclusion, the embodiments described above are intended not to limit this application, but solely to illustrate the technical solutions of this application. Although this application is described in detail with reference to the embodiments described above, those skilled in the art will still understand that modifications can be made to the technical solutions described in the embodiments described above, or equivalent substitutions can be made to some of their technical features, without departing from the scope of the technical solutions of the embodiments of this application. [Explanation of symbols]

[0347] 1400 network devices 1401 units acquired 1402 Processing Unit 1403 Transmitter Unit 1500 network devices 1501 Receiving Unit 1502 Processing Unit 1503 Transmitter Unit 1600 System 1601 Network Device 1602 Network Device 1700 network devices 1710 Processor 1720 Communication Interface 1730 memory 1740 Bus System 1800 network devices 1810 Main control panel 1811 Central Processing Unit 1812 memory 1820 Switching Panel 1830 Interface Panel 1831 Central Processing Unit 1832 Network Processors 1833 Physical Interface Card 1834 Transfer Entry Memory 1840 Interface Panel 1841 Central Processing Unit 1842 Network Processors 1843 Physical Interface Card 1844 Transfer Entry Memory

Claims

1. A packet transmission method, The first network device obtains the first packet, The first network device obtains a tunnel header based on the first packet, The steps of the first network device encapsulating the first packet using an Internet Protocol version 6 (IPv6) header to obtain the second packet, wherein the IPv6 header includes an IPv6 basic header and an IPv6 extension header, the IPv6 extension header comprises a Destination Option Header (DOH), the DOH includes a Type Length Value (TLV) indicating that the DOH carries the tunnel header, and the DOH carries the tunnel header. A method comprising the step of transmitting the second packet to a second network device by the first network device.

2. The method according to claim 1, wherein the tunnel header comprises one or more of the following: a Virtual Extensible Local Area Network (VXLAN) header, a General-Purpose Packet Radio Services Tunneling Protocol (GTP) header, a General-Purpose Routing Encapsulation (GRE) header, an IP-in-IP header, an Intrasite Automated Tunnel Addressing Protocol (ISATAP) header, an Internet Protocol Version 4 over Internet Protocol Version 6 (IPv4 over IPv6) header, a Network Virtualization with General-Purpose Routing Encapsulation (NVGRE) header, a Layer 2 Tunneling Protocol Version 3 (L2TPv3) header, and an MPLS in GRE header.

3. The method according to claim 2, wherein the Options portion of the DOH transports the tunnel header.

4. The method according to claim 2, wherein when the tunnel header is the VXLAN header or the GTP header, the IPv6 extension header further comprises a segment routing header (SRH).

5. The method according to claim 4, wherein the tunnel header is transported in the segment identifier list (SID list) of the SRH.

6. The method according to claim 5, wherein the tunnel header is transported in the SID corresponding to the second network device in the segment list (SID list) of the SRH.

7. The method according to claim 6, wherein the SID of the second network device instructs the second network device to forward packets based on the tunnel header carried in the SID.

8. The method according to claim 2, wherein when the tunnel header is the VXLAN header or the GTP header, the IPv6 header is the IPv6 basic header.

9. The method according to claim 8, wherein the tunnel header is carried in the destination address field of the IPv6 base header.

10. A packet transmission method, A second network device receives a second packet from a first network device, wherein the second packet is encapsulated in an Internet Protocol version 6 (IPv6) header, the IPv6 header includes an IPv6 basic header and an IPv6 extension header, the IPv6 extension header comprises a Destination Option Header (DOH), the DOH includes a Type Length Value (TLV) indicating that the DOH carries a tunnel header, and the DOH carries the tunnel header. The second network device obtains the tunnel header from the IPv6 header, A step of decapsulating the second packet in order to obtain the first packet using the second network device, wherein the first packet does not have the IPv6 header. A packet transmission method comprising the steps of forwarding the first packet based on the tunnel header by the second network device.

11. The method according to claim 10, wherein the tunnel header comprises one or more of the following: a Virtual Extensible Local Area Network (VXLAN) header, a General-Purpose Packet Radio Services Tunneling Protocol (GTP) header, a General-Purpose Routing Encapsulation (GRE) header, an IP-in-IP header, an Intrasite Automated Tunnel Addressing Protocol (ISATAP) header, an Internet Protocol Version 4 over Internet Protocol Version 6 (IPv4 over IPv6) header, a Network Virtualization with General-Purpose Routing Encapsulation (NVGRE) header, a Layer 2 Tunneling Protocol Version 3 (L2TPv3) header, and an MPLS in GRE header.

12. The method according to claim 11, wherein the Options portion of the DOH transports the tunnel header.

13. A network device for packet transmission, applicable to a network comprising multiple network devices, wherein the multiple network devices comprise a first network device and a second network device, the first network device comprising at least one processor and one or more memories, The one or more of the aforementioned memories are configured to store instructions or program code, The aforementioned processor, The aforementioned network device, To obtain the first packet, To obtain a tunnel header based on the first packet and to encapsulate the first packet using an Internet Protocol version 6 (IPv6) header to obtain a second packet, wherein the IPv6 header includes an IPv6 basic header and an IPv6 extensions header, the IPv6 extensions header comprises a Destination Option Header (DOH), the DOH includes a Type Length Value (TLV) indicating that the DOH carries the tunnel header, and the DOH carries the tunnel header. Sending the second packet to the second network device A network device configured to execute the instructions or program code in one or more of the memories, in order to enable this.

14. The device according to claim 13, wherein the tunnel header comprises one or more of the following: a Virtual Extensible Local Area Network (VXLAN) header, a General-Purpose Packet Radio Services Tunneling Protocol (GTP) header, a General-Purpose Routing Encapsulation (GRE) header, an IP-in-IP header, an Intrasite Automated Tunnel Addressing Protocol (ISATAP) header, an Internet Protocol Version 4 over Internet Protocol Version 6 (IPv4 over IPv6) header, a Network Virtualization with General-Purpose Routing Encapsulation (NVGRE) header, a Layer 2 Tunneling Protocol Version 3 (L2TPv3) header, and an MPLS in GRE header.

15. A network device for packet transmission, applicable to a network comprising multiple network devices, wherein the multiple network devices comprise a first network device and a second network device, and the network device is the second network device, and the network device comprises at least one processor and one or more memories. The one or more of the aforementioned memories are configured to store instructions or program code, The aforementioned processor, The aforementioned network device, Receiving a second packet from the first network device, wherein the second packet is encapsulated in an Internet Protocol version 6 (IPv6) header, the IPv6 header includes an IPv6 basic header and an IPv6 extension header, the IPv6 extension header comprises a Destination Option Header (DOH), the DOH includes a Type Length Value (TLV) indicating that the DOH carries the tunnel header, and the DOH carries the tunnel header. The process involves obtaining the tunnel header from the IPv6 header and decapsulating the second packet in order to obtain the first packet, wherein the first packet does not have the IPv6 header. The first packet is forwarded based on the tunnel header. A network device configured to execute the instructions or program code in one or more of the memories, in order to enable this.

16. The network device according to claim 15, wherein the tunnel header comprises one or more of the following: a Virtual Extensible Local Area Network (VXLAN) header, a General-Purpose Packet Radio Services Tunneling Protocol (GTP) header, a General-Purpose Routing Encapsulation (GRE) header, an IP-in-IP header, an Intrasite Automated Tunnel Addressing Protocol (SATAP) header, an Internet Protocol Version 4 over Internet Protocol Version 6 (IPv4 over IPv6) header, a Network Virtualization with General-Purpose Routing Encapsulation (NVGRE) header, a Layer 2 Tunneling Protocol Version 3 (L2TPv3) header, and an MPLS in GRE header.

17. The network device according to claim 16, wherein when the tunnel header is the VXLAN header or the GTP header, the IPv6 header is the IPv6 basic header.

Images