SRv6 processing method and device supporting variable-length compressed sid mix

Abstract

This invention discloses an SRv6 processing method and apparatus supporting mixed encoding of variable-length compressed SIDs. The method includes: S100, the source node receives a compressed SRH and the IPv6 destination address encoded by a controller or manually; S101, intermediate nodes parse the IPv6 destination address and SRH in the received header to obtain FSID and FFlag information; S102, based on the parsing result, determine the space of the next-hop node, calculate the start bit of the next-hop node, and update the values ​​in each field of FFlag; S103, based on the parsing and calculation results, update the IPv6 destination address and SRH; the operation on the SRH includes updating the SL and LastEntry fields, stripping the entire SRH, or pushing it out of the stack; S104, forwarding the updated data packet containing the compressed data. This invention pioneers a new technical approach in the field of SRv6 compression, using flag bits containing multiple fields; and for the first time, extends SRv6 compression processing from pre-transmission to in-transmission, thus achieving higher flexibility, higher compression efficiency, and higher transmission efficiency.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and specifically to an SRv6 processing method and apparatus that supports mixed encoding of variable-length compressed SIDs. Background Technology

[0002] Source routing shifts routing decisions from the network core to the network edge. The source host or SDN controller sets the complete forwarding path in the packet header, allowing packets to reach their destination through a series of specified nodes without requiring hop-by-hop routing. Segment routing (SR), a technology derived from source routing, treats each network node as a segment and the forwarding path as a segment list.

[0003] SRv6 (Segment Routing over IPv6) is an implementation of SR in IPv6 networks, and its programmability in services and transport is considered a core technology for future networks. SRv6 can implement new network services and existing network protocols through its flexible programming capabilities; more importantly, SRv6 has multiple programming spaces, enabling simpler and faster deployment of new services. Therefore, SRv6 not only simplifies various network protocols but also meets the needs of the rapid development of 5G and cloud services, as well as future new service requirements. Furthermore, SRv6 is based on an extension header of the IPv6 header, making its implementation more natural and concise than MPLS and SR over MPLS; it allows the network to include nodes that do not support SRv6, enabling the natural coexistence of overlay networks and underlay networks.

[0004] SRv6 defines an IPv6 routing extension header, the SRH (Segment Routing Header), which contains segments (Segment Identifiers, also known as SIDs) representing nodes along the path, forming a segment list. A standard SRv6 SID occupies 128 bits, representing nodes on the path in the form of IPv6 addresses. As the routing path grows, the SRH carries more segments, leading to a significant increase in header overhead and reduced bandwidth utilization. Furthermore, network devices have limited header parsing depth; excessively long segment lists pose a challenge to the device's hardware capabilities, limiting its support for SRv6. Therefore, the biggest challenge in the deployment and widespread adoption of SRv6 is its substantial header overhead.

[0005] Meanwhile, the standard SRv6 also faces the problem of redundant transmission. During transmission, the SRH contains a complete SegmentList, guiding the data packet to its destination. However, only a very small number of services need to send the complete SegmentList to the destination, while the vast majority of services can use the stack-bottom-out mechanism to delete segments that the data packet has already passed, shortening the SegmentList hop by hop, reducing header overhead and improving transmission efficiency. However, existing SRv6 compression solutions do not address compression optimization during transmission.

[0006] The IETF Engineering Task Force and major vendors are paying close attention to the excessive overhead of SRv6 message headers. For example, the G-SRv6 scheme designed by China Mobile and the uSID scheme proposed by Cisco both aim to compress SIDs to save header overhead. A standard SRv6 SID consists of three parts: "Locator," "Function," and "Arguments." The Locator contains the common address prefixes of each node, and most nodes within the same management domain share the same prefix information. Therefore, G-SRv6 uses fixed-length (typically 32 bits) compressed SIDs to reduce the transmission of the same common address prefix. Similarly, uSIDs also achieve SRv6 header compression by reducing the transmission of common address prefixes. Each segment contains a common address prefix and several fixed-length uSIDs. Since each segment contains a common address prefix, uSID compression efficiency is significantly reduced when the common address prefix is ​​long; conversely, using a short common address prefix wastes a large number of addresses. These two solutions only support fixed-length compressed SIDs, which are not efficient enough and lack flexibility, making them difficult to adapt to the dynamic changes in the needs of networks of various sizes. Moreover, the existing solutions only focus on the compression efficiency of SRH and fail to solve the problem of redundant transmission. In other words, they only focus on optimization before transmission and do not consider optimization during transmission. Summary of the Invention

[0007] This invention provides an SRv6 processing method and apparatus that supports mixed encoding of variable-length compressed SIDs. The controller (or manual operation) can flexibly arrange the IPv6 destination address and the content in the SRH and distribute it to the SRv6 source node. Intermediate nodes parse the received data header and perform operations such as calculating the next-hop node start bit, updating the destination address, pushing the bottom of the stack or stripping the SRH, and updating the SL and LastEntry. The mixed encoding of compressed SIDs of different lengths allows operators or enterprises to flexibly configure and mix SIDs of different lengths for network nodes with different roles according to business needs when deploying SRv6, minimizing header overhead and improving compression and transmission efficiency. Furthermore, this method and apparatus can optimize the transmission process, further improving transmission efficiency.

[0008] The present invention adopts the following technical solution:

[0009] On the one hand, an SRv6 processing method supporting mixed encoding of variable-length compressed SIDs is characterized by comprising:

[0010] S100, The source node receives a compressed SRH and IPv6 destination address, either from the controller or manually; the SRH and IPv6 destination address are compiled based on the FFlag field and the FSID support capabilities of each node on the SRv6 path;

[0011] S101: Receive the SRv6 data packet sent by the previous hop node, parse the IPv6 destination address and SRH in the IPv6 header, and obtain the FSID and FFlag information; the Segment structure in the SegmentList in the SRH includes at least one of the following: standard structure, structure without common prefix, and structure with common prefix; in the standard structure, the Segment includes one standard SID, occupying 128 bits of the entire segment; in the structure without common prefix, the Segment includes at least one variable-length fSID; in the structure with common prefix, the Segment includes a common prefix, at least one variable-length fSID, and a flag field FFlag; the flag field FFlag includes P flag bit, Q flag bit, S flag bit, R flag bit, and SP flag bit; the P flag bit is used to identify whether the address space is on the IPv6 destination address; the Q flag bit is used to identify whether the value in SP is the starting bit of the current node's fSID; the S flag bit is used to indicate whether to push the bottom of the stack; the R flag bit is used to indicate whether to decrement SL by 1; the SP flag bit is used to indicate the starting bit of the fSID;

[0012] S102, based on the parsed message, determine the space where the next hop node is located, calculate the start bit of the next hop node, and calculate and update the values ​​in each field of FFlag;

[0013] S103, based on the resolution and calculation results, updates the IPv6 destination address and performs operations on the SRH; the operations on the SRH include updating the SL and LastEntry fields, stripping the entire SRH, or pushing the bottom segment of the SRH stack.

[0014] S104, forward the compressed update data packet to the next hop node.

[0015] Preferably, before step S102, the method further includes:

[0016] Determine whether the received message contains an SRH. If not, perform SRv6 multi-node hop-by-hop processing, and ensure that the compressed SIDs of each hop device in the IPv6 destination address have the same or different lengths.

[0017] Preferably, intelligent orchestration enables differentiated processing of different data streams. At the same time, some data packets that require complete verification retain the complete SRH, while others have their SRHs reduced during transmission.

[0018] Preferably, intelligent orchestration initializes the IPv6 destination address and the FFlag field in the SRH. During the transmission of SRv6 packets, the FFlag field does not require any external intervention and is continuously and dynamically updated to achieve predetermined transmission optimization, delivering packets along a preset path and traversing conventional SRv6 nodes.

[0019] Preferably, each fSID may or may not carry a VL flavor. If the compressed SID does not carry a VL flavor, i.e., the next hop is a standard SRv6 node, then its address space is SegmentList[SL-1], with the starting bit set to 0. If it carries a VL flavor, the method for obtaining the starting bit of the next hop node is as follows:

[0020] When the Q flag is set to 1, the SP bit in the data packet points to the start of the next-hop node's fSID; when the Q flag is set to 0, the SP bit in the data packet points to the start of the current node's fSID. Since the current node knows the length of its own fSID, it can calculate the start of the next-hop node's fSID using the following formula:

[0021] The starting position of the next hop node = the length of the current SP + the current fSID.

[0022] Preferably, the method for determining the space of the next hop is as follows:

[0023] When the P flag is set to 1, the addressing space is the IPv6 destination address; otherwise, if this compressed SID does not carry VLflavor, the addressing space is SegmentList[SL-1].

[0024] The preferred method for updating the destination address is as follows:

[0025] After confirming the address space, let L1 be the length from the start bit to the end of the address space, and let L2 be the length from the end of the common prefix of the destination address DA to FFlag. Then we get L = min(L1, L2).

[0026] Copy the contents of L bits in the address space, starting from the start bit, to the common prefix of the destination address DA.

[0027] Preferably, the stack bottom push operation specifically includes:

[0028] When the S flag is set to 0, the bottom of the stack is pushed out. If the values ​​of lastEntry and SL are the same, no action is taken; otherwise, lastEntry is modified to match SL, and Segment[SL+1]...Segment[lastEntry] is no longer transmitted. SL is the SL updated by the node.

[0029] Update the Hdr.ext.len field in the SRH and the length field in the IPv6 header.

[0030] Preferably, the segment stripping operation specifically includes:

[0031] When a data packet arrives at the penultimate hop within a segment, the value in the SL field is checked. If SL = 0, it indicates that the segment is at the top of the stack and the current node is the penultimate hop among all nodes, so the entire SRH is removed. Otherwise, the value of the SL field is decremented by 1, the flag bit Q is set to 1, the SP flag bit is set to 0, and the SP is set to the start bit of the next hop node.

[0032] On the other hand, an SRv6 processing device supporting variable-length compressed SID hybrid encoding includes:

[0033] The orchestration module receives compressed SRH and IPv6 destination addresses orchestrated by the controller or manually from the source node; the SRH and IPv6 destination addresses are orchestrated based on the FFlag field and the FSID support capabilities of each node on the SRv6 path;

[0034] The parsing module receives SRv6 packets sent by the previous hop node, parses the IPv6 destination address and SRH in the IPv6 header, and obtains FSID and FFlag information. The Segment structure in the SegmentList of the SRH includes at least one of the following: standard structure, structure without common prefix, and structure with common prefix. In the standard structure, the segment includes one standard SID, occupying 128 bits of the entire segment. In the structure without common prefix, the segment includes at least one variable-length fSID. In the structure with common prefix, the segment includes a common prefix, at least one variable-length fSID, and a flag field FFlag. The flag field FFlag includes a P flag bit, a Q flag bit, an S flag bit, an R flag bit, and an SP flag bit. The P flag bit is used to identify whether the address space is on the IPv6 destination address. The Q flag bit is used to identify whether the value in SP is the starting bit of the current node's fSID. The S flag bit is used to indicate whether to push the bottom of the stack out. The R flag bit is used to indicate whether to decrement SL by 1. The SP flag bit is used to indicate the starting bit of the fSID.

[0035] The calculation module is used to determine the space of the next-hop node based on the parsed message, calculate the start bit of the next-hop node, and calculate and update the values ​​of each field in FFlag.

[0036] The update module is used to update the IPv6 destination address based on the resolution and calculation results, and to perform operations on the SRH. The operations on the SRH include updating the SL and LastEntry fields, stripping the entire SRH, or pushing the bottom segment of the SRH stack.

[0037] The forwarding module is used to forward compressed update data packets to the next-hop node.

[0038] The beneficial effects of this invention are as follows:

[0039] (1) An SRv6 (Flexible SRv6, F-SRv6) processing method supporting mixed encoding of variable-length compressed SIDs is proposed. This method uniquely supports the free mixing of compressed SIDs of different lengths, solving the dilemma of choosing the length of compressed SIDs and providing a solution for incremental deployment of SRv6. Current fixed-length compression solutions cannot provide short-length compressed SIDs for core network nodes, nor can they provide sufficiently long compressed SIDs for SRv6 behaviors requiring long parameters. This method allows operators and enterprises to select appropriate short compressed lengths based on the role of network devices during deployment, significantly improving compression efficiency while also considering future needs.

[0040] (2) This invention supports parameterization of the stack bottom pushout, and can freely choose whether to push out the stack bottom pushout according to different services, without worrying that a small number of or future services need to have a complete Segment List, which would cause most services to waste transmission bandwidth.

[0041] (3) This invention not only improves the compression efficiency of SRH before it is sent to the transmission link, but also optimizes the transmission efficiency of SRH on the link. Improving the compression efficiency before transmission will undoubtedly improve the transmission efficiency, but under the same compression efficiency, F-SRv6 can still optimize and improve the transmission efficiency on the link. For example, the parameterized support for the stack bottom push function can theoretically reduce the transmission overhead by nearly half. In addition, F-SRv6 supports unique intra-segment PSP and flexible address space, which further improves the transmission efficiency.

[0042] (4) The F-SRv6 of this invention is fully compatible with the standard SRv6 and provides better support for deployment on the production network and various services;

[0043] (5) SRv6 deployment has gradually become widespread in real production networks. Since F-SRv6 has significantly improved compression and transmission efficiency on the basis of compatibility with standard SRv6, it will effectively solve the problem of excessive header overhead in SRv6 deployment and has high application value.

[0044] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments, but the SRv6 processing method and apparatus of the present invention that supports mixed encoding of variable-length compressed SIDs are not limited to the embodiments. Attached Figure Description

[0045] Figure 1 This is a flowchart of an SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to an embodiment of the present invention;

[0046] Figure 2 This is a flowchart illustrating the architecture of F-SRv6 according to an embodiment of the present invention.

[0047] Figure 3 The following are three segment structure diagrams of F-SRv6 according to embodiments of the present invention; wherein, (a) represents the standard structure, (b) represents the structure without a common prefix, and (c) represents the structure with a common prefix;

[0048] Figure 4 This is a diagram of the IPv6-based F-SRv6 packet encapsulation format according to an embodiment of the present invention;

[0049] Figure 5 This is a structural diagram of the FFlag field in an embodiment of the present invention;

[0050] Figure 6This is a flowchart illustrating the process of a hybrid network of F-SRv6 nodes and standard SRv6 nodes, as described in an embodiment of the present invention.

[0051] Figure 7 This is a structural block diagram of an SRv6 processing device supporting mixed encoding of variable-length compressed SIDs according to an embodiment of the present invention. Detailed Implementation

[0052] The present invention will be further described below through specific embodiments. It should be noted that the specific embodiments described herein are only for the convenience of illustrating and explaining the specific implementation of the present invention, and are not intended to limit the present invention.

[0053] To make the objectives and technical solutions of this invention clearer, the invention will be further described below with reference to the accompanying drawings and examples. It should be understood that the examples described herein are for illustrative purposes only and are not intended to limit the invention.

[0054] See Figure 1 As shown in the figure, this embodiment provides an SRv6 processing method that supports mixed encoding of variable-length compressed SIDs, including:

[0055] S100, The source node receives a compressed SRH and IPv6 destination address, either from the controller or manually; the SRH and IPv6 destination address are compiled based on the FFlag field and the FSID support capabilities of each node on the SRv6 path;

[0056] S101: Receive the SRv6 data packet sent by the previous hop node, parse the IPv6 destination address and SRH in the IPv6 header, and obtain the FSID and FFlag information; the Segment structure in the SegmentList in the SRH includes at least one of the following: standard structure, structure without common prefix, and structure with common prefix; in the standard structure, the Segment includes one standard SID, occupying 128 bits of the entire segment; in the structure without common prefix, the Segment includes at least one variable-length fSID; in the structure with common prefix, the Segment includes a common prefix, at least one variable-length fSID, and a flag field FFlag; the flag field FFlag includes P flag bit, Q flag bit, S flag bit, R flag bit, and SP flag bit; the P flag bit is used to identify whether the address space is on the IPv6 destination address; the Q flag bit is used to identify whether the value in SP is the starting bit of the current node's fSID; the S flag bit is used to indicate whether to push the bottom of the stack; the R flag bit is used to indicate whether to decrement SL by 1; the SP flag bit is used to indicate the starting bit of the fSID;

[0057] S102, based on the parsed message, determine the space where the next hop node is located, calculate the start bit of the next hop node, and calculate and update the values ​​in each field of FFlag;

[0058] S103, based on the resolution and calculation results, updates the IPv6 destination address and performs operations on the SRH; the operations on the SRH include updating the SL and LastEntry fields, stripping the entire SRH, or pushing the bottom segment of the SRH stack.

[0059] S104, forward the compressed update data packet to the next hop node.

[0060] Specifically, the execution nodes of S101 to S104 above are the current nodes, and these current nodes are not the head nodes.

[0061] This embodiment presents an SRv6 processing method supporting mixed variable-length compressed SIDs, based on SRv6 technology supporting mixed variable-length compressed SIDs (Flexible SRv6), or simply Flexible SRv6 (F-SRv6). F-SRv6 defines a new SRv6 node compression format (Flexible Segment ID, fSID), a new tag field F-SRv6 Flag (FFlag), new additional behaviors (VL flavors), and processing behaviors for fSIDs, thereby enabling mixed variable-length compressed SIDs and optimizing link transmission. On the one hand, F-SRv6 allows users to flexibly select fSIDs of different lengths for mixed encoding according to their needs, improving the compression efficiency of the SRH header (Segment Routing Header); on the other hand, it employs techniques such as Penultimate SegmentID Pop within the Segment (PSP), flexible addressing space, and push-out from the bottom of the segment list stack to further reduce the transmission of the segment list on the link, improving transmission efficiency. Its key features include: (1) Each 128-bit segment can carry one or more fSIDs, and VL flavoring behavior is defined for the fSIDs; (2) The identifier field FFlag is defined and a self-service offset is designed for addressing the next node; (3) A hybrid addressing space for nodes is defined, which can address the next node on the segment list and the IPv6 destination address; (4) A stack-based push mechanism for intra-segment PSPs and segment lists is designed to push traversed segments from the bottom of the stack, significantly reducing the transmission overhead of the SRv6 header. Therefore, F-SRv6 has high compression efficiency and high transmission efficiency, and is fully compatible with the current SRv6 standard, which can support heterogeneous networking, smooth upgrades, and existing network evolution.

[0062] For the specific F-SRv6 design architecture process, please refer to [link / reference]. Figure 2 As shown, F-SRv6 introduces several innovative features, including variable-length compressed SIDs (fSIDs), F-SRv6 END (fEND) processing behavior and VL flavor appending behavior, and the F-SRv6Flag (FFlag) field. For pre-transmission optimization, F-SRv6 employs a hybrid variable-length compressed fSID method to reduce the length of the SRH. For in-transmission optimization, F-SRv6 introduces techniques such as stack bottom-push, intra-segment PSP, and flexible addressing space, pushing segments containing SIDs of missed nodes or SIDs of passed nodes as needed. These will be explained in detail below from five aspects.

[0063] I. fSID format and SRH

[0064] To be compatible with standard SRv6, F-SRv6 retains the 128-bit IPv6 address format for segments. See also Figure 3 As shown in (a), one segment describes one standard SID, which includes three parts: Locator, Function, and Arguments. See also Figure 3 (b) shows that to reduce SRH header overhead, F-SRv6 allows different nodes to use compressed fSIDs of different lengths as needed. In this case, one segment can contain one or more variable-length fSIDs (each fSID must be complete), with any part less than 128 bits padded with 0s. Each fSID is byte-length (1-14 bytes) and consists of three parts: Node ID, Function ID, and Arguments. The length of these three parts is flexible within the fSID, depending on the actual selection. The Node ID describes the ID of the network node and, together with the Common Prefix, forms a routable Locator to guide packet forwarding. Nodes within the same network management domain typically use the same Common Prefix, and one of the F-SRv6 compression strategies is to minimize the transmission of the Common Prefix. However, when the network topology changes or service requirements change, F-SRv6 needs to switch the Common Prefix. In this case, the segment must include the Common Prefix. See [link to relevant documentation]. Figure 3 As shown in (c).

[0065] See Figure 4The diagram shows the F-SRv6 packet encapsulation format based on IPv6. The Segment Left field is the full name of SL (Segment Left); the Last Entry field is the full name of Last Entry (Segment Last Entry); and the SRH's SegmentList can contain... Figure 3 There are three segment structures. When there is no need to switch the public prefix, the public prefix is ​​reused on the IPv6 destination address, and only the fSID needs to be updated. Users can choose to use the structure without a public prefix, i.e. Figure 3 (b) When switching the common prefix across network management domains, a structure with the common prefix must be used, i.e. Figure 3 (c) When using network nodes that only support standard SRv6, a standard architecture must be used, i.e. Figure 3 (a).

[0066] Meanwhile, F-SRv6 defines an 8-bit identifier field FFlag for fSID location and auto-offset, including five identifier fields: P, Q, S, R, and SP. See [link to relevant documentation]. Figure 5 As shown. The following text will use FFlag.P, FFlag.Q, FFlag.S, FFlag.R, and FFlag.SP to represent these fields, and a detailed explanation of these five identifier fields will follow.

[0067] (1) FFlag.P flag: occupies 1 bit and indicates whether the address space is on the IPv6 Destination Address (DA).

[0068] P=1 indicates that the address space is on the IPv6 destination address (abbreviated as p);

[0069] P=0 indicates that the address space is not on the IPv6 destination address (abbreviated as np).

[0070] (2) FFlag.Q flag: occupies 1 bit and indicates which node's starting bit the value in SP is.

[0071] Q = 0 indicates that the value in SP is the starting bit (abbreviated as nq) of the current node fSID;

[0072] Q = 1 indicates that the value in SP is the starting bit (abbreviated as q) of the next-hop node fSID.

[0073] (3) FFlag.S flag: occupies 1 bit and indicates whether to push the bottom of the stack out. The default value is 0.

[0074] S=0 means that the bottom of the stack needs to be pushed out;

[0075] S=1 means do not push from the bottom of the stack.

[0076] (4) FFlag.R flag: occupies 1 bit and is used to indicate that 1 should be subtracted from SL. This is the companion bit of the P and Q bits and only takes effect when combined with P=1 or Q=1.

[0077] R = 0, meaningless (abbreviated as nr);

[0078] R=1 and P=1 (abbreviated pr): When the content of SegmentList[SL] in the SRH received by the node is the same as that of DA: set P=1, which means addressing on DA; at the same time set R=1, which indicates that the value of SL is decremented by 1, and SL points to the next Segment. If S=0 is also set at this time, then the bottom of the stack will be pushed out, which improves the transmission efficiency.

[0079] R=1 and Q=1 (abbreviated qr): This is used when a segment contains only one fSID with a VL flavor (e.g., the fSID itself is quite long, and the fSID of the next node is also very long; this is rare). In this case, a common prefix must be added to the front of the fSID, that is... Figure 3 (c) Form. Setting Q=1 indicates that the value in SP represents the starting bit of the next hop node fSID; setting R=1 indicates that the value of SL is decremented by 1, pointing SL to the next Segment.

[0080] (5) FFlag.SP flag: Occupies 4 bits and is an internal pointer of the Segment or DA, indicating the start bit of fSID. The unit value represents 1 byte, so the addressing range is 0 to 15, completely covering 16 × 8 = 128 bits. Based on the combination of Q and SP, the starting byte position of the next-hop node fSID can be located.

[0081] It should be noted that the flag field Fflag can be expanded as needed, such as including 6 flag fields, and the number of bits occupied by each field can be adjusted as needed. This embodiment does not impose any restrictions.

[0082] II. fSID Positioning and Self-Service Offset

[0083] Unlike existing fixed-length compressed SID schemes, the F-SRv6 implementation in this example supports mixed encoding of fSIDs of different lengths, thus requiring the determination of the starting byte position of the next-hop node. To address this, F-SRv6 proposes a solution of fast positioning and self-adaptive offset.

[0084] First, we establish the concepts of address space and location. Address space refers to the possible locations of the SID of the next-hop node for a given node. F-SRv6 expands the address space for locating the next-hop node to three locations: SegmentList[SL], SegmentList[SL-1], and IPv6 Destination Address (DA), where the SL (Segment Left) field is used to indicate the current node's position in the SegmentList.

[0085] The start bit indicates from which position in the address space to retrieve the SID information of the next-hop node. If the next hop is a standard SRv6 node, then its address space is SegmentList[SL-1], and the start bit is 0. If the next hop is fSID, then:

[0086] 1. Confirm the starting position of the next hop node.

[0087] When FFlag.Q = 1, the SP bit in the F-SRv6 data packet points to the start bit of the next-hop node's fSID; when FFlag.Q = 0, the SP bit in the data packet points to the start bit of the current node's fSID. Since the current node knows the length of its own fSID, it can calculate the start bit of the next-hop node's fSID using the following formula (in bytes): Next-hop start bit = Current SP + Current fSID length. Although there is no preset fixed length, each node can calculate the start bit of the next-hop node's fSID based on its own fSID length and FFlag.SP; this is called the self-adjusting offset.

[0088] 2. Update the destination address

[0089] After confirming the address space and start bit, let L1 be the length of the address space from the start bit to the end, and L2 be the length from the end of the DA common prefix to FFlag. Let L = min(L1, L2). Copy the contents of L bits in the address space starting from the start bit to the end of the IPv6 DA common prefix.

[0090] 3. PSP within the segment

[0091] for Figure 3In scenario (c), when a segment contains multiple fSIDs, and due to the presence of an FFlag field at the end, the LPM method cannot be used to determine whether a compressed SID still exists in the address space, unlike other compression schemes. F-SRv6 extends the concept of PSP from a global scope to within a single segment, introducing an intra-segment PSP method to solve the problem of determining whether an fSID still exists within a segment. By leveraging the orchestration capabilities of the SDN controller, the penultimate hop in a segment uses an fSID with PSP flavor. When a packet arrives at the penultimate hop within the segment, the value in the SL field is checked. If SL = 0, it indicates that the segment is at the top of the stack, meaning the current node is the penultimate hop among all nodes, and the SRH can be removed; otherwise, the value of the SL field is decremented by 1, and FFlag.Q = 1 and FFlag.SP = 0 are set, with SP pointing to the start of the next hop node. With stack bottom-push enabled, the current segment is "removed." F-SRv6's intra-segment PSP is universal and can be used for... Figure 3 (c) can also be used Figure 3 (b). Extending the functionality of PSP flavors to the segment has two advantages: (1) It solves the problem of locating the last fSID. When a node receives a data packet, it matches the PSP flavor and SL fields and finds that the current node is the penultimate hop in the segment, so it can know for sure that there is only one fSID after its own node; (2) It further improves the transmission efficiency. In the case of starting the stack push-out (FFlag.S=0), the stack push-out can be performed in advance, and the segment where the penultimate hop is located does not need to be sent to the subsequent nodes.

[0092] III. Stack Bottom Push Mechanism

[0093] This embodiment of F-SRv6 employs a stack bottom-push mechanism to reduce the length of the SegmentList during transmission, saving link overhead and alleviating the processing burden on intermediate node devices. For example... Figure 4 As shown, the SegmentList in the SRH header is arranged in reverse order, where the top SegmentList[0] represents the last node in the path. Unlike standard SRv6, which always maintains a complete segment list, the segment list of F-SRv6 is gradually shortened during forwarding (optionally). Segments that have already passed through the packet are removed from the segment list, thereby reducing the length of the SRH header. At the same time, LastEntry, SL, HdrExLen ( Figure 4 The value of the Hdr ExLen field will change accordingly.

[0094] In rare cases, such as when secure encryption computation involves the entire SRH, simply pushing from the bottom of the stack is not sufficient. Therefore, stack pushing cannot be a fixed function; that is, it cannot be enabled or disabled for all flows at any given time. Instead, different business flows must be treated differently. At any given time, based on the needs of the business flows, stack pushing is enabled for some flows and disabled for others.

[0095] Because some applications cannot perform stack bottom-out (e.g., secure encryption calculations require the entire SRH), the stack bottom-out function cannot be uniformly enabled or disabled for all flows. Instead, different service flows must be processed differently. This embodiment of F-SRv6 sets the FFlag.S instruction bit to indicate whether the stack bottom-out function should be enabled for the current flow in relation to the SRH. When FFlag.S = 0, if the fSID or SID in one or more segments at the bottom of the stack points to a node that has already passed through or is already included in the IPv6 DA, then F-SRv6 allows the current node to push out these segments. The reason why multiple segments can be pushed out at once is that F-SRv6 nodes located after regular SRv6 nodes may need to push out multiple segments. This parameterized instruction design can meet the needs of various services while improving transmission efficiency, reflecting the flexible programmability of SRv6.

[0096] The stack-bottom-out mechanism is highly efficient in saving data. If the stack-bottom-out mechanism is used for standard SRv6, the number of segments transmitted on the link will be reduced by nearly 50%. Assuming there are N = 10 nodes after the SRv6 source node, the total number of segments transmitted on the link is shown in Table 1. If the existing Reduced mode (see RFC 8754) and PSPflavor are used, a total of 81 segments are transmitted; if the stack-bottom-out mechanism is enabled, a total of 53 segments are transmitted. The larger N is, the closer the reduction rate is to 50%.

[0097] When the stack bottom push mechanism is enabled in F-SRv6, the total number of segments transmitted on the link will be less due to the combination of features such as intra-segment PSP.

[0098] Table 1. Sum of transmission segments for each link under different modes.

[0099]

[0100] IV. Flexible addressing space

[0101] In hybrid networking, the path may include regular SRv6 nodes, with segments following them containing a common prefix; or, when switching common prefixes, the new segment will also contain a common address prefix; additionally, the IPv6 destination address sent by the source node will also contain a common address prefix. In these three scenarios, if a segment containing a common prefix contains only one compressed SID, then the entire 128-bit space is dedicated to that node, leading to a decrease in compression efficiency. This situation occurs in G-SRv6. However, F-SRv6 allows segments containing a common prefix to contain multiple compressed SIDs, thus F-SRv6 has higher compression efficiency. Figure 3 As shown in (c).

[0102] In addition to improving compression efficiency, F-SRv6 also features optimizations during transmission. Figure 3 (c) Assume the common prefix occupies 32 bits, followed by 6 fSIDs. When the packet arrives at the node of the first fSID, the IPv6 DA (Destination Address) already contains the complete information of the entire segment, so there is no need to retransmit the segment to the subsequent 5 fSID nodes.

[0103] To address this, F-SRv6 extends the addressing space from SegmentList[SL] and SegmentList[SL-1] to IPv6DA, and sets the P and R bits in FFlag. When FFlag.P = 1, F-SRv6 will address on IPv6DA; otherwise, it will not address on IPv6DA. When stack push is enabled (FFlag.S = 0), if FFlag.P = 1, FFlag.R = 1 can be set (the use case for pr) to indicate that segments with the same content as DA in SegmentList should be pushed out. This reduces the number of segments transmitted and further improves transmission efficiency.

[0104] V. fEND and Additional Behaviors

[0105] F-SRv6 uses PSP flavor and extends it within segments, while also defining VL flavor. The VL flavor and PSP flavor for each fSID are defined as needed. For ease of explanation, this embodiment of F-SRv6 provides a recommended scheme: the second-to-last bit of the fSID indicates whether it carries a VL flavor (set to 1 if it does), and the last bit of the fSID indicates whether it carries a PSP flavor (set to 1 if it does). When carrying a VL flavor (set to 1), the next-hop node is an fSID node without a common prefix; if not carrying a VL flavor, the next-hop node is a standard SID node or an fSID node with a common prefix. When carrying a PSP flavor, the current node is the second-to-last hop of a segment or the second-to-last hop among all nodes.

[0106] The basic process of handling the fEnd instruction is as follows:

[0107] 1. Determine the starting bit of the fSID of the next hop node based on the VL flavor and the FFlag.Q and FFlag.SP flags.

[0108] 2. Then, determine the address space based on the P flag in FFlag and the SL field in SRH (the address bits need to be determined first, then the address space. This is because changes in the address bits may affect the address space. Assuming there is no intra-segment PSP, if the updated SP becomes 0, the address space may change from SegmentList[SL] to SegmentList[SL-1]. Therefore, logically, the start bit must be determined first, then the address space).

[0109] 3. Read the corresponding segment from the address space into the IPv6 destination address based on the start bit.

[0110] 4. Write the new FFlag to the last 8 bits of the IPv6 destination address. The FFlagS bit, which indicates whether to execute the FFlag pushed from the bottom of the stack, remains unchanged.

[0111] To simplify the fEnd instruction processing flow, the function in Table 2 is defined first.

[0112] Table 2 Functions

[0113]

[0114]

[0115] Based on the combination scenarios of VL flavor and PSP flavor, this embodiment of F-SRv6 defines four new fEnds:

[0116] • noVL_noPSP scenario (as shown in Table 3): VL flavor = 0 (abbreviated as noVL) and PSP flavor = 0 (abbreviated as noPSP);

[0117] • noVL_PSP scenario (as shown in Table 4): VL flavor = 0 and PSP flavor = 1 (abbreviated as PSP);

[0118] • VL_noPSP scenario (as shown in Table 5): VL flavor = 1 (abbreviated as VL) and PSP flavor = 0;

[0119] • VL_PSP scenario (as shown in Table 6): VL flavor = 1 and PSP flavor = 1.

[0120] Table 3. Behavior of fEnd in the noVL_noPSP scenario.

[0121] noVL_noPSP Nq q p noVL_noPSP_nq noVL_noPSP_q np / /

[0122] noVL_noPSP_nq: noVL indicates that the next hop of the current node is an fSID with a common prefix or a standard SRv6 node; noPSP indicates that the current node is not the penultimate hop; nq indicates that SP points to the starting bit of the fSID of the current node.

[0123] The specific processing procedure is as follows:

[0124] SL = SL-1; / / SL-1 points to the next Segment

[0125] DA = SegmentList[SL]; / / Copy the Segment pointed to by SL to the destination address.

[0126] push(); / / Push the bottom of the stack out.

[0127] noVL_noPSP_q: noVL indicates that the next hop of the current node is an fSID with a common prefix or a standard SRv6 node; noPSP indicates that the current node is not the penultimate hop; q indicates that SP points to the starting bit of the fSID of the next hop node.

[0128] The specific processing procedure is as follows:

[0129] DA = SegmentList[SL]; / / Copy the Segment pointed to by SL to the destination address.

[0130] Push(); / / Push the bottom of the stack out.

[0131] Table 4. Behavior of fEnd in the noVL_PSP scenario.

[0132]

[0133] noVL_PSP_nq: noVL indicates that the next hop of the current node is an fSID with a common prefix or a standard SRv6 node; PSP indicates that the current node is the penultimate hop, and it is the true penultimate hop; nq indicates that SP points to the starting bit of the fSID of the current node.

[0134] The specific processing procedure is as follows:

[0135] SL = SL-1; / / SL-1 points to the next Segment

[0136] DA = SegmentList[SL]; / / Copy the Segment pointed to by SL to the destination address.

[0137] pop(); / / Remove SRH

[0138] noVL_PSP_q: noVL indicates that the next hop of the current node is an fSID with a common prefix or a standard SRv6 node; PSP indicates that the current node is the penultimate hop, and it is the true penultimate hop; q indicates that SP points to the starting bit of the fSID of the next hop node.

[0139] The specific processing procedure is as follows:

[0140] DA = SegmentList[SL]; / / Copy the Segment pointed to by SL to the destination address.

[0141] pop(); / / Remove SRH

[0142] Table 5. Behavior of fEnd in VL_noPSP scenario

[0143]

[0144] VL_noPSP_nq_np: VL indicates that the next hop of the current node is fSID; noPSP indicates that the current node is not the penultimate hop; nq indicates that SP points to the starting position of the fSID of the current node; and np indicates that the current address space is on SegmentList.

[0145] The specific processing procedure is as follows:

[0146] seg_index = calc_sp(); / / Calculate the offset seg_index

[0147] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0148] push(); / / Push the bottom of the stack out.

[0149] VL_noPSP_q_np_nr: VL indicates that the next hop of the current node is fSID; noPSP indicates that the current node is not the penultimate hop; q indicates that SP points to the starting position of the fSID of the next hop node; np indicates that the current address space is on SegmentList.

[0150] The specific processing procedure is as follows:

[0151] seg_index = calc_sp(); / / Directly get the offset seg_index

[0152] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0153] FFlag.Q = 0; / / Reset Q to 0, indicating that it points to the current node again.

[0154] push(); / / Push the bottom of the stack out.

[0155] VL_noPSP_q_np_r: VL indicates that the next hop of the current node is fSID; noPSP indicates that the current node is not the penultimate hop; this is applied when the current node's fSID is too long, and both the common prefix and fSID should be included. q indicates that SP points to the starting bit of the next hop node's fSID, and r indicates that SL should be decremented by 1.

[0156] The specific processing procedure is as follows:

[0157] seg_index = calc_sp(); / / Directly get the offset seg_index

[0158] SL = SL – 1; / / SL – 1 points to the next segment.

[0159] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0160] FFlag.Q = 0; / / Reset the Q and R flags to 0

[0161] FFlag.R = 0;

[0162] push(); / / Push the bottom of the stack out.

[0163] VL_noPSP_nq_p_nr: VL indicates that the next hop of the current node is fSID; noPSP indicates that the current node is not the penultimate hop; nq indicates that SP points to the starting bit of the current node's fSID; p indicates that the current address space is on DA.

[0164] The specific processing procedure is as follows:

[0165] seg_index = calc_sp(); / / Calculate the offset seg_index

[0166] update(DA); / / Perform a self-adjusting offset on DA and update the destination address.

[0167] VL_noPSP_nq_pr: VL flavor indicates that the next hop of the current node is fSID; noPSP indicates that the current node is not the penultimate hop; this is used when switching common prefixes and addressing can be performed on DA, pushing this segment with the common prefix off the stack. nq indicates that SP points to the starting bit of the current node's fSID, p indicates that the current address space is on DA, and r indicates that SL-1 should be decremented.

[0168] The specific processing procedure is as follows:

[0169] seg_index = calc_sp(); / / Calculate the offset seg_index

[0170] update(DA); / / Perform a self-adjusting offset on DA and update the destination address.

[0171] SL = SL – 1;

[0172] push(); / / Push the bottom of the stack out.

[0173] Table 6. Behavior of fEnd in the VL_PSP scenario.

[0174]

[0175]

[0176] VL_PSP_nq_end_np: VL indicates that the next hop of the current node is fSID; PSP indicates that the current node is the penultimate hop; the end flag indicates that SL=0, and SL points to the last Segment, which is the actual penultimate hop.

[0177] The specific processing procedure is as follows:

[0178] seg_index = calc_sp(); / / Calculate the offset seg_index

[0179] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0180] pop(); / / Remove SRH

[0181] VL_PSP_nq_middle_np: VL indicates that the next hop of the current node is fSID; PSP indicates that the current node is the penultimate hop; the middle flag indicates that SL>0, and the current node is the penultimate hop within the segment.

[0182] The specific processing procedure is as follows:

[0183] seg_index = calc_sp(); / / Calculate the offset seg_index

[0184] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0185] FFlag.Q = 1; / / Modify the identifier field

[0186] FFlag.SP = 0;

[0187] SL = SL – 1; / / SL points to the next Segment

[0188] push(); / / Push the bottom of the stack out.

[0189] VL_PSP_q_end_np: VL indicates that the next hop of the current node is fSID; PSP indicates that the current node is the penultimate hop; the end flag indicates that SL = 0, SL points to the last segment, which means that the current node is the true penultimate hop; q indicates that SP has already pointed to the next hop, which is the last hop node.

[0190] The specific processing procedure is as follows:

[0191] seg_index = calc_sp(); / / Directly get the offset seg_index

[0192] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0193] pop(); / / Remove SRH

[0194] VL_PSP_q_r_np: VL indicates that the next hop of the current node is fSID; PSP indicates that the current node is the penultimate hop. This is used when the current node's fSID is too long, and both the common prefix and fSID should be included. q indicates that SP points to the last hop node, and r indicates that SL should be decremented by 1.

[0195] The specific processing procedure is as follows:

[0196] seg_index = calc_sp(); / / Directly get the offset seg_index

[0197] SL = SL – 1; / / SL – 1 points to the last segment.

[0198] update(SegmentList[SL]); / / Perform a self-offset on the Segment and update the destination address.

[0199] pop(); / / Remove SRH

[0200] VL_PSP_nq_p: VL indicates that the next hop of the current node is fSID; PSP indicates that the current node is the penultimate hop. p indicates that the current address space is on DA.

[0201] The specific processing procedure is as follows:

[0202] seg_index = calc_sp(); / / Calculate the offset seg_index

[0203] update(DA); / / Perform a self-adjusting offset on DA and update the destination address.

[0204] FFlag.P = 0; / / Reset P to 0, indicating that the next hop is addressed at the Segment.

[0205] FFlag.Q = 1; / / Set Q to 1 and SI to 0, indicating that it has pointed to the next hop fSID.

[0206] FFlag.SP = 0;

[0207] Next, the orchestration principles of the SDN controller will be explained.

[0208] The design principle of F-SRv6 is to fully leverage the capabilities of the control plane, specifically through intelligent orchestration by the SDN controller, rather than by network nodes, thus avoiding the consumption of hardware resources. The FFlag is initialized by the SDN controller in the SRH's SegmentList and dynamically modified during transmission. The SRv6 header node can configure the SRH or receive the SRH issued by the SDN controller. The principle of SegmentList orchestration is inferred from the meaning of the settings of each field in the FFlag, and is therefore understandable, rather than rigidly defined. The principles of SegmentList orchestration are as follows:

[0209] 1. Ensure that the bit length of any fSID on the path is less than or equal to 120 - CPL. CPL is the bit length occupied by the common prefix.

[0210] 2. fSID cannot be used across segments.

[0211] 3. If a compressed fSID directly follows a node, then that node must use a VL flavor; otherwise, it does not. There are several situations where a VL flavor is not used, such as when the next node uses a regular SID, or when the next node uses an fSID but includes a public address prefix before the fSID.

[0212] 4. Every segment, whether it's the second to last, must carry the PSP flavor, regardless of whether it's a middle segment or the last segment. This is how the PSP concept extends into the segment itself.

[0213] 5. If this node is the second to last hop among all nodes, then the PSP flavor should be selected. This is the original meaning of PSP.

[0214] 6. If it is necessary to push the bottom of the stack out, then the S bit must be set.

[0215] 7. A segment containing a common prefix must contain at least three compressed fSIDs for setting the P bit to be worthwhile. Therefore, if the P bit is to be set, the segment containing the common prefix must contain at least three compressed fSIDs; otherwise, the P bit cannot be set.

[0216] 8. If a segment contains only one fSID with a VL flavor (e.g., the fSID itself is quite long, and the fSID of the next node is also very long, which is a rare scenario), then a common prefix should be added, that is... Figure 3(c) The format is: Common prefix + fSID + padding + FFlag, where: FFlag.P = 0, because there is only one fSID, so the P bit should not be set; FFlag.Q = 1, indicating that the addressing start bit is FFlag.SP; FFlag.S is set according to whether stack push is required; FFlag.R = 1, indicating SL--, that is, the address space is the next segment. FFlag.SP = 0, indicating that the start bit of the next fSID is 0, that is, the starting position of the first fSID in the next segment. The controller is arranged like this because there is only a single fSID, so there is no intra-segment PSP, and it is impossible to let the node know that the current segment no longer contains a new fSID.

[0217] See Figure 6 As shown below, the processing procedure will be illustrated using a case study involving a hybrid network of F-SRv6 nodes and standard SRv6 nodes.

[0218] The SRv6 path is: R1 (source node), R2, R3, R4, RA (standard SRv6 node), RB, R5, R6, R7, host.

[0219] In the X below, the first two bits are 0, the third bit is used to indicate whether it has VL flavor, and the fourth bit is used to indicate whether it has PSP flavor.

[0220] #R2's F-SID is 202:202:20X

[0221] 202:202:200 means noVL_noPSP

[0222] 202:202:201 represents noVL_PSP

[0223] 202:202:202 represents VL_noPSP

[0224] 202:202:203 represents VL_PSP

[0225] The F-SID of the #R3 is 33X

[0226] The F-SID of #R4 is 44X

[0227] #RA represents a standard SRv6 node (2001:db8:a:b:c:d::aa1)

[0228] #RB's F-SID is bbX

[0229] The F-SID of the #R5 is 505:50X

[0230] The F-SID for #R6 is 606:60X

[0231] The F-SID for the #R7 is 77X.

[0232] #The host is a regular IPv6 address: 2001:70:4::7

[0233] R1 is the head node (source node) and uses the Reduced mode.

[0234] The destination address DA contains the common prefix a:b, and the fSID of the R2 node application carrying VL_noPSP (R2 is followed by the compressed node fSID, and is not the penultimate hop), the fSID of the R3 application carrying VL_PSP (because it is the penultimate hop within the segment), and the fSID of the R4 application carrying noVL_noPSP (because the next hop is a regular SRv6 node, and R4 is not the penultimate hop among all nodes); then FFlag.P = 1, indicating that addressing should be performed on DA, and FFlag.SP = 4, pointing to the starting position of R2fSID.

[0235] SegmentList[3] contains the standard SRv6 SID of RA; SegmentList[2] contains a series of fSIDs with common prefixes, RB application carries VL_noPSP fSID, R5 application carries VL_PSP fSID, R6 application carries VL_noPSP fSID; SegmentList[1] contains the fSID of R7 with noVL_PSP flavor (because the next hop is a regular node, and R7 is the second to last hop among all nodes); SegmentList[0] contains the IPv6 address of the host.

[0236] from Figure 6 It can be seen that the information from node R1 to node R2 is quite important, including the complete SegmentList sent by the controller to the head node R1 and the controller's initialization of FFlag.

[0237] The packets sent from R2 to R3 show a self-adjusting offset on DA, where R2's fSID is removed and R3's fSID is appended to the common prefix.

[0238] The data packet sent from R3 to R4 shows that FFlag.P=0, FFlag.Q=1, FFlag.SI=0, and R4 has an fSID with the noVL_noPSP combination. R4 needs to get the next hop node from SegmentList[3].

[0239] The data packet sent by R4 to RA shows that the standard SRv6 SID of RA is on DA. After receiving the data packet, RA performs standard SRv6 node processing behavior, decrements SL by 1, obtains the next-hop node from SegmentList[2], and copies it to DA.

[0240] The data packet sent from RA to RB shows that FFlag.P = 1, FFlag.R = 1 (a use case for pr), FFlag.SI = 4, and RB has an fSID with VL_noPSP. At this point, RB performs a self-adjusting offset on DA, RB's fSID is removed, and R5's fSID follows the common prefix. SL is decremented by 1, and finally, the bottom of the stack is pushed out.

[0241] The data packet sent from R5 to R6 shows that a self-adjustment is performed on DA. R5's fSID is removed, and R6's fSID is followed by the common prefix. At this time, FFlag.Q = 1, and R6 obtains the next hop node from SegmentList[1].

[0242] The last data packet sent by R7 shows that SRH has been removed by R7.

[0243] See Figure 7 As shown, this embodiment also discloses an SRv6 processing device that supports mixed encoding of variable-length compressed SIDs, including:

[0244] The orchestration module 700 receives compressed SRH and IPv6 destination addresses orchestrated by the controller or manually from the source node; the SRH and IPv6 destination addresses are orchestrated based on the FFlag field and the FSID support capabilities of each node on the SRv6 path.

[0245] The parsing module 701 is used to receive SRv6 packets sent by the previous hop node, parse the IPv6 destination address and SRH in the IPv6 header, and obtain the FSID and FFlag information. The Segment structure in the SegmentList of the SRH includes at least one of the following: standard structure, structure without common prefix, and structure with common prefix. In the standard structure, the Segment includes one standard SID, occupying 128 bits of the entire segment. In the structure without common prefix, the Segment includes at least one variable-length fSID. In the structure with common prefix, S... The `element` includes a common prefix, at least one variable-length `fSID`, and a tag field `FFlag`. The `FFlag` field includes a P flag, a Q flag, an S flag, an R flag, and an SP flag. The P flag indicates whether the address space is on an IPv6 destination address. The Q flag indicates whether the value in the SP is the start bit of the current node's `fSID`. The S flag indicates whether to push from the stack. The R flag indicates whether to decrement the `SL` by 1. The SP flag indicates the start bit of the `fSID`. Each `fSID` may or may not carry a VL flavor and an extended definition PSP flavor.

[0246] The calculation module 702 is used to determine the space of the next-hop node based on the parsed message, calculate the start bit of the next-hop node, and calculate and update the values ​​of each field in FFlag.

[0247] The update module 703 is used to update the IPv6 destination address based on the resolution and calculation results, and to perform operations on the SRH; the operations on the SRH include updating the SL and LastEntry fields, stripping the entire SRH, or pushing the bottom segment of the SRH stack.

[0248] Forwarding module 704 is used to forward compressed update data packets to the next-hop node.

[0249] For the specific implementation of each module of an SRv6 processing system that supports mixed encoding of variable-length compressed SIDs, please refer to an SRv6 processing method that supports mixed encoding of variable-length compressed SIDs; the details will not be repeated here.

[0250] It should be understood that those skilled in the art can make improvements and modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. An SRv6 processing method supporting mixed encoding of variable-length compressed SIDs, characterized in that, include: S100, the source node receives a compressed SRH and IPv6 destination address, which are intelligently or manually orchestrated by the controller; the SRH and IPv6 destination address are orchestrated based on the FFlag field and the FSID support capability of each node on the SRv6 path; S101: Receive the SRv6 data packet sent by the previous hop node, parse the IPv6 destination address and SRH in the IPv6 header, and obtain the FSID and FFlag information; the Segment structure in the SegmentList in the SRH includes at least one of the standard structure, the structure without a common prefix, and the structure with a common prefix; in the standard structure, the Segment includes one standard SID, which occupies 128 bits of the entire segment; In a structure without a common prefix, a segment includes at least one variable-length fSID; In the structure containing a common prefix, a segment includes a common prefix, at least one variable-length fSID, and a flag field FFlag. The flag field FFlag includes a P flag bit, a Q flag bit, an S flag bit, an R flag bit, and an SP flag bit. The P flag bit is used to identify whether the address space is on an IPv6 destination address. The Q flag bit is used to identify whether the value in SP is the start bit of the current node's fSID. The S flag bit is used to indicate whether to push the bottom of the stack out. The R flag bit is used to indicate whether to decrement SL by 1. The SP flag bit is used to indicate the start bit of the fSID. S102, based on the parsed message, determine the space where the next hop node is located, calculate the start bit of the next hop node, and calculate and update the values ​​in each field of FFlag; S103, based on the resolution and calculation results, updates the IPv6 destination address and performs operations on the SRH; the operations on the SRH include updating the SL and LastEntry fields, stripping the entire SRH, or pushing the bottom segment of the SRH stack. S104, forward the compressed update data packet to the next hop node.

2. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, Before S102, the following is also included: Determine whether the received message contains an SRH. If not, perform SRv6 multi-node hop-by-hop processing, and ensure that the compressed SIDs of each hop device in the IPv6 destination address have the same or different lengths.

3. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, The controller's intelligent orchestration enables differentiated processing of different data streams. At any given time, some data packets that require complete verification retain their complete SRH, while others have their SRHs reduced during transmission.

4. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, The controller's intelligent orchestration initializes the IPv6 destination address and the FFlag field in the SRH. During the transmission of SRv6 packets, the FFlag field does not require any external intervention and is continuously and dynamically updated to achieve predetermined transmission optimization, delivering packets along preset paths and traversing conventional SRv6 nodes.

5. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, Each fSID may or may not carry a VL flavor; if the compressed SID does not carry a VL flavor, i.e., the next hop is a standard SRv6 node, then its address space is SegmentList[SL-1], with the starting bit being 0; if it carries a VL flavor, the method for obtaining the starting bit of the next hop node is as follows: When the Q flag is set to 1, the SP bit in the data packet points to the start of the next-hop node's fSID; when the Q flag is set to 0, the SP bit in the data packet points to the start of the current node's fSID. Since the current node knows the length of its own fSID, it can calculate the start of the next-hop node's fSID using the following formula: The starting position of the next hop node = the length of the current SP + the current fSID.

6. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, The method for determining the space of the next hop is as follows: When the P flag is set to 1, the addressing space is the IPv6 destination address; otherwise, if this compressed SID does not carry VLflavor, the addressing space is SegmentList[SL-1].

7. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, The destination address update method is as follows: After confirming the address space, let L1 be the length from the start bit to the end of the address space, and let L2 be the length from the end of the common prefix of the destination address DA to FFlag. Then we get L=min(L1,L2). Copy the contents of L bits in the address space, starting from the start bit, to the common prefix of the destination address DA.

8. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that, The stack bottom push operation specifically includes: When the S flag is set to 0, the bottom of the stack is pushed out; if the values ​​of lastEntry and SL are the same, no action is taken; otherwise, lastEntry is modified to be the same as SL, and Segment[SL+1]...Segment[lastEntry] is no longer transmitted; where SL is the SL updated by the node. Update the Hdr.ext.len field in the SRH and the length field in the IPv6 header.

9. The SRv6 processing method supporting mixed encoding of variable-length compressed SIDs according to claim 1, characterized in that... The segment removal operation specifically includes: When a data packet arrives at the penultimate hop within a segment, the value in the SL field is checked. If SL = 0, it indicates that the segment is at the top of the stack and the current node is the penultimate hop among all nodes, so the entire SRH is removed. Otherwise, the value of the SL field is decremented by 1, the flag bit Q is set to 1, the SP flag bit is set to 0, and the SP is set to the start bit of the next hop node.

10. An SRv6 processing device supporting mixed encoding of variable-length compressed SIDs, characterized in that, include: The orchestration module receives compressed SRH and IPv6 destination addresses from the source node, either intelligently or manually orchestrated by the controller. The SRH and IPv6 destination addresses are orchestrated based on the FFlag field and the FSID support capabilities of each node on the SRv6 path. The parsing module is used to receive SRv6 packets sent by the previous hop node, parse the IPv6 destination address and SRH in the IPv6 packet header, and obtain FSID and FFlag information; the Segment structure in the SegmentList in the SRH includes at least one of the standard structure, the structure without public prefix, and the structure with public prefix; in the standard structure, the Segment includes one standard SID, which occupies 128 bits of the entire segment; In a structure without a common prefix, a segment includes at least one variable-length fSID; In the structure containing a common prefix, a segment includes a common prefix, at least one variable-length fSID, and a flag field FFlag. The flag field FFlag includes a P flag bit, a Q flag bit, an S flag bit, an R flag bit, and an SP flag bit. The P flag bit is used to identify whether the address space is on an IPv6 destination address. The Q flag bit is used to identify whether the value in SP is the start bit of the current node's fSID. The S flag bit is used to indicate whether to push the bottom of the stack out. The R flag bit is used to indicate whether to decrement SL by 1. The SP flag bit is used to indicate the start bit of the fSID. The calculation module is used to determine the space of the next-hop node based on the parsed message, calculate the start bit of the next-hop node, and calculate and update the values ​​of each field in FFlag. The update module is used to update the IPv6 destination address based on the resolution and calculation results, and to perform operations on the SRH. The operations on the SRH include updating the SL and LastEntry fields, stripping the entire SRH, or pushing the bottom segment of the SRH stack. The forwarding module is used to forward compressed update data packets to the next-hop node.

Images