Compressed Routing Header

Abstract

Embodiments of the present disclosure relate to a compressed routing header. A node receives an Internet Protocol (IP) payload packet including an IPv6 transport header that has been extended with a Compressed Routing Header (CRH). The CRH includes a list of Segment Identifiers (SIDs) that identify the nodes through which the IP payload packet will traverse. The node determines the next segment of the IP payload packet by referring to the SID list. The node updates the destination IP address included in the IPv6 transport header to a specific destination IP address of the next-hop node. The node updates the remaining segment value included in the CRH, which identifies the number of segments remaining in the route of the IP payload packet. The node provides the IP payload packet to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

Description

[0001] This application is a divisional application of the invention patent application with the application date of September 29, 2019, the Chinese national application number of 201910933631.1, and the invention name of "Compressed Routing Header". Technical Field

[0002] This disclosure relates to compressed routing headers. Background Art

[0003] An Internet Protocol (IP) source node, such as an IPv6 node, can direct a payload packet through a specific path to a destination. For example, the source node can define the path as an ordered list of segments and can encode the path in an IPv6 routing header. Summary of the Invention

[0004] According to some implementations, a method can include a node receiving an Internet Protocol (IP) payload packet encapsulated with an IPv6 transport header. The IPv6 transport header can include the destination IP address of the node. The IPv6 transport header may have been extended with a Compressed Routing Header (CRH). The CRH can include a list of Segment Identifiers (SIDs), and the segment identifiers identify a set of nodes that the IP payload packet will traverse when routed through the network. The method can include the node determining the next segment of the IP payload packet by referring to the list of SIDs included in the CRH. The method can include the node updating the destination IP address to a specific destination IP address of the next-hop node based on determining the next segment. The method can include the node updating a remaining segments value included in the CRH, where the remaining segments value identifies the number of segments remaining in the routing of the IP payload packet. The method can include the node providing the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or a destination device in the network.

[0005] According to some implementations, a node may include one or more memories and one or more processors to receive an Internet Protocol (IP) payload packet encapsulated with an IPv6 transport header that has been extended with a Compressed Routing Header (CRH). The CRH may include a list of Segment Identifiers (SIDs), where the segment identifiers identify a set of nodes that the IP payload packet will traverse as it is routed through the network. The list of SIDs may have a variable length between 8 bits and 64 bits. One or more processors may determine the next segment of the IP payload packet by referring to the list of SIDs. One or more processors may update the destination IP address to a specific destination IP address of the next-hop node based on determining the next segment. One or more processors may update the remaining segments value included in the CRH, where the remaining segments value identifies the number of segments remaining in the routing of the IP payload packet. One or more processors may provide the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

[0006] According to some implementations, a non-transitory computer-readable medium may store one or more instructions that, when executed by one or more processors of a node, cause the one or more processors to receive an Internet Protocol (IP) payload packet encapsulated with a header set that includes an IPv6 transport header. The IPv6 transport header may include the destination IP address of the node. The IPv6 transport header may have been extended with a Compressed Routing Header (CRH) that includes a list of Segment Identifiers (SIDs), where the segment identifiers identify a set of nodes that the IP payload packet will traverse as it is routed through the network. The list of SIDs may have a variable length: 8 bits, 16 bits, 32 bits, or 64 bits. One or more instructions may cause the one or more processors to determine the next segment for the IP payload packet by referring to the list of SIDs included in the CRH. One or more instructions may cause the one or more processors to update the destination IP address to a specific destination IP address of the next-hop node. One or more instructions may cause the one or more processors to update the remaining segments value included in the CRH, where the remaining segments value identifies the number of segments remaining in the routing of the IP payload packet. One or more instructions may cause the one or more processors to provide the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figures 1A - 1H are diagrams of one or more example implementations described herein.

[0008] Figure 2 It is a diagram of an example Compressed Routing Header (CRH).

[0009] Figure 3 It is a diagram of an example environment in which the systems and / or methods described herein can be implemented.

[0010] Figure 4 It is Figure 3 a diagram of example components of one or more devices of

[0011] Figures 5 - 7 It is a flowchart of an example process for routing a payload packet through a network using a transport header that has been extended with a Compressed Routing Header (CRH).

[0012] Specific implementation method

[0013] The following detailed description of example implementations refers to the accompanying drawings. Like reference numerals in different drawings may identify the same or similar elements.

[0014] A network of nodes can be used to route packets. In many cases, packets can be routed through the network by taking the least-cost path. For example, a packet can have multiple possible paths through the network, and the nodes can use a routing protocol (e.g., Border Gateway Protocol (BGP) and / or a similar protocol) to select the least-cost path for routing through the network.

[0015] In some cases, segment routing can be used to allow packets to be routed using paths other than the least-cost path. For example, a client using the network to route packets may want the packet to travel through a specific firewall to avoid network congestion, etc., by taking a longer path in the network. To route a packet through the network using segment routing, a segment routing header can be used to encapsulate the packet, and the segment routing header includes a list of IP addresses (or segment identifiers having a bit length as long as the IP addresses), and the list of IP addresses serves as the required hops for the packet to take when being routed through the network. As an example, when a node in the network receives a packet, the node can process the list of IP addresses in the segment routing header to determine whether the next hop identified in the list (instead of the next hop in the least-cost path) is required.

[0016] However, segment routing is generally an inefficient way to route packets through a network. For example, many nodes used to route packets through the network have Application-Specific Integrated Circuits (ASICs), and the ASICs copy the entire list of IP addresses from the buffer memory to the on-chip memory. If the list of IP addresses is long, the node may spend a large amount of processing resources to perform the copy operation and / or spend a large amount of memory resources to store the list.

[0017] Some implementations described herein provide a network of nodes that use a Compressed Routing Header (CRH) to route encapsulated IP payload packets through the network using a predefined path, where the CRH includes a list of Segment Identifiers (SIDs) having a variable length between 8 bits and 64 bits. For example, a set of nodes can each be configured with a specific Segment Translation Table that defines one or more segments of the predefined path. As will be further described herein, the Segment Translation Table can include segments for strict routing and / or segments for loose routing. In this case, when a first edge node receives an IP payload packet, the first edge node can encapsulate the IP payload packet using an IPv6 transport header that has been extended to include the CRH. Additionally, the first edge node can provide the IP payload packet to a first intermediate node in the network.

[0018] In this case, the first intermediate node can refer to the list of SIDs included in the CRH to select an SID. Additionally, the first intermediate node can reference the Segment Translation Table to identify the corresponding SID stored in association with the interface and / or IP address of the next-hop node for the IP payload packet. In this case, the first intermediate node can update the destination IP address (e.g., which can be included in the IPv6 transport header) to the IP address of the next-hop node. Additionally, the first intermediate node can update the remaining segment value of the CRH by decrementing the value by 1.

[0019] Furthermore, the first intermediate node can provide the IP payload packet to the next-hop node (e.g., another intermediate node, an endpoint node, etc.) to allow the next-hop node to continue routing the IP payload packet. One or more additional nodes in the network can use the list of SIDs to route the IP payload packet until the IP payload packet is received by an endpoint node. When the endpoint node receives the IP payload packet, the IP payload packet can have a remaining segment value of zero. This can allow the endpoint node to process the payload header of the IP payload packet (instead of the IPv6 transport header extended with the CRH) to identify the final destination IP address of the ultimate destination (e.g., a device outside the network) and send the IP payload packet to the ultimate destination.

[0020] In this way, a node set can use a CRH to route IP payload packets through a network in a way that uses a predefined path without the need to include the IP address of each hop in the CRH. By using smaller values in the SID list (instead of a list of IP addresses), the node set saves resources (e.g., processing resources, network resources, memory resources, etc.) compared to other types of segment routing headers. For example, the use of a CRH saves processing resources that the node set would otherwise perform copy operations on a longer and more conventional segment routing header, saves network resources (compared to a conventional segment routing header) by reducing the total length of the IP payload packets transmitted over the network, saves memory resources (compared to a conventional segment routing header) by reducing the amount of memory required to store the IP payload packets, etc.

[0021] In addition, some implementations described herein allow the use of one or more link-local IPv6 addresses to route IP payload packets through one or more strictly routed segments (further defined herein). For example, for all segments except the final segment, a node receiving an IP payload packet can update the destination IP address to a link-local IPv6 address. As further described elsewhere herein, this improves security by reducing the chance that an IP payload packet is routed from one of the strictly routed segments. Additionally, by updating the destination IP address to a global IP address (instead of a link-local IPv6 address) on the final segment, the node set further improves security by providing protection against link-local address spoofing.

[0022] Figures 1A - 1H is a diagram of one or more example implementations 100 described herein. For example, (one or more) example implementations 100 can include a first peer device (shown as Peer Device 1), a second peer device (shown as Peer Device 2), and a node set that is part of a network (e.g., a first edge node (shown as Node A), an intermediate node set (shown as Nodes I1, I2, and I3), and a second edge node (shown as Node B)). As Figures 1A - 1H shown, the node set can be configured with a specific segment translation table and can use the specific segment translation table to route Internet Protocol (IP) payload packets encapsulated with an IPv6 transport header that has been extended with a compressed routing header (CRH) through the network.

[0023] As Figure 1AAs shown, and by reference numeral 102, a set of nodes may be configured with a segment translation table. For example, a set of nodes may be configured with a segment translation table to assist in routing network traffic via a specific path. The segment translation table may be provided to the set of nodes via a network controller, via a distributed routing protocol, and / or via another device or technique. The segment translation table may include values for one or more segments that define the path that an IP payload packet may take through the network. For example, the segment translation table may include one or more segments of strict routing, one or more segments of loose routing, and / or a combination of segments of strict and loose routing. A segment of loose routing may be defined as a path from a node to a terminal interface, where the node and the terminal interface are connected via one or more other nodes and / or links. A segment of strict routing may be defined as a path from a node to a terminal interface, where there is exactly one link from the node to the terminal interface.

[0024] In some implementations, a node may be configured with a segment translation table that includes a set of segments of strict routing. For each segment of strict routing, the segment translation table may include a SID unique to the node, two IP addresses (e.g., a global IP address, a link-local IPv6 address, etc.) that may be used to identify the interface at which the segment of strict routing terminates (i.e., the terminal interface), and one link that connects the node to the terminal interface. The SID may be represented by a value that is less expensive for the node to replicate than an IP address (e.g., an 8-bit value, a 16-bit value, etc.). The interface at which the segment of strict routing terminates is a global IP address (e.g., a globally scoped IP address, a unique local address (ULA), etc.) or a link-local IPv6 address. The link-local IPv6 address may be used when sending an IP payload packet to an intermediate node, and the global IP address may be used when sending an IP payload packet to an edge node (e.g., an egress node).

[0025] As shown in the example, a set of network nodes may be configured with a segment translation table that includes one or more segments of strict routing. In this example, a first edge node (Node A) may be configured with a segment translation table that has two segments of strict routing. The first segment of strict routing may include a SID of 129, a global IP address of 2001:db8::1, a link-local IPv6 address of fe80:0:0:1::2, and an interface from the first edge node to a first intermediate node (shown as A->I1). The second segment of strict routing may include a SID of 130, a global IP address of 2001:db8::1, a link-local IPv6 address of fe80:0:0:2::2, and an interface from the first edge node to a second intermediate node (shown as A->I2). In some cases, an ingress node (e.g., the first edge node) may include a master list of segments for the entire route of an IP payload packet (e.g., in Figure 1Ashown as part of a fragmentation translation table for other nodes).

[0026] Additionally or alternatively, a node may be configured with a fragmentation translation table that includes a set of loose routing fragments. For each loose routing fragment, the fragmentation translation table may include a SID, an IP address that may be used to identify a termination interface, and one or more nodes and / or links connecting the source node and the termination interface. The IP address is a global IP address (e.g., a global scope address, a ULA, etc.). Additionally, the fragmentation translation table including the loose routing fragments may be configured for each of a set of nodes.

[0027] In this way, a set of nodes may be configured with a fragmentation translation table that can be used to route IP payload packets through the network.

[0028] As Figure 1B shown, and by reference numeral 104, a first edge node may be configured with routing instructions. For example, a first edge node may be configured with routing instructions that specify a particular path that certain IP payload packets will take through the network and identify one or more required hops that certain IP payload packets will take through the network, etc. In this case, the first edge node may be configured with routing instructions provided by a network controller, provided by a device associated with a network administrator, provided by a client device that has explicitly requested that certain IP payload packets be subject to the routing instructions, etc. The routing instructions may apply to all IP payload packets, a particular type of IP payload packet, IP payload packets having a particular source IP address and / or destination IP address, etc.

[0029] As an example, the routing instructions may indicate that payload packets having a source IP address of a first peer device and / or a destination IP address of a second peer device will be routed from the first peer device (peer device 1) to the first edge node (node A), from the first edge node to the first intermediate node (node I1), from the first intermediate node to the third intermediate node (node I3), from the third intermediate node to the second edge node (node B), and from the second edge node to the second peer device (peer device 2).

[0030] As shown by reference numeral 106, a first peer device may provide an IP payload packet to a first edge node. For example, the first peer device may encapsulate an IP payload packet having a payload header (e.g., an IPv4 payload header, an IPv6 payload header, an Ethernet payload header, etc.). The payload header may be an IPv4 payload header, an IPv6 payload header, an Ethernet payload header, etc. The payload header may include a source IP address of the first peer device (shown as 192.179.1.11) and a destination IP address of a second peer device (shown as 192.179.2.10).

[0031] In this way, the first edge node is able to receive the IP payload packet from the first peer device.

[0032] As Figure 1C shown, and by reference numeral 108, the first edge node may encapsulate the IP payload packet using an IPv6 transport header extended with a used Compressed Routing Header (CRH). For example, the first edge node may refer to a segmentation translation table and / or routing instructions to determine the IP payload packet to be encapsulated using the IPv6 transport header extended with the CRH. As an example, the routing instructions may indicate that an IP payload packet having a specific source IP address or destination IP address will be encapsulated using the IPv6 transport header extended with the CRH.

[0033] The CRH may include a list of SIDs defining the path of the IP payload packet, a total segment value, a remaining segment value, a compression value, a next header value, a header extension length, a routing type, and a reserved value. The list of SIDs may include a list of node-specific values corresponding to the list of SIDs, and the list of SIDs is included in the segmentation translation table. The total segment value may identify the maximum number of segments required for the IP payload packet to reach the final hop node (e.g., the second edge device). The remaining segment value may identify the number of remaining segments between the source node (e.g., the node receiving the IP payload packet) and the second edge node. A description of the remaining values of the CRH may be found Figure 2 below.

[0034] In some implementations, before determining which values are included in the CRH, the first edge node may update the source IP address and destination IP address included in the IPv6 transport header. For example, the first edge node may update the source IP address using the global IP address of the first edge node, and may update the destination IP address using the link-local IPv6 address of the next hop node (which may be found in the segmentation translation table).

[0035] In some implementations, the first edge node may select those values that are included in the CRH. For example, the first edge node may select the values identified in the segmentation translation table as the values of the SID list. Additionally, the first edge node may determine the total segmentation value based on the number of entries in the SID list. One or more additional values in the CRH may be selected or generated in the manner described elsewhere herein.

[0036] In some implementations, the first edge node may use an IPv6 transport header that has been extended with the CRH to encapsulate the IP payload packet. For example, the first edge node may encapsulate the IP payload packet such that the IPv6 transport header is the outermost header of the IP payload packet. There may be a set of extension headers (e.g., hop-by-hop extension header, routing extension header, destination header, etc.) between the IP payload packet and the IPv6 transport header that are not part of the processes described herein.

[0037] As shown by reference numeral 110, the first edge node may provide the IP payload packet encapsulated to the first intermediate node. In this way, the first edge node is able to use an IPv6 transport header that has been extended with the CRH to encapsulate the IP payload packet and is able to use the values included in the CRH to route the IP payload packet to the next hop in the network.

[0038] As Figure 1D shown, the first intermediate node may perform one or more header preprocessing checks and / or one or more security checks on the IP payload packet. For example, and as shown by reference numeral 112, the first intermediate node may determine whether the destination IP address included in the IPv6 transport header matches the IP address of the first intermediate node. This is because the node set is configured to process, update, and / or modify the CRH only when the destination IP address included in the IPv6 transport header matches the IP address of the node. In this example, the first intermediate node may determine that the destination IP address matches the IP address of the first intermediate node (e.g., the IPv6 transport header is shown as having a destination IP address of fe80:0:0:1::2, which is the link-local IPv6 address of the first intermediate node).

[0039] As shown by reference numeral 114, a first intermediate node may determine the number of remaining segments in the path of an IP payload packet. For example, the first intermediate node may process the remaining segment value of the CRH to determine the number of remaining segments in the path. If the remaining segment value is greater than zero, the first intermediate node may continue to process the CRH. If the remaining segment value is zero, the first intermediate node may stop processing the CRH and process the next header of the IP payload packet (e.g., one of an extension header, a payload header, etc.). In fact, the remaining segment value is zero only when the final node in the network is receiving the IP payload packet. As will be further described herein, this provides a way for the final node to identify when the IP payload packet reaches the last hop in the network and may cause the final node to abandon CRH processing and route the IP payload packet to an external network device.

[0040] As shown by reference numeral 116, a first intermediate node may perform one or more security checks. For example, the first intermediate node may determine whether the source IP address included in the IPv6 transport header is a link-local IPv6 address, may determine whether the source IP address or the destination IP address included in the IPv6 transport header is a multicast address, may determine whether the hop limit has been exceeded, may determine whether the IP payload packet is malformed, etc. For example, assume that an IPv6 transport header is used to encapsulate an IP payload packet, the IPv6 transport header has been extended with a 16-byte long CRH and includes a total segment value of 64 (where each segment is one byte). In this example, 64 single-byte segments do not fit into the 16-byte CRH, which means that the payload packet has been malformed. In such a case, the first intermediate node will identify that the payload packet is malformed and will discard the payload packet.

[0041] In this way, the first intermediate node performs one or more header preprocessing checks and / or one or more security checks on the IP payload packet (e.g., one or more headers of the IP payload packet).

[0042] As Figure 1E shown, and by reference numeral 118, a first intermediate node may determine the next segment for the IP payload packet. For example, the first intermediate node may determine the index i of the next segment by subtracting the remaining segment value from the total segment value. In the example shown, the total segment value indicates that there are two total segments, and the remaining segment value indicates that there are two segments remaining. By subtracting the remaining segment value from the total segment value, the first intermediate node may determine that the index i has a zero value.

[0043] Additionally, the first intermediate node may identify the SID number at index position i in the SID list. In the example shown, the SID value at segment [0] is 129. Further, this allows the first intermediate node to determine the next segment by searching in the segment translation table for the corresponding SID that can be stored in association with the global IP address of the next-hop node, the link-local IPv6 address of the next-hop node, and the link identifier of the link to the next-hop node.

[0044] As shown by reference numeral 120, the first intermediate node may update the destination IP address and the remaining segment value of the IP payload packet. For example, the first intermediate node may translate the destination IP address by using the global IP address or the link-local IPv6 address of the next-hop node. In this case, if the remaining segment value is 1 (or another value indicating that the next segment is the final segment), the first intermediate node may translate the destination IP address by using the global IP address, or if the remaining segment value is greater than 1 (or another value indicating that the next segment is not the final segment), the first intermediate node may replace the destination IP address by using the link-local IPv6 address. In some cases, the first intermediate node may convert an eight-bit, sixteen-bit, thirty-two-bit, or sixty-four-bit segment identifier to a one-hundred-twenty-eight-bit IPv6 address.

[0045] By updating the destination IP address included in the IPv6 transport header by using the global IP address at the penultimate node, the penultimate node ensures that when the IP payload packet is routed to the final destination (e.g., the second peer device), the IP payload packet will never have a link-local address. This can prevent various types of attacks where an off-path link attacker may attempt to assume the link state by using the link-local address. By replacing the destination IP address included in the IPv6 transport header by using the link-local IPv6 address, the node performing the update can prevent certain types of misprogramming. For example, between the time when the IP payload packet is sent and the time when the IP payload packet arrives at the first intermediate node, the first intermediate node may have received an instruction to update the segment translation table. In this case, the first intermediate node may incorrectly send the IP payload packet to an adjacent node that is not part of the strict routing path of the IP payload packet based on the updated segment translation table. However, since the destination IP address will be updated to the link-local IPv6 address, the adjacent node that should not receive the IP payload packet will discard the IP payload packet. This is because a node that is not part of the strict routing path may be configured to discard an IP payload packet having a link-local IPv6 source or destination IP address.

[0046] In some implementations, the first intermediate node may update the remaining segment value. For example, the first intermediate node may decrement the remaining segment value by 1. In the example shown, the first intermediate node may reduce the remaining segment value from the value 2 to the value 1.

[0047] In this way, the first intermediate node can use the CRH to determine the next segment for the IP payload packet and can update one or more values of the IP payload packet that allow subsequent nodes to continue routing the IP payload packet.

[0048] As Figure 1F shown, and by reference numeral 122, the first intermediate node may provide the IP payload packet encapsulated into the third intermediate node. The IPv6 transport header of the IP payload packet may include the source IP address of the first endpoint node and the destination IP address as the link-local IPv6 address of the third intermediate node.

[0049] As shown by reference numeral 124, the third intermediate node may determine whether the destination IP address included in the IPv6 transport header matches the IP address of the third intermediate node in the manner described elsewhere herein. As shown by reference numeral 126, the third intermediate node may determine the number of remaining segments in the IP payload packet path in the manner described elsewhere herein. In the example shown, the third intermediate node may determine that there is one remaining segment, which may cause the third intermediate node to continue processing the CRH. As shown by reference numeral 128, the third intermediate node may perform one or more security checks in the manner described elsewhere herein.

[0050] In this way, the third intermediate node can perform one or more header preprocessing checks and / or one or more security checks on the IP payload packet.

[0051] As Figure 1G shown, and by reference numeral 130, the third intermediate node may determine the next segment. For example, the third intermediate node may determine the next segment in the manner described elsewhere herein.

[0052] In the example shown, the total segment value indicates that there are two total segments, and the remaining segment value indicates that there is one remaining segment. By subtracting the remaining segment value from the total segment value, the third intermediate node can determine that the index i has a value of 1. Additionally, the third intermediate node can process the SID list to identify that the SID at index position 1 has a value of 129. This can allow the third intermediate node to determine the next segment by searching for the corresponding SID value 129 in the segment translation table, where the corresponding SID value is stored in association with the global IP address 2001:db8::3, the link-local IPv6 address fe80:0:0:b::2, and the link identifier of the link from the third intermediate node to the second edge node.

[0053] As indicated by reference numeral 132, the third intermediate node can update the destination IP address of the IP payload packet and the remaining segment value included in the CRH. For example, the third intermediate node can replace the destination IP address included in the IPv6 transport header with the link-local IPv6 address or global IP address of the next-hop node. In this case, the third intermediate node can determine that the remaining segment value is 1, and based on the determination that the remaining segment value is 1, can update the destination IP address included in the IPv6 transport header with the global IP address of the next-hop node. In the example shown, the third intermediate node can update the destination IP address from the value fe80:0:0:3::2 to the value 2001:db8::b.

[0054] Additionally, the third intermediate node can decrement the remaining segment value by 1. In the example shown, the third intermediate node can decrement the remaining segment value from the value 1 to the value zero.

[0055] In this way, the third intermediate node is able to determine the next segment of the IP payload packet and is able to update one or more values of the IP payload packet to allow subsequent nodes to continue routing the IP payload packet.

[0056] As Figure 1H shown, and by reference numeral 134, the third intermediate node can provide the IP payload packet encapsulated to the second edge node (Node B). The IP payload packet can include the source IP address (2001:db8::a) of the first edge node and the destination IP address (2001:db8::b) of the second edge node. In some implementations, the second edge node can perform one or more header preprocessing checks in the manner described elsewhere herein.

[0057] As indicated by reference numeral 136, the second edge node can determine the next hop for the IP payload packet based on the number of remaining segments. For example, the second edge node can process the CRH to determine that the remaining segment value is equal to zero.

[0058] In some implementations, since the remaining fragment value is zero, the second edge node can forgo further processing of the CRH and can process one or more other headers of the IP payload packet (e.g., payload headers, etc.). In the example shown, the payload header can include the destination IP address (192.172.1.10) for the second peer device, and the destination IP address can allow the second edge device to route the IP payload packet to the second peer device.

[0059] In some implementations, the second edge node can determine the next hop by referring to a fragment translation table. Although not shown, the second edge node can be configured with a fragment translation table that has the destination IP address (e.g., in place of a global IP address and with a null value for a link-link-local IPv6 address) stored as part of the translation table for the second peer device, and the second edge node can refer to the fragment translation table to identify the destination IP address of the second peer device.

[0060] In this way, a set of nodes can use the CRH to route IP payload packets through the network in a manner that uses a strictly defined path, without the need to include the IP address for each hop in the strictly defined path in the fragment list. This saves resources (e.g., processing resources, network resources, memory resources, etc.) compared to other types of segment routing headers that would spend a large amount of resources performing copy operations on longer and more conventional segment routing headers.

[0061] As described above, provided as an example Figures 1A - 1H . Other examples may differ from those Figures 1A - 1H described. For example, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices / networks arranged differently from those Figures 1A - 1H shown. Additionally, Figures 1A - 1H two or more of the devices shown in Figures 1A - 1H may be implemented within a single device, or the single device shown in

[0062] Figure 2 is a diagram of an example Compressed Routing Header (CRH) 200. As Figure 2As shown, the CRH 200 can include a Next Header field, a Header Extension Length field, a Routing Type field, a Remaining Fragments field (shown as Segments Left), a Total Fragments field (shown as Num Segments), a Reserved field, a Compression field, and a list of Segment Identifier (SID) fields. The Next Header field can include an octet selector value that identifies the type of header that immediately follows an Internet Protocol (IP) header (e.g., an IPv6 header). The Header Extension Length field can include an 8-bit unsigned integer value that identifies the length of the per-hop options header in eight-octet units, excluding the first eight octets.

[0063] As can be defined by the Internet Assigned Numbers Authority (IANA), the Routing Type field can include an octet identifier value for a particular routing header variant. The Remaining Fragments field can include a value that identifies the number of remaining fragments between the originating node (e.g., the node that receives the IP payload packet) and the final-hop node (e.g., the node that is part of the final segment in the path). The Total Fragments field can include a value that identifies the maximum number of fragments required for the IP payload packet to reach the final-hop node. This value can be defined by multiple entries in the SID list. The Reserved field can include a value that is set to zero by the sending node and ignored by the receiving node.

[0064] The Compression field can include a two-bit value that can be examined to determine whether the IP payload packet is malformed. For example, the Compression field can include a value that the node processes to determine the minimum CRH length, which can allow the node to determine whether the IP payload packet is malformed. The minimum CRH length is measured in eight-octet units (excluding the first eight octets). The Compression field can include a value of zero, one, two, or three. A value of zero can correspond to octet encoding, value 1 can correspond to 16-bit encoding, value 2 can correspond to 32-bit encoding, and value 3 can correspond to 64-bit encoding. Additionally, if the compression value is set to value 2 or value 3, the SID list starts at a 32-bit boundary. In these cases, the Reserved field can be extended. In all cases, the CRH ends at a 64-bit boundary. Thus, the CRH can be padded with zeros.

[0065] As an example, to calculate the minimum CRH length, a node can provide a compression value and a total number of segments as inputs to an algorithm for calculating the minimum CRH length. To provide example pseudocode, a node can perform the following: If (compression value == 0), set a value x to be equal to the total number of segments minus 2, set the compression value to be equal to x divided by 8, and if there is a remainder when x is divided by 8, increment the compression value by 1. If (compression value == 1), set x to be equal to the total number of segments minus 1, set the compression value to be equal to x divided by 4, and if there is a remainder when x is divided by 4, increment the compression value by 1. If (compression value == 2), set x to be equal to the total number of segments, set the compression value to be equal to x divided by 2, and if there is a remainder when x is divided by 2, increment the compression value by 1. If (compression value == 3), then set the compression value to be equal to the total number of segments.

[0066] The SID list field can include a set of SID values representing segments in the segment list. In some implementations, such as when the segment list includes loosely routed segments, each SID can include a unique value. In some implementations, such as when the segment list includes strictly routed segments, each SID can be unique to a node such that the same SID value can be used on multiple nodes.

[0067] As described above, provided as an example Figure 2 . Other examples can be different from those Figure 2 described. For example, there can be additional fields and / or values, fewer fields and / or values, different fields and / or values, or fields and / or values arranged differently from those Figure 2 shown.

[0068] Figure 3 is a diagram of an example environment 300 in which the systems and / or methods described herein can be implemented. As Figure 3 shown, environment 300 can include one or more peer devices 310, a node group 320 (shown as nodes 320-1 through 320-N), and a network 330. The devices of environment 300 can be interconnected via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0069] Peer device 310 includes one or more devices capable of receiving and / or providing network traffic. For example, peer device 310 may include traffic transfer devices (e.g., routers, gateways, switches, firewalls, hubs, bridges, reverse proxies, servers (e.g., proxy servers, servers executing virtual machines, etc.)), security devices, intrusion detection devices, load balancers, or devices of similar types. In some implementations, peer device 310 may include endpoint devices that are sources or destinations of network traffic. For example, peer device 310 may include computers or devices of similar types. Peer device 310 may receive network traffic from other peer devices 310 via network 330 (e.g., by routing payload packets using (multiple) nodes 320 as intermediate nodes) and / or may provide network traffic to other peer devices 310. In some implementations, peer device 310 may include edge devices located at the edge of one or more networks. For example, peer device 310 receives network traffic from devices external to network 330 and / or may provide network traffic (e.g., payload packets) to devices external to network 330.

[0070] Nodes 320 include one or more devices capable of receiving, processing, storing, routing, and / or providing traffic (e.g., payload packets, files, etc.) in the manner described herein. For example, nodes 320 may include routers (e.g., label switching routers (LSRs), label edge routers (LERs), ingress routers, egress routers, provider routers (e.g., provider edge routers, provider core routers, etc.), virtual routers, etc.). Additionally or alternatively, nodes 320 may include gateways, switches, firewalls, hubs, bridges, reverse proxies, servers (e.g., proxy servers, cloud servers, data center servers, etc.), load balancers, and / or similar devices.

[0071] In some implementations, nodes 320 may be physical devices implemented within an enclosure (e.g., chassis). In some implementations, nodes 320 may be virtual devices implemented by one or more computer devices in a cloud computing environment or data center.

[0072] In some implementations, node 320 may be configured with one or more segment translation tables. In some implementations, node 320 may receive payload packets from peer device 310. In some implementations, node 320 may encapsulate the payload packets using a Compressed Routing Header (CRH) and may route the IP payload packets to another node 320 using one or more techniques described elsewhere herein. In some implementations, node 320 may be an edge node in network 330. In some implementations, node 320 may be an intermediate node in network 330 (i.e., a node between two or more edge nodes).

[0073] Network 330 includes one or more wired and / or wireless networks. For example, network 330 may include a cellular network (e.g., a fifth-generation (5G) network, a fourth-generation (4G) network such as a Long-Term Evolution (LTE) network, a third-generation (3G) network, a Code Division Multiple Access (CDMA) network, a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., a Public Switched Telephone Network (PSTN)), a private network, an ad-hoc network, an intranet, the Internet, a fiber-based network, a cloud computing network, etc. and / or a combination of these or other types of networks).

[0074] Provide Figure 3 The number and arrangement of the devices and networks shown in Figure 3 as one or more examples. In fact, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently from Figure 3 the devices and / or networks shown in Figure 3 Two or more of the devices shown in may be implemented in a single device, or

[0075] Figure 4 is a diagram of example components of device 400. Device 400 may correspond to peer device 310 and / or node 320. In some implementations, peer device 310 and / or node 320 may include one or more devices 400 and / or one or more components of device 400. As Figure 4As shown, the device 400 may include one or more input components 405-1 through 405-B (B≥1) (collectively referred to hereinafter as input components 405 and individually as input component 405), a switching component 410, one or more output components 415-1 through 415-C (C≥1) (collectively referred to hereinafter as output components 415 and individually as output component 415), and a controller 420.

[0076] The input component 405 may be an attachment point for a physical link and may be an entry point for input traffic (e.g., payload packets). The input component 405 may process the input traffic, for example, by performing data link layer encapsulation or decapsulation. In some implementations, the input component 405 may send and / or receive payload packets. In some implementations, the input component 405 may include an input line card such as one or more interface cards (IFCs) (including one or more payload packet processing components (e.g., in the form of an integrated circuit)), a payload packet forwarding component, a line card controller component, an input port, a processor, a memory, and / or an input queue. In some implementations, the device 400 may include one or more input components 405.

[0077] The switching component 410 may interconnect the input component 405 and the output component 415. In some implementations, the switching component 410 may be implemented via one or more crossbars, via a bus, and / or using a shared memory. The shared memory may act as a temporary buffer to store payload packets from the input component 405 before the payload packets are finally scheduled for delivery to the output component 415. In some implementations, the switching component 410 may enable the input component 405, the output component 415, and / or the controller 420 to communicate.

[0078] The output component 415 may store payload packets and may schedule the payload packets for transmission over an output physical link. The output component 415 may support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, the output component 415 may send and / or receive payload packets. In some implementations, the output component 415 may include an output line card such as one or more IFCs (including one or more payload packet processing components (e.g., in the form of an integrated circuit)), a payload packet forwarding component, a line card controller component, an output port, a processor, a memory, and / or an output queue. In some implementations, the device 400 may include one or more output components 415. In some implementations, the input component 405 and the output component 415 may be implemented by the same set of components (e.g., and the input / output component may be a combination of the input component 405 and the output component 415).

[0079] The controller 420 includes a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC)) and / or other types of processors or processing components. The processor is implemented in hardware, firmware, or a combination of software and hardware. In some implementations, the controller 420 may include one or more processors that can be programmed to perform functions.

[0080] In some implementations, the controller 420 may include a random access memory (RAM), a read only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, optical memory, etc.) that store information and / or instructions used by the controller 420.

[0081] In some implementations, the controller 420 may communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about the network topology. The controller 420 may create a translation table based on the network topology information, create a forwarding table based on the translation table, and forward the forwarding table to the input component 405 and / or the output component 415. The input component 405 and / or the output component 415 may use the forwarding table to perform a routing lookup on incoming and / or outgoing payload packets. In some cases, the controller 420 may create a session table based on information determined when initializing a link failure detection (e.g., BFD) session, and may forward the session table to the input component 405 and / or the output component 415.

[0082] The controller 420 may perform one or more of the processes described herein. The controller 420 may perform these processes in response to executing software instructions stored by a non-transitory computer-readable medium. The computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical storage device or a memory space across multiple physical storage devices.

[0083] The software instructions may be read into the memory and / or storage component associated with the controller 420 from another computer-readable medium or from another device via a communication interface. When executed, the software instructions stored in the memory and / or storage component associated with the controller 420 may cause the controller 420 to perform one or more of the processes described herein. Additionally or alternatively, one or more of the processes described herein may be performed using hardwired circuitry in place of or in combination with software instructions. Thus, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0084] Provided Figure 4The number and arrangement of components shown are examples. In fact, device 400 may include additional components, fewer components, different components, or components arranged differently from those Figure 4 shown. Additionally or alternatively, a set of components (e.g., one or more components) of device 400 may perform one or more functions described as being performed by another set of components of device 400.

[0085] Figure 5 is a flowchart of an example process 500 for routing a payload packet through a network using a transport header extended with a Compressed Routing Header (CRH). In some implementations, Figure 5 one or more processing blocks of Figure 5 may be performed by a node (e.g., node 320). In some implementations,

[0086] As Figure 5 shown, process 500 may include receiving an Internet Protocol (IP) payload packet encapsulated with an IPv6 transport header, where the IPv6 transport header includes the destination IP address of a node, where the IPv6 transport header has been extended with a variable-length Compressed Routing Header (CRH), and where the CRH includes a list of Segment Identifiers (SIDs) that identify a set of nodes that the IP payload packet will traverse when routed through the network. (Block 510). For example, as described above, a node (e.g., using input component 405, switching component 410, controller 420, etc.) may receive an Internet Protocol (IP) payload packet encapsulated with an IPv6 transport header. In some implementations, the IPv6 transport header may include the destination IP address of a node. In some implementations, the IPv6 transport header may have been extended with a variable-length Compressed Routing Header (CRH). In some implementations, the CRH may include a list of Segment Identifiers (SIDs) that identify a set of nodes that the IP payload packet will traverse when routed through the network.

[0087] As Figure 5 further shown, process 500 may include determining a next segment for the IP payload packet by referring to the list of SIDs included in the CRH (block 520). For example, as described above, a node (e.g., using controller 420) may determine a next segment for the IP payload packet by referring to the list of SIDs included in the CRH.

[0088] As Figure 5As further shown, process 500 may include updating the destination IP address to the specific destination IP address of the next-hop node based on determining the next segment (block 530). For example, as described above, a node (e.g., using controller 420) may update the destination IP address to the specific destination IP address of the next-hop node based on determining the next segment.

[0089] As Figure 5 As further shown, process 500 may include updating the remaining segment value included in the CRH, where the remaining segment value identifies the number of segments remaining in the routing of the IP payload packet (block 540). For example, as described above, a node (e.g., using controller 420) may update the remaining segment value included in the CRH, where the remaining segment value identifies the number of segments remaining in the routing of the IP payload packet.

[0090] As Figure 5 As further shown, process 500 may include providing the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network (block 550). For example, as described above, a node (e.g., using switching component 410, output component 415, controller 420, etc.) may provide the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

[0091] Process 500 may include additional implementations, e.g., any single implementation or a combination of the implementations described below and / or any implementation in combination with one or more other processes described elsewhere herein.

[0092] In some implementations, the SID list may have a variable length: eight bits, sixteen bits, thirty-two bits, or sixty-four bits. In some implementations, the set of segments in the IP payload packet routing may include at least one of the following: a strictly routed segment or a loosely routed segment. In some implementations, the final segment in the IP payload packet routing may be a strictly routed segment. In some implementations, a node may configure a segment translation table that associates two or more of the following: a set of SIDs corresponding to the SID list, a set of global IP addresses, a set of link-local IPv6 addresses, or a set of interface mappings.

[0093] In some implementations, when determining the next fragment for an IP payload packet, a node may identify the SIDs in the SID list included in the CRH that are associated with the node, and may use the SIDs to determine the next fragment by referring to a fragment translation table that maps the SIDs to the following: a global IP address of the next-hop node and a fragment translation table that maps to a link-local IPv6 address that identifies the interface of the next-hop node, and when updating the destination IP address, the node may update the destination IP address using the global IP address or the link-local IPv6 address based on whether the next fragment is the final fragment.

[0094] In some implementations, when updating the destination IP address, the node may update the destination IP address to the global IP address based on the next fragment being the final fragment of the route, where the destination IP address is updated to the global IP address, rather than updating the destination IP address to the link-local IPv6 address based on the next fragment being the final fragment of the route.

[0095] Although Figure 5 illustrates example blocks of process 500, in some implementations, process 500 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently than the Figure 5 blocks depicted therein. Additionally or alternatively, two or more of the blocks of process 500 may be executed in parallel.

[0096] Figure 6 is a flowchart of an example process 600 for routing a payload packet through a network using a transport header extended with a compressed routing header (CRH). In some implementations, Figure 6 one or more of the processing blocks may be performed by a node (e.g., node 320). In some implementations, Figure 6 one or more of the processing blocks may be performed by another device or a group of devices separate from the node or a group of devices including the node (e.g., peer device 310).

[0097] As Figure 6 shown, process 600 may include receiving an Internet Protocol (IP) payload packet encapsulated using an IPv6 transport header that has been extended with a compressed routing header (CRH), where the CRH includes a list of segment identifiers (SIDs) that identify a set of nodes that the IP payload packet will traverse when routed through the network, and where the SID list has a variable length between 8 bits and 64 bits (block 610). For example, as described above, a node (e.g., using input component 405, switching component 410, controller 420, etc.) may receive an Internet Protocol (IP) payload packet that includes a set of headers.

[0098] As Figure 6 As further shown, process 600 may include determining the next segment of the IP payload packet by referring to the SID list (block 620). For example, as described above, a node (e.g., using controller 420) may determine the next segment for the IP payload packet by referring to the SID list.

[0099] As Figure 6 As further shown, process 600 may include updating the destination IP address to the specific destination IP address of the next-hop node (block 630). For example, as described above, a node (e.g., using controller 420) may update the destination IP address to the specific destination IP address of the next-hop node.

[0100] As Figure 6 As further shown, process 600 may include updating the remaining segment value included in the CRH, where the remaining segment value identifies the number of segments remaining in the routing of the IP payload packet (block 640). For example, as described above, a node (e.g., using controller 420) may update the remaining segment value included in the CRH, where the remaining segment value identifies the number of segments remaining in the routing of the IP payload packet.

[0101] As Figure 6 As further shown, process 600 may include providing the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network (block 650). For example, as described above, a node (e.g., using switching component 410, output component 415, controller 420, etc.) may provide the IP payload packet including the CRH to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

[0102] Process 600 may include additional implementations, e.g., any single implementation or any combination of the implementations described below and / or in combination with one or more other processes described elsewhere herein.

[0103] In some implementations, the set of segments in the IP payload packet routing may include segments with strict routing. In some implementations, the final segment in the IP payload packet routing may be a segment with strict routing. In some implementations, a node may configure a segment translation table associated with two or more of the following before receiving the IP payload packet: a set of SIDs corresponding to the SID list, a set of global IP addresses, a set of link-local IPv6 addresses, or a set of interface mappings.

[0104] In some implementations, when determining the next segment for an IP payload packet, a node may identify the SID in the SID list included in the CRH that is associated with the node, and may determine the next segment by using the SID to refer to a segment translation table that maps the SID to the global IP address of the next-hop node and the link-local IPv6 address that identifies the next-hop node interface. The global IP address or the link-local IPv6 address may be used as the destination IP address of the IP payload packet. In some implementations, when updating the destination IP address, the node may update the destination IP address by using the global IP address of the node or the link-local IPv6 address of the next-hop node based on whether the next segment is the final segment.

[0105] In some implementations, when updating the destination IP address, the node may update the destination IP address to a specific destination IP address based on the next segment being the final segment of the route, where the specific destination IP address is the global IP address, and where the final segment is a segment of a strict route. In some implementations, the node may determine whether the remaining segment value included in the CRH is a non-zero value before determining the next segment, and may determine whether to continue processing the CRH or process another header of the header set based on the remaining segment value being non-zero.

[0106] Although Figure 6 illustrates example blocks of process 600, in some implementations, process 600 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently than the Figure 6 blocks depicted therein. Additionally or alternatively, two or more blocks in process 600 may be executed in parallel.

[0107] Figure 7 is a flowchart of an example process 700 for routing a payload packet through a network using a transport header that has been extended with a Compressed Routing Header (CRH). In some implementations, Figure 7 one or more processing blocks of Figure 7 may be performed by a node (e.g., node 320). In some implementations,

[0108] As Figure 7As shown, process 700 may include receiving an Internet Protocol (IP) payload packet that has been encapsulated using a set of headers that includes an IPv6 transport header, where the IPv6 transport header includes the destination IP address of a node, where the IPv6 transport header has been extended using a Compressed Routing Header (CRH), the Compressed Routing Header includes a list of Segment Identifiers (SIDs) that identify a set of nodes that the IP payload packet will traverse as it is routed through the network, and where the SID list has a variable length of eight bits, sixteen bits, thirty-two bits, and sixty-four bits (block 710). For example, as described above, a node (e.g., using input component 405, switching component 410, controller 420, etc.) may receive an IP payload packet that has been encapsulated using a set of headers that includes a CRH and a destination header. In some implementations, the CRH may include a list of segment identifiers (SIDs) that identify a set of nodes that the IP payload packet will traverse as it is routed through the network, and the SID list has a variable length of eight bits, sixteen bits, thirty-two bits, or sixty-four bits.

[0109] As Figure 7 As further shown, process 700 may include determining the next segment for the IP payload packet by referring to the list of SIDs included in the CRH (block 720). For example, as described above, a node (e.g., using controller 420) may determine the next segment of the IP payload packet by referring to the list of SIDs included in the CRH.

[0110] As Figure 7 As further shown, process 700 may include updating the destination IP address to a specific destination IP address of the next-hop node (block 730). For example, as described above, a node (e.g., using controller 420) may update the destination IP address to a specific destination IP address of the next-hop node.

[0111] As Figure 7 As further shown, process 700 may include updating the remaining segment value included in the CRH, the remaining segment value identifying the number of segments remaining in the routing of the IP payload packet (block 740). For example, as described above, a node (e.g., using controller 420) may update the remaining segment value included in the CRH, the remaining segment value identifying the number of segments remaining in the routing of the IP payload packet.

[0112] As Figure 7As further shown, process 700 may include providing an IP payload packet including a CRH to a next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network (block 750). For example, as described above, a node (e.g., using controller 420) may provide an IP payload packet including a CRH to a next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

[0113] Process 700 may include additional implementations, such as any single implementation or any combination of the implementations described below and / or in combination with one or more other processes described elsewhere herein.

[0114] In some implementations, the set of segments in the IP payload packet routing may include at least one strictly routed segment. In some implementations, the final segment in the IP payload packet routing may be a strictly routed segment. In some implementations, a node may configure a segment translation table that associates two or more of the following before receiving an IP payload packet: a set of SIDs corresponding to an SID list, a set of global IP addresses, a set of link-local IPv6 addresses, or a set of interface mappings.

[0115] In some implementations, when determining the next segment of an IP payload packet, a node may identify the SID in the SID list included in the CRH that is associated with the node, and may determine the next segment by using the SID to reference a segment translation table that maps the SID to the following: the global IP address of the next-hop node and the segment translation table that identifies the link-local IPv6 address of the next-hop node's interface. The global IP address or the link-local IPv6 address may be used as the destination IP address of the IP payload packet. In some implementations, when updating the destination IP address, a node may update the destination IP address with the node's global IP address or the link-local IPv6 address of the next-hop node based on whether the next segment is the final segment.

[0116] In some implementations, when updating the destination IP address, a node may update the destination IP address to the global IP address based on the next segment being the final segment of the route, where the destination IP address is updated to the global IP address rather than the link-local IPv6 address based on the next segment being the final segment of the route.

[0117] Although Figure 7 example blocks of process 700 are shown, in some implementations, process 700 may include additional blocks, fewer blocks, different blocks, or Figure 7Blocks depicted in [description] are arranged differently. Additionally or alternatively, two or more blocks in process 700 may be executed in parallel.

[0118] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure, or may be obtained from practice of the implementations.

[0119] As used herein, the term network traffic or content may include a set of payload packets. Payload packets may refer to communication structures for communicating information (e.g., protocol data units (PDUs), network payload packets, datagrams, segments, messages, blocks, cells, frames, sub - frames, time slots, symbols, any part of the foregoing, and / or other types of formatted or unformatted data units capable of being transmitted via a network). As used herein, Internet Protocol (IP) payload packets may refer to IPv4 payload packets, IPv6 payload packets, Ethernet payload packets, etc.

[0120] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, and / or a combination of hardware and software.

[0121] Some implementations are described herein in connection with thresholds. As used herein, depending on the context, meeting a threshold may refer to a value greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.

[0122] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods does not limit the implementations. Thus, the operations and behaviors of the systems and / or methods are described herein without reference to specific software code - it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0123] Even if specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of the various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of the various implementations includes each dependent claim in combination with every other claim in the claim set.

[0124] Elements, acts, or instructions used herein are not to be construed as critical or essential, unless explicitly described as such. Additionally, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Further, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more." In instances where there is only one item, the phrase "only one" or similar language is used. Additionally, as used herein, the terms "has," "have," "having," etc. are intended to be open-ended terms. Further, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on."

Claims

1. A method, comprising: The node receives an Internet Protocol (IP) payload packet encapsulated with an IPv6 transport header, wherein the IPv6 transport header includes the destination IP address of the node, wherein the IPv6 transport header has been extended with a Compressed Routing Header (CRH) of variable length, and wherein the CRH includes a list of Segment Identifiers (SIDs), the segment identifiers identifying a set of nodes that the IP payload packet will traverse when routed through the network, wherein the set of nodes includes the node, and wherein the node is configured with a segment translation table that includes one or more strictly routed segments or one or more loosely routed segments; The node determines that the IP payload packet is not malformed using the CRH; The node determines the next segment for the IP payload packet by referring to the segment translation table based on the IP payload packet not being malformed; The node updates the destination IP address to the specific destination IP address of the next-hop node based on determining the next segment; The node updates the remaining segment value included in the CRH, the remaining segment value identifying the number of segments remaining in the routing of the IP payload packet; and The node provides the IP payload packet to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

2. The method according to claim 1, wherein the SID list has the following variable lengths: Eight bits, Sixteen bits, Thirty-two bits, or Sixty-four bits.

3. The method according to claim 1, wherein the set of segments in the routing of the IP payload packet comprises at least one of the following items: A segment with a strict route among the one or more segments with a strict route, or A segment with a loose route among the one or more segments with a loose route.

4. The method according to claim 1, wherein the final segment in the routing of the IP payload packet is a segment with a strict route among the one or more segments with a strict route.

5. The method according to claim 1, further comprising: The node is configured with the segment translation table that associates two or more of the following: A set of SIDs corresponding to the list of SIDs, A set of global IP addresses, A set of link-local IPv6 addresses, or A set of interface mappings.

6. The method according to claim 1, wherein determining the next segment for the IP payload packet comprises: The SID associated with the node that identifies the list of SIDs included in the CRH, and Determining the next segment by using the SID to refer to the segment translation table that maps the SID to the following: The global IP address of the next-hop node, and The link-local IPv6 address that identifies the interface of the next-hop node, and wherein updating the destination IP address includes: Updating the destination IP address with the global IP address of the node or the link-local IPv6 address of the next-hop node based on whether the next segment is the final segment.

7. The method according to claim 1, wherein updating the destination IP address comprises: Updating the destination IP address to the global IP address based on the next segment being the final segment of the route.

8. A node, comprising: One or more memories; and One or more processors to: Receive an Internet Protocol (IP) payload packet encapsulated with an IPv6 transport header that has been extended with a Compressed Routing Header (CRH), wherein the CRH includes a list of Segment Identifiers (SIDs), the segment identifiers identifying a set of nodes that the IP payload packet will traverse when routed through the network, and wherein the list of SIDs has a variable length between 8 bits and 64 bits, and wherein the node is configured with a segment translation table, the segment translation table including one or more segments of strict routing or one or more segments of loose routing; determining, by the node and using the CRH, that the IP payload packet is not malformed; determining, based on the IP payload packet not being malformed, a next segment for the IP payload packet by referring to the segment translation table; updating the destination IP address to a specific destination IP address of the next-hop node; updating a remaining segment value included in the CRH, the remaining segment value identifying the number of segments remaining in the routing of the IP payload packet; and providing the IP payload packet to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

9. The node according to claim 8, wherein the set of segments in the routing of the IP payload packet comprises the segments of the one or more strict routes.

10. The node according to claim 8, wherein the final segment in the routing of the IP payload packet is the segment of the strict route among the segments of the one or more strict routes.

11. The node according to claim 8, wherein the one or more processors are further configured to: Before receiving the IP payload packet, configure the node by using the segment translation table, which associates two or more of the following items: A set of SIDs corresponding to the SID list, A set of global IP addresses, A set of link - local IPv6 addresses, or A set of interface mappings.

12. The node according to claim 8, wherein when determining the next segment for the IP payload packet, the one or more processors are configured to: Identify the SID associated with the node in the SID list included in the CRH, and Determine the next segment by using the SID to refer to the segment translation table that maps the SID to the following items: The global IP address of the next - hop node, and Identify the link-local IPv6 address of the interface of the next-hop node, and wherein, when updating the destination IP address, the one or more processors are configured to: Update the destination IP address based on whether the next segment is the final segment, using the global IP address of the node or the link-local IPv6 address of the next-hop node.

13. The node according to claim 8, wherein, when updating the destination IP address, the one or more processors are configured to: Based on the next segment being the final segment of the route, update the destination IP address to the specific destination IP address, wherein the specific destination IP address is a global IP address, and wherein the final segment is a segment of a strict route.

14. The node according to claim 8, wherein the one or more processors are further configured to: Before determining the next segment, determine whether the remaining segment value included in the CRH is a non-zero value, and Based on whether the remaining segment value is a non-zero value, determine whether to continue processing the CRH or another header of the header set.

15. A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by one or more processors of a node, cause the one or more processors to perform the following actions: receiving an Internet Protocol (IP) payload packet encapsulated using a header set including an IPv6 transport header, wherein the IPv6 transport header includes a destination IP address of the node, wherein the IPv6 transport header has been extended using a compressed routing header (CRH) including a list of segment identifiers (SID), the segment identifiers identifying a set of nodes that the IP payload packet will traverse when routed through the network; and wherein the SID list has a variable length: eight bits, sixteen bits, thirty-two bits, or sixty-four bits, and wherein the node is configured with a segment translation table, the segment translation table including one or more segments of strict routing or one or more segments of loose routing; determining, using the CRH, that the IP payload packet is not malformed; determining, based on the IP payload packet not being malformed, a next segment for the IP payload packet by referring to the segment translation table; updating the destination IP address to a specific destination IP address of the next-hop node; updating a remaining segment value included in the CRH, the remaining segment value identifying the number of segments remaining in the routing of the IP payload packet; and providing the IP payload packet to the next-hop node to allow the next-hop node to route the IP payload packet to another node or destination device in the network.

16. The non-transitory computer-readable medium according to claim 15, wherein the set of segments in the route of the IP payload packet includes at least one strict route segment of the one or more strict route segments.

17. The non-transitory computer-readable medium according to claim 15, wherein a final segment in the routing of the IP payload packet is a strict routing segment among the one or more strict routing segments.

18. The non-transitory computer-readable medium according to claim 15, wherein the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: Before receiving the IP payload packet, configure the node by using the segment conversion table, the segment conversion table associating two or more of the following items: A set of SIDs corresponding to the SID list, A set of global IP addresses, A set of link-local IPv6 addresses, or A set of interface mappings.

19. The non-transitory computer-readable medium according to claim 15, wherein the one or more instructions that cause the one or more processors to determine the next segment for the IP payload packet cause the one or more processors to: Identify the SID associated with the node in the SID list included in the CRH, and Determine the next segment by using the SID to refer to the segment conversion table that maps the SID to the following items: The global IP address of the next-hop node, and The link-local IPv6 address identifying the interface of the next-hop node, and wherein the one or more instructions that cause the one or more processors to update the destination IP address cause the one or more processors to: Update the destination IP address by using the global IP address of the node or the link-local IPv6 address of the next-hop node based on whether the next segment is a final segment.

20. The non-transitory computer-readable medium according to claim 15, wherein the one or more instructions that cause the one or more processors to update the destination IP address cause the one or more processors to: Update the destination IP address to a global IP address based on the next segment being the final segment of the routing.

Images