Method and apparatus for encapsulating routing header of IPv6 packet

Abstract

An embodiment of the present invention provides a method and apparatus for encapsulating a routing header of an IPv6 packet. The method includes: a head node encapsulates a routing header for an IPv6 packet and sends the encapsulated IPv6 packet to the next node in the SRv6 domain. The routing header includes the following fields: Next Header: indicating the type of the inner header after the routing header; Hdr Ext Len: indicating the byte overhead of the routing header; Routing Type: indicating the type of the routing header; Segments Left: indicating the number of segments remaining to be accessed in the segment list included in the routing header; List Len: indicating the byte overhead of the segment list included in the routing header; Offset: indicating the position of the currently accessed Segment in the segment list; reserved fields; a plurality of <ST, CmprL, Segment>, where each <ST, CmprL, Segment> is an element in the segment list, ST indicating the type of the compressed segment; CmprL indicating the length of the common prefix; Segment indicating the compressed segment content; and an optional padding field.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communications, and in particular, to a method and apparatus for encapsulating a routing header of an IPv6 packet. Background Art

[0002] RFC8200 (Internet Protocol, Version 6 (IPv6) Specification) has formulated the IPv6 specification, which defines a Routing Header. The source node of the sent IPv6 packet can include some intermediate node information in the Routing Header to control the packet to access these intermediate nodes before reaching the final destination node. The Routing Type field in the Routing Header is extensible and can be set to different values to define different routing headers to meet different scenarios.

[0003] RFC6554 (An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks) defines a routing header (abbreviated as RH3 due to the value of the Routing Type field being 3) for source route forwarding based on compressed IPv6 address information for the low-power and lossy network scenario. In a low-power and lossy network, assuming that the IPv6 addresses of all nodes are within the same prefix, then when using RH3 for source route forwarding, each element in the segment list included in RH3 only needs to store the different part compared to other elements, and the common prefix of all elements is stored in the Destination Address field of the IPv6 Header. This achieves the purpose of saving the byte overhead of RH3. The applicable scenario of RH3 is very limited and does not support mixing multiple types of segments with multiple different part lengths in RH3.

[0004] RFC8754 (IPv6 Segment Routing Header) defines a routing header for source routing forwarding based on classical IPv6 addresses for the scenario where segment routing (SR) is applied to IPv6 networks, abbreviated as SRv6 (since the value of the Routing Type field is 4, it is abbreviated as RH4). In the SID List included in RH4, each element is an IPv6 address that occupies 16 bytes. When the instruction list is very long, it will result in a very long packet header, severely reducing the payload efficiency of the packet. Currently, the industry is considering introducing the ability to compress SRv6 segment identifiers (SIDs) in SRv6 networks to reduce the byte overhead of RH4. Since the types of services supported in SRv6 networks are rich and the traffic engineering capabilities are stronger, the above RH3 cannot be simply applied in SRv6 networks. Summary of the Invention

[0005] Embodiments of the present invention provide a method and device for encapsulating a routing header of an IPv6 packet, so as to at least solve the problem in the related art that when the SID list included in the SRv6 SRH is very long, it leads to low packet encapsulation efficiency, and even exceeds the packet processing capacity of the device, and its application in the actual network is very limited.

[0006] According to an embodiment of the present invention, a method for encapsulating a routing header of an IPv6 packet is provided, including:

[0007] The head node encapsulates the routing header of the IPv6 packet and sends the encapsulated IPv6 packet to the next node in the SRv6 domain, where the routing header includes the following fields:

[0008] Next Header: Occupies 8 bits and represents the type of the inner header after the routing header;

[0009] Hdr Ext Len: Occupies 8 bits and represents the byte overhead of the routing header;

[0010] Routing Type: Occupies 8 bits and represents the type of the routing header;

[0011] SegmentsLeft: Occupies 8 bits and represents the number of remaining segments to be accessed and processed in the segment list included in the routing header;

[0012] List Len: Represents the byte overhead of the segment list included in the routing header;

[0013] Offset: Is an unsigned integer occupying 12 bits and represents the position of the currently accessed Segment in the segment list;

[0014] Reserved: Occupies 12 bits, reserved field;

[0015] Multiple <ST, CmprL, Segment>, each <ST, CmprL, Segment> being an element in the segment list, where ST: Occupies 4 bits, representing the type of the compressed segment; CmprL: Occupies 4 bits, representing the length of the common prefix; Segment: Represents the compressed segment content, and its length is determined by ST;

[0016] Padding: Optional padding field.

[0017] In an exemplary embodiment, the routing header of the IPv6 packet further includes an optional TLV (Type - Length - Value) field.

[0018] In an exemplary embodiment, the ST includes one of the following types:

[0019] Type 0: Indicates that the corresponding Segment is a complete IPv6 address;

[0020] Type 1: Indicates that the corresponding Segment is a 1 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0021] Type 2: Indicates that the corresponding Segment is a 2 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0022] Type 3: Indicates that the corresponding Segment is a 3 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0023] Type 4: Indicates that the corresponding Segment is a 4 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0024] Type 5: Indicates that the corresponding Segment is a 5 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0025] Type 6: Indicates that the corresponding Segment is a 6 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0026] Type 7: Indicates that the corresponding Segment is a 7 - byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0027] Type 8: indicates that the corresponding Segment is an 8-byte fragment of an IPv6 address, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0028] Type 9: indicates that the corresponding Segment is a 3-byte MPLS Label index, and the complete IPv6 address can be obtained by querying the mapping table through this MPLS Label index;

[0029] Type 10: indicates that the corresponding Segment is a 4-byte SR-MPLS SID index, and the complete IPv6 address can be obtained by querying the mapping table through this SR-MPLS SID index;

[0030] Type 11: indicates that the corresponding Segment is a 4-byte BIER BFR-ID index, and the complete IPv6 address can be obtained by querying the mapping table through this BFR-ID index.

[0031] In an exemplary embodiment, when ST is of type 0, CmprL represents the actual length of the Segment field; when ST is of types 1 - 8, CmprL represents the length of the common prefix to which the corresponding Segment belongs; when ST is of types 9 - 11, the value of CmprL is meaningless.

[0032] In an exemplary embodiment, the segment list in the routing header is stored in ascending order.

[0033] In an exemplary embodiment, when all nodes in the SRv6 domain have the same common prefix for their SRv6 SIDs, the common prefix is stored in the DA of the IPv6 Header, and the different parts of the SRv6 SIDs of each node are stored as compressed information in the segment list of the routing header.

[0034] In an exemplary embodiment, when the head node encapsulates the routing header for the IPv6 packet, for the segment list <S1, S2, S3,..., Sn>, S1 is copied to the DA field of the IPv6 Header. If S1 is stored in the routing header, then Offset is set to point to the second element in the segment list of the routing header, Segment Left = n - 1, indicating that there are n - 1 segment elements remaining to be processed in the segment list, where n is a positive integer.

[0035] In an exemplary embodiment, when the head node encapsulates the routing header for the IPv6 packet, for the segment list <S1, S2, S3, ..., Sn>, it copies S1 to the DA field of the IPv6Header. If S1 is not stored in the routing header, the Offset is set to point to the first element in the segment list of the routing header, and Segment Left = n - 1, indicating that there are n - 1 segment elements remaining to be processed in the segment list, where n is a positive integer.

[0036] In an exemplary embodiment, the method further includes: when an intermediate node or a tail node in the SRv6 domain receives the IPv6 packet, if the DA in the IPv6Header matches the local IP address and the Next Header field of the IPv6Header indicates that the next lower layer header is the routing header, then continue to process the IPv6 packet.

[0037] In an exemplary embodiment, continuing to process the IPv6 packet includes: if Segments Left is equal to 0, then continue to process the inner payload, and the type of the inner payload is determined according to the Next Header field of the routing header; if Segments Left is not equal to 0, then decrement Segments Left by 1, read the next Segment, and the current value of Offset points to the start address of the next <ST, CmprL, Segment>. According to the type value of ST, read the Segment of the corresponding length, and combine the information of CmprL to convert the Segment into a complete new IPv6 address; make Offset point to the start address of the next <ST, CmprL, Segment>; if Offset is greater than List Len * 8, then discard the IPv6 packet and send an error message to the Source Address of the IPv6Header; if the IPv6Hop Limit value of the IPv6Header is less than or equal to 1, then discard the IPv6 packet and send an ICMP TimeExceeded - Hop Limit Exceeded in Transit message to the Source Address of the IPv6Header; if the IPv6Hop Limit of the IPv6Header is greater than 1, then decrement Hop Limit by 1; copy the converted new IPv6 address to the DA of the IPv6Header and forward the IPv6 packet according to the new DA by looking up the IPv6 routing table.

[0038] According to another embodiment of the present invention, there is provided a routing header encapsulation device for IPv6 packets, which is located in the head node. The device includes: an encapsulation module for encapsulating the routing header of the IPv6 packet; a sending module for sending the encapsulated IPv6 packet to the next node in the SRv6 domain. Wherein, the routing header includes the following fields:

[0039] Next Header: Occupies 8 bits, indicating the type of the inner header after the routing header;

[0040] Hdr Ext Len: Occupies 8 bits, indicating the byte overhead of the routing header;

[0041] Routing Type: Occupies 8 bits, indicating the type of the routing header;

[0042] Segments Left: Occupies 8 bits, indicating the number of remaining segments to be accessed and processed in the segment list included in the routing header;

[0043] List Len: Indicates the byte overhead of the segment list included in the routing header;

[0044] Offset: Is an unsigned integer occupying 12 bits, indicating the position of the currently accessed Segment in the segment list;

[0045] Reserved: Occupies 12 bits, reserved field;

[0046] Multiple <ST, CmprL, Segment>, each <ST, CmprL, Segment> being an element in the segment list, where ST: Occupies 4 bits, indicating the type of the compressed segment; CmprL: Occupies 4 bits, indicating the length of the common prefix; Segment: Represents the compressed segment content, and its length is determined by ST;

[0047] Padding: Optional padding field.

[0048] According to still another embodiment of the present invention, there is also provided a computer-readable storage medium, in which a computer program is stored. Wherein, the computer program is set to execute the steps in any one of the above method embodiments when running.

[0049] According to still another embodiment of the present invention, there is also provided an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is set to run the computer program to execute the steps in any one of the above method embodiments.

[0050] In the above embodiments of the present invention, a more flexible segment routing extension header that supports multiple segment types is provided, which provides multiple compression methods, supports the mixing of SIDs of any length, and can better deploy the segment routing function in the IPv6 network. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 is a hardware structure block diagram of a computer terminal according to an embodiment of the present invention.

[0052] Figure 2 is a flowchart of a routing header encapsulation method for IPv6 packets according to an embodiment of the present invention;

[0053] Figure 3 is an encapsulation format diagram of an extended SRH-MST according to an embodiment of the present invention;

[0054] Figure 4 is a network topology diagram according to Embodiment 1 of the present invention;

[0055] Figure 5 is an encapsulation format diagram in which all segments in SRH-MST are 2-byte IPv6 address fragments according to an embodiment of the present invention;

[0056] Figure 6 is an encapsulation format diagram in which each segment in SRH-MST is an IPv6 address fragment of different lengths according to an embodiment of the present invention;

[0057] Figure 7 According to an embodiment of the present invention, it is an encapsulation format diagram in which all segments in SRH-MST are 3-byte MPLS Labels;

[0058] Figure 8 is a structural schematic diagram of a routing header encapsulation device for IPv6 packets according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] In the following, embodiments of the present invention will be described in detail with reference to the drawings and in conjunction with the embodiments.

[0060] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above drawings are used to distinguish similar objects, and do not necessarily need to describe a specific order or sequence.

[0061] The method embodiments provided in the embodiments of the present application can be executed on a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 is a hardware structure block diagram of the computer terminal on which the method of the embodiment of the present invention runs. As Figure 1 shown, the computer terminal may include one or more (Figure 1 Only one processor 102 is shown (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a field-programmable gate array FPGA), and a memory 104 for storing data. Among them, the above computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 The structure shown is only schematic and does not limit the structure of the above computer terminal. For example, the computer terminal may further include more or fewer components than Figure 1 shown, or have a different configuration from Figure 1 shown.

[0062] The memory 104 can be used to store computer programs. For example, software programs and modules of application software, such as the computer program corresponding to the method in the embodiments of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above method. The memory 104 may include a high-speed random access memory, and may further include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely provided with respect to the processor 102, and these remote memories can be connected to other terminals through a network. Examples of the above network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0063] The transmission device 106 is used to receive or send data via a network. Specific examples of the above network may include a wireless network provided by a communication provider. In one instance, the transmission device 106 includes a network adapter (abbreviated as NIC), which can be connected to other network devices through a base station and thus communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0064] In this embodiment, a method for encapsulating a routing header of an IPv6 packet running on a network architecture is provided. Figure 2 It is a flowchart of the method according to the embodiments of the present invention, as Figure 1 shown, and the process includes the following steps:

[0065] Step S102, the head node encapsulates the routing header of the IPv6 packet;

[0066] Step S104, send the encapsulated IPv6 packet to the next node in the SRv6 domain, where the routing header includes the following fields:

[0067] Next Header: Occupies 8 bits, indicating the type of the inner header after the said routing header;

[0068] Hdr Ext Len: Occupies 8 bits, indicating the byte overhead of the said routing header;

[0069] Routing Type: Occupies 8 bits, indicating the type of the said routing header;

[0070] Segments Left: Occupies 8 bits, indicating the number of remaining segments to be accessed and processed in the segment list included in the said routing header;

[0071] List Len: Indicates the byte overhead of the segment list included in the said routing header;

[0072] Offset: Is an unsigned integer occupying 12 bits, indicating the position of the currently accessed Segment in the segment list;

[0073] Reserved: Occupies 12 bits, reserved field;

[0074] Multiple <ST, CmprL, Segment>, each <ST, CmprL, Segment> being an element in the said segment list, where ST: Occupies 4 bits, indicating the type of the compressed segment; CmprL: Occupies 4 bits, indicating the length of the common prefix; Segment: Represents the compressed segment content, and its length is determined by ST;

[0075] Padding: Optional padding field.

[0076] In this embodiment, the routing header of the said IPv6 packet further includes an optional TLV field.

[0077] In this embodiment, the said ST includes one of the following types:

[0078] Type 0: Indicates that the corresponding Segment is a complete IPv6 address;

[0079] Type 1: Indicates that the corresponding Segment is a 1-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0080] Type 2: Indicates that the corresponding Segment is a 2-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0081] Type 3: It indicates that the corresponding Segment is a 3-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0082] Type 4: It indicates that the corresponding Segment is a 4-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0083] Type 5: It indicates that the corresponding Segment is a 5-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0084] Type 6: It indicates that the corresponding Segment is a 6-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0085] Type 7: It indicates that the corresponding Segment is a 7-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0086] Type 8: It indicates that the corresponding Segment is an 8-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0087] Type 9: It indicates that the corresponding Segment is a 3-byte MPLS Label index, and the complete IPv6 address can be obtained by querying the mapping table through this MPLS Label index;

[0088] Type 10: It indicates that the corresponding Segment is a 4-byte SR-MPLS SID index, and the complete IPv6 address can be obtained by querying the mapping table through this SR-MPLS SID index;

[0089] Type 11: It indicates that the corresponding Segment is a 4-byte BIER BFR-ID index, and the complete IPv6 address can be obtained by querying the mapping table through this BFR-ID index.

[0090] In this embodiment, when ST is of type 0, CmprL represents the actual length of the Segment field; when ST is of types 1 - 8, CmprL represents the length of the common prefix to which the corresponding Segment belongs; when ST is of types 9 - 11, the value of CmprL is meaningless.

[0091] In this embodiment, the segment list in the routing header is stored in ascending order.

[0092] In this embodiment, when the SRv6 SIDs of all nodes in the SRv6 domain have the same common prefix, the common prefix is stored in the DA of the IPv6 Header, and the different parts of the SRv6 SIDs of each node are stored as compressed information in the segment list of the routing header.

[0093] In this embodiment, when the head node encapsulates the routing header for the IPv6 packet, for the segment list <S1, S2, S3,..., Sn>, copy S1 to the DA field of the IPv6 Header. If S1 is stored in the routing header, then Offset is set to point to the second element in the segment list of the routing header, and Segment Left = n - 1, indicating that there are n - 1 segment elements left to be processed in the segment list.

[0094] In this embodiment, when the head node encapsulates the routing header for the IPv6 packet, for the segment list <S1, S2, S3,..., Sn>, copy S1 to the DA field of the IPv6 Header. If S1 is not stored in the routing header, then Offset is set to point to the first element in the segment list of the routing header, and Segment Left = n - 1, indicating that there are n - 1 segment elements left to be processed in the segment list.

[0095] In this embodiment, the method further includes: when an intermediate node or a tail node in the SRv6 domain receives the IPv6 packet, if the DA in the IPv6 Header matches the local IP address and the Next Header field of the IPv6 Header indicates that the next layer header is the routing header, then continue to process the IPv6 packet.

[0096] In this embodiment, continuing to process the IPv6 packet includes: if Segments Left is equal to 0, then continue to process the inner payload, and the type of the inner payload is determined according to the Next Header field of the routing header; if Segments Left is not equal to 0, then decrement Segments Left by 1, read the next Segment, and the current value of Offset points to the start address of the next <ST, CmprL, Segment>. According to the type value of ST, read the Segment with the corresponding length, and combine the information of CmprL to convert the Segment into a complete new IPv6 address; make Offset point to the start address of the next <ST, CmprL, Segment>; if Offset is greater than List Len * 8, then discard the IPv6 packet and send an error message to the Source Address of the IPv6 header; if the IPv6 Hop Limit value of the IPv6 header is less than or equal to 1, then discard the IPv6 packet and send an ICMP Time Exceeded - Hop Limit Exceeded in Transit message to the Source Address of the IPv6 header; if the IPv6 Hop Limit of the IPv6 header is greater than 1, then decrement Hop Limit by 1; copy the converted new IPv6 address to the DA of the IPv6 header and forward the IPv6 packet according to the new DA by looking up the IPv6 routing table.

[0097] To facilitate the understanding of the technical solutions provided in the embodiments of the present invention, the following will be described in conjunction with embodiments of specific application scenarios.

[0098] Considering the following actual requirements of the SRv6 network, a new routing header is proposed in the embodiments of the present invention to meet some of the following requirements.

[0099] Requirement 1: The IPv6 address planning of all nodes in the SRv6 network may be regular (i.e., the IPv6 addresses of these nodes all have the same common prefix), or very messy. In both cases, there is a need for a corresponding mechanism to compress the SRv6 SID List in the packet.

[0100] Requirement 2: The path represented by the SRv6 SID List may cross multiple domains with different IPv6 address plans. Therefore, the compressed SRv6 SID List needs to support multiple types of compressed segment identifiers, and different types of compressed segment identifiers have different compressed lengths. For example, the length of some compressed segment identifiers is 4 bytes, and some are 2 bytes.

[0101] Requirement 3: When an IPv6 packet is forwarded according to the SRv6 SID List, useful information saved in multiple fields (such as Traffic Class, Flow label) in the IPv6 Header cannot be lost.

[0102] Requirement 4: After the SRv6 SID List in the IPv6 packet is compressed, it must be able to restore the original uncompressed SRv6 SID List information only based on the information carried in the packet itself, rather than relying on some control information on each node in the network or the forwarding information given in the forwarding table entries, because these information may oscillate and change, and there is a timing mismatch problem with the IPv6 packets already sent by the head node. This requirement is very beneficial for third-party offline tools to parse packets.

[0103] Requirement 5: Support interoperability with the network where RH4 has been deployed.

[0104] Requirement 6: When a packet is forwarded segment by segment, there must be pointer information to truly and accurately reflect how many remaining segments are to be processed.

[0105] In the existing SRv6 SRH (i.e., RH4), each SID in the Segment ID List (SID List) is a 128-bit IPv6 address. When the SID List is very long, the packet encapsulation efficiency is very low, even exceeding the packet processing capacity of the device, and its application in the actual network is very limited. In this embodiment, a new routing header and its usage method are introduced to solve this problem.

[0106] This embodiment adopts the following technical solution: Based on the Routing Header defined in RFC8200, a new routing header is introduced, and multiple segment types are supported in the segment list. We call this new routing header SRH-MST (Segment Routing Header with Multiple Segment Type). Assume that the value of the Routing Type field applied to the IANA (Internet Assigned Numbers Authority) is 5.

[0107] Figure 3 is the format of SRH-MST, and the descriptions of each field are as follows:

[0108] Next Header: Occupies 8 bits, indicating the type of the inner header immediately following SRH-MST. Its definition and value can refer to RFC8200.

[0109] Hdr Ext Len: Occupies 8 bits, representing the byte overhead of SRH-MST, that is, how many 8-byte units are included in SRH-MST, excluding the first 8-byte unit. Its definition and value range can be referred to RFC8200. Note that in the segment list included in the SRH-MST described in this patent, each segment may be a compressed value, that is, each segment is not necessarily 16 bytes, so the value of HdrExt Len is not necessarily twice the number of segments in the segment list.

[0110] Routing Type: Occupies 8 bits, and the value of this field is to be assigned by IANA (Internet Assigned Numbers Authority), indicating that this routing header is SRH-MST.

[0111] Segments Left: Occupies 8 bits, representing how many segments are left to be accessed and processed in the segment list included in SRH-MST. Its definition and value range can be referred to RFC8200.

[0112] List Len: The byte overhead of the segment list included in SRH-MST, that is, how many 8-byte units the entire segment list contains. Note that the length of the entire segment list must be aligned to 8 bytes, that is, an integer multiple of 8 bytes. For this purpose, meaningless 0s may need to be filled after the last Segment (i.e., Segment N). List Len must be less than HdrExt Len.

[0113] Offset: An unsigned integer occupying 12 bits. Its function is that when the segment list included in SRH-MST is regarded as an array in bytes (assumed to be denoted as Segment List[]), the subscript of the currently accessed Segment in Segment List[]. When accessing elements in the segment list according to Offset, the access range must not exceed the range represented by List Len * 8.

[0114] Reserved: Occupies 12 bits, reserved field, undefined.

[0115] Each of the following <ST, CmprL, Segment> describes an element in the segment list.

[0116] ST: Occupies 4 bits, Segment Type, representing the type of the compressed segment. The following types are currently defined:

[0117] 0: Indicates that the corresponding Segment is a complete IPv6 address. Note that the corresponding Segment field does not necessarily occupy 16 bytes, and its length is given by CmprL. This is because the lower bits of many IPv6 addresses are 0, and it is not necessary to actually store the entire 16 bytes in the Segment field;

[0118] 1: Indicates that the corresponding Segment is a 1-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0119] 2: Indicates that the corresponding Segment is a 2-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0120] 3: Indicates that the corresponding Segment is a 3-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0121] 4: Indicates that the corresponding Segment is a 4-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0122] 5: Indicates that the corresponding Segment is a 5-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0123] 6: Indicates that the corresponding Segment is a 6-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0124] 7: Indicates that the corresponding Segment is a 7-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0125] 8: Indicates that the corresponding Segment is an 8-byte IPv6 address fragment, which can be concatenated with the corresponding common prefix to form a complete IPv6 address;

[0126] 9: Indicates that the corresponding Segment is a 3-byte MPLS Label. Through this MPLS Label, the mapping table can be queried to obtain the complete IPv6 address;

[0127] 10: Indicates that the corresponding Segment is a 4-byte SR-MPLSSID (index). Through this SR-MPLSSID, the mapping table can be queried to obtain the complete IPv6 address;

[0128] 11: Indicates that the corresponding Segment is a 4-byte BIER BFR-ID. Through this BFR-ID, the complete IPv6 address can be obtained by querying the mapping table;

[0129] It should be noted that in this embodiment, in addition to the above types, other type values of ST can also be defined.

[0130] CmprL: Occupies 4 bits, Common Prefix Length, the length of the common prefix (in bytes). When ST is 0, CmprL represents the actual length of the Segment field; when ST is the address segment type represented by 1 to 8, CmprL represents the length of the common prefix to which the corresponding Segment belongs; when ST is a mapping index such as MPLS Label, SR-MPLS SID, BIER BFR-ID, etc., the value of CmprL is meaningless and can be set to 0.

[0131] Segment: The compressed segment content, and its length is determined by ST, as described above.

[0132] Padding: Optional padding field, and its content also belongs to the segment list. It must be filled with 0 to ensure that the entire segment list is aligned in 8-byte units, that is, the List Len is an integer multiple of 8. If the segment list already meets the 8-byte alignment, there is no need for a Padding field.

[0133] Optional Type Length Value objects: SRH-MST can also contain optional TLVs for various more advanced application scenarios.

[0134] In this embodiment, the segment list in SRH-MST is stored in ascending order. For example, for a logical SegmentList<S1, S2, S3,..., Sn>, where S1 is the first Segment logically and Sn is the last Segment logically. As Figure 1 shown, the compressed information of S1 is stored in the Segment 1 field, and the compressed information of Sn is stored in the Segment N field. Note that it is also feasible to design the segment list in SRH-MST to be stored in descending order, just like the existing SRH (Segment Routing Header, refer to RFC8754). However, considering the simplicity of the processing flow, the ascending order storage method is selected in this embodiment.

[0135] In this embodiment, when the head node encapsulates SRH-MST for a packet:

[0136] For the above Segment List<S1, S2, S3,..., Sn>, S1 will be copied to the DA field of the IPv6 Header. If S1 is also stored in the SRH-MST (i.e., the compressed information of S1 is stored in the Segment 1 field), then the Offset needs to be set to point to the Segment 2 field, i.e., Offset = 1 + sizeof(Segment 1). Additionally, SegmentLeft = n - 1, indicating that there are n - 1 segment elements remaining to be processed in the segment list.

[0137] Optionally, to further save the byte overhead of the SRH-MST, for the above Segment List<S1, S2, S3,..., Sn>, since S1 has been copied to the DA field of the IPv6 Header, the head node can also not store S1 in the SRH-MST. Then the SRH-MST only needs to contain n - 1 Segments. At this time, the compressed information of S2 is stored in the Segment 1 field, and the compressed information of Sn is stored in the Segment N - 1 field. The Offset needs to be set to point to the Segment 1 field, i.e., Item Offset = 0. Additionally, Segment Left = n - 1, indicating that there are n - 1 segment elements remaining to be processed in the segment list.

[0138] In the following embodiments, how to store the compressed segment information in the segment list of the SRH-MST in different scenarios will be further described.

[0139] In the embodiment, when an IPv6 packet is received at an intermediate node or a tail node, if the DA in the IPv6 Header matches the local IP address and the Next Header field of the IPv6 Header indicates that the next layer header is the SRH-MST, then continue to process the SRH-MST according to the following process:

[0140]

[0141]

[0142] Compared with the prior art, this embodiment provides a more flexible segment routing extension header that supports multiple segment types, provides multiple compression methods, supports the mixing of SIDs of any length, and can better deploy the segment routing function in the IPv6 network.

[0143] Embodiment 1

[0144] This example describes that each segment element in the segment list of the SRH-MST uses a 16-bit IPv6 address fragment as the compressed SID content. AsFigure 4 In the network shown, all nodes are assigned 128-bit classical SRv6 SIDs, and these SRv6 SIDs are all in the same common prefix (2001:db80:: / 32). For example:

[0145] Node S is assigned the Node SID 2001:db80:0100:: for identifying the node;

[0146] Node A is assigned the Node SID 2001:db80:0a00:: for identifying the node;

[0147] Node B is assigned the Node SID 2001:db80:0b00:: for identifying the node, and in addition, an Adjacency SID 2001:db80:0b01:: for identifying the link is assigned for the three-layer link B->C;

[0148] Node C is assigned the Node SID 2001:db80:0c00:: for identifying the node;

[0149] Node D is assigned the Node SID 2001:db80:0d00:: for identifying the node;

[0150] Suppose an SRv6-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 requested from the controller for calculation. This Segment List can be translated into the SID List <2001:db80:0a00::, 2001:db80:0b00::, 2001:db80:0b01::, 2001:db80:0d00::>.

[0151] Since the above Adjacency SID 2001:db80:0b01:: for identifying the link is itself routable, the above SID List can be optimized to <2001:db80:0a00::, 2001:db80:0b01::, 2001:db80:0d00::>.

[0152] On the head node S, when forwarding the packet along the above SID List, an IPv6 Header + SRH-MST can be encapsulated for the packet. Since these SIDs have the same common prefix, the common prefix can be stored in the DA of the IPv6 Header, and the different parts of these SIDs are stored in the segment list of the SRH-MST as compressed information, as Figure 5 shown:

[0153] The <ST,ComprL,Segment> corresponding to the first segment element is <2,4,0a00>, indicating that the Segment 1 field stores a 2-byte IPv6 address fragment. This IPv6 address fragment can be concatenated with the corresponding 4-byte common prefix to form a complete IPv6 address, and the common prefix is stored in the DA of the IPv6Header.

[0154] The <ST,ComprL,Segment> corresponding to the second segment element is <2,4,0b01>, indicating that the Segment 2 field also stores a 2-byte IPv6 address fragment. This IPv6 address fragment can be concatenated with the corresponding 4-byte common prefix to form a complete IPv6 address, and the common prefix is stored in the DA of the IPv6Header.

[0155] The <ST,ComprL,Segment> corresponding to the third segment element is <2,4,0d00>, indicating that the Segment 3 field also stores a 2-byte IPv6 address fragment. This IPv6 address fragment can be concatenated with the corresponding 4-byte common prefix to form a complete IPv6 address, and the common prefix is stored in the DA of the IPv6Header.

[0156] To ensure that the length of the segment list is an integer multiple of 8 bytes, the Padding field occupies 7 bytes. At this time, List Len is set to 2, indicating that the byte overhead of the entire segment list occupies 2 8-byte units.

[0157] The following describes the forwarding process of the packet along this SR-TE path:

[0158] 1) The packet is forwarded from the head node S to the logically first Segment Node (i.e., node A). Since the head node knows the original SID List before compression, it can directly set the DA of the IPv6Header to the first SID (2001:db80:0a00::) of the SID List.

[0159] In this example, since the first SID (2001:db80:0a00::) is also stored in the segment list of the SRH-MST after compression, when the packet is sent, the Offset field of the SRH-MST needs to be offset to point to the second segment element, that is, Offset = sizeof<ST,CmprL,Segment 1> = 3.

[0160] The Segment Left field of the SRH-MST is set to 2, indicating that there are 2 segment elements left to be processed.

[0161] The message will look up the routing table according to the DA in the IPv6 Header and forward it to Node A.

[0162] 2) When the message arrives at Node A, since the DA in the IPv6 Header is equal to 2001:db80:0a00:: and it hits the local local SID entry, it will continue to identify the inner payload as a routing header according to the Next Header in the IPv6 Header, and identify it as SRH-MST according to the Routing Type of the routing header, and sequentially execute the following code to process SRH-MST:

[0163] Step1: Check and find that Segment Left is greater than 0, then subtract 1 from Segment Left to become 1;

[0164] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 3]. First read the first byte, and get the <ST,ComprL> information as <2,4>, which means that the Segment field stores a 2-byte IPv6 address fragment, then continue to read 2 bytes to get 0x0b01;

[0165] Step3: The Offset field is offset to point to the third segment element, that is, Offset = Offset + sizeof<ST,CmprL,Segment 2> = 6.

[0166] Step4: Convert 0x0b01 into a complete 16-byte IPv6 address, that is, obtain the common prefix (2001:db80::) from the logical high 4 bytes of the DA in the IPv6 Header, concatenate it with 0x0b01 to get 2001:db80:0b01::, and then copy it to the DA field of the IPv6 Header;

[0167] Step5: Look up the routing table and forward the message according to the DA in the IPv6 Header. The message will be forwarded to Node B.

[0168] 3) When the message arrives at Node B, since the DA in the IPv6 Header is equal to 2001:db80:0b01:: and it hits the local local SID entry, it will continue to identify the inner payload as a routing header according to the Next Header in the IPv6 Header, and identify it as SRH-MST according to the Routing Type of the routing header, and sequentially execute the following code to process SRH-MST:

[0169] Step1: If it is found that Segment Left is greater than 0, then decrement Segment Left by 1 to make it 0;

[0170] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 6]. First, read the first byte and get the <ST,ComprL> information as <2,4>, which indicates that the Segment field stores a 2-byte IPv6 address fragment. Then continue to read 2 bytes to get 0x0d00;

[0171] Step3: The Offset field is offset to point to the fourth segment element, that is, Offset = Offset + sizeof<ST,CmprL,Segment 3> = 9. Note that there is actually no fourth segment element here.

[0172] Step4: Convert 0x0d00 into a complete 16-byte IPv6 address. That is, obtain the common prefix (2001:db80::) from the upper 4 bytes of the logical high part of the DA in the IPv6Header, concatenate it with 0x0d00 to get 2001:db80:0d00::, and then copy it to the DA field of the IPv6Header;

[0173] Step5: Since the above-hit local SID entry indicates that the packet should be forwarded along link B-C, there is no need to look up the routing table based on the DA of the IPv6Header. Instead, directly forward the packet along link B-C.

[0174] 4) When the packet arrives at node C, the DA of the IPv6Header is equal to 2001:db80:0d00::, which is not the local address of node C. Then node C continues to look up the routing table based on the DA of the IPv6Header and forwards the packet to node D.

[0175] 5) When the packet arrives at node D, since the DA of the IPv6Header is equal to 2001:db80:0d00::, it hits the local local SID entry. Then continue to identify the inner payload as a routing header based on the Next Header of the IPv6Header, and identify it as SRH-MST based on the Routing Type of the routing header. Execute the following code to process SRH-MST:

[0176] Step1: If it is found that Segment Left is equal to 0, then remove the IPv6header and SRH-MST, and continue to identify and process the inner payload based on the Next Header field of the SRH-MST.

[0177] It should be noted that although the encapsulation and forwarding process of packets is described by taking ST = 2 alone as an example in this embodiment, in fact, the processing of other STs (from 1 to 8) is similar. It's just that the lengths of the respective segment elements <ST, CmprL, Segment> in the SRH-MST segment list will be different from those in this embodiment. Additionally, it will also affect the settings of the corresponding List Len field and Offset field in the SRH-MST. For example, for a segment element <ST, CmprL, Segment> with ST = 4, its length is 5 bytes. When reading such a segment element from the SRH-MST, the Offset will be incremented by 5.

[0178] Embodiment 2

[0179] Based on Embodiment 1, this embodiment examines the segment elements with mixed different ST types in the SRH-MST. Still as Figure 4 shown, all nodes are allocated 128-bit classical SRv6 SIDs. Assume that the SRv6 SIDs of nodes S, A, and B are all in the same common prefix (2001:db80:: / 32), and the SRv6 SIDs of nodes C and D are all in the same common prefix (2002:db80:: / 32). For example:

[0180] Node S is allocated the Node SID 2001:db80:0100:: for identifying the node;

[0181] Node A is allocated the Node SID 2001:db80:0a00:: for identifying the node;

[0182] Node B is allocated the Node SID 2001:db80:0b00:: for identifying the node. Additionally, an Adjacency SID 2001:db80:0b01:: for identifying the link is allocated for the three-layer link B->C;

[0183] Node C is allocated the Node SID 2002:db80:0c00:: for identifying the node;

[0184] Node D is allocated the Node SID 2002:db80:0d00:: for identifying the node;

[0185] Similarly, assume an SRv6-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 Segment List can be translated into the SID List <2001:db80:0a00::, 2001:db80:0b01::, 2002:db80:0d00::>.

[0186] At the head node S, when forwarding the packet along the above SID List, an IPv6Header+SRH-MST can be encapsulated for the packet. Since the first SID and the second SID in the SID List have the same common prefix in the SID List, they can share the common prefix in the DA of the IPv6Header, and only store their different parts in the segment list of the SRH-MST; since the prefix of the third SID is different from the prefix of the adjacent previous SID, the complete SID information needs to be stored in the SRH-MST. The specific encapsulation of the SRH-MST is as Figure 6 shown:

[0187] The <ST, ComprL, Segment> corresponding to the first segment element is <2, 4, 0a00>, indicating that the Segment 1 field stores a 2-byte IPv6 address fragment, which can be concatenated with the corresponding 4-byte long common prefix to form a complete IPv6 address, and the common prefix is stored in the DA of the IPv6Header.

[0188] The <ST, ComprL, Segment> corresponding to the second segment element is <2, 4, 0b01>, indicating that the Segment 2 field also stores a 2-byte IPv6 address fragment, which can be concatenated with the corresponding 4-byte long common prefix to form a complete IPv6 address, and the common prefix is stored in the DA of the IPv6Header.

[0189] The <ST, ComprL, Segment> corresponding to the third segment element is <0, 6, 2002:db80:0d00>, indicating that the Segment3 field stores a 6-byte complete IPv6 address (as the high part of the IPv6 address, padded with zeros at the low part).

[0190] To ensure that the length of the segment list is an integer multiple of 8 bytes, the Padding field occupies 3 bytes. At this time, List Len is set to 2, indicating that the byte overhead of the entire segment list occupies 2 8-byte units.

[0191] Next, the forwarding process of the packet along this SR-TE path will be described:

[0192] 1) The packet is forwarded from the head node S to the logically first Segment Node (i.e., node A). Since the head node has the original SID List before compression, it can directly set the DA of the IPv6 Header to the first SID (2001:db80:0a00::) in the SID List.

[0193] In this example, since the first SID (2001:db80:0a00::) is also stored in the segment list of SRH-MST after compression, when the packet is sent, the Offset field of SRH-MST needs to be offset to point to the second segment element, i.e., Offset = sizeof<ST, CmprL, Segment 1> = 3.

[0194] The Segment Left field of SRH-MST is set to 2, indicating that there are still 2 segment elements to be processed.

[0195] The packet will forward to node A by looking up the routing table according to the DA of the IPv6 Header.

[0196] 2) When the packet arrives at node A, since the DA of the IPv6 Header is equal to 2001:db80:0a00::, it hits the local SID table entry. Then, continue to identify the inner payload as a routing header according to the Next Header of the IPv6 Header, and identify it as SRH-MST according to the Routing Type of the routing header. Then, execute the following code to process SRH-MST sequentially:

[0197] Step1: Check and find that Segment Left is greater than 0, then subtract 1 from Segment Left to become 1;

[0198] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 3]. First, read the first byte to get the <ST, ComprL> information as <2, 4>, which indicates that the Segment field stores a 2-byte IPv6 address fragment. Then, continue to read 2 bytes to get 0x0b01;

[0199] Step3: The Offset field is offset to point to the third segment element, i.e., Offset = Offset + sizeof<ST, CmprL, Segment 2> = 6.

[0200] Step4: Convert 0x0b01 into a complete 16-byte IPv6 address. That is, obtain the common prefix (2001:db80::) from the upper 4 bytes of the logical high part of the DA in the IPv6Header, concatenate it with 0x0b01 to get 2001:db80:0b01::, and then copy it to the DA field of the IPv6Header;

[0201] Step5: Forward the packet according to the DA in the IPv6Header by looking up the routing table. The packet will be forwarded to node B.

[0202] 3) When the packet arrives at node B, since the DA in the IPv6Header is equal to 2001:db80:0b01:: and hits the local SID table entry, continue to identify the inner payload as a routing header according to the Next Header in the IPv6Header, and identify it as SRH-MST according to the Routing Type of the routing header. Then execute the following code to process SRH-MST sequentially:

[0203] Step1: Check and find that Segment Left is greater than 0, then decrement Segment Left by 1 to become 0;

[0204] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 6]. First read the first byte, and get the <ST,ComprL> information as <0,6>. It can be known that the Segment field stores the upper part of a 6-byte complete IPv6 address, so continue to read 6 bytes to get 2002:db80:0d00;

[0205] Step3: The Offset field is offset to point to the fourth segment element, that is, Offset = Offset + sizeof<ST,CmprL,Segment 3> = 13. Note that there is actually no fourth segment element here.

[0206] Step4: Copy 2002:db80:0d00:: to the DA field of the IPv6Header;

[0207] Step5: Since the local SID table entry hit above indicates that the packet should be forwarded along link B-C, there is no need to look up the routing table according to the DA in the IPv6Header, and directly forward the packet along link B-C.

[0208] 4) When the packet arrives at node C, the DA of the IPv6Header is equal to 2001:db80:0d00::, which is not the local address of node C. Then node C continues to search the routing table according to the DA of the IPv6Header and forwards the packet to node D.

[0209] 5) When the packet arrives at node D, according to the DA of the IPv6Header being equal to 2001:db80:0d00::, the local local SID entry is hit. Then continue to identify the inner payload as a routing header according to the Next Header of the IPv6Header, and identify it as SRH-MST according to the Routing Type of the routing header, and execute the following code to process SRH-MST:

[0210] Step1: Check and find that Segment Left is equal to 0. Then remove the IPv6header and SRH-MST, and continue to identify and process the inner payload according to the Next Header field of SRH-MST.

[0211] Embodiment III

[0212] The foregoing embodiments are all examples of compression schemes for address splicing methods. They rely on all nodes or a part of the nodes in the network having the same common prefix for their SIDs. However, in some IPv6 networks, due to historical address planning reasons, it is very difficult to plan the SIDs of the nodes in the network (even a small number of nodes) within the same common prefix. In order to deploy segment routing in such IPv6 networks, we need to consider a scheme that uses a short index to map the complete IPv6 address. This embodiment discusses using an MPLS label as the short index, and other types of indexes such as the prefix-SID of SR-MPLS or the BFR-ID of BIER are similar.

[0213] Still in the Figure 4 network shown, all nodes are assigned 128-bit classical SRv6 SIDs, for example:

[0214] Node S is assigned the Node SID 2001:db80::0100 for identifying the node;

[0215] Node A is assigned the Node SID 2002:db80::0a00 for identifying the node;

[0216] Node B is assigned the Node SID 2003:db80::0b00 for identifying the node;

[0217] Node C is assigned the Node SID 2004:db80::0c00 for identifying the node;

[0218] Node D assigns Node SID 2005:db80::0d00 for identifying the node;

[0219] These SIDs have no common prefix.

[0220] Suppose each node also assigns a short MPLS label for its own SID and advertises the corresponding mapping relationship between the MPLS label and the SID to other nodes in the network. After other nodes receive it, they can reassign the incoming label locally, create the corresponding incoming label forwarding entry, and give the mapping SID information in the incoming label forwarding entry. There are various ways to assign and advertise labels, such as LDP, SR-MPLS, etc. In the MPLS architecture, the SID here is equivalent to a kind of FEC. To make the description concise, we assume that for a FEC, the values of its incoming label and outgoing label are exactly equal. For example:

[0221] Node S receives the advertisement of label (label-a) for SID 2002:db80::0a00 from Node A, and Node S also assigns the incoming label (label-a) for this SID;

[0222] Node A receives the advertisement of label (label-b) for SID 2003:db80::0b00 from Node B, and Node A also assigns the incoming label (label-b) for this SID;

[0223] Node B receives the advertisement of label (label-c) for SID 2004:db80::0c00 from Node C, and Node B also assigns the incoming label (label-c) for this SID;

[0224] Node C receives the advertisement of label (label-d) for SID 2005:db80::0d00 from Node D, and Node C also assigns the incoming label (label-d) for this SID;

[0225] Node D assigns label (label-d) for SID 2005:db80::0d00;

[0226] Suppose an SRv6-TE path is established from the head node S to the tail node D, and its Segment List is <node A, node B, node C, node D>. This path may be calculated by the head node itself or requested from the controller for calculation. Although this Segment List can be translated into the SID List <2002:db80::0a00, 2003:db80::0b00, 2004:db80::0c00, 2005:db80::0d00>, encapsulating such an SID List in the SRH-MST will incur a very large byte overhead. Since the head node or the controller knows the short indexes mapped to these SIDs, a more optimal SID List is <label-a, label-b, label-c, label-d>.

[0227] On the head node S, when forwarding the packet along the above SID List, an IPv6Header+SRH-MST can be encapsulated for the packet.

[0228] As Figure 7 shown:

[0229] The <ST, ComprL, Segment> corresponding to the first segment element is <9, 0, label-a>, indicating that the 3-byte MPLS Label is stored in the Segment 1 field, and the complete IPv6 address is obtained by querying the incoming label mapping entry with this MPLS Label.

[0230] The <ST, ComprL, Segment> corresponding to the second segment element is <9, 0, label-b>, indicating that the 3-byte MPLS Label is stored in the Segment 2 field, and the complete IPv6 address is obtained by querying the incoming label mapping entry with this MPLS Label.

[0231] The <ST, ComprL, Segment> corresponding to the third segment element is <9, 0, label-c>, indicating that the 3-byte MPLS Label is stored in the Segment 3 field, and the complete IPv6 address is obtained by querying the incoming label mapping entry with this MPLS Label.

[0232] The <ST, ComprL, Segment> corresponding to the fourth segment element is <9, 0, label-d>, indicating that the 3-byte MPLS Label is stored in the Segment 4 field, and the complete IPv6 address is obtained by querying the incoming label mapping entry with this MPLS Label.

[0233] Since the length of the segment list is already an integer multiple of 8 bytes, there is no need to fill in Padding. At this time, List Len is set to 2, indicating that the byte overhead of the entire segment list occupies 2 8-byte units.

[0234] The forwarding process of the packet along this SR-TE path will be described below:

[0235] 1) The packet is forwarded from the head node S to the logically first Segment Node (i.e., node A). Since the head node knows the original SID List <2002:db80::0a00, 2003:db80::0b00, 2004:db80::0c00, 2005:db80::0d00> before compression, it can directly set the DA of the IPv6 Header to the first SID (2002:db80::0a00). Alternatively, the head node can query the corresponding input label mapping entry according to the first SID (i.e., label-a) of the compressed SID List <label-a, label-b, label-c, label-d>, obtain the SID (2002:db80::0a00) information, and then copy it to the DA field of the IPv6 Header.

[0236] In this example, since the first SID (label-a) is also stored in the segment list of SRH-MST, when the packet is sent, the Offset field of SRH-MST needs to be offset to point to the second segment element, i.e., Offset = sizeof<ST, CmprL, Segment 1> = 4.

[0237] The Segment Left field of SRH-MST is set to 3, indicating that there are 3 segment elements left to be processed.

[0238] The packet will forward to node A by looking up the routing table according to the DA of the IPv6 Header.

[0239] 2) When the packet arrives at node A, according to the DA of the IPv6 Header being equal to 2002:db80::0a00, the local local SID entry is hit. Then, continue to identify the inner payload as a routing header according to the Next Header of the IPv6 Header, and identify it as SRH-MST according to the Routing Type of the routing header. Sequentially execute the following code to process SRH-MST:

[0240] Step1: Check and find that Segment Left is greater than 0, then decrement Segment Left by 1 to become 2;

[0241] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 4]. First, read the first byte, and the <ST, ComprL> information obtained is <9, 0>. It can be known that the Segment field stores a 3-byte MPLS Label. Then continue to read 3 bytes to get label-b;

[0242] Step3: The Offset field is offset to point to the third segment element, that is, Offset = Offset + sizeof<ST, CmprL, Segment 2> = 8.

[0243] Step4: Query the corresponding incoming label mapping entry according to label-b, obtain the SID (2003:db80::0b00) information, and then copy it to the DA field of the IPv6Header;

[0244] Step5: According to the DA of the IPv6Header, search the routing table to forward the packet, and the packet will be forwarded to node B.

[0245] 3) When the packet arrives at node B, since the DA of the IPv6Header is equal to 2003:db80::0b00, the local local SID entry is hit. Then continue to identify the inner payload as a routing header according to the Next Header of the IPv6Header, and identify it as SRH-MST according to the Routing Type of the routing header. Sequentially execute the following code to process SRH-MST:

[0246] Step1: Check and find that Segment Left is greater than 0, then decrement Segment Left by 1 to become 1;

[0247] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 4]. First, read the first byte, and the <ST, ComprL> information obtained is <9, 0>. It can be known that the Segment field stores a 3-byte MPLS Label. Then continue to read 3 bytes to get label-c;

[0248] Step3: The Offset field is offset to point to the fourth segment element, that is, Offset = Offset + sizeof<ST, CmprL, Segment 2> = 12.

[0249] Step4: Query the corresponding incoming label mapping table entry according to label-c, obtain the SID (2004:db80::0c00) information, and then copy it to the DA field of the IPv6Header;

[0250] Step5: According to the DA of the IPv6Header, search the routing table to forward the packet, and the packet will be forwarded to node C.

[0251] 4) When the packet arrives at node C, since the DA of the IPv6Header is equal to 2004:db80::0c00 and the local local SID table entry is hit, continue to identify the inner payload as a routing header according to the Next Header of the IPv6Header, and identify it as SRH-MST according to the Routing Type of the routing header, and sequentially execute the following code to process SRH-MST:

[0252] Step1: Check and find that Segment Left is greater than 0, then subtract 1 from Segment Left to become 0;

[0253] Step2: Read the next Segment element from the segment list, that is, read Segment List[Offset = 4]. First, read the first byte to get the <ST,ComprL> information as <9,0>, and it can be known that the Segment field stores a 3-byte MPLS Label, then continue to read 3 bytes to get label-d;

[0254] Step3: The Offset field is offset to point to the fifth segment element, that is, Offset = Offset + sizeof<ST,CmprL,Segment 2> = 16. Note that there is actually no fifth element here.

[0255] Step4: Query the corresponding incoming label mapping table entry according to label-d, obtain the SID (2005:db80::0d00) information, and then copy it to the DA field of the IPv6Header;

[0256] Step5: According to the DA of the IPv6Header, search the routing table to forward the packet, and the packet will be forwarded to node C.

[0257] 5) When the packet arrives at node D, since the DA of the IPv6Header is equal to 2005:db80::0d00 and it hits the local local SID entry, it continues to identify the inner payload as a routing header based on the Next Header of the IPv6Header, and identifies it as SRH-MST based on the Routing Type of the routing header, and executes the following code to process SRH-MST:

[0258] Step1: Check and find that Segment Left is equal to 0, then remove the IPv6header and SRH-MST, and continue to identify and process the inner payload according to the Next Header field of SRH-MST.

[0259] In this embodiment, the reason for not directly using MPLS forwarding is that the network is not a pure MPLS network. For example, nodes S and A are not directly connected, and there may be other IPv6-only nodes in between. This embodiment only uses the label mapping relationship of MPLS, rather than the traditional MPLS packet forwarding behavior.

[0260] Embodiment 4

[0261] It can be easily deduced from the foregoing embodiments that it is also possible to encapsulate segment elements of ST(0-8) and ST(9-11) types simultaneously in the segment list of SRH-MST. This is essentially because the decapsulation of each segment element is independent and there is no dependency relationship between them. For example, in the segment list, the compression information contained in the current segment element is completely given by its own <ST, CmprL, Segment> triple, and the complete IPv6 address can be independently obtained therefrom, which has nothing to do with the previous or next segment element in the segment list.

[0262] For the packet forwarding process of SRH-MST containing segment elements of any type, it is completely similar to the foregoing embodiments and will not be elaborated here.

[0263] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, in essence, or the part that makes a contribution to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present invention.

[0264] In this embodiment, a routing header encapsulation device for IPv6 packets is further provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated here. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0265] Figure 8 is a structural block diagram of a routing header encapsulation device for IPv6 packets according to an embodiment of the present invention. As Figure 8 shown, this device is located in the head node 100 of the SRv6 domain, and this device includes an encapsulation module 10 and a sending module 20.

[0266] The encapsulation module 10 is used to encapsulate the routing header of the IPv6 packet. The sending module 20 is used to send the encapsulated IPv6 packet to the next node in the SRv6 domain. Among them, the routing header includes the following fields:

[0267] Next Header: Occupies 8 bits, indicating the type of the inner layer header after the routing header;

[0268] Hdr Ext Len: Occupies 8 bits, indicating the byte overhead of the routing header;

[0269] Routing Type: Occupies 8 bits, indicating the type of the routing header;

[0270] Segments Left: Occupies 8 bits, indicating the number of remaining segments to be accessed in the segment list included in the routing header;

[0271] List Len: Represents the byte overhead of the segment list included in the routing header;

[0272] Offset: Is an unsigned integer occupying 12 bits, indicating the position of the currently accessed Segment in the segment list;

[0273] Reserved: Occupies 12 bits, reserved field;

[0274] Multiple <ST, CmprL, Segment>, each <ST, CmprL, Segment> is an element in the segment list, where ST: Occupies 4 bits, indicating the type of the compressed segment; CmprL: Occupies 4 bits, indicating the length of the common prefix; Segment: Represents the compressed segment content, and its length is determined by ST;

[0275] Padding: Optional padding field.

[0276] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to this: the above-mentioned modules are all located in the same processor; or, the above-mentioned various modules are separately located in different processors in any combination form.

[0277] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored. Among them, the computer program is set to execute the steps in any one of the above method embodiments when running.

[0278] In an exemplary embodiment, the above computer-readable storage medium may include but is not limited to: various media such as USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical discs that can store computer programs.

[0279] An embodiment of the present invention further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is set to run the computer program to execute the steps in any one of the above method embodiments.

[0280] In an exemplary embodiment, the above electronic device may further include a transmission device and input / output devices. Among them, the transmission device is connected to the above processor, and the input / output devices are connected to the above processor.

[0281] The specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be repeated here.

[0282] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present invention can be implemented by a general-purpose computing device. They can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order from here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. In this way, the present invention is not limited to any specific combination of hardware and software.

[0283] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for encapsulating a routing header of an IPv6 packet, characterized in that, including: The head node encapsulates the routing header for the IPv6 packet and sends the encapsulated IPv6 packet to the next node in the SRv6 domain. The routing header includes the following fields: Next Header: Occupies 8 bits, indicating the type of the inner header after the routing header; Hdr Ext Len: Occupies 8 bits, indicating the byte overhead of the routing header; Routing Type: Occupies 8 bits, indicating the type of the routing header; Segments Left: Occupies 8 bits, indicating the number of remaining segments to be accessed in the segment list included in the routing header; List Len: Indicates the byte overhead of the segment list included in the routing header; Offset: Is an unsigned integer occupying 12 bits, indicating the position of the currently accessed Segment in the segment list; Reserved: Occupies 12 bits, reserved field; Multiple <ST, CmprL, Segment>, each <ST, CmprL, Segment> being an element in the segment list, where ST: Occupies 4 bits, indicating the type of the compressed segment; CmprL: Occupies 4 bits, indicating the length of the common prefix; Segment: Represents the compressed segment content, and its length is determined by ST; Padding: Optional padding field.

2. The method according to claim 1, wherein The routing header of the IPv6 packet further includes an optional type length value TLV field.

3. The method according to claim 1, wherein The ST includes one of the following types: Type 0: Indicates that the corresponding Segment is a complete IPv6 address; Type 1: Indicates that the corresponding Segment is a 1-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 2: Indicates that the corresponding Segment is a 2-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 3: Indicates that the corresponding Segment is a 3-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 4: Indicates that the corresponding Segment is a 4-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 5: Indicates that the corresponding Segment is a 5-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 6: Indicates that the corresponding Segment is a 6-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 7: Indicates that the corresponding Segment is a 7-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 8: Indicates that the corresponding Segment is an 8-byte IPv6 address fragment, and this IPv6 address fragment can be concatenated with the corresponding common prefix to form a complete IPv6 address; Type 9: Indicates that the corresponding Segment is a 3-byte MPLS Label index. Through this MPLS Label index, the complete IPv6 address can be obtained by querying the mapping table; Type 10: Indicates that the corresponding Segment is a 4-byte SR-MPLS SID index. Through this SR-MPLS SID index, the complete IPv6 address can be obtained by querying the mapping table; Type 11: Indicates that the corresponding Segment is a 4-byte BIER BFR-ID index. Through this BFR-ID index, the complete IPv6 address can be obtained by querying the mapping table.

4. The method according to claim 3, wherein Among them, When ST is of type 0, CmprL represents the actual length of the Segment field; when ST is of type 1-8, CmprL represents the length of the common prefix to which the corresponding Segment belongs; when ST is of type 9-11, the value of CmprL is meaningless.

5. The method according to claim 1, wherein Among them, The segment list in the routing header is stored in ascending order.

6. The method according to claim 1, characterized in that Among them, When all nodes in the SRv6 domain have the same common prefix for their SRv6 SIDs, the common prefix is stored in the DA of the IPv6 Header, and the different parts of the SRv6 SIDs of each node are stored as compressed information in the segment list of the routing header.

7. The method according to claim 1, characterized in that, Among them, When the head node encapsulates the routing header for the IPv6 packet, for the segment list <S1, S2, S3,..., Sn>, copy S1 to the DA field of the IPv6 Header. If S1 is saved in the routing header, then Offset is set to point to the second element in the segment list of the routing header, and Segment Left = n - 1, indicating that there are n - 1 segment elements left to be processed in the segment list, where n is a positive integer.

8. The method according to claim 1, characterized in that When the head node encapsulates the routing header for the IPv6 packet, for the segment list <S1, S2, S3,..., Sn>, copy S1 to the DA field of the IPv6 Header. If S1 is not stored in the routing header, then Offset is set to point to the first element in the segment list of the routing header, and SegmentLeft = n - 1, indicating that there are n - 1 segment elements left to be processed in the segment list, where n is a positive integer.

9. The method according to claim 1, characterized in that, The method further includes: When an intermediate node or a tail node in the SRv6 domain receives the IPv6 packet, if the DA in the IPv6 Header matches the local IP address and the Next Header field of the IPv6 Header indicates that the next layer header is the routing header, then continue to process the IPv6 packet.

10. The method according to claim 9, wherein Among them, Continuing to process the IPv6 packet includes: If Segments Left is equal to 0, then continue to process the inner payload, and the type of the inner payload is determined according to the Next Header field of the routing header; If Segments Left is not equal to 0, decrement Segments Left by 1, read the next Segment, and the current value of Offset points to the start address of the next <ST, CmprL, Segment>. According to the type value of ST, read the Segment of the corresponding length, and combine the information of CmprL to convert the Segment into a complete new IPv6 address; Make Offset point to the start address of the next next <ST, CmprL, Segment>; If Offset is greater than List Len * 8, discard the IPv6 packet and send an error message to the SourceAddress of the IPv6 Header; If the IPv6 Hop Limit value in the IPv6 Header is less than or equal to 1, discard the IPv6 packet and send an ICMP Time Exceeded - Hop Limit Exceeded in Transit message to the Source Address of the IPv6 Header; if the IPv6 Hop Limit value in the IPv6 Header is greater than 1, decrement the Hop Limit value by 1; Copy the converted new IPv6 address to the DA of the IPv6 Header and forward the IPv6 packet according to the new DA by looking up the IPv6 routing table.

11. A routing header encapsulation device for IPv6 packets, located in the head node, characterized in that, Includes: An encapsulation module for encapsulating the routing header of the IPv6 packet; A sending module for sending the encapsulated IPv6 packet to the next node in the SRv6 domain, where the routing header includes the following fields: Next Header: Occupies 8 bits, indicating the type of the inner header after the routing header; Hdr Ext Len: Occupies 8 bits, indicating the byte overhead of the routing header; Routing Type: Occupies 8 bits, indicating the type of the routing header; Segments Left: Occupies 8 bits, indicating the number of remaining segments to be accessed in the segment list included in the routing header; List Len: Indicates the byte overhead of the segment list included in the routing header; Offset: An unsigned integer occupying 12 bits, indicating the position of the currently accessed Segment in the segment list; Reserved: Occupies 12 bits, reserved field; Multiple <ST, CmprL, Segment>, each <ST, CmprL, Segment> being an element in the segment list, where ST: Occupies 4 bits, indicating the type of the compressed segment; CmprL: Occupies 4 bits, indicating the length of the common prefix; Segment: Represents the compressed segment content, and its length is determined by ST; Padding: Optional padding field.

12. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein when the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 10 are implemented.

13. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of the method described in any one of claims 1 to 10 are implemented.

Images