| Internet-Draft | IETF Network Slicing | June 2024 |
| Boucadair | Expires 28 December 2024 | [Page] |
This document lists a set of slicing-related specifications that are being development within the IETF. This document is meant to provide an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Traffic Engineering Architecture and Signaling Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/teas/.¶
Source for this draft and an issue tracker can be found at https://github.com/boucadair/ietf-slice-overview.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 December 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Various slicing efforts are being conduced within various IETF WGs (e.g., teas, idr, spring, ccamp, mpls, opsawg, 6man, and ippm) and areas (e.g., rtg, int, tsv, and ops). All these efforts are referring to the IETF framework that is developed by the teas WG (Section 2), however there is a lack of a global visibility about these efforts and their interdependency.¶
Also, there is a lack of cross-WG communications in some cases when a slicing-related specification is candidate for adoption or adopted by a WG. This lack of global view at the IETF level and lack of early cross-WG communications may induce some inconsistency. For example, some proposals argue in favor of specifying extensions to convey specific identifiers in packets. However, distinct identifiers are being proposed: slice identifier, NRP Selector, NRP identifier, VTN identifier, VTN resource identifier, etc. The need and relationship between these identifiers are worth to be discussed independent of the channels that are used to convey these identifiers.¶
This document provides an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent, e.g.:¶
Position the various concepts: network slice, network resource partition, virtual transport network, etc.¶
Clarify the need of the various identifiers introduced so far and soften redundant/duplicate uses.¶
Harmonize the definition of relevant identifiers (length, encoding, usage, etc.) rather than having the specification of the same identifier repeated in many places. For example, current specifications use distinct encoding length of the same attribute (variable, 16-bit, 32-bit).¶
Clarify the relationship and co-existence of identifiers if more than one is needed.¶
[RFC9543] is the authoritative IETF framework for Network Slices. It provides definitions for a slice-related core terms and specifies a framework for the provision of Network Slice Services over networks that are deployed using technologies that are owned by the IETF (IP, MPLS, etc.). The document refers to such slices as IETF Network Slice or "the term "RFC 9543 Network Slice".¶
[RFC9543] provides a clear distinction between:¶
the "RFC 9543 Network Slice Service" which is the service delivered to the customer and which is agnostic to the technologies and mechanisms used by the service provider, and¶
the "RFC 9543 Network Slice" which is the realization of the service in the service provider's network achieved by partitioning network resources and by applying a set of mechanisms within the network.¶
The RFC 9543 Network Slice Service is specified in terms of:¶
a set of Service Demarcation Point (SDP),¶
a set of one or more connectivity constructs between subsets of these SDPs, and¶
a set of service objectives for each SDP sending to each connectivity construct.¶
The service objectives can be expressed as Service Level Objectives (SLOs) or Service Level Expectations (SLEs).¶
In some deploymenets, the underlying network can be customized to select a subset of resources that are suitable for the delivery of an RFC 9543 Network Slice Service. Such a customization can be achieved by creating a set of Network Resource Partitions (NRPs).¶
In other deployments, RFC 9543 Network Slices can be hosted directly on the underlay network (i.e., without requiring any NRP).¶
RFC 9543 Network Slices can be realized using existing tools (Section 3.1). The extensions listed in Section 6 or Section 7 are not required in such a case.¶
[RFC9543] does not provide any recommendation about the technological means to realize an RFC 9543 Network Slice Service. These considerations are deployment specific.¶
[I-D.ietf-teas-5g-ns-ip-mpls] describes a model for the realization of RFC 9543 Network Slices for 5G networks. This realization model reuses many building blocks that are commonly used in service provider networks, specifically:¶
[I-D.ietf-teas-ns-ip-mpls] proposes a model that is inspired from the Diffserv model for the realization of Network Slices over IP/MPLS networks. Specifically, this model introduces the concept of Slice-Flow Aggregate which is defined as a collection of packets that are mapped to an NRP and are given the same forwarding treatment in a shared network. An aggregate can group flows from of one or more RFC 9543 Network Slice Services.¶
[I-D.ietf-teas-ns-ip-mpls] also introduces the notion of NRP Policy that is used to trigger the creation of NRPs that will support a given Slice-Flow Aggregate. In some deployment schemes, packets that belong to a Slice-Flow Aggregate are forwarded by intermediate node along the appropriate NRP by processing an NRP Selector that is carried by these packets.¶
[I-D.ietf-ccamp-yang-otn-slicing] defines Optical Transport Networks (OTN) slice as an OTN virtual network topology connecting a number of OTN endpoints using a set of shared or dedicated OTN network resources to satisfy specific SLOs. OTN slices are considered as a technology-specific realization of an RFC 9543 Network Slice in the OTN domain.¶
[I-D.ietf-teas-enhanced-vpn] describes a framework for providing enhanced VPN services based upon VPN and Traffic Engineering (TE) technologies. Enhanced VPN (VPN+) can be used for the realization of Network Slices. This document introduces the concept of Virtual Transport Network (VTN), which is a virtual underlay network consisting of a subset of network resources allocated from the physical underlay network, and is associated with a customized network topology.¶
[I-D.barguil-teas-network-slices-instantation] focuses on the instantiation of the RFC 9543 Network Slice Services in service provider networks using existing data models. In particular, this document describes the relationship between service models for managing the RFC 9543 Network Slice Services and network models (e.g., the Layer-3 Network Model (L3NPM, [RFC9182]), the Layer-2 Network Model (L2NM [RFC9291])) used for the realization of the slices.¶
[I-D.ietf-teas-ns-controller-models] proposes an approach for structuring the RFC 9543 Network Slice Controller as well as how to use different data models being defined for RFC 9543 Network Slice Service provision.¶
[I-D.gong-spring-hierarchical-slice-solution] proposes a hierarchical approach for realizing RFC 9543 Network Slices in Segment Routing domain. The approach involves two levels:¶
[I-D.li-teas-composite-network-slices] investigates a set of scenarios for realizing composite RFC 9543 Network Slices (that basically involve other slices). The document defines a new identifier, called Inter-domain NRP ID.¶
[I-D.zhang-rtgwg-aaa-hierarchical-network-slices] describes an authentication, authorization, and accounting process for hierarchical Network Slices. The document suggest adding NRP-ID to accounting meesages, but lacks a discussion whether any protocol extension is needed.¶
[I-D.ietf-teas-5g-network-slice-application] focuses on the application of RFC 9543 Network Slices in the context of the 3GPP 5G slices.¶
[I-D.cbs-teas-5qi-to-dscp-mapping] documents an example of possible mapping of 5QI values to DSCP markings with a focus on 5G Network Slices. The document groups different 5QI types in classes based on their SLOs.¶
[I-D.jiang-tsvwg-slice-media-service] explores how IETF schemes (DSCP and UDP options) can be used to expose some QoS-related metadata for specific flows to 5GS. The document focuses on the Extended Reality & multi-modality communication (XRM) service.¶
[I-D.ietf-teas-applicability-actn-slicing] describes the applicability of ACTN to Network Slicing.¶
[I-D.ietf-dmm-tn-aware-mobility] discusses a mapping of 5G slices to RFC 9543 Network Slices when the transport network is separated from the networks in which the 5G network functions are deployed (e.g., 5G functions distributed across data centers). This document zooms into the use of UDP source port number in GTP-U outer header and LAN to map between a 5G slice and corresponding RFC 9543 Network Slice segments that is listed in [I-D.ietf-teas-5g-network-slice-application].¶
[I-D.sw-detnet-network-slice-mapping-yang] describes the applicability of DetNet to RFC 9543 Network Slice, particularly to provide deterministic services. The document describes how to use DetNet flow aggregation as the Slice-Flow Aggregates over an underlying NRP following the approach in Section 3.2.¶
Figure 1 provides an example of the various data models that can be invoked in the context of Network Slicing.¶
+---------------+
| Customer |
+-------+-------+
Customer Service Model |
e.g., slice-svc, ac-svc,| and bearer-svc
+-------+-------+
| Service |
| Orchestration |
+-------+-------+
Network Model |
e.g., l2vpn-ntw, l3vpn-ntw, sap, and | ac-ntw
+-------+-------+
| Network |
| Orchestration |
+-------+-------+
Network Configuration Model |
+-----------+-----------+
| |
+--------+------+ +--------+------+
| Domain | | Domain |
| Orchestration | | Orchestration |
+---+-----------+ +--------+------+
Device | | |
Configuration | | |
Model | | |
+----+----+ | |
| Config | | |
| Manager | | |
+----+----+ | |
| | |
| NETCONF/CLI..................
| | |
+--------------------------------+
+----+ Bearer | | Bearer +----+
|CE#1+--------+ Network +--------+CE#2|
+----+ AC | | AC +----+
+--------------------------------+
Site A Site B
[RFC9181] specifies a set of reusable types and groupings to manage VPN services. Note that VPNs are used for the realization of Network Slices.¶
[I-D.ietf-opsawg-teas-common-ac] specifies a set of reusable types and groupings to manage Attachment Circuits (ACs).¶
[I-D.ietf-opsawg-teas-attachment-circuit] specifies YANG data models for managing 'Attachment Circuits'-as-a-Service (ACaaS) and also bearers. These ACs and bearers are used to identify where to deliver a slice service.¶
[I-D.ietf-teas-ietf-network-slice-nbi-yang] defines a YANG data model for manaing RFC 9543 Network Slice Services.¶
[RFC9408] defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks).¶
A SAP network topology can be used for one or multiple service types ('service-type'). Setting this data node to 'network-slice' allows a controller to expose where RFC 9543 Network Slices services are being delivered. It can also be used to check where RFC 9543 Network Slice Services can be delivered.¶
[I-D.ietf-opsawg-ntw-attachment-circuit] augments the SAP model with more details for managing ACs at the network level.¶
[I-D.liu-teas-transport-network-slice-yang] specifies a YANG model for RFC 9543 Network Slice Topology with on exposing a customized topology that contains a topology intent with required SLO/SLEs to express the customer’s intent for resource reservation.¶
The need for such a model is yet to be justified as the current scope is redundant with, e.g., what can be already achieved using [I-D.ietf-teas-actn-vn-yang]. The authors should motivate why [I-D.ietf-teas-actn-vn-yang] is not sufficient.¶
[I-D.ietf-teas-nrp-yang] specifies a YANG data model for managing NRPs.¶
[I-D.dhody-teas-ietf-network-slice-mapping] specifies an RFC 9543 Network Slice Service mapping YANG model. The model supports the following mappings:¶
[I-D.ietf-idr-bgp-ct] specifies mechanisms for classifying underlay routes into a set of classes, called Transport Classes, and mapping service-specific routes to a specific Transport Class. For example, [I-D.ietf-idr-bgp-ct] can be used to create a customized topology for Network Slices. These topologies (Transport Classes) will be typically created to satisfy certain TE characteristics. A new Transport Class Route Target Extended Community is defined for this purpose. A Transport Class is identified by a 4-octet identifier: Transport Class ID.¶
[I-D.ietf-idr-bgp-car] specifies a new BGP SAFI called BGP Color-Aware Routing (BGP CAR). Colors are defined to characterize an objective (e.g., low latency). To satisfy Network Slice requirements, CAR may be used to establish paths that address specific objectives. These paths will be associated with a Color.¶
The proposal leverages the BGP Color Extended Community defined in [RFC9012] and builds upon the Color concept defined in [RFC9256]. In addition, a new Extended Community, called Local-Color-Mapping (LCM) Extended Community, is defined to address cases where the granularity of the exposed colors differs when crossing domains.¶
[I-D.ietf-idr-flowspec-network-slice-ts] specifies a BGP Flowspec extension for NRP traffic steering.¶
[I-D.drake-teas-bgp-ls-filter-nrp] specifies new BGP-LS attributes, called BGP-LS Filters, for NRPs in SR networks. A BGP-LS Filter provides a description of a subset of the links and nodes in an underlay network. Ingress PE selects a path to an egress PE from the topology defined by the BGP-LS Filters it has imported for a given VPN.¶
[I-D.chen-idr-bgp-ls-transport-slice] adds new BGP-LS attribute TLVs to encode information such as NRP-ID.¶
[I-D.ietf-idr-sr-policy-nrp] and [I-D.liu-idr-bgp-network-slicing] define extensions to BGP in order to advertise NRP ID in an SR Policy. The NRP ID is encoded in 4 octets.¶
[I-D.chen-idr-bgp-ls-sr-policy-nrp] specifies SR Policy extensions for NRP in BGP-LS. The NRP ID is encoded in 4 octets.¶
[I-D.dong-pce-pcep-nrp] specifie Path Computation Element Communication Protocol (PCEP) extensions for NRP. The NRP ID is encoded in 4 octets.¶
[I-D.ietf-lsr-isis-sr-vtn-mt] specifies how to use IS-IS Multi-Topology (MT) for SR-based VTNs.¶
[I-D.ietf-idr-bgpls-sr-vtn-mt] describes a mechanism to distribute the information of SR-based VTNs to the network controller using BGP-LS with Multi-Topology.¶
[I-D.decraene-mpls-slid-encoded-entropy-label-id] proposes an approach to encode slice identifiers in a portion of the MPLS Entropy Label (EL). The number of bits to be used for encoding the slice identifier in the EL is policy-based. Transit LSRs uses the slice identifier in the EL to apply per-slice policies.¶
[I-D.filsfils-spring-srv6-stateless-slice-id] proposes to encode slice identifers in a portion of the IPv6 Flow Label. Slice identifiers are used by intermediate IPv6 routers to process the packet according to a network slice policy.¶
When an ingress SR router encapsulates a packet in an IPv6 packet with an SRH, [I-D.cheng-spring-srv6-encoding-network-sliceid] suggests to use the least significant bits of the outer IPv6 source address to encode a slide identifier. SLID Presence Indicator (SPI) is used to indicate the presence of a slice identifier. The number of bits used to encode slice identifiers is local to an SR domain.¶
[I-D.ietf-6man-enhanced-vpn-vtn-id] describes a mechanism to carry an identifier, called VTN resource ID, in the IPv6 Hop-by-Hop extension header. The document claims that "VTN resource ID" is equivalent to NRP-ID, but does motivate why another yet ID is thus needed rather than using "NRP-ID".¶
The length of the VTN ID depends on the context type. When CT=0, the VTN ID is a 4-octet ID.¶
An NRP can be represented in SR networks using a set of NRP-specific resource-aware segments [I-D.ietf-spring-resource-aware-segments] [I-D.ietf-spring-sr-for-enhanced-vpn].¶
[I-D.liu-spring-nrp-id-in-srv6-segment] specifies an approach to encode the NRP ID in the SRH. This ID is used by intermediate IPv6 routers to identify the NRP to be used for forwarding. The encoding of the NRP ID in an IPv6 address is variable; an instruction is thus needed to help identifyint the NRP-ID position (e.g., low 16 bits).¶
As mentioned in Section 3.2, packets that are associated with a Slice-Flow Aggregate may carry an NRP Selector (NRPS). This selector is intended to be conveyed in the packet's network layer header to identify the flow aggregate to which a packet belongs. [I-D.li-mpls-mna-nrp-selector] investigates a set of options to use MPLS Network Actions (MNA) to carry the NRPS:¶
[I-D.gong-spring-srv6-nrp-flavor] defines a new SRv6 Endpoint behavior [RFC8986] to associate a SID with a set of NRPs.¶
[I-D.liu-mpls-lsp-ping-nrp] specifies extenstions to the LSP Ping/Traceroute to convey NRP-ID in SR domains.¶
The NRP-ID is a encoded as a 4-octet field.¶
[RFC9544] introduces a new set of metrics, called Precision Availability Metrics (PAM). These metrics are used to assess whether a service (e.g., Network Slice Service) is provided in compliance with its specified SLOs.¶
[I-D.clemm-opsawg-pam-ipfix] specifies a set of new IP Flow Information Export (IPFIX) Information Elements to export precision availability data associated with Flows. These Information Elements are specifically designed to indicate compliance of a Flow with an SLO.¶
[I-D.liu-opsawg-ipfix-network-slice] explores how to use IPFIX to export NRP IDs. However, there is currently no one single stable/authoritative specification of NRP-ID. This identifier is being proposed as data plane and control plane extensions. These proposals do not share the same ID format.¶
The initial version of [I-D.liu-opsawg-ipfix-network-slice] does explain which plan is used, in which layer the ID was exported, etc. Defining an IPFIX IE is useful for network observability, however there is no stable specification yet of the ID to be exported.¶
[I-D.contreras-pce-pam] specifies a new PCEP object (PRECISION METRIC) for path calculation with performance requirements expressed as SLOs. The new PCEP object uses the attributes defined in [RFC9544].¶
[I-D.ietf-teas-nrp-scalability] discusses a set of scenarios for the deployment of NRP with a focus on scalability implications. The document reasons about the increase of requested RFC 9543 Network Slice Services that would require NRPs. Such an increase of slices is speculative at this stage.¶
[I-D.ma-teas-ietf-network-slice-deployment] reports a set of "deployments" from various network operators and identifies some considerations for operating Network Slices (e.g., scalability and automation). Most of these reported cases rely upon SRv6. The document does not provide enough details whether these "deployments" are for testing purposes or reflect setups to carry customers' traffic.¶
Security considerations of the mechanisms listed in the document are discussed in the relevant documents that specify these mechanisms.¶
This document does not make any request to IANA.¶
Thanks to Kaliraj Vairavakkalai for the comments.¶