CN112491708A

CN112491708A - Routing header encapsulation method and device of IPv6 message

Info

Publication number: CN112491708A
Application number: CN202011105906.1A
Authority: CN
Inventors: 彭少富
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2020-10-15
Filing date: 2020-10-15
Publication date: 2021-03-12
Also published as: WO2022078509A1

Abstract

The embodiment of the invention provides a method and a device for encapsulating a routing header of an IPv6 message, wherein the method comprises the following steps: the head node encapsulates an IPv6 message by a routing head and sends the encapsulated IPv6 message to the next node of the SRv6 domain, wherein the routing head comprises the following fields: next Header: indicating an inner header type following the routing header; hdr Ext Len: represents the byte overhead of the routing header; routing Type: indicating a type of the routing header; segments Left: representing the number of the segments which remain to be accessed in the segment list contained in the routing header; list Len: a byte overhead representing a segment list contained by the routing header; offset: represents the position of the currently accessed Segment in the Segment list; reserving a field; a plurality of < ST, CmprL, Segment >, each < ST, CmprL, Segment > being an element in the Segment list, wherein ST represents the type of Segment after compression; CmprL denotes the length of the common prefix; segment represents compressed Segment content; an optional padding field.

Description

Routing header encapsulation method and device of IPv6 message

Technical Field

The embodiment of the invention relates to the field of communication, in particular to a method and a device for encapsulating a routing header of an IPv6 message.

Background

RFC8200(Internet Protocol, Version 6(IPv6) Specification) sets forth an IPv6 Specification, in which a Routing Header is defined, and a source node sending an IPv6 message may include some intermediate node information in the Routing Header to control the message to access intermediate nodes before reaching a final destination node. The Routing Type field in the Routing Header is extensible, and different values can be set to define different Routing headers and meet different scenes.

RFC6554(An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and loss Networks) defines a Routing Header for Source Routing forwarding based on compressed IPv6 address information (since the value of the Routing Type field is 3, it is abbreviated as RH3), for Low-Power and Lossy network scenarios. In low-power consumption and lossy networks, assuming that the IPv6 addresses of all nodes are within the same prefix (prefix), when RH3 is used for source routing forwarding, each element in the segment list contained in RH3 only needs to store its difference part compared with other elements, and the common prefix of all elements is stored in the Destination Address field of IPv6 Header. This achieves the goal of saving the byte overhead of RH 3. The applicable scenarios of RH3 are very limited, and do not support the blending of multiple types of segments with multiple different part lengths in RH 3.

RFC8754(IPv6 Segment Routing Header) also defines a Routing Header for source Routing forwarding based on a classic IPv6 address (RH 4 for short because the value of the Routing Type field is 4) for a scenario where Segment Routing (Segment Routing) is applied to an IPv6 network, SRv6 for short. Each element in a segment identifier List (SID List) contained in RH4 is an IPv6 address occupying 16 bytes, which results in a long header when the instruction List is long, and thus the payload efficiency of the packet is seriously reduced. The industry is currently considering the introduction of compression capability for SRv6 Segment Identification (SID) in SRv6 networks to reduce the byte overhead of RH 4. Because SRv6 has abundant supported service types and stronger traffic engineering capability, the RH3 cannot be easily applied to SRv6 network.

Disclosure of Invention

The embodiment of the invention provides a method and a device for encapsulating a routing header of an IPv6 message, which are used for at least solving the problems that the message encapsulation efficiency is low, even exceeds the message processing capacity of equipment and the application in an actual network is very limited due to the fact that a segment identification list contained in SRv6 SRH in the related technology is very long.

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

the head node encapsulates an IPv6 message by a routing head and sends the encapsulated IPv6 message to the next node of the SRv6 domain, wherein the routing head comprises the following fields:

next Header: 8 bits, representing an inner header type after the routing header;

hdr Ext Len: occupying 8 bits, representing the byte overhead of the routing header;

routing Type: occupying 8 bits and representing the type of the routing header;

segments Left: occupying 8 bits and representing the number of the segments left to be accessed and processed in the segment list contained in the routing header;

list Len: a byte overhead representing a segment list contained by the routing header;

offset: the unsigned integer occupying 12 bits represents the position of the Segment currently accessed in the Segment list;

reserved: occupying 12 bits and reserving fields;

a plurality of < ST, CmprL, Segment >, each < ST, CmprL, Segment > being an element in the Segment list, wherein ST: 4 bits, representing the type of the compressed segment; CmprL: 4 bits are occupied, and the length of the common prefix is represented; segment: represents the compressed segment content, the length of which is determined by ST;

padding: an optional padding field.

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

In one exemplary embodiment, the ST comprises one of the following types:

type 0: indicating that the corresponding Segment is a complete IPv6 address;

type 1: an IPv6 address fragment indicating that the corresponding Segment is 1 byte, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 2: an IPv6 address fragment indicating that the corresponding Segment is 2 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 3: an IPv6 address fragment indicating that the corresponding Segment is 3 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 4: an IPv6 address fragment indicating that the corresponding Segment is 4 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 5: an IPv6 address fragment indicating that the corresponding Segment is 5 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 6: an IPv6 address fragment indicating that the corresponding Segment is 6 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 7: an IPv6 address fragment indicating that the corresponding Segment is 7 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 8: an IPv6 address fragment indicating that the corresponding Segment is 8 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

type 9: the MPLS Label index which represents that the corresponding Segment is 3 bytes can be used for inquiring the mapping table to obtain the complete IPv6 address;

type 10: the SR-MPLS SID index with the corresponding Segment being 4 bytes can be used for inquiring the mapping table to obtain a complete IPv6 address;

type 11: and a BIER BFR-ID index which indicates that the corresponding Segment is 4 bytes can be used for inquiring the mapping table to obtain the complete IPv6 address.

In one exemplary embodiment, when ST is 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.

In an exemplary embodiment, the segment list in the routing header is stored in a positive order.

In an exemplary embodiment, when SRv6 SIDs of all nodes of the SRv6 domain have the same common prefix, the common prefix is stored in the DA of the IPv6Header, and the difference part of the SRv6 SIDs of each node is stored as compressed information in the segment list of the routing Header.

In an exemplary embodiment, when the head node encapsulates the routing Header to the IPv6, for a Segment list < S1, S2, S3.. multidot.sn >, S1 is copied to a DA field of an IPv6Header, if S1 is stored in the routing Header, Offset is set to point to a second element in the Segment list in the routing Header, and Segment Left is n-1, which indicates that n-1 Segment elements remain in the Segment list to be processed, where n is a positive integer.

In an exemplary embodiment, when the head node encapsulates the routing Header for the IPv6, for a Segment list < S1, S2, S3.. multidot.sn >, S1 is copied to a DA field of an IPv6Header, if S1 is not stored in the routing Header, Offset is set to point to a first element in the Segment list in the routing Header, and Segment Left is n-1, which indicates that n-1 Segment elements remain in the Segment list to be processed, where n is a positive integer.

In one exemplary embodiment, the method further comprises: and when the intermediate node or the tail node of the SRv6 domain receives the IPv6 message, if the DA in the IPv6Header is matched with the local IP address and the Next Header field of the IPv6Header prompts that the Next layer Header is the routing Header, the IPv6 message is continuously processed.

In an exemplary embodiment, continuing to process the IPv6 message includes: if the Segments Left is equal to 0, continuing to process the inner layer load, wherein the type of the inner layer load is determined according to a Next Header field of the routing Header; if the Segments Left is not equal to 0, subtracting 1 from the Segments Left, reading the next Segment, wherein the current value of Offset points to the head address of the next < ST, CmprL and Segment >, reading the Segment with the corresponding length according to the type value of the ST, and converting the Segment into a complete new IPv6 address by combining the information of CmprL; let Offset point to the next < ST, CmprL, Segment > first address; if the Offset is larger than List Len × 8, discarding the IPv6 message, and sending an error message to the Source Address of the IPv6 Header; if the IPv6 Hop Limit value of the IPv6Header is less than or equal to 1, discarding the IPv6 message and sending an ICMP TimeExceedTime-Hop Limit Exceeded in Transit message to the Source Address of the IPv6 Header; if the IPv6 Hop Limit of the IPv6Header is greater than 1, subtracting 1 from the Hop Limit; and copying the new IPv6 address obtained by conversion to the DA of the IPv6Header, and checking an IPv6 routing table according to the new DA to forward the IPv6 message.

According to another embodiment of the present invention, there is provided a routing header encapsulation apparatus for an IPv6 packet, where the apparatus is located in a header node, and the apparatus includes: the encapsulation module is used for encapsulating the routing header of the IPv6 message; a sending module, configured to send the encapsulated IPv6 packet to a next node in SRv6 domain, where the routing header includes the following fields:

routing Type: occupying 8 bits and representing the type of the routing header;

reserved: occupying 12 bits and reserving fields;

padding: an optional padding field.

According to a further embodiment of the present invention, there is also provided a computer-readable storage medium having a computer program stored thereon, wherein the computer program is arranged to perform the steps of any of the above method embodiments when executed.

According to yet another embodiment of the present invention, there is also provided an electronic device, including a memory in which a computer program is stored and a processor configured to execute the computer program to perform the steps in any of the above method embodiments.

In the above embodiments of the present invention, a segment routing extension header that more flexibly supports multiple segment types is provided, multiple compression modes are provided, mixed compilation of SIDs of any length is supported, and a segment routing function can be better deployed in an IPv6 network.

Drawings

Fig. 1 is a block diagram of a hardware configuration of a computer terminal according to an embodiment of the present invention.

Fig. 2 is a flowchart of a routing header encapsulation method of an IPv6 message according to an embodiment of the present invention;

FIG. 3 is a diagram of the encapsulation format of an extended SRH-MST according to an embodiment of the present invention;

FIG. 4 is a network topology diagram according to a first embodiment of the invention;

FIG. 5 is a diagram of the encapsulation format of a 2-byte IPv6 address fragment for all segments in an SRH-MST according to an embodiment of the present invention;

FIG. 6 is a diagram of the encapsulation format of IPv6 address fragments with different lengths for segments in SRH-MST according to an embodiment of the present invention;

FIG. 7 is a diagram of a package format for an SRH-MST with all segments being 3-byte MPLS Label, according to an embodiment of the present invention;

fig. 8 is a schematic structural diagram of a routing header encapsulating device of an IPv6 message according to an embodiment of the present invention.

Detailed Description

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings in conjunction with the embodiments.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

The method embodiments provided in the embodiments of the present application may be executed in a computer terminal or a similar computing device. Taking the operation on a computer terminal as an example, fig. 1 is a hardware structure block diagram of a computer terminal on which the method of the embodiment of the present invention operates. As shown in fig. 1, the computer terminal may include one or more processors 102 (only one is shown in fig. 1) (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), and a memory 104 for storing data, wherein the computer terminal may further include a transmission device 106 for communication function and an input-output device 108. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration and is not intended to limit the structure of the computer terminal. For example, the computer terminal may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

The memory 104 can be used for storing computer programs, for example, software programs and modules of application software, such as computer programs corresponding to the methods in the embodiments of the present invention, and the processor 102 executes the computer programs stored in the memory 104 to execute various functional applications and data processing, i.e., to implement the methods described above. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to other terminals over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider. In one example, the transmission device 106 includes a Network adapter (NIC), which can be connected to other Network devices through a base station so as to communicate with the internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

In this embodiment, a method for encapsulating a routing header of an IPv6 message running in a network architecture is provided, and fig. 2 is a flowchart of a method according to an embodiment of the present invention, as shown in fig. 1, the method includes the following steps:

step S102, the head node encapsulates the IPv6 message by a routing head;

step S104, sending the encapsulated IPv6 message to the next node of SRv6 domain, wherein the routing header comprises the following fields:

routing Type: occupying 8 bits and representing the type of the routing header;

reserved: occupying 12 bits and reserving fields;

padding: an optional padding field.

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

In the present embodiment, the ST includes one of the following types:

type 0: indicating that the corresponding Segment is a complete IPv6 address;

In the present embodiment, when ST is 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.

In this embodiment, the segment list in the routing header adopts a positive order storage manner.

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 IPv6Header, and the difference part of the SRv6 SIDs of each node is stored in the segment list of the routing Header as compressed information.

In this embodiment, when the head node encapsulates the routing Header to the IPv6, for a Segment list < S1, S2, S3.,. Sn >, S1 is copied to a DA field of an IPv6Header, if S1 is stored in the routing Header, Offset is set to point to a second element in the Segment list in the routing Header, and Segment Left is n-1, which indicates that n-1 Segment elements remain in the Segment list to be processed.

In this embodiment, when the head node encapsulates the routing Header for the IPv6, for a Segment list < S1, S2, S3., > Sn >, S1 is copied to a DA field of an IPv6Header, if S1 is not stored in the routing Header, Offset is set to point to a first element in the Segment list in the routing Header, and Segment Left is n-1, which indicates that n-1 Segment elements remain in the Segment list to be processed.

In this embodiment, the method further includes: and when the intermediate node or the tail node of the SRv6 domain receives the IPv6 message, if the DA in the IPv6Header is matched with the local IP address and the Next Header field of the IPv6Header prompts that the Next layer Header is the routing Header, the IPv6 message is continuously processed.

In this embodiment, the continuing to process the IPv6 message includes: if the Segments Left is equal to 0, continuing to process the inner layer load, wherein the type of the inner layer load is determined according to a Next Header field of the routing Header; if the Segments Left is not equal to 0, subtracting 1 from the Segments Left, reading the next Segment, wherein the current value of Offset points to the head address of the next < ST, CmprL and Segment >, reading the Segment with the corresponding length according to the type value of the ST, and converting the Segment into a complete new IPv6 address by combining the information of CmprL; let Offset point to the next < ST, CmprL, Segment > first address; if the Offset is larger than List Len × 8, discarding the IPv6 message, and sending an error message to the Source Address of the IPv6 Header; if the IPv6 Hop Limit value of the IPv6Header is less than or equal to 1, discarding the IPv6 message and sending an ICMP TimeExceedTime-Hop Limit Exceeded in Transit message to the Source Address of the IPv6 Header; if the IPv6 Hop Limit of the IPv6Header is greater than 1, subtracting 1 from the Hop Limit; and copying the new IPv6 address obtained by conversion to the DA of the IPv6Header, and checking an IPv6 routing table according to the new DA to forward the IPv6 message.

In order to facilitate understanding of the technical solutions provided by the embodiments of the present invention, the following description will be made with reference to embodiments of specific application scenarios.

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

Requirement 1: SRv6 the IPv6 address plans of all nodes in the network may be very regular (i.e., the IPv6 addresses of the nodes all have the same common prefix) or very cluttered, both of which require a corresponding mechanism to compress the SRv6SID List in the message.

Requirement 2: the SRv6SID List may traverse multiple domains with different IPv6 address plans, and thus the compressed SRv6SID List needs to support multiple types of compressed segment identifiers, where the different types of compressed segment identifiers have different compressed lengths, for example, some compressed segment identifiers have a length of 4 bytes and some compressed segment identifiers have a length of 2 bytes.

Requirement 3: when the IPv6 message is forwarded according to the SRv6SID List, useful information stored in a plurality of fields (such as Traffic Class and Flow label) in the IPv6Header cannot be lost.

Requirement 4: after the SRv6SID List in the IPv6 message is compressed, the original uncompressed SRv6SID List information must be restored only according to the information carried by the message itself, and the information cannot depend on some control information on each node in the network or forwarding information given in the forwarding table entry, because the information may oscillate and change, there is a timing problem that is mismatched with the IPv6 message already sent by the head node. This requirement is very beneficial for third party offline tools to parse the message.

Requirement 5: support interworking with networks already deployed with RH 4.

Requirement 6: when the message is forwarded segment by segment, pointer information is needed to truly and accurately reflect the number of the remaining segments to be processed.

In a segment identifier List (SID List) included in an existing SRv6 SRH (i.e., RH4), each SID is a 128-bit IPv6 address, and when SIDList is long, the packet encapsulation efficiency is very low, even exceeds the packet processing capability of the device, and the application in an actual network is very limited. The embodiment introduces a new routing header and a method for using the same to solve the problem.

The embodiment adopts the following technical scheme: based on the Routing Header defined in RFC8200, a new Routing Header is introduced, wherein a Segment list can support a plurality of Segment types, and the new Routing Header is called SRH-MST (Segment Routing Header with Multiple Segment type). Assume that the Routing Type field proposed for application to IANA (Internet Assigned Numbers Automation Internet digital Assistant) has a value of 5.

FIG. 3 is a format of SRH-MST, where the fields are described as follows:

next Header: takes 8 bits and indicates the type of inner header immediately following the SRH-MST. Its definition and value can be referred to RFC 8200.

Hdr ExtLen: and 8 bits are occupied, which represents the byte overhead of the SRH-MST, namely how many 8 bytes are contained in the SRH-MST, and the first 8 bytes are not considered. Its definition and value can be referred to RFC 8200. Note that in the segment list contained in the SRH-MST described in this patent, each segment may be a compressed value, i.e., each segment is not necessarily 16 bytes, so the value of Hdr Ext Len is not necessarily twice the number of segments in the segment list.

Routing Type: the routing header occupies 8 bits, and the value of the field is to be distributed by IANA (Internet Assigned Numbers Authority Internet digital distribution agency), which indicates that the routing header is SRH-MST.

Segments Left: and 8 bits are occupied, which indicates how many segments are left to be accessed and processed in the segment list contained in the SRH-MST. Its definition and value can be referred to RFC 8200.

ListLen: the byte overhead of the segment list contained in SRH-MST, i.e., how many 8 bytes the entire segment list contains. Note that the length of the entire segment list must be aligned in 8 bytes, i.e., an integer multiple of 8 bytes. For this purpose, it may be necessary to fill in the meaningless 0 after the last Segment (i.e., Segment N). List Len must be smaller than Hdr Ext Len.

Offset: the 12-bit unsigned integer has the effect that when the Segment List contained in the SRH-MST is considered as an array in bytes (assumed to be Segment List [ ]), the currently accessed Segment is a subscript in the Segment List [ ]. When an element in the segment List is accessed according to Offset, the access range must not exceed the range represented by List Len 8.

Reserved: 12 bits, reserved field, undefined.

Each < ST, CmprL, Segment > below describes an element in the paragraph list.

ST: the Segment Type, which is 4 bits, represents the Type of the compressed Segment. The following types are currently defined:

0: indicating 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, because the lower part of many IPv6 addresses is 0, and it is not really necessary to put the entire 16 bytes into the Segment field;

1: an IPv6 address fragment indicating that the corresponding Segment is 1 byte, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

2: an IPv6 address fragment indicating that the corresponding Segment is 2 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

3: an IPv6 address fragment indicating that the corresponding Segment is 3 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

4: an IPv6 address fragment indicating that the corresponding Segment is 4 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

5: an IPv6 address fragment indicating that the corresponding Segment is 5 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

6: an IPv6 address fragment indicating that the corresponding Segment is 6 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

7: an IPv6 address fragment indicating that the corresponding Segment is 7 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

8: an IPv6 address fragment indicating that the corresponding Segment is 8 bytes, wherein the IPv6 address fragment can be spliced with the corresponding public prefix into a complete IPv6 address;

9: the MPLS Label with the corresponding Segment of 3 bytes is expressed, and the complete IPv6 address can be obtained by inquiring the mapping table through the MPLS Label;

10: SR-MPLS SID (index) with 4 bytes of corresponding Segment is represented, and the complete IPv6 address can be obtained by querying the mapping table through the SR-MPLS SID;

11: representing the corresponding Segment is BIER BFR-ID with 4 bytes, and the complete IPv6 address can be obtained by querying the mapping table through the BFR-ID;

it should be noted that, in the present embodiment, in addition to the above-mentioned types, other types of values of ST may be defined.

CmprL: takes 4 bits, Common Prefix Length, 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 fragment type represented by 1-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 has no meaning and can be set to 0.

Segment: the length of the compressed segment content is determined by ST, as described above.

Padding: the optional padding field, whose content also belongs to the segment List, must be padded with 0 to ensure that the entire segment List is aligned by 8 bytes, i.e., List Len is an integer multiple of 8. If the segment list would have satisfied 8-byte alignment, then there is no Padding field needed.

Optinal Type Length Value objects: the SRH-MST may also contain optional TLVs for various other higher-level application scenarios.

In this embodiment, the Segment List in SRH-MST is stored in positive order, for example, for a logical Segment List < S1, S2, S3., Sn >, where S1 is the logical first Segment and Sn is the logical last Segment. As shown in fig. 1, the Segment1 field stores compressed information of S1, and the Segment N field stores compressed information of Sn. Note that it is also feasible to design the Segment list in the SRH-MST to adopt a reverse order storage manner, just as in the SRH (Segment Routing Header, refer to RFC8754) in the prior art, but in consideration of the concise line of the processing flow, the forward order storage manner is selected in the present embodiment.

In this embodiment, when the head node encapsulates the SRH-MST for the packet:

for Segment List < S1, S2, S3, as, Sn >, S1 above, to be copied to the DA field of IPv6Header, if S1 is also stored in SRH-MST (i.e. the Segment1 field stores compressed information of S1), Offset needs to be set to point to Segment2 field, i.e. Offset 1+ sizeof (Segment 1). In addition, Segment Left is n-1, which means that n-1 Segment elements remain in the Segment list to be processed.

Optionally, in order to further save the byte overhead of SRH-MST, for Segment List < S1, S2, S3, as, Sn > above, the head node may not store S1 in SRH-MST because S1 has already been copied to the DA field of IPv6 Header. Then only N-1 Segments need to be included in the SRH-MST, where the Segment1 field stores the compressed information of S2, and the Segment N-1 field stores the compressed information of Sn. Offset needs to be set to point to Segment1 field, i.e., Item Offset is 0. In addition, Segment Left is n-1, which means that n-1 Segment elements remain in the Segment list to be processed.

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

In the embodiment, when an intermediate node or a tail node receives an IPv6 message, if a DA in an IPv6Header matches a local IP address and a Next Header field of the IPv6Header indicates that a Next Header is an SRH-MST, the SRH-MST is continuously processed according to the following procedure:

according to the type value of the ST, the Segment with the corresponding length is read, and the Segment is converted into the final complete new IPv6 address by combining the information of CmprL, which is concretely as follows:

if ST is 0, then get the corresponding length Segment according to CmprL, because it is already the full IPv6 address, so no translation is needed. The read Segment value is used as the upper bit and the lower bit of the IPv6 address to be filled with zero;

if ST is 1 to 8, the part of the DA field of the current IPv6Header, which corresponds to the length of CmprL in the upper part, is a public prefix, the address fragment value contained in the Segment field is spliced behind the public prefix, and the zero padding is carried out on the lower part, so that the 128-bit complete IPv6 address can be obtained. Note that the upper and lower bits referred to herein are both arithmetically upper and lower bits of a numerical value, and are not upper and lower bits of the numerical value in actual hardware storage.

If the ST is 9 to 11, locally inquiring a corresponding mapping table, and acquiring a complete IPv6 address from the mapping table item;

compared with the prior art, the embodiment provides a segment routing expansion header which is more flexible and supports various segment types, provides various compression modes, supports mixed compilation of SIDs with any length, and can better deploy a segment routing function in an IPv6 network.

Example one

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

the Node S allocates a Node SID 2001: db80: 0100:foridentifying the Node;

node A assigns Node SID 2001: db80:0a 00:foridentifying the Node;

the Node B allocates Node SID 2001: db80:0B00 for identifying the Node, and additionally allocates Adjacency SID 2001: db80:0B01 for identifying the link for the three-layer link B- > C;

node C assigns Node SID 2001: db80:0C 00:foridentifying the Node;

node D assigns Node SID 2001: db80:0D00:: for identifying the Node;

assuming that an SRv6-TE path is established from head node S to tail node D, whose Segment List is < node A, node B, link B- > C, node D >, the path may be calculated by the head node itself or by the request controller. The Segment List can be translated into SID List <2001: db80:0a00: 2001: db80:0b00: 2001: db80:0b01: 2001: db80:0d00: the present invention is also disclosed.

Since the Adjacency SID 2001: db80:0b01 of the identified link is routable, the SIDList can be optimized to be <2001: db80:0a00: 2001: db80:0b01: 2001: db80:0d00: the identified link is routable.

When the message is forwarded along the SIDLIst, IPv6Header + SRH-MST can be encapsulated for the message on the head node S. Since the SIDs all have the same common prefix, the common prefix can be stored in the DA of IPv6Header, and the difference part of the SIDs is stored as compressed information in the segment list of SRH-MST, as shown in fig. 5:

the < ST, ComprL, Segment > corresponding to the first Segment element is <2,4,0a00>, which indicates that the Segment1 field stores 2 bytes of IPv6 address fragment, the IPv6 address fragment can be spliced with corresponding public prefix of 4 bytes length into a complete IPv6 address, and the public prefix is stored in DA of IPv6 Header.

The < ST, ComprL, Segment > corresponding to the second Segment element is <2,4,0b01>, which indicates that the Segment2 field stores the IPv6 address Segment of 2 bytes, the IPv6 address Segment can be spliced with the corresponding public prefix of 4 bytes length into a complete IPv6 address, and the public prefix is stored in the DA of the IPv6 Header.

The < ST, ComprL, Segment > corresponding to the third Segment element is <2,4,0d00>, which indicates that the Segment3 field stores the IPv6 address Segment of 2 bytes, the IPv6 address Segment can be spliced with the corresponding public prefix of 4 bytes length into a complete IPv6 address, and the public prefix is stored in the DA of the IPv6 Header.

To ensure that the length of the segment list is an integer multiple of 8 bytes, the Padding field takes up 7 bytes. At this time, the List Len is set to 2, and the byte overhead representing the entire segment List occupies 28 bytes.

The following will describe the forwarding process of the packet along the SR-TE path:

1) the message is forwarded from the head Node S to the logically first Segment Node (i.e. Node A), and since the head Node has the original SID List before compression, the DA of IPv6Header can be directly set as the first SID of SIDList (2001: db80:0a 00:).

In this example, since the first SID (2001: db80:0a00::) is also compressed and stored in the Segment list of SRH-MST, the Offset field of SRH-MST is shifted to point to the second Segment element, i.e., Offset ═ sizeof < ST, CmprL, and Segment1 ═ 3 when the message is sent out.

The Segment Left field of SRH-MST is set to 2, indicating that 2 Segment elements remain to be processed.

The message looks up a routing table according to the DA of the IPv6Header and forwards the message to the node A.

2) When the message reaches the node A, according to the fact that DA of IPv6Header is equal to 2001: db80:0a00, when local SID table entries are hit, the inner layer load is continuously identified as a Routing Header according to Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is sequentially executed:

step 1: if the Segment Left is larger than 0, the Segment Left is reduced by 1 to become 1;

step 2: reading the next Segment element from the Segment List, namely reading Segment List [ Offset ═ 3], reading the first byte first to obtain < ST, ComprL > information of <2,4>, that is, knowing that the Segment field stores 2-byte IPv6 address fragment, continuing to read 2 bytes to obtain 0x0b 01;

step 3: the Offset field is Offset to point to the third Segment element, Offset + sizeof < ST, CmprL, Segment2> 6.

Step 4: converting 0x0b01 into a complete 16-byte IPv6 address, namely, acquiring a public prefix (2001: db 80:) from the logic high-order 4 bytes of the DA of the IPv6Header, splicing the public prefix with 0x0b01 to obtain 2001: db80:0b 01:), and then copying the public prefix into the DA field of the IPv6 Header;

step 5: and searching a routing table to forward the message according to the DA of the IPv6Header, wherein the message is forwarded to the node B.

3) When the message reaches the node B, according to the fact that DA of IPv6Header is equal to 2001: db80:0B01, when local SID table entries are hit, the inner layer load is continuously identified as a Routing Header according to Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is sequentially executed:

step 1: if the Segment Left is larger than 0, the Segment Left is reduced by 1 to be 0;

step 2: reading the next Segment element from the Segment List, namely reading Segment List [ Offset ═ 6], reading the first byte first to obtain < ST, ComprL > information of <2,4>, that is, knowing that the Segment field stores 2-byte IPv6 address fragment, continuing to read 2 bytes to obtain 0x0d 00;

step 3: the Offset field is Offset to point to the fourth Segment element, i.e., Offset + sizeof < ST, CmprL, Segment3> 9. Note that the fourth segment element does not actually exist here.

Step 4: converting 0x0d00 into a complete 16-byte IPv6 address, namely, acquiring a public prefix (2001: db 80:) from the logic high-order 4 bytes of the DA of the IPv6Header, splicing the public prefix with 0x0d00 to obtain 2001: db80:0d 00:), and then copying the public prefix into the DA field of the IPv6 Header;

step 5: because the hit local SID list item prompts that the message is forwarded along the link B-C, the message is directly forwarded along the link B-C without searching a routing table according to the DA of the IPv6 Header.

4) When the message reaches the node C, the DA of the IPv6Header is equal to 2001: db80:0D00, that is, the message is not the local address of the node C, the node C continues to search the routing table according to the DA of the IPv6Header, and forwards the message to the node D.

5) When the message reaches a node D, according to the fact that DA of IPv6Header is equal to 2001: db80:0D00, when a local SID table entry is hit, the inner layer load is continuously identified as a Routing Header according to Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is executed:

step 1: and if the Segment Left is checked to be equal to 0, removing the IPv6Header and the SRH-MST, and continuing to identify and process the inner layer load according to the Next Header field of the SRH-MST.

It should be noted that although the present embodiment describes the packet encapsulation and forwarding process by taking the simple ST ═ 2 as an example, actually, the processing of other STs (1 to 8) is similar, except that the length of each Segment element < ST, CmprL, Segment > in the Segment List of SRH-MST is different from that of the present embodiment, and the setting of the corresponding List Len field and Offset field in SRH-MST is also affected. For example, a Segment element < ST, CmprL, Segment > with ST-4, which is 5 bytes in length, Offset will be accumulated by 5 when reading one such Segment element from SRH-MST.

Example two

The present embodiment considers the mixed-coding of segment elements of different ST types in SRH-MST based on the first embodiment. As also shown in FIG. 4, all nodes are assigned 128 bits of classical SRv6 SIDs, assuming that the SRv6 SIDs of node S, A, B are all in the same common prefix (2001: db80:: 32) and the SRv6 SIDs of node C, D are all in the same common prefix (2002: db80:: 32), such as:

the Node S allocates a Node SID 2001: db80: 0100:foridentifying the Node;

node A assigns Node SID 2001: db80:0a 00:foridentifying the Node;

the Node C allocates Node SID 2002: db80:0C 00:foridentifying the Node;

node D assigns a Node SID 2002: db80:0D00:: for identifying the Node;

similarly, assume that an SRv6-TE path is established from head node S to tail node D, with Segment List being < node A, node B, link B- > C, node D >, which translates into SID List <2001: db80:0a00: 2001: db80:0B01: 2002: db80:0D00: 2002.

When the message is forwarded along the SID List, IPv6Header + SRH-MST may be encapsulated for the message at the head node S. Since the first SID and the second SID in the SID List have the same common prefix, they can share the common prefix in DA in IPv6Header, and only store their difference part in the segment List of SRH-MST; since the prefix of the third SID is different from that of the last SID, the SRH-MST needs to store the complete SID information. The specific package of the SRH-MST is shown in fig. 6:

The third Segment element corresponds to < ST, ComprL, Segment > of <0,6,2002: db80:0d00>, indicating that 6 bytes of the full IPv6 address (as the upper part of the IPv6 address, the lower zero padding) is stored in the Segment3 field.

To ensure that the length of the segment list is an integer multiple of 8 bytes, the Padding field takes 3 bytes. At this time, the List Len is set to 2, and the byte overhead representing the entire segment List occupies 28 bytes.

1) the message is forwarded from the head Node S to the logically first Segment Node (i.e., Node A), and since the head Node has the original SID List before compression, the DA of the IPv6Header can be directly set as the first SID of the SID List (2001: db80:0a 00:).

In this example, since the first SID (2001: db80:0a00::) is also compressed and stored in the Segment list of SRH-MST, the Offset field of SRH-MST is shifted to point to the second Segment element, i.e., Offset ═ sizeof < ST, CmprL, Segment1 ═ 3, when the message is sent out.

step 2: reading the next Segment element from the Segment List, namely reading Segment List [ Offset ═ 6], reading the first byte first to obtain < ST, ComprL > information <0,6>, namely knowing that the Segment field stores the high-order part of the complete IPv6 address of 6 bytes, continuing to read the 6 bytes to obtain 2002: db80:0d 00;

step 3: the Offset field is Offset to point to the fourth Segment element, Offset + sizeof < ST, CmprL, Segment3> -13. Note that the fourth segment element does not actually exist here.

Step 4: copying 2002 db80:0d 00:intoa DA field of an IPv6 Header;

EXAMPLE III

The foregoing embodiments are all compression schemes in an example of address concatenation, and they rely on SIDs of all nodes or a part of nodes in a network to have the same common prefix, however, in some IPv6 networks, it is difficult to plan SIDs of nodes (even a small number of nodes) in the network within the same common prefix due to historical address planning reasons. To deploy segmented routing in such IPv6 networks, we need to consider a scheme that uses a short index to map the full IPv6 address. This implementation discusses using MPLS labels as short indices, and other types of indices, such as prefix-SID for SR-MPLS or BFR-ID for BIER, are similar.

Still as in the network shown in fig. 4, all nodes are assigned 128-bit classic SRv6 SIDs, such as:

the Node S allocates a Node SID 2001: db80:0100 for identifying the Node;

node A assigns a Node SID 2002: db80::0a00 for identifying the Node;

node B assigns Node SID 2003: db80::0B00 for identifying the Node;

node C assigns Node SID 2004: db80::0C00 for identifying the Node;

node D assigns Node SID 2005: db80::0D00 for identifying the Node;

these SIDs have no common prefix.

Suppose each node also allocates a short MPLS label to its own SID, and advertises the mapping relationship from the corresponding MPLS label to the SID to other nodes in the network, and after receiving the mapping relationship, the other nodes may reallocate an incoming label locally, create a corresponding incoming label forwarding entry, and send out 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 FEC. For simplicity of description, we assume that for a FEC, its in-label and out-label values are exactly equal. Such as:

node S receives a label (label-a) advertisement from node A for SID 2002: db80::0a00, and node S also assigns a label (label-a) to the SID;

node A receives a label (label-B) advertisement from node B for SID 2003: db80::0B00, node A also assigns a label (label-B) to the SID;

node B receives a label (label-C) advertisement from node C for SID 2004: db80::0C00, node B also assigns a label (label-C) to the SID;

node C receives a label (label-D) advertisement from node D for SID 2005: db80::0D00, and node C also assigns a label (label-D) to the SID;

node D assigns a label (label-D) for SID 2005: db80::0D 00;

assuming that an SRv6-TE path is established from the head node S to the tail node D, with Segment List < node a, node B, node C, node D >, the path may be calculated by the head node itself or by the requesting controller. Although this Segment List can be translated into a SID List <2002: db80::0a00,2003: db80::0b00,2004: db80::0c00,2005: db80::0d00>, encapsulating such a SID List in SRH-MST would take a very large byte overhead. Since the head node or controller knows the short indices mapped to these SIDs, the more optimal SID List is < label-a, label-b, label-c, label-d >.

When the message is forwarded along the SID List, IPv6Header + SRH-MST may be encapsulated for the message at the head node S. As shown in fig. 7:

the < ST, ComprL, Segment > corresponding to the first Segment element is <9,0, Label-a >, indicating that the Segment1 field stores 3 bytes of MPLS Label, and the MPLS Label queries the Label mapping table entry to obtain the complete IPv6 address.

The < ST, ComprL, Segment > corresponding to the second Segment element is <9,0, Label-b >, indicating that the Segment2 field stores 3 bytes of MPLS Label, and the MPLS Label queries the Label mapping table entry to obtain the complete IPv6 address.

The < ST, ComprL, Segment > corresponding to the third Segment element is <9,0, Label-c >, indicating that the Segment3 field stores 3 bytes of MPLS Label, and the MPLS Label queries the Label mapping table entry to obtain the complete IPv6 address.

The < ST, ComprL, Segment > corresponding to the fourth Segment element is <9,0, Label-d >, indicating that the Segment 4 field stores 3 bytes of MPLS Label, and the MPLS Label queries the Label mapping table entry to obtain the complete IPv6 address.

Padding is not needed since the length of the segment list is already an integer multiple of 8 bytes. At this time, the List Len is set to 2, and the byte overhead representing the entire segment List occupies 28 bytes.

1) the message is forwarded from the head Node S to the logically first Segment Node, i.e., Node A, and since the head Node has knowledge of the original SID before compression List <2002: db80::0a00,2003: db80::0b00,2004: db80::0c00,2005: db80::0d00>, the DA of the IPv6Header can be directly set to the first SID (2002: db80::0a 00). Or, the head node may query the corresponding entry mapping table 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 copy it to the DA field of IPv6 Header.

In this example, since the first SID (label-a) is also stored in the Segment list of SRH-MST, when the message is sent out, the Offset field of SRH-MST is shifted to point to the second Segment element, i.e., Offset ═ sizeof < ST, CmprL, and Segment1 ═ 4.

The Segment Left field of SRH-MST is set to 3, indicating that 3 Segment elements remain to be processed.

2) When the message reaches the node A, according to the fact that DA of IPv6Header is equal to 2002: db80:0a00, a local SID table entry is hit, the inner layer load is continuously identified as a Routing Header according to the Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is sequentially executed:

step 1: if the Segment Left is larger than 0, the Segment Left is reduced by 1 to 2;

step 2: reading the next Segment element from the Segment List, namely reading Segment List [ Offset ═ 4], reading the first byte first to obtain < ST, ComprL > information <9,0>, that is, knowing that the Segment field stores 3 bytes of MPLS Label, continuing to read 3 bytes to obtain Label-b;

step 3: the Offset field is Offset to point to the third Segment element, Offset + sizeof < ST, CmprL, Segment2> 8.

Step 4: inquiring a corresponding label-in mapping table item according to label-b, acquiring SID (2003: db80::0b00) information, and copying the SID information into a DA field of an IPv6 Header;

3) When the message reaches the node B, according to the fact that DA of IPv6Header is equal to 2003: db80::0B00, a local localSID table entry is hit, the inner layer load is continuously identified as a Routing Header according to the Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is sequentially executed:

step 2: reading the next Segment element from the Segment List, namely reading Segment List [ Offset ═ 4], reading the first byte first to obtain < ST, ComprL > information <9,0>, that is, knowing that the Segment field stores 3 bytes of MPLS Label, continuing to read 3 bytes to obtain Label-c;

step 3: the Offset field is Offset to point to the fourth Segment element, Offset + sizeof < ST, CmprL, Segment2> -12.

Step 4: inquiring a corresponding label-in mapping table item according to label-c, acquiring SID (2004: db80::0c00) information, and copying the SID information into a DA field of an IPv6 Header;

step 5: and searching a routing table to forward the message according to the DA of the IPv6Header, wherein the message is forwarded to the node C.

4) When the message reaches the node C, according to the fact that DA of IPv6Header is equal to 2004: db80::0C00, a local SID table entry is hit, the inner layer load is continuously identified as a Routing Header according to the Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is sequentially executed:

step 2: reading the next Segment element from the Segment List, namely reading Segment List [ Offset ═ 4], reading the first byte first to obtain < ST, ComprL > information <9,0>, that is, knowing that the Segment field stores 3 bytes of MPLS Label, continuing to read 3 bytes to obtain Label-d;

step 3: the Offset field is Offset to point to the fifth Segment element, i.e., Offset + sizeof < ST, CmprL, Segment2> 16. Note that the fifth element does not actually exist here.

Step 4: inquiring a corresponding label-entering mapping table item according to label-d, acquiring SID (2005: db80::0d00) information, and copying the SID information into a DA field of an IPv6 Header;

5) When the message reaches a node D, according to the fact that DA of IPv6Header is equal to 2005: db80::0D00, a local SID table entry is hit, then the inner layer load is continuously identified as a Routing Header according to the Next Header of IPv6Header, and SRH-MST is identified according to Routing Type of the Routing Header, and the following code processing SRH-MST is executed:

In this embodiment, MPLS forwarding is not directly adopted because the network is not a pure MPLS network, for example, the node S and the node a are not directly connected, and there may be other IPv6-only nodes between them. In this embodiment, only the label mapping relationship of MPLS is used, and the traditional MPLS packet forwarding behavior is not used.

Example four

As can be readily derived from the foregoing embodiments, it is also possible to encapsulate both ST (0-8) and ST (9-11) type segment elements in the SRH-MST segment list. This is essentially because the decapsulation of each Segment element is independent and has no dependency relationship with each other, 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 obtained by independent translation, and there is no relationship with the previous Segment element or the next Segment element in the Segment list.

The message forwarding process of the SRH-MST including segment elements of any type is completely similar to the foregoing embodiment, and details are not repeated.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present invention.

In this embodiment, a routing header encapsulation apparatus of an IPv6 message is further provided, where the apparatus is used to implement the foregoing embodiments and preferred embodiments, and details of the foregoing description are omitted for the sake of description. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Fig. 8 is a block diagram of a routing header encapsulation apparatus of an IPv6 message according to an embodiment of the present invention, and as shown in fig. 8, the apparatus is located in a header node 100 of SRv6 domain, and the apparatus includes an encapsulation module 10 and a sending module 20.

The encapsulation module 10 is used for encapsulating the routing header of the IPv6 message. The sending module 20 is configured to send the encapsulated IPv6 packet to a next node in SRv6 domain, where the routing header includes the following fields:

routing Type: occupying 8 bits and representing the type of the routing header;

segments Left: occupying 8 bits and representing the number of segments remaining to be accessed in a segment list contained in the routing header;

reserved: occupying 12 bits and reserving fields;

padding: an optional padding field.

It should be noted that, the above modules may be implemented by software or hardware, and for the latter, the following may be implemented, but not limited to: the modules are all positioned in the same processor; alternatively, the modules are respectively located in different processors in any combination.

Embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program is arranged to perform the steps of any of the above-mentioned method embodiments when executed.

In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to: various media capable of storing computer programs, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Embodiments of the present invention also provide an electronic device comprising a memory having a computer program stored therein and a processor arranged to run the computer program to perform the steps of any of the above method embodiments.

In an exemplary embodiment, the electronic apparatus may further include a transmission device and an input/output device, wherein the transmission device is connected to the processor, and the input/output device is connected to the processor.

For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary embodiments, and details of this embodiment are not repeated herein.

It will be apparent to those skilled in the art that the various modules or steps of the invention described above may be implemented using a general purpose computing device, they may be centralized on a single computing device or distributed across a network of computing devices, and they may be implemented using program code executable by the computing devices, such that they may be stored in a memory device and executed by the computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into various integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for encapsulating a routing header of an IPv6 message is characterized by comprising the following steps:

routing Type: occupying 8 bits and representing the type of the routing header;

reserved: occupying 12 bits and reserving fields;

padding: an optional padding field.

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

3. The method according to claim 1, wherein the ST comprises one of the following types:

type 0: indicating that the corresponding Segment is a complete IPv6 address;

type 10: the SR-MPLSSID index which represents that the corresponding Segment is 4 bytes can be inquired to obtain a complete IPv6 address through the mapping table;

4. The method of claim 3, wherein when ST is 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 of claim 1, wherein the segment list in the routing header is stored in positive order.

6. The method as claimed in claim 1, wherein when the SRv6SID of all nodes in SRv6 domain have the same common prefix, the common prefix is deposited in DA of IPv6Header, and the difference part of SRv6SID of each node is deposited as compressed information in the segment list of the routing Header.

7. The method of claim 1, wherein when encapsulating the routing Header for the IPv6, the head node copies S1 to a DA field of an IPv6Header for a Segment list < S1, S2, S3.. Sn >, and if S1 is stored in the routing Header, then Offset is set to point to a second element in the Segment list in the routing Header, and Segment Left is n-1, indicating that n-1 Segment elements remain in the Segment list to be processed, where n is a positive integer.

8. The method of claim 1, wherein the head node copies S1 to a DA field of an IPv6Header for a Segment list < S1, S2, S3.,. Sn >, when encapsulating the routing Header for the IPv6 packet, if S1 is not stored in the routing Header, Offset is set to point to a first element in the Segment list in the routing Header, and Segment Left is n-1, indicating that n-1 Segment elements remain to be processed in the Segment list, where n is a positive integer.

9. The method of claim 1, further comprising:

and when the intermediate node or the tail node of the SRv6 domain receives the IPv6 message, if the DA in the IPv6Header is matched with the local IP address and the Next Header field of the IPv6Header prompts that the Next layer Header is the routing Header, the IPv6 message is continuously processed.

10. The method of claim 9, wherein continuing to process the IPv6 message comprises:

if the Segments Left is equal to 0, continuing to process the inner layer load, wherein the type of the inner layer load is determined according to a Next Header field of the routing Header;

if the Segments Left is not equal to 0, subtracting 1 from the Segments Left, reading the next Segment, wherein the current value of Offset points to the head address of the next < ST, CmprL and Segment >, reading the Segment with the corresponding length according to the type value of the ST, and converting the Segment into a complete new IPv6 address by combining the information of CmprL;

let Offset point to the next < ST, CmprL, Segment > first address;

if the Offset is larger than List Len × 8, discarding the IPv6 message, and sending an error message to the Source Address of the IPv6 Header;

if the IPv6 Hop Limit value of the IPv6Header is less than or equal to 1, discarding the IPv6 message and sending an ICMP Time Exceeded-Hop Limit Exceeded in Transit message to the Source Address of the IPv6 Header; if the IPv6 Hop Limit value of the IPv6Header is larger than 1, subtracting 1 from the Hop Limit value;

and copying the new IPv6 address obtained by conversion to the DA of the IPv6Header, and checking an IPv6 routing table according to the new DA to forward the IPv6 message.

11. A routing header encapsulating device of an IPv6 packet, located in a header node, comprising:

the encapsulation module is used for encapsulating the routing header of the IPv6 message;

a sending module, configured to send the encapsulated IPv6 packet to a next node in SRv6 domain, where the routing header includes the following fields:

routing Type: occupying 8 bits and representing the type of the routing header;

reserved: occupying 12 bits and reserving fields;

padding: an optional padding field.

12. A computer-readable storage medium, in which a computer program is stored, which computer program, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 10.

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 the steps of the method as claimed in any of claims 1 to 10 are implemented when the computer program is executed by the processor.