Segment routing header compression method, service processing method, segment routing header compression device, and service processing device

Abstract

The present disclosure provides a segment routing header compression method, the method including: setting a compressed segment identifier or an uncompressed segment identifier in each node on a segment routing path; setting a compressed segment identifier, which additionally has a function of performing segment identifier type conversion for the segment identifier indicated by the remaining segment number, in a critical node; generating a segment list including the compressed segment identifiers and the uncompressed segment identifiers that have already been set; and generating a segment routing header of a service message, the segment routing header of the service message including the segment list and a routing type field for indicating the format of the segment routing header, the format of the segment routing header conforming to the format of the compressed segment identifier. The present disclosure further provides a service processing method, a segment routing header compression device, a service processing device, a computer device, and a computer-readable medium.

Description

[Technical Field]

[0001] This application claims priority from Chinese Patent Application No. 202010285171.9, filed on April 13, 2020, the contents of which are incorporated herein by reference in their entirety.

[0002] The present disclosure relates to the field of wireless communication technology, and in particular to a segment routing header compression method , SERVICE PROCESSING METHOD, SEGMENT ROUTING HEADER COMPRESSION DEVICE AND SERVICE PROCESSING DEVICE - Patent application Regarding. [Background technology]

[0003] Segment Routing (SR) is a technology that realizes source routing, and RFC8402 defines two standard SR mechanisms: SR-MPLS, which is based on the MPLS (Multi-Protocol Label Switching) forwarding plane, and SRv6, which is based on the IPv6 (Internet Protocol Version 6) forwarding plane. SRv6 can be directly implemented based on the IPv6 extension routing header, realizing the integration of IP (Internet Protocol) forwarding and tunneling forwarding without additional encapsulation. SRv6 also uses a 128-bit format SID (Segment ID), the same as IPv6 addresses, and divides the SID into two parts, a locator and a function, enabling flexible network and mixed-service programming, which has led to widespread industry recognition.

[0004] However, the SRv6 method uses a SID list consisting of a series of 128-bit SIDs to describe a service route, which causes the problem of excessive header overhead. To solve this problem, the industry has proposed various Segment Routing Header (SRH) compression solutions, such as the uSID method (draft-filsfils-spring-net-pgm-extension-srv6-usid-02) and the regular compressed SID (C-SID) method (draft-li-spring-compressed-srv6-np-00).

[0005] In the SRv6 method, the forwarding node (transit) only needs to process normal IPv6 forwarding, and the endpoint node (endpoint) needs to process the SRH header. However, the SRH header compression method mentioned above requires all endpoint nodes to use the compressed SID format (the C-SID method allows the final hop endpoint node to use the uncompressed format, but does not allow intermediate nodes to use the uncompressed format). In other words, endpoint nodes participating in IPv6 message forwarding must have the ability to support compressed SIDs. This places very high demands on the network's SID planning in relation to the SRH processing capabilities of network nodes, and to some extent limits the spread and application of SRv6. Summary of the Invention [Means for solving the problem]

[0006] In a first aspect, an embodiment of the present disclosure provides a segment routing header compression method, the segment routing header compression method including: configuring a compressed segment identifier or an uncompressed segment identifier in each node on a segment routing path; configuring a compressed segment identifier additionally having a function of performing segment identifier type conversion for a segment identifier indicated by a remaining number of segments in a critical node in the segment routing path, where the critical node is one of two adjacent nodes to which a different type of segment identifier has already been configured and to which a compressed segment identifier has already been configured; generating a segment list including the already-configured compressed segment identifier and the already-configured uncompressed segment identifier; and generating a segment routing header of a service message, where the segment routing header of the service message includes the segment list and a routing type field for indicating a format of a segment routing header, and the format of the segment routing header is compatible with the format of the compressed segment identifier.

[0007] In a second aspect, an embodiment of the present disclosure further provides a service processing method applied to a node on a segment routing path, wherein a compressed segment identifier or an uncompressed segment identifier is configured in each node on the segment routing path, a compressed segment identifier additionally having a function of performing segment identifier type conversion on a segment identifier indicated by a number of remaining segments is configured in a critical node on the segment routing path, the critical node being one of two adjacent nodes to which different types of segment identifiers have already been configured and to which a compressed segment identifier has already been configured, the service processing method including: obtaining a segment list including the already-configured compressed segment identifier and the already-configured uncompressed segment identifier and a routing type field for indicating a format of the segment routing header from a segment routing header of a received service message; processing a current segment identifier in the segment list and changing the number of remaining segments according to the routing type field; if the current node is a critical node, performing segment identifier type conversion on the segment identifier indicated by the number of remaining segments; and forwarding the service message including the segment identifier type indicated by the number of remaining segments to a next-hop node.

[0008] In a third aspect, an embodiment of the present disclosure further provides a segment routing header compression device, comprising: a setting module; a first generating module; and a second generating module. The setting module is configured to set a compressed segment identifier or an uncompressed segment identifier to each node on a segment routing path, and to set a compressed segment identifier, which additionally has a function of performing segment identifier type conversion on a segment identifier indicated by a remaining number of segments, to a critical node in the segment routing path, the critical node being a node to which a compressed segment identifier has already been set, of two adjacent nodes to which different types of segment identifiers have already been set. The first generating module is configured to generate a segment list including the already-set compressed segment identifiers and the already-set uncompressed segment identifiers. The second generating module is configured to generate a segment routing header of a service message, the segment routing header of the service message including the segment list and a routing type field for indicating a format of the segment routing header, and the format of the segment routing header is compatible with the format of the compressed segment identifier.

[0009] In a fourth aspect, an embodiment of the present disclosure further provides a service processing device applied to a node of a segment routing path, wherein a compressed segment identifier or an uncompressed segment identifier is configured in each node on the segment routing path, a compressed segment identifier that additionally has a function of performing segment identifier type conversion on a segment identifier indicated by a remaining segment number is configured in a critical node on the segment routing path, and the critical node is a node to which a compressed segment identifier has already been configured among two adjacent nodes to which different types of segment identifiers have already been configured, and the service processing device comprises: an acquisition module, a processing module, a conversion module, and a forwarding module, and the acquisition module converts a segment identifier of a received service message into a compressed segment identifier. and a routing type field for indicating a format of the segment routing header from the service message, the routing module is configured to obtain a segment list including a previously set compressed segment identifier and a previously set uncompressed segment identifier, and a routing type field for indicating a format of the segment routing header, the processing module is configured to process a current segment identifier in the segment list and change a remaining segment number according to the routing type field, the conversion module is configured to perform segment identifier type conversion on the segment identifier pointed to by the remaining segment number if the current node is a critical node, and the forwarding module is configured to forward the service message including the segment identifier type pointed to by the remaining segment number to a next-hop node.

[0010] In a fifth aspect, an embodiment of the present disclosure further provides a computing device, the computing device including one or more processors and a storage device, wherein the storage device stores one or more programs, and the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the segment routing header compression method or the service processing method as provided in the aforementioned embodiments.

[0011] In a sixth aspect, the embodiments of the present disclosure further provide a computer-readable medium storing a computer program, which, when executed, realizes the segment routing header compression method or the service processing method as provided in the above-mentioned embodiments. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a flowchart of a segment routing header compression method provided by an embodiment of the present disclosure. [Figure 2] 1 is a flowchart of a service processing method provided by an embodiment of the present disclosure. [Figure 3] 10 is a flowchart of modifying the number of remaining segments according to a routing type field provided by an embodiment of the present disclosure; [Figure 4] FIG. 1 is a network topology diagram provided by specific example 1 of the present disclosure. [Figure 5] FIG. 10 is a schematic diagram of an SRH structure in the A->Z service message transmission direction provided by specific example 1 of the present disclosure. [Figure 6] FIG. 10 is a schematic diagram of an SRH structure in the Z->A service message transmission direction provided by specific example 1 of the present disclosure. [Figure 7] FIG. 10 is a schematic diagram of the service processing process in the A->Z service message transmission direction provided by specific example 1 of the present disclosure. [Figure 8] FIG. 10 is a schematic diagram of a service processing process in the Z->A service message transmission direction provided by specific example 1 of the present disclosure. [Figure 9] FIG. 10 is a network topology diagram provided by specific example 2 of the present disclosure. [Figure 10] A schematic diagram of the SRH_Ext structure of the A->Z service message transmission direction provided by specific example 2 of the present disclosure. [Figure 11]A schematic diagram of the SRH_Ext structure in the Z->A service message transmission direction provided by specific example 2 of the present disclosure. [Figure 12] FIG. 10 is a schematic diagram of a service processing process in the A->Z service message transmission direction provided by specific example 2 of the present disclosure. [Figure 13] FIG. 10 is a schematic diagram of a service processing process in the Z->A service message transmission direction provided by specific example 2 of the present disclosure. [Figure 14] FIG. 10 is a schematic diagram of an SRH structure in the A->Z service message transmission direction provided by specific example 3 of the present disclosure. [Figure 15] FIG. 10 is a schematic diagram of an SRH structure in the Z->A service message transmission direction provided by specific example 3 of the present disclosure. [Figure 16] FIG. 10 is a schematic diagram of a service processing process in the A->Z service message transmission direction provided by specific example 3 of the present disclosure. [Figure 17] FIG. 10 is a schematic diagram of a service processing process in the Z->A service message transmission direction provided by specific example 3 of the present disclosure. [Figure 18] FIG. 2 is a structural schematic diagram of a segment routing header compression device provided by an embodiment of the present disclosure; [Figure 19] FIG. 2 is a structural schematic diagram of a service processing device provided by an embodiment of the present disclosure; DETAILED DESCRIPTION OF THE INVENTION

[0013]

[0023] Exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings, but the exemplary embodiments may be embodied in different forms and the embodiments described herein should not be construed as limiting. Rather, the purpose of providing these embodiments is to make this disclosure as thorough and complete as possible, and to fully convey the scope of the disclosure to those skilled in the art.

[0014] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0015] The terms used herein are used only to describe particular embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a," "an," and "the" are intended to include at least one and do not exclude a plurality, unless the context clearly indicates otherwise. It should be understood that when the terms "comprising" and / or "consisting of" are used herein, they indicate the presence of certain features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or possible addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof.

[0016] The embodiments described herein may be described with reference to plan views and / or cross-sectional views, using idealized schematic diagrams of the present disclosure. Therefore, exemplary illustrations may be changed depending on manufacturing techniques and / or tolerances. Therefore, the embodiments of the present invention are not limited to the embodiments shown in the accompanying drawings, but also include modified embodiments formed based on the manufacturing process.

[0017] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as those commonly understood by those skilled in the art. Terms defined in common dictionaries should be interpreted as meanings consistent with the meanings in the context of the relevant technology and this disclosure, and should not be interpreted as having ideal or overly formal meanings unless expressly limited herein.

[0018] The embodiment of the present disclosure provides a segment routing header compression method, as shown in FIG. 1, including the following steps S11 to S13.

[0019] In step S11, a compressed segment identifier or an uncompressed segment identifier is set to each node on the segment routing path, and a compressed segment identifier that additionally has the function of performing segment identifier type conversion for the segment identifier indicated by the remaining number of segments (Segments Lef,SL) is set to a critical node in the segment routing path.

[0020] A critical node is a node to which a compressed segment identifier has already been set among two adjacent nodes to which different types of segment identifiers have already been set. In an embodiment of the present disclosure, the types of segment identifiers include compressed segment identifiers and non-compressed segment identifiers. For example, if a segment routing path is node A-node B-node C, compressed segment identifiers are set to node A and node B, and a non-compressed segment identifier is set to node C. Since the segment identifier types of node B and node C are different and a compressed segment identifier is set to node B, node B is a critical node in the segment routing path.

[0021] In this step, the segment routing header compression device sets either a compressed segment identifier or an uncompressed segment identifier to each node on the segment routing path, and sets a compressed segment identifier that additionally has a function of performing segment identifier type conversion for the segment identifier pointed to by SL (number of remaining segments) to a critical node among them. That is, the compressed segment identifier includes two types: one is a compressed segment identifier set to a non-critical node, and this type of compressed segment identifier can be realized using a conventional compressed segment identifier; and the other is a compressed segment identifier set to a critical node, and this type of compressed segment identifier has a function of performing segment identifier type conversion for the segment identifier pointed to by SL, and can be realized, for example, by defining a function field of this segment identifier.

[0022] Once the segment routing header compressor sets the compressed segment identifiers and uncompressed segment identifiers to the corresponding nodes, each node can spread the compressed segment identifiers and uncompressed segment identifiers throughout the SR domain via an IGP (Interior Gateway Protocol).

[0023] In step S12, a segment list including the already set compressed segment identifiers and the already set uncompressed segment identifiers is generated.

[0024] In this step, the source node of the segment routing path generates a segment list by calculation, and the segment list is filled with the compressed segment identifiers or uncompressed segment identifiers of each node according to the needs of network programming. In the segment list, the segment identifiers of each node on the segment routing path are arranged in the order of service message transmission.

[0025] In step S13, generate a segment routing header for the service message, where the segment routing header for the service message includes a segment list and a routing type field for indicating a format of the segment routing header, and the format of the segment routing header conforms to the format of the compressed segment identifier.

[0026] In this step, the segment list is carried in a segment routing header (SRH) of the service message, and the segment routing header of the service message further includes a routing type field, which indicates the format of the segment routing header, and the format of the segment routing header conforms to the format of the compressed segment identifier. Different segment routing header formats define different methods for modifying the SL, which will be described in detail later.

[0027] In a segment routing header compression method provided by an embodiment of the present disclosure, a compressed segment identifier or an uncompressed segment identifier is configured in each node on a segment routing path, a compressed segment identifier additionally having a function of performing segment identifier type conversion on a segment identifier indicated by an SL is configured in a critical node that is one of two adjacent nodes to which a different type of segment identifier has already been configured and to which a compressed segment identifier has already been configured, a segment list including the already configured compressed segment identifier and the uncompressed segment identifier is generated, and a segment routing header of a service message is generated, the segment routing header of the service message including a segment list and a routing type field for indicating a format of the segment routing header, the format of the segment routing header conforming to the format of the compressed segment identifier. By performing segment identifier type conversion and defining a segment routing header format conforming to the format of the compressed segment identifier, the embodiment of the present disclosure can realize mixed networking and mixed programming of nodes to which compressed segment identifiers are configured and nodes to which uncompressed segment identifiers are configured, thereby enabling SRv6 to be applied to more complex networking environments and advantageous for accelerating the practical application and deployment of SRv6 in existing networks.

[0028] In some embodiments, the critical node is a node that has already been configured with a compressed segment identifier and has already been configured with an uncompressed segment identifier at its next hop node, for example, if the segment routing path is node A-node B-node C and the service message transmission path is ABC, node A and node B are configured with compressed segment identifiers and node C is configured with an uncompressed segment identifier, so node B is the critical node. In this case, the function that performs segment identifier type conversion on the segment identifier pointed to by SL is a first conversion function, and the first conversion function is a function that converts the type of the segment identifier pointed to by SL into an uncompressed segment identifier.

[0029] In some embodiments, the critical node is a node to which a compressed segment identifier has already been set and a non-compressed segment identifier has already been set in a previous hop node, for example, if a segment routing path is node A-node B-node C and a service message transmission path is CBA, node A and node B are set with compressed segment identifiers and node C is set with a non-compressed segment identifier, so node B is the critical node. In this case, the function that performs segment identifier type conversion on the segment identifier pointed to by SL is a second conversion function, and the second conversion function is a function that converts the type of the segment identifier pointed to by SL into a compressed segment identifier.

[0030] In some embodiments, the segment routing header of the service message may further include a Flag field indicating the type of segment identifier pointed to by the SL, for example, a value of 1 in the Flag field indicates that the segment identifier pointed to by the current SL is a compressed segment identifier, and a value of 0 in the Flag field indicates that the segment identifier pointed to by the current SL is a non-compressed segment identifier.

[0031] The first conversion function includes changing the value of a Flag field in a segment routing header of the received service message to a value representing an uncompressed segment identifier (i.e., Flag=0). That is, the first conversion function is defined as End.uzip and is configured to realize a conversion process from a compressed segment identifier to an uncompressed segment identifier, and its processing content includes changing the Flag flag and changing the SL to indicate the uncompressed segment identifier. Note that the processing content of End.uzip may further include an End operation of the compressed segment identifier itself, and different compressed segment identifiers have different End operation methods. That is, the embodiment of the present disclosure may be compatible with compression methods of different segment identifiers.

[0032] The second conversion function includes changing the value of a Flag field in the segment routing header of the received service message to a value representing a compressed segment identifier (i.e., Flag=1). That is, the second conversion function is defined as End.zip and is configured to realize a conversion process from an uncompressed segment identifier to a compressed segment identifier, and its processing content includes changing the Flag flag and changing the SL to indicate the compressed segment identifier. Note that the processing content of End.zip may further include an End operation of the compressed segment identifier itself, and different End operation methods exist for different compressed segment identifiers. That is, the embodiment of the present disclosure may be compatible with compression methods of different segment identifiers.

[0033] In some embodiments, the value of the routing type field is a first predetermined value, for example, Routing type=6, and accordingly the segment routing header of the service message further includes an extension (SRH_Ext) field, which represents a first segment routing header format, and performs a function of decrementing the value of SL by n after processing one compressed segment identifier is completed, and a function of decrementing the value of SL by m after processing one uncompressed segment identifier is completed, where n is the ratio between the length of the compressed segment identifier and the length of the shortest supported compressed segment identifier, and n is a positive integer, and m is the ratio between the length of the uncompressed segment identifier and the length of the shortest supported compressed segment identifier, and m is a positive integer.

[0034] That is, the segment routing header of a service message can use a new field defined as SRH_Ext, which supports mixed programming of compressed and uncompressed segment identifiers, and thus programming of compressed segment identifiers of different lengths. In this case, the SL operation is redefined depending on the length of the shortest compressed segment identifier. For example, if the shortest supported compressed segment identifier length is 16 bits, the SRH_Ext field defines the following functionality:

[0035] After processing of the 16-bit compressed segment identifier is complete, the End operation decrements SL by 1.

[0036] After processing of the 32-bit compressed segment identifier is complete, the End operation decrements SL by 2.

[0037] After processing of the 64-bit compressed segment identifier is complete, the End operation decrements SL by 4.

[0038] After processing of one uncompressed segment identifier (the length of one uncompressed segment identifier is 128 bits) is completed, SL is decremented by 8 by the End operation.

[0039] In some embodiments, the value of the Routing Type field is a second predetermined value, for example, Routing type=4. In this case, the segment routing header uses the conventional Routing Type field as is, but the function of the Routing Type field needs to be redefined to accommodate both compressed and uncompressed segment identifiers. Specifically, the Routing Type field represents a second segment routing header format, where p compressed segment identifiers occupy the bits of the length of t uncompressed segment identifiers, where t is a positive integer, and p is a rounded value of the ratio of the length of one uncompressed segment identifier to the length of one compressed segment identifier. If the sum of the lengths of the p compressed segment identifiers is less than the length of the t uncompressed segment identifiers, the remaining length is filled with reserved bytes. In this case, the Routing Type field performs the function of decrementing SL by 1 after processing all compressed segment identifiers within the length of one uncompressed segment identifier is completed. Note that the Routing Type field can also perform the function of decrementing SL by 1 after processing one uncompressed segment identifier is completed, according to the conventional definition.

[0040] That is, when Routing type=4, SL still represents the number of segment identifiers within the length (128 bits) of one uncompressed segment identifier. When compressed segment identifiers are used in the segment routing header of a service message, multiple compressed segment identifiers must be combined to occupy 128 bits. If they cannot occupy an exact integer multiple of 128 bits (the integer is t, where t is 1 or greater), a reserved field is filled and added to make it an integer multiple of 128 bits. After processing of compressed segment identifiers is complete, SL is decremented by 1 after processing of all compressed segment identifiers within one 128-bit region is completed. After processing of uncompressed segment identifiers is complete, SL is decremented by 1 with the End operation.

[0041] When processing compressed segment identifiers, it is necessary to determine whether or not processing of all compressed segment identifiers within one 128-bit block has been completed before deciding whether or not to change the value of SL.

[0042] In some embodiments, for example, compressed segment identifiers are compressed using the uSID (draft-filsfils-spring-net-pgm-extension-srv6-usid-02) method. In this case, completing the processing of all compressed segment identifiers within the length of one uncompressed segment identifier means that the bits following the currently processed segment identifier in the segment list are all zero.

[0043] In some embodiments, for example, compressed segment identifiers are compressed using the C-SID (draft-li-spring-compressed-srv6-np-00) method. In this case, a counter (Sub_SL) field for recording the number of unprocessed compressed segment identifiers may be further provided in the segment routing header or segment list of the service message. Each time processing of one compressed segment identifier is completed, the value of the counter field is decremented by 1, and the initial value of the counter field is p (p is the rounded value of the ratio between the length of one uncompressed segment identifier and the length of one compressed segment identifier). In this case, completion of processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the value of the counter field being zero.

[0044]

[0023] The embodiments of the present disclosure further provide a service processing method applied to nodes on a segment routing path, in which a compressed segment identifier or an uncompressed segment identifier is configured to each node on the segment routing path, a compressed segment identifier that additionally has a function of performing segment identifier type conversion for a segment identifier indicated by an SL is configured to a critical node on the segment routing path, and the critical node is a node to which a compressed segment identifier has already been configured, of two adjacent nodes to which different types of segment identifiers have already been configured. As shown in Figure 2, the service processing method includes the following steps S21 to S24.

[0045] In step S21, a segment list including already set compressed segment identifiers and already set uncompressed segment identifiers and a routing type field for indicating the format of the segment routing header are obtained from the segment routing header of the received service message.

[0046] Before forwarding the service message, a segment list including compressed segment identifiers and uncompressed segment identifiers is generated by a segment routing header compression device, and the segment list is carried in the segment routing header of the service message. In this step, after receiving the service message sent by the previous hop node, a node on the segment routing path obtains the segment list from the segment routing header of the service message and obtains a routing type field for indicating the format of the segment routing header.

[0047] In step S22, the current segment identifier in the segment list is processed and the SL is changed according to the routing type field.

[0048] In this step, the service processing device processes the current segment identifier in the segment list, and the segment identifier is a compressed segment identifier or an uncompressed segment identifier. Since different routing types define different methods for changing the SL after processing a segment identifier, it is necessary to determine the routing type and change the SL according to the routing type. The SL change methods for different routing types will be described in detail later with reference to Figure 3.

[0049] In step S23, if the current node is a critical node, a segment identifier type conversion is performed on the segment identifier pointed to by SL.

[0050] The segment identifier type includes a compressed segment identifier and an uncompressed segment identifier, and converting the segment identifier type includes converting a compressed segment identifier to an uncompressed segment identifier or converting an uncompressed segment identifier to a compressed segment identifier.

[0051] It should be understood that if the current node is a non-critical node, the function defined for the segment identifier (which may be either a compressed segment identifier or an uncompressed segment identifier) ​​set in the current node is executed, and there is no need to perform segment identifier type conversion for the segment identifier pointed to by SL.

[0052] In step S24, the service message containing the segment identifier type pointed to by SL is forwarded to the next hop node.

[0053] In this step, the service processing device includes the converted segment identifier type obtained in step S23 in the service message and transfers the service message to the next hop node.

[0054] In a service processing method provided by an embodiment of the present disclosure, a segment list including a pre-configured compressed segment identifier and a pre-configured uncompressed segment identifier and a routing type field for indicating the format of the segment routing header are obtained from the segment routing header of a received service message, a current segment identifier in the segment list is processed, an SL is changed according to the routing type field, and if the current node is a critical node, a segment identifier type conversion is performed on the segment identifier pointed to by the SL, and the service message including the segment identifier type pointed to by the SL is forwarded to the next-hop node. According to the embodiment of the present disclosure, by performing segment identifier type conversion on the segment identifier pointed to by the SL in the critical node and changing the SL according to the routing type field, it is possible to realize mixed networking and mixed programming of nodes configured with compressed segment identifiers and nodes configured with uncompressed segment identifiers, which enables SRv6 to be applied to more complex networking environments and is advantageous for accelerating the practical application and deployment of SRv6 in existing networks.

[0055] In some embodiments, the critical node is a node to which a compressed segment identifier has already been set and a next-hop node is a node to which an uncompressed segment identifier has already been set. In this case, performing the segment identifier type conversion (i.e., step S23) on the segment identifier pointed to by the SL includes changing the type of the segment identifier pointed to by the SL to an uncompressed segment identifier. That is, in the message transmission direction, the previous-hop node of the critical node is a node to which a compressed segment identifier has already been set, and the next-hop node of the critical node is a node to which an uncompressed segment identifier has already been set.

[0056] In some embodiments, the critical node is a node to which a compressed segment identifier has already been set and a previous-hop node is a node to which an uncompressed segment identifier has already been set. In this case, performing the segment identifier type conversion (i.e., step S23) on the segment identifier pointed to by the SL includes changing the type of the segment identifier pointed to by the SL to a compressed segment identifier. That is, in the message transmission direction, the previous-hop node of the critical node is a node to which an uncompressed segment identifier has already been set, and the next-hop node of the critical node is a node to which a compressed segment identifier has already been set.

[0057] In some embodiments, the function of converting the segment identifier type for the segment identifier pointed to by the SL can be realized by providing a flag field. Specifically, the segment routing header of the service message further includes a flag field for indicating the type of the segment identifier pointed to by the SL, and the segment identifier type includes compressed segment identifiers and uncompressed segment identifiers. For example, it can be defined that Flag=0 indicates an uncompressed segment identifier and Flag=1 indicates a compressed segment identifier.

[0058] Accordingly, in step S23, before performing segment identifier type conversion on the segment identifier pointed to by SL, it further includes obtaining a flag field from the segment routing header of the service message.

[0059] Accordingly, in the case where the critical node is a node that already has a compressed segment identifier set and the next hop node is a node that already has an uncompressed segment identifier set, changing the type of segment identifier pointed to by the SL to an uncompressed segment identifier includes changing the value of the flag field to a value that represents an uncompressed segment identifier, for example, changing the value of the flag field to 0.

[0060] Accordingly, in the case where the critical node is a node that already has a compressed segment identifier set and the previous hop node is a node that already has a non-compressed segment identifier set, changing the type of segment identifier pointed to by the SL to a compressed segment identifier includes changing the value of the flag field to a value that represents a compressed segment identifier, for example, changing the value of the Flag field to 1.

[0061] In the service message forwarding process, after the segment identifier processing is completed, the SL needs to be changed. In the embodiment of the present disclosure, the segment routing header format is defined in the routing type field, and the SL change method in different segment routing header formats is defined. The SL change method in different segment routing header formats will be described in detail below with reference to FIG. 3.

[0062] In some embodiments, as shown in FIG. 3, modifying the SL according to the routing type field (ie, step S23) includes the following steps S231 to S233.

[0063] In step S231, determine the segment routing header format based on the routing type field; if the segment routing header format is the first segment routing header format, execute step S232; if the segment routing header format is the second segment routing header format, execute step S233.

[0064] In some embodiments, the segment routing header format can be determined based on the value of the routing type field. When the value of the routing type field is a first predetermined value, the segment routing header format is considered to be a first segment routing header format, and when the value of the routing type field is a second predetermined value, the segment routing header format is considered to be a second segment routing header format. For example, the first predetermined value may be 6 and the second predetermined value may be 4. The value of the routing type field being the first predetermined value means that the segment routing header of the service message further includes an extension (SRH_Ext) field, so that the SL is changed according to the method defined by the SRH_Ext field. The value of the routing type field being the second predetermined value means that the SL is still changed according to the method defined by the routing type field (however, the SL change method defined by the routing type field in the embodiments of the present disclosure is different from the conventional SL change method).

[0065] In step S232, after processing one compressed segment identifier is completed, the value of SL is subtracted by n, where n is the ratio between the length of the compressed segment identifier and the length of the shortest supported compressed segment identifier, and n is a positive integer; and after processing one uncompressed segment identifier is completed, the value of SL is subtracted by m, where m is the ratio between the length of the uncompressed segment identifier and the length of the shortest supported compressed segment identifier, and m is a positive integer.

[0066] In this step, when Routing type=6, the operation of changing SL based on the length of the shortest compressed segment identifier is redefined as follows, for example: If the length of the shortest supported compressed segment identifier is 16 bits, after processing of a 16-bit compressed segment identifier is completed, the End operation subtracts SL by 1 (n=16 / 16=1). After processing of a 32-bit compressed segment identifier is completed, the End operation subtracts SL by 2 (n=32 / 16=2). After processing of a 64-bit compressed segment identifier is completed, the End operation subtracts SL by 4 (n=64 / 16=4). Also, after processing of a 128-bit uncompressed segment identifier is completed, the End operation subtracts SL by 8 (n=128 / 16=8).

[0067] It should be understood that to ensure that the check is performed accurately, the Last Entry field in the segment routing header should be defined accordingly, and that when checking, SL should also be calculated as a multiple of the length of the shortest compressed segment identifier supported (e.g., 16 bits).

[0068] In step S233, after all compressed segment identifiers within the length of one uncompressed segment identifier have been processed, SL is decremented by one.

[0069] In the second segment routing header format, p compressed segment identifiers occupy the bits of t uncompressed segment identifiers, where t is a positive integer and p is the rounded ratio of the length of one uncompressed segment identifier to the length of one compressed segment identifier. If the sum of the lengths of p compressed segment identifiers is less than the length of t uncompressed segment identifiers, the remaining length is filled with reserved bytes. That is, when Routing type=4, SL still represents the number of segment identifiers within the length (128 bits) of one uncompressed segment identifier. When compressed segment identifiers are used in the segment routing header of a service message, multiple compressed segment identifiers must be combined to occupy 128 bits. If they cannot occupy an exact integer multiple of 128 bits (the integer is t, where t is 1 or greater), the reserved field is filled and added to make it an integer multiple of 128 bits. In this case, after processing of the compressed segment identifiers is completed, SL is decremented by 1.

[0070] In this step, the value of SL is decremented by 1 after processing of one uncompressed segment identifier is completed.

[0071] In an embodiment of the present disclosure, when processing compressed segment identifiers, it is necessary to determine whether processing of all compressed segment identifiers within one 128-bit range has been completed before deciding whether to change the value of SL.

[0072] In some embodiments, for example, for a compressed segment identifier compressed using the uSID method, it can be determined whether processing of all compressed segment identifiers within 128 bits has been completed by determining the remaining bits. In this case, the above-mentioned "processing of all compressed segment identifiers within the length of one uncompressed segment identifier" means that the bits following the currently processed segment identifier in the segment list are all zero.

[0073] In some embodiments, for example, for compressed segment identifiers compressed using the C-SID method, a counter may be provided to determine whether processing of all compressed segment identifiers within 128 bits has been completed. Specifically, a counter (Sub_SL) field for recording the number of unprocessed compressed segment identifiers is provided in the segment routing header or segment list of the service message, and the value of Sub_SL is decremented by 1 each time processing of one compressed segment identifier is completed, with the initial value of Sub_SL being p. In this case, completion of processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the value of the counter field being zero.

[0074] Note that the values ​​of Sub_SL and SL do not necessarily become 0 at the same time. When processing a compressed segment identifier, it is possible that SL has already become 0 but Sub_SL is not 0. This means that the last 128 bits in the segment list have been processed, but there are still compressed segment identifiers that have not been processed, so it should not be treated as the final hop.

[0075] To clearly explain the proposed embodiments of the present disclosure, the following will describe the proposed embodiments of the present disclosure in detail using three specific examples respectively.

[0076] Example 1 The networking topology of Example 1 is shown in Figure 4. One VPN4 service exists, and it is necessary to create an SRv6 route for ABDFMZ, which involves mixed programming of compressed and uncompressed SID nodes. The AG node is configured with a 32-bit compressed segment identifier, and compressed using the uSid compression method. The common prefix (uSID Block) of the compressed SID is 32 bits, and each compressed segment identifier is 32 bits. Therefore, by excluding the uSID block from one 128-bit block, the compressed SIDs of three SRv6 nodes can be represented. Nodes M, N, and Z are configured with a 128-bit uncompressed SID.

[0077] In the SRH compression process, the following definitions are made:

[0078] (1) In the SRH, Flag=1 indicates that the current SID is a compressed SID, and Flag=0 indicates that the current SID is a non-compressed SID.

[0079] (2) Define the first conversion function End.uzip (encoded as 0x77) of the critical node between compressed SID and uncompressed SID to convert the type of segment identifier pointed to by SL from compressed SID to uncompressed SID. The code is as follows: If (SRH.Flag == 1) Set SRH.Flag=0 Decrement SL by 1 Update IPv6 DA with Segment_List[SL] Forward the packet to the new DA

[0080] (3) Define the second conversion function End.zip (encoded as 0x78) of the critical node between uncompressed SID and compressed SID to convert the type of segment identifier pointed to by SL from uncompressed SID to compressed SID. The code is as follows: If (SRH.Flag == 0) Set SRH.Flag=1 Decrement SL by 1 Update IPv6 DA with Segment_List[SL] Forward the packet to the new IPv6 DA

[0081] Figure 5 is a schematic diagram of the SRH structure in the A->Z service message transmission direction. At node A, the SRH shown in Figure 5 uses the VPN4 service transport path indicated by ABDFMZ. At node F, the SRH uses F:77, which indicates that the End.uzip operation is performed to switch from compressed SID to uncompressed SID.

[0082] Figure 6 is a schematic diagram of the SRH structure in the Z->A service message transmission direction. At the Z node, the VPN4 service transfer path is used, where the SRH shown in Figure 6 indicates ZMFDBA. At the F node, a 128-bit uncompressed SID is set and F:78 is used, which indicates that the End.zip operation is performed to switch from the uncompressed SID to the compressed SID.

[0083] In this specific example 1, Routing type=4 indicates that the SRH format is the second segment routing header format, that is, the routing type field in the SRH is compatible with the conventional SRH. In the End operation of compressed SID, when processing of all compressed SIDs within one 128-bit range (i.e., compressed SIDs compressed using the uSID method) is completed, SL is further decremented by 1, as shown in the following code: IF (SRH.Flag == 1) IF DA[64..95] != 0 / / There are unprocessed uSIDs remaining Copy DA[64..127] into DA[32..95] Set DA[96..127] to 0x0000 Forward the packet to the new IPv6 DA ELSE IF (DA[64..95] == 0) and SL>0 / / Processing of all uSIDs within the current 128 bits has been completed, so extract and process the compressed SID within the next 128 bits. Decrement SL by 1 Update IPv6 DA with Segment_List[SL] Forward the packet to the new IPv6 DA ELSE Report error / / If there are no next 128 bits, the service should be processed instead of the End operation and an error should be reported.

[0084] The service processing flow for the A->Z service message transmission direction is shown in Figure 7, the segment routing path is ABDFMZ, and the End.DX4 function is executed according to DA=20:02:Z:11::. The service processing flow for the Z->A service message transmission direction is shown in Figure 8, the segment routing path is ZMFDBA, and the End.DX4 function is executed according to DA=20:02:A:11::.

[0085] Example 2 The networking topology of Example 2 is shown in Figure 9. An L2VPN service exists and it is necessary to create an SRv6 route for ABDFMZ with mixed programming of compressed and uncompressed SID nodes. The AG node uses a 32-bit compressed SID, while the M, N, and Z nodes are configured with 128-bit uncompressed SIDs. In this example, the SRH uses the second segment routing header format, i.e., the newly defined SRH_Ext field, i.e., Routing Type=6, is used, and the SRH_Ext is not involved in compatibility processing with the conventional SRH header.

[0086] In the SRH compression process, the following definitions are made:

[0087] (1) In SRH_Ext, define Flag=1 to indicate that the current SID is a compressed SID, and Flag=0 to indicate that the current SID is a non-compressed SID.

[0088] (2) Define the first conversion function End.uzip (encoded as 0x77) of the critical node between compressed SID and uncompressed SID to convert the type of segment identifier pointed to by SL from compressed SID to uncompressed SID. The code is as follows: IF (SRH.Flag == 1) Set SRH.Flag=0 IF (SL>=10) Decrement SL by 2 / / Assuming the shortest 16-bit compressed SID is supported, since our compressed SID is 32 bits, we should decrement SL by 2 Update IPv6 DA with Segment_List[SL] / / Get the next uncompressed SID Forward the packet to IPv6 DA ELSE Report error / / Next hop is not an uncompressed SID, so report an error;

[0089] (3) Define the second conversion function End.zip (encoded as 0x78) of the critical node between uncompressed SID and compressed SID to convert the type of segment identifier pointed to by SL from uncompressed SID to compressed SID. The code is as follows: If (SRH.Flag == 0) Set SRH.Flag=1 IF SL>10 Decrement SL by 8 Update IPv6 DA with Segment_List[SL] / / Get the next compressed SID Forward the packet to the new IPv6 DA

[0090] Figure 10 is a schematic diagram of the SRH_Ext structure in the A->Z service message transmission direction. At node A, the L2VPN service forwarding path is used, where the SRH_Ext shown in Figure 10 indicates ABDFMZ. At node F, F:77 is used, which indicates that the End.uzip operation is performed to switch from compressed SID to uncompressed SID.

[0091] Figure 11 is a schematic diagram of the SRH_Ext structure in the Z->A service message transmission direction. At the Z node, the L2VPN service transfer path is used, where the SRH_Ext shown in Figure 11 indicates ZMFDBA, and at the F node, F:78 is used, which indicates that the End.zip operation is performed to switch from the uncompressed SID to the compressed SID.

[0092] This specific example 2 employs a new Routing type (6), so there is no need to consider compatibility with the conventional SRH process. Assuming that the minimum length of the compressed SID supported by the SRH_Ext is 16 bits, the compressed SID is 32 bits here, so the End operation of the compressed SID subtracts 2 from SL, while the End operation of the uncompressed SID subtracts 8 from SL.

[0093] The service processing flow for the A->Z service message transmission direction is shown in Figure 12, the segment routing path is ABDFMZ, and the End.DX2 function is executed according to DA=20:02:Z:15::. The service processing flow for the Z->A service message transmission direction is shown in Figure 13, the segment routing path is ZMFDBA, and the End.DX2 function is executed according to DA=20:02:A:15::.

[0094] Example 3 The networking topology of Example 3 is shown in Figure 9. An L2VPN service exists and it is necessary to create an SRv6 route for ABDFMZ with mixed programming of compressed and uncompressed SID nodes. The AG node uses a 32-bit compressed SID, while the M, N, and Z nodes are configured with 128-bit uncompressed SIDs. The difference between Example 3 and Example 2 is that the SRH in this example is the second segment routing header format, i.e., Routing Type=4, which is compatible with conventional SRH processing without adding any extra extension fields.

[0095] In the SRH compression process, the following definitions are made:

[0096] (1) In the SRH, Flag = 1 indicates that the current SID is a compressed SID, and Flag = 0 indicates that the current SID is an uncompressed SID. In this case, the Flag seen on the node of the uncompressed SID (e.g., M node) is 0, which is the same as the conventional SRH.

[0097] (2) Define the first conversion function End.uzip (encoded as 0x77) of the critical node between compressed SID and uncompressed SID to convert the type of segment identifier pointed to by SL from compressed SID to uncompressed SID. The code is as follows: IF(SRH.Flag == 1) Set SRH.Flag=0 IF (SL>0) Decrement SL by 1 Update IPv6 DA with Segment_List[SL] Forward the packet to the new DA ELSE Report error / / Report an error because it is the last SID and the conversion operation cannot be performed;

[0098] (3) Define the second conversion function End.zip (encoded as 0x78) of the critical node between uncompressed SID and compressed SID to convert the type of segment identifier pointed to by SL from uncompressed SID to compressed SID. The code is as follows: IF (SRH.Flag == 0) Set SRH.Flag=1 IF (SL>0) Decrement SL by 1 Set Sub_SL by Segment_List[SL] / / Determines the number of compressed SIDs it contains by determining the length of the last reserved byte within the 128 bits Update IPv6 DA with Segment_List[SL][Sub_SL] Forward the packet to the new IPv6 DA ELSE Report error / / This is the last SID, and the conversion operation cannot be performed; report an error.

[0099] Figure 14 is a schematic diagram of the SRH structure in the A->Z service message transmission direction. At the A node, the SRH shown in Figure 14 uses the L2VPN service forwarding path indicating ABDFMZ, and at the F node, F:77 is used, which indicates that the End.uzip operation is performed to switch from the compressed SID to the uncompressed SID.

[0100] Figure 15 is a schematic diagram of the SRH structure in the Z->A service message transmission direction. At the Z node, the SRH shown in Figure 15 uses the L2VPN service forwarding path indicating ZMFDBA. At the F node, the SRH is encoded to 128 bits and uses F:78, which indicates that the End.zip operation is performed to switch from the uncompressed SID to the compressed SID.

[0101] This specific example 3 adopts a method compatible with the conventional SRH, i.e., Routing type=4, and its compatible processing method includes the following: SL still represents a 128-bit SID number, and when a compressed SID is adopted in the SRH, multiple compressed SIDs are combined to obtain an integer multiple of 128 bits, and if the result of combining multiple compressed SIDs is not an integer multiple of 128 bits, reserved bytes must be filled to make it an integer multiple of 128 bits. For example, as shown in Figure 14, in the transmission direction of the A->Z service message, there are only three compressed SIDs in the segment list. In this case, to add one complete 128 bits, the remaining bits must be filled with all zeros.

[0102] When processing uncompressed SIDs, the SL is decremented by 1 with the End operation. On the other hand, when processing compressed SIDs, the SL is decremented by 1 only when all compressed SIDs within one 128-bit block have been processed. Sub_SL is provided to record the number of unprocessed compressed segment identifiers within 128 bits, and its code is as follows: IF (SRH.Flag == 1) IF Sub_SL > 0 / / There are currently unprocessed compressed SIDs remaining within 128 bits Update IPv6 DA with Segment_List[SL][Sub_SL] Decrement Sub_SL by 1 Forward the packet to the new IPv6 DA ELSE IF(Sub_SL) == 0 and (SL)>0 / / Processing of all compressed SIDs within the current 128 bits has been completed, so extract and process the compressed SIDs within the next 128 bits. Decrement SL by 1 Set Sub_SL by Segment_List[SL] Update IPv6 DA with Segment_List[SL][Sub_SL] Forward the packet to the new IPv6 DA ELSE Report error / / If there are no next 128 bits, the service should be processed instead of the End operation and an error should be reported.

[0103] When processing a compressed SID, it is possible that SL has already become 0 but Sub_SL is not 0. This means that the last 128 bits of the segment list have been processed, but there are still compressed SIDs that have not been processed, so in this case, it should not be treated as the final hop.

[0104] The service processing flow for the A->Z service message transmission direction is shown in Figure 16, the segment routing path is ABDFMZ, and the End.DX2 function is executed according to DA=20:02:Z:15::. The service processing flow for the Z->A service message transmission direction is shown in Figure 17, the segment routing path is ZMFDBA, and the End.DX2 function is executed according to DA=20:02:A:15::.

[0105] The embodiments of the present disclosure provide an SRH compression method that simultaneously supports the compressed SID format and the uncompressed SID format in the SRv6 SRH header, thereby enabling the SRv6 forwarding path to include both nodes represented by compressed SIDs and nodes represented by uncompressed SIDs, thereby expanding the scenarios in which SRv6 can be applied. A new flag field is defined to indicate whether the SID pointed to by SL in the SRH is a compressed SID or an uncompressed SID, and a new function is defined to realize conversion processing from compressed SID to uncompressed SID and from uncompressed SID to compressed SID in the SRv6 forwarding path.

[0106] Based on the same technical idea, an embodiment of the present disclosure further provides a segment routing header compression device, which, as shown in Fig. 18, includes a setting module 101, a first generating module 102, and a second generating module 103. The setting module 101 is configured to set a compressed segment identifier or an uncompressed segment identifier to each node on a segment routing path, and to set a compressed segment identifier, which additionally has a function of performing segment identifier type conversion on a segment identifier indicated by a remaining segment number (SL), to a critical node on the segment routing path, where the critical node is a node to which a compressed segment identifier has already been set, of two adjacent nodes to which a different type of segment identifier has already been set.

[0107] The first generating module 102 is configured to generate a segment list including the already set compressed segment identifiers and the already set uncompressed segment identifiers.

[0108] The second generating module 103 is configured to generate a segment routing header of a service message, the segment routing header of the service message including the segment list and a routing type field for indicating a format of the segment routing header, and the format of the segment routing header is compatible with a format of the compressed segment identifier.

[0109] In some embodiments, the critical node is a node that has already been configured with a compressed segment identifier and a next-hop node that has already been configured with an uncompressed segment identifier, and the function that performs segment identifier type conversion on the segment identifier pointed to by the remaining segments (SL) is a first conversion function, and the first conversion function is a function that converts the type of the segment identifier pointed to by SL into an uncompressed segment identifier.

[0110] In some embodiments, the critical node is a node that has already been configured with a compressed segment identifier and a node that has already been configured with an uncompressed segment identifier at a previous hop node, and the function that performs segment identifier type conversion on the segment identifier pointed to by the remaining segment number (SL) is a second conversion function, and the twenty-first conversion function is a function that converts the type of the segment identifier pointed to by SL into a compressed segment identifier.

[0111] In some embodiments, the segment routing header of the service message further includes a flags field to indicate the type of segment identifier to which the SL points, and the first conversion function includes changing the value of the flags field in the segment routing header of the received service message to a value representing an uncompressed segment identifier, and / or the second conversion function includes changing the value of the flags field in the segment routing header of the received service message to a value representing a compressed segment identifier.

[0112] In some embodiments, the segment routing header of the service message further includes an extension field, the extension field representing a first segment routing header format, and performs the following functions: after processing one compressed segment identifier is completed, decrementing the value of SL by n; and after processing one uncompressed segment identifier is completed, decrementing the value of SL by m, where n is a ratio between the length of the compressed segment identifier and the length of the shortest supported compressed segment identifier, n is a positive integer; and m is a ratio between the length of the uncompressed segment identifier and the length of the shortest supported compressed segment identifier, m is a positive integer.

[0113] In some embodiments, the routing type field represents a second segment routing header format, the second segment routing header format including p compressed segment identifiers occupying bits of a length of t uncompressed segment identifiers, where t is a positive integer, and p is a rounded value of the ratio of the length of one uncompressed segment identifier to the length of one compressed segment identifier, and if the sum of the lengths of the p compressed segment identifiers is less than the length of the t uncompressed segment identifiers, filling the remaining length with reserved bytes.

[0114] The routing type field performs a function of decrementing SL by 1 after all compressed segment identifiers within the length of one uncompressed segment identifier are processed.

[0115] In some embodiments, completing the processing of all compressed segment identifiers within the length of one uncompressed segment identifier as described above includes having all bits in the segment list following the currently processed segment identifier be all zeros.

[0116] In some embodiments, the segment routing header or the segment list of the service message further includes a counter field for recording the number of unprocessed compressed segment identifiers. Each time processing of one compressed segment identifier is completed, the value of the counter field is decremented by 1, and the initial value of the counter field is p. Completion of processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the value of the counter field being zero.

[0117] Based on the same technical idea, an embodiment of the present disclosure further provides a service processing device applied to a node on a segment routing path, wherein a compressed segment identifier or an uncompressed segment identifier is configured in each node on the segment routing path, and a compressed segment identifier that additionally has a function of performing segment identifier type conversion on a segment identifier indicated by a remaining segment number (SL) is configured in a critical node on the segment routing path, and the critical node is a node to which a compressed segment identifier has already been configured among two adjacent nodes to which different types of segment identifiers have already been configured. As shown in FIG. 19 , the service processing device includes an acquisition module 201, a processing module 202, a conversion module 203, and a forwarding module 204. The acquisition module 201 is configured to acquire a segment list including the already configured compressed segment identifiers and the already configured uncompressed segment identifiers and a routing type field for indicating the format of the segment routing header from the segment routing header of a received service message.

[0118] The processing module 202 is configured to process the current segment identifier in the segment list and modify the SL according to the routing type field.

[0119] The conversion module 203 is configured to perform a segment identifier type conversion on the segment identifier pointed to by the SL if the current node is a critical node.

[0120] The forwarding module 204 is configured to forward the service message containing the segment identifier type pointed to by the SL to a next-hop node.

[0121] In some embodiments, the critical node is a node that has already been configured with a compressed segment identifier and a next-hop node that has already been configured with an uncompressed segment identifier, and the conversion module 203 is configured to change the type of the segment identifier pointed to by the SL to an uncompressed segment identifier.

[0122] In some embodiments, the critical node is a node that has already been configured with a compressed segment identifier and a previous-hop node that has already been configured with an uncompressed segment identifier, and the conversion module 203 is configured to convert the type of the segment identifier pointed to by the SL into a compressed segment identifier.

[0123] In some embodiments, the segment routing header of the service message further includes a flag field to indicate the type of segment identifier to which the SL points.

[0124] The obtaining module 201 is further configured to obtain a flag field from a segment routing header of the service message before the conversion module 203 performs segment identifier type conversion on the segment identifier pointed to by the SL.

[0125] The processing module 202 is configured to change the value of the flag field to a value representing an uncompressed segment identifier and / or to change the value of the flag field to a value representing a compressed segment identifier.

[0126] In some embodiments, when the segment routing header is in a first segment routing header format, the processing module 202 is configured to decrement the value of SL by n after completing one compressed segment identifier processing, and to decrement the value of SL by m after completing one uncompressed segment identifier processing, where n is a ratio of the length of the compressed segment identifier to a length of the shortest supported compressed segment identifier, where n is a positive integer, and m is a ratio of the length of the uncompressed segment identifier to a length of the shortest supported compressed segment identifier, where m is a positive integer.

[0127] In some embodiments, the processing module 202 is configured, when the segment routing header is in a second segment routing header format, to subtract 1 from SL after processing of all compressed segment identifiers within the length of one uncompressed segment identifier is completed, where p compressed segment identifiers occupy bits of the length of t uncompressed segment identifiers, where t is a positive integer, and p is a rounded value of the ratio between the length of one uncompressed segment identifier and the length of one compressed segment identifier, and when the sum of the lengths of the p compressed segment identifiers is less than the length of the t uncompressed segment identifiers, to fill the remaining length with reserved bytes.

[0128] In some embodiments, completing the processing of all compressed segment identifiers within the length of one uncompressed segment identifier as described above includes having all bits in the segment list following the currently processed segment identifier be all zeros.

[0129] In some embodiments, the segment routing header or the segment list of the service message further includes a counter field for recording the number of unprocessed compressed segment identifiers. Each time processing of one compressed segment identifier is completed, the value of the counter field is decremented by 1, and the initial value of the counter field is p. Completion of processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the value of the counter field being zero.

[0130] An embodiment of the present disclosure further provides a computing device, the computing device including one or more processors and a storage device, wherein the storage device stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the segment routing header compression method as provided in the aforementioned embodiment.

[0131] An embodiment of the present disclosure further provides a computer-readable medium storing a computer program, which, when executed, implements the service processing method as provided in the above-described embodiment.

[0132] Those skilled in the art will understand that all or some steps of the methods disclosed above, and some or all functional modules / units within the apparatus, can be implemented as software, firmware, hardware, or a suitable combination thereof. In hardware embodiments, the division among the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical assemblies; for example, one physical assembly may have multiple functions, or one function or step may be performed cooperatively by several physical assemblies. Some or all of the physical assemblies may be implemented as software executed by a processor (e.g., a central processing unit, a digital signal processor, or a microprocessor), as hardware, or as an integrated circuit such as an application-specific integrated circuit. Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). Those skilled in the art will recognize that the term computer storage media includes volatile and non-volatile, removable and non-removable media, implemented in any method or technology for storing information (computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cartridges, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computer. Additionally, it will be known to those skilled in the art that communication media typically include computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any information delivery media.

[0133] Exemplary embodiments are disclosed herein, and although specific terms are used, they are not intended to be limiting and should be construed in a generic and descriptive sense. It will be apparent to those skilled in the art that, in some instances, unless expressly specified otherwise, features, characteristics, and / or elements described in connection with particular embodiments may be used alone or in combination with features, characteristics, and / or elements described in connection with other embodiments. Accordingly, those skilled in the art will recognize that various changes in form and detail may be made without departing from the scope of the present disclosure, as defined by the appended claims.

Claims

1. A compressed segment identifier or a non-compressed segment identifier is set to each node on a segment routing path, and a compressed segment identifier is set to a critical node in the segment routing path so that the critical node additionally has a function of performing segment identifier type conversion for a segment identifier indicated by the number of remaining segments, and the critical node is a node to which a compressed segment identifier has already been set, out of two adjacent nodes to which different types of segment identifiers have already been set; generating a segment list including the previously established compressed segment identifiers and the previously established uncompressed segment identifiers; generating a segment routing header of a service message, the segment routing header of the service message including the segment list and a routing type field for indicating a format of the segment routing header, the format of the segment routing header conforming to a format of the compressed segment identifier; A computer-implemented method for compressing a segment routing header, comprising:

2. The critical node is a node to which a compressed segment identifier has already been set and a next-hop node is a node to which an uncompressed segment identifier has already been set, the function that performs segment identifier type conversion on the segment identifier indicated by the remaining segment number is a first conversion function, and the first conversion function is a function that converts the type of the segment identifier indicated by the remaining segment number into an uncompressed segment identifier, and / or the critical node is a node to which a compressed segment identifier has already been set and a non-compressed segment identifier has already been set in a previous hop node, the function of performing segment identifier type conversion on the segment identifier indicated by the remaining segment number is a second conversion function, and the second conversion function is a function of converting the type of the segment identifier indicated by the remaining segment number into a compressed segment identifier; The segment routing header of the service message further includes a flag field for indicating the type of segment identifier to which the remaining segment number points; the first conversion function includes changing a value of a flags field in a segment routing header of the received service message to a value representing an uncompressed segment identifier, and / or the second conversion function includes changing a value of a flags field in a segment routing header of the received service message to a value representing a compressed segment identifier. The segment routing header compression method according to claim 1 .

3. the segment routing header of the service message further includes an extension field, the extension field represents a first segment routing header format, and performs the functions of: subtracting a value of a number of remaining segments by n after processing one compressed segment identifier is completed; and subtracting a value of a number of remaining segments by m after processing one uncompressed segment identifier is completed, where n is a ratio of a length of the compressed segment identifier to a length of a shortest supported compressed segment identifier, n is a positive integer; and m is a ratio of a length of an uncompressed segment identifier to a length of a shortest supported compressed segment identifier, m is a positive integer; or the routing type field represents a second segment routing header format, the second segment routing header format including p compressed segment identifiers occupying bits of a length of t uncompressed segment identifiers, where t is a positive integer and p is a rounded value of the ratio between the length of one uncompressed segment identifier and the length of one compressed segment identifier, and filling the remaining length with reserved bytes when the sum of the lengths of the p compressed segment identifiers is less than the length of the t uncompressed segment identifiers, and the routing type field performs a function of subtracting 1 from the number of remaining segments after processing of all compressed segment identifiers within the length of one uncompressed segment identifier is completed. The segment routing header compression method according to claim 1 or 2.

4. Completing the processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the bits following the currently processed segment identifier in the segment list being all zero, or The segment routing header or the segment list of the service message further includes a counter field for recording the number of unprocessed compressed segment identifiers, and each time processing of one compressed segment identifier is completed, the value of the counter field is decremented by 1, the initial value of the counter field is p, and the completion of processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the value of the counter field being zero. The segment routing header compression method according to claim 3 .

5. A service processing method applied to a node of a segment routing path, comprising: A compressed segment identifier or a non-compressed segment identifier is set to each node on the segment routing path, a compressed segment identifier is set to a critical node on the segment routing path so that the critical node is additionally equipped with a function of performing segment identifier type conversion on a segment identifier indicated by the number of remaining segments, and the critical node is a node to which a compressed segment identifier has already been set, of two adjacent nodes to which different types of segment identifiers have already been set, The service processing method includes: Obtaining a segment list including a pre-configured compressed segment identifier and a pre-configured uncompressed segment identifier from a segment routing header of the received service message, and a routing type field for indicating a format of the segment routing header; processing a current segment identifier in the segment list and changing the number of remaining segments according to the routing type field; If the current node is a critical node, performing a segment identifier type conversion on the segment identifier pointed to by the remaining segment number; forwarding the service message including the segment identifier type indicated by the remaining segment number to a next-hop node; A computer-based service processing method including:

6. The critical node is a node to which a compressed segment identifier has already been set and a non-compressed segment identifier has already been set in a next-hop node, and performing a segment identifier type conversion on the segment identifier indicated by the remaining segment number includes changing the type of the segment identifier indicated by the remaining segment number to a non-compressed segment identifier; and / or The critical node is a node to which a compressed segment identifier has already been set and a non-compressed segment identifier has already been set in a previous hop node, and performing segment identifier type conversion on the segment identifier indicated by the remaining segment number includes changing the type of the segment identifier indicated by the remaining segment number to a compressed segment identifier; The segment routing header of the service message further includes a flag field for indicating the type of segment identifier to which the remaining segment number points; Before performing a segment identifier type conversion on the segment identifier pointed to by the remaining number of segments, The service processing method further includes: obtaining a flag field from a segment routing header of the service message; Changing the type of the segment identifier pointed to by the remaining segment number to an uncompressed segment identifier includes changing the value of the flag field to a value representing an uncompressed segment identifier; and / or Changing the type of the segment identifier pointed to by the remaining segment number to a compressed segment identifier includes changing the value of the flag field to a value representing a compressed segment identifier. The service processing method according to claim 5 .

7. Changing the number of remaining segments according to the routing type field If the segment routing header is in a first segment routing header format, after processing one compressed segment identifier is completed, subtracting n from the value of the number of remaining segments; After completing the processing of one uncompressed segment identifier, subtracting m from the value of the number of remaining segments; where n is the ratio between the length of the compressed segment identifier and the length of the shortest supported compressed segment identifier, and n is a positive integer; m is the ratio between the length of the uncompressed segment identifier and the length of the shortest supported compressed segment identifier, where m is a positive integer; Changing the number of remaining segments according to the routing type field If the segment routing header is in a second segment routing header format, after processing of all compressed segment identifiers within the length of one uncompressed segment identifier is completed, subtracting one from the number of remaining segments; where p compressed segment identifiers occupy the bits of the length of t uncompressed segment identifiers, t is a positive integer, p is a rounded value of the ratio of the length of one uncompressed segment identifier to the length of one compressed segment identifier, and if the sum of the lengths of p compressed segment identifiers is less than the length of t uncompressed segment identifiers, the remaining length is filled with reserved bytes.

7. The service processing method according to claim 5 or 6.

8. Completing the processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the bits following the currently processed segment identifier in the segment list being all zero; a counter field for recording the number of unprocessed compressed segment identifiers in the segment routing header or the segment list of the service message, wherein the value of the counter field is decremented by 1 each time processing of one compressed segment identifier is completed, and the initial value of the counter field is p; Completion of processing of all compressed segment identifiers within the length of one uncompressed segment identifier includes the value of the counter field being zero. The service processing method according to claim 7.

9. A segment routing header compression device comprising: a setting module; a first generating module; and a second generating module, The setting module is configured to set a compressed segment identifier or an uncompressed segment identifier to each node on a segment routing path, and to set a compressed segment identifier to a critical node in the segment routing path so that the critical node is additionally equipped with a function of performing segment identifier type conversion on a segment identifier indicated by a remaining number of segments, and the critical node is a node to which a compressed segment identifier has already been set, of two adjacent nodes to which different types of segment identifiers have already been set; the first generating module is configured to generate a segment list including a pre-established compressed segment identifier and a pre-established uncompressed segment identifier; the second generating module is configured to generate a segment routing header of a service message, the segment routing header of the service message including the segment list and a routing type field for indicating a format of the segment routing header, the format of the segment routing header conforming to a format of the compressed segment identifier; Segment routing header compressor.

10. A service processing device applied to a node of a segment routing path, A compressed segment identifier or a non-compressed segment identifier is set to each node on the segment routing path, a compressed segment identifier is set to a critical node on the segment routing path so that the critical node is additionally equipped with a function of performing segment identifier type conversion on a segment identifier indicated by the number of remaining segments, and the critical node is a node to which a compressed segment identifier has already been set, of two adjacent nodes to which different types of segment identifiers have already been set, The service processing device comprises an acquisition module, a processing module, a conversion module, and a transfer module; The acquiring module is configured to acquire, from a segment routing header of the received service message, a segment list including a previously set compressed segment identifier and a previously set uncompressed segment identifier, and a routing type field for indicating a format of the segment routing header; the processing module is configured to process a current segment identifier in the segment list and change a number of remaining segments according to the routing type field; The conversion module is configured to perform segment identifier type conversion on a segment identifier indicated by a remaining segment number when the current node is a critical node; The forwarding module is configured to forward the service message including a segment identifier type indicated by a remaining segment number to a next-hop node. Service processing unit.

Images