Message encapsulation method, message forwarding method, notification method, electronic device, and storage medium

Abstract

The present disclosure provides a message encapsulation method, including: determining a segment routing-traffic engineering SR-TE path; generating a SID list according to the segment identifier SID of each node in the SR-TE path, wherein each of the nodes supports multiple universal SID encapsulation types UET, and the multiple UETs of the node correspond to SIDs of different lengths, respectively, and in the SID list, the SID of at least the node that is an intermediate node of the SR-TE path is the SID with a length that is not the longest among the multiple SIDs corresponding to the node; forming a segment routing header SRH using the SID list; and encapsulating an initial message using the SRH to obtain a final message. The present disclosure also provides a message forwarding method, a UET notification method, an electronic device, and a computer-readable storage medium. The final message load rate obtained by encapsulating the message encapsulation method is relatively high.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of data communications, and in particular, to a message encapsulation method, a message forwarding method, a UET notification method, an electronic device, and a computer-readable storage medium. Background Art

[0002] Segment Routing (SR) is a method of routing based on the source node. Usually, the source node adds a layer of ordered instructions (or ordered segment identifiers (SIDs), or segments for short) list information to the data message. On the data plane, the shortest path forwarding is performed segment by segment based on the ordered SID list information. When the SID list is very long, the message will have a very long segment routing header (SRH), which reduces the payload efficiency of the message.

[0003] Public Content

[0004] The embodiments of the present disclosure provide a message encapsulation method, a message forwarding method, a UET notification method, an electronic device, and a computer-readable storage medium.

[0005] In a first aspect, an embodiment of the present disclosure provides a message encapsulation method, including:

[0006] Determine the Segment Routing-Traffic Engineering SR-TE path;

[0007] Generate a SID list according to the segment identifier SID of each node in the SR-TE path, wherein each of the nodes supports multiple universal SID encapsulation types UET, and the multiple UETs of the node correspond to SIDs of different lengths, respectively. In the SID list, the SID of at least a node that is an intermediate node of the SR-TE path is a SID with a length that is not the longest among the multiple SIDs corresponding to the node;

[0008] Using the SID list to form a segment routing header SRH;

[0009] The initial message is encapsulated using the SRH to obtain a final message.

[0010] In a second aspect, an embodiment of the present disclosure provides a message forwarding method, including:

[0011] After receiving the final message sent by the previous node, parse the final message to obtain a SID list of each node in the SR-TE path, wherein the final message is a final message obtained according to the encapsulation method described in the first aspect;

[0012] The final message is forwarded to the next hop node according to the SID list.

[0013] In a third aspect, an embodiment of the present disclosure provides a UET notification method, including:

[0014] Notify the network of the UET capability information of the current node;

[0015] The SID information carrying the corresponding UET capability of the current node is announced to the network.

[0016] In a fourth aspect, the present disclosure provides an electronic device, comprising:

[0017] one or more processors;

[0018] A storage device stores one or more programs thereon, and when the one or more programs are executed by the one or more processors, the one or more processors implement the above method.

[0019] In a fifth aspect, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the program implements the above method when executed by a processor.

[0020] In the message encapsulation method provided in the present disclosure, the SID list includes the SID whose length is not the longest among the multiple SIDs of each node. Therefore, the length of the SID list is relatively short, and the SRH finally formed is also relatively short, thereby improving the load efficiency in the final message. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings are used to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing detailed example embodiments with reference to the accompanying drawings, in which:

[0022] Figure 1 is a flow chart of a message encapsulation method provided by an embodiment of the present disclosure;

[0023] Figure 2 The UET Flag is added to the ISIS SRv6 Capabilities sub-TLV to indicate different SID compression capabilities;

[0024] Figure 3 The new UET Flag in OSPFv3 SRv6 Capabilities TLV indicates different SID compression capabilities;

[0025] Figure 4It is an SRv6 domain composed of different compression domains;

[0026] Figure 5 The new UET Flag in the ISIS SRv6 End SID sub-TLV indicates the allocation and notification of each UET and each SID;

[0027] Figure 6 The new UET Flag in OSPFv3 SRv6 End SID Sub-TLV indicates the allocation and notification of each UET and each SID;

[0028] Figure 7 It is an encapsulation format diagram that extends SRv6 SRH to add the UET Flag and mix SIDs of different lengths;

[0029] Figure 8 It is a network topology diagram of specific embodiments 1 and 2;

[0030] Fig. 9 is a network topology diagram of specific embodiment 3;

[0031] Fig.10 This is a network topology diagram of the fourth specific embodiment.

[0032] Fig.11 It is a flow chart of the message forwarding method provided by the present disclosure. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the technical solution of the present disclosure, a message encapsulation method, a message forwarding method, a UET notification method, an electronic device and a computer-readable storage medium provided by the present disclosure are described in detail below in conjunction with the accompanying drawings.

[0034] Example embodiments will be described more fully below with reference to the accompanying drawings, but the example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. On the contrary, the purpose of providing these embodiments is to make the present disclosure thorough and complete and to enable those skilled in the art to fully understand the scope of the present disclosure.

[0035] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

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

[0037] The terms used herein are only used to describe specific embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded.

[0038] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted as having an idealized or overly formal meaning unless explicitly defined as such herein.

[0039] In the related art, segment routing can be applied to the data plane of Multi-Protocol Label Switching (MPLS) and the data plane of IPv6. When segment routing is applied to the data plane of MPLS, it is called SR-MPLS, and when segment routing is applied to the data plane of IPv6, it is called SRv6. In one standard, it is described that segment routing is applied to the data plane of MPLS by superimposing a layer of ordered segment list (also known as MPLS label stack) outside the message. In another standard, it is described that segment routing is applied to the data plane of IPv6 by superimposing a layer of ordered short list (i.e., a string of IPv6 address lists) outside the message. It can be seen that when the instruction list is long, both of the above technologies will cause the message header to be too long, which seriously reduces the payload efficiency of the message. Especially for SRv6, when the SRH is introduced in the message header, a string of mandatory IPv6 address lists is included, which greatly limits the implementation of specific products.

[0040] The core idea of ​​the present disclosure is to introduce a shorter SID in SRH, such as 64-bit, 32-bit, 16-bit, or 8-bit SID, etc. These short SIDs are called compressed SIDs to replace the existing 128-bit classic SRv6 SID. Among them, the compression effect of the 32-bit SID will be improved by 4 times compared with the existing 128-bit SID, and it is more suitable for the current mainstream chip processing capabilities in the industry, and it is also very convenient for the corresponding control plane protocol expansion. Therefore, this patent recommends the use of a 32-bit short SID and is mainly based on this discussion, but the discussed solution is also applicable to SIDs of other lengths.

[0041] Another core idea of ​​the present disclosure is to support the mixing of SIDs of various lengths, that is, SRH contains SIDs of various lengths at the same time to adapt to the reality of gradual network upgrades and transformations, such as in the SID List, some SIDs are 128-bit classic SRv6 SIDs, some SIDs are 32-bit compressed SIDs, and some SIDs are 16-bit compressed SIDs. In order to achieve this flexible mixing effect, it is necessary to explicitly give a SID length change prompt on the boundary node where the SID length changes. To this end, we will discuss how to extend the control plane protocol to facilitate the determination of the boundary node where the SID length changes in the segment list when constructing the SID List end-to-end, and the boundary node is responsible for switching the decapsulation of the SRH from one SID length to another SID length.

[0042] In view of this, as a first aspect of the present disclosure, a message encapsulation method is provided, such as Figure 1 As shown, the message encapsulation method includes:

[0043] In step S110, a segment routing-traffic engineering SR-TE path is determined;

[0044] In step S120, a SID list is generated according to the segment identifier SID of each node in the SR-TE path, wherein each of the nodes supports multiple universal SID encapsulation types UET, and the multiple UETs of the node correspond to SIDs of different lengths, respectively. In the SID list, the SID of at least a node that is an intermediate node of the SR-TE path is a SID with a length that is not the longest among the multiple SIDs corresponding to the node;

[0045] In step S130, a segment routing header SRH is formed using the SID list;

[0046] In step S140, the initial message is encapsulated using the SRH to obtain a final message.

[0047] It should be noted that the final message is a service message, and the SR-TE path includes multiple nodes passed when forwarding the service message, and the multiple nodes include a head node, at least one intermediate node and a tail node.

[0048] The message encapsulation method provided in the present disclosure may be executed by the head node in the SR-TE path. Each node supports multiple UETs, and each node may set SIDs of different lengths for its own different UETs.

[0049] In the message encapsulation method provided in the present disclosure, the SID list includes the SID whose length is not the longest among the multiple SIDs of each node. Therefore, the length of the SID list is relatively short, and the SRH finally formed is also relatively short, thereby improving the load efficiency in the final message.

[0050] Refer to the following Figure 8 The generation method provided by the present disclosure is explained.

[0051] like Figure 8 As shown in FIG, the SR-TE path for forwarding packets is node S→node A→node B→node C→node D.

[0052] In the related art, the SID length of each node in the SR-TE path is 128 bits. In the generation method provided in the present disclosure, in the SR-TE path, the SID length of node A is 32 bits, the SID length of node C is 64 bits, and the SID length of node D can be 128 bits. It can be seen that the length of the SID list finally generated by the generation method provided in the present disclosure is less than the length of the SID list generated in the related art.

[0053] The following uses the SRv6 network as an example to introduce the present disclosure in detail.

[0054] In an SRv6 network, each node can configure the SID compression capability it supports and advertise the SID compression capability to the outside world, so that all nodes in the network can learn the SID compression capability of other nodes. This article refers to the SID compression capability as UET (Unified-SID Encapsulation Type). For example, each node can be configured to support the following UET:

[0055] UET(0): Only the existing 128-bit IPv6 address is supported as the SID, that is, the existing classic SRv6 SID.

[0056] UET(1): In addition to supporting the use of existing 128-bit IPv6 addresses as SIDs, it also supports the use of 32-bit IPv4 addresses or values ​​as SIDs.

[0057] UET(2): In addition to supporting the use of the existing 128-bit IPv6 address as the SID, it also supports the use of the 32-bit MPLS Label as the SID. The upper 20 bits of the 32 bits store the MPLS Label, and the lower 12 bits store other auxiliary information.

[0058] UET(3): In addition to supporting the use of existing 128-bit IPv6 addresses as SIDs, it also supports the use of 64-bit values ​​as SIDs.

[0059] UET(4): In addition to supporting the use of existing 128-bit IPv6 addresses as SIDs, it also supports the use of 16-bit values ​​as SIDs.

[0060] UET(5): In addition to supporting the use of existing 128-bit IPv6 addresses as SIDs, it also supports the use of 8-bit values ​​as SIDs.

[0061] Of course, the present disclosure is not limited to this.

[0062] As another aspect of the present disclosure, a UET notification method is provided, including:

[0063] The attributes carrying the current node UET are broadcast to the network.

[0064] As mentioned above, considering the current chip capabilities in the industry and the convenience of control plane protocol expansion, it is more advantageous to use a short 32-bit SID. Therefore, in general, a SRv6 node may be configured to support both compression capabilities UET(0) and UET(1), and another SRv6 node may be configured to support both compression capabilities UET(0) and UET(2). That is, each SRv6 node must support the classic 128-bit SRv6 SID, and on this basis, introduce the ability to support shorter compressed SIDs with different characteristics. Of course, in theory, a SRv6 node, such as a border node, may be configured to support richer compression capabilities UET(0), UET(1), UET(2), UET(3), UET(4), UET(5), etc., so as to facilitate the switching of SIDs of different lengths on the border node.

[0065] The specific implementation of extending the existing protocol in the control plane to advertise the SID compression capability is as follows:

[0066] 1) draft-ietf-lsr-isis-srv6-extensions-05 defines the ISIS (Intermediate System to Intermediate System) extension to support SRv6. Each node can advertise its SRv6 capabilities by including a new SRv6 Capabilities sub-TLV in the router capabilities TLV defined in RFC7981. This patent will continue to carry SID compression capability information in the SRv6 Capabilities sub-TLV. Figure 2As shown in the figure, in the Flags field of the SRv6 Capabilities sub-TLV, a new two-bit UET Flag is defined to support the notification of various typical SID compression capabilities. The values ​​and meanings of the UET Flag are as follows:

[0067] 0b00: Only the existing 128-bit IPv6 address can be used as the SID.

[0068] 0b01: In addition to supporting the use of existing 128-bit IPv6 addresses as SIDs, it also supports the use of 32-bit IPv4 addresses or values ​​as SIDs.

[0069] 0b10: In addition to supporting the use of existing 128-bit IPv6 addresses as SIDs, it also supports the use of 32-bit MPLS Labels as SIDs. The upper 20 bits of the 32 bits store the MPLS Label, and the lower 12 bits (called ContextField) store other auxiliary information.

[0070] 0b11: Support all the above capabilities.

[0071] 2) draft-ietf-lsr-ospfv3-srv6-extensions-00 defines OSPFv3 (Open Shortest Path First) extensions to support SRv6. Each node can advertise its SRv6 capabilities by including a new SRv6Capabilities TLV in the OSPFv3 Router Information LSA defined in RFC7770. This patent will continue to carry SID compression capability information in the SRv6 Capabilities TLV. Figure 3 As shown in the figure, in the Flags field of the SRv6 Capabilities TLV, a new two-bit UET Flag is defined to support the notification of various typical SID compression capabilities. The value and meaning of the UET Flag refer to the above ISIS part and will not be repeated here.

[0072] 3) Similarly, draft-ietf-idr-bgpls-srv6-ext-02 defines BGP-LS (North-Bound Distribution of Link-State and Traffic Engineering information Using BGP, using BGP to announce link status and TE information, see RFC7752) to extend SRv6 to support reporting of SRv6 information of each node in the network to the controller. In the notification method provided in the present disclosure, SID compression capability information will be added to the reported SRv6 capability information, so that when the controller translates the end-to-end path calculation results into the SID List, it can perceive the SID compression capability information of all nodes passed by the path, identify the boundary nodes connected to different compressed SID types, and then select the appropriate type of SID. The SRv6 Capabilities TLV defined in BGP-LS and the newly added SID compression capability information are similar to the above-mentioned IGP, and the specific extensions will not be repeated.

[0073] In an SRv6 network, each node can apply for a SID according to the SID compression capability it supports and the allocation method of each SRV6 SID per SID compression capability. That is, each SRv6 SID has a specific UET attribute, and this SID with the UET attribute is announced to the outside world, so that all nodes in the network can learn the SIDs of other nodes.

[0074] like Figure 4As shown in the figure, in the entire SRv6 domain, since the local area in the network is upgraded to support compression capabilities, the entire SRv6 domain contains three sub-domains that use compressed SIDs of different lengths. For example, ABR1 supports both UET(0) and UET(1), so it can allocate two types of SIDs for these two types of UETs. For example, taking END SID as an example, ABR1 can allocate END SID abr1-sid1 for UET(0) and END SID abr1-sid2 for UET(1); similarly, ABR2 supports both UET(0) and UET(2), so it can allocate END SID abr2-sid1 for UET(0) and ENDSID abr2-sid2 for UET(2). Other types of SIDs, such as END.X and other topology-related SIDs, and Service Function-related SIDs, can be allocated different SIDs for different UETs. Theoretically, all types of SIDs can be assigned to different UETs. However, considering the actual situation, SIDs related to overlay VPN (Virtual Private Network) services (such as SIDs related to L3VPN and EVPN services) generally appear at the end of the SID List. At this time, it does not involve the situation where the SID length changes. Therefore, it is not recommended to assign different SIDs related to overlay services to different UETs to save SID resources.

[0075] After allocating a SID with a specific UET attribute, the SRv6 node will create a corresponding Local SID entry locally, and explicitly give the UET attribute in the Function processing of the Local SID entry.

[0076] In the SID List contained in the SRH, for a SID with a specific UET attribute, the SID following it, that is, the Next SID, will be prompted as to which compression SID method is used. For example, if the UET attribute value is 0, the Next SID is the existing 128-bit IPv6 address; if the UET attribute value is 1, the Next SID is a 32-bit IPv4 address or value; if the UET attribute value is 2, the Next SID is a 32-bit MPLS Label, and so on.

[0077] The specific implementation of extending the existing protocol in the control plane to advertise each UE T per SID is as follows:

[0078] 1) draft-ietf-lsr-isis-srv6-extensions-05 defines ISIS extension support for SRv6, and each node can advertise its own assigned SID. Among them, the SRv6 Locator TLV is introduced, and the SRv6 End SID sub-TLV carrying the END SID is included; the SRv6 End.X SID sub-TLV carrying the END.X SID of the point-to-point link is introduced; the SRv6 LAN End.X SID sub-TLV carrying the LAN END.X SID of the broadcast link is introduced. This disclosure continues to add UET attributes to the existing SID announcement, such as Figure 5 As shown in the figure, in the Flags field of the SRv6 End SID sub-TLV, a new two-bit UET Flag is defined to indicate the UET attribute of the END SID. The values ​​and meanings of the UET Flag are as follows:

[0079] 0b00: indicates that the Next SID is a 128-bit IPv6 address.

[0080] 0b01: indicates that the Next SID is a 32-bit IPv4 address or value.

[0081] 0b10: indicates that the Next SID is a 32-bit MPLS Label.

[0082] 0b11: Reserved, undefined.

[0083] Similarly, a two-bit UET Flag may be newly defined in the Flags field of the SRv6 End.X SID sub-TLV and the SRv6 LAN End.X SID sub-TLV to indicate the UET attribute of the corresponding END.X SID or LAN END.X SID, which will not be described in detail.

[0084] Note: For UET(1) type SID advertisements, information on how to convert a 32-bit IPv4 address or value into a 128-bit classic SRv6 SID should also be provided. The SRv6 SID Structure Sub-Sub-TLV has been defined in draft-ietf-lsr-isis-srv6-extensions-05 as a sub-sub-TLV included in the above SRv6 EndSID sub-TLV, SRv6 End.X SID sub-TLV, and SRv6 LAN End.X SID sub-TLV. The specific structure of the corresponding SID is provided, including the length of the SRv6 SID Locator Block, the length of the SRv6 SID Locator Node, the length of the SRv6 SID Function, and the length of the SRv6 SID Arguments, in bits. Therefore, the prior art has revealed a very intuitive conversion method, that is, under a specific address plan, in the 128-bit SRv6 SID of the UET(1) type, the high-bit part is the SRv6 SID Locator Block (SRv6 SID Locator Block is the public address part of all nodes in the SRv6 domain), and the following 32 bits are composed of SRv6 SID Locator Node, SRv6SID Function and SRv6 SID Arguments, and the remaining bits are filled with zeros. In other words, in the SID List, a 128-bit classic SRv6 SID sid1 with the UET(1) attribute indicates that the Next SID sid2 is a 32-bit IPv4 address or value. The method for converting the Next SID sid2 into a complete 128-bit classic SRv6 SID sid2' is that the high-bit part of sid2' is the SRv6 SID Locator Block information provided by the high-bit part of sid1, and the next 32 bits are the SRv6 SID Locator Node, SRv6 SID Function, and SRv6SID Arguments information provided by sid2 (some of the information may be 0 itself), and the remaining bits are filled with zeros.

[0085] 2) draft-ietf-lsr-ospfv3-srv6-extensions-00 defines OSPFv3 extensions to support SRv6, and each node can announce its own assigned SID. It introduces SRv6 Locator LSA and SRv6 Locator TLV, and includes SRv6 End SID Sub-TLV carrying END SID in SRv6 Locator TLV; introduces SRv6 End.X SIDSub-TLV carrying END.X SID of point-to-point link; introduces SRv6 LAN End.X SID Sub-TLV carrying LAN END.X SID of broadcast link. This patent continues to add UET attributes to the existing SID announcement, such as Figure 6 As shown in the figure, in the Flags field of the SRv6 End SID Sub-TLV, a new two-bit UET Flag is defined to indicate the UET attribute of the END SID. The value and meaning of the UET Flag refer to the above ISIS part and will not be repeated here.

[0086] Similarly, a two-bit UET Flag may be newly defined in the Flags field of the SRv6 End.X SID Sub-TLV and the SRv6 LAN End.X SID Sub-TLV to indicate the UET attribute of the corresponding END.X SID or LAN END.X SID, which will not be described in detail.

[0087] 3) draft-ietf-idr-bgpls-srv6-ext-02 defines BGP-LS extension SRv6 to support reporting SRv6 information of each node in the network to the controller. Among them, SRv6 SID NLRI, SRv6 SID Information TLV, and SRv6 Endpoint Behavior TLV are introduced, and END SID is included in SRv6 SID Information TLV, and the attributes of END SID are included in SRv6Endpoint Behavior TLV; SRv6 End.X SID TLV is introduced to carry END.X SID in point-to-point link attributes; SRv6 LAN End.X SID TLV is introduced to carry LANEND.X SID in broadcast link attributes. This patent adds a new UET attribute to the SRv6 SID information reported above, that is, a two-bit UET Flag is newly defined in the Flags field of the SRv6 EndpointBehavior TLV, the Flags field of the SRv6 End.X SID TLV, and the Flags field of the SRv6 LAN End.XSID TLV to indicate the UET attribute of the corresponding SID. The specific extension is similar to the aforementioned IGP and will not be repeated here. When the controller translates the end-to-end path calculation results into the SID List, it can select the appropriate SID with a specific UET attribute as needed.

[0088] For nodes in a compression domain that uses UET(2) (i.e., 32-bit MPLS Labels are used as SIDs), in theory, they can also apply for SR-MPLS SIDs in the same way as the allocation of SRv6 SIDs above, using the per-UET per-SR-MPLS SID allocation method. For example: Figure 4 In the example, the ABR2 node can allocate SR-MPLS Prefix-SID abr2-node-sid1 for UET(0) and SR-MPLS Prefix-SID abr2-node-sid2 for UET(2), but this method will waste precious MPLS label resources. In fact, in the SRH SID List, each MPLS Label type SID only occupies 20 bits, and the remaining 12 bits (Context Field) can store UET information to indicate what type of SID the Next SID is. For details, please refer to Figure 7 .

[0089] In an SRv6 network, Figure 4As shown, the head node S (or request controller) can calculate an SR-TE (Segment Routing Traffic Engineering) path from the head node S to the destination node D. This path can traverse multiple compressed sub-domains with different UETs. The corresponding SR-TE path needs to be composed of a SID List with appropriate SIDs having specific UET attributes. Assume that the Segment List corresponding to the SR-TE path from S to D is <X, ABR1, Y, ABR2, Z, D>, which consists of multiple loose nodes. In the prior art without any compression scheme, this Segment List would be translated into the SID List <128bits-end-sid-x, 128bits-end-sid-abr1, 128bits-end-sid-y, 128bits-end-sid-abr2, 128bits-end-sid-z, 128bits-end-sid-d>. However, considering the capabilities of each compressed sub-domain discussed in this patent, the head node or controller knows that nodes S / X / ABR1 have the compression capability of UET(1), nodes ABR1 / Y / ABR2 have the compression capability of UET(0), and nodes ABR2 / Z / D have the compression capability of UET(2). It can be inferred that node ABR1 is the boundary node between two different compression domains (UET(1) and UET(0)), and node ABR2 is the boundary node between two different compression domains (UET(0) and UET(2)). Then, according to the per-UET per-SID information advertised by each node, this Segment List can actually be represented as <X (with UET(1) attribute), ABR1 (with UET(0) attribute), Y (with UET(0) attribute), ABR2 (with UET(2) attribute), Z (with UET(2) attribute), D (with UET(0) attribute)>. Note that the above UET attributes indicate the type of the Next SID. Therefore, it can be translated into a SID List composed of some shorter SIDs <32bits-ipv4-x, 32bits-ipv4-abr1, 128bits-end-sid-y, 128bits-end-sid-abr2, 32bits-label-z, 32bits-label-d>. Further explanations are as follows:

[0090] For example, the END SID allocated by node X is 128 bits-end-sid-x, and the UET attribute in the corresponding local SID table entry is UET(1) to indicate the Next SID, 32 bits-ipv4-abr1, which is a 32-bit IPv4 address or value.

[0091] Note that the S node needs to convert the shorter 32 bits-ipv4-x (a 32-bit IPv4 address) into 128 bits-end-sid-x (a complete 128-bit classic SRv6 END SID) and copy it to the DA (Destination Address) field of the IPv6 Header before forwarding the message to the X node. The specific conversion method is to combine 32 bits-ipv4-x with 128 bits-end-sid-s (a complete 128-bit classic SRv6 END SID with the UET(1) attribute), that is, the high bit part of 128 bits-end-sid-x is provided by the high bit part of 128 bits-end-sid-s, the next 32 bits are provided by 32 bits-ipv4-x, and the remaining bits are padded with zeros. Or a more concise implementation is that node S actually already knows that the first SID in the SID List is 128 bits-end-sid-x, and it directly copies 128 bits-end-sid-x to the DA field of the IPv6 Header, except that the logical first SID in the SRH is filled with 32 bits-ipv4-x.

[0092] For example, the END SID assigned by node ABR1 is 128 bits-end-sid-abr1, and the UET attribute in the corresponding local SID table entry is UET(0), which indicates the Next SID, 128 bits-end-sid-y, which is a 128-bit classic SRv6 SID. Note that node X also needs to convert the shorter 32 bits-ipv4-abr1 into 128 bits-end-sid-abr1 and copy it to the DA (Destination Address) field of the IPv6 Header, and then guide the message to be forwarded to node ABR1. The specific conversion method can be to combine 32bits-ipv4-abr1 with 128bits-end-sid-x (a complete 128-bit classic SRv6 END SID with the UET(1) attribute), that is, the high-bit part of 128bits-end-sid-abr1 is provided by the high-bit part of 128bits-end-sid-x, the next 32 bits are provided by 32bits-ipv4-abr1, and the remaining bits are padded with zeros.

[0093] For example, the END SID assigned to node Y is 128 bits-end-sid-y, and the UET attribute in the corresponding local SID table entry is UET(0), which indicates the Next SID, 128 bits-end-sid-abr2, which is a 128-bit classic SRv6 SID.

[0094] For example, the END SID allocated by node ABR2 is 128 bits-end-sid-abr2, and the UET attribute in the corresponding local SID table entry is UET(2) to indicate the Next SID, that is, 32 bits-label-z, which is a 32-bit MPLS Label.

[0095] For example, the MPLS Label assigned by node Z, namely 32bits-label-z, has nothing to do with UET. In the SIDList of SRH, the Context Field of SID 32bits-label-z stores the corresponding UET attribute UET(2) to indicate the Next SID, namely 32bits-label-d, which is a 32-bit MPLS Label. Note that node ABR2 needs to first map the above 32bits-label-z into a 128-bit IPv6 address, copy it to the DA (DestinationAddress) field of the IPv6 Header, and then guide the message to be forwarded to node Z. The specific mapping method can be to find the corresponding ILM (Incoming Label Map) table entry and obtain FEC information from the ILM table entry. For example, Prefix FEC provides the IPv6 address to the remote node, and Adjacency FEC provides the IPv6 address to the link peer interface.

[0096] For example, the MPLS Label assigned by node D, namely 32bits-label-d, has nothing to do with UET. In the SIDList of SRH, the corresponding UET is stored in the Context Field of SID 32bits-label-d to indicate the type of Next SID. For example, if there is a 128-bit classic SRv6SID related to VPN service at the end of the SID List of SRH, the UET stored in the Context Field of SID 32bits-label-d is UET(0). Note that node Z also needs to map the above 32bits-label-d into a 128-bit IPv6 address, copy it to the DA field of the IPv6 Header, and then guide the message to be forwarded to node D.

[0097] If the SR-TE path is calculated by the controller, the controller needs to send the path calculation result (SID List) to the head node S. In the sent SID List, the UET attribute of each SID must be given so that the head node can use the compressed SID when encapsulating the SRH for the message and assemble these SIDs in the SRH in order.

[0098] The specific implementation method of extending the SDN southbound channel so that the path calculation result sent from the controller carries the UET attribute is as follows:

[0099] 1) draft-ietf-pce-segment-routing-ipv6-03 defines the PCEP channel to deliver SRv6 TEtunnel, which introduces the SRv6-ERO Subobject to carry the classic 128-bit SRv6 SID. This patent defines a new two-bit UET Flag in the Flags field to indicate the UET attribute of the corresponding SID. The specific extension and the value and meaning of the UET attribute are similar to those mentioned above and will not be repeated here.

[0100] In addition, RFC8664 defines the PCEP channel to send SR-MPLS TE tunnel, which introduces SR-EROSubobject to carry SR-MPLS SID. This patent believes that an end-to-end SID List that traverses multiple different UET compression domains may contain classic SRv6 SIDs, 32-bit IPv4 addresses or SIDs represented by numerical values, and 32-bit MPLS Labels. For this reason, this patent will also define a two-bit UET Flag in the Flags field of SR-ERO Subobject to indicate the UET attribute of the corresponding SID. The specific extension and the value and meaning of the UET attribute are similar to those mentioned above and will not be repeated here.

[0101] 2) draft-ietf-idr-segment-routing-te-policy-08 defines the SR-MPLS policy or SRv6 TE policy delivered through the BGP channel, which introduces the Segment sub-TLV to carry various types of segments. The currently known types are Type A to Type K. This patent defines a new two-bit UET Flag in the Flags field of these types of segments to indicate the UET attribute of the corresponding segment. The specific extensions and the values ​​and meanings of the UET attributes are similar to those mentioned above and will not be repeated here.

[0102] For example, for Figure 4For the SR-TE path from S to D shown in the figure, the controller calculates the corresponding Segment List as follows:<X, ABR1, Y, ABR2, Z, D> Then, according to the compression capability of each node and the information of each UET and each SID announced by each node, the SID List<128bits-end-sid-x (including UET(1) attribute), 128bits-end-sid-abr1 (including UET(0) attribute), 128bits-end-sid-y (including UET(0) attribute), 128bits-end-sid-abr2 (including UET(2) attribute), 32bits-label-z (including UET(2) attribute), 32bits-label-d (including UET(0) attribute)> is sent to the head node S. Note that the above UET attribute indicates the type of Next SID. Therefore, when the head node encapsulates SRH for the message, it can use the SID List<32bits-ipv4-x, 32bits-ipv4-abr1, 128bits-end-sid-y,128bits-end-sid-abr2, 32bits-label-z, 32bits-label-d>.

[0103] In an SRv6 network, Figure 4 As shown in the figure, for the SRv6-TE path from S to D, the corresponding Segment List is<X, ABR1, Y, ABR2, Z, D> When the VPN service message is forwarded along the SR-TE path, the head node S can use a SID List<32bits-ipv4-x, 32bits-ipv4-abr1,128bits-end-sid-y, 128bits-end-sid-abr2, 32bits-label-z, 32bits-label-d,128bits-vpn-sid> composed of short length SIDs when encapsulating the message. In order to be compatible with the existing SRv6 encapsulation method based on 128-bit length SID during SRH encapsulation, this patent proposes the following encapsulation method:

[0104] 1) In the Flags field of the existing SRH, a new two-bit UET Flag (referred to as SRH.UET) is defined, see Figure 7 , to indicate the compression domain type of the current message. The values ​​and meanings of SRH.UET are as follows:

[0105] 0b00: indicates that the current compression field uses a 128-bit IPv6 address as the SID compression method.

[0106] 0b01: indicates that the current compression field uses a 32-bit IPv4 address or value as the SID compression method.

[0107] 0b10: Indicates that the current compression field uses the 32-bit MPLS Label as the SID compression mode.

[0108] 0b11: Reserved, undefined.

[0109] 2) Taking the classic 128-bit as the basic unit, each adjacent short SID can be assembled together and placed in the 128-bit basic unit, and the idle bits are filled with zeros.

[0110] like Figure 7 The following is a specific encapsulation example of SID List<32bits-ipv4-x, 32bits-ipv4-abr1, 128bits-end-sid-y, 128bits-end-sid-abr2, 32bits-label-z, 32bits-label-d, 128bits-vpn-sid>. Note that according to the definition of draft-ietf-6man-segment-routing-header-26, the SID List in SRH (represented as SRH.List[]) is stored in reverse order, so SRH.List[0] stores the logical last SID, that is, 128bits-vpn-sid, and List[4] stores the logical first SID, that is, it consists of the entries 32bits-ipv4-x, 32bits-ipv4-abr1, and two 32-bit entries padded with zeros. This indicates that SRH.List contains five 128-bit basic units, and the initial value of Segment Left (SRH.SL) in SRH is 5. SRH.UET is initially set to 0b01 to reflect the compression type UET (1) used by the first logical SID (i.e. 32bits-ipv4-x).

[0111] Note that in the lower 12 bits of the Context Field field of 32bits-label-z, the UET attribute is set to 0b10, indicating that the next SID is a 32-bit MPLS Label; in the lower 12 bits of the Context Field field of 32bits-label-d, the UET attribute is set to 0b00, indicating that the next SID is a 128-bit classic SRv6 SID. Figure 7 shown.

[0112] Note that the SID represented by the 32-bit IPv4 address and the SID represented by the 32-bit MPLS Label can be placed in the same 128-bit basic unit. This situation will be discussed in the subsequent specific embodiments.

[0113] The present disclosure also provides a message forwarding method, specifically, as follows: Fig.11 As shown, the message forwarding method includes:

[0114] In step S210, after receiving the final message sent by the previous node, the final message is parsed to obtain a SID list of each node in the SR-TE path, wherein the final message is the final message obtained by the above encapsulation method provided by the present disclosure;

[0115] In step S220, the final message is forwarded to the next hop node according to the SID list.

[0116] Next, we will discuss in detail the case where the message is forwarded from the head node S to the logical first segment node (i.e., node X). Since SRH.UET is 0b01, it means that it is currently in the UET (1) type compression domain. In this type of compression domain, each SID only occupies 32 bits, which is only one-fourth of the 128-bit classic SRv6 SID. The initial SRH.SL (equal to 5) value indicates how many 128-bit classic SRv6 SIDs are left to be processed, so first you need to quadruple SRH.SL and update its value, that is, SRH.SL = SRH.SL * 4, and get SRH.SL = 20.

[0117] Then get the logical first SID in the SRH, that is, execute the following main codes in sequence:

[0118] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 19;

[0119] Step 2: Read SRH.List[SRH.SL] to get 32bits-ipv4-x. Note that SRH.UET indicates that it is currently in the compression domain of type UET(1), so each time an element is read from SRH.List[], only 32 bits are read.

[0120] Step 3: Convert 32 bits-ipv4-x into 128 bits-end-sid-x, and then copy it to the DA field of the outer IPv6 Header. The conversion method is as described above.

[0121] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node X.

[0122] When the message arrives at node X, the current DA is equal to 128bits-end-sid-x, and the local SID table entry is hit. The UET attribute given in this local SID table entry is UET(1), which is updated to SRH.UET. Then the Next SID is still a 32-bit IPv4 address, so node X will execute the following main codes in sequence:

[0123] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 18;

[0124] Step 2: Read SRH.List[SRH.SL] to get 32bits-ipv4-abr1. Note that SRH.UET indicates that it is currently in the compression domain of type UET(1), so each time an element is read from SRH.List[], only 32 bits are read.

[0125] Step 3: Convert 32 bits-ipv4-abr1 to 128 bits-end-sid-abr1, and then copy it to the DA field of the outer IPv6 Header. The conversion method is as described above.

[0126] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node ABR1.

[0127] When the message arrives at node ABR1, the current DA is equal to 128bits-end-sid-abr1, and the local localSID entry is hit. The UET attribute given in this local SID entry is UET(0). It is updated to SRH.UET, and the Next SID is a 128-bit classic SRv6 SID, that is, the compression domain will be switched to the traditional classic SRv6 domain. Therefore, node ABR1 needs to first restore SRH.SL to a count in units of 128-bit classic SRv6 SID. It only needs to divide SRH.SL by 4 and round it to update its value, that is, SRH.SL = SRH.SL / 4, and get SRH.SL=4, and then execute the following main codes in sequence:

[0128] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 3;

[0129] Step 2: Read SRH.List[SRH.SL] and get 128bits-end-sid-y. Note that SRH.UET indicates that it is currently in the compression domain of type UET(0), so each time an element is read from SRH.List[], 128 bits will be read.

[0130] Step 3: Copy 128bits-end-sid-y to the DA field of the outer IPv6 Header;

[0131] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node Y.

[0132] Note: The above code is actually the current classic SRv6 processing of SRH, and this patent is fully compatible with it, that is, the nodes in the UET(0) type compression domain are completely unaware of the existence of SIDs of different lengths mixed in the SRH.

[0133] When the message arrives at node Y, the current DA is equal to 128bits-end-sid-y, and the local SID entry is hit. The UET attribute in this local SID entry is UET(0), which is updated to SRH.UET. Then the Next SID is still a 128-bit classic SRv6 SID, and the following main codes are executed in sequence:

[0134] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 2;

[0135] Step 2: Read SRH.List[SRH.SL] and get 128bits-end-sid-abr2. Note that SRH.UET indicates that it is currently in the compression field of type UET(0), so each time an element is read from SRH.List[], 128 bits will be read.

[0136] Step 3: Copy 128bits-end-sid-abr2 to the DA field of the outer IPv6 Header;

[0137] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node ABR2.

[0138] Note: The above code is actually how the current classic SRv6 processes SRH.

[0139] When the packet reaches node ABR2, the current DA is equal to 128bits-end-sid-abr2, and the local localSID entry is hit. The UET attribute in this local SID entry is UET(2). It is updated to SRH.UET, and the Next SID is a 32-bit MPLS Label, that is, the compression domain will be switched to a domain that uses MPLS label compression. In this type of compression domain, each SID occupies only 32 bits, which is only one-fourth of the 128-bit classic SRv6 SID. The current SRH.SL (equal to 2) value indicates how many 128-bit classic SRv6 SIDs are left to be processed. Therefore, first, SRH.SL needs to be quadrupled and then updated, that is, SRH.SL = SRH.SL * 4, to get SRH.SL=8, and then the following main codes are executed in sequence:

[0140] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 7;

[0141] Step 2: Read SRH.List[SRH.SL] and get 32bits-label-z. Note that SRH.UET indicates that it is currently in the compression domain of type UET(2), so each time an element is read from SRH.List[], only 32 bits are read.

[0142] Step 3: Get the UET value 0b10 saved in the Context Field of 32bits-label-z and update it to SRH.UET;

[0143] Step 4: Map the 32-bits-label-z into an IPv6 address (this address is a local address on node Z), and then copy it to the DA field of the outer IPv6 Header. The mapping method is as described above.

[0144] Step 5: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node Z.

[0145] When the message reaches node Z, the current DA hits the local address routing table entry, and there is no update to SRH.UET. Continue to parse SRH. Since SRH.UET is 0b10, the Next SID is still a 32-bit MPLS Label, and the following main codes are executed in sequence:

[0146] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 6;

[0147] Step 2: Read SRH.List[SRH.SL] and get 32bits-label-d. Note that SRH.UET indicates that it is currently in the compression domain of type UET(2), so each time an element is read from SRH.List[], only 32 bits are read.

[0148] Step 3: Get the UET value 0b00 saved in the Context Field of 32bits-label-d and update it to SRH.UET, which means that the compression domain after the message reaches node D will be switched to the traditional classic SRv6 domain. Therefore, node Z needs to restore SRH.SL to a count in units of 128-bit classic SRv6 SID in advance. It only needs to divide SRH.SL by 4 and then round it to update its value, that is, SRH.SL = SRH.SL / 4, and get SRH.SL = 1.

[0149] Step 4: Map the 32bits-label-d into an IPv6 address, and then copy it to the DA field of the outer IPv6 Header. The conversion method is as described above.

[0150] Step 5: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node D.

[0151] When the message reaches node D, the current DA hits the local address routing table entry, and there is no update to SRH.UET. Continue to parse SRH. Since SRH.UET is 0b00, the Next SID is a 128-bit classic SRv6 SID, and the following main codes are executed in sequence:

[0152] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 0;

[0153] Step 2: Read SRH.List[SRH.SL] to get 128bits-vpn-sid. Note that SRH.UET indicates that it is currently in the compression domain of type UET(0), so each time an element is read from SRH.List[], 128 bits will be read.

[0154] Step 3: Copy the 128bits-vpn-sid to the DA field of the outer IPv6 Header;

[0155] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message. The message will hit the local SID table entry and continue to process the message according to the existing technology.

[0156] According to the processing behaviors on the above nodes, the pseudo code of the general processing flow is summarized as follows. The following only involves the key processing flows related to this patent:

[0157] The process of sending a message by the head node:

[0158] S01. Set the initial value of SRH.UET to reflect the compression method used by the first logical SID;

[0159] S02. Set the initial value of SRH.SL to be equal to the SID count in 128-bit units in SRH.List[].

[0160] S03. if (SRH.UET == 0b00) {

[0161] S04. Decrement SRH.SL by 1;

[0162] S05. Read the 128-bit SRH.List[SRH.SL] element and copy it to the DA field of the IPv6 Header; or if the head node already knows the SID List information before encapsulating the SRH, directly copy the first SID to the DA field of the IPv6 Header;

[0163] S06. Look up the routing table and forward the message according to the DA in the outer IPv6 Header;

[0164] S07.}

[0165] S08. else if (SRH.UET == 0b01) {

[0166] S09. Multiply SRH.SL by 4;

[0167] S10. Decrement SRH.SL by 1;

[0168] S11. Read the 32-bit SRH.List[SRH.SL] element, convert it into a 128-bit SRv6 SID, and then copy it to the DA field of the IPv6 Header; or if the head node already knows the SID List information before encapsulating the SRH, directly copy the first SID to the DA field of the IPv6 Header;

[0169] S12. Look up the routing table and forward the message based on the DA in the outer IPv6 Header.

[0170] S13.}

[0171] S14. else if (SRH.UET == 0b10) {

[0172] S15. Multiply SRH.SL by 4;

[0173] S16. Decrement SRH.SL by 1;

[0174] S17. Read the 32-bit SRH.List[SRH.SL] element, map it to a 128-bit IPv6 address by looking up the ILM table, and then copy it to the DA field of the IPv6 Header; or if the head node already knows the SID List information before encapsulating the SRH, directly copy the first SID to the DA field of the IPv6 Header;

[0175] S18. Look up the routing table to forward the message according to the DA in the outer IPv6 Header; or directly obtain the forwarding information from the matching ILM table entry to forward the message;

[0176] S19.}

[0177] The processing flow of receiving messages at the intermediate node or tail node is as follows:

[0178] S01. Check the routing table according to the DA of the message. If a local SID table entry is matched, the UET attribute in the local SID table entry is updated to SRH.UET. If SRH.UET is updated from 0b00 to 0b01 or 0b10, SRH.SL is multiplied by 4. If SRH.UET is updated from 0b01 or 0b10 to 0b00, SRH.SL is divided by 4. If a common address routing table entry is matched, SRH.UET is not updated.

[0179] S02. if (SRH.SL == 0) {

[0180] S03 processing SRH package inner load;

[0181] S04.}

[0182] S05. else {

[0183] S06. if (SRH.UET == 0b00) {

[0184] S07. Decrement SRH.SL by 1;

[0185] S08. Read the 128-bit SRH.List[SRH.SL] element and copy it to the DA field of the IPv6 Header;

[0186] S09. Look up the routing table and forward the message according to the DA in the outer IPv6 Header.

[0187] S10.}

[0188] S11. else if (SRH.UET == 0b01) {

[0189] S12. Decrement SRH.SL by 1;

[0190] S13. Read the 32-bit SRH.List[SRH.SL] element, convert it into a 128-bit SRv6 SID, and then copy it to the DA field of the IPv6 Header;

[0191] S14. Look up the routing table and forward the message based on the DA in the outer IPv6 Header.

[0192] S15.}

[0193] S16. else if (SRH.UET == 0b10) {

[0194] S17. Decrement SRH.SL by 1;

[0195] S18. Read the 32-bit SRH.List[SRH.SL] element, map it to a 128-bit IPv6 address in the ILM table, and then copy it to the DA field of the IPv6 Header;

[0196] S19. Get the UET in the Context Field of the SRH.List[SRH.SL] element and update it to SRH.UET. If SRH.UET is updated from 0b10 to 0b00, SRH.SL is divided by 4.

[0197] S20. Look up the routing table to forward the message according to the DA of the outer IPv6 Header; or directly obtain the forwarding information from the matching ILM table entry to forward the message;

[0198] S21.}

[0199] S22.}

[0200] It should be noted that in the above steps, when multiple 32-bit SIDs are stored in a 128-bit basic unit, it involves the operation of multiplying SRH.SL by 4 or dividing it by 4. Obviously, if multiple 16-bit SIDs are stored in a 128-bit basic unit, it involves the operation of multiplying SRH.SL by 8 or dividing it by 8; if multiple 64-bit SIDs are stored in a 128-bit basic unit, it involves the operation of multiplying SRH.SL by 2 or dividing it by 2; if multiple 8-bit SIDs are stored in a 128-bit basic unit, it involves the operation of multiplying SRH.SL by 16 or dividing it by 16. Specific embodiments

[0201] This example describes a compression scheme that uses a simple 32-bit IPv4 address or value as the SID for the entire SRv6 domain. Figure 8 In the SRv6 network shown, the ISIS protocol is running, all nodes are configured to support UET(0) and UET(1), and the SRv6 capability information flooded externally contains UET Flag=0b01. All nodes are assigned a 128-bit classic SRv6 SID per UET per SID, for example:

[0202] Node S allocates END SID end-sid-s-uet0 for UET(0) and allocates END SID end-sid-s-uet1 for UET(1);

[0203] Node A allocates END SID end-sid-a-uet0 to UET(0) and allocates END SID end-sid-a-uet1 to UET(1);

[0204] Node B allocates END SID end-sid-b-uet0 for UET(0) and END SID end-sid-b-uet1 for UET(1). In addition, Node B allocates END.X SID end.x-sid-bc-uet0 for UET(0) and END.X SID end.x-sid-bc-uet1 for UET(1) for the Layer 3 link B->C.

[0205] Node C allocates END SID end-sid-c-uet0 for UET(0) and allocates END SID end-sid-c-uet1 for UET(1);

[0206] Node D allocates END SID end-sid-d-uet0 for UET(0) and allocates END SID end-sid-d-uet1 for UET(1);

[0207] Assume that an SR-TE path is established from the head node S to the tail node D, and its segment list is<node A,node B, link B-> C, node D>, this path may be calculated by the head node itself, or calculated by requesting the controller.

[0208] When the Segment List needs to be translated into a SID List, the head node (or controller) will check the route nodes (i.e., the segments in the Segment List) along the way to obtain the common compression capabilities of each node. In this example, all nodes have announced the compression capabilities of the UET(1) type and also announced the SIDs corresponding to the UET(1). Then, the head node (or controller) can use all the SIDs corresponding to the UET(1) in the SID List, that is, the SID List is<end-sid-a-uet1, end-sid-b-uet1, end.x-sid-bc-uet1, end-sid-d-uet1> .

[0209] However, if VPN services need to be carried on the SR-TE path, a VPN service-related SID needs to be inserted at the end of the above SID List. Assume that it is an END.DT6 type SID, end.dt6-sid-d-uet0. This SID is allocated by node D and is a 128-bit classic SRv6 SID. It should be noted that after inserting end.dt6-sid-d-uet0 at the end of the above SID List, the end-sid-d-uet1 at the end should be replaced with end-sid-d-uet0, and the SID List is obtained.<end-sid-a-uet1, end-sid-b-uet1, end.x-sid-bc-uet1, end-sid-d-uet0,end.dt6-sid-d-uet0> .

[0210] Since SRv6 SIDs of the END.X type are also routable, the above SID List can be optimized as follows:<end-sid-a-uet1, end.x-sid-bc-uet1, end-sid-d-uet0, end.dt6-sid-d-uet0> .

[0211] Assume that in all the above END or END.X type SID notifications, the SID structure information indicates that all SIDs are in the same SRv6 SID Locator Block, and the length of the SRv6 SID Locator Node + the length of the SRv6 SID Function + the length of the SRv6 SID Arguments in the structure information does not exceed 32 bits. For example:

[0212] In the structure of end-sid-a-uet1, the upper 32 bits are 32bits-block, which is the SRv6 SID LocatorBlock information, and the next 32 bits are 32bits-ipv4-a-uet1, which is the SRv6 SID Locator Node + SRv6SID Function information;

[0213] Similarly, in the structure of end-sid-b-uet1, the upper 32 bits are 32bits-block, and the next 32 bits are 32bits-ipv4-b-uet1;

[0214] In the structure of end.x-sid-bc-uet1, the upper 32 bits are 32 bits-block, and the next 32 bits are 32 bits-ipv4-bc-uet1;

[0215] In the structure of end-sid-d-uet0, the upper 32 bits are 32 bits-block, and the next 32 bits are 32 bits-ipv4-d-uet0;

[0216] When the head node S encapsulates the SRH for the message, it can use a short 32-bit IPv4 address or value as the SID, that is, the compressed SID List is <32bits-ipv4-a-uet1, 32bits-ipv4-bc-uet1, 32bits-ipv4-d-uet0, end.dt6-sid-d-uet0>. In the SRH, the first three SIDs are assembled in a 128-bit basic unit, and the excess space is filled with zeros. The initial value of SRH.SL is 2, and SRH.UET is set to 0b01.

[0217] The following describes the packet forwarding process along the SR-TE path:

[0218] 1) The message is forwarded from the head node S to the logically first Segment Node (i.e., node A). Since SRH.UET is 0b01, it means that it is currently in the UET (1) type compression domain. In this type of compression domain, each SID only occupies 32 bits, so first you need to quadruple SRH.SL and update its value, i.e., SRH.SL = SRH.SL * 4, and get SRH.SL = 8.

[0219] Then get the logical first SID in the SRH, that is, execute the following main codes in sequence:

[0220] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 7;

[0221] Step 2: Read SRH.List[SRH.SL] and get 32bits-ipv4-a-uet1, only 32 bits are read;

[0222] Step 3: Convert 32bits-ipv4-a-uet1 to end-sid-a-uet1, and then copy it to the DA field of the outer IPv6 Header. The conversion method is as described above.

[0223] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node A.

[0224] 2) When the message arrives at node A, the current DA is equal to end-sid-a-uet1, and the local SID table entry is hit. The UET attribute given in this local SID table entry is UET(1), which is updated to SRH.UET, and then the following main codes are executed in sequence:

[0225] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 6;

[0226] Step 2: Read SRH.List[SRH.SL] and get 32bits-ipv4-bc-uet1, only read 32 bits;

[0227] Step 3: Convert 32bits-ipv4-bc-uet1 to end.x-sid-bc-uet1, and then copy it to the DA field of the outer IPv6 Header. The conversion method is as described above.

[0228] Step 4: According to the DA in the outer IPv6 Header, the routing table is searched to forward the message, and the message will be forwarded to node B.

[0229] 3) When the message arrives at node B, the current DA is equal to end.x-sid-bc-uet1, and the local localSID table entry is hit. The UET attribute given in this local SID table entry is UET(1), which is updated to SRH.UET, and then the following main codes are executed in sequence:

[0230] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 5;

[0231] Step 2: Read SRH.List[SRH.SL] and get 32bits-ipv4-d-uet0, only read 32 bits;

[0232] Step 3: Convert 32bits-ipv4-d-uet0 to end-sid-d-uet0, and then copy it to the DA field of the outer IPv6 Header. The conversion method is described above.

[0233] Step 4: The message is forwarded along the link corresponding to end.x-sid-bc-uet1.

[0234] 3) When the message reaches node D, the current DA is equal to end-sid-d-uet0, and the local SID entry is hit. The UET attribute in this local SID entry is UET(0), and it is updated to SRH.UET, that is, the compression domain will be switched to the traditional classic SRv6 domain. Node D first restores SRH.SL to a count in units of 128-bit classic SRv6 SID, that is, SRH.SL = SRH.SL / 4, and obtains SRH.SL=1, and then executes the following main codes in sequence:

[0235] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 0;

[0236] Step 2: Read SRH.List[SRH.SL], get end.dt6-sid-d-uet0, read 128 bits;

[0237] Step 3: Copy end.dt6-sid-d-uet0 to the DA field of the outer IPv6 Header;

[0238] Step 4: According to the DA of the outer IPv6 Header, the routing table is searched to forward the message. The message will hit the local SID table entry, remove the outer IPv6 header and SRH, and continue to process the inner IPv6 payload. Specific embodiments

[0239] This example describes the entire SRv6 domain using a simple 32-bit MPLS Label as the SID compression solution. Figure 8 The SRv6 network shown in the figure runs the ISIS protocol. All nodes are configured to support UET(0) and UET(2), and the SRv6 capability information flooded externally contains UET Flag=0b10. All nodes are assigned a 128-bit classic SRv6 SID per UET per SID, for example:

[0240] Node S allocates END SID end-sid-s-uet0 for UET(0) and allocates END SID end-sid-s-uet2 for UET(2);

[0241] Other nodes are similarly assigned SIDs and named accordingly.

[0242] Assume that an SR-TE path is established from the head node S to the tail node D, and its segment list is<node A,node B, link B-> C, node D>, this path may be calculated by the head node itself, or calculated by requesting the controller.

[0243] When the Segment List needs to be translated into a SID List, the head node (or controller) will check the route nodes along the Segment List and obtain the public compression capabilities of each route node. In this example, all nodes have announced the UET(2) type of compression capability. The head node (or controller) can use all MPLS Labels in the SID List, that is, the SID List is<s.label-a, a.label-b, b.label-bc, c.label-d> . Among them, s.label-a indicates the label locally allocated on node S for prefix-A (for example, the loopback route of node A), a.label-b indicates the label locally allocated on node A for prefix-B (for example, the loopback route of node B), b.label-bc indicates the label locally allocated on node B for adjacency-BC, and c.label-d indicates the label locally allocated on node C for prefix-D (for example, the loopback route of node D).

[0244] It should be noted that the existing SR-MPLS control plane protocol can be deployed in the SRv6 domain to announce the above-mentioned MPLS Label, or the SRv6 control plane protocol can be directly extended to introduce a simplified version of the label announcement capability. This part is not within the scope of discussion of this patent.

[0245] If VPN services need to be carried on the SR-TE path, a SID related to the VPN service needs to be inserted at the end of the above SID List. Assume that it is an END.DT6 type SID, end.dt6-sid-d-uet0. This SID is allocated by node D and is a 128-bit classic SRv6 SID. Then the SID List is obtained.<s.label-a, a.label-b,b.label-bc, c.label-d, end.dt6-sid-d-uet0> .

[0246] In the SRH encapsulated in the message, the first four SIDs are assembled into a 128-bit basic unit, and the UET Flag in the Context Field of s.label-a, a.label-b, and b.label-bc is 0b10, while the UET Flag in the Context Field of c.label-d is 0b00. The initial value of SRH.SL is 2, and SRH.UET is set to 0b10.

[0247] The following describes the packet forwarding process along the SR-TE path:

[0248] 1) The message is forwarded from the head node S to the logically first segment node (i.e., node A). Since SRH.UET is 0b10, it means that it is currently in the UET (2) type compression domain. In this type of compression domain, each SID only occupies 32 bits, so first you need to multiply SRH.SL by 4 and then update its value, i.e., SRH.SL = SRH.SL * 4, and get SRH.SL = 8.

[0249] Then get the logical first SID in the SRH, that is, execute the following main codes in sequence:

[0250] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 7;

[0251] Step 2: Read SRH.List[SRH.SL] and get s.label-a, only 32 bits are read;

[0252] Step 3: Get the UET value 0b10 saved in the Context Field of s.label-a and update it to SRH.UET;

[0253] Step 4: Map s.label-a to prefix-A, and then copy it to the DA field of the outer IPv6 Header;

[0254] Step 5: According to the DA in the outer IPv6 Header, the routing table is searched for forwarding information (or forwarding information is directly obtained according to the ILM mapping table entry), and the message is forwarded to node A.

[0255] 2) When the message arrives at node A, the current DA is equal to prefix-A, and the local address routing table entry is hit, and there is no update to SRH.UET. According to SRH.UET being 0b10, the following main codes are executed in sequence:

[0256] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 6;

[0257] Step 2: Read SRH.List[SRH.SL] and get a.label-b, only 32 bits are read;

[0258] Step 3: Get the UET value 0b10 saved in the Context Field of a.label-b and update it to SRH.UET;

[0259] Step 4: Map a.label-b to prefix-B, and then copy it to the DA field of the outer IPv6 Header;

[0260] Step 5: According to the DA in the outer IPv6 Header, the routing table is searched for forwarding information (or forwarding information is directly obtained according to the ILM mapping table entry), and the message is forwarded to node B.

[0261] 3) When the message arrives at node B, the current DA is equal to prefix-B, and the local address routing table entry is hit, and there is no update to SRH.UET. According to SRH.UET being 0b10, the following main codes are executed in sequence:

[0262] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 5;

[0263] Step 2: Read SRH.List[SRH.SL] and get b.label-bc, only 32 bits are read;

[0264] Step 3: Get the UET value 0b10 saved in the Context Field of b.label-bc and update it to SRH.UET;

[0265] Step 4: Map b.label-bc to the peer interface IPv6 address of adjacency-BC, and then copy it to the DA field of the outer IPv6 Header;

[0266] Step 5: According to the DA in the outer IPv6 Header, the routing table is searched for forwarding information (or forwarding information is directly obtained according to the ILM mapping table entry), and the message is forwarded to node B.

[0267] 4) When the message arrives at node C, the local address routing table entry is hit according to the local interface IPv6 address whose current DA is equal to adjacency-BC, and there is no update to SRH.UET. According to SRH.UET being 0b10, the following main codes are executed in sequence:

[0268] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 4;

[0269] Step 2: Read SRH.List[SRH.SL] and get c.label-d, only 32 bits are read;

[0270] Step 3: Get the UET value 0b00 saved in the Context Field of c.label-d and update it to SRH.UET, which means that the compression domain after the message reaches node D will be switched to the traditional classic SRv6 domain. Therefore, node C needs to restore SRH.SL to a count in units of 128-bit classic SRv6 SID in advance. It only needs to divide SRH.SL by 4 and then round it to update its value, that is, SRH.SL = SRH.SL / 4, and get SRH.SL = 1;

[0271] Step 4: Map c.label-d to prefix-D, and then copy it to the DA field of the outer IPv6 Header;

[0272] Step 5: According to the DA in the outer IPv6 Header, the routing table is searched for forwarding information (or forwarding information is directly obtained according to the ILM mapping table entry), and the message is forwarded to node D.

[0273] 5) When the message arrives at node D, the current DA hits the local address routing table entry, and there is no update to SRH.UET. Continue to parse SRH. Since SRH.UET is 0b00, the Next SID is a 128-bit classic SRv6 SID, and the following main codes are executed in sequence:

[0274] Step 1: Subtract 1 from SRH.SL, and SRH.SL becomes 0;

[0275] Step 2: Read SRH.List[SRH.SL], get end.dt6-sid-d-uet0, read 128 bits;

[0276] Step 3: Copy end.dt6-sid-d-uet0 to the DA field of the outer IPv6 Header;

[0277] Step 4: According to the DA of the outer IPv6 Header, the routing table is searched to forward the message. The message will hit the local SID table entry, remove the outer IPv6 header and SRH, and continue to process the inner IPv6 payload. Specific embodiments

[0278] This embodiment describes a scenario where the entire SRv6 domain consists of three different compression domains. The above technical solution has already involved the SID mixing schemes of various compression domains. This embodiment mainly examines the situation where UET (1) and UET (2) type compression domains are adjacent. Both compression domains use 32-bit SIDs. In SRH, they can be assembled into the same 128-bit basic unit. Fig. 9 The network shown in the figure runs the ISIS protocol. Nodes S, X, and ABR1 are all configured to support UET(0), nodes ABR1, Y, and ABR2 are all configured to support UET(1), and nodes ABR2, Z, and D are all configured to support UET(2). Each node includes the corresponding UET Flag in the external flooding SRv6 capability information. All nodes are allocated 128-bit classic SRv6 SIDs per UET per SID, for example:

[0279] Node ABR1 allocates END SID end-sid-abr1-uet0 to UET(0) and allocates END SID end-sid-abr1-uet1 to UET(1);

[0280] Node ABR2 allocates END SID end-sid-abr2-uet0 to UET(0), allocates END SID end-sid-abr2-uet1 to UET(1), and allocates END SID end-sid-abr2-uet2 to UET(2);

[0281] Other nodes are similarly allocated SIDs and named in the same manner. For the naming of the 32-bit IPv4 address in the compression field of the UET(1) type, reference may be made to the first embodiment.

[0282] In addition, node ABR2 locally allocates label abr2.label-z for prefix-Z (for example, the loopback route of node Z), and node Z locally allocates label z.label-d for prefix-D (for example, the loopback route of node D).

[0283] Assume that an SR-TE path is established from the head node S to the tail node D, and its segment list is<node X,node ABR1, node Y, node ABR2, node Z, node D> ,This path may be calculated by the head node itself, or calculated by requesting the controller.

[0284] When it is necessary to translate this Segment List into a SID List, the head node (or controller) will check the route nodes along the Segment List and obtain the common compression capabilities of each route node. In this example, the head node or controller knows that node S / X / ABR1 has the compression capability of UET(0), node ABR1 / Y / ABR2 has the compression capability of UET(1), and node ABR2 / Z / D has the compression capability of UET(2). It can be inferred that node ABR1 is the boundary node of two different compression domains (UET(0) and UET(1)), and node ABR2 is the boundary node of two different compression domains (UET(1) and UET(2)). Based on the information of each UET and each SID announced by each node, this Segment List can be finally translated into a SID List (including SIDs related to VPN services) as follows: <end-sid-x-uet0, end-sid-abr1-uet0, 32bits-ipv4-y-uet1, 32bits-ipv4-abr2-uet2, abr2.label-z, z.label-d, end.dt6-sid-d-uet0> .

[0285] In the SRH encapsulated in the message, the four SIDs 32bits-ipv4-y-uet1, 32bits-ipv4-abr2-uet2, abr2.label-z, and z.label-d are assembled into a 128-bit basic unit, and the UET Flag in the Context Field of abr2.label-z is 0b10, while the UET Flag in the Context Field of z.label-d is 0b00. The initial value of SRH.SL is 4, and SRH.UET is set to 0b00.

[0286] The message forwarding process along the SR-TE path is similar to that in the foregoing embodiment. It should be noted that when the message enters the UET(1) type compression domain from node ABR1, SRH.SL will be quadrupled and SRH.UET will be set to 0b01. After that, the message will read the Next SID every 32 bits. In particular, on ABR2, the message will switch from the UET(1) type compression domain to the UET(2) type compression domain. At this time, SRH.SL is still counted in units of the original 32-bit SID, but SRH.UET is simply modified to 0b10. After the MPLS Label type SID is processed on node D, SRH.SL is restored to the count in units of the classic SRv6 SID of every 128 bits, and then SRH.UET is modified to 0b00, entering the classic SRv6 SRH processing flow. Specific embodiments

[0287] This embodiment is based on the first embodiment and discusses the interconnection and interoperability between two compressed domains with different SRv6 SID Locator Blocks that use a simple 32-bit IPv4 address or value as the SID. Fig.10 In the SRv6 network shown, the ISIS protocol is running, all nodes are configured to support UET(0) and UET(1), and the SRv6 capability information flooded externally contains UET Flag=0b01. All nodes are allocated 128-bit classic SRv6 SIDs per SID per UET, where the SIDs allocated to nodes S / X / ABR are in the same SRv6 SID Locator Block block1, and the SIDs allocated to nodes ABR / Y / D are in the same SRv6 SID Locator Block block2, for example:

[0288] Node S allocates END SID end-sid-block1-s-uet0 for UET(0) and ENDSID end-sid-block1-s-uet1 for UET(1). These SIDs are both in block1.

[0289] Node X allocates END SID end-sid-block1-x-uet0 for UET(0) and ENDSID end-sid-block1-x-uet1 for UET(1). These SIDs are both in block1.

[0290] Node ABR allocates END SID end-sid-block1-abr-uet0 for UET(0) and END SID end-sid-block1-abr-uet1 for UET(1). These SIDs are all in block1. Node ABR also allocates END SID end-sid-block2-abr-uet0 for UET(0) and END SID end-sid-block2-abr-uet1 for UET(1). These SIDs are all in block2.

[0291] Node Y allocates END SID end-sid-block2-y-uet0 for UET(0) and ENDSID end-sid-block2-y-uet1 for UET(1). These SIDs are both in block2.

[0292] Node D allocates END SID end-sid-block2-d-uet0 for UET(0) and ENDSID end-sid-block2-d-uet1 for UET(1). These SIDs are both in block2.

[0293] Assume that an SR-TE path is established from the head node S to the tail node D, and its segment list is<node X,node ABR, node Y, node D> ,This path may be calculated by the head node itself, or calculated by requesting the controller.

[0294] When it is necessary to translate this Segment List into a SID List, the head node (or controller) will check the route nodes along the Segment List (i.e., the Segments in the Segment List) to obtain the public compression capabilities of each node. In this example, all nodes have announced the UET(1) type compression capability and the SID corresponding to UET(1). Then the head node (or controller) can use all the SIDs corresponding to UET(1) in the SID List.

[0295] Assume that in the notification of all the above SIDs, the SID structure information indicates that end-sid-block1-s-uet1, end-sid-block1-x-uet1, and end-sid-block1-abr-uet1 are all in the same SRv6 SID Locator Blockblock1, and end-sid-block2-abr-uet1, end-sid-block2-y-uet1, and end-sid-block2-d-uet1 are all in the same SRv6 SID Locator Block block2, and the length of the SRv6 SIDLocator Node + the length of the SRv6 SID Function + the length of the SRv6 SID Arguments in the structure information does not exceed 32 bits. For example:

[0296] In the structure of end-sid-block1-x-uet1, the upper 32 bits are block1, and the next 32 bits are 32bits-ipv4-block1-x-uet1, which is the SRv6 SID Locator Node + SRv6 SID Function information;

[0297] Similarly, in the structure of end-sid-block1-abr-uet1, the upper 32 bits are block1, and the next 32 bits are 32bits-ipv4-block1-abr-uet1;

[0298] In the structure of end-sid-block2-abr-uet1, the upper 32 bits are block2, and the next 32 bits are 32bits-ipv4-block2-abr-uet1;

[0299] When the head node S encapsulates the SRH for the message, it can use a short 32-bit IPv4 address or value as the SID, and perceive the ABR as the boundary node of two different blocks 1 and block 2. The compressed SID List is <32bits-ipv4-block1-x-uet1, 32bits-ipv4-block1-abr-uet0, end-sid-block2-abr-uet1, 32bits-ipv4-block2-y-uet1, 32bits-ipv4-block2-d-uet1>. In SRH, the first two SIDs are assembled in a 128-bit basic unit, and the excess space is filled with zeros; the second two SIDs are assembled in a 128-bit basic unit, and the excess space is filled with zeros. The initial value of SRH.SL is 3, and SRH.UET is set to 0b01.

[0300] Or the above SID List can be optimized to <32bits-ipv4-block1-x-uet0, end-sid-block2-abr-uet1, 32bits-ipv4-block2-y-uet1, 32bits-ipv4-block2-d-uet1>, that is, switch the compression domain type on node X in advance to avoid inserting SIDs related to the two node ABRs. At this time, in the SRH, the first SID is assembled in a 128-bit basic unit, and the excess space is filled with zeros; the last two SIDs are assembled in a 128-bit basic unit, and the excess space is filled with zeros. The initial value of SRH.SL is 3, and SRH.UET is set to 0b01.

[0301] The specific message forwarding process will not be described in detail.

[0302] The present disclosure also provides an electronic device, comprising:

[0303] one or more processors;

[0304] A memory stores one or more programs, and when the one or more programs are executed by one or more processors, the one or more processors implement the above method provided by the present disclosure.

[0305] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU), etc.; the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH).

[0306] An embodiment of the present disclosure provides a computer-readable medium on which a computer program is stored. When the program is executed by a processor, the above method provided by the present disclosure is implemented.

[0307] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as 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 cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically contain 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 may include any information delivery media.

[0308] Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for limiting purposes. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly noted, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, those skilled in the art will appreciate that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A message encapsulation method, comprising: Determine the Segment Routing-Traffic Engineering SR-TE path; Generate a SID list according to the segment identifier SID of each node in the SR-TE path, wherein each of the nodes supports multiple universal SID encapsulation types UET, and the multiple UETs of the node correspond to SIDs of different lengths, respectively. In the SID list, the SID of at least a node that is an intermediate node of the SR-TE path is a SID with a length that is not the longest among the multiple SIDs corresponding to the node; Using the SID list to form a segment routing header SRH; Encapsulating the initial message using the SRH to obtain a final message; Each non-longest SID in the SID list is a SID obtained by compressing the original longest SID; and the SID list is generated according to the segment identifier SID of each node in the SR-TE path, including: The SID of at least one intermediate node carries a Flag indicating the length of the next SID of the SID of the intermediate node in the SID list.

2. The method according to claim 1, in, The method is applied to an SRv6 network; and The length of the longest SID corresponding to the multiple UETs is 128 bits, and the length of the corresponding non-longest SID is selected from the group consisting of 32 bits, 16 bits and 8 bits.

3. The method according to claim 1, wherein: Forming the SRH using the SID list includes: The SRH carries a Flag indicating the type of compression domain in which the message is located.

4. A message forwarding method, comprising: After receiving the final message sent by the previous node, the final message is parsed to obtain a SID list of each node in the SR-TE path, wherein the final message is the final message obtained by the encapsulation method according to claim 1; The final message is forwarded to the next hop node according to the SID list.

5. The method according to claim 4, wherein: Forwarding the final message to the next hop node according to the SID list includes: According to the Flag indicating the compression type of the next SID in the SID list and carried by the SID of the current node in the SID list, determining whether the next SID is a compressed SID and the corresponding compression type; In response to determining that the next SID is a compressed SID and the corresponding compression type, restoring the next SID in the SID list to an uncompressed SID; and According to the uncompressed SID, the final message is forwarded to a next hop node whose destination is the uncompressed SID.

6. An electronic device, comprising: one or more processors; A storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 5.

7. A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method according to any one of claims 1 to 5.

Images