A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies HPE
Wien Austria kszarkowicz@juniper.net
Nokia
Rennes France richard.roberts@nokia.com
HPE
London United Kingdom jlucek@juniper.net
Orange
France mohamed.boucadair@orange.com
Telefonica
Ronda de la Comunicacion, s/n Madrid Spain luismiguel.contrerasmurillo@telefonica.com https://lmcontreras.com/
RTG teas L3VPN L2VPN Slice Service Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a network slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling the service objectives for 5G slicing connectivity. The realization model reuses many building blocks commonly used in service provider networks at the current time.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2025 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 () 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.
Table of Contents
  • .  Introduction
  • .  Terminology
    • .  Definitions
    • .  Abbreviations
  • .  5G Network Slicing Integration in Transport Networks
    • .  Scope of the Transport Network
    • .  5G Network Slicing Versus Transport Network Slicing
    • .  Transport Network Reference Design
    • .  Orchestration Overview
    • .  Mapping 5G Network Slices to Transport Network Slices
    • .  First 5G Network Slice Versus Subsequent Slices
    • .  Overview of the Transport Network Realization Model
  • .  Handoff Between Domains
    • .  VLAN Handoff
    • .  IP Handoff
    • .  MPLS Label Handoff
  • .  QoS Mapping Realization Models
    • .  QoS Layers
    • .  QoS Realization Models
    • .  Transit Resource Control
  • .  PE Underlay Transport Mapping Models
    • .  5QI-Unaware Model
    • .  5QI-Aware Model
  • .  Capacity Planning/Management
    • .  Bandwidth Requirements
    • .  Bandwidth Models
  • .  Network Slicing OAM
  • .  Scalability Implications
  • . IANA Considerations
  • . Security Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • .  Example of Local IPv6 Addressing Plan for Network Functions
  • Acknowledgments
  • Contributors
  • Authors' Addresses
Introduction This document focuses on network slicing for 5G networks, covering the connectivity between Network Functions (NFs) across multiple domains such as edge clouds, data centers, and the Wide Area Network (WAN). The document describes a network slice realization approach that fulfills 5G slicing requirements by using existing IP/MPLS technologies (at the time of publication of this document) to optimally control connectivity Service Level Agreements (SLAs) offered for 5G Network Slices. To that aim, this document describes the scope of the Transport Network in 5G architectures (), disambiguates 5G Network Slicing versus Transport Network Slicing (), draws the perimeter of the various orchestration domains to realize slices (), and identifies the required coordination between these orchestration domains for adequate setup of Attachment Circuits (ACs) (). This work is compatible with the framework defined in , which describes network slicing in the context of networks built from IETF technologies. Specifically, this document describes an approach to how RFC 9543 Network Slices are realized within provider networks and how such slices are stitched to Transport Network resources in a customer site in the context of Transport Network Slices (). The realization of an RFC 9543 Network Slice (i.e., connectivity with performance commitments) involves the provider network and partially the AC (the Provider Edge (PE) side of the AC). This document assumes that the customer site infrastructure is over-provisioned and involves short distances (low latency) where basic QoS/scheduling logic is sufficient to comply with the Service Level Objectives (SLOs).
Transport Network Slice and RFC 9543 Network Slice Scopes | Transport Network Slice | RFC 9543 Network Slice SDP Type 3 - SDP Type 4- Customer Provider Customer Site 1 Network Site 2 AC AC NF ... CE PE PE NF |------------Transport Network Slice---------| RFC 9543 Network Slice .-----SDP Type 3----. | .- SDP Type 4-. | | | | | v v v v +------------+ +---------------+ +------------+ | Customer | | Provider | | Customer | | Site 1 | | Network | | Site 2 | | | +-+--+ +-+--+ | | | +---+ +--+-+ AC | | | | AC +-+-+ | | |NF +...+ CE +------+ PE | | PE +----+NF | | | +---+ +--+-+ | | | | +-+-+ | | | +-+--+ +-+--+ | | | | | | | | +------------+ +---------------+ +------------+
This document focuses on RFC 9543 Network Slice deployments where the Service Demarcation Points (SDPs) are located per Types 3 and 4 in Figure 1 of . The realization approach described in this document is typically triggered by Network Slice Service requests. How a Network Slice Service request is placed for realization, including how it is derived from a 5G Slice Service request, is out of scope. Mapping considerations between 3GPP and RFC 9543 Network Slice Service (e.g., mapping of service parameters) are discussed in documents such as . The 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) for slice identification . Because S-NSSAIs are not visible to the transport domain, 5G domains can expose the 5G Network Slices to the transport domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or Layer 4). Passing information between customer sites and provider networks is referred to as the "handoff". lists a set of handoff methods for slice mapping purposes. Unlike approaches that require new protocol extensions (e.g., ), the realization model described in this document uses a set of building blocks commonly used in service provider networks (at the time of publication of this document). The model uses (1) L2VPN and/or L3VPN service instances for logical separation, (2) fine-grained resource control at the PEs, (3) coarse-grained resource control within the provider network, and (4) capacity planning and management. More details are provided in Sections , , , and . This realization model uses a single Network Resource Partition (NRP) (). The applicability to multiple NRPs is out of scope. Although this document focuses on 5G, the realizations are not fundamentally constrained by the 5G use case. The document is not intended to be a BCP and does not claim to specify mandatory mechanisms to realize network slices. Rather, a key goal of the document is to provide pragmatic implementation approaches by leveraging existing techniques that are readily available and widely deployed. The document is also intended to align the mobile and the IETF perspectives of slicing from a realization perspective. For a definitive description of 3GPP network architectures, the reader should refer to . More details can be found in .
Terminology
Definitions The document uses the terms defined in . Specifically, the use of "Customer" is consistent with but with the following contextualization (see also ):
Customer:
An entity that is responsible for managing and orchestrating the end-to-end 5G Mobile Network, notably the Radio Access Network (RAN) and Core Network (CN). This entity is distinct from the customer of a 5G Network Slice Service.
This document makes use of the following terms:
Customer site:
A customer manages and deploys 5G NFs (e.g., gNodeB (gNB) and 5G Core (5GC)) in customer sites. A customer site can be either a physical or a virtual location. A provider is responsible for interconnecting customer sites. Examples of customer sites are a customer private locations (e.g., Point of Presence (PoP) and Data Center (DC)), a Virtual Private Cloud (VPC), or servers hosted within the provider network or colocation service.
Resource Control:
In the context of this document, resource control is used mainly to refer to buffer management and relevant Quality of Service (QoS) functions.
"5G Network Slicing" and "5G Network Slice":
Refer to "Network Slicing" and "Network Slice" as defined in .
Abbreviations
3GPP:
3rd Generation Partnership Project
5GC:
5G Core
5QI:
5G QoS Indicator
A2A:
Any-to-Any
AC:
Attachment Circuit
AMF:
Access and Mobility Management Function
CE:
Customer Edge
CIR:
Committed Information Rate
CS:
Customer Site
CN:
Core Network
CoS:
Class of Service
CP:
Control Plane
CU:
Centralized Unit
CU-CP:
Centralized Unit Control Plane
CU-UP:
Centralized Unit User Plane
DC:
Data Center
DDoS:
Distributed Denial of Service
DM:
Data Model
DSCP:
Differentiated Services Code Point
eCPRI:
enhanced Common Public Radio Interface
FIB:
Forwarding Information Base
GPRS:
General Packet Radio Service
gNB:
gNodeB
GTP:
GPRS Tunneling Protocol
GTP-U:
GPRS Tunneling Protocol User Plane
IGP:
Interior Gateway Protocol
L2VPN:
Layer 2 Virtual Private Network
L3VPN:
Layer 3 Virtual Private Network
LSP:
Label Switched Path
MACsec:
Media Access Control Security
MIoT:
Massive Internet of Things
MNO:
Mobile Network Operator
MPLS:
Multiprotocol Label Switching
NF:
Network Function
NS:
Network Slice
NRP:
Network Resource Partition
NSC:
Network Slice Controller
PE:
Provider Edge
PIR:
Peak Information Rate
QoS:
Quality of Service
RAN:
Radio Access Network
RIB:
Routing Information Base
RSVP:
Resource Reservation Protocol
SD:
Slice Differentiator
SDP:
Service Demarcation Point
SLA:
Service Level Agreement
SLO:
Service Level Objective
S-NSSAI:
Single Network Slice Selection Assistance Information
SST:
Slice/Service Type
SR:
Segment Routing
SRv6:
Segment Routing version 6
TC:
Traffic Class
TE:
Traffic Engineering
TN:
Transport Network
UP:
User Plane
UPF:
User Plane Function
URLLC:
Ultra-Reliable Low-Latency Communication
VLAN:
Virtual Local Area Network
VPN:
Virtual Private Network
VRF:
Virtual Routing and Forwarding
VXLAN:
Virtual Extensible Local Area Network
5G Network Slicing Integration in Transport Networks
Scope of the Transport Network The main 5G network building blocks are the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). The Transport Network is defined by the 3GPP in Section 1 of :
part supporting connectivity within and between CN and RAN parts.
The 3GPP management system does not directly control the Transport Network; it is considered a non-3GPP managed system. This is discussed in Section 4.4.1 of :
The non-3GPP part includes TN parts. The 3GPP management system provides the network slice requirements to the corresponding management systems of those non-3GPP parts, e.g. the TN part supports connectivity within and between CN and AN parts.
In practice, the TN may not map to a monolithic architecture and management domain. It is frequently segmented, non-uniform, and managed by different entities. For example, depicts an NF instance that is deployed in an edge data center (DC) connected to an NF located in a Public Cloud via a WAN (e.g., MPLS-VPN service). In this example, the TN can be seen as an abstraction representing an end-to-end connectivity based upon three distinct domains: DC, WAN, and Public Cloud. A model for the Transport Network based on orchestration domains is introduced in .
Example of Transport Network Decomposition 5G RAN or Core Network NF Transport Network NF Data Center -MPLS VPN- -Public- Backbone Cloud PE PE GW .-. .-. .-. .-. '-' '-' '-' '-' PE PE +----------------------------------+ +----+ 5G RAN or Core Network +----+ | +----------------------------------+ | | | v v +--+ +----------------------------------+ +--+ |NF+--+ Transport Network +--+NF| +--+ +--+---------------+------------+--+ +--+ | | | v v v +-- Data Center --+ +-MPLS VPN-+ +-Public-+ | | | Backbone | | Cloud | | +----+ +----+ | +--+ +--+ +--+ | | '----' '----' | |PE| |PE| |GW| | | .-. .-. .-. .-. | +--+ +--+ +--+ | | '-' '-' '-' '-' | | | | | | | +--+ +--+ | | | | |PE| |PE| | | | | +--+ +--+ | | | | | | | | +-----------------+ +----------+ +--------+
5G Network Slicing Versus Transport Network Slicing Network slicing has a different meaning in the 3GPP mobile world and transport world. This difference can be seen from the descriptions below that set out the objectives of 5G Network Slicing () and Transport Network Slicing (). These descriptions are not intended to be exhaustive.
5G Network Slicing In , the 3GPP defines 5G Network Slicing as an approach:
where logical networks/partitions are created, with appropriate isolation, resources and optimized topology to serve a purpose or service category (e.g. use case/traffic category, or for MNO internal reasons) or customers (logical system created "on demand").
These resources are from the TN, RAN, and CN domains together with the underlying infrastructure. Section 3.1 of defines a 5G Network Slice as:
a logical network that provides specific network capabilities and network characteristics, supporting various service properties for network slice customers.
Transport Network Slicing The term "Transport Network Slice" refers to a slice in the Transport Network domain of the 5G architecture. This section elaborates on how Transport Network Slicing is defined in the context of this document. It draws on the 3GPP definitions of "Transport Network" and "Network Slicing" in . The objective of Transport Network Slicing is to isolate, guarantee, or prioritize Transport Network resources for Slice Services. Examples of such resources include buffers, link capacity, or even Routing Information Base (RIB) and Forwarding Information Base (FIB). Transport Network Slicing provides various degrees of sharing of resources between slices (). For example, the network capacity can be shared by all slices, usually with a guaranteed minimum per slice, or each individual slice can be allocated dedicated network capacity. Parts of a given network may use the former, while others use the latter. For example, in order to satisfy local engineering guidelines and specific service requirements, shared TN resources could be provided in the backhaul (or midhaul), and dedicated TN resources could be provided in the midhaul (or backhaul). The capacity partitioning strategy is deployment specific. There are different components to implement Transport Network Slices based upon mechanisms such as Virtual Routing and Forwarding (VRF) instances for logical separation, QoS, and Traffic Engineering (TE). Whether all or a subset of these components are enabled is a deployment choice.
Transport Network Reference Design depicts the reference design used in this document for modeling the Transport Network based on management perimeters (customer vs. provider).
Reference Design with Customer Sites and Provider Network Customer Provider Customer Orchestration Orchestration Orchestration Domain Domain Domain Customer Provider Network Customer Site 1 Site 2 AC AC NF .... CE PE PE NF (CE) Transport Network Customer Provider Customer Orchestration Orchestration Orchestration Domain Domain Domain +----------------+ +---------------------+ +----------------+ | Customer | | Provider Network | | Customer | | Site 1 | | | | Site 2 | | +----+ | | +----+ +----+ | | +----+ | | +--+ | | | AC | | | | | | AC | | | | | |NF|....| CE +----------+ PE | | PE +-----------+ NF | | | +--+ | | | | | | | | | | | | | | +----+ | | +----+ +----+ | | +----+ | | | | | | (CE) | +----------------+ +---------------------+ +----------------+ <-----------------Transport Network--------------->
The description of the main components shown in is provided in the following subsections.
Customer Site (CS) On top of 5G NFs, a customer may manage additional TN elements (e.g., servers, routers, and switches) within a customer site. NFs may be hosted on a CE, directly connected to a CE, or located multiple IP hops from a CE. In some contexts, the connectivity between NFs that belong to the same site can be achieved via the provider network. The orchestration of the TN within a customer site involves a set of controllers for automation purposes (e.g., Network Function Virtualization Infrastructure (NFVI), Container Network Interface (CNI), Fabric Managers, or Public Cloud APIs). Documenting how these controllers are implemented is out of scope for this document.
Customer Edge (CE) A CE is a function that provides logical connectivity of a customer site () to the provider network (). The logical connectivity is enforced at Layer 2 and/or Layer 3 and is denominated an Attachment Circuit (AC) (). Examples of CEs include TN components (e.g., router, switch, and firewalls) and also 5G NFs (i.e., an element of the 5G domain such as Centralized Unit (CU), Distributed Unit (DU), or User Plane Function (UPF)). A CE is typically managed by the customer, but it can also be co-managed with the provider. A co-managed CE is orchestrated by both the customer and the provider. In this case, the customer and provider usually have control on distinct device configuration perimeters. A co-managed CE has both PE and CE functions, and there is no strict AC connection, although one may consider that the AC stitching logic happens internally within the CE itself. The provider manages the AC between the CE and the PE. This document generalizes the definition of a CE with the introduction of "distributed CE"; that is, the logical connectivity is realized by configuring multiple devices in the customer domain. The CE function is distributed. An example of distributed CE is the realization of an interconnection using an L3VPN service based on a distributed CE composed of a switch (SW) in Layer 2 and a router (RTR) in Layer 3, as shown in . Another example of distributed CE is shown in .
Example of Distributed CE Customer Provider Site Network AC PE RTR SW Distributed CE +--------------+ +--------------+ | Customer | | Provider | | Site | | Network | | +---------------+ | | | | | | | | | +---+ +----+ | +----+ | | | | | | ================== | | | | | +------------AC----------+ PE | | | | |RTR| | SW ================== | | | | +---+ +----+ | +----+ | | | | | | | +--Distributed--+ | | | CE | | | +--------------+ +--------------+
In most cases, CEs connect to PEs using IP (e.g., via Layer 3 VLAN subinterfaces), but a CE may also connect to the provider network using other technologies such as MPLS (potentially over IP tunnels) or Segment Routing over IPv6 (SRv6) . Thus, the CE has awareness of provider service configuration (e.g., control plane identifiers such as Route Targets (RTs) and Route Distinguishers (RDs)). However, the CE is still managed by the customer, and the AC is based on MPLS or SRv6 data plane technologies. The complete termination of the AC within the provider network may happen on distinct routers; this is another example of distributed PE. Service-aware CEs are used, for example, in the deployments discussed in Sections and .
Provider Network A provider uses a provider network to interconnect customer sites. This document assumes that the provider network is based on IP, MPLS, or both.
Provider Edge (PE) A PE is a device managed by a provider that is connected to a CE. The connectivity between a CE and a PE is achieved using one or multiple ACs (). This document generalizes the PE definition with the introduction of "distributed PE"; that is, the logical connectivity is realized by configuring multiple devices in the provider network (i.e., the Provider Orchestration Domain). The PE function is distributed. An example of a distributed PE is the "managed CE service". For example, a provider delivers VPN services using CEs and PEs that are both managed by the provider (example (i) in ). The managed CE can also be a Data Center Gateway as depicted in example (ii) of . A provider-managed CE may attach to CEs of multiple customers. However, this device is part of the provider network.
Examples of Distributed PE Customer Provider Site Network Mngd CE AC CE PE Distributed PE (i) Distributed PE Customer Provider Site Network IP Fabric DC AC GW PE .-. .-. .-. .-. '-' '-' '-' '-' Distributed Distributed CE PE Data Center- (ii) Distributed PE and CE +--------------+ +--------------+ | Customer | | Provider | | Site | | Network | | | +-----------------+ | | +----+ | +----+ +----+ | | | | ==================Mngd| | | | | | | CE +--------AC------+ CE +---+ PE | | | | | ================== | | | | | | +----+ | +----+ +----+ | | | | +---Distributed---+ | | | | PE | +--------------+ +--------------+ (i) Distributed PE +--------------+ +--------------+ | Customer | | Provider | | Site | | Network | | +-----------------+ +-----------------+ | | | IP Fabric | | +----+ +----+ | | | | +----+ +----+ ============= DC | | | | | | | '----' '----' +-----AC----+ GW +---+ PE | | | | | .-. .-. .-. .-. ============= | | | | | | | '-' '-' '-' '-' | | +----+ +----+ | | | +---Distributed---+ +---Distributed---+ | | CE | | PE | | | | | +--Data Center-+ +--------------+ (ii) Distributed PE and CE
In subsequent sections of this document, the terms "CE" and "PE" are used for both single and distributed devices.
Attachment Circuit (AC) The AC is the logical connection that attaches a CE () to a PE (). A CE is connected to a PE via one or multiple ACs. This document uses the concept of distributed CE and PE (Sections and ) to consolidate a CE/AC/PE definition that is consistent with the orchestration perimeters (). The CEs and PEs delimit the customer and provider orchestration domains, respectively, while an AC interconnects these domains. For consistency with the terminology used in AC data models (e.g., the data models defined in and ), this document assumes that an AC is configured on a "bearer", which represents the underlying connectivity. For example, the bearer is illustrated with "=" in Figures and . An AC is technology specific. Examples of ACs are VLAN ACs configured on a physical interface (bearer) or Overlay VXLAN EVI ACs configured on an IP underlay (bearer). Deployment cases where the AC is also managed by the provider are not discussed in this document because the setup of such an AC does not require any coordination between the customer and provider orchestration domains.
Orchestration Overview
5G End-to-End Slice Orchestration Architecture This section introduces a global framework for the orchestration of a 5G end-to-end slice (a.k.a. 5G Network Slice) with a zoom on TN parts. This framework helps to delimit the realization scope of RFC 9543 Network Slices and identify interactions that are required for the realization of such slices. This framework is consistent with the management coordination example shown in Figure 4.7.1 of . In , a 5G End-to-End Network Slice Orchestrator (5G NSO) is responsible for orchestrating 5G Network Slices end-to-end. The details of the 5G NSO are out of the scope of this document. The realization of the 5G Network Slices spans RAN, CN, and TN. As mentioned in , the RAN and CN are under the responsibility of the 3GPP management system, while the TN is not. The orchestration of the TN is split into two subdomains in conformance with the reference design in :
Provider Network Orchestration Domain (simply referred to as "Provider Orchestration Domain"):
As defined in , the provider relies on a Network Slice Controller (NSC) to manage and orchestrate RFC 9543 Network Slices in the provider network. This framework allows for managing connectivity with SLOs.
Customer Site Orchestration Domain (simply referred to as "Customer Orchestration Domain"):
The orchestration of TN elements of the customer sites relies upon a variety of controllers (e.g., Fabric Manager, Element Management System, or Virtualized Infrastructure Manager (VIM)).
A Transport Network Slice relies upon resources that can involve both the provider and customer TN domains. More details are provided in . A Transport Network Slice might be considered as a variant of horizontal composition of network slices mentioned in .
5G End-to-End Slice Orchestration with TN 5G NSO 3GPP domains Orchestration (RAN and CN) Transport Network Orchestration Customer Site RFC9543 NSC Customer Site Orchestration Orchestration Provider Network AC AC NF NF .... CE PE PE (CE) Customer Customer Site Site RFC 9543 | Network Slice | | Transport Network Slice | .---------. | 5G NSO | '-+---+---' | | v | .-------------. | | 3GPP domains | | .----------+ Orchestration +-)---------------------------. | | (RAN and CN) | | | | '-------------' | | | v | | .-----------------------------------------------. | | | Transport Network Orchestration | | | | +--------------+ +-----------+ +--------------+ | | | | |Customer Site | |RFC9543 NSC| |Customer Site | | | | | |Orchestration | | | |Orchestration | | | | | +--------------+ +-----------+ +--------------+ | | | '---|-------------------|---------------------|-' | | | | | | | | | | | | v v v | +--|----------+ +-----------------+ +-------|--+ | | | | Provider | | | | | v | +----+ Network +----+ +-----+ | | | +--+ +----+ AC | | | | AC | NF |<-+ | | |NF+....+ CE +------+ PE | | PE +------+ (CE)| | | +--+ +----+ | | | | +-----+ | | | +----+ +----+ | | | Customer | | | | Customer | | Site | | | | Site | +-------------+ +-----------------+ +----------+ RFC 9543 |-----Network Slice---| |-------------Transport Network Slice-----------|
The various orchestrations depicted in encompass the 3GPP's Network Slice Subnet Management Function (NSSMF) mentioned, for instance, in Figure 5 of .
Transport Network Segments and Network Slice Instantiation The concept of distributed PE () assimilates the CE-based SDPs defined in (i.e., Types 1 and 2) as SDP Types 3 or 4 in this document. In the architecture depicted in , the connectivity between NFs can be decomposed into three main segment types:
Customer Site:
Either connects NFs located in the same customer site or connects an NF to a CE. This segment may not be present if the NF is the CE. In this case, the AC connects the NF to a PE. The realization of this segment is driven by the 5G Network Orchestration (e.g., NF instantiation) and the Customer Site Orchestration for the TN part.
Provider Network:
Represents the connectivity between two PEs. The realization of this segment is controlled by an NSC ().
Attachment Circuit:
The orchestration of this segment relies partially upon an NSC for the configuration of the AC on the PE customer-facing interfaces and the Customer Site Orchestration for the configuration of the AC on the CE. PEs and CEs that are connected via an AC need to be provisioned with consistent data plane and control plane information (VLAN IDs, IP addresses/subnets, BGP Autonomous System Number (ASN), etc.). Hence, the realization of this interconnection is technology specific and requires coordination between the Customer Site Orchestration and an NSC. Automating the provisioning and management of the AC is thus key to automate the overall service provisioning. Aligned with , this document assumes that this coordination is based upon standard YANG data models and APIs. The provisioning of an RFC 9543 Network Slice may rely on new or existing ACs. is a basic example of a Layer 3 CE-PE link realization with shared network resources (such as VLAN IDs and IP prefixes), which are passed between orchestrators via a dedicated interface, e.g., the Network Slice Service Model (NSSM) or Attachment Circuits as a Service (ACaaS) .
Coordination of Transport Network Resources for AC Provisioning RFC 9543 NSC Customer Site Orchestration IETF APIs/DM (Provider Network Orchestration) - - .1 192.0.2.0/31 .0 NF ..... CE PE VLAN 100 Customer Provider Site Network | AC | .-------------. .----------------. | | | RFC 9543 NSC | | Customer Site | | | | Orchestration | IETF APIs/DM |(Provider Network | | |<----------------->| Orchestration) | '-------------' '----------------' | | | | +---------------|-+ +-|---------------+ | v | | v | | +--+ +--+ .1| 192.0.2.0/31 |.0+--+ | | |NF+.....+CE+---------------------------+PE| | | +--+ +--+ | VLAN 100 | +--+ | | Customer | | Provider | | Site | | Network | +-----------------+ +-----------------+ |----------- AC -----------|
Mapping 5G Network Slices to Transport Network Slices There are multiple options for mapping 5G Network Slices to Transport Network Slices:
1-to-N mapping:
A single 5G Network Slice can be mapped to multiple Transport Network Slices. For instance, consider the scenario depicted in , which illustrates the separation of the 5G control plane and user plane in Transport Network Slices for a single 5G Enhanced Mobile Broadband (eMBB) network slice. It is important to note that this mapping can serve as an interim step to M-to-N mapping. Further details about this scheme are described in .
M-to-1 mapping:
Multiple 5G Network Slices may rely upon the same Transport Network Slice. In such a case, the Service Level Agreement (SLA) differentiation of slices would be entirely controlled at the 5G control plane, for example, with appropriate placement strategies. This use case is illustrated in , where a UPF for the Ultra-Reliable Low-Latency Communication (URLLC) slice is instantiated at the edge cloud, close to the gNB CU-UP, to improve latency and jitter control. The 5G control plane and the UPF for the eMBB slice are instantiated in the regional cloud.
M-to-N mapping:
The mapping of 5G to Transport Network Slice combines both approaches with a mix of shared and dedicated associations. In this scenario, a subset of the Transport Network Slices can be intended for sharing by multiple 5G Network Slices (e.g., the control plane Transport Network Slice is shared by multiple 5G Network Slices). In practice, for operational and scaling reasons, M-to-N mapping would typically be used, with M much greater than N.
1-to-N Mapping (Single 5G Network Slice to Multiple Transport Network Slices) 5G Network Slice eMBB N3 N3 CU-UP Transport Network Slice UP_eMBB UPF N2 N2 CU-CP Transport Network Slice CP AMF Transport Network +---------------------------------------------------------------+ | 5G Network Slice eMBB | | +------------------------------------+ | | +-----+ N3 | +--------------------------------+ | N3 +-----+ | | |CU-UP+------+Transport Network Slice UP_eMBB +-------+ UPF | | | +-----+ | +--------------------------------+ | +-----+ | | | | | | +-----+ N2 | +--------------------------------+ | N2 +-----+ | | |CU-CP+------+ Transport Network Slice CP +-------+ AMF | | | +-----+ | +--------------------------------+ | +-----+ | +------------|------------------------------------|-------------+ | | | Transport Network | +------------------------------------+
M-to-1 Mapping (Multiple 5G Network Slices to Single Transport Network Slice) Edge Cloud UPF_URLLC Cell Site Regional Cloud CU-UP_URLLC Transport Network Slice ALL 5GC CP CU-UP_eMBB UPF_eMBB Transport Network +-------------+ | Edge Cloud | | +---------+ | | |UPF_URLLC| | | +-----+---+ | | | | +-------|-----+ | +---------------+ +-------|----------------------+ | | | | | | Cell Site | | +-----+--------------------+ | +--------------+ | | | | | | | Regional | | +-----------+ | | | | | | Cloud | | |CU-UP_URLLC+-----+ Transport Network | | | +----------+ | | +-----------+ | | | Slice ALL +-----+ 5GC CP | | | | | | | | | +----------+ | | +-----------+ | | | | | | | | |CU-UP_eMBB +-----+ | | | +----------+ | | +-----------+ | | | +-----+ UPF_eMBB | | +---------------+ | | | | | +----------+ | | +--------------------------+ | | | | | +--------------+ | Transport Network | +------------------------------+
Note that the actual realization of the mapping depends on several factors, such as the actual business cases, the NF vendor capabilities, the NF vendor reference designs, as well as service provider or even legal requirements. Mapping approaches that preserve the 5G Network Slice identification in the TN (e.g., the approach in ) may simplify required operations to map Transport Network Slices back to 5G Network Slices. However, such considerations are not detailed in this document because these are under the responsibility of the 3GPP orchestration.
First 5G Network Slice Versus Subsequent Slices An operational 5G Network Slice incorporates both 5G control plane and user plane capabilities. For instance, in some deployments, in the case of a slice based on split CU in the RAN, both CU-UP and CU-CP may need to be deployed along with the associated interfaces E1, F1-c, F1-u, N2, and N3, which are conveyed in the TN. In this regard, the creation of the "first slice" can be subject to a specific logic that does not apply to subsequent slices. Let us consider the example depicted in to illustrate this deployment. In this example, the first 5G Network Slice relies on the deployment of NF-CP and NF-UP functions together with two Transport Network Slices for the control and user planes (TNS-CP and TNS-UP1). Next, in many cases, the deployment of a second slice relies solely on the instantiation of a UPF (NF-UP2) together with a dedicated Transport Network Slice for the user plane (TNS-UP2). The control plane of the first 5G Network Slice is also updated to integrate the second slice; the Transport Network Slice (TNS-CP) and Network Functions (NF-CP) are shared. The model described here, in which the control plane is shared among multiple slices, is likely to be common; it is not mandatory, though. Deployment models with a separate control plane for each slice are also possible. Section 6.1.2 of specifies that the eMBB slice (SST=1 and no Slice Differentiator (SD)) should be supported globally. This 5G Network Slice would be the first slice in any 5G deployment.
First and Subsequent Slice Deployment (1) Deployment of first 5G Network Slice First 5G Network Slice NF-CP TNS-CP NF-CP NF-UP TNS-UP1 NF-UP Transport Network (2) Deployment of additional 5G Network Slice with shared Control Plane First 5G Network Slice NF-CP TNS-CP NF-CP SHARED (SHARED) SHARED NF-UP TNS-UP1 NF-UP Transport Network NF-UP2 TNS-UP2 NF-UP2 Second 5G Network Slice (1) Deployment of first 5G Network Slice +---------------------------------------------------------------+ | First 5G Network Slice | | | | +------------------------------+ | | +-----+ | +--------------------------+ | +-----+ | | |NF-CP+------+ TNS-CP +------+NF-CP| | | +-----+ | +--------------------------+ | +-----+ | | | | | | +-----+ | +--------------------------+ | +-----+ | | |NF-UP+------+ TNS-UP1 +------+NF-UP| | | +-----+ | +--------------------------+ | +-----+ | +----------------|------------------------------|---------------+ | | | Transport Network | +------------------------------+ (2) Deployment of additional 5G Network Slice with shared Control Plane +---------------------------------------------------------------+ | First 5G Network Slice | | | | +------------------------------+ | | +-----+ | +--------------------------+ | +-----+ | | |NF-CP+------+ TNS-CP +------+NF-CP| | | +-----+ | +--------------------------+ | +-----+ | | SHARED | (SHARED) | SHARED | | | | | | +-----+ | +--------------------------+ | +-----+ | | |NF-UP+------+ TNS-UP1 +------+NF-UP| | | +-----+ | +--------------------------+ | +-----+ | +----------------|------------------------------|---------------+ | | | Transport Network | | | +----------------|------------------------------|---------------+ | | | | | +------+ | +--------------------------+ | +------+ | | |NF-UP2+-----+ TNS-UP2 +-----+NF-UP2| | | +------+ | +--------------------------+ | +------+ | | | | | | +------------------------------+ | | | | Second 5G Network Slice | +---------------------------------------------------------------+
Transport Network Slice mapping policies can be enforced by an operator (e.g., provided to a TN Orchestration or 5G NSO) to determine whether existing Transport Network Slices can be reused for handling a new Slice Service creation request. Providing such a policy is meant to better automate the realization of 5G Network Slices and minimize the realization delay that might be induced by extra cycles to seek for operator validation.
Overview of the Transport Network Realization Model The realization model described in this document is depicted in . The following building blocks are used:
  • L2VPN and/or L3VPN service instances for logical separation: This realization model of transport for 5G Network Slices assumes Layer 3 delivery for midhaul and backhaul transport connections and a Layer 2 or Layer 3 delivery for fronthaul connections. Enhanced Common Public Radio Interface (eCPRI) supports both delivery models. L2VPN/L3VPN service instances might be used as a basic form of logical slice separation. Furthermore, using service instances results in an additional outer header (as packets are encapsulated/decapsulated at the nodes hosting service instances), providing clean discrimination between 5G QoS and TN QoS, as explained in . Note that a variety of L2VPN mechanisms can be considered for slice realization. A non-comprehensive list is provided below:
    • Virtual Private LAN Service (VPLS)
    • Virtual Private Wire Service (VPWS) ()
    • Various flavors of EVPNs:
      • VPWS EVPN ,
      • Provider Backbone Bridging combined with EVPN (PBB-EVPN) ,
      • EVPN over MPLS , and
      • EVPN over Virtual Extensible LAN (VXLAN) .
    The use of VPNs for realizing network slices is briefly described in .
  • Fine-grained resource control at the PE: This is sometimes called "admission control" or "traffic conditioning". The main purpose is the enforcement of the bandwidth contract for the slice right at the edge of the provider network where the traffic is handed off between the customer site and the provider network. The method used here is granular ingress policing (rate limiting) to enforce contracted bandwidths per slice and, potentially, per traffic class within the slice. Traffic above the enforced rate might be immediately dropped or marked as high drop-probability traffic, which is more likely to be dropped somewhere inside the provider network if congestion occurs. In the egress direction at the PE node, hierarchical schedulers/shapers can be deployed, providing guaranteed rates per slice, as well as guarantees per traffic class within each slice. For managed CEs, edge admission control can be distributed between CEs and PEs, where part of the admission control is implemented on the CE and the other part on the PE.
  • Coarse-grained resource control at the transit links (non-attachment circuits) in the provider network, using a single NRP (called "base NRP" in ), spanning the entire provider network. Transit nodes in the provider network do not maintain any state of individual slices. Instead, only a flat (non-hierarchical) QoS model is used on transit links in the provider network, with up to 8 traffic classes. At the PE, traffic flows from multiple Slice Services are mapped to the limited number of traffic classes used on transit links in the provider network.
  • Capacity planning/management for efficient usage of provider network resources: The role of capacity planning/management is to ensure the provider network capacity can be utilized without causing any bottlenecks. The methods used here can range from careful network planning that ensures a more or less equal traffic distribution (i.e., equal-cost load balancing) to advanced TE techniques, with or without bandwidth reservations, that force more consistent load distribution, even in non-ECMP-friendly network topologies. See also .
Resource Allocation Slicing Model with a Single NRP .............................................. : Base NRP : : : PE : : PE -- -- - -- -- -- - -- -- -- -- -- -- -- -- -- -- -- -- -- -- N S # P P 1 == == N S # 2 -- -- - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- : : : : : : '..............................................' SDP, with fine-grained QoS (dedicated resources per network slice) Coarse-grained QoS, with resources shared by all network slices ... Base NRP -- -- Network slice .............................................. : Base NRP : +-----:----+ +----:-----+ | PE : | | : PE | -- -- |- -- -- --| - -- -- -- -- -- -- -- -- -- -- -- | -- -- -- | N *<---+ | | +--->* S | | | +-----+ +-----+ | | | # *<---+ | | P | | P | | +--->* 1 | | | | | | | | | | == == | +---->o<----->o<--->o<------>o<--->o<----->o<----+ | N | | | | | | | | | | S *<---+ | | | | | | +--->* # | | | +-----+ +-----+ | | | 2 *<---+ | | +--->* -- -- |- -- -- --|-- -- -- -- -- -- -- -- -- -- -- -- | -- -- -- | | : | | : | +-----:----+ +----:-----+ : : '..............................................' * SDP, with fine-grained QoS (dedicated resources per network slice) o Coarse-grained QoS, with resources shared by all network slices ... Base NRP -- -- Network slice
The P nodes shown in are routers that do not interface with customer devices. See . This document does not describe in detail how to manage an L2VPN or L3VPN, as this is already well-documented. For example, the reader may refer to and for such details.
Handoff Between Domains The 5G control plane relies upon 32-bit S-NSSAIs for slice identification. The S-NSSAI is not visible to the transport domain. So instead, 5G network functions can expose the 5G Network Slices to the transport domain by mapping to explicit Layer 2 or Layer 3 identifiers, such as VLAN-IDs, IP addresses, or Differentiated Services Code Point (DSCP) values. The following subsections list a few handoff methods for slice mapping between customer sites and provider networks. More details about the mapping between 3GPP and RFC 9543 Network Slices is provided in .
VLAN Handoff In this option, the RFC 9543 Network Slice, fulfilling connectivity requirements between NFs that belong to a 5G Network Slice, is represented at an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in .
Example of 5G Network Slice with VLAN Handoff Providing End-to-End Connectivity VLANs representing slices VLANs representing slices Provider x x x x x.......x NF x x PE PE x xL2/L3x.......x NF x x x x x.......x AC Network AC x Logical interface represented by a VLAN on a physical interface SDP VLANs representing slices VLANs representing slices | +-------------------+ | | | | | | | +------+ | +-+----+ Provider +---+--+ | +-----+ | +------+ | | v | | | | v | | v | | | x------x * | | * x------x x.......x | | NF x------x * PE | | PE * x------xL2/L3x.......x NF | | x------x * | | * x------x x.......x | | | | | | | | | | | +------+ AC +--+---+ Network +---+--+ AC +-----+ +------+ | | +------------------+ x Logical interface represented by a VLAN on a physical interface * SDP
Each VLAN represents a distinct logical interface on the ACs and hence provides the possibility to place these logical interfaces in distinct Layer 2 or Layer 3 service instances and implement separation between slices via service instances. Since the 5G interfaces are IP-based interfaces (with the exception of the F2 fronthaul interface, where eCPRI with Ethernet encapsulation is used), this VLAN is typically not transported across the provider network. Typically, it has only local significance at a particular SDP. For simplification, a deployment may rely on the same VLAN identifier for all ACs. However, that may not be always possible. As such, SDPs for the same slice at different locations may use different VLAN values. Therefore, a table mapping VLANs to RFC 9543 Network Slices is maintained for each AC, and the VLAN allocation is coordinated between customer orchestration and provider orchestration. While VLAN handoff is simple for NFs, it adds complexity at the provider network because of the requirement of maintaining mapping tables for each SDP and performing a configuration task for new VLANs and IP subnet for every slice on every AC.
IP Handoff In this option, an explicit mapping between source/destination IP addresses and a slice's specific S-NSSAI is used. The mapping can have either local (e.g., pertaining to a single NF attachment) or global TN significance. The mapping can be realized in multiple ways, including (but not limited to):
  • S-NSSAI to a dedicated IP address for each NF
  • S-NSSAI to a pool of IP addresses for global TN deployment
  • S-NSSAI to a subset of bits of an IP address
  • S-NSSAI to a DSCP value
  • S-NSSAI to SRv6 Locators or Segment Identifiers (SIDs)
  • Use of a deterministic algorithm to map S-NSSAI to an IP subnet, prefix, or pools. For example, adaptations to the algorithm defined in may be considered.
Mapping S-NSSAIs to IP addresses makes IP addresses an identifier for slice-related policy enforcement in the Transport Network (e.g., differentiated services, traffic steering, bandwidth allocation, security policies, and monitoring). One example of the IP handoff realization is the arrangement in which the slices in the TN domain are instantiated using IP tunnels (e.g., IPsec or GTP-U tunnels) established between NFs, as depicted in . The transport for a single 5G Network Slice might be constructed with multiple such tunnels, since a typical 5G Network Slice contains many NFs, especially DUs and CUs. If a shared NF (i.e., an NF that serves multiple slices, such as a shared DU) is deployed, multiple tunnels from the shared NF are established, each tunnel representing a single slice.
Example of 5G Network Slice with IP Handoff Providing End-to-End Connectivity Tunnels representing slices Provider NF PE | | PE L2/L3+.......+ NF AC Network AC Tunnel (IPsec, GTP-U, etc.) termination point SDP Tunnels representing slices +------------------+ | | | | +------+ +-+---+ Provider +---+-+ +-----+ | +------+ | | | | | | | | v | | | o============*================*==========================o | | NF +-------+ PE | | PE +-------+L2/L3+.......+ NF | | o============*================*==========================o | | | | | | | | | | | +------+ AC +-+---+ Network +---+-+ AC +-----+ +------+ | | +------------------+ o Tunnel (IPsec, GTP-U, etc.) termination point * SDP
As opposed to the VLAN handoff case (), there is no logical interface representing a slice on the PE; hence, all slices are handled within a single service instance. The IP and VLAN handoffs are not mutually exclusive but instead could be used concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping table similar to the VLAN handoff solution is needed (). The mapping table can be simplified if, for example, IPv6 addressing is used to address NFs. An IPv6 address is a 128-bit field, while the S-NSSAI is a 32-bit field: The Slice/Service Type (SST) is 8 bits, and the Slice Differentiator (SD) is 24 bits. Out of the 128 bits of the IPv6 address, 32 bits may be used to encode the S-NSSAI, which makes an IP-to-slice mapping table unnecessary. The S-NSSAI/IPv6 mapping is a local IPv6 address allocation method to NFs not disclosed to on-path nodes. IP forwarding is not altered by this method and is still achieved following BCP 198 . Intermediary TN nodes are not required to associate any additional semantic with the IPv6 address. However, operators using such mapping methods should be aware of the implications of any change of S-NSSAI on the IPv6 addressing plans. For example, modifications of the S-NSSAIs in use will require updating the IP addresses used by NFs involved in the associated slices. An example of a local IPv6 addressing plan for NFs is provided in .
MPLS Label Handoff In this option, the service instances representing different slices are created directly on the NF, or within the customer site hosting the NF, and attached to the provider network. Therefore, the packet is encapsulated outside the provider network with MPLS encapsulation or MPLS-in-UDP encapsulation , depending on the capability of the customer site, with the service label depicting the slice. There are three major methods (based upon ) for interconnecting MPLS services over multiple service domains:
Option A ():
VRF-to-VRF connections.
Option B ():
Redistribution of labeled VPN routes with next-hop change at domain boundaries.
Option C ():
Redistribution of labeled VPN routes without next-hop change and redistribution of labeled transport routes with next-hop change at domain boundaries.
illustrates the use of service-aware CE () for the deployment discussed in Sections and .
Example of MPLS-Based Attachment Circuit Customer Provider Site Network MP-BGP MPLS-based AC CE PE VRF foo +--------------+ +--------------+ | Customer | | Provider | | Site | | Network | | | | | | | | | | | <------MP-BGP-----> | | | +--+-+ +-+--+ | | | | MPLS-based AC | | | | | CE +------------------+ PE | | | +--+----+--+ | | | | | VRF foo | +-+--+ | +--------+----------+ +--------------+
Option A This option is based on the VLAN handoff, described in ; it is not based on the MPLS label handoff.
Option B In this option, L3VPN service instances are instantiated outside the provider network. These L3VPN service instances are instantiated in the customer site, which could be, for example, either on the compute that hosts mobile NFs (, left-hand side) or within the DC/cloud infrastructure itself (e.g., on the top of the rack or leaf switch within cloud IP fabric (, right-hand side)). On the AC connected to a PE, packets are already MPLS encapsulated (or MPLS-in-UDP/MPLS-in-IP encapsulated, if cloud or compute infrastructure don't support MPLS encapsulation). Therefore, the PE uses neither a VLAN nor an IP address for slice identification at the SDP but instead uses the MPLS label.
Example of MPLS Handoff with Option B BGP VPN BGP VPN BGP VPN COM=1, L=A" COM=1, L=A' COM=1, L=A COM=2, L=B" COM=2, L=B' COM=2, L=B COM=3, L=C" COM=3, L=C' COM=3, L=C nhs nhs nhs nhs VLANs service instances service instances representing representing slices representing slices slices - Provider - # #<><>x......x NF # PE PE #<><>x......x NF # AC AC #<><>x......x CS1 Network L2/L3 CS2 x Logical interface represented by a VLAN on a physical interface # Service instances (with unique MPLS labels) SDP <------ <------ <------ BGP VPN BGP VPN BGP VPN COM=1, L=A" COM=1, L=A' COM=1, L=A COM=2, L=B" COM=2, L=B' COM=2, L=B COM=3, L=C" COM=3, L=C' COM=3, L=C <-----------><-------------><------------> nhs nhs nhs nhs VLANs service instances service instances representing representing slices representing slices slices | | | +---+ | +-------------+ +-|--------|----------+ | | | | Provider | | | | | | +-+--v-+ +--+--+ +--+--+ +-+-v----+ v +-----+ | | | # | | * | | * | | #<><>x......x | | | | NF # +------+ * PE| |PE * +------+ #<><>x......x NF | | | | # | AC | * | | * | AC | #<><>x......x | | | +--+---+ +--+--+ +--+--+ +-+------+ +-----+ | | CS1| | Network | | L2/L3 CS2 | +----+ +-------------+ +---------------------+ x Logical interface represented by a VLAN on a physical interface # Service instances (with unique MPLS labels) * SDP
MPLS labels are allocated dynamically in Option B deployments, where, at the domain boundaries, service prefixes are reflected with next-hop self (nhs), and a new label is dynamically allocated, as shown in (e.g., labels A, A', and A" for the first depicted slice). Therefore, for any slice-specific per-hop behavior at the provider network edge, the PE needs to determine which label represents which slice. In the BGP control plane, when exchanging service prefixes over an AC, each slice might be represented by a unique BGP community, so tracking label assignment to the slice might be possible. For example, in , for the slice identified with COM=1, the PE advertises a dynamically allocated label A". Since, based on the community, the label-to-slice association is known, the PE can use this dynamically allocated label A" to identify incoming packets as belonging to "slice 1" and execute appropriate edge per-hop behavior. It is worth noting that slice identification in the BGP control plane might be with per-prefix granularity. In the extreme case, each prefix can have a different community representing a different slice. Depending on the business requirements, each slice could be represented by a different service instance as outlined in . In that case, the route target extended community () might be used as a slice differentiator. In other deployments, all prefixes (representing different slices) might be handled by a single "mobile" service instance, and some other BGP attribute (e.g., a standard community ) might be used for slice differentiation. There could also be a deployment option that groups multiple slices together into a single service instance, resulting in a handful of service instances. In any case, fine-grained per-hop behavior at the edge of provider network is possible.
Option C Option B relies upon exchanging service prefixes between customer sites and the provider network. This may lead to scaling challenges in large-scale 5G deployments as the PE node needs to carry all service prefixes. To alleviate this scaling challenge, in Option C, service prefixes are exchanged between customer sites only. In doing so, the provider network is offloaded from carrying, propagating, and programming appropriate forwarding entries for service prefixes. Option C relies upon exchanging service prefixes via multi-hop BGP sessions between customer sites, without changing the NEXT_HOP BGP attribute. Additionally, IPv4/IPv6 labeled unicast (SAFI-4) host routes, used as NEXT_HOP for service prefixes, are exchanged via direct single-hop BGP sessions between adjacent nodes in a customer site and a provider network, as depicted in . As a result, a node in a customer site performs hierarchical next-hop resolution.
Example of MPLS Handoff with Option C BGP VPN COM=1, L=A, NEXT_HOP=CS2 COM=2, L=B, NEXT_HOP=CS2 COM=3, L=C, NEXT_HOP=CS2 BGP LU BGP LU BGP LU CS2, L=X" CS2, L=X' CS2, L=X nhs nhs nhs nhs VLANs service instances service instances representing representing slices representing slices slices - Provider - # #<><>x......x NF # PE PE #<><>x......x NF # AC AC #<><>x......x CS1 Network L2/L3 CS2 x Logical interface represented by a VLAN on a physical interface # Service instances (with unique MPLS label) SDP <---------------------------------------- BGP VPN COM=1, L=A, NEXT_HOP=CS2 COM=2, L=B, NEXT_HOP=CS2 COM=3, L=C, NEXT_HOP=CS2 <---------------------------------------> <------ <------ <------ BGP LU BGP LU BGP LU CS2, L=X" CS2, L=X' CS2, L=X <-----------><--------------><----------> nhs nhs nhs nhs VLANs service instances service instances representing representing slices representing slices slices | | | +---+ | +-------------+ +-|--------|----------+ | | | | Provider | | | | | | +-+-v-+ +--+--+ +--+--+ +-+-v----+ v +-----+ | | | # | | * | | * | | #<><>x......x | | | |NF # +-------+ * PE| |PE * +------+ #<><>x......x NF | | | | # | AC | * | | * | AC | #<><>x......x | | | +--+--+ +--+--+ +--+--+ +-+------+ +-----+ | | CS1| | Network | | L2/L3 CS2 | +----+ +-------------+ +---------------------+ x Logical interface represented by a VLAN on a physical interface # Service instances (with unique MPLS label) * SDP
This architecture requires an end-to-end Label Switched Path (LSP) leading from a packet's ingress node inside one customer site to its egress inside another customer site, through a provider network. Hence, at the domain (customer site and provider network) boundaries, the NEXT_HOP attribute for IPv4/IPv6 labeled unicast needs to be modified to next-hop self (nhs), which results in a new IPv4/IPv6 labeled unicast label allocation. Appropriate forwarding entries for label swaps for IPv4/IPv6 labeled unicast labels are programmed in the data plane. There is no additional "labeled transport" protocol on the AC (e.g., no LDP, RSVP, or SR). Packets are transmitted over the AC with the IPv4/IPv6 labeled unicast as the top label, with the service label deeper in the label stack. In Option C, the service label is not used for forwarding lookup on the PE. This significantly lowers the scaling pressure on PEs, as PEs need to program forwarding entries only for IPv4/IPv6 labeled unicast host routes, which are used as NEXT_HOP for service prefixes. Also, since one IPv4/IPv6 labeled unicast host route represents one customer site, regardless of the number of slices in the customer site, the number of forwarding entries on a PE is considerably reduced. For any slice-specific per-hop behavior at the provider network edge, as described in detail in , the PE needs to determine which label in the packet represents which slice. This can be achieved, for example, by allocating non-overlapping service label ranges for each slice and using those ranges for slice identification purposes on the PE.
QoS Mapping Realization Models
QoS Layers The resources are managed via various QoS policies deployed in the network. QoS mapping models to support 5G slicing connectivity implemented over a packet switched provider network use two layers of QoS, which are discussed in the following subsections.
5G QoS Layer QoS treatment is indicated in the 5G QoS layer by the 5G QoS Indicator (5QI), as defined in . The 5QI is an identifier that is used as a reference to 5G QoS characteristics (e.g., scheduling weights, admission thresholds, queue management thresholds, and link-layer protocol configuration) in the RAN domain. Given that 5QI applies to the RAN domain, it is not visible to the provider network. Therefore, if 5QI-aware treatment is desired in the provider network, 5G network functions might set DSCP with a value representing 5QI so that differentiated treatment can be implemented in the provider network as well. Based on these DSCP values, very granular QoS enforcement might be implemented at the SDP of each provider network segment used to construct transport for given 5G Network Slice. The exact mapping between 5QI and DSCP is out of scope for this document. Mapping recommendations are documented, e.g., in . Each Slice Service might have flows with multiple 5QIs. 5QIs (or, more precisely, corresponding DSCP values) are visible to the provider network at SDPs (i.e., at the edge of the provider network). In this document, this layer of QoS is referred to as "5G QoS Class" ("5G QoS" in short) or "5G DSCP".
Transport Network (TN) QoS Layer Control of the TN resources and traffic scheduling/prioritization on provider network transit links are based on a flat (non-hierarchical) QoS model in this network slice realization. That is, RFC 9543 Network Slices are assigned dedicated resources (e.g., QoS queues) at the edge of the provider network (at SDPs), while all RFC 9543 Network Slices are sharing resources (sharing QoS queues) on the transit links of the provider network. Typical router hardware can support up to 8 traffic queues per port; therefore, this document assumes support for 8 traffic queues per port in general. At this layer, QoS treatment is indicated by a QoS indicator specific to the encapsulation used in the provider network. Such an indicator may be a DSCP or MPLS Traffic Class (TC). This layer of QoS is referred to as "TN QoS Class" ("TN QoS" for short) in this document.
QoS Realization Models While 5QI might be exposed to the provider network via the DSCP value (corresponding to a specific 5QI value) set in the IP packet generated by NFs, some 5G deployments might use 5QI in the RAN domain only, without requesting per-5QI differentiated treatment from the provider network. This might be due to an NF limitation (e.g., no capability to set DSCP), or it might simply depend on the overall slicing deployment model. The O-RAN Alliance, for example, defines a phased approach to the slicing, with initial phases utilizing only per-slice, but not per-5QI, differentiated treatment in the TN domain (see Annex F of ). Therefore, from a QoS perspective, the 5G slicing connectivity realization defines two high-level realization models for slicing in the TN domain: a 5QI-unaware model and a 5QI-aware model. Both slicing models in the TN domain could be used concurrently within the same 5G Network Slice. For example, the TN segment for 5G midhaul (F1-U interface) might be 5QI-aware, while at the same time, the TN segment for 5G backhaul (N3 interface) might follow the 5QI-unaware model. These models are further elaborated in the following two subsections.
5QI-Unaware Model In the 5QI-unaware model, the DSCP values in the packets received from NF at SDP are ignored. In the provider network, there is no QoS differentiation at the 5G QoS Class level. The entire RFC 9543 Network Slice is mapped to a single TN QoS Class and therefore to a single QoS queue on the routers in the provider network. With a low number of deployed 5G Network Slices (for example, only two 5G Network Slices: eMBB and MIoT), it is possible to dedicate a separate QoS queue for each slice on transit routers in the provider network. However, with the introduction of private/enterprises slices, as the number of 5G Network Slices (and thus the corresponding RFC 9543 Network Slices) increases, a single QoS queue on transit links in the provider network serves multiple slices with similar characteristics. QoS enforcement on transit links is fully coarse-grained (single NRP, sharing resources among all RFC 9543 Network Slices), as displayed in .
Mapping of Slice to TN QoS (5QI-Unaware Model) PE SDP Transit link NS 1 TN QoS Class 1 SDP TN QoS Class 2 NS 2 TN QoS Class 3 SDP TN QoS Class 4 NS 3 TN QoS Class 5 SDP TN QoS Class 6 NS 4 TN QoS Class 7 SDP TN QoS Class 8 NS 5 Max 8 TN Classes Fine-grained QoS enforcement Coarse-grained QoS enforcement (dedicated resources per (resources shared by multiple RFC 9543 Network Slice) RFC 9543 Network Slices) +----------------------------------------------------------------+ +-------------------. PE | | .--------------+ | | | | SDP | | .------------------------------+ | | +----------+ | | | Transit link | | | | NS 1 +-------------+ | .------------------------. | | | +----------+ | | +-----|--> TN QoS Class 1 | | | '--------------' | | | '------------------------' | | .--------------+ | | | .------------------------. | | | SDP | | | | | TN QoS Class 2 | | | | +----------+ | | | | '------------------------' | | | | NS 2 +---------+ | | .------------------------. | | | +----------+ | | | | | | TN QoS Class 3 | | | '--------------' | | | | '------------------------' | | .--------------+ | | | | .------------------------. | | | SDP | | +---)-----|--> TN QoS Class 4 | | | | +----------+ | | | | '------------------------' | | | | NS 3 +-------------+ | .------------------------. | | | +----------+ | | +---------|--> TN QoS Class 5 | | | '--------------' | | | '------------------------' | | .--------------+ | | | .------------------------. | | | SDP | | | | | TN QoS Class 6 | | | | +----------+ | | | | '------------------------' | | | | NS 4 +---------+ | .------------------------. | | | +----------+ | | | | | TN QoS Class 7 | | | '--------------' | | | '------------------------' | | .--------------+ | | | .------------------------. | | | SDP | | | | | TN QoS Class 8 | | | | +----------+ | | | | '------------------------' | | | | NS 5 +---------+ | Max 8 TN Classes | | | +----------+ | | '------------------------------+ | '--------------' | | +-------------------' | +----------------------------------------------------------------+ Fine-grained QoS enforcement Coarse-grained QoS enforcement (dedicated resources per (resources shared by multiple RFC 9543 Network Slice) RFC 9543 Network Slices)
When the IP traffic is handed over at the SDP from the AC to the provider network, the PE encapsulates the traffic into MPLS (if MPLS transport is used in the provider network) or IPv6, optionally with some additional headers (if SRv6 transport is used in the provider network), and sends out the packets on the provider network transit link. The original IP header retains the DSCP marking (which is ignored in the 5QI-unaware model), while the new header (MPLS or IPv6) carries the QoS marking (MPLS Traffic Class bits for MPLS encapsulation or DSCP for SRv6/IPv6 encapsulation) related to the TN Class of Service (CoS). Based on the TN CoS marking, per-hop behavior for all RFC 9543 Network Slices is executed on provider network transit links. Provider network transit routers do not evaluate the original IP header for QoS-related decisions. This model is outlined in for MPLS encapsulation and in for SRv6 encapsulation.
QoS with MPLS Encapsulation MPLS Header Label TN TC - - - - - - - - IP Header IP Header 5G DSCP 5G DSCP Payload Payload (GTP-U/IPsec) (GTP-U/IPsec) - - - - - - - - +--------------+ | MPLS Header | +-----+-----+ | |Label|TN TC| | +--------------+ - - - - - - - - +-----+-----+--+ | IP Header | |\ | IP Header | | +-------+ | \ | +-------+ | |5G DSCP|---------+ \ | |5G DSCP| +------+-------+ \ +------+-------+ | | \ | | | | \ | | | | | | | Payload | / | Payload | |(GTP-U/IPsec) | / |(GTP-U/IPsec) | | | / | | | |---------+ / | | | | | / | | | | |/ | | +--------------+ - - - - - - - - +--------------+
QoS with SRv6 Encapsulation IPv6 Header TN DSCP : Optional : : IPv6 : : Headers : - - - - - - - - IP Header IP Header 5G DSCP 5G DSCP Payload Payload (GTP-U/IPsec) (GTP-U/IPsec) - - - - - - - - +--------------+ | IPv6 Header | | +-------+ | |TN DSCP| +------+-------+ : Optional : : IPv6 : : Headers : +--------------+ - - - - - - - - +-----+-----+--+ | IP Header | |\ | IP Header | | +-------+ | \ | +-------+ | |5G DSCP|---------+ \ | |5G DSCP| +------+-------+ \ +------+-------+ | | \ | | | | \ | | | | | | | Payload | / | Payload | |(GTP-U/IPsec) | / |(GTP-U/IPsec) | | | / | | | |---------+ / | | | | | / | | | | |/ | | +--------------+ - - - - - - - - +--------------+
From a QoS perspective, both options are similar. However, there is one difference between the two options. The MPLS TC is only 3 bits (8 possible combinations), while DSCP is 6 bits (64 possible combinations). Hence, SRv6 provides more flexibility for TN CoS design, especially in combination with soft policing with in-profile and out-of-profile traffic, as discussed in . Provider network edge resources are controlled in a fine-grained manner, with dedicated resource allocation for each RFC 9543 Network Slice. Resource control and enforcement happens at each SDP in two directions: inbound and outbound.
Inbound Edge Resource Control The main aspect of inbound provider network edge resource control is per-slice traffic volume enforcement. This kind of enforcement is often called "admission control" or "traffic conditioning". The goal of this inbound enforcement is to ensure that the traffic above the contracted rate is dropped or deprioritized, depending on the business rules, right at the edge of provider network. This, combined with appropriate network capacity planning/management (), is required to ensure proper isolation between slices in a scalable manner. As a result, traffic of one slice has no influence on the traffic of other slices, even if the slice is misbehaving (e.g., Distributed Denial-of-Service (DDoS) attacks or node/link failures) and generates traffic volumes above the contracted rates. The slice rates can be characterized with the following parameters :
  • CIR: Committed Information Rate (i.e., guaranteed bandwidth)
  • PIR: Peak Information Rate (i.e., maximum bandwidth)
These parameters define the traffic characteristics of the slice and are part of the SLO parameter set provided by the 5G NSO to an NSC. Based on these parameters, the provider network's inbound policy can be implemented using one of following options:
  • 1r2c (single-rate two-color) rate limiter This is the most basic rate limiter, described in (though not termed "1r2c" in that document). At the SDP, it meters a traffic stream of a given slice and marks its packets as in-profile (below CIR being enforced) or out-of-profile (above CIR being enforced). In-profile packets are accepted and forwarded. Out-of-profile packets are either dropped right at the SDP (hard rate limiting) or re-marked (with different MPLS TC or DSCP TN markings) to signify "this packet should be dropped in the first place, if there is congestion" (soft rate limiting), depending on the business policy of the provider network. In the latter case, while packets above CIR are forwarded at the SDP, they are subject to being dropped during any congestion event at any place in the provider network.
  • 2r3c (two-rate three-color) rate limiter This was initially defined in , and an improved version is defined in . In essence, the traffic is assigned to one of the these three categories:
    • Green, for traffic under CIR
    • Yellow, for traffic between CIR and PIR
    • Red, for traffic above PIR
    An inbound 2r3c meter implemented with , compared to , is more "customer friendly" as it doesn't impose outbound peak-rate shaping requirements on CE devices. In general, 2r3c meters give greater flexibility for provider network edge enforcement regarding accepting the traffic (green), deprioritizing and potentially dropping the traffic on transit during congestion (yellow), or hard-dropping the traffic (red).
Inbound provider network edge enforcement for the 5QI-unaware model, where all packets belonging to the slice are treated the same way in the provider network (no 5G QoS Class differentiation in the provider), is outlined in .
Ingress Slice Admission Control (5QI-Unaware Model) Slice policer S l i <> c e A t 1 t a c h S m l e i n <> c t e C 2 i r c u S i l t i <> c e 3 Slice policer +---------+ | +---|--+ | | | | | | | S | | | | l | | v | i | | -------------<>----|--> c | | | e | A | | | t | | 1 | t | | | a | ------ c | | | h | | S | m | | l | e | | i | n | -------------<>----|--> c | t | | e | | | | C | | 2 | i | | | r | ------ c | | | u | | S | i | | l | t | | i | | -------------<>----|--> c | | | e | | | | | | 3 | | | | | +---|--+ | +---------+
Outbound Edge Resource Control While inbound slice admission control at the provider network edge is mandatory in the architecture described in this document, outbound provider network edge resource control might not be required in all use cases. Use cases that specifically call for outbound provider network edge resource control are:
  • Slices use both CIR and PIR parameters, and provider network edge links (ACs) are dimensioned to fulfill the aggregate of slice CIRs. If, at any given time, some slices send the traffic above CIR, congestion in the outbound direction on the provider network edge link (AC) might happen. Therefore, fine-grained resource control to guarantee at least CIR for each slice is required.
  • Any-to-Any (A2A) connectivity constructs are deployed, again resulting in potential congestion in the outbound direction on the provider network edge links, even if only slice CIR parameters are used. This again requires fine-grained resource control per slice in the outbound direction at the provider network edge links.
As opposed to inbound provider network edge resource control, typically implemented with rate-limiters/policers, outbound resource control is typically implemented with a weighted/priority queuing, potentially combined with optional shapers (per slice). A detailed analysis of different queuing mechanisms is out of scope for this document but is provided in . outlines the outbound provider network edge resource control model for 5QI-unaware slices. Each slice is assigned a single egress queue. The sum of slice CIRs, used as the weight in weighted queueing model, should not exceed the physical capacity of the AC. Slice requests above this limit should be rejected by the NSC, unless an already-established slice with lower priority, if such exists, is preempted.
Ingress Slice Admission Control (5QI-Unaware Model) - Output QoS output queues - - - - - - - - - - - - - - - - - - - - - - - - - S \ / l i A c weight-Slice-1-CIR t e shaping-Slice-1-PIR --t-- a 1 | / \ c - - - - - - - - - - - - - - - - - - - - - - - - - - h S \ / m l e i n c weight-Slice-2-CIR t e shaping-Slice-2-PIR C 2 | / \ i - - - - - - - - - - - - - - - - - - - - - - - - - - r S \ / c l u i i c weight-Slice-3-CIR t e shaping-Slice-3-PIR 3 / \ - - - - - - - - - - - - - - - - - - - - - - - - - +---------+ QoS output queues | | | +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | | S | \|/ | | l | | | | i | | | A | c | | weight-Slice-1-CIR | t | e .--|--------------------------. | shaping-Slice-1-PIR ---|--t--|---|--> | | | a | 1 '--|--------------------------' /|\ | c ------ - - - - - - - - - - - - - - - - - - - - - - - - - - | h | S | \|/ | m | l | | | e | i | | | n | c | | weight-Slice-2-CIR | t | e .--|--------------------------. | shaping-Slice-2-PIR ---|-----|---|--> | | | C | 2 '--|--------------------------' /|\ | i ------ - - - - - - - - - - - - - - - - - - - - - - - - - - | r | S | \|/ | c | l | | | u | i | | | i | c | | weight-Slice-3-CIR | t | e .--|--------------------------. | shaping-Slice-3-PIR ---|-----|---|--> | | | | 3 '--|--------------------------' /|\ | +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | | +---------+
5QI-Aware Model In the 5QI-aware model, a potentially large number of 5G QoS Classes, represented via the DSCP set by NFs (the architecture scales to thousands of 5G Network Slices), is mapped (multiplexed) to up to 8 TN QoS Classes used in a provider network transit equipment, as outlined in .
Mapping of Slice 5G QoS to TN QoS (5QI-Aware Model) PE R SDP F Transit link C 5G DSCP A 9 TN QoS Class 1 5 4 5G DSCP B 3 TN QoS Class 2 N 5G DSCP C S TN QoS Class 3 1 5G DSCP D TN QoS Class 4 R F TN QoS Class 5 C 5G DSCP A -- 9 5 TN QoS Class 6 4 5G DSCP E 3 TN QoS Class 7 N 5G DSCP F S TN QoS Class 8 2 5G DSCP G Max 8 TN Classes SDP Fine-grained QoS enforcement Coarse-grained QoS enforcement (dedicated resources per (resources shared by multiple RFC 9543 Network Slice) RFC 9543 Network Slices) +---------------------------------------------------------------+ +-------------------+ PE | | .--------------+ | | R | | SDP | | +-----------------------------+ F | | .---------. | | | Transit link | C | | | 5G DSCP A +---------------+ | .-----------------------. | 9 | | '---------' | | +---|--> TN QoS Class 1 | | 5 | | .---------. | | | | '-----------------------' | 4 | | | 5G DSCP B +------------+ | | .-----------------------. | 3 | | '---------' | | | | | | TN QoS Class 2 | | | | .---------. | | | | | '-----------------------' | N | | | 5G DSCP C +---------+ | | | .-----------------------. | S | | '---------' | | | | | | | TN QoS Class 3 | | | | .---------. | | | | | | '-----------------------' | 1 | | | 5G DSCP D +------+ | | | | .-----------------------. | | | '---------' | | | | +--)---|--> TN QoS Class 4 | | | '--------------' | | | | | | '-----------------------' | R | .--------------+ | | | | | | .-----------------------. | F | | .---------. | | | +--)--|---|--> TN QoS Class 5 | | C | | | 5G DSCP A +------)--|--|--+ | '-----------------------' | 9 | | '---------' | | | | | | .-----------------------. | 5 | | .---------. | | | | | | | TN QoS Class 6 | | 4 | | | 5G DSCP E +------)--)--+ | '-----------------------' | 3 | | '---------' | | | | | .-----------------------. | | | .---------. | | | | | | TN QoS Class 7 | | N | | | 5G DSCP F +------)--+ | '-----------------------' | S | | '---------' | | | | .-----------------------. | | | .---------. | | +------------|--> TN QoS Class 8 | | 2 | | | 5G DSCP G +------+ | '-----------------------' | | | '---------' | | | Max 8 TN Classes | | | SDP | | +-----------------------------+ | '--------------' | | +-------------------+ | +---------------------------------------------------------------+ Fine-grained QoS enforcement Coarse-grained QoS enforcement (dedicated resources per (resources shared by multiple RFC 9543 Network Slice) RFC 9543 Network Slices)
Given that in deployments with a large number of 5G Network Slices, the number of potential 5G QoS Classes is much higher than the number of TN QoS Classes, multiple 5G QoS Classes with similar characteristics -- potentially from different slices -- would be grouped with common operator-defined TN logic and mapped to the same TN QoS Class when transported in the provider network. That is, common Per-Hop Behavior (PHB) is executed on transit provider network routers for all packets grouped together. An example of this approach is outlined in . A provider may decide to implement Diffserv-Intercon PHBs at the boundaries of its network domain .
Example of 3GPP QoS Mapped to TN QoS PE NF-A 3GPP S-NSSAI 100 SDP 5QI=1 DSCP=46 DSCP=46 5QI=65 DSCP=46 DSCP=46 5QI=7 DSCP=10 DSCP=10 TN QoS Class 5 Queue 5 NF-B 3GPP S-NSSAI 200 SDP 5QI=1 DSCP=46 DSCP=46 TN QoS Class 1 Queue 1 5QI=65 DSCP=46 DSCP=46 5QI=7 DSCP=10 DSCP=10 +--------------- PE -----------------+ +------ NF-A ------------+ | | | | | .----------+ | | 3GPP S-NSSAI 100 | | | SDP | | | .-----. .-------. | | | .------. | | | |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ | | '-----' '-------' | | | '------' | | | | .-----. .-------. | | | .------. | | | | |5QI=65 +->+DSCP=46 +----->+DSCP=46 +----+ | | '-----' '-------' | | | '------' | | | | .-----. .-------. | | | .------. | | | | |5QI=7 +->+DSCP=10 +----->+DSCP=10 +----)-+ .------------. | | '-----' '-------' | | | '------' | | | |TN QoS Class 5| | +------------------------+ | '----------' +-)--> Queue 5 | | | | | '------------' | +------- NF-B -----------+ | | | | | | | .----------+ | | | | 3GPP S-NSSAI 200 | | | SDP | | | | | .-----. .-------. | | | .------. | | | | | |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ | .------------. | | '-----' '-------' | | | '------' | | | |TN QoS Class 1| | | .-----. .-------. | | | .-------. | | +--> Queue 1 | | | |5QI=65 +->+DSCP=46 +----->+DSCP=46 +---+ | '------------' | | '-----' '-------' | | | '-------' | | | | .-----. .-------. | | | .-------. | | | | |5QI=7 +->+DSCP=10 +----->+DSCP=10 +-----+ | | '-----' '-------' | | | '-------' | | +------------------------+ | '----------' | +--------------------------------------+
In current SDO progress of 3GPP (Release 19) and O-RAN, the mapping of 5QI to DSCP is not expected to be in a per-slice fashion, where 5QI-to-DSCP mapping may vary from 3GPP slice to 3GPP slice; hence, the mapping of 5G QoS DSCP values to TN QoS Classes may be rather common. Like in the 5QI-unaware model, the original IP header retains the DSCP marking corresponding to 5QI (5G QoS Class), while the new header (MPLS or IPv6) carries the QoS marking related to TN QoS Class. Based on the TN QoS Class marking, per-hop behavior for all aggregated 5G QoS Classes from all RFC 9543 Network Slices is executed on the provider network transit links. Provider network transit routers do not evaluate the original IP header for QoS-related decisions. The original DSCP marking retained in the original IP header is used at the PE for fine-grained inbound/outbound enforcement per slice and per 5G QoS Class on the AC. In the 5QI-aware model, compared to the 5QI-unaware model, provider network edge resources are controlled in an even more fine-grained manner, with dedicated resource allocation for each RFC 9543 Network Slice and for a number of traffic classes (most commonly, up to 4 or 8 traffic classes, depending on the hardware capability of the equipment) within each RFC 9543 Network Slice.
Inbound Edge Resource Control Compared to the 5QI-unaware model, admission control (traffic conditioning) in the 5QI-aware model is more granular, as it not only enforces per-slice capacity constraints, but may also enforce the constraints per 5G QoS Class within each slice. A 5G Network Slice using multiple 5QIs can potentially specify rates in one of the following ways:
  • Rates per traffic class (CIR or CIR+PIR), no rate per slice (sum of rates per class gives the rate per slice).
  • Rate per slice (CIR or CIR+PIR), and rates per prioritized (premium) traffic classes (CIR only). A best-effort traffic class uses the bandwidth (within slice CIR/PIR) not consumed by prioritized classes.
In the first option, the slice admission control is executed with traffic class granularity, as outlined in . In this model, if a premium class doesn't consume all available class capacity, it cannot be reused by a non-premium class (i.e., best-effort).
Ingress Slice Admission Control (5QI-Aware Model) Class policer 5Q-QoS-A: CIR-1A <> S 5Q-QoS-B: CIR-1B <> l 5Q-QoS-C: CIR-1C <> i c e BE CIR/PIR-1D <> A 1 t t a c 5Q-QoS-A: CIR-2A <> S h 5Q-QoS-B: CIR-2B <> l m 5Q-QoS-C: CIR-2C <> i e c n e t BE CIR/PIR-2D <> 2 C i r c 5Q-QoS-A: CIR-3A <> S u 5Q-QoS-B: CIR-3B <> l i 5Q-QoS-C: CIR-3C <> i t c e BE CIR/PIR-3D <> 3 Class +---------+ policer +--|---+ | | | | 5Q-QoS-A: CIR-1A ------<>-----------|--> S | | 5Q-QoS-B: CIR-1B ------<>-----------|--> l | | 5Q-QoS-C: CIR-1C ------<>-----------|--> i | | | c | | | e | | BE CIR/PIR-1D ------<>-----------|--> | A | | 1 | t | | | t | ------ a | | | c | 5Q-QoS-A: CIR-2A ------<>-----------|--> S | h | 5Q-QoS-B: CIR-2B ------<>-----------|--> l | m | 5Q-QoS-C: CIR-2C ------<>-----------|--> i | e | | c | n | | e | t | BE CIR/PIR-2D ------<>-----------|--> | | | 2 | C | | | i | ------ r | | | c | 5Q-QoS-A: CIR-3A ------<>-----------|--> S | u | 5Q-QoS-B: CIR-3B ------<>-----------|--> l | i | 5Q-QoS-C: CIR-3C ------<>-----------|--> i | t | | c | | | e | | BE CIR/PIR-3D-------<>-----------|--> | | | 3 | | | | | +--|---+ | +---------+
The second option combines the advantages of the 5QI-unaware model (per-slice admission control) with per-traffic-class admission control, as outlined in . Ingress admission control is at class granularity for premium classes (CIR only). A non-premium class (i.e., best-effort class) has no separate class admission control policy, but it is allowed to use the entire slice capacity, which is available at any given moment (i.e., slice capacity, which is not consumed by premium classes). It is a hierarchical model, as depicted in .
Ingress Slice Admission Control (5QI-Aware Model) - Hierarchical Slice policer Class policer - 5Q-QoS-A: CIR-1A <> - -- S 5Q-QoS-B: CIR-1B <> - -- l 5Q-QoS-C: CIR-1C <> - -- i c e BE CIR/PIR-1D - -- A 1 t - t a - c 5Q-QoS-A: CIR-2A <> - -- S h 5Q-QoS-B: CIR-2B <> - -- l m 5Q-QoS-C: CIR-2C <> - -- i e c n e t BE CIR/PIR-2D - -- 2 C - i r - c 5Q-QoS-A: CIR-3A <> - -- S u 5Q-QoS-B: CIR-3B <> - -- l i 5Q-QoS-C: CIR-3C <> - -- i t c e BE CIR/PIR-3D - -- 3 - Slice policer +---------+ Class +--|---+ | policer .-. | | | 5Q-QoS-A: CIR-1A ----<>--------|-|--|--> S | | 5Q-QoS-B: CIR-1B ----<>--------|-|--|--> l | | 5Q-QoS-C: CIR-1C ----<>--------|-|--|--> i | | | | | c | | | | | e | | BE CIR/PIR-1D --------------|-|--|--> | A | | | | 1 | t | '-' | | t | ------ a | .-. | | c | 5Q-QoS-A: CIR-2A ----<>--------|-|--|--> S | h | 5Q-QoS-B: CIR-2B ----<>--------|-|--|--> l | m | 5Q-QoS-C: CIR-2C ----<>--------|-|--|--> i | e | | | | c | n | | | | e | t | BE CIR/PIR-2D --------------|-|--|--> | | | | | 2 | C | '-' | | i | ------ r | .-. | | c | 5Q-QoS-A: CIR-3A ----<>--------|-|--|--> S | u | 5Q-QoS-B: CIR-3B ----<>--------|-|--|--> l | i | 5Q-QoS-C: CIR-3C ----<>---- ---|-|--|--> i | t | | | | c | | | | | e | | BE CIR/PIR-3D --------------|-|--|--> | | | | | 3 | | '-' | | | +--|---+ | +---------+
Outbound Edge Resource Control outlines the outbound edge resource control model at the Transport Network layer for 5QI-aware slices. Each slice is assigned multiple egress queues. The sum of queue weights, which are 5G QoS queue CIRs within the slice, should not exceed the CIR of the slice itself. And, similar to the 5QI-aware model, the sum of slice CIRs should not exceed the physical capacity of the AC.
Egress Slice Admission Control (5QI-Aware Model) QoS output queues - - - - - - - - - - - - - - - - - - - - - - - - - \ / 5Q-QoS-A: w-5Q-QoS-A-CIR S l -i- 5Q-QoS-B: w-5Q-QoS-B-CIR c weight-Slice-1-CIR e shaping-Slice-1-PIR 5Q-QoS-C: w-5Q-QoS-C-CIR 1 Best Effort (remainder) / \ A - - - - - - - - - - - - - - - - - - - - - - - - - t \ / t a c S h l m i ... weight-Slice-2-CIR e c shaping-Slice-2-PIR n e t 2 / \ C - - - - - - - - - - - - - - - - - - - - - - - - - i \ / r c u i S t l i ... weight-Slice-3-CIR c shaping-Slice-3-PIR e 3 / \ - - - - - - - - - - - - - - - - - - - - - - - - - +---------+ QoS output queues | +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - - | | .--|--------------------------. \|/ ---|-----|---|--> 5Q-QoS-A: w-5Q-QoS-A-CIR | | | | S '-----------------------------' | | | l .-----------------------------. | ---|-----|-i-|--> 5Q-QoS-B: w-5Q-QoS-B-CIR | | | | c '-----------------------------' | weight-Slice-1-CIR | | e .-----------------------------. | shaping-Slice-1-PIR ---|-----|---|--> 5Q-QoS-C: w-5Q-QoS-C-CIR | | | | 1 '-----------------------------' | | | .-----------------------------. | ---|-----|---|--> Best Effort (remainder) | | | | '--|--------------------------' /|\ | A +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | t | .--|--------------------------. \|/ | t | | | | | a | '-----------------------------' | | c | S | | | h | l | | m | i | ... | weight-Slice-2-CIR | e | c | | shaping-Slice-2-PIR | n | e .-----------------------------. | | t | | | | | | 2 '-----------------------------' /|\ | C +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | i | | \|/ | r + .-----------------------------. | | c | | | | | u | '-----------------------------' | | i | S | | | t | l | | | | i | ... | weight-Slice-3-CIR | | c | | shaping-Slice-3-PIR | | e .-----------------------------. | | | | | | | | 3 '-----------------------------' /|\ | +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---------+
Transit Resource Control Transit resource control is much simpler than edge resource control in the provider network. As outlined in , at the provider network edge, 5G QoS Class marking (represented by DSCP related to 5QI set by Mobile Network functions in the packets handed off to the TN) is mapped to the TN QoS Class. Based on TN QoS Class, when the packet is encapsulated with an outer header (MPLS or IPv6), the TN QoS Class marking (MPLS TC or IPv6 DSCP in outer header, as depicted in Figures and ) is set in the outer header. PHB in provider network transit routers is based exclusively on that TN QoS Class marking, i.e., original 5G QoS Class DSCP is not taken into consideration on transit. Provider network transit resource control does not use any inbound interface policy but only uses an outbound interface policy, which is based on the priority queue combined with a weighted or deficit queuing model, without any shaper. The main purpose of transit resource control is to ensure that during network congestion events (for example, events caused by network failures or temporary rerouting), premium classes are prioritized, and any drops only occur in traffic that was deprioritized by ingress admission control (see ) or in non-premium (best-effort) classes. Capacity planning and management, as described in , ensures that enough capacity is available to fulfill all approved slice requests.
PE Underlay Transport Mapping Models The PE underlay transport (underlay transport, for short) refers to a specific path forwarding behavior between PEs in order to provide packet delivery that is consistent with the corresponding SLOs. This realization step focuses on controlling the paths that will be used for packet delivery between PEs, independent of the underlying network resource partitioning. It is worth noting that TN QoS Classes and underlay transport are each related to different engineering objectives. For example, the TN domain can be operated with 8 TN QoS Classes (representing 8 hardware queues in the routers) and two underlay transports (e.g., a latency-optimized underlay transport using link-latency metrics for path calculation and an underlay transport following IGP metrics). The TN QoS Class determines the per-hop behavior when the packets are transiting through the provider network, while underlay transport determines the paths for packets through the provider network based on the operator's requirements. This path can be optimized or constrained. A network operator can define multiple underlay transports within a single NRP. An underlay transport may be realized in multiple ways such as (but not limited to):
  • A mesh of RSVP-TE or SR-TE tunnels created with specific optimization criteria and constraints. For example, mesh "A" might represent tunnels optimized for latency, and mesh "B" might represent tunnels optimized for high capacity.
  • A Flex-Algorithm with a particular metric-type (e.g., latency), or one that only uses links with particular properties (e.g., a Media Access Control Security (MACsec) link ) or excludes links that are within a particular geography.
These protocols can be controlled, e.g., by tuning the protocol list under the "underlay-transport" data node defined in the L3VPN Network Model (L3NM) and the L2VPN Network Model (L2NM) . Also, underlay transports may be realized using separate NRPs. However, such an approach is left out of the scope given the current state of the technology at the time of writing this document. Similar to the QoS mapping models discussed in , for mapping to underlay transports at the ingress PE, both the 5QI-unaware and 5QI-aware models are defined. Essentially, entire slices can be mapped to underlay transports without 5G QoS consideration (5QI-unaware model). For example, flows with different 5G QoS Classes, even from same slice, can be mapped to different underlay transports (5QI-aware model). depicts an example of a simple network with two underlay transports, each using a mesh of TE tunnels with or without Path Computation Element (PCE) and with or without per-path bandwidth reservations. discusses in detail different bandwidth models that can be deployed in the provider network. However, discussion about how to realize or orchestrate underlay transports is out of scope for this document.
Example of Underlay Transport Relying on TE Tunnels Ingress PE PE-A > x Underlay x Transport x PE-B A x > PE-C Underlay > Transport B PE-D > +---------------+ +------+ | Ingress PE | +------------------------------->| PE-A | | | | +-------------------------->>| | | | | | +------+ | +----------+ | | +---------------------+ | | | | | | | | x------+ +---------------------+ | |Underlay x----------|-------------+ +------+ | |Transport x----------)--+ +------------->| PE-B | | | A x-------+ | | +---+ +------>>| | | +----------+ | | | | | | | +------+ | | | | | | +---------+ | +----------+ | | | | | | | | | | | | | +------+ | | o-------)--+ +--)--------------------->| PE-C | | |Underlay o-------|--------+ +---->>| | | |Transport o-------|-----------------+ | +------+ | | B o-----+ +---------------+ | | | | | | | | | | | +----------+ | | +---+ +---+ | +------+ +------+ | | | | | | | +-------------->| PE-D | +---------------+ +---+ +---+ +--------------->>| | +------+
For illustration purposes, shows only single tunnels per underlay transport for an (ingress PE, egress PE) pair. However, there might be multiple tunnels within a single underlay transport between any pair of PEs.
5QI-Unaware Model As discussed in , in the 5QI-unaware model, the provider network doesn't take into account 5G QoS during execution of per-hop behavior. The entire slice is mapped to a single TN QoS Class; therefore, the entire slice is subject to the same per-hop behavior. Similarly, in the 5QI-unaware PE underlay transport mapping model, the entire slice is mapped to a single underlay transport, as depicted in .
Mapping of Network Slice to Underlay Transport (5QI-Unaware Model) .. .. .. .. .. .. . : AC : PE : : : SDP : : : : NS 1 : : : : : : : SDP : : : Underlay : NS 2 Transport : : A : : : : : SDP : : : : NS 3 : : : : : : Underlay : SDP : Transport : : B : NS 4 : : : : : : : SDP : : : : NS 5 : : : : '.. .. .. .. .. .. .' +-------------------------------------------+ |.. .. .. .. .. .. . | : AC : PE | : .--------------. : | : | SDP | : | : | +----------+ | : | : | | NS 1 +-----------+ | : | +----------+ | : | | : '--------------' : | | : .--------------. : | +---------+ | : | SDP | : | | | | : | +----------+ | : | |Underlay | | : | | NS 2 +-------+ +--->Transport| | : | +----------+ | : | | | A | | : '--------------' : | | | | | : .--------------. : | | +---------+ | : | SDP | : | | | : | +----------+ | : | | | : | | NS 3 +-------+ | | : | +----------+ | : | | +---------+ | : '--------------' : | | | | | : .--------------. : | | |Underlay | | : | SDP | : +---)--->Transport| | : | +----------+ | : | | | B | | : | | NS 4 +-------+ | | | | : | +----------+ | : | +---------+ | : '--------------' : | | : .--------------. : | | : | SDP | : | | : | +----------+ | : | | : | | NS 5 +-----------+ | : | +----------+ | : | : '--------------' : | '.. .. .. .. .. .. .' | +-------------------------------------------+
5QI-Aware Model In the 5QI-aware model, the traffic can be mapped to underlay transports at the granularity of 5G QoS Class. Given that the potential number of underlay transports is limited, packets from multiple 5G QoS Classes with similar characteristics are mapped to a common underlay transport, as depicted in .
Mapping of Network Slice to Underlay Transport (5QI-Aware Model) .. .. .. .. .. .. . : AC : PE : : R : SDP : F : : C : 5G QoS A 9 : : 5 : : 4 : 5G QoS B 3 : : : : N : 5G QoS C Underlay S : : Transport : : A 1 : 5G QoS D : : : : R : : F : : C : 5G QoS A 9 : : 5 : : Underlay 4 : 5G QoS E Transport 3 : : B : : N : 5G QoS F S : : : : 2 : 5G QoS G : : : SDP : : : '.. .. .. .. .. .. ' +---------------------------------------------+ |.. .. .. .. .. .. . | : AC : PE | : .--------------. : | R : | SDP | : | F : | .---------. | : | C : | | 5G QoS A +-------+ | 9 : | '---------' | : | | 5 : | .---------. | : | | 4 : | | 5G QoS B +-------+ | 3 : | '---------' | : | +---------+ | : | .---------. | : | | | | N : | | 5G QoS C +-------)----+ |Underlay | | S : | '---------' | : +----)---->Transport| | : | .---------. | : | | | A | | 1 : | | 5G QoS D +-------)----+ | | | : | '---------' | : | | +---------+ | : '--------------' : | | | R : .--------------. : | | | F : | .---------. | : | | | C : | | 5G QoS A +-------+ | +---------+ | 9 : | '---------' | : | | | | | 5 : | .---------. | : | | |Underlay | | 4 : | | 5G QoS E +-------+ +---->Transport| | 3 : | '---------' | : | | B | | : | .---------. | : | | | | N : | | 5G QoS F +------------+ +---------+ | S : | '---------' | : | | : | .---------. | : | | 2 : | | 5G QoS G +------------+ | : | '---------' | : | : | SDP | : | : '--------------' : | '.. .. .. .. .. .. ' | +---------------------------------------------+
Capacity Planning/Management
Bandwidth Requirements This section describes the information conveyed by the 5G NSO to the NSC with respect to slice bandwidth requirements. shows three DCs that contain instances of network functions. Also shown are PEs that have links to the DCs. The PEs belong to the provider network. Other details of the provider network, such as P-routers and transit links, are not shown. In addition, details of the DC infrastructure in customer sites, such as switches and routers, are not shown. The 5G NSO is aware of the existence of the network functions and their locations. However, it is not aware of the details of the provider network. The NSC has the opposite view -- it is aware of the provider network infrastructure and the links between the PEs and the DCs, but it is not aware of the individual network functions at customer sites.
Example of Multi-DC Architecture DC 1 DC 2 NF1A PE1A PE2A NF2A NF1B NF2B NF1C PE1B PE2B NF2C Provider Network DC 3 PE3A NF3A NF3B PE3B NF3C SDP, with fine-grained QoS (dedicated resources per RFC 9543 Network Slices) +-------- DC 1-------+ +-----------------+ +-------- DC 2-------+ | | | | | | | +------+ | +-----+ +-----+ | +------+ | | | NF1A | +--* PE1A| |PE2A *--+ | NF2A | | | +------+ | +-----+ +-----+ | +------+ | | +------+ | | | | +------+ | | | NF1B | | | | | | NF2B | | | +------+ | | | | +------+ | | +------+ | +-----+ +-----+ | +------+ | | | NF1C | +--* PE1B| |PE2B *--+ | NF2C | | | +------+ | +-----+ +-----+ | +------+ | +--------------------+ | | +--------------------+ | Provider | | Network | +--------DC 3--------+ | +-----+ | +------+ | | |PE3A *--+ | NF3A | | | +-----+ | +------+ | | | | +------+ | | | | | NF3B | | | | | +------+ | | +-----+ | +------+ | | |PE3B *--+ | NF3C | | | +-----+ | +------+ | | | | | +-----------------+ +--------------------+ * SDP, with fine-grained QoS (dedicated resources per RFC 9543 Network Slices)
Let us consider 5G Network Slice "X" that uses some of the network functions in the three DCs. If this slice has latency requirements, the 5G NSO will have taken those into account when deciding which NF instances in which DC are to be invoked for this slice. As a result of such a placement decision, the three DCs shown are involved in 5G Network Slice "X", rather than other DCs. For its decision-making, the 5G NSO needs information from the NSC about the observed latency between DCs. Preferably, the NSC would present the topology in an abstracted form, consisting of point-to-point abstracted links between pairs of DCs and associated latency and, optionally, delay variation and link-loss values. It would be valuable to have a mechanism for the 5G NSO to inform the NSC which DC-pairs are of interest for these metrics; there may be thousands of DCs, but the 5G NSO will only be interested in these metrics for a small fraction of all the possible DC-pairs, i.e., those in the same region of the provider network. The mechanism for conveying the information is out of scope for this document. shows the matrix of bandwidth demands for 5G Network Slice "X". Within the slice, multiple NF instances might be sending traffic from DCi to DCj. However, the 5G NSO sums the associated demands into one value. For example, "NF1A" and "NF1B" in "DC 1" might be sending traffic to multiple NFs in "DC 2", but this is expressed as one value in the traffic matrix: the total bandwidth required for 5G Network Slice "X" from "DC 1" to "DC 2" (8 units). Each row in the right-most column in the traffic matrix shows the total amount of traffic going from a given DC into the Transport Network, regardless of the destination DC. Note that this number can be less than the sum of DC-to-DC demands in the same row, on the basis that not all the NFs are likely to be sending at their maximum rate simultaneously. For example, the total traffic from "DC 1" for slice "X" is 11 units, which is less than the sum of the DC-to-DC demands in the same row (13 units). Note, as described in , a slice may have per-QoS class bandwidth requirements and may have CIR and PIR limits. This is not included in the example, but the same principles apply in such cases. Inter-DC Traffic Demand Matrix (Slice X)
From/To DC 1 DC 2 DC 3 Total from DC
DC 1 n/a 8 5 11.0
DC 2 1 n/a 2 2.5
DC 3 4 7 n/a 10.0
The YANG data model defined in can be used to convey all of the information in the traffic matrix to an NSC. The NSC applies policers corresponding to the last column in the traffic matrix to the appropriate PE routers, in order to enforce the bandwidth contract. For example, it applies a policer of 11 units to PE1A and PE1B that face DC 1, as this is the total bandwidth that DC 1 sends into the provider network corresponding to slice "X". Also, the controller may apply shapers in the direction from the TN to the DC if there is the possibility of a link in the DC being oversubscribed. Note that a peer NF endpoint of an AC can be identified using "peer-sap-id" as defined in . Depending on the bandwidth model used in the provider network (), the other values in the matrix, i.e., the DC-to-DC demands, may not be directly applied to the provider network. Even so, the information may be useful to the NSC for capacity planning and failure simulation purposes. On the other hand, if the DC-to-DC demand information is not used by the NSC, the IETF YANG data models for L3VPN service delivery or L2VPN service delivery could be used instead of the YANG data model defined in , as they support conveying the bandwidth information in the right-most column of the traffic matrix. The provider network may be implemented in such a way that it has various types of paths, for example, low-latency traffic might be mapped onto a different transport path from other traffic (for example, a particular Flex-Algorithm, a particular set of TE paths, or a specific queue ), as discussed in . The 5G NSO can use the YANG data model defined in to request low-latency transport for a given slice if required. However, the YANG data models in or do not support requesting a particular transport-type, e.g., low-latency. One option is to augment these models to convey this information. This can be achieved by reusing the "underlay-transport" construct defined in and .
Bandwidth Models This section describes three bandwidth management schemes that could be employed in the provider network. Many variations are possible, but each example describes the salient points of the corresponding scheme. Schemes 2 and 3 use TE; other variations on TE are possible as described in .
Scheme 1: Shortest Path Forwarding (SPF) Shortest path forwarding is used according to the IGP metric. Given that some slices are likely to have latency SLOs, the IGP metric on each link can be set to be in proportion to the latency of the link. In this way, all traffic follows the minimum latency path between endpoints. In Scheme 1, although the operator provides bandwidth guarantees to the slice customers, there is no explicit end-to-end underpinning of the bandwidth SLO, in the form of bandwidth reservations across the provider network. Rather, the expected performance is achieved via capacity planning, based on traffic growth trends and anticipated future demands, in order to ensure that network links are not over-subscribed. This scheme is analogous to that used in many existing business VPN deployments, in that bandwidth guarantees are provided to the customers but are not explicitly underpinned end to end across the provider network. A variation on the scheme is that Flex-Algorithm is used. For example, one Flex-Algorithm could use latency-based metrics, and another Flex-Algorithm could use the IGP metric. There would be a many-to-one mapping of network slices to Flex-Algorithms. While Scheme 1 is technically feasible, it is vulnerable to unexpected changes in traffic patterns and/or network element failures resulting in congestion. This is because, unlike Schemes 2 and 3, which employ TE, traffic cannot be diverted from the shortest path.
Scheme 2: TE Paths with Fixed Bandwidth Reservations Scheme 2 uses RSVP-TE or SR-TE paths with fixed bandwidth reservations. By "fixed", we mean a value that stays constant over time, unless the 5G NSO communicates a change in slice bandwidth requirements, due to the creation or modification of a slice. Note that the "reservations" may be maintained by the transport controller; it is not necessary (or indeed possible for current SR-TE technology at the time of writing this document) to reserve bandwidth at the network layer. The bandwidth requirement acts as a constraint whenever the controller (re)computes a path. There could be a single mesh of paths between endpoints that carry all of the traffic types, or there could be a small handful of meshes, for example, one mesh for low-latency traffic that follows the minimum latency path and another mesh for the other traffic that follows the minimum IGP metric path, as described in . There would be a many-to-one mapping of slices to paths. The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj demands of the individual slices. For example, if only slices "X" and "Y" are present, then the bandwidth requirement from "DC 1" to "DC 2" is 12 units (8 units for slice "X" () and 4 units for slice "Y" ()). When the 5G NSO requests a new slice, the NSC, increments the bandwidth requirement according to the requirements of the new slice. For example, in , suppose a new slice is instantiated that needs 0.8 Gbps from "DC 1" to "DC 2". The transport controller would increase its notion of the bandwidth requirement from "DC 1" to "DC 2" from 12 Gbps to 12.8 Gbps to accommodate the additional expected traffic. Inter-DC Traffic Demand Matrix (Slice Y)
From/To DC 1 DC 2 DC 3 Total from DC
DC 1 n/a 4 2.5 6.0
DC 2 0.5 n/a 0.8 1.0
DC 3 2.6 3 n/a 5.1
In the example, each DC has two PEs facing it for reasons of resilience. The NSC needs to determine how to map the "DC 1" to "DC 2" bandwidth requirement to bandwidth reservations of TE LSPs from "DC 1" to "DC 2". For example, if the routing configuration is arranged such that in the absence of any network failure, traffic from "DC 1" to "DC 2" always enters "PE1A" and goes to "PE2A", the controller reserves 12.8 Gbps of bandwidth on the path from "PE1A" to "PE2A". On the other hand, if the routing configuration is arranged such that in the absence of any network failure, traffic from "DC 1" to "DC 2" always enters "PE1A" and is load-balanced across "PE2A" and "PE2B", the controller reserves 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2A" and 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2B". It might be tricky for the NSC to be aware of all conditions that change the way traffic lands on the various PEs and therefore know that it needs to change bandwidth reservations of paths accordingly. For example, there might be an internal failure within "DC 1" that causes traffic from "DC 1" to land on "PE1B" rather than "PE1A". The NSC may not be aware of the failure and therefore may not know that it now needs to apply bandwidth reservations to paths from "PE1B" to "PE2A" and "PE2B".
Scheme 3: TE Paths without Bandwidth Reservation Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths. There could be a single mesh of paths between endpoints that carry all of the traffic types, or there could be a small handful of meshes, for example, one mesh for low-latency traffic that follows the minimum latency path and another mesh for the other traffic that follows the minimum IGP metric path, as described in . There would be a many-to-one mapping of slices to paths. The difference between Scheme 2 and Scheme 3 is that Scheme 3 does not have fixed bandwidth reservations for the paths. Instead, actual measured data plane traffic volumes are used to influence the placement of TE paths. One way of achieving this is to use distributed RSVP-TE with auto-bandwidth. Alternatively, the NSC can use telemetry-driven automatic congestion avoidance. In this approach, when the actual traffic volume in the data plane on a given link exceeds a threshold, the controller, knowing how much actual data plane traffic is currently traveling along each RSVP or SR-TE path, can tune one or more paths using the link such that they avoid that link. This approach is similar to that described in . It would be undesirable to move a path that has latency as its cost function, rather than another type of path, in order to ease the congestion, as the altered path will typically have a higher latency. This can be avoided by designing the algorithms described in the previous paragraph such that they avoid moving minimum-latency paths unless there is no alternative.
Network Slicing OAM The deployment and maintenance of slices within a network imply that a set of OAM functions need to be deployed by the providers, for example:
  • Providers should be able to execute OAM tasks on a per-network-slice basis. These tasks can cover the "full" slice within a domain or a portion of that slice (for troubleshooting purposes, for example). For example, per-slice OAM tasks can consist of (but not limited to):
    • tracing resources that are bound to a given network slice,
    • tracing resources that are invoked when forwarding a given flow bound to a given network slice,
    • assessing whether flow isolation characteristics are in conformance with the Network Slice Service requirements, or
    • assessing the compliance of the allocated network slice resources against flow and customer service requirements.
    provides an overview of available OAM tools. These technology-specific tools can be reused in the context of network slicing. Providers that deploy network slicing capabilities should be able to select whatever OAM technology or specific feature that would address their needs.
  • Providers may want to enable differentiated failure detection and repair features for a subset of network slices. For example, a given network slice may require fast detection and repair mechanisms, while others may not be engineered with such means. The provider can use techniques such as those described in , , and .
  • Providers may deploy means to dynamically discover the set of network slices that are enabled within its network. Such dynamic discovery capability facilitates the detection of any mismatch between the view maintained by the control/management plane and the actual network configuration. When mismatches are detected, corrective actions should be undertaken accordingly. For example, a provider may rely upon the L3NM or the L2NM to maintain the full set of L2VPN/L3VPNs that are used to deliver Network Slice Services. The correlation between an L2VPN/L3VPN instance and a Network Slice Service is maintained using the "parent-service-id" attribute ().
  • Providers should provide the means to report a set of network performance metrics to assess whether the agreed Slice Service objectives are honored. These means are used for SLO monitoring and violation detection purposes. For example, the YANG data model in can be used to report the one-way delay and one-way delay variation of links. Both conventional active/passive measurement methods and more recent telemetry methods (e.g., YANG Push ) can be used.
  • Providers should have the means to report and expose observed performance metrics and other OAM state to customer. For example, the YANG data model defined in exposes a set of statistics per SDP, connectivity construct, and connection group.
Scalability Implications The mapping of 5G Network Slices to Transport Network Slices (see ) is a design choice of service operators that may be a function of, e.g., the number of instantiated slices, requested services, or local engineering capabilities and guidelines. However, operators should carefully consider means to ease slice migration strategies. For example, a provider may initially adopt a 1-to-1 mapping if it has to instantiate just a few network slices and accommodate the need of only a few customers. That provider may decide to move to an M-to-1 mapping for aggregation/scalability purposes if sustained increased slice demand is observed. Putting in place adequate automation means to realize network slices (including the adjustment of the mapping of Slice Services to network slices) would ease slice migration operations. The realization model described in this document inherits the scalability properties of the underlying L2VPN and L3VPN technologies (). Readers may refer, for example, to or for a scalability assessment of some of these technologies. Providers may adjust the mapping model to better handle local scalability constraints.
IANA Considerations This document has no IANA actions.
Security Considerations discusses generic security considerations that are applicable to network slicing, with a focus on the following considerations:
Conformance to security constraints:
Specific security requests, such as not routing traffic through a particular geographical region can be met by mapping the traffic to an underlay transport () that avoids that region.
NSC authentication:
Per , underlay networks need to be protected against attacks from an adversary NSC as this could destabilize overall network operations. The interaction between an NSC and the underlay network is used to pass service provisioning requests following a set of YANG modules that are designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols have to use (1) a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) mutual authentication. The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Readers may refer to documents that describe NSC realization, such as .
Specific isolation criteria:
Adequate admission control policies, for example, policers as described in , should be configured in the edge of the provider network to control access to specific slice resources. This prevents the possibility of one slice consuming resources at the expense of other slices. Likewise, access to classification and mapping tables have to be controlled to prevent misbehaviors (an unauthorized entity may modify the table to bind traffic to a random slice, redirect the traffic, etc.). Network devices have to check that a required access privilege is provided before granting access to specific data or performing specific actions.
Data Confidentiality and Integrity of an RFC 9543 Network Slice:
As described in , the customer might request a Service Level Expectation (SLE) that mandates encryption. This can be achieved, e.g., by mapping the traffic to an underlay transport () that uses only MACsec-encrypted links.
In order to avoid the need for a mapping table to associate source/destination IP addresses and the specific S-NSSAIs of slices, describes an approach where some or all S-NSSAI bits are embedded in an IPv6 address using an algorithm approach. An attacker from within the Transport Network who has access to the mapping configuration may infer the slices to which a packet belongs. It may also alter these bits, which may lead to steering the packet via a distinct network slice and thus to service disruption. Note that such an attacker from within the Transport Network may inflict more damage (e.g., randomly drop packets). Security considerations specific to each of the technologies and protocols listed in the document are discussed in the specification documents of each of these protocols. In particular, readers should refer to the "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)" , the "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)" (), and the "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)" for a comprehensive discussion about security considerations related to VPN technologies (including authentication and encryption between PEs, use of IPsec tunnels that terminate within the customer sites to protect user data, prevention of illegitimate traffic from entering a VPN instance, etc.). Also, readers may refer to for a discussion about security considerations related to TE mechanisms.
References Normative References BGP/MPLS IP Virtual Private Networks (VPNs) This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] IPv6 Prefix Length Recommendation for Forwarding IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. Network Configuration Access Control Model The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. A Framework for Network Slices in Networks Built from IETF Technologies This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Informative References Private 5G: A Systems Approach Common Public Radio Interface: eCPRI Interface Specification Common Public Radio Interface 802.1AE: MAC Security (MACsec) IEEE 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS Telefonica Ribbon Communications Juniper Networks Work in Progress NG.113: 5GS Roaming Guidelines GSMA Version 4.0 IETF Network Slice Application in 3GPP 5G End-to-End Network Slice Huawei Technologies Telefonica Ciena Huawei Technologies Ribbon Communications Work in Progress Realizing Network Slices in IP/MPLS Networks Cisco Systems Inc. Juniper Networks Huawei Technologies Ericsson ZTE Corporation Work in Progress IETF Network Slice Controller and its Associated Data Models Telefonica Ciena Nvidia Huawei This document describes 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 (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. Work in Progress A YANG Data Model for the RFC 9543 Network Slice Service Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. Work in Progress Xhaul Packet Switched Architectures and Solutions O-RAN Alliance O-RAN.WG9.XPSAAS, Version 09.00 BGP Communities Attribute This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK] An Architecture for Differentiated Services This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. A Two Rate Three Color Marker This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. RSVP-TE: Extensions to RSVP for LSP Tunnels This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] Provider Provisioned Virtual Private Network (VPN) Terminology The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community. Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community. A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community. Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community. The Secure Shell (SSH) Authentication Protocol The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] BGP Extended Communities Attribute This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK] Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section. This memo provides information for the Internet community. Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users. The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community. Framework for Layer 2 Virtual Private Networks (L2VPNs) This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community. Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK] Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node. This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK] Basic Specification for IP Fast Reroute: Loop-Free Alternates This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK] Path Computation Element (PCE) Communication Protocol (PCEP) This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] IP Fast Reroute Framework This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes. A Recommendation for IPv6 Address Text Representation As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. This document is not an Internet Standards Track specification; it is published for informational purposes. Network Configuration Protocol (NETCONF) The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] Guidelines for the Use of the "OAM" Acronym in the IETF At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes. An Overview of Operations, Administration, and Maintenance (OAM) Tools Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary. Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use. BGP MPLS-Based Ethernet VPN This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". Encapsulating MPLS in UDP This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Active and Passive Metrics and Methods (with Hybrid Types In-Between) This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. On Queuing, Marking, and Dropping This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior. RESTCONF Protocol This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). Diffserv-Interconnection Classes and Practice This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS. Virtual Private Wire Service Support in Ethernet VPN This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. YANG Data Model for L3VPN Service Delivery This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text. Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks. A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. Subscription to YANG Notifications for Datastore Updates This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. A Framework for Automating Service and Network Management with YANG Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Operational Security Considerations for IPv6 Networks Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks. A YANG Network Data Model for Layer 3 VPNs As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. Segment Routing Policy Architecture Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. A YANG Network Data Model for Layer 2 VPNs This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. IGP Flexible Algorithm IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. A YANG Data Model for Network and VPN Service Performance Monitoring The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. A YANG Network Data Model for Service Attachment Points (SAPs) This document 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). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. Overview and Principles of Internet Traffic Engineering This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS) Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as a "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., RFC 9543 Network Slice Service). The document also specifies a YANG service data model for managing bearers over which ACs are established. A Network YANG Data Model for Attachment Circuits This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). System architecture for the 5G System (5GS) 3rd Generation Partnership Project Version 19.5.0, Release 19 Management and orchestration; Concepts, use cases and requirements 3rd Generation Partnership Project Version 19.0.0, Release 19
Example of Local IPv6 Addressing Plan for Network Functions Different IPv6 address allocation schemes following the approach in may be used, with one example allocation shown in .
Example of S-NSSAI Embedded into an IPv6 Address NF-specific Reserved (not slice specific) for S-NSSAI xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd 128 bits tt - SST (8 bits) dddddd - SD (24 bits) NF-specific Reserved (not slice specific) for S-NSSAI <----------------------------><---------> +----+----+----+----+----+----+----+----+ |xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd| +----+----+----+----+----+----+----+----+ <------------------128 bits-------------> tt - SST (8 bits) dddddd - SD (24 bits)
In reference to , the most significant 96 bits of the IPv6 address are unique to the NF but do not carry any slice-specific information. The S-NSSAI information is embedded in the least significant 32 bits. The 96-bit part of the address may be structured by the provider, for example, on the geographical location or the DC identification. Refer to for a discussion on the benefits of structuring an address plan around both services and geographic locations for more structured security policies in a network. uses the example from to demonstrate a slicing deployment, where the entire S-NSSAI is embedded into IPv6 addresses used by NFs. Let us consider that "NF-A" has a set of tunnel termination points with unique per-slice IP addresses allocated from 2001:db8:a::/96, while "NF-B" uses a set of tunnel termination points with per-slice IP addresses allocated from 2001:db8:b::/96. This example shows two slices: "customer A eMBB" (SST=1, SD=00001) and "customer B MIoT" (SST=3, SD=00003). For "customer A eMBB" slice, the tunnel IP addresses are auto-derived as the IP addresses {2001:db8:a::100:1, 2001:db8:b::100:1}, where {:0100:0001} is used as the last two octets. "customer B MIoT" slice (SST=3, SD=00003) tunnel uses the IP addresses {2001:db8:a::300:3, 2001:db8:b::300:3} and simply adds {:0300:0003} as the last two octets. Leading zeros are not represented in the resulting IPv6 addresses as per .
Deployment Example with S-NSSAI Embedded into IPv6 Addresses 2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B) 2001:db8:a::100:1/128 2001:db8:b::100:1/128 - - - - - - - - eMBB (SST=1) - Provider - NF PE | | PE L2/L3+.......+ NF - Network - - - - - - - - - MIoT (SST=3) 2001:db8:a::300:3/128 2001:db8:b::300:3/128 Tunnel (IPsec, GTP-U, etc.) termination point SDP 2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B) 2001:db8:a::100:1/128 2001:db8:b::100:1/128 | | | + - - - - - - - - + eMBB (SST=1) | | | | | | +----v-+ +--+--+ Provider +---+-+ | +-----+ +-v----+ | | | | | | v | | | | | o============*================*==========================o | | NF +-------+ PE | | PE +-------+L2/L3+.......+ NF | | o============*================*==========================o | | | | | | | ^ | | | | +----^-+ +--+--+ Network +---+-+ | +-----+ +-^----+ | | | | | | + - - - - - - - - + MIoT (SST=3) | | | 2001:db8:a::300:3/128 2001:db8:b::300:3/128 o Tunnel (IPsec, GTP-U, etc.) termination point * SDP
Acknowledgments The authors would like to thank , , , , , , , , , and for their review of this document and for providing valuable comments. Special thanks to and for the detailed and careful reviews. Thanks to and for the rtg-dir reviews, for the tsv-art review, for the int-dir review, for the genart review, for the secdir review, and for the opsdir review. Thanks to for the AD review. Thanks to , , and for the IESG review.
Contributors
Sunnyvale CA United States of America je_drake@yahoo.com
Ribbon Communications
Tel Aviv Israel ivan.bykov@rbbn.com
Ciena
Ottawa Canada rrokui@ciena.com
Verizon
Dallas TX United States of America luay.jalil@verizon.com
XL Axiata
Jakarta Indonesia benyds@xl.co.id
Rakuten
Bangalore India amitd@arrcus.com
British Telecom
London United Kingdom mojdeh.amani@bt.com
Authors' Addresses HPE
Wien Austria kszarkowicz@juniper.net
Nokia
Rennes France richard.roberts@nokia.com
HPE
London United Kingdom jlucek@juniper.net
Orange
France mohamed.boucadair@orange.com
Telefonica
Ronda de la Comunicacion, s/n Madrid Spain luismiguel.contrerasmurillo@telefonica.com https://lmcontreras.com/