| Internet-Draft | IETF Network Slicing | June 2023 |
| Boucadair | Expires 11 December 2023 | [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 (teas@ietf.org), 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 11 December 2023.¶
Copyright (c) 2023 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.:¶
Future versions of this document many include recommendations.¶
[I-D.ietf-teas-ietf-network-slices] 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.¶
[I-D.ietf-teas-ietf-network-slices] provides a clear distinction between:¶
The IETF Network Slice service is specified in terms of:¶
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 IETF Network Slice service. Such a customization can be achieved by creating a set of Network Resource Partitions (NRPs).¶
In other deployments, IETF Network Slices can be hosted directly on the underlay network (i.e., without requiring any NRP).¶
IETF 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.¶
[I-D.ietf-teas-ietf-network-slices] does not provide any recommendation about the technological means to realize an IETF Network Slice service. These considerations are deployment specific.¶
[I-D.srld-teas-5g-slicing] describes a model for the realization of IETF 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 IETF 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 IETF 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 IETF 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 IETF Network Slice services in service provider networks using available data models. In particular, this document describes the relationship between service models for managing the IETF 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.contreras-teas-slice-controller-models] proposes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision.¶
[I-D.gong-teas-hierarchical-slice-solution] proposes a hierarchical approach for realizing IETF 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 IETF Network Slices (that basically involve other slices). The document defines a new identifier, called Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID).¶
[I-D.ietf-teas-5g-network-slice-application] focuses on the application of IETF Network Slices in the context of the 3GPP 5G slices.¶
[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 IETF 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 IETF 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 IETF 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.boro-opsawg-teas-common-ac] specifies a set of reusable types and groupings to manage Attachment Circuits (ACs).¶
[I-D.boro-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 IETF Network Slice Services.¶
[I-D.ietf-opsawg-sap] 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 IETF Network Slices services are being delivered. It can also be used to check where IETF Network Slice services can be delivered.¶
[I-D.boro-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 IETF Network Slice Topology.¶
The need for such a model is yet to be justified as the current scope is redundant with what can be already achieved using the SAP model (Section 5.3.1).¶
[I-D.wdbsp-teas-nrp-yang] specifies a YANG data model for managing NRPs.¶
[I-D.dhody-teas-ietf-network-slice-mapping] specifies an IETF Network Slice Service mapping YANG model. The model supports the following mappings:¶
[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.dong-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.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.¶
[I-D.ietf-ippm-pam] 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.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 IETF Network Slice services that would require NRPs. Such an increase of slices is speculative at this stage.¶
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 TBC.¶