Segment Routing for End-to-End IETF Network Slicing

Abstract

Network slicing can be used to meet the connectivity and performance requirement of different services or customers in a shared network. An IETF network slice can be realized as enhanced VPNs (VPN+), which is delivered by integrating the overlay VPN service with a Virtual Transport Network (VTN) as the underlay. An end-to-end IETF network slice may span multiple network domains. Within each domain, traffic of the end-to-end network slice service is mapped to a local VTN.¶

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 VTN binding segments (VTN BSID). The multi-domain IETF network slice can be specified using a list of VTN 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 into the specific VTN in the local domain.¶

This document describes the functionality of VTN binding segment and its instantiation in SR-MPLS and SRv6.¶

1. Introduction

[I-D.ietf-teas-ietf-network-slices] introduces the concept and the characteristics of IETF network slice, and describes a general framework for IETF network slice management and operation.¶

[I-D.ietf-teas-enhanced-vpn] 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.¶

[I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the scalability considerations in the control plane and data plane to enable VPN+ services, and provide the suggestions to improve the scalability of VTN. In the control plane, It proposes the approach of decoupling the topology and resource attributes of VTN, so that multiple VTNs may share the same topology and the result of topology based path computation. In the data plane, it proposes to carry a VTN-ID of a network domain in the data packet to determine the set of resources reserved for the corresponding VTN.¶

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 VTN-ID which identifies the virtual underlay network 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 VTN binding segments (VTN BSID). The multi-domain IETF network slice can be specified using a list of VTN 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 VTN-ID of the local domain.¶

This document describes the functionality of the network slice binding segment and its instantiation in SR-MPLS and SRv6.¶

2. Segment Routing for IETF E2E Network Slicing

[I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the scalability considerations in the control plane and data plane to enable VPN+ services. In data plane, it proposes to carry a dedicated VTN-ID in data packet to determine the set of resources reserved for the corresponding VTN in a network domain.¶

[I-D.li-teas-e2e-ietf-network-slicing] 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 VTN-ID to local VTN-IDs at the network domain edge 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.¶

1. The first approach is to use one type of VTN binding segment to specify the mapping of traffic to a list of resource-aware segments of a local VTN.¶
2. The second approach is to use one type of VTN binding segment to determine a local VTN-ID, and instruct the encapsulation of the local VTN-ID into the packet at the domain edge node.¶
3. The third approach is to use one type of VTN binding segment to specify the mapping of traffic to a local VTN, the local VTN-ID is specified in the associated fields by the ingress node, and is encapsulated into the packet at the domain edge node.¶
4. The fourth approach is to use one type of VTN binding segment to specify the mapping of traffic to a SR policy which is bound to a local VTN.¶

The function of the first type of VTN binding segment is similar to the function of the existing binding segment, the difference is it is associated with a particular VTN. The other types of the VTN binding segments are different from the existing binding segment, and their instantiation in SR-MPLS and SRv6 are described in the following sections.¶

3. SRv6 VTN Binding Functions

[RFC8986] 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 used as the first type of VTN binding function to specify the mapping of traffic to a list of resource-aware SRv6 segments of a local VTN.¶

[I-D.dong-6man-enhanced-vpn-vtn-id] 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 VTN binding segments described in section 2, three new SRv6 Binding functions are defined in the following sections.¶

   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > 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 VTN-ID option to V in the HBH Ext header
   S16.   Submit the packet to the egress IPv6 FIB lookup for
             transmission to the new destination
   S17. }

   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > 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 VTN-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 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. }

   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > 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 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. }

4. SR-MPLS VTN BSIDs

[I-D.li-mpls-enhanced-vpn-vtn-id] describes the mechanism of carrying the VTN-ID of a network domain in the MPLS extension header.¶

With SR-MPLS data plane, VTN binding SIDs can be allocated by a domain edge node for the three types of VTN binding behaviors described in section 2.¶

For the first type of VTN binding segment, a BSID is bound to a list of resource-aware segments of a local VTN. When a node receives a packet with a locally assigned VTN BSID, it determines the corresponding SID list which consists of the resource-aware segments of a local VTN, and encapsulates the SID list to the MPLS label stack.¶

For the second type of VTN binding segment, a VTN BSID is bound to a VTN of the local network domain. When a node receives a packet with a locally assigned VTN BSID, it determines the corresponding local VTN-ID based on the mapping relationship between the VTN BSID and the VTN-ID, and encapsulates the packet with an MPLS VTN extension header which carries the local VTN-ID option. Note this requires to assign a VTN BSID for each VTN.¶

For the third type of VTN binding segment, a VTN BSID is bound to a VTN of the local network domain, the VTN-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 VTN BSID, it obtains the corresponding local VTN-ID from the VTN-ID list in the VTN extension header, and update the local VTN-ID option in the VTN extension header with the obtained VTN-ID.¶

For the fourth type of VTN binding behavior, a VTN BSID is bound to a SR Policy in a VTN of the local network domain. When a node receives a packet with a locally assigned VTN BSID, it determines the corresponding SID list and the local VTN-ID, and encaps the packet with the SID list and an MPLS VTN extension header which carries the local VTN-ID option. Note this requires to assign a VTN BSID for each SR policy in each VTN the node participates in.¶

8. References