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

Abstract

The invention discloses a method for encapsulating a data message, electronic equipment and a readable storage medium, on one hand, the scheme provided by the invention is applied to a controller, and the method comprises the following steps: determining whether a head end node of a data transmission path supports a target function, the target function representing the capability of processing target compression information; under the condition that the head end node supports the target function, compressing the segment list corresponding to the data transmission path to obtain target compression information; and notifying the head end node of a segment routing strategy carrying the target compression information, wherein the segment routing strategy is used for indicating the head end node to package the received target traffic according to the target compression information. On the other hand, the scheme provided by the invention is also applied to a head end node of a data transmission path, and comprises the following steps: acquiring a segment routing strategy which is announced by a controller and carries target compression information; and packaging the received target traffic according to the target compression information.

Description

Technical Field

[0001] 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

[0002] SRv6 is the implementation of segment routing technology on the IPv6 data plane. During forwarding, the traffic encapsulation segment routing header (SRH) is used to indicate the nodes, links or services that the traffic forwarding path needs to pass through. SRH is an IPv6 routing extension header, which consists of a group of SRv6 SIDs (Segment Identifiers). The length of SRv6 SID is 128 bits, so in practical applications, there are often disadvantages such as large message overhead and low network link bandwidth utilization. In this regard, in practical applications, SRv6 SID can be compressed to reduce the length of the SRH routing extension header, thereby optimizing the message overhead.

[0003] However, there are many compression methods in actual applications, and requiring network devices to support multiple compression methods will increase the burden on network devices. If the headend node of the traffic does not support a certain compression method that needs to be used, the entire SRv6 domain cannot use this compression method.

[0004] The technical problem to be solved by the present 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. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a method for encapsulating data packets, an electronic device, and a readable storage medium, so as to solve the problem 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.

[0006] In a first aspect, a method for encapsulating a data message is provided, which is applied to a controller and includes:

[0007] 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;

[0008] 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;

[0009] 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.

[0010] In a second aspect, a method for encapsulating a data message is provided, which is applied to a head-end node of a data transmission path, comprising:

[0011] 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;

[0012] The received target traffic is encapsulated according to the target compression information.

[0013] According to a third aspect, an electronic device is provided, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method according to the first aspect and / or the second aspect.

[0014] 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.

[0015] In an embodiment of the present application, first, determine whether the head-end node of the data transmission path supports the target function, wherein the target function represents the ability to process the target compression information; then, if the head-end node supports the target function, compress the segment list corresponding to the data transmission path to obtain the target compression information; then, notify the head-end node of the segment routing policy carrying the target compression information, and the segment routing policy is used to instruct the head-end node to encapsulate the received target traffic according to the target compression information. Through this scheme, 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. Then, the controller sends the 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, and no compression is required by the head-end node. Thus, when the head-end node in the transmission link itself does not support a certain compression method or does not have the compression capability, the compressed segment routing header can be applied to encapsulate the forwarding traffic, which is conducive to reducing the message overhead, improving the bandwidth utilization of the network link, and reducing the burden on the network equipment. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] 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:

[0017] Figure 1It is a flowchart of a method for encapsulating data messages applied to a controller according to an embodiment of the present application;

[0018] Figure 2 It is a schematic diagram of a newly added P tag in BGP-LS extended SRv6 Capabilities sub-TLV in one embodiment of the present application;

[0019] Figure 3 It 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 BGPSRPolicy in one embodiment of the present application;

[0020] Figure 4 It is a flowchart of a method for encapsulating data messages applied to a head-end node according to an embodiment of the present application;

[0021] Figure 5 It is a schematic diagram of a segmented routing network topology structure of an embodiment of the present application;

[0022] Figure 6 It 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 a PCEP Compressed SRH sub-TLV or a BGP Compressed SRHsub-sub-TLV in an embodiment of the present application;

[0023] Figure 7 It is a schematic diagram of the structure of the 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 SRHsub-sub-TLV in an embodiment of the present application;

[0024] Figure 8 It is a structural schematic diagram of a device for encapsulating data messages applied to a controller according to an embodiment of the present application;

[0025] Fig. 9 It is a structural diagram of a device for encapsulating data messages applied to a head-end node according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] 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, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application. The numbering of the drawings in this application is only used to distinguish the various steps in the scheme, and is not used to limit the execution order of the various steps. The specific execution order is subject to the description in the specification.

[0027] The present invention relates to a segment routing (SR) technology, and in particular to a method of transmitting data packets using an IPv6 data plane (called SRv6) and adopting a compression technology. The present invention can be applied to an application scenario where a head-end node cannot support a corresponding compression method, and can also be applied to an application scenario where the head-end node is not convenient to perform compression due to reasons such as overload.

[0028] In order to solve the problems existing in the prior art, the embodiment of the present application provides a method for encapsulating data messages, which is applied to a controller, such as Figure 1 As shown, including:

[0029] 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.

[0030] The head-end node can actively or passively report to the controller whether it supports the target function, and the specific reporting can be realized in the form of a message. Supporting the target function means that the head-end node itself has the function of analyzing and processing the target compression information.

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

[0032] For example, the head-end node supports the target function, which 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 band, and to restore and generate the SRH header to be encapsulated for the traffic from the structure.

[0033] 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.

[0034] 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.

[0035] In actual applications, the controller supports multiple compression methods, and the target proxy compression method can be selected according to actual needs. For example, the target proxy compression method can be the Next-C-SID compression method or the Replace-C-SID compression method. Among them, C-SID refers to Compressed Segment Identifiers, that is, compression identifiers.

[0036] In the case where the head-end node supports the target function, the controller can comprehensively determine the compression method actually used based on multiple factors such as the compression method required to be performed on the data and the compression methods announced by other nodes.

[0037] 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.

[0038] S13: Notify 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.

[0039] The controller sends the target compression information to the head-end node by sending the segment routing policy (SR Policy) message to the head-end node, which instructs the head-end node to use the target compression information to encapsulate the received target traffic. In the process of encapsulating the received target traffic, the head-end node can directly use the target compression information, and does not need to perform segment list compression itself, so the head-end node itself does not need to support every compression technology.

[0040] For example, the controller can send the SR Policy to the headend node through the Path Computation Element Communication Protocol (PCEP) or the Border Gateway Protocol (BGP). Alternatively, it can also be sent through other protocol messages according to actual needs.

[0041] Specifically, when the head-end node supports the target function, the controller can carry the PCEP Compressed SRH sub-TLV in the Explicit Route Object (ERO) during the notification of the PCEP message. Alternatively, the controller can carry the BGP Compressed SRH sub-sub-TLV in the Segment-List sub-TLV during the notification of the Update message of the BGPSR Policy, thereby notifying the segment routing policy carrying the target compression information to the head-end node.

[0042] In actual applications, optionally, if the head-end node does not support the target function, the controller can notify PCEP's PCRep (PCEP Path Computation Reply, PCEP path calculation reply) message, PCInitiate (PCEP LSPInitiate Request, PCEP label forwarding path initialization request) message, PCUpd (PCEP LSP Update Request, PCEP label forwarding path update request) message, PCRpt (PCEP LSP StateReport, PCEP label forwarding path status report) message or BGPSR Policy Update message in the manner specified by the existing protocol. These PCEP messages carry ERO, and the BGP Update message carries Segment-List sub-TLV.

[0043] If the node supports the target function, the controller may carry the newly added lower-level PCEP Compressed SRH sub-TLV structure of this application in the ERO object when notifying the PCEP message, and may carry the newly added lower-level BGP Compressed SRH sub-sub-TLV structure of this application in the Segment-List sub-TLV when notifying the Update message of the BGPSR Policy.

[0044] On the headend node side, after receiving a PCEP message or an Update message of a BGPSR Policy, 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 Update message of the BGPSR Policy. Alternatively, the headend node can also compress the information from the ERO object or the Segment-List sub-TLV itself according to the method specified by the existing protocol.

[0045] Through the scheme provided by the embodiment of the present application, first, determine whether the head-end node of the data transmission path supports the target function, wherein the target function represents the ability to process the target compression information; then, if the head-end node supports the target function, compress the segment list corresponding to the data transmission path to obtain the target compression information; then, the segment routing strategy carrying the target compression information is notified to the head-end node, and the segment routing strategy is used to instruct the head-end node to encapsulate the received target traffic according to the target compression information. Through this scheme, 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. Then, the controller sends the segment routing strategy 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, and no compression is required by the head-end node. Thus, when the head-end node in the transmission link itself does not support a certain compression method or does not have the compression capability, the compressed segment routing header can be applied to encapsulate the forwarding traffic, which is conducive to reducing the message overhead, improving the bandwidth utilization of the network link, and reducing the burden on network devices.

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

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

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

[0049] 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.

[0050] In practical applications, the specific position of the flag bit can be preset by a technician, or can be pre-negotiated and determined by the controller and the head-end node. Correspondingly, the meaning expressed by the value of the flag bit can also be predetermined.

[0051] 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 make a notification in the manner specified by the existing protocol and does not perform proxy compression.

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

[0053] In actual applications, the headend node can flexibly set the value of the flag bit to flexibly change the proxy compression. For example, if the headend node itself does not have the required compression function, the P flag bit is set to 1, so that the controller performs proxy compression. Alternatively, if the headend node is in a high-load state and it is not convenient for it to perform compression, the P flag bit is set to 1, so that the controller performs proxy compression.

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

[0055] In this example, the BGP-LS protocol specifically refers to a protocol message that the network node notifies the controller of its capabilities and status. In this solution, the SRv6 Capabilities sub-TLV of the BGP-LS protocol is extended, and a P flag is added to indicate whether the network node supports the target function.

[0056] For example, Figure 2 This is a schematic diagram of 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 preset in the fourth bit of the Flags field. The P flag position 1 indicates that the network node supports SRH compression proxy, that is, it can process the newly added PCEP Compressed SRH sub-TLV in the PCEP message and the newly added BGP Compressed SRH sub-sub-TLV in the Update message of the BGPSR Policy.

[0057] Based on the solution provided in the above embodiment, optionally, the data transmission path corresponds to at least one segment list;

[0058] Wherein, in the segment routing strategy, the target compression information is carried after the corresponding segment list.

[0059] In this example, the controller can first calculate one or more candidate paths for the headend node, and generate one or a group of segment lists based on the candidate paths. The segment list is compressed to obtain the corresponding target compression information, and the target compression information is carried after the corresponding segment list, so that the corresponding relationship between the segment list and the target compression information is retained in the segment routing policy. In actual applications, the above target compression information can be carried in the ERO object of PCEP or the Segment-List sub-TLV of BGP so as to be sent down to the headend node.

[0060] Specifically, when the head-end node supports the target function, when the controller notifies the candidate path to the head-end node, it can 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 BGPSR Policy.

[0061] Subsequently, the headend node receives the segment routing policy carrying the target compression information announced by the controller using PCEP or BGPSR Policy and performs parsing. If the parsing finds that there is a PCEP Compressed SRH sub-TLV or BGPCompressed 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 by the PCEP Compressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV.

[0062] Alternatively, 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 BGPCompressed SRH sub-sub-TLV.

[0063] In actual applications, if the headend node does not support the target function, the controller does not carry PCEP Compressed SRH sub-TLV and BGP Compressed SRHsub-sub-TLV when announcing candidate path information using PCEP or BGP SRPolicy. The headend node can perform compression and subsequent processing according to existing rules.

[0064] Based on the solution provided in the above embodiment, optionally, the target compression information includes a Type field, a Count field and a Compressed Segment List field;

[0065] Wherein, the Type field is used to indicate that the type of the current structure is the target compression information;

[0066] The Compressed Segment List field is used to indicate the content of the target compression information;

[0067] The Count field is determined by dividing the length of the Compressed Segment List field by 16.

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

[0069] Specifically, see Figure 3 The Type field may be pre-defined by IANA (Internet Assigned Numbers Authority) for PCEP Compressed SRH sub-TLV and BGP CompressedSRH sub-sub-TLV, respectively.

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

[0071] Compressed Segment List is the target compression information obtained by the controller compression, and the head-end node will fill in the data part of the SRH routing extension header of the IPv6 header.

[0072] In addition, the segment routing policy message can also carry other fields, for example, Figure 3 In the Length field, the Length field can 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.

[0073] 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 it is treated as 0 when receiving.

[0074] Since the existing protocol's SRv6-ERO and Segment sub-TLV both have some 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 together. The structure used in the solution provided in this embodiment does not have an extra header to separate valid information, so that the compressed information is concentrated together, which is 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. It will be more intuitive and clearer to view the path information on the head-end node.

[0075] Based on the solution provided in the above embodiment, optionally, in the above step S13, the segment routing strategy carrying the target compression information is notified to the headend node, including:

[0076] S31: The segment routing policy is carried and notified 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.

[0077] In this example, the BGPSR Policy is extended, and the controller can carry the target compression information in the BGP Compressed SRH sub-sub-TLV when notifying the segment routing policy to the headend node.

[0078] In this example, the BGPSR Policy is extended to add the BGP Compressed SRH sub-sub-TLV. The newly added sub-sub-TLV is used as the subordinate TLV of the Segment-List sub-TLV.

[0079] Based on the solution provided in the above embodiment, optionally, in the above step S13, the segment routing strategy carrying the target compression information is notified to the headend node, including:

[0080] S41: Carrying the segment routing policy notification to the headend node through 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.

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

[0082] Specifically, in this example, the PCEP protocol is extended to add a PCEP Compressed SRH sub-TLV, and the newly added sub-TLV is used as a subordinate TLV of ERO.

[0083] The main structure diagram of the PCEP Compressed SRH sub-TLV of PCEP and the BGPCompressed SRH sub-sub-TLV of BGPSR Policy in this example can be as follows: Figure 3 shown.

[0084] 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 protocol PCEP's SRv6-ERO or BGPSR Policy's Segment sub-TLV to carry the target compression information. The solution provided by the embodiment of the present application can make the compressed information more centralized, that is, each compressed C-SIDContainer can be put together.

[0085] in addition, Figure 3The structure shown is consistent with the data field in the SRH routing extension header, which can be directly used by the head-end node. In addition, SRv6-ERO and Segment sub-TLV can maintain the existing usage mode to carry the complete SID. The head-end node receives not only the target compression information, but also the original Segment list information, which can help to view the path information on the head-end node more intuitively and clearly.

[0086] Optionally, when the controller finds that the segment list of the SR Policy candidate path to be announced contains segments with compression methods that the headend node cannot support, it can also choose to use only Figure 3 The structure shown advertises the target compression information and does not need to carry the original segment list.

[0087] In order to solve the problems existing in the prior art, such as Figure 4 As shown, the embodiment of the present application also provides a method for encapsulating a data message, which is applied to a head-end node of a data transmission path, including:

[0088] S51: Obtain a 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 by 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.

[0089] In this step, the head-end node obtains the segment routing policy announced by the controller. For example, the routing policy can be announced using PCEP or BGPSR Policy. The routing policy carries the newly added PCEP Compressed SRH sub-TLV or BGPCompressed SRH sub-sub-TLV. The head-end node can perform compression according to the original Segment list. If the head-end node finds that there are unresolvable segments in the Segment list, it can also directly encapsulate the received target traffic according to the information carried by PCEP Compressed SRHsub-TLV or BGP Compressed SRH sub-sub-TLV.

[0090] S52: Encapsulate the received target traffic according to the target compression information. Specifically, fill in the destination address and SRH routing extension header of the IPv6 packet header encapsulated by the target traffic according to the information of PCEPCompressed SRH sub-TLV or BGP Compressed SRH sub-sub-TLV. In the step of encapsulating the received target traffic, the headend node may fill in the last group of 16 bytes indicated by Count in the Compressed Segment List in the destination address of the IPv6 header.

[0091] Whether the headend node enables Reduce when filling in the SRH routing extension header, where Reduce means that the SRH routing extension header does not need to carry the destination address that has been filled in the IPv6 header.

[0092] 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 part of the SRH routing extension header is filled with Compressed Segment List.

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

[0094] 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 of the IPv6 header is filled in with Compressed SegmentList and the SRH routing extension header is not required.

[0095] Through this solution, 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. This enables the head-end node to 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 of the transmission link itself does not support a certain compression method or does not have the compression capability, the compressed segment routing header can be applied, which is beneficial to reducing message overhead, improving network link bandwidth utilization, and reducing the burden on network devices.

[0096] Based on the solution provided in the above embodiment, optionally, before the above step S51, that is, before obtaining the segment routing policy announced by the controller, the method further includes:

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

[0098] 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. Correspondingly, 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 decides whether to perform proxy compression on the segment list instead of the head-end node.

[0099] Based on the solution provided in the above embodiment, optionally, the protocol message includes a border gateway protocol link state update message, and the identification field includes an SRv6 Capabilities sub-TLV.

[0100] Based on the solution provided in the above embodiment, optionally, the data transmission path corresponds to at least one segment list;

[0101] Wherein, in the segment routing strategy, the target compression information is carried after the corresponding segment list.

[0102] Based on the solution provided in the above embodiment, optionally, the target compression information includes a Type field, a Count field and a Compressed Segment List field;

[0103] Wherein, the Type field is used to indicate that the type of the current structure is the target compression information;

[0104] The Compressed Segment List field is used to indicate the content of the target compression information;

[0105] The Count field is determined by dividing the length of the Compressed Segment List field by 16.

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

[0107] S71: 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.

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

[0109] S81: 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.

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

[0111] 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.

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

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

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

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

[0116] Figure 5 A segmented routing network topology is shown. Next, the filling and use of the PCEP Compressed SRH sub-TLV or the BGP Compressed SRH sub-sub-TLV will be described.

[0117] exist Figure 5In the network topology shown, traffic is sent from source node N10 to destination node N19. N11, as the headend node, receives the SR Policy announced by PCEP or BGPSR Policy from the controller. N11 only supports ordinary SRv6 SID and does not support compression, but N11 supports the SRH compression proxy capability of the present invention. When N11 uses BGP-LS to announce the node capability to the controller, the P tag position is set to 1. N12 to N18 support two compression modes: Next-C-SID and Replace-C-SID for Endpoint Behavior.

[0118] Exemplarily, the IPv6 address of N10 is A:10::, and the IPv6 address of N19 is A:19::.

[0119] The IPv6 address of N11 is A:11:: and the common SID is B:11::.

[0120] 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, and the length of C1:C1 as Locator_Block is 4 bytes.

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

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

[0123] The forwarding path of SR Policy 2 is represented by a segment list consisting of compressible SIDs of 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::> .

[0124] Figure 6The diagram is a structural diagram of the compression information generated by the controller for the Segment list of the above 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.

[0125] The headend node N11 receives the candidate path message of SR Policy 1 announced by PCEP or BGPSR Policy from the controller. In addition to the regular segment list, the candidate path message also carries the following information generated according to the Next-C-SID compression method: Figure 6 The Compressed SRH structure shown.

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

[0127] If Reduce is not enabled on the headend node N11, the IPv6 header will also carry 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 part of the SRH routing extension header is filled with Compressed SRH List. The encapsulation format of the traffic message forwarded by the headend node N11 using SR Policy 1 is as follows:

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

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

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

[0131] 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 equal to 1. When Reduce is enabled on the headend node N11, the encapsulation format of the traffic message forwarded using SR Policy 1 is as follows:

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

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

[0134] Figure 7 The diagram is a structural diagram of the compression information generated by the controller for the Segment list of the above SR Policy 2 according to the Replace-C-SID compression method in the PCEP Compressed SRH sub-TLV or the BGP Compressed SRH sub-sub-TLV.

[0135] The headend node N11 receives the candidate path message of SR Policy 2 announced by PCEP or BGPSR Policy from the controller. In addition to the regular segment list, the candidate path message also carries the following information generated by the Replace-C-SID compression method: Figure 7 The Compressed SRH structure shown.

[0136] The last group of 16 bytes indicated by Count=3 in the Compressed SRH List in the structure will be used as the destination address of the IPv6 header. The following describes two situations respectively, depending on whether the headend node N11 enables Reduce:

[0137] If Reduce is not enabled on the headend node N11, the IPv6 header will also carry an SRH routing extension header, where the Segment Left and Last Entry fields of the SRH routing extension header are filled with Count-1, which is equal to 2, and the data part of the SRH routing extension header is filled with Compressed SRH List. The encapsulation format of the traffic message forwarded by the headend node N11 using SR Policy 2 is as follows:

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

[0139] (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)

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

[0141] If Reduce is enabled on the headend node N11, because the Count in the structure is greater than 1, the IPv6 header still needs to carry the SRH routing extension header, where the Segment Left field of the SRH routing extension header is filled with Count-1, which is equal to 2, and the Last Entry field is filled with Count-2, which is equal to 1. The data part of the SRH routing extension header is filled with the rest of the structure except the last 16 bytes of the Compressed SRH List. When Reduce is enabled on the headend node N11, the encapsulation format of the traffic message forwarded using SR Policy 2 is as follows:

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

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

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

[0145] The solution provided by the embodiment of the present application can be applied to application scenarios where header compression needs to be performed. With the development of SRv6 technology and header compression technology, compression methods not mentioned in the examples of this application may also appear in actual application scenarios. The solution provided by the embodiment of the present application can be performed by the controller agent to compress the segment list, so that the head-end node does not need to support a variety of complicated compression methods, and the head-end node does not need to perform local compression, which is conducive to the expansion of compression methods and the development of SRv6 technology. It can also improve the compatibility of the transmission link with multiple compression methods of the segment routing header, reduce message overhead, improve network link bandwidth utilization, and reduce development costs.

[0146] Optionally, in order to solve the problems existing in the prior art, such as Figure 8 As shown, the embodiment of the present application further provides a device 800 for encapsulating a data message, which is applied to a controller and includes:

[0147] Determining module 801, 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;

[0148] A compression module 802, when the head-end node supports the target function, compresses the segment list corresponding to the data transmission path to obtain the target compression information;

[0149] 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.

[0150] 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, and the head-end node itself does not need to perform compression. Then, the controller sends the 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, and the head-end node no longer needs to perform compression. Therefore, when the head-end node in the transmission link itself does not support a certain compression method or does not have the compression capability, it can also apply the compressed segment routing header to encapsulate the forwarding traffic, which is beneficial to reduce the message overhead, improve the network link bandwidth utilization, and reduce the burden on network equipment.

[0151] Among them, the above modules in the device provided by the embodiment of the present application can also implement the method steps provided by the above method embodiment. Alternatively, the device provided by the embodiment of the present application can also include other modules in addition to the above modules to implement the method steps provided by the above method embodiment. And the device provided by the embodiment of the present application can achieve the technical effects that can be achieved by the above method embodiment.

[0152] Optionally, in order to solve the problems existing in the prior art, such as Fig. 9 As shown, the 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:

[0153] An acquisition module 901 is configured to acquire a segment routing strategy notified by a controller, wherein the segment routing strategy carries target compression information, and the target compression information is obtained by the controller by 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 target compression information;

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

[0155] 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, and the head-end node itself does not need to perform compression. Then, the controller sends the 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, and the head-end node no longer needs to perform compression. Therefore, when the head-end node in the transmission link itself does not support a certain compression method or does not have the compression capability, it can also apply the compressed segment routing header to encapsulate the forwarding traffic, which is beneficial to reduce the message overhead, improve the network link bandwidth utilization, and reduce the burden on network equipment.

[0156] Among them, the above modules in the device provided by the embodiment of the present application can also implement the method steps provided by the above method embodiment. Alternatively, the device provided by the embodiment of the present application can also include other modules in addition to the above modules to implement the method steps provided by the above method embodiment. And the device provided by the embodiment of the present application can achieve the technical effects that can be achieved by the above method embodiment.

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

[0158] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above-mentioned method embodiment of encapsulating data messages is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated 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.

[0159] 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 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 may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0160] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented 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 processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0161] These computer program instructions may also be stored in a computer-readable memory capable of directing 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 an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0162] 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, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0164] The 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. The memory is an example of a computer-readable medium.

[0165] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 disk read-only memory (CD-ROM), digital versatile disk (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 temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0166] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0167] 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 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 may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0168] The above is only 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 modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for encapsulating a data message, characterized in that: Applicable to controllers, including: 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 according to claim 1, characterized in that 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 according to claim 2, characterized in that 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 according to claim 1, characterized in that 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 according to claim 4, characterized in that 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 according to claim 5, characterized in that 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 according to claim 5, characterized in that 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, characterized in that: The headend node used in the data transmission path includes: 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 according to claim 8, characterized in that 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 according to claim 9, characterized in that 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 according to claim 8, characterized in that 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 according to claim 11, characterized in that 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 according to claim 12, characterized in that 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 according to claim 12, characterized in that 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, characterized in that 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 according to claim 15, characterized in that 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, characterized in that: include: 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 or 8 to 16 are implemented.

18. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7 or 8 to 16.

Images