Segment Routing for End-to-End IETF Network Slicing

introduces the concept and the characteristics of IETF network slices, and describes a general framework for IETF network slice management and operation. It also introduces the concept of the Network Resource Partition (NRP), which is a collection of resources identified in the underlay network. An IETF network slice can be realized by mapping a set of connectivity constructs to a network resource partition (NRP). describes the framework and the candidate component technologies for providing enhanced VPN (VPN+) services based on VPN and Traffic Engineering (TE) technologies. Enhanced VPN (VPN+) can be used for the realization of IETF network slices. describes the scalability considerations in the control plane and data plane of NRPs and provides suggestions to improve the scalability of NRPs. In the data plane, it proposes to carry an NRP-ID in the data packet to determine the set of resources reserved for the corresponding NRP. describes the mechanism of carrying the VTN resource ID (which is equivalent to NRP-ID) of a network domain in the IPv6 Hop-by-Hop (HBH) extension header. An end-to-end IETF network slice may span multiple network domains. Within each domain, traffic of the end-to-end network slice service needs to be mapped to an intra-domain NRP. On the domain edge nodes, the NRP in the local domain used for carrying the end-to-end network slice needs to be determined. describes the framework for carrying network slice related identifiers in the data plane: each of the network slice related identifiers may have a different network scope. It provides an approach of mapping the inter-domain NRP-ID to intra-domain NRP-IDs at the network domain edge nodes. In SR networks, an NRP can be established and represented using either a set of NRP-specific resource-aware segments , or an NRP-ID which can identify the set of network resources allocated to an NRP. When segment routing (SR) is used to provide end-to-end IETF network slices, information of the intra-domain NRP can be specified using special SR binding segments called NRP binding segments and indicated by Segment Identifiers (SIDs) called NRP binding segment identifiers (NRP BSID). Then an inter-domain NRP can be specified using a list of NRP BSIDs in the packet, each of which is used by the corresponding domain edge nodes to steer the traffic of the end-to-end IETF network slice into the specific intra-domain NRP. This document describes the functionality of the NRP binding segment and its instantiation in SR-MPLS and SRv6 data plane.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

With Segment Routing, there are several optional approaches to steer the end-to-end network slice traffic into the intra-domain NRPs. These approaches can be classified into two categories. The first category of the approaches are to use an NRP BSID to steer traffic to an SR Policy which is associated with an intra-domain NRP. This is called the NRP Traffic Engineering (NRP-TE) BSID. There are two variants in terms of the detailed behavior: The first variant is to use an NRP BSID to specify the mapping of traffic to an SR policy which consists of list of resource-aware segments associated with a intra-domain NRP. The second variant is to use an NRP BSID to specify the mapping of traffic to an SR policy which is associated with an intra-domain NRP-ID. The second category of approaches are to use an NRP BSID to steer traffic to follow the shortest path within an intra-domain NRP. This is called the NRP Best Effort (NRP-BE) BSID. There are two variants in terms of the detailed behavior: The first variant is to use an NRP BSID to determine an intra-domain NRP-ID, and instruct the domain edge node to encapsulate the intra-domain NRP-ID into the packet. The second variant is to use an NRP BSID to specify the mapping of traffic to an intra-domain NRP, the intra-domain NRP-ID is specified in some fields of the packet by the ingress node of the end-to-end network slice, and is obtained and encapsulated into the packet at the domain edge node. The behavior of the NRP-TE BSID is similar to the function of the existing SR BSID, the difference is that it is associated with a particular intra-domain NRP. The behavior of the NRP-BE BSID is different from the existing SR BSID. The instantiation of the NRP BSIDs in SR-MPLS and SRv6 are described in the following sections.

defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors. The SRv6 End.B6.Encaps behavior is defined to bind to an SRv6 Policy with encapsulation, and it can be used for the first variant of the NRP-TE BSID. In this case, the SRv6 End.B6 encaps function is used to steer the network slice traffic to an SRv6 Policy, which consists of candidate paths built with resource-aware SRv6 segment lists that are associated with an intra-domain NRP. For other types and variants of NRP binding segments as described in section 2, three new SRv6 behaviors are defined as shown in the following subsections.

A new SRv6 function called End.B6NRP.Encaps: Endpoint bound to an SRv6 Policy with IPv6 NRP encapsulation is defined. This is a variation of the End behavior. It instructs the endpoint node to determine an SRv6 Policy in a specific NRP of the local-domain, and encapsulate both the SID list and the NRP-ID specified by the SRv6 Policy in a new IPv6 header. Any SID instance of this behavior is associated with an SR Policy B, an NRP-ID V, and a source address A. When node N receives a packet whose IPv6 DA is S, and S is a local End.B6NRP.Encaps SID, N does the following:

max_LE) or (Segments Left > Last Entry+1)) { S10. Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S11. } S12. Decrement IPv6 Hop Limit by 1 S13. Decrement Segments Left by 1 S14. Update IPv6 DA with Segment List[Segments Left] S15. Push a new IPv6 header with its own SRH containing B, and set the NRP-ID in the HBH header to V S16. Set the outer IPv6 SA to A S17. Set the outer IPv6 DA to the first SID of B S18. Set the outer Payload Length, Traffic Class, Flow Label, Hop Limit, and Next Header fields S19. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination S20. } | Note: | Comparing with the End.B6.Encaps behavior, the difference is | in step 15, which includes the setting of the NRP-ID in the | IPv6 HBH header ]]>

A new SRv6 function called End.NRP.Encaps: Endpoint with IPv6 NRP encapsulation is defined. This is a variation of the End behavior. It instructs the endpoint node to determine the corresponding NRP-ID of the local domain based on the mapping relationship between the End.NRP.Encaps SID and the intra-domain NRPs maintained on the endpoint. Then the NRP-ID is carried in the IPv6 HBH header of the packet. Any SID instance of this behavior is associated with an NRP-ID V. When node N receives a packet whose IPv6 DA is S, and S is a local End.NRP.Encaps SID, N does the following:

max_LE) or (Segments Left > Last Entry+1)) { S10. Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S11. } S12. Decrement IPv6 Hop Limit by 1 S13. Decrement Segments Left by 1 S14. Update IPv6 DA with Segment List [Segments Left] S15. Set the NRP-ID in the HBH header to V S16. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination S17. } | Note: | Comparing with the End.B6NRP.Encaps behavior, the difference is | in step 15 to 17, which does not need to include an SRH | in the IPv6 header]]>

A new SRv6 function called End.BNRP.Encaps: Endpoint bound to an IPv6 NRP with encapsulation is defined. This is a variation of the End behavior. For the End.BNRP SID, its corresponding NRP-ID is specified by the ingress node of the SRv6 path of the inter-domain NRP, and is carried in some fields of the packet. It instructs the endpoint node to obtain the corresponding NRP-ID from the received packet, and encapsulate it into the IPv6 HBH header of the packet for further forwarding. Through the End.BNRP.Encaps behavior, the ingress node can flexibly specify the intra-domain NRPs the packet needs to traverse in the multi-domain network. Any SID instance of this behavior is associated with an NRP-ID V. There can be several options to carry the intra-domain NRP-ID corresponding to the End.BNRP.Encaps behavior: The NRP-ID is carried in the argument field of the End.BNRP.Encaps SID. The NRP-ID is carried in the SRH TLV field. The NRP-ID is carried in the next SID following the End.BNRP.Encaps SID in the SID list. Editor's note: In the current version of this document, the option 1 is further specified. The use of other options is for further study. When an ingress node of an end-to-end SR path of the inter-domain NRP encapsulates an End.BNRP.Encaps SID in the SID list, it SHOULD put the intra-domain NRP-ID which the packet is expected to be steered to in that domain into the argument part of the corresponding SID. Any SID instance of this behavior contains one NRP-ID V in its argument. When node N receives a packet whose IPv6 DA is S, and S is a local End.BNRP.Encaps SID, N does the following:

max_LE) or (Segments Left > Last Entry+1)) { S10. Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S11. } S12. Obtain the NRP-ID V from the argument part of the IPv6 DA S13. Decrement IPv6 Hop Limit by 1 S14. Decrement Segments Left by 1 S15. Update IPv6 DA with Segment List [Segments Left] S16. Set the NRP-ID in the HBH header to V S17. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination S18. } | Note: | Comparing with the End.NRP.Encaps behavior, the difference is | in the new step 12, which is to obtain the NRP-ID from the | current IPv6 DA. ]]>

describes the mechanism of carrying the VTN ID in the MPLS extension header. The VTN ID is equivalent to an NRP-ID. With the SR-MPLS data plane, SR-MPLS BSIDs can be allocated by a domain edge node for different NRP Binding behaviors described in section 2. For the first variant of NRP-TE BSID, an SR-MPLS BSID is bound to an SR Policy which consists of candidate paths built with resource-aware segment lists associated with an intra-domain NRP. When a node receives a packet with a locally assigned NRP-TE BSID, it determines the corresponding segment list which consists of the resource-aware segments of a intra-domain NRP, and encapsulates the SID list to the MPLS label stack. For the second variant of the NRP-TE BSID, an SR-MPLS BSID is bound to an SR Policy associated with an intra-domain NRP-ID. When a node receives a packet with a locally assigned NRP-TE BSID, it determines the corresponding SID list and the intra-domain NRP-ID, and encapsulates the packet with both the SID list and an MPLS VTN extension header which carries the intra-domain NRP-ID. Note this requires to assign a separate NRP BSID for each SR policy in the intra-domain NRPs which the node participates in. For the first variant of the NRP-BE BSID, an SR-MPLS BSID is bound to the shortest path in an intra-domain NRP. When a node receives a packet with a locally assigned NRP-BE BSID, it determines the corresponding intra-domain NRP-ID based on the mapping relationship between the NRP-BE BSID and the intra-domain NRPs, and encapsulates the packet with an MPLS VTN extension header which carries the intra-domain NRP-ID. Note this requires to assign a separate NRP-BE BSID for each intra-domain NRP. For the second variant of the NRP-BE BSID, an SR-MPLS BSID is bound to the shortest path in an intra-domain NRP, the NRP-ID is specified by the E2E SR path ingress node of the inter-domain NRP and is carried in the MPLS VTN extension header. When a node receives a packet with a locally assigned NRP-BE BSID, it obtains the corresponding intra-domain NRP-ID from an NRP-ID list carried in the packet, then encapsulates the obtained intra-domain NRP-ID into the MPLS VTN extension header of the packet.

IANA is requested to assign the following code points from the "SRv6 Endpoint Behaviors" sub-registry in the "Segment-routing with IPv6 data plane (SRv6) Parameters" registry:

The security considerations of segment routing applies to this document.

The authors would like to thank Zhibo Hu and Yawei Zhang for their review and valuable comments.