Method for encapsulating data message, electronic device, and readable storage medium

Abstract

The present application relates to a method for encapsulating a data message, an electronic device, and a readable storage medium. On one hand, the solution provided by the present application is applied to a controller, and comprises: determining whether a head-end node of a data transmission path supports a target function, wherein the target function represents the capability of processing target compression information; when the head-end node supports the target function, compressing a segment list corresponding to the data transmission path to obtain the target compression information; and notifying the head-end node of a segment routing policy carrying the target compression information, wherein the segment routing policy is used for instructing the head-end node to encapsulate received target traffic on the basis of the target compression information. On the other hand, the solution provided by the present application is also applied to the head-end node of the data transmission path, and comprises: acquiring a segment routing policy which is advertised by a controller and carries target compression information; and encapsulating received target traffic on the basis of the target compression information.

Description

Method for encapsulating data message, electronic device and readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to a Chinese patent application filed with the Patent Office of China on July 28, 2023, with application number 202310955059.5 and invention name “A method for encapsulating data messages, an electronic device and a readable storage medium”. The entire contents of the Chinese patent application are incorporated herein by reference. Technical Field

[0003] The present application relates to the field of communications, and in particular to a method for encapsulating data messages, an electronic device, and a readable storage medium. Background Art

[0004] SRv6 (Segment Routing IPv6) is the implementation of segment routing technology on the data plane of Internet Protocol Version 6 (IPv6). During forwarding, the Segment Routing Header (SRH) encapsulates traffic and indicates the nodes, links, or services that the traffic forwarding path must pass through. SRH is an IPv6 routing extension header consisting of a set of SRv6 SIDs (Segment Identifiers). The SRv6 SID is 128 bits long, so in practical applications, it often suffers from high message overhead and low network link bandwidth utilization. To address this, the SRv6 SID can be compressed in practical applications to reduce the length of the SRH routing extension header, thereby optimizing message overhead.

[0005] However, there are many compression methods used in practice, and requiring network devices to support multiple compression methods would increase the burden on network devices. If the headend node of the traffic does not support a certain compression method, the entire SRv6 domain cannot use this compression method.

[0006] The technical problem to be solved by this application is that the SRv6 domain cannot apply a certain compression method to compress the original SRv6 segment list because the head-end node does not support the compression method.

[0007] Summary of the Invention

[0008] In a first aspect, a method for encapsulating data packets is provided, which is applied to a controller, comprising: determining whether a head-end node of a data transmission path supports a target function, wherein the target function represents the ability to process target compression information; when the head-end node supports the target function, compressing a segment list corresponding to the data transmission path to obtain the target compression information; and notifying the head-end node of a segment routing policy carrying the target compression information, wherein the segment routing policy is used to instruct the head-end node to encapsulate the received target traffic according to the target compression information.

[0009] In a second aspect, a method for encapsulating data packets is provided, which is applied to the head-end node of a data transmission path, including: obtaining a segment routing strategy announced by a controller, wherein the segment routing strategy carries target compression information, and the target compression information is obtained by the controller compressing the segment list corresponding to the data transmission path when the head-end node supports the target function, and the target function represents the ability to process the target compression information; encapsulating the received target traffic according to the target compression information.

[0010] In a third aspect, an electronic device is provided, which includes a processor, a memory, and a computer program stored in the memory and runnable on the processor, and when the computer program is executed by the processor, the steps of the method of the first aspect and / or the second aspect are implemented.

[0011] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method of the first aspect and / or the second aspect are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0013] FIG1 is a flow chart of a method for encapsulating data packets applied to a controller according to an embodiment of the present application;

[0014] FIG2 is a schematic diagram of a newly added P flag in a BGP-LS extended SRv6 Capabilities sub-TLV according to an embodiment of the present application;

[0015] FIG3 is a schematic diagram of the main structure of the PCEP Compressed SRH sub-TLV of PCEP and the BGP Compressed SRH sub-sub-TLV of BGP SR Policy in one embodiment of the present application;

[0016] FIG4 is a flow chart of a method for encapsulating data packets applied to a head-end node according to an embodiment of the present application;

[0017] FIG5 is a schematic diagram of a segmented routing network topology structure according to an embodiment of the present application;

[0018] FIG6 is a schematic diagram of the structure of compression information generated by the controller for the Segment list of SR Policy 1 according to the Next-C-SID compression method in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV according to an embodiment of the present application;

[0019] FIG7 is a schematic diagram of the structure of compression information generated by the controller for the Segment list of SR Policy 2 according to the Replace-C-SID compression method in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV according to an embodiment of the present application;

[0020] FIG8 is a schematic structural diagram of a device for encapsulating data packets applied to a controller according to an embodiment of the present application;

[0021] FIG9 is a schematic structural diagram of an apparatus for encapsulating data packets applied to a head-end node according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. The figure numbers in this application are only used to distinguish the various steps in the scheme and are not used to limit the execution order of the various steps. The specific execution order is subject to the description in the specification.

[0023] The present invention relates to Segment Routing (SR) technology, and in particular to a method for transmitting data packets using an IPv6 data plane (called SRv6) and employing compression technology. This solution can be applied to application scenarios where the headend node cannot support the corresponding compression method, and can also be applied to application scenarios where the headend node is not convenient to perform compression due to reasons such as overload.

[0024] In order to solve the problems existing in the prior art, an embodiment of the present application provides a method for encapsulating data packets, which is applied to a controller, as shown in FIG1 , and includes:

[0025] S11: Determine whether the head-end node of the data transmission path supports a target function, wherein the target function represents a capability of processing target compressed information.

[0026] The headend node can actively or passively report to the controller whether it supports the target function. Specifically, the report can be realized in the form of a message. Supporting the target function means that the headend node itself has the ability to analyze and process the target compression information.

[0027] The head-end node supporting the target function may specifically refer to the head-end node being able to use the target compression information compressed by the controller to encapsulate the received target traffic.

[0028] For example, the target function supported by the head-end node may specifically refer to the SRH compression proxy capability, which may specifically refer to the ability of the head-end node to process the target compression information, that is, to identify the Compressed SRH structure of the protocol message and to restore and generate the SRH header to be encapsulated for the traffic from the structure.

[0029] In actual applications, technicians can pre-configure a switch on the network device to control this function. The switch can enable or disable the function based on commands, thereby achieving flexible control of data encapsulation.

[0030] S12: When the head-end node supports the target function, compress the segment list corresponding to the data transmission path to obtain the target compression information.

[0031] In practice, the controller supports multiple compression methods. You can select the target proxy compression method based on actual needs. For example, the target proxy compression method can be Next-C-SID compression or Replace-C-SID compression. C-SID refers to Compressed Segment Identifiers, or compressed identifiers.

[0032] When the head-end node supports the target function, the controller can determine the actual compression method based on a variety of factors such as the compression method required to be performed on the data and the compression methods announced by other nodes.

[0033] In this step, the controller performs proxy compression on the segment list corresponding to the data transmission path, that is, the controller performs the above compression instead of the head-end node.

[0034] S13: Notify the head-end node of a segment routing policy carrying the target compression information, where the segment routing policy is used to instruct the head-end node to encapsulate received target traffic according to the target compression information.

[0035] The controller sends target compression information to the headend node by sending a Segment Routing Policy (SR Policy) message, instructing the headend node to encapsulate the received target traffic using the target compression information. The headend node can directly use the target compression information when encapsulating the received target traffic, without having to perform segment list compression itself. Therefore, the headend node does not need to support every compression technology.

[0036] For example, the controller can deliver the SR Policy to the headend node via the Path Computation Element Communication Protocol (PCEP) or Border Gateway Protocol (BGP). Alternatively, it can deliver the SR Policy via other protocol messages based on actual needs.

[0037] In one embodiment, if the headend node supports the target function, the controller may include the PCEP Compressed SRH sub-TLV in the Explicit Route Object (ERO) when transmitting a PCEP message. Alternatively, the controller may include the BGP Compressed SRH sub-sub-TLV in the Segment-List sub-TLV when transmitting a BGP SR Policy Update message, thereby notifying the headend node of the segment routing policy with the target compression information.

[0038] In actual applications, in one embodiment, if the headend node does not support the target function, the controller can notify the PCEP PCRep (PCEP Path Computation Reply) message, PCInitiate (PCEP LSPInitiate Request) message, PCUpd (PCEP LSP Update Request) message, PCRpt (PCEP LSP State Report) message, or BGP SR Policy Update message in the manner specified by the existing protocol. These PCEP messages carry EROs, and the BGP Update message carries the Segment-List sub-TLV.

[0039] If the node supports the target function, the controller can carry the newly added lower-level PCEP Compressed SRH sub-TLV structure in the ERO object when notifying PCEP messages. When the controller notifies BGP SR Policy Update messages, the controller can carry the newly added lower-level BGP Compressed SRH sub-sub-TLV structure in the Segment-List sub-TLV.

[0040] After receiving a PCEP message or a BGP SR Policy Update message, the headend node can directly obtain the compressed information from the PCEP Compressed SRH sub-TLV carried in the ERO object of the PCEP message or the BGP Compressed SRH sub-sub-TLV carried in the Segment-List sub-TLV of the BGP SR Policy Update message. Alternatively, the headend node can perform compression itself from the ERO object or Segment-List sub-TLV using methods specified in existing protocols.

[0041] The solution provided by the embodiments of the present application first determines whether the headend node of the data transmission path supports the target function, where the target function represents the ability to process target compression information. Then, if the headend node supports the target function, the segment list corresponding to the data transmission path is compressed to obtain the target compression information. Subsequently, the segment routing policy carrying the target compression information is notified to the headend node. The segment routing policy is used to instruct the headend node to encapsulate the received target traffic according to the target compression information. Through this solution, if the headend node supports the target function, the controller performs proxy compression on the segment list, eliminating the need for the headend node to perform compression itself. The controller then sends the segment routing policy message carrying the target compression information to the headend node, allowing the headend node to encapsulate the received target traffic according to the target compression information, eliminating the need for the headend node to perform compression. As a result, even if the headend node in the transmission link does not support a certain compression method or lacks compression capability, it can still use the compressed segment routing header to encapsulate and forward traffic, which helps reduce message overhead, improve network link bandwidth utilization, and reduce the burden on network equipment.

[0042] Based on the solution provided in the above embodiment, in one embodiment, in the above step S11, determining whether the headend node of the data transmission path supports the target function includes:

[0043] S21: Acquire the protocol message reported by the head-end node.

[0044] S22: When the flag bit of the identification field carried in the protocol message is a preset value, determine that the head-end node supports the target function.

[0045] In an embodiment of the present application, whether the headend node supports the target function is indicated by the value of a pre-set flag bit of the identification field carried in the protocol message. The flag bit can be represented as a P (Proxy) flag bit, for example.

[0046] In practical applications, the specific position of the flag bit can be pre-set by a technician, or determined in advance by negotiation between the controller and the head-end node. Correspondingly, the meaning expressed by the value of the flag bit can also be pre-determined.

[0047] For example, assuming the preset value is 1, when the P flag is 1, it indicates that the head-end node supports the target function, and the controller can pre-execute proxy compression instead of the head-end node. If the P flag is 0, it indicates that the head-end node does not support the target function, and the controller can notify in the manner specified by the existing protocol and not perform proxy compression.

[0048] In the embodiment of the present application, the value in the flag bit expresses whether the head-end node supports the target function, so that the controller decides whether to perform proxy compression on the segment list on behalf of the head-end node.

[0049] In practice, the headend node can flexibly set the value of this flag to flexibly change proxy compression. For example, if the headend node itself does not have the required compression capabilities, the P flag bit can be set to 1, causing the controller to perform proxy compression. Alternatively, if the headend node is under high load and cannot perform compression itself, the P flag bit can be set to 1, causing the controller to perform proxy compression.

[0050] Based on the solution provided by the above embodiment, in one embodiment, the protocol message reported by the headend node includes a Border Gateway Protocol Link State (BGP-LS) update message, and the identification field includes an SRv6 Capabilities sub-TLV.

[0051] In this example, the BGP-LS protocol specifically refers to a protocol message used by network nodes to notify the controller of their capabilities and status. This solution extends the SRv6 Capabilities sub-TLV of the BGP-LS protocol and adds a P flag to indicate whether the network node supports the target function.

[0052] For example, Figure 2 illustrates the newly added P flag in the BGP-LS extension of the SRv6 Capabilities sub-TLV in this example. The P flag in this example can be set to the fourth bit of the Flags field. Setting the P flag to 1 indicates that the network node supports SRH compression proxying, meaning it can process the newly added PCEP Compressed SRH sub-TLV in PCEP messages and the newly added BGP Compressed SRH sub-sub-TLV in BGP SR Policy Update messages.

[0053] Based on the solution provided by the above embodiment, in one embodiment, the data transmission path corresponds to at least one segment list; wherein, in the segment routing strategy, the target compression information is carried after the corresponding segment list.

[0054] In this example, the controller can first calculate one or more candidate paths for the headend node and generate one or more segment lists based on the candidate paths. The segment lists are then compressed to obtain corresponding target compression information, which is then carried after the corresponding segment lists. This ensures that the segment routing policy maintains the correspondence between the segment lists and the target compression information. In practice, this target compression information can be carried in a PCEP ERO object or a BGP Segment-List sub-TLV for delivery to the headend node.

[0055] In one embodiment, when the head-end node supports the target function, the controller may carry the target compression information obtained after compressing the segment list in the newly added lower-level PCEP Compressed SRH sub-TLV of the PCEP message ERO or the newly added lower-level BGP Compressed SRH sub-sub-TLV of the Update message Segment-List sub-TLV of the BGP SR Policy when notifying the candidate path to the head-end node.

[0056] Subsequently, the headend node receives the segment routing policy carrying the target compression information announced by the controller using PCEP or BGP SR Policy and performs parsing. If the parsed data contains a PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV carrying the target compression information after the segment list is compressed, the headend node can encapsulate the received target traffic according to the target compression information carried in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV.

[0057] In one embodiment, if the head-end node has its own compression function, it can also perform compression according to the Segment list. However, if the head-end node finds that it cannot parse the compression method indicated by the Endpoint Behavior of the Segment in the Segment list, it adopts the above method to generate the SRH routing extension header of the IPv6 header according to the target compression information after the Segment list is compressed carried by the PCEP Compressed SRH sub-TLV or the BGP Compressed SRH sub-sub-TLV.

[0058] In practice, if the headend node does not support the target function, the controller does not carry the PCEP Compressed SRH sub-TLV and BGP Compressed SRH sub-sub-TLV when advertising candidate path information using PCEP or BGP SR Policy. The headend node performs compression and subsequent processing according to existing rules.

[0059] Based on the solution provided in the above embodiment, the target compression information includes a Type field, a Count field and a Compressed Segment List field; wherein the Type field is used to indicate that the type of the current structure is the target compression information; the Compressed Segment List field is used to indicate the content of the target compression information; the Count field is determined by the length of the Compressed Segment List field divided by 16.

[0060] In this instance, the target compression information may specifically include information obtained by the controller compressing the original Segment list according to a certain compression method. This information can be used by the head-end node to fill in the data part of the SRH routing extension header of the IPv6 header.

[0061] Specifically, referring to FIG. 3 , the Type field may be predefined by IANA (Internet Assigned Numbers Authority) for PCEP Compressed SRH sub-TLV and BGP Compressed SRH sub-sub-TLV, respectively.

[0062] The Count field indicates the length of the Compressed Segment List portion of the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV in groups of 16 bytes.

[0063] The Compressed Segment List is the target compression information obtained by the controller compression. This information will be filled into the data part of the SRH routing extension header of the IPv6 header by the headend node.

[0064] In addition, the segment routing policy message may also carry other fields. For example, in Figure 3, the Length field may indicate the length of the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV in groups of 8 bytes after removing the 8 bytes of the header.

[0065] In addition, the flag field and the reserved field can also be carried, which can be pre-defined according to actual needs. In this example, 0 can be filled in when sending and treated as 0 when receiving.

[0066] Since the existing protocols' SRv6-ERO and Segment sub-TLV both have headers to indicate certain attributes of the SID, if these sub-TLVs are used directly to carry the C-SID Container, a lot of extra useless header information will be carried, and these useless header information will also separate the C-SID Containers that should be placed continuously. The structure used in the solution provided in this embodiment does not have additional headers to separate valid information, so that the compressed information is concentrated together, consistent with the data field of the SRH routing extension header encapsulated during traffic forwarding, making it convenient for the head-end node to directly use the encapsulated traffic. Moreover, SRv6-ERO and Segment sub-TLV maintain the existing usage method to carry the complete SID. The head-end node receives not only the compressed information of the Segment list, but also the original Segment list information, which will be more intuitive and clearer when viewing the path information on the head-end node.

[0067] Based on the solution provided in the above embodiment, in one embodiment, in step S13, notifying the segment routing policy carrying the target compression information to the headend node includes:

[0068] S31: The segment routing policy is carried and announced to the headend node via the Border Gateway Protocol (BGP), wherein the target compression information is used as the lower-level encoding format information of the segment list sub-encoding format.

[0069] In this example, the BGP SR Policy is extended so that the controller can carry the target compression information in the BGP Compressed SRH sub-sub-TLV when advertising the segment routing policy to the headend node.

[0070] In this example, BGP SR Policy is extended to add the BGP Compressed SRH sub-sub-TLV. The new sub-sub-TLV serves as a subordinate TLV of the Segment-List sub-TLV.

[0071] Based on the solution provided in the above embodiment, in one embodiment, in step S13, notifying the segment routing policy carrying the target compression information to the headend node includes:

[0072] S41: The segment routing policy is carried and announced to the headend node via the Path Computation Element Communication Protocol (PCEP), wherein the target compression information is used as the lower-level encoding format information of the display routing object (ERO).

[0073] In this example, PCEP is extended so that the controller can carry target compression information in the PCEP Compressed SRH sub-TLV when advertising the segment routing policy to the headend node.

[0074] In one embodiment, the PCEP protocol is extended in this example, and a PCEP Compressed SRH sub-TLV is added, and the newly added sub-TLV serves as a subordinate TLV of the ERO.

[0075] In this example, the main structures of the PCEP Compressed SRH sub-TLV of PCEP and the BGP Compressed SRH sub-sub-TLV of BGP SR Policy can be shown in Figure 3.

[0076] In this example, a new structure is defined to carry the target compression information after the Segment list is compressed. There is no need to reuse the existing protocols SRv6-ERO of PCEP or Segment sub-TLV of BGP SR Policy to carry the target compression information. The solution provided by the embodiment of the application can make the compressed information more centralized, that is, each compressed C-SID Container can be put together.

[0077] In addition, the structure shown in Figure 3 is consistent with the data field in the SRH routing extension header, making it easy for headend nodes to use directly. Moreover, SRv6-ERO and Segment sub-TLV can maintain their existing usage and carry the full SID. The headend node receives not only the target compression information but also the original segment list information, which makes it easier to view the path information on the headend node.

[0078] In one embodiment, when the controller finds that the segment list of the SR Policy candidate path to be announced contains segments with a compression method that the head-end node cannot support, it can also choose to use only the structure shown in Figure 3 to announce the target compression information without carrying the original segment list.

[0079] To solve the problems existing in the prior art, as shown in FIG4 , an embodiment of the present application further provides a method for encapsulating a data message, which is applied to a head-end node of a data transmission path, comprising:

[0080] S51: Obtain a segment routing policy announced by the controller, wherein the segment routing policy carries target compression information, and the target compression information is obtained by the controller compressing the segment list corresponding to the data transmission path when the head-end node supports a target function, and the target function represents the ability to process the target compression information.

[0081] In this step, the headend node obtains the segment routing policy advertised by the controller. For example, PCEP or BGP SR Policy can be used to advertise the routing policy, which carries the newly added PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV. The headend node can then perform compression based on the original segment list. If the headend node finds that the segment list contains unresolvable segments, it can directly encapsulate the received target traffic based on the information carried in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV.

[0082] S52: Encapsulate the received target traffic according to the target compression information. In some embodiments, the destination address and SRH routing extension header of the IPv6 packet header encapsulated with the target traffic are filled in based on the information in the PCEP Compressed SRH sub-TLV or the BGP Compressed SRH sub-sub-TLV. During the step of encapsulating the received target traffic, the headend node may fill in the destination address of the IPv6 header with the last 16 bytes indicated by Count in the Compressed Segment List.

[0083] Whether the headend node enables Reduce when filling in the SRH routing extension header is affected by whether the headend node enables Reduce. Reduce means that the SRH routing extension header does not need to carry the destination address that has been filled in the IPv6 header.

[0084] If Reduce is not enabled on the headend node, the Last Entry and Segment Left fields of the SRH routing extension header are filled with the value of Count-1, and the data portion of the SRH routing extension header is filled with the Compressed Segment List.

[0085] If Reduce is enabled on the headend node, the Last Entry field of the SRH routing extension header is filled with the value of Count-2, the Segment Left field is filled with the value of Count-1, and the data portion of the SRH routing extension header is filled with the Compressed Segment List excluding the last 16 bytes.

[0086] If the Count value in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV is 1 and Reduce is enabled on the headend node, the destination address in the IPv6 header is filled in the Compressed Segment List, and the SRH routing extension header is not carried.

[0087] This solution allows the controller to perform proxy compression on the segment list when the headend node supports the target functionality, eliminating the need for the headend node to perform compression itself. This allows the headend node to encapsulate received target traffic based on the target compression information, eliminating the need for compression by the headend node itself. This allows compressed segment routing headers to be applied even when the headend node of a transmission link doesn't support a particular compression method or lacks compression capabilities. This reduces packet overhead, improves network link bandwidth utilization, and reduces the burden on network equipment.

[0088] Based on the solution provided by the above embodiment, in one embodiment, before the above step S51, that is, before obtaining the segment routing policy announced by the controller, the following is further included:

[0089] S61: Reporting a protocol message with a flag bit of an identification field set to a preset value to the controller, where the preset value is used to indicate that the head-end node supports the target function.

[0090] In an embodiment of the present application, whether the head-end node supports the target function is indicated by the value of a pre-set flag bit of the identification field carried in the protocol message. In practical applications, the specific position of the flag bit can be pre-set by a technician, or determined in advance by negotiation between the controller and the head-end node. Accordingly, the meaning expressed by the value of the flag bit can also be predetermined. In an embodiment of the present application, whether the head-end node supports the target function is expressed by the value in the flag bit, so that the controller can decide whether to perform proxy compression on the segment list on behalf of the head-end node.

[0091] Based on the solution provided by the above embodiment, in one embodiment, the protocol message includes a Border Gateway Protocol link state update message, and the identification field includes an SRv6 Capabilities sub-TLV.

[0092] Based on the solution provided by the above embodiment, in one embodiment, the data transmission path corresponds to at least one segment list; wherein, in the segment routing strategy, the target compression information is carried after the corresponding segment list.

[0093] Based on the solution provided in the above embodiment, in one embodiment, the target compression information includes a Type field, a Count field and a Compressed Segment List field; wherein the Type field is used to indicate that the type of the current structure is the target compression information; the Compressed Segment List field is used to indicate the content of the target compression information; and the Count field is determined by dividing the length of the Compressed Segment List field by 16.

[0094] Based on the solution provided by the above embodiment, in one embodiment, before the above step S52, that is, before encapsulating the received target traffic according to the target compression information, the method further includes:

[0095] S71: In response to the notification protocol being the Border Gateway Protocol (BGP), the target compression information is obtained from the lower-level encoding format information of the segment list sub-encoding format.

[0096] Based on the solution provided by the above embodiment, in one embodiment, before the above step S52, that is, before encapsulating the received target traffic according to the target compression information, the method further includes:

[0097] S81: In response to the notification protocol being the Path Computation Element Communication Protocol (PCEP), the target compression information is obtained from the lower-level encoding format information of the display routing object (ERO).

[0098] Based on the solution provided by the above embodiment, in one embodiment, in the above step S52, encapsulating the received target traffic according to the target compression information includes:

[0099] S91: Fill in the destination address and SRH routing extension header of the IPv6 message header of the target traffic encapsulation according to the target compression information.

[0100] Based on the solution provided by the above embodiment, in one embodiment, in the above step S91, filling in the destination address and SRH routing extension header of the IPv6 message header of the target traffic encapsulation according to the target compression information includes:

[0101] S101: Determine the destination address of the IPv6 packet header based on the Count field and the Compressed Segment List field.

[0102] S102: Determine the Last Entry field and the Segment Left field of the SRH routing extension header of the IPv6 packet header based on the Count field.

[0103] S103: Determine the data field of the SRH routing extension header based on the Compressed Segment List field.

[0104] FIG5 shows a segment routing network topology. The following describes how to fill in and use the PCEP Compressed SRH sub-TLV or the BGP Compressed SRH sub-sub-TLV.

[0105] In the network topology shown in Figure 5, traffic is sent from source node N10 to destination node N19. As the headend node, N11 receives an SR Policy from the controller, advertised by PCEP or BGP SR Policy. N11 only supports standard SRv6 SIDs and does not support compression. However, N11 supports the SRH compression proxy capability of the present invention. When N11 uses BGP-LS to advertise node capabilities to the controller, it sets the P flag to 1. N12 through N18 support two compression modes: Next-C-SID and Replace-C-SID for Endpoint Behavior, respectively.

[0106] For example, the IPv6 address of N10 is A:10::, and the IPv6 address of N19 is A:19::.

[0107] N11's IPv6 address is A:11::, and its common SID is B:11::.

[0108] The compressible SID of Next-C-SID of Endpoint Behavior N12 to N18 is C1:C1:k:1::, where k corresponds to the node sequence number. The length of C1:C1 as the Locator_Block is 4 bytes.

[0109] The compressible SID of Replace-C-SID of Endpoint Behavior N12 to N18 is C2:C2:C2:C2:k:2::, where k represents the node sequence number. The length of C2:C2:C2:C2 as the Locator_Block is 8 bytes.

[0110] N11 receives two SR Policies from the controller. The forwarding path for SR Policy 1 is represented by a segment list consisting of compressible SIDs in Next-C-SID:<C1:C1:13:1::,C1:C1:15:1::,C1:C1:17:1::> .

[0111] The forwarding path for SR Policy 2 is represented by a segment list consisting of compressible SIDs in Replace-C-SID: <C2:C2:C2:C2:12:2::,C2:C2:C2:C2:13:2::,C2:C2:C2:C2:14:2::,C2:C2:C2:C2:15:2::,C2:C2:C2:C2:16:2::,C2:C2:C2:C2:17:2::,C2:C2:C2:C2:18:2::> .

[0112] FIG6 is a schematic diagram showing the structure of the compression information generated by the controller for the Segment list of the SR Policy 1 according to the Next-C-SID compression method in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV.

[0113] The headend node N11 receives a candidate path message for SR Policy 1 from the controller using PCEP or BGP SR Policy. The candidate path message carries not only the regular segment list but also the Compressed SRH structure (as shown in Figure 6) generated using the Next-C-SID compression method.

[0114] The last 16 bytes of the Compressed SRH List indicated by Count = 1 in the structure will be used as the destination address of the IPv6 header. The following describes two cases based on whether the headend node N11 enables Reduce.

[0115] If Reduce is not enabled on headend node N11, the IPv6 header also carries an SRH routing extension header. The Segment Left and Last Entry fields of the SRH routing extension header are filled with Count - 1, that is, 0. The data portion of the SRH routing extension header is filled with the Compressed SRH List. When headend node N11 forwards traffic packets using SR Policy 1, the encapsulation format is as follows:

[0116] (IPv6 B:11::,C1:C1:13:1:15:1:17:1)

[0117] (SRH Segment Left=0,Last Entry=0;C1:C1:13:1:15:1:17:1)

[0118] (IPv6 A:10::,A:19::)

[0119] If Reduce is enabled on the headend node N11, the IPv6 header does not need to carry the SRH routing extension header because the Count in the structure is 1. When Reduce is enabled on the headend node N11, the encapsulation format of the traffic packet forwarded using SR Policy 1 is as follows:

[0120] (IPv6 B:11::,C1:C1:13:1:15:1:17:1)

[0121] (IPv6 A:10::,A:19::)

[0122] FIG7 is a schematic diagram showing the structure of the compression information generated by the controller for the Segment list of the SR Policy 2 according to the Replace-C-SID compression method in the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV.

[0123] The headend node N11 receives a candidate path message for SR Policy 2 from the controller using PCEP or BGP SR Policy. The candidate path message carries not only the regular segment list but also the Compressed SRH structure (as shown in Figure 7) generated using the Replace-C-SID compression method.

[0124] The last 16 bytes of the Compressed SRH List, indicated by Count = 3, will be used as the destination address of the IPv6 header. The following describes two scenarios, depending on whether Reduce is enabled on the headend node N11:

[0125] If Reduce is not enabled on headend node N11, the IPv6 header also carries an SRH routing extension header. The Segment Left and Last Entry fields of the SRH routing extension header are filled with Count - 1, which is equal to 2. The data portion of the SRH routing extension header is filled with Compressed SRH List. When headend node N11 uses SR Policy 2 to forward traffic packets, the encapsulation format is as follows:

[0126] (IPv6 B:11::,C2:C2:C2:C2:12:2:0:0)

[0127] (SRH Segment Left=2,Last Entry=2; ::18:2:17:2; 16:2:15:2:14:2:13:2; C2:C2:C2:C2:12:2:0:0)

[0128] (IPv6 A:10::,A:19::)

[0129] If Reduce is enabled on headend node N11, because the Count field in the structure is greater than 1, the IPv6 header still carries the SRH routing extension header. The Segment Left field of the SRH routing extension header is filled with Count - 1 (here, 2), and the Last Entry field is filled with Count - 2 (here, 1). The data portion of the SRH routing extension header is filled with the rest of the Compressed SRH List in the structure, excluding the last 16 bytes. When Reduce is enabled on headend node N11, the encapsulation format for forwarding traffic packets using SR Policy 2 is as follows:

[0130] (IPv6 B:11::,C2:C2:C2:C2:12:2:0:0)

[0131] (SRH Segment Left=2,Last Entry=1; ::18:2:17:2; 16:2:15:2:14:2:13:2)

[0132] (IPv6 A:10::,A:19::)

[0133] The solution provided by the embodiment of this application can be applied to application scenarios that require header compression. With the development of SRv6 technology and header compression technology, compression methods not mentioned in the examples of this application may appear in actual application scenarios. The solution provided by the embodiment of this application can be performed by the controller agent to compress the segment list, thereby eliminating the need for the head-end node to support multiple complex compression methods and the need for the head-end node to perform local compression. This is conducive to the expansion of compression methods and the development of SRv6 technology, and can also improve the compatibility of transmission links with multiple compression methods for segment routing headers, reduce message overhead, improve network link bandwidth utilization, and reduce development costs.

[0134] To solve the problems existing in the prior art, as shown in FIG8 , an embodiment of the present application further provides a device 800 for encapsulating a data message, which is applied to a controller and includes:

[0135] The determination module 801 determines whether the head-end node of the data transmission path supports a target function, wherein the target function represents the ability to process target compressed information.

[0136] The compression module 802 compresses the segment list corresponding to the data transmission path to obtain the target compression information when the head-end node supports the target function.

[0137] The notification module 803 notifies the segment routing policy carrying the target compression information to the head-end node, where the segment routing policy is used to instruct the head-end node to encapsulate the received target traffic according to the target compression information.

[0138] Through the device provided by the embodiment of the present application, the controller performs proxy compression on the segment list when the head-end node supports the target function, without the need for the head-end node to perform compression itself. The controller then sends a segment routing policy message carrying the target compression information to the head-end node, so that the head-end node can encapsulate the received target traffic according to the target compression information, without the need for the head-end node to perform compression. Therefore, even if the head-end node in the transmission link itself does not support a certain compression method or does not have compression capabilities, it can also apply the compressed segment routing header to encapsulate and forward traffic, which is beneficial to reducing message overhead, improving network link bandwidth utilization, and reducing the burden on network equipment.

[0139] The aforementioned modules in the apparatus provided in the embodiments of the present application may also implement the method steps provided in the aforementioned method embodiments. Alternatively, the apparatus provided in the embodiments of the present application may further include other modules in addition to the aforementioned modules to implement the method steps provided in the aforementioned method embodiments. Furthermore, the apparatus provided in the embodiments of the present application can achieve the technical effects achievable by the aforementioned method embodiments.

[0140] To solve the problems existing in the prior art, as shown in FIG9 , an embodiment of the present application further provides a device 900 for encapsulating a data message, which is applied to a head-end node of a data transmission path, including:

[0141] Acquisition module 901 acquires the segment routing strategy announced by the controller, wherein the segment routing strategy carries target compression information, and the target compression information is obtained by the controller compressing the segment list corresponding to the data transmission path when the head-end node supports the target function, and the target function represents the ability to process the target compression information.

[0142] The encapsulation module 902 encapsulates the received target traffic according to the target compression information.

[0143] Through the device provided by the embodiment of the present application, the controller performs proxy compression on the segment list when the head-end node supports the target function, without the need for the head-end node to perform compression itself. The controller then sends a segment routing policy message carrying the target compression information to the head-end node, so that the head-end node can encapsulate the received target traffic according to the target compression information, without the need for the head-end node to perform compression. Therefore, even if the head-end node in the transmission link itself does not support a certain compression method or does not have compression capabilities, it can also apply the compressed segment routing header to encapsulate and forward traffic, which is beneficial to reducing message overhead, improving network link bandwidth utilization, and reducing the burden on network equipment.

[0144] The aforementioned modules in the apparatus provided in the embodiments of the present application may also implement the method steps provided in the aforementioned method embodiments. Alternatively, the apparatus provided in the embodiments of the present application may further include other modules in addition to the aforementioned modules to implement the method steps provided in the aforementioned method embodiments. Furthermore, the apparatus provided in the embodiments of the present application can achieve the technical effects achievable by the aforementioned method embodiments.

[0145] In one embodiment, the embodiment of the present application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, the various processes of the above-mentioned method embodiment of encapsulating data packets are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0146] The present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements the various processes of the above-mentioned method embodiment for encapsulating data packets and can achieve the same technical effects. To avoid repetition, the details are not described here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0147] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0148] The present application is described with reference to the flow chart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present application. It should be understood that each flow process and / or box in the flow chart and / or block diagram and the combination of the flow process and / or box in the flow chart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processing machine or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart flow or multiple flows and / or one box or multiple boxes of the block diagram.

[0149] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0150] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0151] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0152] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0153] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0154] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0155] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0156] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for encapsulating data messages, applied to a controller, comprising: determining whether a head-end node of a data transmission path supports a target function, wherein the target function represents a capability of processing target compressed information; In a case where the head-end node supports the target function, compressing the segment list corresponding to the data transmission path to obtain the target compression information; The segment routing policy carrying the target compression information is notified to the head-end node, where the segment routing policy is used to instruct the head-end node to encapsulate the received target traffic according to the target compression information.

2. The method of claim 1, wherein: The step of determining whether the head end node of the data transmission path supports the target function includes: Obtaining the protocol message reported by the head-end node; When the flag bit of the identification field carried by the protocol message is a preset value, it is determined that the head-end node supports the target function.

3. The method of claim 2, wherein: The protocol message includes a border gateway protocol link state update message, and the identification field includes an SRv6 Capabilities sub-TLV.

4. The method of claim 1, wherein: The data transmission path corresponds to at least one segment list; Wherein, in the segment routing strategy, the target compression information is carried after the corresponding segment list.

5. The method of claim 4, wherein: The target compression information includes a Type field, a Count field, and a Compressed Segment List field; Wherein, the Type field is used to indicate that the type of the current structure is the target compression information; The Compressed Segment List field is used to indicate the content of the target compression information; The Count field is determined by dividing the length of the Compressed Segment List field by 16.

6. The method of claim 5, wherein: Notifying the segment routing strategy carrying the target compression information to the headend node includes: The segment routing policy is carried and announced to the head-end node via the Border Gateway Protocol BGP, wherein the target compression information is used as the lower-level encoding format information of the segment list sub-encoding format.

7. The method of claim 5, wherein: Notifying the segment routing strategy carrying the target compression information to the headend node includes: The segment routing policy is carried and announced to the headend node via the path computation unit communication protocol PCEP, wherein the target compression information is used as the lower-level encoding format information of the display routing object ERO.

8. A method for encapsulating a data message, applied to a head-end node of a data transmission path, comprising: Acquire a segment routing strategy announced by the controller, wherein the segment routing strategy carries target compression information, the target compression information is obtained by the controller compressing a segment list corresponding to the data transmission path when the head-end node supports a target function, and the target function indicates a capability of processing the target compression information; The received target traffic is encapsulated according to the target compression information.

9. The method of claim 8, wherein: Before obtaining the segment routing policy advertised by the controller, it also includes: A protocol message in which a flag bit of an identification field is a preset value is reported to the controller, where the preset value is used to indicate that the head-end node supports the target function.

10. The method of claim 9, wherein: The protocol message includes a border gateway protocol link state update message, and the identification field includes an SRv6 Capabilities sub-TLV.

11. The method of claim 8, wherein: The data transmission path corresponds to at least one segment list; Wherein, in the segment routing strategy, the target compression information is carried after the corresponding segment list.

12. The method of claim 11, wherein: The target compression information includes a Type field, a Count field, and a Compressed Segment List field; Wherein, the Type field is used to indicate that the type of the current structure is the target compression information; The Compressed Segment List field is used to indicate the content of the target compression information; The Count field is determined by dividing the length of the Compressed Segment List field by 16.

13. The method of claim 12, wherein: Before encapsulating the received target traffic according to the target compression information, the method further includes: In response to the announcement protocol being the Border Gateway Protocol (BGP), the target compression information is obtained from the lower-level encoding format information of the segment list sub-encoding format.

14. The method of claim 12, wherein: Before encapsulating the received target traffic according to the target compression information, the method includes: In response to the notification protocol being the Path Computation Element Communication Protocol PCEP, the target compression information is acquired from the lower-level encoding format information of the display routing object ERO.

15. The method according to claim 13 or 14, wherein: Encapsulating the received target traffic according to the target compression information includes: The destination address and the SRH routing extension header of the IPv6 message header encapsulated by the target traffic are filled in according to the target compression information.

16. The method of claim 15, wherein: Fill in the destination address and SRH routing extension header of the IPv6 message header of the target traffic encapsulation according to the target compression information, including: Determine the destination address of the IPv6 packet header based on the Count field and the Compressed Segment List field; Determine the Last Entry field and the Segment Left field of the SRH routing extension header of the IPv6 packet header based on the Count field; The data field of the SRH routing extension header is determined based on the Compressed Segment List field.

17. An electronic device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 7 are implemented, or the steps of the method according to any one of claims 8 to 16 are implemented.

18. A computer-readable storage medium, wherein: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented, or the steps of the method according to any one of claims 8 to 16 are implemented.

Images