Segment Routing for End-to-End IETF Network Slicing

introduces the concept and the characteristics of IETF network slice, and describes a general framework for IETF network slice management and operation.It also introduces the concept Network Resource Partition (NRP), which is a collection of resources identified in the underlay network. describes the framework and the candidate component technologies for providing enhanced VPN (VPN+) services based on existing VPN and Traffic Engineering (TE) technologies with enhanced characteristics that specific services require above traditional VPNs. It also introduces the concept of Virtual Transport Network (VTN). A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the underlay, so as to provide the network characteristics required by the customers. Enhanced VPN (VPN+) and VTN can be used for the realization of IETF network slices. In the context of IETF network slicing, a VTN can be instantiated as an NRP. VTN and NRP are considered interchangable terms in this document. describes the scalability considerations in the control plane and data plane to enable NRPs and provide the suggestions to improve the scalability of NRP. In the control plane, It proposes the approach of decoupling the topology and resource attributes of NRP, so that multiple NRPs may share the same topology and the result of topology based path computation. In the data plane, it proposes to carry a dedicated NRP-ID of a network domain in the data packet to determine the set of resources reserved for the corresponding NRP. An IETF network slice may span multiple network domains. Within each domain, traffic of the end-to-end network slice is mapped to a local network slice. The NRP ID which identifies the NRP in the local domain for the end-to-end network slice needs to be determined on the domain edge node. When segment routing (SR) is used to build a multi-domain IETF network slice, information of the local network slices in each domain can be specified using special SR binding segments called NRP binding segments (NRP BSID). The multi-domain IETF network slice can be specified using a list of NRP BSIDs in the packet, each of which can be used by the corresponding domain edge nodes to steer the traffic of end-to-end IETF network slice using the specific resource-aware segments or NRP-ID of the local domain. This document describes the functionality of the network slice binding segment and its instantiation in SR-MPLS and SRv6.

describes the scalability considerations in the control plane and data plane to create NRPs. In data plane, it proposes to carry a dedicated NRP-ID in data packet to determine the set of resources reserved for the corresponding NRP in a network domain. describes the framework of carrying network slice related identifiers in the data plane, each of the network slice IDs may have a different network scope. It provides an approach of mapping the global NRP-ID to domain NRP-IDs at the network domain border nodes. With Segment Routing, there are several optional approaches to realize the mapping between the end-to-end network slice and the network slice constructs in the local domain. The first type of approaches are to use one type of NRP BSID to steer traffic to an SR Policy associated with a local NRP. This is called the NRP-TE BSID. There are some variants in terms of the detailed behavior: The first variant is to use one type of NRP BSID to specify the mapping of traffic to a SR policy which consists of list of resource-aware segments associated with a local NRP. The second variant is to use one type of NRP BSID to specify the mapping of traffic to a SR policy which is bound to a local NRP-ID. The second type of approaches is to use one type of NRP BSID to steer traffic to follow the shortest path within a local domain NRP. This is called the NRP-BE BSID. There are some variants in terms of the detailed behavior: The first variant is to use one type of NRP BSID to determine a local NRP-ID, and instruct the encapsulation of the local NRP-ID into the packet at the domain edge node. The second variant is to use one type of NRP BSID to specify the mapping of traffic to a local NRP, the local NRP-ID is specified in the associated fields by the ingress node, and is encapsulated into the packet at the domain edge node. The behavior of the first type of NRP BSID is similar to the function of the existing SR BSID, the difference is it is associated with a particular NRP. The second type of the NRP BSID is different from the existing binding segment. 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 function is defined to instantiate the Binding SID in SRv6, which can be reused as one type of NRP-TE BSID to specify the mapping of traffic to a list of resource-aware SRv6 segments of a domain NRP. describes the mechanism of carrying the VTN-ID of a network domain in the IPv6 Hop-by-Hop (HBH) extension header. For the type 2, 3, 4 of NRP binding segments described in section 2, three new SRv6 Binding functions are defined in the following sections.

A new SRv6 function called End.B6NRP.Encaps: Endpoint bound to a SRv6 Policy in a NRP with IPv6 encapsulation is defined in this section. 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 the SID list of the SR Policy and the NRP-ID in a new IPv6 header. Any SID instance of this behavior is associated with an SR Policy B, a 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 the VTN-ID in VTN option set to V in the HBH Ext header 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. }]]>

A new SRv6 function called End.NRP.Encaps 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 NRPs maintained on the endpoint. The NRP-ID is encapsulated in the VTN option in the IPv6 HBH extension header. Any SID instance of this behavior is associated with one 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.NRP.Encaps SID, N does the following:

A new SRv6 function called End.BNRP.Encaps: Endpoint bound to a NRP with IPv6 encapsulation is defined. This is a variation of the End behavior. For the End.BNRP SID, its corresponding NRP-ID should be specified and encapsulated by the ingress node of SRv6 Path. It instructs the endpoint node to obtain the corresponding NRP-ID from the SRH, and encapsulate it in the VTN option in the IPv6 HBH extension header. Through the End.BNRP.Encaps, the ingress node can flexibly specify the local NRP the packet traverses in the network. Any SID instance of this behavior is associated with one NRP-ID V and a source address A. There can be several options to carry the local NRP-ID corresponding to the End.BNRP.Encaps function: 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, option 1 is preferred, in which the local NRP-ID is carried in the argument field of the SRv6 SID. When an ingress node of an SR path encapsulates the End.BNRP.Encaps SID into the packet, it SHOULD put the NRP-ID which the packet is expected to be mapped to into the argument part of the SID. 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 VTN-ID in VTN option to V in the HBH Ext header S17. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination S18. }]]>

describes the mechanism of carrying the VTN-ID of a network domain in the MPLS extension header. With SR-MPLS data plane, NRP BSIDs can be allocated by a domain edge node for the three types of NRP binding behaviors described in section 2. For the first type of NRP BSID, a BSID can be bound to a list of resource-aware segments of a local NRP. When a node receives a packet with a locally assigned NRP BSID, it determines the corresponding SID list which consists of the resource-aware segments of a local NRP, and encapsulates the SID list to the MPLS label stack. For another variant of the first type NRP BSID, a NRP BSID is bound to a SR Policy and a local NRP-ID. When a node receives a packet with a locally assigned NRP BSID, it determines the corresponding SID list and the local NRP-ID, and encaps the packet with the SID list and an MPLS VTN extension header which carries the local NRP-ID. Note this requires to assign a NRP BSID for each SR policy in each NRP the node participates in. For the second type of NRP BSID, a NRP BSID is bound to the shortest path in an NRP of the local network domain. When a node receives a packet with a locally assigned NRP BSID, it determines the corresponding local NRP-ID based on the mapping relationship between the NRP BSID and the NRP-ID, and encapsulates the packet with an MPLS VTN extension header which carries the local NRP-ID. Note this requires to assign a NRP BSID for each local NRP. For a variant of the second type NRP BSID, a NRP BSID is bound to the shortest path in an NRP of the local network domain, the NRP-ID is specified and encapsulated by the ingress node in the MPLS VTN extension header. When a node receives a packet with a locally assigned NRP BSID, it obtains the corresponding local NRP-ID from the NRP-ID list in the VTN extension header, and update the local NRP-ID in the VTN extension header with the obtained NRP-ID.

TBD

The authors would like to thank Zhibo Hu for his review and valuable comments.