WO2024124260A2

WO2024124260A2 - Ipv6 domain level segment routing using srh

Info

Publication number: WO2024124260A2
Application number: PCT/US2024/021305
Authority: WO
Inventors: Haoyu Song; Alvaro Retana
Original assignee: Futurewei Technologies, Inc.
Priority date: 2024-03-25
Filing date: 2024-03-25
Publication date: 2024-06-13
Also published as: WO2024124260A3

Abstract

The disclosure provides a method and an apparatus thereof. The method is implemented by a network node in a domain-level segment routing (DLSR), including: receiving a first packet in an internet protocol (IP) version six (IPv6) format. The first packet is encapsulated to generate a second packet including an IPv6 header and a segment routing header (SRH). The SRH includes a segment list corresponding to a forwarding path, where the segment list comprises domain segment identifiers (DSIDs) that each comprise a domain ID identifying a domain. The IPv6 header comprises an IPv6 destination address being set to a value of a first DSID in the segment list. The second packet is forwarded to a second node based on the IPv6 destination address.

Description

IPv6 Domain Level Segment Routing using SRH

TECHNICAL FIELD

[0001] The present disclosure is generally related to network communications, and is specifically related to a domain-based segment routing mechanism that can function as layer 3.5 in the Open Systems Interconnection (OSI) model and that is compatible with Internet Protocol version 6 (IPv6) and Segment Routing version 6 (SRv6) architecture.

BACKGROUND

[0002] In traditional IP network routing, IP packets are forwarded based on a routing table built by routing protocols. The route taken by the IP packets is usually the shortest path calculated by the routing protocols. In segment routing, the source chooses a path and encodes it in the packet header as an ordered list of segments. The rest of the network executes the encoded instructions.

[0003] In an IPv6 data plane, an ordered list of segments is encoded in a routing extension header. In SRv6, a Segment Routing Header (SRH) is added to an original packet as an IPv6 extension header.

SUMMARY

[0004] The disclosed aspects/embodiments provide a mechanism of domain routing. Each domain, also known as an autonomous system (AS), is virtualized into a node with edge routers acting as virtual interfaces. In this way, quality of service (QoS) data can be saved for each node, which can allow different domains to work together to provide end to end QoS, network security, domain-level policy, and cross-domain traffic engineering for packet flows. For example, domain level segment routing (DLSR) can be used. In the context of internet protocol (IP) version six (IPv6), the DLSR may be considered as a special case of Segment Routing version 6 (SRv6), in which each domain is virtualized as a single node and encoded as a domain-level segment identifier (or simply, domain segment identifier) (DSID). Segment routing header (SRH) is used to support DLSR, and DSIDs may be mixed with any other types of SIDs in the SRH to enhance the flexibility and programmability of SRv6 networks. Furthermore, DLSR allows each domain to hide its intradomain routing/forwarding details and be managed and monitored as a whole. The disclosed embodiments are compatible with IPv6 and SRv6 architecture. [0005] A first aspect relates to a method implemented by a network node in a DLSR network domain, the method comprising: receiving a first packet in IPv6 format; encapsulating the first packet into a second packet that comprises an IPv6 header and a SRH, wherein the SRH comprises a segment list corresponding to a forwarding path, the segment list comprises DSIDs, that each comprise a domain identifier (ID) identifying a domain associated with a corresponding DSID, and the IPv6 header comprises an IPv6 destination address being set to a value of a first DSID in the segment list; and forwarding the second packet to a second node based on the IPv6 destination address.

[0006] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the SRH further comprises a plurality of node SIDs that each comprise a node ID identifying a node.

[0007] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the SRH further comprises a segments left field having a pointer to a next DSID in the segment list.

[0008] Optionally, in any of the preceding aspects, another implementation of the aspect provides that a length of a prefix is variable, and wherein each of the DSIDs share a common prefix indicating a type of segment identifiers in the segment list.

[0009] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the domain ID is a globally unique identifier of 32 bits and represents an AS number assigned to the domain.

[0010] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the domain ID is included in a DSID locator that is used as an anycast address of the domain.

[0011] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the SRH further comprises a routing type field set to indicate that domain level source routing is used for the second packet.

[0012] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the second packet further comprises a DLSR options type length value (TLV) containing QoS data for domains traversed by the packet.

[0013] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first packet is encapsulated in the second packet as a packet payload. [0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides that encapsulating the first packet to generate the second packet comprises: asserting the SRH into the first packet to generate the second packet; and modifying a first IPv6 destination of the first packet to the value of the first DSID in the segment list.

[0015] A second aspect relates to a method implemented by a network node in a DLSR network domain, the method comprising: receiving a packet in an IPv6 format, wherein the packet comprises an IPv6 destination address and an SRH, wherein the SRH comprises a segment list corresponding to a forwarding path and a segments left field, and wherein the segment list comprises DSIDs each including a domain ID identifying a domain; determining whether the IPv6 destination address matches an address of the network node; determining a next DSID from the DSIDs in the segment list when the IPv6 destination address matches the address of the network node; updating the IPv6 destination address to the next DSID in the segment list; and forwarding the packet with the updated IPv6 destination address toward a next domain based on the updated IPv6 destination address.

[0016] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the segments left field comprising a pointer to the next DSID, and wherein the method further comprises decrementing the pointer upon determining the next DSID.

[0017] Optionally, in any of the preceding aspects, another implementation of the aspect provides that each of the DSIDs comprises a domain ID identifying a domain associated with a corresponding DSID.

[0018] Optionally, in any of the preceding aspects, another implementation of the aspect provides that each of the DSIDs comprises a domain ID identifying a domain associated with a corresponding DSID.

[0019] Optionally, in any of the preceding aspects, another implementation of the aspect provides that a length of a prefix is variable, and wherein each of the DSIDs share a common prefix indicating a type of segment identifiers in the segment list.

[0020] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the domain ID is a globally unique identifier of 32 bits and represents an AS number assigned to the domain. [0021] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the domain ID is included in a DSID locator that is used as an anycast address of the domain.

[0022] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the SRH further comprises a routing type field set to indicate domain level source routing is used for the packet.

[0023] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the packet further comprises a DLSR options TLV containing QoS data for domains traversed by the packet.

[0024] A third aspect relates to an apparatus, comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the apparatus to perform the method of the first aspect.

[0025] A fourth aspect relates to an apparatus, comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the apparatus to perform the method of the second aspect.

[0026] A fifth aspect relates to a non-transitory computer readable medium comprising a computer program product for use by a network node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium such that when executed by one or more processors, cause the network node to execute the method of the first aspect.

[0027] A sixth aspect relates to a non-transitory computer readable medium comprising a computer program product for use by a network node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium such that when executed by one or more processors, cause the network node to execute the method of the second aspect.

[0028] A seventh aspect relates to a network device, comprising one or more means for performing the method of the first aspect.

[0029] An eighth aspect relates to a network device, comprising one or more means for performing the method of the second aspect. [0030] For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

[0031] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0033] FIG. 1 is a schematic diagram of an example domain-level segment identifier according to an embodiment of the disclosure.

[0034] FIG. 2A is a schematic diagram of an example packet configured to support domainlevel segment routing according to an embodiment of the disclosure.

[0035] FIG. 2B is a schematic diagram of an example packet configured to support domain-level segment routing according to an embodiment of the disclosure.

[0036] FIG. 2C is a schematic diagram of an example packet configured to support domain-level segment routing according to an embodiment of the disclosure.

[0037] FIG. 3 is a schematic diagram of an example IPv6 based network of different domains configured to support communications between a source and a destination according to an embodiment of the disclosure.

[0038] FIG. 4 is a schematic diagram of an example network element.

[0039] FIG. 5A is a flowchart of an example method of performing domain level segment routing at an edge node according to an embodiment of the disclosure.

[0040] FIG. 5B is a flowchart of an example method of performing domain level segment routing at an edge node according to an embodiment of the disclosure.

[0041] FIG. 6 is a flowchart of another example method of performing domain level source routing in the network according to an embodiment of the disclosure.

[0042] FIG. 7 is a flowchart of an example method of performing domain level segment routing at an edge node according to an embodiment of the disclosure. [0043] FIG. 8 is a schematic diagram of an example system for communicating data using domain-level segment routing.

DETAILED DESCRIPTION

[0044] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0045] The disclosed aspects/embodiments provide a mechanism of domain routing. Each domain, also known as an autonomous system (AS), is abstracted as a virtual router. The Domain Border Routers (DBR) are abstracted as the virtual router interface, and all the intra-domain routers of a domain form the switch fabric of the corresponding virtual router. A packet from its source to destination will be forwarded though a sequence of virtual routers. There can be multiple paths available. Each virtual router’s performance is individually monitored and measured. In this way, quality of service (QoS) data can be saved for each node, which can allow different domains to work together to provide end to end QoS for packet flows. For example, domain level segment routing (DLSR) can be used. DLSR can also be referred as domain level source routing in some contexts. In the context of internet protocol (IP) version six (IPv6), the DLSR may be considered as a special case of SRv6, in which each domain is virtualized as a single node and encoded as a domain segment identifier (DSID). Segment routing header (SRH) is used to support DLSR, and DSIDs may be mixed with any other types of segment identifiers (e.g., node-level SIDs) in an SRH. In general, each AS may be managed by a different entity. The details of the internal connectivity in the domain may represent proprietary information for the domain. Also, if the forwarding is considered per-domain, then there is no need to know extra information. In this manner, DLSR allows each domain to hide its intra-domain routing/forwarding details and be managed and monitored as a whole. It serves as a security mechanism and a scalability and simplification mechanism because others are not forced to deal with additional information. The disclosed embodiments are compatible with IPv6 and SRv6 architecture, easy to deploy, and enable new use cases. [0046] In one embodiment, an edge node determines a Segment Routing (SR) policy (e.g., list of segments or a segment list) that includes segments that represent IP addresses (e.g., IPv6 addresses) to apply to packets for a packet flow. These policies can change in response to network conditions, network programming, etc. In one embodiment, the SR policy specifies to add an SRH with a segment list containing multiple segments or SIDs. An SR ingress node uses encapsulation to add the SRH into packets. The SR ingress node first receives a first packet in an IPv6 format, wherein the first packet comprises an IPv6 header including a destination address. The SR ingress node encapsulates the first packet into a second packet which comprises a new IPv6 header and the SRH. Thus, the packet comprises three headers i.e. an original IPv6 header, an SRH, and a new IPv6 header. The original destination address of the packet is left unmodified in the network. The new destination address of the new IPv6 header is set to a first segment of the segment list and the packet is forwarded to a next node following the shortest path. The next node then processes the packet by updating the new destination address to the next segment of the segment list when the new destination address matches an address of the node itself. The last segment of the list is an SR egress node. It decapsulates the packet by removing the SRH header and the new IPv6 header, and forwards it to its original destination.

[0047] In the disclosed embodiments, the SRH includes the segment list comprising one or more

DSIDs and other types of node-level SIDs in an arbitrary order. Each of the DSID comprises a 32- bit domain identifier (ID) that uniquely identifies a domain the packet should traverse along a path from the source to the destination. In one embodiment, the domain ID can be set the same as the AS number. Each DSID may be considered as an anycast address and advertised by all the domain border routers (DBRs) of a domain in routing protocols such as border gateway protocol (BGP). In this manner, each DSID can be used as an IPv6 destination address to reach a domain through any nearest border router of that domain. Using DSIDs in the segment list abstain address translation when processing the SRH and routing protocol update. Further, the SRH may include a DLSR options type length value (TLV), as well as the functions and parameters carried in the DSID.

[0048] FIG. 1 is a schematic diagram of an example DSID. In an SRv6 network, a packet processing process may be divided into several segments. In the disclosed embodiments, DLSR may be considered as a special case of SRv6, in which each domain is virtualized as a single node and encoded as a DSID. SRH is used to support DLSR, and DSIDs can be mixed with any other types of node-level SIDs in the SRH. In one embodiment, the segment list of the SRH includes one or more DSIDs and/or node-level SIDs in an arbitrary order. In one embodiment, the segment list of the SRH includes only DSIDs. As shown in FIG. 1, a DSID has a value of 128 bits. In an embodiment, each DSID may include a DSID locator (LOC) 102 and functions (and optionally, any argument) 104. The DSID locator 102 indicates which node in the multiple domain network a packet is to be routed to in order to perform the function 104. The DSID locator 102 may further include two parts: a prefix 106 and a domain ID 108. The prefix 106 may be globally allocated by a network operator to indicate that the SID type is of domain. All DSIDs in the domain have a common prefix. It may be considered that all the DSIDs in the domain form an DSID block. Therefore, the prefix may also be referred to as a DSID block (B). The length of the prefix is variable. The domain ID 108 is used to distinguish between nodes in the domain. DSIDs of different nodes in the domain have different domain IDs. Therefore, the domain ID 108 may also be referred to as a DSID node (N). The domain ID 108 has a value of 32 bits. Thus, in a same domain, all DSIDs have a common prefix 106, and domain ID 108 of all the DSIDs have a same length (i.e. 32 bites). In an embodiment, it may prefer to use the AS number assigned for the domain as the domain ID 108. The DSID may be considered as an anycast address for which the DSID locator 102 is advertised by all DBRs of a domain in routing protocols such as BGP. In this manner, DSID may be used as an IPv6 destination address to reach a domain through any nearest border router of that domain. The functions may be any possible functions having any optional argument.

[0049] FIG. 2A is a schematic diagram of an example packet 200A configured to support domain level segment routing. As shown in FIG. 2A, the packet 200A includes an IPv6 header 202 and a packet payload 204 for transporting data and/or information related to upper layer protocols. The SR ingress node first receives a first packet in an IPv6 format, wherein the first packet comprises the IPv6 header 202. The IPv6 header 202 includes fields used for IPv6 routing. Such fields may include a version field 206 set to indicate the packet is an IPv6 packet, a traffic class field 208 comprising packet priority information, a flow label field 210 comprising a flow label to indicate an association between the packet and a flow, a payload length field 212 set to indicate the number of bits in the payload, a next header (NH) field 214 that identifies the type of header following the IPv6 header, a hop limit field 216 indicating a number of hops a packet can traverse before being considered stale, and a source address (SA) field 218 indicating the IP address of the packet source etc. The IPv6 header 202 also contains a destination address (DA) 220, which contains the destination address of the packet. The destination address 218 is a 128-bit address in IPv6 format. The destination address 220 indicates the address of the destination for the packet.

[0050] FIG. 2B is a schematic diagram of an example packet 200B configured to support domain level segment routing. The SRH format for DLSR is identical to the standard format of SRH as described in more detail in the Internet Engineering Task Force (IETF) document Request for Comments (RFC) 8754 entitled “IPv6 Segment Routing Header (SRH)” by C. Filsfils, et al., published March, 2020. As shown in FIG. 2A, the packet 200B includes an IPv6 header 202, an SRH 222, an IPv6 header 224, and a packet payload 204 for transporting data and/or information related to upper layer protocols. The NH field in the IPv6 header 224 is set to value of 43 indicating that the next header is an SRH. All other fields depicted in the IPv6 header 202 of FIG. 2B are similar to the fields depicted in the IPv6 header 202 of FIG. 2A. For the sake of brevity, a detailed description of these fields is not repeated herein.

[0051] In an embodiment, an extension header may be placed after the IPv6 header 202 in a packet. As shown in FIG. 2B, the next header is the SRH 222. The SRH 222 includes various fields to support domain level segment routing. The first eight octets of the SRH 222 include a next header (NH) field 226, a length field 228, a routing type (RT) field 230, a segments left (SL) field 232, last entry field 234, reserved bits 236 which are reserved for other purposes, and a DLSR options TLV 238. The next header field 226 indicates the next extension header following the current header, in this case an upper layer header used by upper layer protocols followed by the packet payload 204. It should be noted that other extension headers may be included after the SRH 222, in which case the next header field 226 indicates the type of the next header. The length field 228 indicates the length of the SRH 222. The routing type 230 contains data indicating the type of routing used for the packet. In the present example, the routing type 230 is set to a value indicating DLSR routing is employed for the current packet. The SL field 232 is used to identify a number of remaining segments in the segment list before reaching the final destination. The last entry field 234 contains an index of the last element in a segment list. In an embodiment, the SRH 222 further comprises a segment identifier (SID) list comprising a segment list 240 comprising plurality of DSIDs and other types of node-level SIDs in arbitrary number and order. Each segment is identifiable by the value of the segments left field 232 as an index and has a size of 128 bits. In an embodiment, the segment list includes one or more DSIDs and/or one or more other SIDs. In another embodiment, the segment list can include only the DSIDs. The format of the DSID is described and shown in FIG. 1. The segment list is encoded starting from the last segment of the SR Policy. That is, the first element of the segment list (segment list [0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SR Policy, and so on. Furthermore, the SRH format for DLSR is identical to the standard format of SRH as described in more detail in the IETF document RFC 8754 entitled “IPv6 Segment Routing Header (SRH)” by C. Filsfils, et al., published March, 2020.

[0052] In an embodiment, on the SRv6 network, the SRH 222 including the segment list 240 may be encapsulated into a packet by a head node (a.k.a. an ingress node) on a forwarding path, and subsequent nodes on a packet forwarding path may process the packet based on the SID list. For example, the received IPv6 packet with an IPv6 header 202 and a packet payload 204 is encapsulated in a packet including an IPv6 header 224 with the SRH 222. The IPv6 header 224 includes a source address field 242 and a destination address field 244. The head node on the forwarding path may set a value of the destination address field 244 to a DSID corresponding to a first executed segment in the segment list. The NH field in the IPv6 header 224 may be set as value of 43 indicating that the next header is an SRH. Most of other fields depicted in the IPv6 header 224 are similar to the fields depicted in the IPv6 header 202. For the sake of brevity, a detailed description of these fields is not repeated herein. In addition, the head node may further set a value of the segments left (SL) field 232 to N-l, where N is a quantity of DSIDs included in the SID list. That is, the segment [SL] is the first DSID in the SID list, and corresponds to the first executed segment. The segments left field 232 is used to identify a number of remaining segments in the segment list before reaching the final destination. Furthermore, the SRH 222 may further include a DLSR options TLV 238. The DLSR options TLV 238 may contain any QoS data related to the one or more domains traversed by the packet and/or any QoS requirements related to the packet. The DLSR options TLV 238 is optional. In an embodiment, once an encapsulated SRv6 packet reaches the egress node and a value in the SL field 232 is equal to zero, the egress node decapsulates the packet (i.e. removes the SRH 222 and the new IPv6 header 224 from the packet) and forwards the packet towards a destination node.

[0053] FIG. 2C is a schematic diagram of an example packet 200C configured to support domain level segment routing. In an embodiment, one or more extension headers may be placed between an IPv6 header and a packet payload in a packet. As shown in FIG. 2C, the extension header is the SRH 222. As shown in FIG. 2C, the packet 200C includes an IPv6 header 252, an SRH 222, and a packet payload 204 for transporting data and/or information related to upper layer protocols. After receiving the first packet (e.g. IPv6 packet shown in FIG. 2A) including the IPv6 header 202 and the packet payload 204, the SR ingress node encapsulates the first packet to generate or form a second packet (e.g. SRv6 packet shown in FIG. 2C) which includes the IPv6 header 252, the SRH 222 and the packet payload 204. The encapsulation may include inserting the SRH 222 between the IPv6 header 202 and the packet payload 204 of the packet shown in FIG. A and modifying or replacing values of one or more fields in the IPv6 header 202 to form the IPv6 header 252. The SRH 222 includes various fields to support domain level segment routing. All the fields of the SRH 222 depicted in FIG. 2C are similar to the fields of the SRH 222 depicted in the FIG. 2B. For the sake of brevity, a detailed description of these fields is not repeated herein. In an embodiment, the destination address field 220 of the IPv6 header 252 is set to a first segment of the segment list (e.g., first segment is the first DSID in the segment list), and the NH field in the IPv6 header 224 may be set as value of 43 indicating that the next header is an SRH. The packet 200C is forwarded to a next node following the shortest path. The next node then processes the packet by updating the destination address to the next segment of the segment list when the destination address matches an address of the node itself. The last segment of the list is an SR egress node. In an embodiment, once an encapsulated SRv6 packet reaches the SR egress node and a value in the segments left field 232 is equal to zero, the SR egress node decapsulates the packet by removing the SRH and forwards it to a destination node. [0054] FIG. 3 is a schematic diagram of an example IPv6 based network 300 of different domains configured to support communications between a source node 311 and a destination node 315. The network 300 comprises a plurality of autonomous systems 310 configured to communicate via IP protocols. Each of the autonomous systems 310 is a group of interconnected network devices that form a domain. Hence, the term domain and autonomous system 310 can generally be used interchangeably herein. A domain is a realm of administrative autonomy, authority, or control within the internet. Accordingly, each autonomous system 310 is generally controlled by a different entity. For security reasons, autonomous systems 310 generally do not share detailed information related to internal structure and operation. Each autonomous system 310 comprises edge nodes (a.k.a DBRs) 313 and internal nodes (not shown). The internal nodes are configured to communicate data between the edge nodes 313. The edge nodes 313 serve as entry and exit points into the autonomous system 310 and the corresponding domain. The edge nodes 313 are configured to communicate flows of packets from a current autonomous system 310 to any other autonomous system 310 to which the edge node 313 is connected. The edge nodes 313 are further configured to provide security and other services to maintain the proper functionality of the corresponding autonomous system 310. Autonomous systems 310 that are connected can be referred to as adjacent. From the standpoint of a particular communication an autonomous system 310 in the direction of a source node 311 is in an upstream direction, while an autonomous system 310 in the direction of a destination node 315 is in a downstream direction.

[0055] The various nodes in the network 300 are connected by links 317. The inter-domain links are depicted as solid lines. The intra-domain links are depicted as dashed lines, and have been simplified by removing the connecting internal nodes for visual clarity. A link 317 is any connection between two points capable of communicating data, such as optical, electrical, electro-optical, and/or or wireless connections. A source (src) node 311 is any device configured to transmit packets of data in an IPv6 format and a destination (dst) node 315 is any device configured to receive packets from a source. For example, the source node 311 and the destination node 315 can be contained inside separate autonomous systems 310, as shown, when both devices are servers in data centers. In other examples, the source node 311 and/or the destination node 315 may be user devices contained outside a corresponding autonomous system 310.

[0056] To perform domain level segment routing, each autonomous system/domain 310 can be abstracted into a virtual router. Further, each DBR or edge node 113 can be abstracted into an interface into the corresponding virtual router. Such abstraction allows packets to be routed through particular domains via corresponding interfaces. Further, such abstraction allows the corresponding QoS information to be communicated in a manner that is abstract enough to hide security information while providing useful information for routing purposes.

[0057] DLSR routing is an example routing mechanism that can be used to implement domain level routing. In the context of IPv6, the DLSR may be considered as a special case of SRv6, in which each domain is virtualized as a single node and encoded as a DSID. SRH is used to support DLSR, and DSIDs may be mixed with any other types of SIDs in an SRH. In this manner, DLSR allows each domain to hide its intra-domain routing/forwarding details and be managed and monitored as a whole. The disclosed embodiments are compatible with IPv6 and SRv6 architecture. On the SRv6 network, an IPv6 packet includes an IPv6 header, an SRH and a packet payload. The IPv6 packet with the SRH is referred to as SRv6. The IPv6 header includes a destination address and other IPv6 related fields. The format of IPv6 packet is described in FIG. 2A, and the format of SRv6 packet is described in FIG. 2B or FIG. 2C. The SRH includes a segment list having one or more DSIDs and other types of node-level SIDs in an arbitrary order. The format of a DSID is described in FIG. 1.

[0058] DLSR Forwarding Examples

[0059] In an embodiment, an SRH may specify a pure domain-level forwarding path either as a strict source routing or as a loose source routing. The domain-level forwarding path avoids new behaviors on domain border routers, enables several new use cases, and brings unique advantages. In an embodiment, SR policies with mixed DSID and other types of SIDs enhance the flexibility and programmability of SRv6 networks.

[0060] Strict pure DLSR example

[0061] A DLSR path is said to be strict routed when a segment representing each of the domain of the path is present in the segment list of the SRH header. Strict encoding of an DLSR path generates a list of domain-level segments to encode the path in the packet. In one embodiment, the source domain AS0 receives a packet in an IPv6 format, where the packet includes an IPv6 header with a destination address. The source domain AS0 encapsulates the received IPv6 packet to generate a new packet. The new packet may include the received IPv6 packet and additional headers, where the additional headers may include a new IPv6 header and an SRH. The new IPv6 header includes a new IPv6 destination address. To describe the forwarding process for the strict pure DLSR, FIG. 3 is used as an example. Assume the domain-level path length is N (including the source domain AS0 and the destination domain AS5 as shown in FIG. 3), set segments left field 232 as N-l, and last entry field 234 as N.

[0062] Assume that the source node 311 in AS0 may send the IPv6 packet to the destination node 315 in AS5 and it acquires a strict DLSR path AS0— >AS1— >AS2— >AS5 for the packet. The IPv6 packet at source node 311 formatted as (src, AS1) (dst, AS5, AS2, AS1; SL=3) represents that source address of the new IPv6 header is set as src, a new destination address of the new IPv6 header is set as a first DSID (i.e., AS1) in the segment list, and SRH as the next header. The SRH is added to the packet with segment list having DSIDs encoded as (dst, AS5, AS2, AS1; SL=3), wherein the rightmost DSID AS1 is the first DSID and the leftmost DSID AS5 is the last DSID. Only the ingress DBRs and egress DBRs of a domain process the SRH. The other interior routers simply forward packets based on the original destination address in the IPv6 header. In one embodiment, a value of the original destination address is not changed along the path between the source of the packet and the destination of the packet. The original destination address remains the same. [0063] After encapsulating the new IPv6 header with SRH to the packet, the edge node 313 forwards the encapsulated packet to DBR a of AS 1 310. In an embodiment, on the forwarding path, the domain ingress DBRs with the matched DSIDs in the destination address will process the SRH. In this manner, DBR a determines whether the content of destination address (DA) of the received IPv6 header matches an address of the DBR a to process the SRH. In response to determining that the destination address matches the node’s address, the DBR a updates the destination address in the IP header based on a next DSID in the segment list. The segments left field that includes a pointer to the next DSID, decrements the pointer upon determining the next domain ID. Thus, the packet at DBR a is updated to (src, AS2) (dst, AS5, AS2, AS1, ASO; SL=2). Then, the DBR a forwards the encapsulated packet (which includes an updated IP header) to the next node (e.g., the domain border node d) in the multiple domain network 300 in accordance with the updated DA.

[0064] The DBR d receives the encapsulated packet and updates the new destination address in the new IPv6 header based on a next DSID in the segment list. The segments left field that includes a pointer to the next DSID, decrements the pointer upon determining the next DSID. Thus, packet at DBR d is updated to (src, AS5) (dst, AS5, AS2, AS1; SL=1). Then, the DBR d forwards the encapsulated packet (which includes an updated IP header) to the next node (e.g., the domain border node y) in accordance with the updated DA.

[0065] The DBR y receives the encapsulated packet. The DBR y is aware that the destination 115 is in its own domain. For example, edge node y checks the pointer into the segment list and determine the pointer has reached a final value (e.g., has been decremented to zero and/or has reached the end of the list). Upon determining the packet is in the destination domain, the edge node y copies the destination address back into the original destination address field. Thus, packet at DBR d is updated to (src, dst) (dst, AS5, AS2, AS1 ; SL=0). Thus, once the encapsulated SRv6 packet reaches the destination/egress domain AS5, the destination node decapsulates the packet and forwards the packet towards a destination node dst in AS5. In an embodiment, when the penultimate hop popping (PHP) behavior is preferred, node 'y' can remove the SRH before forwarding the packet to dst.

[0066] Loose pure DLSR example

[0067] A DLSR path is said to be loosely routed when the SRH contains a number of segments that are fewer than the nodes/domains over the path. Loosely encoding of an DLSR path generates partial domain segments to encode the path in the packet. In one embodiment, the source domain ASO receives a packet in an IPv6 format, where the packet includes an IPv6 header with an original destination address. The source domain ASO encapsulates the received IPv6 packet to form a new packet including a new IPv6 header and the SRH, where the new IPv6 header includes a new IPv6 destination address. To describe the forwarding process for the loose pure DLSR, FIG. 3 is used as an example. Assume the domain-level path length is N (including the source domain ASO and the destination domain AS5 as shown in FIG. 3), set segments left field 232 as N-l, and last entry field 234 as N.

[0068] Assume that the source node 311 in ASO may send an IPv6 packet to the destination node 315 in AS5 and it acquires a loose DLSR path AS3^AS4 for the packet. The IPv6 packet at source node 311 formatted as (src, AS3) (dst, AS4, AS3; SL=2) represents that source address of the IPv6 header is set as src, a destination address of the IPv6 header is set as a first DSID in the segment list, and SRH as the next header. The SRH is added to the packet including segment list with DSIDs encoded as (dst, AS4, AS3; SL=2).

[0069] After encapsulating the new IPv6 header and the SRH to the packet, the edge node 313 forwards the encapsulated packet to DBR f of AS3. In an embodiment, on the forwarding path, the domain ingress DBRs with the matched DSIDs in the destination address will process the SRH. In this manner, DBR f determines whether the content of destination address of the received IPv6 header matches an address of the DBR f to process the SRH. In response to determining that the destination address matches the node’s address, the DBR f updates the destination address in the IP header based on a next DSID in the segment list. The segments left field that comprises a pointer to the next DSID, decrements the pointer upon determining the next domain DSID. Thus, packet at DBR f is updated to (src, AS4) (dst, AS4, AS3; SL=1). Then, the DBR f forwards the encapsulated packet (which includes an updated IP header) to the next node (e.g., the domain border node h) in the multiple domain network 300 in accordance with the updated DA.

[0070] The DBR h receives the encapsulated packet. The DBR h checks the pointer into the segment list and determines the pointer has reached a final value (e.g., has been decremented to zero and/or has reached the end of the list). Upon checking the packet, the edge node h copies the destination address into the IPv6 destination address field. Thus, packet at DBR h is updated to (src, dst) (dst, AS4, As3; SL=0). Thus, once the encapsulated SRv6 packet reaches the destination/egress domain AS5, the destination node decapsulates the encapsulated SRv6 packet and forwards the decapsulated packet towards a destination node in AS5. In an embodiment, when the PHP behavior is preferred, node 'h' can remove the SRH before forwarding the packet to dst. [0071] General DLSR Example

[0072] A DLSR path is said to be general routed when the SRH contains a mixed number of domain-level segments and node-level segments over the path to enhance the flexibility and programmability of SRv6 networks. In one embodiment, the source domain ASO receives a packet in an IPv6 format, where the packet includes an IPv6 header having an original IPv6 destination address. The source domain ASO encapsulates the received IPv6 packet in a packet (e.g. a packet shown in FIG. 2B which can be referred to as SRv6 packet) including a new IPv6 header and the SRH, where the IPv6 header includes a new IPv6 destination address different from the original IPv6 destination. To describe the forwarding process for the general DLSR, FIG. 3 is used as an example. Assume the domain-level path length is N (including the source domain ASO and the destination domain AS5 as shown in FIG. 3), set segments left field 232 as N-l, and last entry field 234 as N. [0073] Assume that the source node 311 in ASO may send an IPv6 packet to the destination node 315 in AS5 and it acquires a DLSR path AS3— >e for the packet. The IPv6 packet at source node 311 formatted as (src, AS3) (dst, e, AS3; SL=2) represents that source address of the new IPv6 header is set as src, a destination address of the new IPv6 header is set as a first DSID in the segment list, and SRH as the next header. The SRH is added to the packet with segment list having DSIDs encoded as (dst, AS3, e; SL=2).

[0074] After encapsulating the new IPv6 header with the SRH to the packet, the edge node 313 forwards the encapsulated packet to DBR e of AS3. In an embodiment, on the forwarding path, the domain ingress DBRs with the matched DSIDs in the destination address will process the SRH. In this manner, DBR f determines whether the content of the destination address of the received IPv6 header matches an address of the DBR e to process the SRH. In response to determining that the destination address matches the node’s address, the DBR e updates the destination address in the new IPv6 header based on a next DSID in the segment list. The SL field that comprises a pointer to the next DSID, decrements the pointer upon determining the next domain ID. Thus, packet at DBR ‘f is updated to (src, e) (dst, e, AS3; SL=1). Then, the DBR e forwards the encapsulated packet (which includes an updated IP header) to the next node (e.g., the domain border node e) in the multiple domain network 300 in accordance with the updated DA.

[0075] The DBR e receives the encapsulated packet. The DBR e checks the pointer into the segment list and determines the pointer has reached a final value (e.g., has been decremented to zero and/or has reached the end of the list). Upon checking the packet, the edge node e copies the destination address into the IPv6 destination address field. Thus, packet at DBR e is updated to (src, dst) (dst, e, AS3; SL=0). Finally, the packet is forwarded to dst in AS5. In an embodiment, when the PHP behavior is preferred, node e can remove the SRH before forwarding the packet to dst.

[0076] In an embodiment, since a DSID represents a domain, there may be few rules to be obeyed when specifying a domain-level forwarding path. For example, some rules are: 1) The original source and the final destination of a packet may be a physical node. The final destination of the packet is the last SID in the segment list, 2) The next segment endpoint of a domain-level segment endpoint may be located outside of the domain, because the domain is considered as a single node, 3) The last segment endpoint (i.e., the final destination) can be within a domain-level segment endpoint. This is usually used for strict DLSR where the complete domain-level path is specified, and 4) The source node can be within a domain-level segment endpoint (i.e., the first domain on the path).

[0077] DLSR SRH compression

[0078] As DLSR SIDs share the common prefix, and each has a 32-bit domain ID, both NEXT- C-SID flavor and REPLACE-C-SID flavor, as described in more detail in the IETF document entitled “Compressed SRv6 Segment List Encoding” by W. Cheng, et al., published October, 2023, can be supported to reduce the SRH overhead.

[0079] Use Cases

[0080] The disclosed embodiments support domain level source routing and forwarding in IPv6 networks by introducing the domain level segment and using it in SRH. The DLSR provides various use cases. In one case, using a domain-level segment is more compact than using two node-level segments, and support multihoming without exposing the domain topology and configuration. In another case, using a domain-level path, some domains can avoid or include domains for any security and privacy reasons. Traffic can also guide to certain domains for special treatments such as security screening and lawful interception. In another case, with a domain-level path, the peering and routing preferences at data plane can be expressed. As domain-level routing policies are easy to be specified, certain traffic can be pinned to a specific domain where one of the anycast destinations is located. In another case, multiple domain-level paths with the same or different service levels can be provisioned. Path choosing or load balancing can be applied on these paths to achieve the ideal performance. In another case, domain level source routing further allows service providers to collaborate on providing distributed network services. In another case, DLSR provides a way to support path validation at the domain level. The path information is kept in the SRH and can be verified at each segment endpoint. Various verification algorithms and protocols can be used (e.g., In-band OAM (10 AM) Proof of Transit (POT). In another case, when the SR domain covers multiple ASes, DLSR can be used to effectively reduce the packet overhead and protect the privacy. In this case, the packet is forwarded at the domain level. Each DSID is configured as a binding SID (BSID), so at each domain border, a local SR policy is applied to tunnel through the domain.

[0081] FIG. 4 is a schematic diagram of an example network element 400. The network element 400 is suitable for implementing the disclosed examples/embodiments as described herein. The network element 400 comprises downstream ports 420, upstream ports 450, and/or transceiver units (Tx/Rx) 410, including transmitters and/or receivers for communicating data upstream and/or downstream over a network. The network element 400 also includes a processor 430 including a logic unit and/or central processing unit (CPU) to process the data and a memory 432 for storing the data. The network element 400 may also comprise electrical, optical-to-electrical (OE) components, electrical-to-optical (EO) components, and/or wireless communication components coupled to the upstream ports 450 and/or downstream ports 420 for communication of data via electrical, optical, or wireless communication networks. The network element 400 may also include input and/or output (VO) devices for communicating data to and from a user. The VO devices may include output devices such as a display for displaying image and/or video data. The VO devices may also include input devices, such as a keyboard, mouse, trackball, etc., and/or corresponding interfaces for interacting with such output devices.

[0082] The processor 430 is implemented by hardware and software. The processor 430 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 430 is in communication with the downstream ports 420, Tx/Rx 410, upstream ports 450, and memory 432. The processor 430 comprises a DLSR module 414. The DLSR module 414 implements the disclosed embodiments described herein. For example, the DLSR module 414 may route a packet 200 according to DLSR routing. As such, the DLSR module 414 improves the functionality of the network element 400 as well as addresses problems that are specific to the image coding arts. Further, the DLSR module 414 affects a transformation of the network element 400 to a different state. Alternatively, the DLSR module 414 can be implemented as instructions stored in the memory 432 and executed by the processor 430 (e.g., as a computer program product stored on a non-transitory medium).

[0083] The memory 432 comprises one or more memory types such as disks, tape drives, solid- state drives, read only memory (ROM), random access memory (RAM), flash memory, ternary content-addressable memory (TCAM), static random-access memory (SRAM), etc. The memory 432 may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution.

[0084] FIG. 5A is a flowchart of an example method 500A of performing domain routing. For example, the method 500A can be performed in a source (node), a source edge node (a.k.a. headend node or an ingress node) in a source domain, and/or an edge node in a domain along a path as described with respect to network 300. The method 500 A can be applied to a packet such as packet 200B. The method can be implemented in a network element 400. The method 500A is performed by a network node positioned in a domain-level segment routing network domain.

[0085] At step 501, the network node receives a first packet in an IPv6 format, where the first packet includes a first IPv6 header having an original destination address. In an embodiment, a value of the original destination address is not changed along a path between a source (node) of the packet and a destination (node) of the packet.

[0086] At step 503, the network node encapsulates the first packet to generate or output a second packet that includes a second IPv6 header and an SRH and the first IPv6 header. In this embodiment, the second IPv6 header is an outer IPv6 header of the second packet and the first IPv6 header is an inner IPv6 header of the second packet. The SRH includes a segment list corresponding to a forwarding path, where the segment list includes DSIDs that each have a domain ID identifying a domain associated with a corresponding DSID. The second IPv6 header includes a second IPv6 destination address being set to a value of a first DSID in the segment list. In an embodiment, the SRH may further include a mix of DSIDs and a plurality of node SIDs to enhance the flexibility and programmability of SRv6 networks. Each of the node SIDs includes a node ID identifying a node associated with a corresponding node SID. In an embodiment, a length of each of the DSIDs is 128 bits, where each of the DSIDs includes a DSID locator and a function, and the DSID locator may include a prefix and the domain ID. The length of the prefix is variable, where each of the DSIDs share a common prefix indicating a type of segment identifiers in the segment list. In an embodiment, the domain ID is a globally unique identifier of 32 bits, which represents an AS number assigned to each domain.

[0087] At step 505, the network node forwards the second packet to a second node based on the second IPv6 destination address.

[0088] FIG. 5B is a flowchart of an example method 500B of performing domain routing. For example, the method 500B can be performed in a source (node), a source edge node (a.k.a. headend node or an ingress node) in a source domain, and/or an edge node in a domain along a path as described with respect to network 300. The method 500B can be applied to a packet such as packet 200C. The method can be implemented in a network element 400. The method 500B is performed by a network node positioned in a domain-level segment routing network domain.

[0089] At step 502, the network node receives a first packet in an IPv6 format, where the first packet includes an IPv6 header containing a first IPv6 destination address (e.g. original IPv6 destination address) in a destination address field.

[0090] At step 504, the network node encapsulates the first packet to generate or output a second packet that includes the IPv6 header and an SRH, where the SRH includes a segment list corresponding to a forwarding path, the segment list includes DSIDs that each contain a domain ID identifying a domain associated with a corresponding DSID, and the IPv6 header in the second packet includes a second IPv6 address being set to a value of a first DSID in the segment list. In another word, the first IPv6 address in the destination address field has been replaced by the second IPv6 address. In an embodiment, the SRH may further include a mix of DSIDs and a plurality of node SIDs to enhance the flexibility and programmability of SRv6 networks. Each of the node SIDs includes a node ID identifying a node associated with a corresponding node SID. In an embodiment, a length of each of the DSIDs is 128 bits, each of the DSIDs includes a DSID locator and a function, the DSID locator includes a prefix and the domain ID. The length of the prefix is variable, and each of the DSIDs share a common prefix indicating a type of segment identifiers in the segment list. In an embodiment, the domain ID is a globally unique identifier of 32 bits and represents an AS number assigned to each domain.

[0091] At step 506, the network node forwards the second packet to a second node based on the second IPv6 destination address.

[0092] FIG. 6 is a flowchart of an example method 600 of performing domain routing. For example, the method 600 can be performed by a segment end node (a.k.a. domain border router) along a path as described with respect to network 300. The method 600 can be applied to a packet such as packet 200B or 200C. The method can be implemented in a network element 400. The method 600 is performed by a network node positioned in a current network domain.

[0093] At step 601, the network node receives a first packet in an IPv6 format, where the first packet includes an IPv6 header with a first IPv6 destination address and an SRH, where the SRH includes a segment list corresponding to a forwarding path and a segments left field, and the segment list includes DSIDs. In an embodiment, the SRH may further comprise a mix of DSIDs and a plurality of node SIDs to enhance the flexibility and programmability of SRv6 networks. Each of the node SIDs comprises a node ID identifying a node associated with a corresponding node SID.

[0094] At step 603, the network node determines whether the first IPv6 destination address matches an address of the segment end node.

[0095] At step 605, the network node determines a next DSID from the DSIDs in the segment list when the first IPv6 destination address matches the address of the segment end node.

[0096] At step 607, the network node updates the first IPv6 destination address to the next DSID in the segment list, to output a second packet.

[0097] At step 609, the network node forwards the second packet toward a next domain based on the updated IPv6 destination address.

[0098] FIG. 7 is a flowchart of an example method 700 of performing domain routing. For example, the method 700 can be performed by a segment end node (a.k.a. domain border router) along a path as described with respect to network 300. The method 700 can be applied to a packet such as packet 200B. The method can be implemented in a network element 400. The method 700 is performed by a network node positioned in a current network domain.

[0099] At step 701, the network node receives a packet in an IPv6 format, where the packet includes an IPv6 header and an SRH. The IPv6 header includes an IPv6 destination address. The SRH comprises a segments list corresponding to a forwarding path and a segments left field, and the segment list includes DSIDs. In an embodiment, the SRH may further comprise a mix of DSIDs and a plurality of node SIDs to enhance the flexibility and programmability of SRv6 networks. Each of the node SIDs comprises a node ID identifying a node associated with a corresponding node SID. [0100] At step 703, the network node determines whether the IPv6 destination address matches an address of the network node.

[0101] At step 705, the network node determines whether a value in the segments left field is equal to zero and the network node is the segment end node.

[0102] At step 707, the network node decapsulates the first packet by removing the IPv6 header and the SRH to obtain a second packet.

[0103] At step 709, the network node forwards the second packet toward an original destination address.

[0104] FIG. 8 is a schematic diagram of an example system 800 for communicating data using domain routing. The system 800 may employ a source domain device 810, which may be implemented by a source node 311, an edge node 313, a network element 400, or combinations thereof. The system 800 may also comprise a destination domain device 820, which may be implemented by an edge node 313, a network element 400, or combinations thereof. The source domain device 810 includes a receiving module 801 for receiving a packet 200A or 200B, a processing module 803 for processing the packet 200A or 200B, and a transmitting module 805 for forwarding the packet. The destination domain device 820 may be further configured to perform any of the steps of method 500A or 500B. In a similar manner, the destination domain device 820 includes a receiving module 821, a processing module 823, and a transmitting module 825. The destination domain device 820 may be further configured to perform any of the steps of method 600. [0105] A first component is directly coupled to a second component when there are no intervening components, except for a line, a trace, or another medium between the first component and the second component. The first component is indirectly coupled to the second component when there are intervening components other than a line, a trace, or another medium between the first component and the second component. The term “coupled” and its variants include both directly coupled and indirectly coupled. The use of the term “about” means a range including ±10% of the subsequent number unless otherwise stated.

[0106] It should also be understood that the steps of the exemplary methods set forth herein are not necessarily required to be performed in the order described, and the order of the steps of such methods should be understood to be merely exemplary. Likewise, additional steps may be included in such methods, and certain steps may be omitted or combined, in methods consistent with various embodiments of the present disclosure. [0107] While several embodiments have been provided in the present disclosure, it may be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0108] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of the present disclosure. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method implemented by a network node in a domain-level segment routing (DLSR) network domain, the method comprising: receiving a first packet in an internet protocol (IP) version six (IPv6) format; encapsulating the first packet to generate a second packet that comprises an IPv6 header and a segment routing header (SRH), wherein the SRH comprises a segment list corresponding to a forwarding path, the segment list comprises domain segment identifiers (DSIDs) that each comprise a domain identifier (ID) identifying a domain associated with a corresponding DSID, and the IPv6 header comprises an IPv6 destination address being set to a value of a first DSID in the segment list; and forwarding the second packet to a second node based on the IPv6 destination address.

2. The method of claim 1, wherein the SRH further comprises a plurality of node segment identifiers (SIDs) that each comprise a node ID identifying a node.

3. The method of claim 1 or 2, wherein SRH further comprises a segments left field having a pointer to a next DSID in the segment list.

4. The method of any of claims 1-3, wherein a length of a prefix is variable, and wherein each of the DSIDs share a common prefix indicating a type of segment identifiers in the segment list.

5. The method of any of claims 1-4, wherein the domain ID is a globally unique identifier of 32 bits and represents an autonomous system (AS) number assigned to the domain.

6. The method of any of claims 1-5, wherein the domain ID is included in a DSID locator that is used as an anycast address of the domain.

7. The method of any of claims 1-6, wherein the SRH further comprises a routing type field set to indicate that domain level source routing is used for the second packet.

8. The method of any of claims 1-7, wherein the second packet further comprises a domain level source routing (DLSR) options type length value (TLV) containing quality of service (QoS) data for domains traversed by the packet.

9. The method of any of claims 1-8, wherein the first packet is encapsulated in the second packet as a packet payload.

10. The method of any of claims 1-8, wherein the encapsulating the first packet to generate the second packet comprises: asserting the SRH into the first packet to generate the second packet, wherein a modifying a first IPv6 destination of the first packet to the value of the first DSID in the segment list as the IPv6 destination of the second packet.

11. A method implemented by a network node in a domain-level segment routing (DLSR) network domain, the method comprising: receiving a packet in an internet protocol (IP) version six (IPv6) format, wherein the packet comprises an IPv6 destination address and a segment routing header (SRH), wherein the SRH comprises a segment list corresponding to a forwarding path and a segments left field, and wherein the segment list comprises domain segment identifiers (DSIDs) each including a domain identifier (ID) identifying a domain; determining whether the IPv6 destination address matches an address of the network node; determining a next DSID from the DSIDs in the segment list when the IPv6 destination address matches the address of the network node; updating the IPv6 destination address to the next DSID in the segment list; and forwarding the packet with the updated IPv6 destination address toward a next domain based on the updated IPv6 destination address.

12. The method of claim 11, wherein the segments left field comprising a pointer to the next DSID, and wherein the method further comprises decrementing the pointer upon determining the next DSID.

13. The method of claims 1 1 or 12, wherein each of the DSIDs comprises a domain ID identifying a domain associated with a corresponding DSID.

14. The method of any of claims 10-13, wherein a length of a prefix is variable, and wherein each of the DSIDs share a common prefix indicating a type of segment identifiers in the segment list.

15. The method of any of claims 10-14, wherein the domain ID is a globally unique identifier of 32 bits and represents an autonomous system (AS) number assigned to the domain.

16. The method of any of claims 10-15, wherein the domain ID is included in a DSID locator that is used as an anycast address of the domain.

17. The method of any of claims 10-16, wherein the SRH further comprises a routing type field set to indicate domain level source routing is used for the packet.

18. The method of any of claims 10-17, wherein the packet further comprises a domain level source routing (DLSR) options type length value (TLV) containing quality of service (QoS) data for domains traversed by the packet.

19. An apparatus, comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the apparatus to perform the method of any of claims 1-10.

20. An apparatus, comprising: a memory storing instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the network node to perform the method of any of claims 11-18.

21 . A non-transitory computer readable medium comprising a computer program product for use by a network node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the network node to execute the method of any of claims 1-10.

22. A non-transitory computer readable medium comprising a computer program product for use by a network node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the network node to execute the method of any of claims 11-18.

23. A network device, comprising one or more means for performing the method of any of claims 1-10.

24. A network device, comprising one or more means for performing the method of any of claims 11-18.