CN117354377A

CN117354377A - Message processing method, network equipment and communication system

Info

Publication number: CN117354377A
Application number: CN202211203005.5A
Authority: CN
Inventors: 韩冰; 夏阳; 李呈; 胡志波
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-07-04
Filing date: 2022-09-29
Publication date: 2024-01-05
Also published as: WO2024007939A1

Abstract

A message processing method, network device and communication system are disclosed to solve the problem of low bandwidth utilization rate caused by too long message header of a message. The method comprises the following steps: the first network equipment obtains a first message, wherein a message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header also comprises at least part of different contents in different messages of the data stream; the first network device sends a first message to the second network device.

Description

Message processing method, network equipment and communication system

The present application claims priority from the chinese patent office, application number 202210780372.5, entitled "a SRv6& IPv6+ extreme header compression method, apparatus and system", filed on 7.4 of 2022, the entire contents of which are incorporated herein by reference.

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a message processing method, a network device, and a communications system.

Background

With the rise of new services such as 5G and cloud services and the development of network programming technologies, the services require a forwarding plane of a network to have stronger programmable capability, and meanwhile, a more concise converged network solution is required. In this context, segment routing (segment routing IPv, SRv 6) based on the internet protocol sixth edition (Internet protocol version, ipv 6) forwarding plane has evolved.

SRv6 is a Segment Routing (SR) network architecture implemented based on an IPv6 data plane, supporting the insertion of forwarding instructions at a source node to refer to forwarding of data messages. The core idea of SR is to cut the message forwarding path into different segments and insert segment information into the message at the starting point of the path to guide the message forwarding. Such path segments are called "segments" and are identified by Segment identification (Segment identifier, SID). Specifically, SRv is implemented by extending the segment routing header (segment routing header, SRH) on the basis of an IPv6 message. The SRH consists of a series of SIDs, each of which is a 128bit IPv6 address, in the format: a locate + function (locator + function), wherein locator is the first N bits (bit) of data that may be used to describe an address, and the last 128-N bits of data may be used to define the corresponding function. The IPv6 address is divided into different fields by codes, thereby realizing different network functions.

When the forwarding path of the message is composed of more SIDs, the length of the header of SRv is up to 200 bytes, which is almost equal to the length of the payload, and is equivalent to only 50% of the effective data transmission bandwidth of the network, and the link of 100 gigabits per second (Gigabits per second, gbps) is equivalent to only 50Gbps, resulting in a decrease in the network bandwidth utilization after SRv6 is applied.

Disclosure of Invention

The application provides a message processing method, network equipment and a communication system, which are used for reducing the length of a message header of a message and improving the utilization rate of network bandwidth.

In a first aspect, the present application provides a method for processing a message. The method comprises the following steps: the first network equipment obtains a first message, wherein a message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header also comprises at least part of different contents in different messages of the data stream; the first network device sends a first message to the second network device. The first message reserves different contents in different messages of the data stream in the message header, so that the length of the message header of the first message is shorter, the proportion of the message header in the message is reduced, the proportion of effective data is increased, the network can transmit more messages, the proportion of the effective data transmitted in the network bandwidth is also increased, and the utilization rate of the network bandwidth can be improved.

In one possible implementation, the method further includes: the first network equipment obtains a second message, wherein the second message belongs to a data stream, and a message header of the second message comprises a compression identifier and at least part of the same content in different messages of the data stream; the first network device sends a second message to the second network device, so that the second network device stores a first mapping relation according to the second message, the first mapping relation comprises a compression identifier and a mapping relation between the same at least partial content in different messages of the data stream, and the first mapping relation is used for decompressing the first message. By using the compression identifier to indicate a data stream, that is, the compression identifier can refer to at least part of the same content in the message header of different messages in the data stream, the second network device can sense and store the first mapping relationship between the compression identifier and the same content in the message header of different messages in the data stream through the second message, and the message header of the first message in the data stream can carry the compression identifier without carrying at least part of the same content in the message header of different messages in the data stream, so that the length of the message header is greatly compressed. The second network device stores the first mapping relation of the same content in the message heads of the different messages in the data stream and the compression identifier, so that the first message can be decompressed through the compression identifier and the first mapping relation, namely, the message heads of the first message are restored to the message heads of the same content in the message heads of the different messages carried in the data stream, and the forwarding of the message is not influenced while the network bandwidth utilization rate is improved.

In one possible implementation, the second message is an internet protocol version four (Internet protocol version, IPv 4) or IPv6 message, and the header payload length field (IPv 6 message) or total length field (IPv 4 message) of the second message has the compression identifier carried in the payload length field or total length field. Or the second message is an IPv6 message, and the message header of the second message comprises an IPv6 expansion header, and the compression identifier is positioned in the IPv6 expansion header. The load length of the message or the total length of the data message can be recalculated according to the message itself, so that the content in the payload length field or the total length field is replaced by the compression identifier, and under the condition of not changing the format of the message, the second message is used for transmitting the compression identifier and the same content in the message header of different messages in the data stream to the second network device, so that the second network device can store the mapping relation according to the second message.

In one possible implementation, the header of the first packet and the header of the second packet further include version identifiers of the compression identifiers, and the first mapping relationship includes a mapping relationship between the compression identifiers, the version identifiers, and at least some of the same content in different packets of the data stream. By combining the version identification and the compression identification, the method can ensure that the same at least partial content in the message heads of different messages in the data stream can be obtained accurately when the first message is decompressed, thereby ensuring that the decompressed first message is accurate.

In one possible implementation, the header of the second message includes a version number field in which the current version identifier is carried. Or the second message is an IPv6 message, and the message header of the second message comprises an IPv6 extension header, and the current version identifier is positioned in the IPv6 extension header of the second message. The messages in the same data stream generally use the same protocol, and the second network device can know the content in the version number field according to the protocol supported by the second network device, so that the content in the version number field can be replaced by the version identifier of the compression identifier. And under the condition of not changing the message format, transmitting the compression identifier and at least part of the same content in the message header of different messages in the data stream to the second network equipment through the second message, so that the second network equipment can store the first mapping relation according to the second message.

In one possible implementation manner, before the first network device obtains the first packet, the method further includes: the first network equipment receives a third message, wherein the third message belongs to a data stream, a message header of the third message comprises a first field and a second field, the content in the first field is at least part of different contents in different messages of the data stream, and the content in the second field is at least part of the same content in different messages of the data stream; the first network device obtains a compressed identifier according to the characteristic information of the third message, wherein the characteristic information is used for identifying the data stream. The first network device obtaining a first message includes: the first network device obtains a first message according to the compression identifier and the third message, and the length of the message header of the first message is smaller than that of the third message. The data stream to which the message belongs is identified through the characteristic information in the message, so that the compression identifier corresponding to the data stream to which the message belongs is obtained according to the characteristic information, and therefore, when the third message is compressed, the compression identifier can be added into the compressed message header to obtain the first message, and therefore, the message header of the first message can not need to carry all contents, the length of the message header of the first message is shorter than that of the third message, and the length of the first message is shorter than that of the third message, and the network bandwidth utilization rate is improved.

In one possible implementation, the feature information includes at least one of a virtual private network VPN identification and content in the second field carried in the third message.

In one possible implementation, the third message is an IPv4 message.

In one possible implementation manner, the third message is an IPv6 message, a header of the third message includes an IPv6 header, the IPv6 header includes an IPv6 basic header and N IPv6 extension headers, the second field includes a field in the IPv6 basic header and/or the N IPv6 extension headers, and N is a positive integer greater than or equal to 0.

In one possible implementation, N is greater than or equal to 1, and the N IPv6 extension headers include at least one of an SRH extension header, an application aware network extension header, a network slice extension header, and a bit index explicit copy extension header.

In one possible implementation, N is greater than or equal to 1, an SRH extension header is included in the N IPv6 extension headers, the SRH extension header includes a segment identification list, and the second field includes a segment identification list field. The segment identifier list often includes at least one segment identifier, and the length of one segment identifier reaches 16 bytes, so that the second field includes the segment identifier list field, that is, the message header of the first message does not carry the content in the segment identifier list field, which can effectively reduce the length of the message header.

In one possible implementation, the SRH extension header further includes an SRH base header, and the second field includes at least one field in the SRH base header. The length of the SRH basic header is 8 bytes, so that the message header of the first message does not carry the content in at least one field in the SRH basic header, the length of the message header can be reduced by 8 bytes at most, and the length of the message header can be further reduced.

In one possible implementation, N is greater than or equal to 1, and the N IPv6 extension headers include an application-aware network extension header, and the second field includes at least one field in the aware network extension header. The length of one segment identification reaches 16 bytes, so that the second field comprises a segment identification list field, that is, the message header of the first message does not carry the content in the segment identification list field, thereby effectively reducing the length of the message header. The length of one segment identification reaches 16 bytes, so that the second field comprises a segment identification list field, that is, the message header of the first message does not carry the content in the segment identification list field, thereby effectively reducing the length of the message header.

In one possible implementation, N is greater than or equal to 1, and the N IPv6 extension headers include a network slice extension header, and the second field includes at least one field in the network slice extension header. The length of the network slice extension head reaches 16 bytes, so that the message head of the first message does not carry the content in at least one field in the network slice extension head, the length of the message head can be reduced by 16 bytes at most, and the length of the message head can be effectively reduced.

In one possible implementation, N is greater than or equal to 1, and the N IPv6 extension headers include bit-indexed explicit replication extension headers, and the second field includes at least one field of the bit-indexed explicit replication extension headers. The length of the bit index explicit copy extension head is at least 16 bytes, so that the message head of the first message does not carry the content in at least one field in the bit index explicit copy extension head, the length of the message head can be reduced by at least 16 bytes at most, and the length of the message head can be effectively reduced.

In one possible implementation, the second network device is a next hop device of the first network device. When the message is transmitted between two adjacent network devices, the message does not need to be forwarded by other network devices, so that the transmission of the first message between the first network device and the second network device is not affected even if part of the content is not carried in the message header of the first message. The short message header of the first message can improve the bandwidth utilization rate of the link between the first network device and the second network device.

In one possible implementation, the first network device and the second network device are network devices in an IPv6 segment route SRv path of the data flow, and the second network device is a next SRv segment endpoint node of the first network device in the SRv6 path. When there is a transit node between the first network device and the second network device, the transit node forwards the message according to the destination IP address in the IPv6 basic header, so, in the case that the message header of the first message retains the complete content of the IPv6 basic header, the content in the IPv6 extension header and the like can be compressed by the method of the present scheme, so that even if the content in the message header of the first message is incomplete, the content can be forwarded from the first network device to the second network device through other network devices, and the bandwidth utilization of the link between the first network device and the second network device is improved.

In a second aspect, the present application provides a method for processing a message. The method comprises the following steps: the second network equipment receives a first message from the first network equipment, wherein the message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header of the first message also comprises at least part of different contents in different messages of the data stream; the second network device decompresses the first message into a third message according to a first mapping relation, wherein the first mapping relation comprises a mapping relation of compression identification and at least partial content identical to that in different messages of the data stream, and a message header of the third message comprises different content in different messages of the data stream and identical content in different messages of the data stream. Therefore, the second network device can restore the first message into the third message according to the compression identifier and the first mapping relation in the message header of the first message. On the premise of improving the bandwidth utilization rate of a link segment between the first network device and the second network device, the forwarding of the message in a subsequent link is not affected.

In one possible implementation, the method further includes: the second network equipment receives a second message from the first network equipment, wherein the message header of the second message comprises a compression identifier and at least part of the same content in different messages of the data flow; and the second network equipment stores the first mapping relation according to the second message. Therefore, the second network device can accurately restore the first message to the third message according to the first mapping relation when receiving the first message.

In one possible implementation, the header of the first packet and the header of the second packet further include version identifiers of the compression identifiers, and the first mapping relationship includes a mapping relationship between the compression identifiers, the version identifiers, and at least some of the same content in different packets of the data stream. The second network device decompressing the first message into a third message according to the first mapping relation includes: the second network equipment obtains at least part of the same content in different messages of the data stream according to the compression identifier, the version identifier and the first mapping relation; the second network device decompresses the first message into a third message according to the first message and the same at least partial content in different messages of the data stream.

In one possible implementation manner, the third message is an IPv6 message, a header of the third message includes an IPv6 header, the IPv6 header includes an IPv6 basic header and N IPv6 extension headers, identical contents in different messages of the data flow are located in the IPv6 basic header and/or the N IPv6 extension headers, and N is a positive integer greater than or equal to 0.

In one possible implementation, the second network device is a next hop device of the first network device.

In one possible implementation, the first network device and the second network device are network devices in an IPv6 segment route SRv path of the data flow, and the second network device is a next SRv segment endpoint node of the first network device in the SRv6 path.

In a third aspect, the present application provides a network device. The network device includes: the processing module is used for obtaining a first message, and the message header of the first message comprises a compression identifier, wherein the compression identifier indicates a data stream corresponding to the first message, and the message header also comprises at least part of different contents in different messages of the data stream; and the receiving and transmitting module is used for transmitting the first message to the second network equipment.

In one possible implementation, the processing module is configured to obtain a second packet, where the second packet belongs to a data stream, and a header of the second packet includes a compression identifier and at least part of the same content in different packets of the data stream; the receiving and transmitting module is used for sending a second message to the second network equipment so that the second network equipment stores a first mapping relation according to the second message, the first mapping relation comprises a compression identifier and a mapping relation between the same at least partial content in different messages of the data stream, and the first mapping relation is used for decompressing the first message.

In one possible implementation, the header of the first packet and the header of the second packet further include version identifiers of the compression identifiers, and the first mapping relationship includes a mapping relationship between the compression identifiers, the version identifiers, and at least some of the same content in different packets of the data stream.

In one possible implementation manner, the transceiver module is configured to receive a third packet, where the third packet belongs to a data stream, and a packet header of the third packet includes a first field and a second field, where contents in the first field are at least part of contents that are different in different packets of the data stream, and contents in the second field are at least part of contents that are the same in different packets of the data stream; the processing module is used for obtaining a compression identifier according to the characteristic information of the third message, wherein the characteristic information is used for identifying the data stream; the processing module is used for obtaining a first message according to the compression identifier and the third message, and the length of the message header of the first message is smaller than that of the third message.

In a fourth aspect, the present application provides a network device. The network device includes: the receiving and transmitting module is used for receiving a first message from the first network equipment, the message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header of the first message also comprises at least part of different contents in different messages of the data stream; the processing module is used for decompressing the first message into a third message according to a first mapping relation, wherein the first mapping relation comprises a mapping relation of compression identification and at least partial content identical to that in different messages of the data stream, the first message is decompressed into the third message, and the message header of the third message comprises different content in different messages of the data stream and identical content in different messages of the data stream.

In one possible implementation manner, the transceiver module is configured to receive a second packet from the first network device, where a header of the second packet includes a compression identifier and at least part of the same content in different packets of the data stream; and the processing module is used for storing the first mapping relation according to the second message.

In one possible implementation manner, the header of the first message and the header of the second message further include version identifiers of the compression identifiers, the first mapping relationship includes a mapping relationship among the compression identifiers, the version identifiers and at least part of the same content in different messages of the data stream, and the processing module is configured to obtain at least part of the same content in different messages of the data stream according to the compression identifiers, the version identifiers and the first mapping relationship; and the processing module is used for decompressing the first message into a third message according to the first message and at least part of the same content in different messages of the data stream.

In a fifth aspect, the present application provides a network device. The network device comprises a processor and a memory, the processor being coupled to the memory, the processor being configured to perform the message processing method of the first aspect or any one of the possible implementations of the first aspect, or the message processing method of the second aspect or any one of the possible implementations of the second aspect, based on instructions stored in the memory.

In a sixth aspect, the present application provides a communication system. The system comprises a first network device and a second network device; wherein the first network device is configured to implement the first aspect or the message processing method in any possible implementation manner of the first aspect, and the second network device is configured to implement the second aspect or the message processing method in any possible implementation manner of the second aspect.

In a seventh aspect, the present application provides a computer-readable storage medium. The computer readable storage medium comprises instructions which, when run on a computer, cause the computer to perform the message processing method as in the first aspect or any one of the possible implementations of the first aspect, or the message processing method as in the second aspect or any one of the possible implementations of the second aspect.

In an eighth aspect, the present application provides a computer program product comprising instructions which, when executed by a network device, cause the network device to perform the method of message processing as in the first aspect or any one of the possible implementations of the first aspect, or the second aspect or any one of the possible implementations of the second aspect.

In a ninth aspect, the present application provides a chip comprising processing circuitry for invoking and running a program from memory, such that a network device in which the chip apparatus is installed implements the message processing method of the first aspect or any one of the possible implementations of the first aspect, or the message processing method of the second aspect or any one of the possible implementations of the second aspect.

Drawings

Fig. 1 is a schematic structural diagram of a SRv message provided in an embodiment of the present application;

fig. 2 is a schematic diagram of a forwarding path of an indication packet based on a segment list according to an embodiment of the present application;

fig. 3 is a schematic diagram of a forwarding flow based on End SID according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of a communication system according to an embodiment of the present application;

fig. 5a is a schematic diagram of a message structure of a single-layer header according to an embodiment of the present application;

Fig. 5b is a schematic diagram of a message structure with a dual-layer header according to an embodiment of the present application

Fig. 6 is a flow chart of a message processing method provided in an embodiment of the present application;

fig. 7 is a schematic structural diagram of a third packet according to an embodiment of the present application;

fig. 8 is a schematic diagram of a first packet according to an embodiment of the present application;

fig. 9 is a flow chart of another embodiment of a message processing method according to the embodiment of the present application;

fig. 10 is a schematic structural diagram of a second packet according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of another network device according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of still another network device according to an embodiment of the present application.

Detailed Description

The application provides a message processing method, network equipment and a communication system, which are used for solving the problem of low bandwidth utilization rate caused by overlong message heads of messages.

The message processing method provided by the application can be applied to message forwarding scenes in a network, such as message forwarding scenes based on Segment Routing (SR) and tunnel technologies such as virtual expansion local area network (virtual eXtensible local area network, vxLAN), or common IPv4 and IPv6 message forwarding scenes. The SR technique is briefly described below.

SR is a tunneling technique based on source route forwarding mode. SR technology includes two data planes, namely multiprotocol label switching (multi-protocol label switching, MPLS) and IPv6, which are referred to as SR MPLS and IPv6 segment routing (english: internetprotocol version 6for Segment Routing, abbreviated: SRv 6), respectively. SRv6 a segment list (SID list, also called segment list or SID list) is typically carried using a segment routing header (segment routing header, SRH). SID list is used to specify the forwarding path for IPv6 messages. Wherein SRH is an IPv6 Routing Header (IPv 6 Routing Header). The Routing Type (Routing Type) of SRH has a value of, for example, 4.

The design ideas of SR include: the source node in the traffic flow maintains flow (per-flow) based state, e.g., SRv path information, while other nodes do not need to maintain per-flow state. Wherein the source node of the traffic flow is the source node of the SR tunnel. The function of maintaining the per-flow state is the SR policy (SR policy).

Segments (also called segments) or Segment IDs (SIDs) are core elements of the SR. The definition of segment includes: segment represents any topology, instruction, or service.

An SR Tunnel (SR Tunnel) refers to a Tunnel formed by encapsulating segment list into a header at a source node. An SR tunnel may be used for traffic engineering (traffic engineering, TE) tunnel applications, operations, aadm initiation, and maintenance (OAM) detection, fast reroute (FRR), etc. Here, a tunnel generally refers to a set of end-to-end paths between two points, where the two points are a start point of the tunnel and an end point of the tunnel, respectively, the start point of the tunnel is a source node, and the end point of the tunnel is a tail node. The tunnel includes a path or paths.

SRv6 technology refers to the application of SR technology in IPv6 networks. Some terminology in SRv6 technology is described below.

SRH employs a loose source routing mode. That is, it is not required that each hop on the forwarding path support and parse SRH, nor that SID list in SRH contain each hop node on the path. There are multiple types of node roles in the SRv network, which fall substantially into the following 3 classes.

Srv6 Source Node (SRv 6 Source Node): a source node that generates SRv message. The source node may be a host that generates an IPv6 message and supports SRv6, or may be an edge device of SRv domain.

2. Transfer Node (Transit Node): IPv6 nodes forwarding SRv messages but not SRv 6. The transit node takes the SRv6 message as a common IPv6 message, searches the IPv6 routing table according to the longest matching principle, processes and forwards the message, and does not process SRH. The transit node may be a general IPv6 node or a node supporting SRv 6.

Srv6 segment endpoint node (SRv 6 Segment Endpoint Node): any node that receives and processes SRv6 message, where the IPv6 destination address of the message must be a locally configured SID, hereinafter referred to as an endpoint node.

The role of a node is related to its role in SRv message forwarding. The same node may take different roles, such as a node may be SRv source node in some SRv path and a transit node or endpoint node in other SRv6 paths.

Endpoint node behavior (behavir) includes End SIDs, end.X SIDs, end.DT4SIDs, end.OTP SIDs (End is an abbreviation for End) and the like, also referred to as instructions, each SID being bound to an instruction indicating an action that the End node needs to perform when processing SIDs. In addition to the above behavior, the endpoint node behavior also includes additional (flag) behavior including, for example, penultimate segment pop-up SRH (penultimate segment pop of the SRH, PSP), penultimate segment pop-up SRH (ultimate segment pop of the SRH, USP), and penultimate segment decapsulation (ultimate segment decapsulation, USD). PSP refers to the penultimate endpoint node in the SRv path performing the operation of removing SRH. USP refers to the last endpoint node in the SRv path performing the operation to remove SRH. USD refers to the operation of the last endpoint node in the SRv path to perform the decapsulation of the outer layer IPv6 header.

SIDs are identifiers of segments that are used to identify unique segments. At the forwarding level of SR MPLS, SIDs may be mapped to MPLS labels. At the forwarding level of SRv, the SID may be mapped to an IPv6 address. The SID can essentially represent a topology, instruction, or service.

SRv6 SIDs are coded using IPv6 addresses (128 bits) and encapsulated in SRH. When forwarding a message, a node supporting SRv6 queries a local SID table (also called local SID table) according to a destination address (destination address, DA) in the message, and when the destination address of the message is matched with any SID in the local SID table, the destination address is confirmed to hit the local SID table, and then corresponding operation is executed based on topology, instruction or service corresponding to the SID; if the destination address of the message is not matched with each SID in the local SID table, inquiring the IPv6 routing forwarding table according to the destination address, and forwarding the message according to the routing forwarding table hit by the destination address in the routing forwarding table.

SRv6 message: the IPv6 message is composed of an IPv6 standard header+an extension header (0..n) +payload (payload). To implement segment routing IPv6 (SRv) based on the IPv6 forwarding plane, an IPv6 extension header, called SRH (segment routing header) extension header, is added, which specifies an explicit path for IPv6 and stores segment list information for IPv 6. The source node adds an SRH extension header in the IPv6 message, and the intermediate node can forward according to the path information contained in the SRH extension header. By adding the extension head in this way, the SR is smoothly fused with the original IPv6 forwarding plane.

Referring to fig. 1, fig. 1 is a schematic structural diagram of a SRv6 packet according to an embodiment of the present application. SRv6 messages may include IPv6 header, SRH and payload. Each part of the SRv message is described below by (1) to (3):

(1) IPv6 base header in SRv message.

The IPv6 base header in SRv message may include a Source Address (SA) and a DA. In a normal IPv6 message, the IPv6 DA is fixed. In SRv, in SRv6, the IPv6 DA identifies the next node of the current message, and in the SR tunnel, the SR node can continuously update the destination address to complete hop-by-hop forwarding. The SID carried by the destination address in the IPv6 header may be referred to as an active SID.

(2) SRH in SRv message.

SRH is an IPv6 extension header. SRH is used to implement SRv6 based on the IPv6 forwarding plane. As shown in fig. 1, the SRH may include the following (2.1) to (2.9).

(2.1) segment List

The segment list may include one or more SIDs, each of which may be in the form of an IPv6 address, so that the segment list may also be understood as an explicit IPv6 address stack. The segment list may be denoted as segment list n, which may be 128 x n bits long, and may be encoded starting from the last segment of the path. segment list is in the form of an IPv6 address.

(2.2) the number of Segments Left (SL).

The SL field is used to indicate the number of intermediate nodes that should still be accessed before reaching the destination node, and may also be referred to as the remaining node field. The value of the SL field may indicate the active SID in the segment list. The length of SL may be 8 bits. For example, if the segment list includes 5 SIDs, SID0, SID1, SID2, SID3 and SID4, respectively, and the SL has a value of 2, it indicates that there are 2 SIDs in the segment list that are not processed, SID0 and SID1, respectively, the SID currently to be processed in the segment list is SID2, and there are 2 SIDs in the segment list that have been processed, SID3 and SID4, respectively.

In combination with (2.1) and (2.2) above, SRH can be abstracted into the following format:

SRH(SL＝n)

<segment list[0],segment list[1],segment list[2],...,segment list[n]>：

Wherein < segment list [0], segment list [1], segment list [2], segment list [ n ] is a segment list of Rv6 message, similar to MPLS label stack information in SR MPLS, generated at the source node. segment list [ n ] is the first segment list to be processed on the SRv path, segment list [ n-1] is the second, segment list [ n-2] is the third, and segment list [0] is the n+1th.

It should be noted that, when expressing the SRH in the IPv6 message, the SRH may be expressed in the reverse order, that is, as (segment list [2], segment list [1], segment list [0 ]).

As shown in fig. 2, fig. 2 is a schematic diagram of a forwarding path of a packet based on a segment list indication according to an embodiment of the present application. In SRv, each time a SRv node is passed, the Segments Left (SL) field is decremented by 1 and the IPv6DA information is transformed. Wherein the Segments Left and Segments List fields together determine the IPv6DA information.

If the SL value is n (n-0), then the IPv6DA value is the value of Segments List [ n ].

If the SL value is n-1, then the IPv6DA value is the value of Segments List [ n-1 ].

If the SL value is n-2, then the IPv6DA value is the value of Segments List [ n-2 ].

If the SL value is 0 (n-n=0), then the IPv6DA value is the value of Segments List [0 ].

(2.3) optional (TLV)

The TLV is an encoded format, and includes a type (type), a length (length), and a value (value). One TLV may be included in the SRH, multiple TLVs may be included, or no TLV may be included. Different TLVs in the SRH may have a side-by-side relationship or may have a nested relationship.

(2.4) next header (next header): SRv6 the message may also include one or more extension headers or one or more higher layer headers following the extension Header, the Next Header identifying the type of Header immediately following the SRH. The length of the next header type field may be 8 bits.

(2.5) an extended header length (English: header extended length, abbreviated: hdr Ext Len) field is used to indicate the length of the SRH header. The length of the SRH header mainly refers to the length of the segment list, e.g., the length occupied from segment list [0] to segment list [ n ].

(2.6) routing type (routing type) field: for identifying the routing header type, SRH type is 4. The length of the routing type field may be 8 bits.

(2.7) last entry field. An index representing the last element of the segment list contained in the segment list. The Last Entry field may be 8 bits in length.

(2.8) flags (flags) field: for indicating some identification of the data packet. The length of the Flags field may be 8 bits.

(2.9) Tag (Tag) field: for identifying the same group of data packets. The Tag field may be 16 bits in length.

(3) SRv6, payload in message.

The payload in SRv message is, for example, an IPv4 message, an IPv6 message, or an Ethernet (Eth) frame. The load in SRv message may be referred to as the original message.

Referring to fig. 3, fig. 3 is a schematic diagram of a forwarding flow based on End SID according to an embodiment of the present application, where the forwarding flow includes: the message is pressed into the SRH at the node B, the path information in the SRH is < K::, I:, H:, E: >, and the destination address in the IPv6 header of the message is E:. Whenever a message passes through an intermediate node, such as node E, node H and node I, the intermediate node queries a Local SID table according to the IPv6 DA of the message, and if the intermediate node determines that the message is of End type, the intermediate node continues to query an IPv6 routing forwarding table, forwards the message according to the next hop of the output interface that is queried by the IPv6 routing forwarding table, and simultaneously subtracts 1 from SL to convert the IPv6 DA once. The transit nodes such as node C and node G do not participate in SRv processing on the SRv packet forwarding path, i.e., perform normal IPv6 packet forwarding according to the destination IP in the destination address field in the IPv6 packet header. When the message arrives at the node I, the node I inquires the Local SID table according to the destination address of the IPv6 header in the message, judges the type of the message to be End type, then continuously inquires the IPv6 routing forwarding table, and forwards the message according to the outlet interface searched by the IPv6 routing forwarding table. Meanwhile SL is reduced to 0, IPv6 DA is changed to K, at the moment, path information < K:, I:, H:, E:, is of no practical value, so that node I removes SRH by utilizing PSP characteristics, and then forwards the message with the SRH removed to node K.

In the process of transmitting the message in the network, the message header of the message also occupies the network bandwidth. The longer the length of the header of the message, the larger the occupancy rate of the network bandwidth, which can lead to a decrease in the occupancy rate of the effective data (load) transmitted in the network, i.e., a decrease in the network bandwidth utilization rate. For example, in the process of forwarding a message based on tunneling technology, such as SRv, vxLAN, etc., a tunnel header needs to be encapsulated in an original message as an outer layer header, which results in a higher data proportion and a lower payload (payload) proportion in the header of the message encapsulating the tunnel header, while the network bandwidth is limited, and eventually, the bandwidth utilization is reduced. Even if the IPv4 message with the tunnel header not encapsulated, the length of the message header can reach 60 bytes at the highest. The length of the basic message header of the IPv6 message without the encapsulated tunnel header is 40 bytes, and if the IPv6 message also carries the IPv6 extension header, the length of the message header is longer.

The header of the SRv message includes an IPv6 base header (40 bytes) and an SRH extension header, as exemplified by the SRv message. The SRH extension header includes an SRH base header (8 bytes) and a SID list. Each SID in the SID list is 16 bytes in length, and if the SID list includes 6 SIDs, the SID list may be up to 96 bytes long. Thus, in the header of the SRv message, only the length of the IPv6 base header and the SRH extension header can reach 144 bytes. If more SIDs are contained in the SID list, or other IPv6 extension headers are also contained in the message header, the length of the message header can reach 200 bytes at maximum, which is almost equal to the length of the load, the effective data transmission bandwidth of the network is only 50%, and the link of 100Gbps is only 50Gbps.

Therefore, the following embodiments are provided to solve the problem that the bandwidth utilization of the network is reduced due to the too long message header.

As shown in fig. 4, fig. 4 is a schematic structural diagram of a communication system according to an embodiment of the present application. The communication system of the present embodiment may be implemented based on network devices in various networks, such as SRv network, vxLAN network, IPv6 network, IPv4 network, or SR MPLS network, to name but a few. The network device may be a physical network device such as a switch, router, or server. The network device may also be a virtual network device such as a virtual switch or a virtual router.

The communication system includes a first network device and a second network device. The first network device and the second network device may be two adjacent hops in the packet forwarding path, and the second network device is a next-hop device of the first network device. The two adjacent hops may refer to two network devices having a direct connection relationship in a packet forwarding path, where a packet sent by a first network device to a second network device directly arrives at the second network device without being transferred by other network devices. In some other embodiments, the first network device and the second network device may also be connected through other network devices. For example, the first network device and the second network device are both network devices in the SRv6 network, the second network device is the next endpoint node of the first network device on the SRv path, and a transit node (a node that only performs IPv6 forwarding but does not perform SRv processing) may be spaced between the first network device and the second network device.

Illustratively, in fig. 3, the SRv forwarding path of the message is a node→b node→c node→e node→g node→h node→i node→k node, where B node, E node, H node and I node are nodes performing SRv processing, E node is the next endpoint node of B node, H node is the next endpoint node of E node, and I node is the next endpoint node of H node, and so on. The C node and the G node are transit nodes which do not perform SRv processing. The first network device and the second network device may be two network devices directly connected to each other, such as node a and node B, node B and node C, respectively, or may be two network devices spaced apart from each other by a transit node C, such as node B and node E, or two network devices spaced apart from each other by a transit node G, such as node C and node H.

In this embodiment, the first network device is configured to compress a packet. The first network device may compress and replace the header of the message, where the compressed message has a header with a shorter length. The compressed header is hereinafter referred to as compressed header. The message comprising the compressed message header is hereinafter referred to as compressed message.

The message may be SRv message, vxLAN message, etc. with a tunnel header encapsulated, or ordinary (non-encapsulated tunnel header) IPv6 message or IPv4 message, etc. As shown in fig. 5a and fig. 5b, fig. 5a is a schematic structural diagram of a single-layer header packet according to an embodiment of the present application; fig. 5b is a schematic diagram of a message structure of a dual-layer header according to an embodiment of the present application. Messages can be classified into messages with single layer headers (fig. 5 a) and messages with double layer headers (fig. 5 b) according to the number of header layers of the messages. In fig. 5b, the double-layer header refers to a new header encapsulated in the outer layer of the original message, where the original message is used as the load of the new header, and the new header may be called a tunnel header or an outer layer header, and the header of the original message may be called an inner layer header. When the message has two layers of message heads, the first network device compresses the message heads, which can be referred to as compressing the outer layer of message heads, compressing the inner layer of message heads, compressing the outer layer of message heads and compressing the inner layer of message heads. When the message only has a single-layer message header, the first network device may compress the single-layer message header of the message.

The first network device may compress the message by compressing the header of the message and replacing the header of the message with the compressed header, or may directly encapsulate the compressed header for the message.

The above-mentioned directly encapsulated compressed header generally occurs in a scenario where the first network device is the tunnel start point. For example, when the first network device is a source node in a SRv network, the first network device needs to encapsulate SRv heads including SR paths for the outer layer of the original packet. Also for example, when the first network device is a VxLAN tunnel endpoint (VxLAN Tunnel Endpoints, VTEP) in a VxLAN network, the first network device needs to encapsulate a tunnel header including an IP header, an ethernet header, and a VxLAN header for the outer layer of the received original message. In this case, in order to improve the efficiency of the compression processing, the first network device may not generate and encapsulate the outer layer packet header of the original packet, but directly generate the compression packet header corresponding to the outer layer packet header, encapsulate the compression packet header for the original packet, and further obtain the compression packet. Therefore, the method for compressing the header includes the case of directly generating the compressed header in the scenario where the first network device is the tunnel start point. In another implementation, when the header of the original message also needs to be compressed, the header of the original message may be compressed and replaced. Of course, in this case, the first network device may also generate an outer layer packet header, and encapsulate the compressed packet header for the original packet after forming the compressed packet header according to the outer layer packet Wen Tousheng, which is not limited herein.

Therefore, the header compression of the existing message in the message and the header directly after the message encapsulation compression belong to the header compression of the message in the application.

The message header generally includes a data link layer header, an IP header, an upper layer protocol header, and the like. In this embodiment, the first network device may compress at least one of an IP header and an upper layer protocol header in the packet header. For a packet with a dual layer header, the first network device may also compress the data link layer header in the inner layer header. That is, in the dual-layer packet header, the compressible portion includes a portion of the outer layer packet header except the data link layer header, and the data link layer header, the IP header, the upper layer protocol header, etc. in the inner layer packet header.

In this embodiment, the principle of the first network device compressing the header is that at least part of the same content in different messages of the data stream in the header to be compressed is deleted, and at least part of different content in different headers of the data stream is reserved, so as to obtain a compressed header. Therefore, compared with an uncompressed message head, the length of the compressed message head is shorter, and the utilization rate of network bandwidth can be improved. The specific compression method of the message will be described in detail below.

The second network device is configured to decompress the message. Specifically, the second network device is configured to decompress a compressed header of the compressed message after receiving the compressed message, and replace the compressed header of the compressed message with a decompressed header, i.e. a header before compression, so as to decompress the compressed message. The second network device, for example, stores at least part of the deleted content in the compressed header, restores the compressed header to the header before compression according to the content retained in the compressed header and the deleted at least part of the content stored in the second network device, so as to obtain the decompressed header, and replaces the compressed header with the decompressed header.

When the second network device is the tunnel endpoint, or the destination device of the message, such as the last (USP behavior or USD behavior) or penultimate endpoint node (SPS behavior) in the SRv path, or the VTEP in the VXLAN network, the compressed tunnel header may not need to be restored. When the compressed message header is obtained by compressing the tunnel header, the second network device may pop up the compressed message header of the compressed message, so as to strip the original message from the compressed message. When the compressed header is obtained by compressing the tunnel header and the inner layer header, the second network device needs to restore and replace the compressed inner layer header with the header of the original message before compression, and the part of the compressed tunnel header can be deleted without restoration and replacement.

According to the embodiment, the same at least partial content in different messages of the same data stream is deleted from the message header of the message, so that redundant transmission of repeated content in different message headers of the same data stream in a network can be reduced, the proportion of effective data in the network transmission process is improved, and the bandwidth utilization rate is improved. And the second network device can restore the compressed message header to the message header before compression, so that the transmission of the message in the network is not affected.

Specifically, as shown in fig. 6, fig. 6 is a flow chart of a message processing method provided in the embodiment of the present application. The execution body of the embodiment is the first network device in the communication system. The embodiment comprises the following steps:

s601: the first network device obtains a first message, a message header of the first message includes a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header of the first message further includes at least part of different contents in different messages of the data stream.

The first message is the compressed message, and the message header of the first message is the compressed message header.

Specifically, the first network device compresses the message header of the received third message to obtain a compressed message header. The first network device replaces the message header of the third message header with the compressed message header or directly encapsulates the compressed message header to obtain the first message. The header of the first message includes a compressed identification field. The compression identification field is used for bearing a compression identification (compress identity, CID) for indicating the data flow to which the first message belongs. The length of the compressed identification field may be 12 bits, 14 bits, 16 bits, 18 bits, 20 bits, etc., and the length of the compressed identification field may be greater or less, without limitation. It can be understood that the first packet is a packet after the third packet is compressed, and the first packet and the third packet are still substantially the same packet, so that the data flow to which the first packet belongs is also the data flow to which the third packet belongs.

The header of the third message includes the contents of the first field and the contents of the second field. The header of the first message includes the contents of the first field but does not include the contents of the second field. The content carried by the first field is at least part of the content which is different in a different message (a message before compression) of the data stream to which the third message belongs. That is, the content in the first field of the existing message in the data stream to which the third message belongs is different from the content in the first field of the other messages. The content carried by the second field is at least part of the same content in a different message (a message before compression) of the data stream to which the third message belongs. That is, the contents of the second fields of all the messages in the data stream to which the third message belongs are the same.

The first field may include a part of all fields having different contents in different messages of the data stream. The first field may also include all fields with different contents in different messages of the data stream. The second field may include a part of the fields among all the fields having the same content in different messages of the data stream. The second field may also include all fields having the same content in different messages of the data stream, without limitation.

The first network device performs compression processing on the header of the third message to obtain a compressed header, which may be that the first network device obtains the content in the first field in the header of the third message, and generates the compressed header according to the content in the first field and the compression identifier corresponding to the third message. The compressed message header does not carry the content in the second field, so that the length of the compressed message header is shorter.

The first network device maintains, for example, a compressed flow table. The compressed flow table may be generated by the first network device, or may be generated by the controller and issued to the first network device. The compressed stream table stores the characteristic information of the data stream and the second mapping relation of the compressed identification. The compressed flow table may be a linear table, such as an array or a linked list. The compressed stream table may also be a non-linear table, such as a hash table, or the like. The message carries at least part of characteristic information of the data stream to which the message belongs. If the characteristic information corresponding to different messages is the same, it can be stated that the messages belong to the same data stream. After receiving the third message, the first network device obtains feature information according to the third message, and further obtains a compression identifier corresponding to the third message according to the feature information and a second mapping relation stored in the compression flow table.

In one possible implementation, the characteristic information may be a plurality of sets. The tuples are, for example, a tuple (source IP address and destination IP address), a triplet (source IP address, destination IP address and protocol), a quadruple (source IP address, destination IP address, source port and destination port), a quintuple (source IP address, destination IP address, source port, destination port and protocol) or a seven-tuple (source IP address, destination IP address, source port, destination port, source queue pair, destination queue pair and protocol) and the like. When the third message is a message with a single-layer message header, the multi-tuple is obtained from the single-layer message header. When the third message is a message with a double-layer message header, the multiple groups can be obtained from the inner-layer message header or the outer-layer message header. When the third message is an IPv6 message, the tuple may also be a source IP address and a flow label in the IPv6 basic message header. When the third message is a message with a single-layer message header, the source IP address and the flow label may be obtained from the single-layer message header.

In another possible implementation, the characteristic information may include a tuple and a virtual private network (virtual private network, VPN) identification. The VPN identification may be a VPN SID. When the third packet is a SRv packet, the first network device may obtain the VPN SID from the SID list in the tunnel header of the third packet. When the first network device is a source node in the SRv network, the first network device may determine a corresponding VPN instance according to a port that receives the third packet, and obtain, according to a destination IP address in a header of the third packet, a VPN SID from a routing table corresponding to the VPN instance.

The VPN identification may also be a VPN index (VPN index) when the first network device is a source node in the SRv network. The VPN index is used to identify a VPN instance. The first network device may determine the VPN index from the port from which the third message was received.

In another possible implementation, the feature information may be the content in the second field. Of course, the feature information may be other features besides the above features, as long as the feature information can uniquely identify one data stream. Or the content of the second fields of all the messages in the data stream corresponding to the feature information needs to be ensured to be the same.

Since the feature information has a mapping relation with the compressed identifier, the feature information can identify a data stream, and then the compressed identifier can also identify the data stream. One compressed identification can only be used to identify at most one data stream at a time. The compressed identity may be issued by the control device of the first network device. When the first network device compresses a new data stream, a compression identifier is obtained from a plurality of unassigned compression identifiers, and a second mapping relationship between the compression identifier and characteristic information of the data stream is stored. When the second mapping relation corresponding to a certain compression identifier in the compression flow table is aged, the compression identifier can be recovered and added into the unassigned compression identifier again.

The compressed identity may also be generated by the first network device based on the characteristic information. For example, the first network device combines its node identification with the characteristic information (the tuple, or the tuple plus VPN identification) of the data stream to obtain the compressed identification. In order to control the length of the compressed identifier, the node identifier and the characteristic information of the data stream can be compressed to a fixed length in a hash operation mode or the like. Also for example, the compressed identification is obtained by hashing or compressing the content in the second field to a fixed length using a compression algorithm.

In another implementation, the compressed identity may be the characteristic information when the characteristic information of the data stream is a tuple, or a tuple plus a VPN identity. The compressed flag length should be shorter than the total length of the content in the second field, so that the length of the compressed header including the compressed flag can be shorter than the length of the header before compression.

When the compressed identifier is a reusable compressed identifier, the compressed header may further include a version identifier field. The version identification field is used to carry the version identification of the compressed identification. The length of the revision identification field may be 4 bits, 6 bits, 8 bits, etc., and the length of the revision identification field may be longer or shorter, without limitation. When the compressed identifier is reused, the first network identifier adopts a version identifier different from the version identifier corresponding to the previous R times of using the compressed identifier. R is an integer greater than or equal to 1. For example, when a compression identifier is used for the first time, the version identifier corresponding to the compression identifier is 01, and when the compression identifier is used for the second time, the version identifier corresponding to the compression identifier is 02. The compressed identification and the version identification are thus able to uniquely identify one data stream without causing the second network device to identify a different data stream as the same data stream due to reuse of the compressed identification.

The second mapping relationship is, for example, a mapping relationship between the feature information and the compression identifier and version identifier. The first network device obtains feature information according to the third message, obtains a compression identifier and a version identifier from the compression flow table according to the feature information and the second mapping relation, and adds the compression identifier and the version identifier into the compression message header when constructing the compression message header corresponding to the third message.

Illustratively, the third message is an IPv6 message, and an IPv6 header of the IPv6 message is compressed. The IPv6 message header of the IPv6 message comprises an IPv6 basic header and N IPv6 extension headers. N is a positive integer greater than or equal to 0, namely, the IPv6 message does not need to include an IPv6 extension head, and also can include at least one IPv6 extension head. When the IPv6 packet does not include the IPv6 extension header, the IPv6 base header may be compressed, i.e., the second field includes a field in the IPv6 base header. When the IPv6 message includes an IPv6 extension header, the IPv6 basic header may be compressed, that is, the second field includes a field in the IPv6 basic header; the IPv6 extension header may also be compressed, i.e., the second field includes a field in the IPv6 extension header; it is also possible to compress both the IPv6 basic header and the IPv6 extension header, i.e. the second field comprises fields in both the IPv6 basic header and the IPv6 extension header. When the number of the IPv6 expansion heads is greater than or equal to 2, all the IPv6 expansion heads can be compressed, and part of the IPv6 expansion heads can be compressed.

As shown in fig. 1, the IPv6 base header includes fields of version number (version), stream Type (TC), stream label (flow label), payload length (payload length), next header (next header), hop limit (hop limit), source Address (SA), and destination address (destination address, DA).

Wherein, since the lengths of the payloads of different messages may be different, the contents in the payload length field may be different in different messages. In one possible implementation, the payload length field may be retained as a second field in the compressed header, i.e. the compressed header includes the contents of the payload length field. In some other implementations, the compressed header may not include the contents of the payload length field, because the contents of the payload length field may be recalculated based on the length of the payload in the packet, and may be recovered, thereby enabling the length of the compressed header to be further shortened by 2 bytes.

When the characteristic information of the data stream includes contents of all fields except the payload length field in the IPv6 basic header, that is, contents of all fields except the payload length field in the IPv6 basic header of all packets in the data stream are identical, the second field may include at least part of the fields except the payload length field in the IPv6 basic header. If the second field includes all fields except the payload length field in the IPv6 base header and the compressed header does not include the content of the payload length field, then the compressed header does not include the content in the IPv6 base header, in which case the compression rate of the IPv6 base header reaches a maximum, i.e., a percentage compression. The length of the IPv6 basic header is fixed and is 40 bytes (320 bits), and under the condition that the compression rate of the IPv6 basic header is maximum, the length of the compressed message header can be shortened by 40 bytes compared with the uncompressed message header.

When the characteristic information of the data stream is a multi-group or multi-group plus VPN, the content of partial fields, such as a traffic type field and a flow label field, may be different in IPv6 basic headers of different messages of the same data stream. In this case, the first field may include a flow type field and a flow index field, and the second field may include at least part of fields other than the payload length field, the flow type field, and the flow index field in the IPv6 base header. I.e. the compressed header comprises the contents of the stream type field and the stream label field and not the second field. If the second field includes all fields except the payload length field, the stream type field and the stream label field in the IPv6 basic header, and the compressed header does not include the payload length field, then the compressed header includes 28 bits of the contents of the stream type field and the stream label field in the IPv6 basic header, and the length of the compressed header can be 292 bits shorter than the uncompressed header. When the first field includes a stream type field and a stream label field, the number of data streams can be reduced, so that the storage space occupied by the feature information and the compressed identifier mapping relation for storing the data streams in the first network device is reduced.

In one possible scenario, for example, when there is also a transit node between the first network device and the second network device, the transit node needs to identify the IPv6 message and forward the message according to the destination IP address in the IPv6 base header. In this case, the IPv6 base header is not compressed, i.e., all of the contents in the IPv6 base header are retained.

Possible implementations of compressing the IPv6 extension header are described next. IPv6 extension headers include, for example, SRH extension headers, application-aware network (APN) extension headers, network slice extension headers, and bit index explicit copy (bit index explicit replication, BIER) extension headers, etc. The IPv6 extension header may also include other extension headers, without limitation.

As shown in fig. 1, the SRH extension header includes an SRH basic header and a SID list. The first network device may compress the SRH basic header, or compress the SID list, or both the SRH basic header and the SID list.

The SID list may include at least one SID field. The second field may include at least one field in a list of SIDs. When the second field includes all fields in the SID list, the compressed header does not include contents in the SID list, and assuming that the SID list includes K SIDs, the length of the compressed header may be shortened by k×16 bytes compared to the uncompressed header.

The SRH basic header includes fields of a next header (next header), an extension header length (Hdr Ext Len), a routing type (routing type), a number of remaining segments (segments left), a last item (last entry), a flag (flags), and a tag (tag). Wherein the content of the next header field may be different in different messages of the data stream, the first field may include the next header field, i.e. the compressed message header includes the content in the next header field. For fields in the SRH base header other than the next header field, the second field may include at least a portion thereof. The length of the SRH basic header is 8 bytes, the length of the next header field is 1 byte, and if the second field includes all fields except the next header field, the length of the compressed header may be shortened by 7 bytes compared to the uncompressed header. When the first field includes the next header field, the number of data streams can be reduced, so that the storage space occupied by the characteristic information and the compressed identifier mapping relation for storing the data streams in the first network device is reduced.

Of course, when the characteristic information of the data stream includes the content in the next header field in the SRH basic header, the content in the next header field is the same in a different packet of the data stream, and then the second field may include the next header field, i.e., the compressed packet header does not include the content in the next header field. In this case, if the second field includes all fields in the SRH header, the SRH header compression rate reaches the maximum, and the compressed header does not include the content of the SRH header, then the length of the compressed header may be shortened by 8 bytes compared to the uncompressed header.

The network slice extension header includes fields such as a next header (next header), an extension header length (Hdr Ext Len), an option type (option type), an option data length (option data length), a flag bit (flags), a network slice identification (slice ID), and a reserved field (reserved). The second field may include at least a portion of a field in a network slice extension header.

The compression manner of the APN extension header, the network slice extension header, the BIER extension header, etc. is similar to that of the SRH extension header, and thus will not be described in detail herein. In the case of maximum compression rate, the second field includes all fields of an APN extension header (16 bytes), a network slice extension header (16 bytes), or a BIER extension header (16 bytes minimum), etc., that is, the compressed packet header does not include the content in the corresponding extension header.

Fig. 7 is a schematic structural diagram of a third packet according to an embodiment of the present application, as shown in fig. 7 and fig. 8; fig. 8 is a schematic diagram of a first packet according to an embodiment of the present application. In fig. 7, the IPv6 header of the third packet includes an IPv6 base header, an SRH extension header, an APN extension header, and a network slice extension header, where an optional TLV in which the APN extension header is located in the SRH extension header is taken as an example. Assuming that the SID list of the SRH extension header includes 6 SIDs, the length of the IPv6 header before compression is 176 bytes.

The compressed message (first message) obtained by the compression of the first network device is shown as 8. It will be appreciated that the format of the compressed header in fig. 8 is merely illustrative, and the compressed header specifically includes which fields, and the positions, lengths, etc. of the fields may be adjusted according to actual requirements, which is not limited in this application. The compressed header of the compressed packet includes, for example, a compressed identifier field, a version identifier field of the compressed identifier, a stream type field (8 bits) and a stream label field (20 bits) in the IPv6 base header, and a next header field (8 bits) in the SRH extension header. Taking the length of the compressed identification field as 16 bits, the length of the version identification field as 4 bits as an example, the length of the compressed header is 7 bytes. Compared with the IPv6 message head before compression, the compressed message head shortens 169 bytes, the compression rate of the message head under the scene reaches over 96 percent, and the length of the message head can be greatly reduced.

Optionally, the compressed header may also include a reserved field. In practice, the compressed header may also need to carry some other information, and may be carried in the reserved field. The length of the reserved field is, for example, 1 byte. The length of the compressed message header comprising the reserved field is 8 bytes, and compared with the IPv6 message header before compression, the compressed message header is shortened by 168 bytes, and the compression rate of the message header under the scene reaches more than 95 percent.

Taking the load length of the third message as 200 bytes, the lengths of the data link layer and the physical layer of the third message as 34 bytes as an example, and the total length of the third message as 410 bytes. The load in the compressed message is unchanged, and the load length is the same as that of the third message. The compression ratio of the compressed message is 168 bytes divided by 410 bytes relative to the uncompressed third message, resulting in a compression ratio of greater than 40%. That is, in this scenario, the network bandwidth utilization can be improved by about 40%.

Therefore, by the message processing method provided by the embodiment, the length of the message header of the message can be obviously reduced, so that the network bandwidth occupied by the transmission of redundant data in the message header of the data stream in the network is reduced, the network can transmit more effective data, and the utilization rate of the network bandwidth is improved.

S602: the first network device sends a first message to the second network device.

And the first network equipment compresses the third message to obtain a first message and then sends the first message to the second network equipment. Therefore, the link between the first network device and the second network device transmits the first message with the shorter message header, and the third message is not required to be transmitted, so that the bandwidth utilization rate of the link between the first network device and the second network device can be improved.

After the second network device receives the first message, in order to ensure that the load in the first message can be transmitted to the destination device by the network, the second network device can restore the header of the first message into an uncompressed header and replace the uncompressed header. The compressed message header is restored to a message header before compression, and the second network device needs to be able to accurately identify each compressed message and obtain the compressed part of data in the compressed message. Therefore, the present application also provides a second embodiment of the message processing method.

As shown in fig. 9, fig. 9 is a flow chart of another embodiment of a message processing method according to the embodiment of the present application. The execution body of the embodiment includes the first network device and the second network device in the communication system. The embodiment comprises the following steps:

s901: the first network device obtains a second message according to the fourth message, wherein the second message comprises the compression identifier and at least part of the same content in different messages of the data stream.

The fourth message is a message before compression in the data stream, and the fourth message is a message header in the data stream without compression. The fourth message may be a message received from another network device. Or when the first network device is a server, the fourth message may also be a message generated by the first network device itself.

The fourth message may be the first message in a data stream. After the first network device receives the fourth message, the first network device obtains the characteristic information of the data stream according to the fourth message, and matches whether the same characteristic information exists in the compressed stream table. If the characteristic information does not exist in the compressed flow table, the fourth message can be described as the first message in a new data flow.

Optionally, the fourth packet may be a 1+i×m packet in one data stream, i is 1, 2, 3, …, M, and M is an integer greater than 1. That is, the fourth message may also be a message separated from the last fourth message by M messages in the data stream.

Optionally, the fourth packet may also be a packet separated from the first packet in the data stream by a period of j×q. j is 1, 2, 3, …, n, Q is an integer greater than 1, and the unit of Q may be milliseconds or seconds, etc.

The first network device adds the compression identifier corresponding to the data stream to which the fourth message belongs to the fourth message, so as to obtain a second message. The content in the second field, i.e. the same at least content in different messages of the data stream, is reserved in the header of the second message. The second message is used for transmitting the mapping relation of the compression identifier and at least the same content in different messages of the data stream to the second network equipment.

In one possible implementation, the first network device may replace the content in a field in the header of the fourth packet with the second packet obtained by compressing the identifier. The compressed identity replacement content is a content that can be recovered according to the characteristics of the message itself. For example, the content replaced by the compressed identifier is content of the indication length class such as the load length or the message length, and the load length or the message length can be recalculated according to the length of the message, so that even if the content is replaced by the compressed identifier, the content is not wrong or completely invalid. When the fourth message is an IPv4 message, it may be that the content in a total length (total length) field in the IPv4 message header is replaced with a compression identifier. When the fourth message is an IPv6 message, it may be that the content in the payload length field in the IPv6 message header is replaced with a compression identifier. Other types of messages are the same and are not described in detail herein. In this case, the length of the compression flag is the length of the field of the replaced content. For example, the length of the total length field in the IPv4 header and the length of the payload length field in the IPv6 header are both 16 bits, and then the length of the compression flag is also 16 bits. Therefore, the message length of the second message is the same as that of the fourth message, and the transmission of the second message in the network does not occupy extra bandwidth. As shown in fig. 10, fig. 10 is a schematic structural diagram of a second packet according to an embodiment of the present application. In fig. 10, SRv message is taken as an example.

In another possible implementation, for example, when the fourth packet is an IPv6 packet, the compression identifier may also be located in an IPv6 extension header in the IPv6 packet. For example, the first network device generates an IPv6 extension header including the compression identifier, and adds the IPv6 extension header including the compression identifier to the header of the fourth packet, to obtain the second packet. In this case, the length of the compression flag may be set according to actual requirements, and is not limited herein. And adding the compression identifier into the fourth message through the IPv6 extension head, wherein the obtained second message is still a normal IPv6 message, so that the second network equipment is easy to identify the second message.

Optionally, when the compressed identifier in the second packet is a reusable compressed identifier, the second packet further includes a version identifier of the compressed identifier added by the first network device. The second network equipment can distinguish different data streams using the same compression identifier according to the compression identifier and the version identifier in the second message.

The version identifier may be carried in the second message by replacing the content in a field in the header of the fourth message. Similarly, the content replaced by the compressed identification is content that can be restored. For example, the alternate content is the content in the version number field of the IPv4 header. Or in the version number field in the IPv6 header, as shown in fig. 10.

When the fourth message is an IPv6 message, the version identifier may also be located in an IPv6 extension header of the IPv6 message. The processing manner of the compression identifier in the IPv6 extension header is the same, and will not be described herein.

In this embodiment, in order to ensure that the data stored in the decompression table is accurate, other contents of the fourth message are not modified except for adding the compression identifier and the version identifier to the fourth message. Therefore, the second message is obtained by adding the compression identifier and the version identifier in the fourth message, and the content of the second field in the fourth message is reserved in the second message, so that after the second message is received by the second network device, the compression identifier and the content in the second field can be stored according to the second message and used for decompressing the compression message in the same data stream.

When there are multiple second messages in the data stream, the second messages except the first second message in the data stream are used for reducing the risk that the packet loss occurs in the previous second message, or the corresponding record (the mapping relationship between the compression identifier and the content in the second field) in the decompression table ages, so that the second network device does not store the mapping relationship between the compression identifier and the content in the second field, and further the compressed message in the same data stream cannot be recovered.

In order to enable the second network device to distinguish the first message from the second message so as to execute corresponding operations, the message header of the first message and the message header of the second message also include a third field. The values in the third field in the header of the first message and the second message are different, so that the second network device can determine whether the received message is the second message or the first message according to the value in the third field. The value of the third field in the second message is the first target value, and the value of the third field in the second message is the second target value. In one possible implementation, the third field may be located in the data link layer header of the first and second messages, since the data link layer header (the outer data link layer header if the message is a dual layer header) is not compressed. The third field of the data link layer header is, for example, a type (type) field in the ethernet header.

In another possible implementation, if the first packet and the second packet are IPv6 packets, the third field may also be located in the IPv6 extension header.

S902: the first network device sends a second message to the second network device.

S903: the second network device updates the first mapping relation of the compressed identifier and at least part of the same content in different messages of the data stream according to the second message.

When the second network device receives the message, the second network device obtains the value in the third field in the message header of the message, and when the value in the third field is the first target value, the second network device can determine that the message is the second message, and needs to store the first mapping relation between the compression identifier and at least part of the same content in different messages of the data stream.

And the second network equipment receives the second message and acquires the compression identifier in the second message and the content in the second field. If the first mapping relation corresponding to the compression identifier is not stored in the decompression table, that is, the received second message is the first second message in the data stream, the compression identifier and the content in the second field are stored in the decompression table so as to store the first mapping relation between the compression identifier and the content in the second field. Therefore, the second network device can execute the decompression operation on the compressed message according to the first mapping relation corresponding to the compression identifier stored in the decompression table. If the first mapping relation corresponding to the compression identifier is stored in the decompression table, that is, the received second message is not the first second message in the data stream, the time stamp of the first mapping relation corresponding to the compression identifier in the decompression table is updated, so that the first mapping relation corresponding to the compression identifier in the decompression table is prevented from being deleted due to the fact that the first mapping relation corresponding to the compression identifier is aged before the data stream.

In a possible scenario, if the compressed identifier is a reused identifier, because the second network device does not sense that the first network device recovers and reuses the compressed identifier, it may happen that a certain compressed identifier is recovered and reused by the first network device due to ageing of the compressed flow table, the compressed identifier is used to indicate a new data flow, and the first mapping relationship corresponding to the compressed identifier in the decompression table of the second network device is not yet aged, that is, the mapping relationship between the compressed identifier and the content of the second field in the packet of the old data flow is also stored, so when the new data flow arrives at the second network device, the second network device may acquire the content of the second field corresponding to the old data flow according to the compressed identifier, so as to decompress the compressed packet in the new data flow, which may result in that the packet cannot be forwarded to the correct destination.

Therefore, when the compression identifier is reused and the second message further includes the version identifier of the compression identifier, the second network device obtains the compression identifier, the version identifier and the content in the second field in the second message, and stores the compression identifier, the version identifier and the content in the second field in the decompression table, that is, the first mapping relationship includes the mapping relationship of the compression identifier, the version identifier and the content in the second field. The content in the second field stored in the decompression table can uniquely correspond to one data stream, so that the compressed message can be correctly decompressed subsequently.

If the second message is not the first second message of the data stream, the second network device does not need to store the first mapping relation corresponding to the compression identifier again when the second network device obtains the compression identifier and inquires that the first mapping relation corresponding to the compression identifier is stored in the decompression table according to the compression identifier. If the second message further includes a version identifier, the second network device acquires the compression identifier and the version identifier in the second message, and queries that the decompression table already stores the first mapping relationship corresponding to the compression identifier and the version identifier, the second network device does not need to store the first mapping relationship between the compression identifier and the version identifier and the content in the second field again, and the second network device updates the timestamp of the first mapping relationship corresponding to the compression identifier and the version identifier in the decompression table.

Alternatively, in order to reduce the storage space of the second network device occupied by the decompression table, the second network device may not store the contents of all the second fields in the decompression table, for example, the contents of the fields that are available without storing. For example, the content in the version number field may not be stored in the decompression table. The content in the version number field may be obtained, for example, from a type (type) field of a link layer header (an outer link layer header in the case of a two layer header) of the message. Or when the second network device is only used for forwarding the IPv4 message, the content of the version number field may be determined to be 4; when the system is only used for forwarding the IPv6 message, the content in the version number field can be determined to be 6.

After the second network device receives the second message, the second message can be recovered to be a fourth message. Namely stripping the compression mark and the version mark in the second message. If the compressed identifier and the version identifier are carried in the second message by replacing the content in the fields of the fourth message, deleting the compressed identifier and the version identifier from the fields, and adding the correct content corresponding to the fields, thereby recovering the second message into the fourth message. For example, the second message is an IPv6 message, the compression identifier and the version identifier are respectively carried in a payload length field and a version number field in an IPv6 message header, and the second network device calculates the byte numbers of an IPv6 extension header and an upper layer protocol data unit after the IPv6 base header to obtain a payload length value, adds the payload length value to the payload field, adds the version number 6 (indicating the IPv6 message) to the version number field, and restores the second message to a fourth message. If the compression identifier and the version identifier are located in the IPv6 extension header, the located IPv6 extension header can be deleted.

S904: the first network device obtains a first message according to the third message, and a message header of the first message comprises a compression identifier and at least part of different contents in different messages of the data stream.

This step is similar to S601, and thus will not be described here.

In this embodiment, the third packet and the fourth packet are both packets before compression in the same data stream, and the third packet is a packet other than the fourth packet in the packets before compression in the data stream.

In order to enable the second network device to distinguish between the first message and the second message, the first network device may add a second target value in a third field in a header of the first message to identify the message as the first message.

When the third field is located in the IPv6 extension header, the content before the third field in the header of the first packet is uncompressed with respect to the third packet, and the content after the third field is the compressed content, so as to ensure that the second network device can accurately obtain the second target value from the third field.

S905: the first network device sends a first message to the second network device.

S906: the second network device decompresses the first message into a third message according to the first message and a first mapping relation corresponding to the compression identifier.

When the second network device receives the message, the value in the third field in the message header of the message is obtained, and when the value in the third field is the second target value, the second network device can determine that the message is the first message and is a compressed message, and decompression operation needs to be performed on the first message so as to restore the first message into the third message.

And after the second network equipment receives the first message, acquiring a compression identifier in the first message, and acquiring the content in the second field from a decompression table storing a first mapping relation between the compression identifier and the content in the second field according to the compression identifier. The second network device combines the content of the first field in the third message reserved in the first message and the content in the second field obtained from the decompression table, and restores the first message to the third message according to the format of the message header of the third message. Thus, the third message can be identified and forwarded by the subsequent network device.

When the compression identifier in the first message is the recycled compression identifier, and the first message also comprises the version identifier, the second network device acquires the compression identifier and the version identifier in the first message, and queries the decompression table according to the compression identifier and the version identifier to acquire the content of the second field having the first mapping relation with the compression identifier and the version identifier. Or the second network equipment acquires the compression identifier and the version identifier in the first message, queries the decompression table according to the compression identifier to acquire the corresponding version identifier and the content in the second field, judges whether the version identifier acquired from the first message is consistent with the version identifier acquired from the decompression table, if so, uses the content in the second field acquired from the decompression table to recover the first message, and if not, continues to query the decompression table according to the compression identifier until the version identifier acquired from the first message is consistent with the version identifier acquired from the decompression table. Therefore, the content in the second field for recovering the first message obtained from the decompression table is unique and accurate, and the risk caused by the fact that the third message cannot be recovered due to the fact that the compression identifier is reused can be avoided.

If the content in the third message is not in the header of the first message or in the decompression table, for example, the content in the version number field and the content in the payload length field, when the second network device restores the first message to the third message, the second network device adds the content into the corresponding field. For example, if the third message is an IPv6 message, a value of 6 is added to the version number field. The content in the payload length field is obtained and added by the second network device calculating the message length.

It can be understood that, in the embodiment, decompressing the first message into the third message or restoring the compressed header into the header before compression does not mean that the content in the header of the decompressed third message is completely consistent with the content in the header of the third message before compression. In some scenarios, the second network device needs to perform some operations on the header that are outside of the recovery header. The second network device also needs to modify the contents of the destination address field in the IPv6 base header and the contents of the remaining number of segments field in the SRH extension header, for example, when the third message is a SRv6 message. The contents of the destination address field and the remaining segment number field in the header of the recovered third message are different from those of the third message before compression.

In this embodiment, the first network device compresses the header of the third packet into a compressed header with a shorter length, so that the length of the first packet including the compressed header is shorter, and the proportion of the effective data in the first packet is higher. The first message is transmitted on the link between the first network device and the second network device, so that bandwidth resources can be saved, and the link can transmit more messages. And the proportion of the effective data in the first message is increased, so that the proportion of the effective data transmitted in the link is increased, and the utilization rate of the network bandwidth can be improved.

And the same data stream comprises a first message and at least one second message. The second message is used for transmitting the compressed identifier and the first mapping relation of the content in the second field, so that the subsequent second network equipment can decompress the compressed first message into a third message based on the first mapping relation.

Further, the second network device stores a first mapping relationship between at least part of content (content in the second field) not carried in the header of the first message and the compression identifier, and since the compression identifier indicates a data stream, the content in the second field of the header of a different message in the same data stream is the same, so that the second network device can obtain at least part of content not carried in the header of the first message according to the compression identifier in the compression message, so as to accurately restore different compression messages in the data stream into uncompressed messages. The forwarding of the message in the subsequent link is not affected while the network bandwidth utilization rate is improved.

In this embodiment, taking the second network device to decompress the first message as an example, the process of the second network device recovering the first message into the third message is described. Of course, when the second network device is the tunnel endpoint, or the destination device of the message, for example, the last or penultimate endpoint node in the SRv path, or the VTEP in the VXLAN network, the compressed tunnel header or header may not perform decompression. In this case, the second network device may not store the mapping relationship between the corresponding compression identifier and the content of the second field in the tunnel header.

Fig. 11 is a schematic structural diagram of a network device according to an embodiment of the present application, as shown in fig. 11. The network device in this embodiment is a first network device in the communication system shown in fig. 4 and in the message processing methods shown in fig. 6 and 9. In this embodiment, the network device 1100 includes a processing module 1101 and a transceiver module 1102.

The processing module 1101 is configured to obtain a first packet, where a header of the first packet includes a compression identifier, where the compression identifier indicates a data stream corresponding to the first packet, and the header further includes at least part of different contents in different packets of the data stream. The transceiver module 1102 is configured to send a first message to a second network device.

In a possible implementation, the processing module 1101 is configured to obtain a second packet, where the second packet belongs to a data stream, and a header of the second packet includes a compression identifier and at least part of the same content in different packets of the data stream. The transceiver module 1102 is configured to send a second packet to a second network device, so that the second network device stores a first mapping relationship according to the second packet, where the first mapping relationship includes a compression identifier and a mapping relationship between at least the same content in different packets of the data flow, and the mapping relationship is used for decompressing the first packet.

In a possible implementation manner, the transceiver module 1102 is configured to receive a third packet, where the third packet belongs to a data stream, and a header of the third packet includes a first field and a second field, where a content in the first field is at least part of a content that is different in different packets of the data stream, and a content in the second field is at least part of a content that is the same in different packets of the data stream. The processing module 1101 is configured to obtain a compressed identifier according to feature information of the third packet, where the feature information is used to identify a data stream. The processing module 1101 is configured to obtain a first packet according to the compression identifier and the third packet, where a length of a header of the first packet is smaller than a length of a header of the third packet.

Fig. 12 is a schematic structural diagram of another network device according to an embodiment of the present application, as shown in fig. 12. The network device in this embodiment is a second network device in the communication system shown in fig. 4 and in the message processing methods shown in fig. 6 and 9. In this embodiment, the network device 1200 includes a processing module 1201 and a transceiver module 1202.

The transceiver module 1202 is configured to receive a first packet from a first network device, where a header included in the first packet includes a compression identifier, the compression identifier indicates a data stream corresponding to the first packet, and the header included in the first packet further includes at least part of different contents in different packets of the data stream.

The processing module 1201 is configured to decompress the first packet into a third packet according to the first mapping relationship. The first mapping relationship includes compressing at least part of the mapping relationship identifying the same content as in different messages of the data stream, decompressing the first message into a third message, a header of the third message including different content in different messages of the data stream and the same content in different messages of the data stream.

In one possible implementation, the transceiver module 1202 is configured to receive a second packet from the first network device, where a header of the second packet includes a compression identifier and at least part of the same content in a different packet of the data stream. A processing module 1201 is configured to store the first mapping relationship according to the second message.

In one possible implementation, the header of the first packet and the header of the second packet further include version identifiers of the compression identifiers, and the first mapping relationship includes a mapping relationship between the compression identifiers, the version identifiers, and at least some of the same content in different packets of the data stream. A processing module 1201 is configured to obtain at least part of the content that is the same in different messages of the data stream according to the compression identifier, the version identifier and the first mapping relationship. A processing module 1201 is configured to decompress the first packet into a third packet according to the first packet and at least part of the same content in different packets of the data stream.

In one possible implementation manner, the third message is an IPv6 message, a header of the third message includes an IPv6 header, the IPv6 header includes an IPv6 basic header and N IPv6 extension headers, the same content in different messages of the data flow is located in the IPv6 basic header and/or the N IPv6 extension headers, and N is a natural number.

Fig. 13 is a schematic structural diagram of still another network device according to an embodiment of the present application, as shown in fig. 13. In this embodiment, network device 1300 includes a processor 1301 and a memory 1302. Processor 1301 is coupled to memory 1302, processor 1301 being configured to perform the operations of the first network device in any embodiment of the above-described message processing method or the operations of the second network device in any embodiment of the above-described message processing method based on instructions stored in memory 1302.

The present application also provides a computer readable storage medium comprising instructions which, when executed on a computer, cause the computer to perform a corresponding message processing method as in fig. 6 or 9.

The present application also provides a computer program product comprising instructions. The computer program product may be a software or program product containing instructions capable of running on a network device or stored in any available medium. When the computer program product is run on a network device, the network device is caused to perform the operations of the first network device in any embodiment of the above-described message processing method or the operations of the second network device in any embodiment of the above-described message processing method.

The application provides a chip, which comprises a processing circuit, wherein the processing circuit is used for calling and running a program from a memory, so that network equipment provided with the chip device executes the operation of first network equipment in any embodiment of the message processing method or the operation of second network equipment in any embodiment of the message processing method.

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

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, or may be in electrical or other forms.

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

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. With such understanding, all or part of the technical solutions of the present application may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM, random access memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Claims

1. A method for processing a message, the method comprising:

the method comprises the steps that first network equipment obtains a first message, wherein a message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header also comprises at least part of different contents in different messages of the data stream;

the first network device sends the first message to a second network device.

2. The method according to claim 1, wherein the method further comprises:

the first network device obtains a second message, wherein the second message belongs to the data stream, and a message header of the second message comprises the compression identifier and at least part of the same content in different messages of the data stream;

the first network device sends the second message to the second network device, so that the second network device stores a first mapping relation according to the second message, the first mapping relation comprises a mapping relation between the compression identifier and the same at least partial content in different messages of the data stream, and the first mapping relation is used for decompressing the first message.

3. The method of claim 2, wherein the header of the first message and the header of the second message further include version identifiers of the compressed identifiers, and wherein the first mapping relationship includes a mapping relationship among the compressed identifiers, the version identifiers, and the same at least partial content in different messages of the data stream.

4. A method according to any one of claims 1 to 3, wherein before the first network device obtains the first message, further comprising:

the first network device receives a third message, wherein the third message belongs to the data stream, a message header of the third message comprises a first field and a second field, the content in the first field is at least part of the content which is different in different messages of the data stream, and the content in the second field is at least part of the same content in different messages of the data stream;

the first network device obtains the compression identifier according to the characteristic information of the third message, wherein the characteristic information is used for identifying the data stream;

the first network device obtaining a first message includes:

the first network device obtains the first message according to the compression identifier and the third message, and the length of the message header of the first message is smaller than that of the third message.

5. The method of claim 4, wherein the characteristic information comprises at least one of a virtual private network VPN identification carried in the third message and content in the second field.

6. The method according to claim 4 or 5, wherein the third message is an internet protocol version six IPv6 message, a message header of the third message includes an IPv6 message header, the IPv6 message header includes an IPv6 basic header and N IPv6 extension headers, the second field includes a field in the IPv6 basic header and/or the N IPv6 extension headers, and N is a positive integer greater than or equal to 0.

7. The method of claim 6, wherein N is greater than or equal to 1, and wherein the N IPv6 extension headers include at least one of a segment routing header SRH extension header, an application aware network extension header, a network slice extension header, and a bit index explicit copy extension header.

8. The method according to any of claims 1 to 7, wherein the second network device is a next hop device of the first network device.

9. The method of any of claims 1-7, wherein the first network device and the second network device are network devices in an IPv6 segment route SRv path of the data flow, the second network device being a next SRv segment endpoint node of the first network device in the SRv6 path.

10. A method for processing a message, the method comprising:

the method comprises the steps that second network equipment receives a first message from first network equipment, wherein a message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header of the first message also comprises at least part of different contents in different messages of the data stream;

the second network device decompresses the first message into a third message according to a first mapping relation, wherein the first mapping relation comprises a mapping relation of the compression identifier and at least part of the same content in different messages of the data stream, and a message header of the third message comprises different content in different messages of the data stream and the same content in different messages of the data stream.

11. The method according to claim 10, wherein the method further comprises:

the second network device receives a second message from the first network device, wherein the message header of the second message comprises the compression identifier and at least part of the same content in different messages of the data flow;

And the second network equipment stores the first mapping relation according to the second message.

12. The method of claim 11, wherein the header of the first message and the header of the second message further include version identifiers of the compressed identifiers, the first mapping relationship includes a mapping relationship between the compressed identifiers, the version identifiers, and the same at least partial content in different messages of the data stream, and the second network device decompressing the first message into a third message according to the first mapping relationship includes:

the second network device obtains the same at least partial content in different messages of the data flow according to the compression identifier, the version identifier and the first mapping relation;

and the second network equipment decompresses the first message into the third message according to the first message and the same at least partial content in different messages of the data stream.

13. The method according to any one of claims 10 to 12, wherein the third message is an IPv6 message, a header of the third message includes an IPv6 header, the IPv6 header includes an IPv6 basic header and N IPv6 extension headers, the same content in different messages of the data flow is located in the IPv6 basic header and/or the N IPv6 extension headers, and N is a positive integer greater than or equal to 0.

14. The method of claim 13, wherein N is greater than or equal to 1, and wherein the N IPv6 extension headers include at least one of an SRH extension header, an application aware network extension header, a network slice extension header, and a bit index explicit copy extension header.

15. The method according to any of claims 10 to 14, wherein the second network device is a next hop device of the first network device.

16. The method of any of claims 10 to 14, wherein the first network device and the second network device are network devices in a SRv path of the data flow, the second network device being a next SRv segment endpoint node of the first network device in the SRv path.

17. A network device, the network device comprising:

the processing module is used for obtaining a first message, wherein a message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header also comprises at least part of different contents in different messages of the data stream;

and the receiving and transmitting module is used for transmitting the first message to the second network equipment.

18. The network device of claim 17, wherein the network device,

the processing module is configured to obtain a second packet, where the second packet belongs to the data stream, and a header of the second packet includes the compression identifier and at least part of the same content in different packets of the data stream;

the transceiver module is configured to send the second packet to the second network device, so that the second network device stores a first mapping relationship according to the second packet, where the first mapping relationship includes a mapping relationship between the compression identifier and the same at least part of content in different packets of the data flow, and the first mapping relationship is used to decompress the first packet.

19. The network device of claim 18, wherein the header of the first message and the header of the second message further include version identifiers of the compressed identifiers, and wherein the first mapping relationship includes a mapping relationship between the compressed identifiers, the version identifiers, and the same at least partial content in different messages of the data stream.

20. The network device according to claim 17 to 19, wherein,

The transceiver module is configured to receive a third packet, where the third packet belongs to the data stream, and a packet header of the third packet includes a first field and a second field, where contents in the first field are at least part of contents that are different in different packets of the data stream, and contents in the second field are at least part of contents that are the same in different packets of the data stream;

the processing module is configured to obtain the compression identifier according to feature information of the third packet, where the feature information is used to identify the data stream;

the processing module is configured to obtain the first message according to the compression identifier and the third message, where a length of a message header of the first message is smaller than a length of a message header of the third message.

21. The network device of claim 20, wherein the characteristic information includes at least one of a virtual private network VPN identification carried in the third message and content in the second field.

22. The network device according to claim 20 or 21, wherein the third message is an IPv6 message, a header of the third message includes an IPv6 header, the IPv6 header includes an IPv6 basic header and N IPv6 extension headers, the second field includes a field in the IPv6 basic header and/or the N IPv6 extension headers, and N is a positive integer greater than or equal to 0.

23. The network device of claim 22, wherein N is greater than or equal to 1, and wherein the N IPv6 extension headers include at least one of an SRH extension header, an application aware network extension header, a network slice extension header, and a bit index explicit copy extension header.

24. A network device, the network device comprising:

the receiving and transmitting module is used for receiving a first message from first network equipment, wherein the message header of the first message comprises a compression identifier, the compression identifier indicates a data stream corresponding to the first message, and the message header of the first message also comprises at least part of different contents in different messages of the data stream;

the processing module is configured to decompress the first packet into a third packet according to a first mapping relationship, where the first mapping relationship includes a mapping relationship of the compression identifier and at least part of the content that is the same as that in different packets of the data stream, and a header of the third packet includes different content in different packets of the data stream and the same content in different packets of the data stream.

25. The network device of claim 24, wherein the network device,

The receiving and transmitting module is configured to receive a second packet from the first network device, where a header of the second packet includes the compression identifier and the same at least part of content in different packets of the data flow;

and the processing module is used for storing the first mapping relation according to the second message.

26. The network device of claim 25, wherein the header of the first message and the header of the second message further include version identifiers of the compressed identifiers, wherein the first mapping relationship includes a mapping relationship between the compressed identifiers, the version identifiers, and the same at least partial content in different ones of the data streams,

the processing module is configured to obtain the same at least part of content in different packets of the data stream according to the compression identifier, the version identifier and the first mapping relationship;

the processing module is configured to decompress the first packet into the third packet according to the first packet and the same at least partial content in different packets of the data stream.

27. The network device according to any one of claims 24 to 26, wherein the third message is an IPv6 message, a header of the third message includes an IPv6 header, the IPv6 header includes an IPv6 basic header and N IPv6 extension headers, and the same content in different messages of the data flow is located in the IPv6 basic header and/or the N IPv6 extension headers, and N is a positive integer greater than or equal to 0.

28. The network device of claim 27, wherein the N is greater than or equal to 1, and wherein the N IPv6 extension headers include at least one of an SRH extension header, an application aware network extension header, a network slice extension header, and a bit index explicit copy extension header.

29. A network device comprising a processor and a memory, the processor being coupled to the memory, the processor being configured to perform the message processing method of any of claims 1-9, or the message processing method of any of claims 10-16, based on instructions stored in the memory.

30. A communication system, the system comprising a first network device and a second network device; wherein the first network device is configured to implement the message processing method of any one of claims 1 to 9, and the second network device is configured to implement the message processing method of any one of claims 10 to 16.

31. A computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the message processing method of any of claims 1-9 or the message processing method of any of claims 10-16.

32. A computer program product comprising instructions which, when executed by a network device, cause the network device to perform the message processing method of any of claims 1-9 or the message processing method of any of claims 10-16.