RFC 9889
A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
RFC 9889: A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies ✨
okay bestie, let's get into it 🎀 this RFC is from the IETF (Internet Engineering Task Force), the group that keeps the Internet's protocols running, and it's a 🦋 Informational document, which means it's sharing info and ideas and is not a Standards Track spec. The editors are K. Szarkowicz (HPE, who's also the lead editor 👑), R. Roberts (Nokia), and M. Boucadair (Orange), with co-authors J. Lucek (HPE) and LM. Contreras (Telefonica). It was published in November 2025 and it's ISSN 2070-1721 🌸
This one doesn't obsolete or update any other RFCs, so it's its own little island 🏝️ and it's all about getting 5G network slices to work over the IP/MPLS stuff that service providers already run. Literally no new protocol extensions needed, which is so iconic 💅
The Abstract is basically the vibe check: network slicing is a 3GPP (3rd Generation Partnership Project) feature for mobile networks 📱 and making 5G slicing real means every part of the mobile world needs to pitch in, like the Radio Access Network (RAN), the Core Network (CN), and the Transport Network (TN) 🧚 This doc zooms in on the Transport Network, showing a realization model for IP/MPLS networks that hits the service goals for 5G slicing connectivity, and it reuses a bunch of building blocks service providers already love 🍓
Status of This Memo 📜
This is the official "we're not a standard, we're just sharing" part 🙈 It's informational, not Internet Standards Track. It's an IETF product with IETF community consensus, reviewed publicly, and approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for an Internet Standard though, so check Section 2 of RFC 7841 if you want the full tea ☕
Errata, current status, and feedback info live at https://www.rfc-editor.org/info/rfc9889 💖
Copyright Notice ©️
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. Read those carefully, because they spell out your rights and restrictions. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License 💜
Table of Contents 🗺️
1. Introduction
2. Terminology
2.1. Definitions
2.2. Abbreviations
3. 5G Network Slicing Integration in Transport Networks
3.1. Scope of the Transport Network
3.2. 5G Network Slicing Versus Transport Network Slicing
3.3. Transport Network Reference Design
3.4. Orchestration Overview
3.5. Mapping 5G Network Slices to Transport Network Slices
3.6. First 5G Network Slice Versus Subsequent Slices
3.7. Overview of the Transport Network Realization Model
4. Handoff Between Domains
4.1. VLAN Handoff
4.2. IP Handoff
4.3. MPLS Label Handoff
5. QoS Mapping Realization Models
5.1. QoS Layers
5.2. QoS Realization Models
5.3. Transit Resource Control
6. PE Underlay Transport Mapping Models
6.1. 5QI-Unaware Model
6.2. 5QI-Aware Model
7. Capacity Planning/Management
7.1. Bandwidth Requirements
7.2. Bandwidth Models
8. Network Slicing OAM
9. Scalability Implications
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Example of Local IPv6 Addressing Plan for Network
Functions
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🌈
okay so this doc is all about network slicing for 5G, specifically the connectivity between Network Functions (NFs) spread across multiple domains like edge clouds, data centers, and the Wide Area Network (WAN) 🌍 The approach uses existing IP/MPLS tech (as of publication) to tightly control the connectivity Service Level Agreements (SLAs) offered for 5G Network Slices 💅 So the doc covers the scope of the Transport Network in 5G (Section 3.1), untangles 5G Network Slicing from Transport Network Slicing (Section 3.2), draws the lines around the different orchestration domains (Section 3.4), and figures out the coordination needed between those domains to set up Attachment Circuits (ACs) (Section 3.4.2) 🎀
This work fits the framework in [RFC9543], which describes network slicing for networks built from IETF tech 🦋 Specifically, it shows how RFC 9543 Network Slices get realized inside provider networks and how they get stitched to Transport Network resources at a customer site, in the context of Transport Network Slices (Figure 1) ✨ The realization of an RFC 9543 Network Slice (aka connectivity with performance commitments) involves the provider network and partly the AC, specifically the Provider Edge (PE) side of it 🧚 The doc assumes the customer site is over-provisioned and the distances are short (low latency), so basic QoS and scheduling logic is enough to hit the Service Level Objectives (SLOs) 🍓
|------------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 | |
| +---+ +--+-+ | | | | +-+-+ |
| | +-+--+ +-+--+ | |
| | | | | |
+------------+ +---------------+ +------------+
Figure 1: Transport Network Slice and RFC 9543 Network Slice ScopesThis doc focuses on RFC 9543 Network Slice deployments where the Service Demarcation Points (SDPs) sit at Types 3 and 4 in Figure 1 of [RFC9543] 🌸
The realization approach here usually kicks off when a Network Slice Service request comes in 💖 How that request gets placed for realization, including how it's derived from a 5G Slice Service request, is out of scope 🙈 Mapping between 3GPP and RFC 9543 Network Slice Service stuff (like mapping service parameters) is covered in docs like [NS-APP] 📚
Here's the 5G bit: the 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) to identify slices [TS-23.501]. S-NSSAIs aren't visible to the transport domain though, so 5G domains can expose the 5G Network Slices to transport by mapping them to explicit data plane identifiers (like Layer 2, Layer 3, or Layer 4) 🧚 Passing info between customer sites and provider networks is called the "handoff", and Section 4 lists a set of handoff methods for slice mapping 💅
Unlike approaches that need new protocol extensions (like [NS-IP-MPLS]), this realization model uses building blocks that service provider networks already commonly use (at publication time) 🎀 The model uses (1) L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for logical separation, (2) fine-grained resource control at the PEs, (3) coarse-grained resource control inside the provider network, and (4) capacity planning and management 🦋 More details are in Sections 3.7, 5, 6, and 7 ✨
This model uses a single Network Resource Partition (NRP) (Section 7.1 of [RFC9543]), and applying it to multiple NRPs is out of scope 🌈
Yes, this doc focuses on 5G, but the realizations aren't fundamentally limited to 5G 🫶 It's not meant to be a BCP and it doesn't claim to specify mandatory mechanisms for realizing network slices 💀 The real goal is pragmatic implementation approaches using existing techniques that are readily available and widely deployed 🍓 It also aims to line up the mobile and IETF views of slicing from a realization standpoint 🧚
For a definitive description of 3GPP network architectures, go to [TS-23.501], and [Book-5G] has more details 📚
2. Terminology 🎀
2.1. Definitions 💅
The doc uses the terms defined in [RFC9543] 🦋 Specifically, "Customer" matches [RFC9543] but with the following contextualization (see also Section 3.3):
Customer: 👑 An entity 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 also uses 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 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 this doc, resource control mainly refers to buffer management and the relevant Quality of Service (QoS) functions 💖
"5G Network Slicing" and "5G Network Slice": ✨ These refer to "Network Slicing" and "Network Slice" as defined in [TS-28.530] 🫶
2.2. Abbreviations 💅
okay bestie, here's the whole acronym cheat sheet, so you're never lost when a message is full of letters 🫶
3GPP: 3rd Generation Partnership Project5GC: 5G Core5QI: 5G QoS IndicatorA2A: Any-to-AnyAC: Attachment CircuitAMF: Access and Mobility Management FunctionCE: Customer EdgeCIR: Committed Information RateCS: Customer SiteCN: Core NetworkCoS: Class of ServiceCP: Control PlaneCU: Centralized UnitCU-CP: Centralized Unit Control PlaneCU-UP: Centralized Unit User PlaneDC: Data CenterDDoS: Distributed Denial of ServiceDM: Data ModelDSCP: Differentiated Services Code PointeCPRI: enhanced Common Public Radio InterfaceFIB: Forwarding Information BaseGPRS: General Packet Radio ServicegNB: gNodeBGTP: GPRS Tunneling ProtocolGTP-U: GPRS Tunneling Protocol User PlaneIGP: Interior Gateway ProtocolL2VPN: Layer 2 Virtual Private NetworkL3VPN: Layer 3 Virtual Private NetworkLSP: Label Switched PathMACsec: Media Access Control SecurityMIoT: Massive Internet of ThingsMNO: Mobile Network OperatorMPLS: Multiprotocol Label SwitchingNF: Network FunctionNS: Network SliceNRP: Network Resource PartitionNSC: Network Slice ControllerPE: Provider EdgePIR: Peak Information RateQoS: Quality of ServiceRAN: Radio Access NetworkRIB: Routing Information BaseRSVP: Resource Reservation ProtocolSD: Slice DifferentiatorSDP: Service Demarcation PointSLA: Service Level AgreementSLO: Service Level ObjectiveS-NSSAI: Single Network Slice Selection Assistance InformationSST: Slice/Service TypeSR: Segment RoutingSRv6: Segment Routing version 6TC: Traffic ClassTE: Traffic EngineeringTN: Transport NetworkUP: User PlaneUPF: User Plane FunctionURLLC: Ultra-Reliable Low-Latency CommunicationVLAN: Virtual Local Area NetworkVPN: Virtual Private NetworkVRF: Virtual Routing and ForwardingVXLAN: Virtual Extensible Local Area Network
3. 5G Network Slicing Integration in Transport Networks 🦋
3.1. Scope of the Transport Network ✨
okay so the big 5G 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 [TS-28.530]:
part supporting connectivity within and between CN and RAN parts.the 3GPP management system does not directly control the Transport Network. it's considered a non-3GPP managed system. this is discussed in Section 4.4.1 of [TS-28.530]:
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's frequently segmented, non-uniform, and managed by different entities. for example, Figure 2 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 Section 3.4. 🌸
+----------------------------------+
+----+ 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| | |
| | +--+ +--+ | |
| | | | | |
+-----------------+ +----------+ +--------+
Figure 2: Example of Transport Network Decomposition3.2. 5G Network Slicing Versus Transport Network Slicing 🍓
network slicing means something different in the 3GPP mobile world than in the transport world. you can see the difference in the descriptions below, which lay out the objectives of 5G Network Slicing (Section 3.2.1) and Transport Network Slicing (Section 3.2.2). these descriptions are not meant to be exhaustive.
3.2.1. 5G Network Slicing 📡
in [TS-28.530], 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 come from the TN, RAN, and CN domains together with the underlying infrastructure.
Section 3.1 of [TS-28.530] 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.3.2.2. Transport Network Slicing 🚀
the term "Transport Network Slice" refers to a slice in the Transport Network domain of the 5G architecture. this section explains 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 [TS-28.530].
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 (Section 8 of [RFC9543]). 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. ✨
3.3. Transport Network Reference Design 🎀
Figure 3 shows the reference design used in this document for modeling the Transport Network based on management perimeters (customer vs. provider).
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--------------->
Figure 3: Reference Design with Customer Sites and Provider Networkthe main components in Figure 3 are described in the subsections below. 💖
3.3.1. 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. 🧚
3.3.2. Customer Edge (CE) 🎀
okay bestie, so a CE is the function that gives a customer site (Section 3.3.1) its logical connectivity to the provider network (Section 3.3.3) 💖 That connectivity is enforced at Layer 2 and/or Layer 3, and it's called an Attachment Circuit (AC) (Section 3.3.5). CEs can be TN components like routers, switches, and firewalls, but they can also be 5G NFs, which are elements of the 5G domain like the 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, and they usually control different device configuration perimeters 🫶 A co-managed CE has both PE and CE functions, and there's no strict AC connection, although you could say the AC stitching logic happens inside the CE itself 🙈 The provider manages the AC between the CE and the PE.
This doc also generalizes the CE definition with "distributed CE" 🌈 That means the logical connectivity is realized by configuring multiple devices in the customer domain, so the CE function is spread out. An example is an interconnection using an L3VPN service with a distributed CE made of a switch (SW) in Layer 2 and a router (RTR) in Layer 3, shown in Figure 4. Another example is in Figure 5.
+--------------+ +--------------+
| Customer | | Provider |
| Site | | Network |
| +---------------+ | |
| | | | |
| | +---+ +----+ | +----+ |
| | | | | ================== | |
| | | +------------AC----------+ PE | |
| | |RTR| | SW ================== | |
| | +---+ +----+ | +----+ |
| | | | |
| +--Distributed--+ | |
| CE | | |
+--------------+ +--------------+Figure 4: Example of Distributed CE 🍓
In most cases CEs connect to PEs using IP (e.g., via Layer 3 VLAN subinterfaces), but a CE can also connect to the provider network using MPLS (potentially over IP tunnels) or Segment Routing over IPv6 (SRv6) [RFC8986] 🦋 So the CE has awareness of provider service config, like control plane identifiers such as Route Targets (RTs) and Route Distinguishers (RDs) 👑 Even so, the CE is still managed by the customer, and the AC is based on MPLS or SRv6 data plane tech. The complete termination of the AC within the provider network may happen on distinct routers, and that's another example of a distributed PE. Service-aware CEs are used in the deployments discussed in Sections 4.3.2 and 4.3.3 💅
3.3.3. Provider Network 🌸
A provider uses a provider network to interconnect customer sites. This document assumes the provider network is based on IP, MPLS, or both 🧚
3.3.4. 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 (Section 3.3.5).
This doc generalizes the PE definition with "distributed PE" ✨ The logical connectivity is realized by configuring multiple devices in the provider network (i.e., the Provider Orchestration Domain), so the PE function is distributed.
An example of a distributed PE is the "managed CE service" 🌟 A provider delivers VPN services using CEs and PEs that are both managed by the provider (example (i) in Figure 5). The managed CE can also be a Data Center Gateway, as in example (ii) of Figure 5. A provider-managed CE may attach to the CEs of multiple customers, but this device is still part of the provider network 🙌
+--------------+ +--------------+
| 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 CEFigure 5: Examples of Distributed PE 🎀
In the sections that follow, the terms "CE" and "PE" are used for both single and distributed devices 💖
3.3.5. Attachment Circuit (AC) 💅
The AC is the logical connection that attaches a CE (Section 3.3.2) to a PE (Section 3.3.4). A CE is connected to a PE via one or multiple ACs.
This doc uses the concept of distributed CE and PE (Sections 3.3.2 and 3.3.4) to consolidate a CE/AC/PE definition that's consistent with the orchestration perimeters (Section 3.4). The CEs and PEs delimit the customer and provider orchestration domains, respectively, and an AC interconnects these domains 🌈
For consistency with the terminology used in AC data models (e.g., the data models defined in [RFC9834] and [RFC9835]), this doc assumes an AC is configured on a "bearer", which represents the underlying connectivity. For example, the bearer is illustrated with "=" in Figures 4 and 5 🦋
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 setting up such an AC does not require any coordination between the customer and provider orchestration domains 🌸
🙈 Note: To keep the figures simple, only one AC and single-homed CEs are drawn, and the underlying bearers are left out of most of them. This doc does NOT rule out multiple ACs between a CE and a PE, or CEs that are attached to more than one PE.
3.4. Orchestration Overview 🌈
3.4.1. 5G End-to-End Slice Orchestration Architecture 🧚
okay bestie, this section drops a big-picture framework for orchestrating a 5G end-to-end slice (a.k.a. a 5G Network Slice) 💅 and it zooms in on the TN parts. It helps mark where the realization scope of RFC 9543 Network Slices begins and ends, and it spots the interactions you need to make these slices happen ✨
This framework lines up with the management coordination example in Figure 4.7.1 of [TS-28.530] 🌸
In Figure 6, there's a 5G End-to-End Network Slice Orchestrator (5G NSO) 👑 that's in charge of orchestrating 5G Network Slices end-to-end. The details of the 5G NSO are out of scope for this doc 🙈 The realization of the 5G Network Slices spans RAN, CN, and TN. Like we said in Section 3.1, the RAN and CN are under the 3GPP management system, but the TN is not. So the TN orchestration gets split into two subdomains, following the reference design in Section 3.3:
- Provider Network Orchestration Domain (simply referred to as "Provider Orchestration Domain"): As defined in [RFC9543], the provider leans on a Network Slice Controller (NSC) to manage and orchestrate RFC 9543 Network Slices in the provider network. This framework lets you manage connectivity with SLOs 💜
- Customer Site Orchestration Domain (simply referred to as "Customer Orchestration Domain"): Orchestrating the TN elements at customer sites leans on a whole squad of controllers (e.g., Fabric Manager, Element Management System, or Virtualized Infrastructure Manager (VIM)) 🎀
A Transport Network Slice relies on resources that can involve both the provider and customer TN domains. The juicy details are in Section 3.4.2 🦋
A Transport Network Slice might be seen as a variant of the horizontal composition of network slices mentioned in Appendix A.6 of [RFC9543] ✨
.---------.
| 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-----------|
Figure 6: 5G End-to-End Slice Orchestration with TNThe various orchestrations in Figure 6 cover the 3GPP's Network Slice Subnet Management Function (NSSMF), mentioned for instance in Figure 5 of [NS-APP] 🧠
3.4.2. Transport Network Segments and Network Slice Instantiation 🌈
The concept of distributed PE (Section 3.3.4) treats the CE-based SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2) as SDP Types 3 or 4 in this document 💖
In the architecture from Section 3.4.1, the connectivity between NFs can be broken down 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 that case, the AC connects the NF to a PE.
- Its realization 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. Its realization is controlled by an NSC (Section 6.3 of [RFC9543]).
- Attachment Circuit: Orchestrating this segment relies partially on an NSC, for configuring the AC on the PE customer-facing interfaces, and on the Customer Site Orchestration, for configuring the AC on the CE.
- PEs and CEs 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.). So 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 key to automating the overall service provisioning 🫶
- Aligned with [RFC8969], 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 🦋
Figure 7 is a basic example of a Layer 3 CE-PE link realization with shared network resources (such as VLAN IDs and IP prefixes). These get passed between orchestrators via a dedicated interface, e.g., the Network Slice Service Model (NSSM) [NSSM] or Attachment Circuits as a Service (ACaaS) [RFC9834] 👑
.-------------. .----------------.
| | | 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 -----------|
Figure 7: Coordination of Transport Network Resources for AC
Provisioning3.5. Mapping 5G Network Slices to Transport Network Slices ✨
okay so bestie, there are a few different ways you can map 5G Network Slices onto Transport Network Slices, and they're all giving different vibes 💅
1-to-N mapping: one 5G Network Slice gets mapped to multiple Transport Network Slices 🦋 Figure 8 shows this one, where a single 5G Enhanced Mobile Broadband (eMBB) network slice gets split so the 5G control plane and user plane each have their own Transport Network Slice. The really important bit is that this mapping can be an interim step on the way to M-to-N mapping 🌸 more details on that scheme are in Section 3.6.
M-to-1 mapping: multiple 5G Network Slices share the same Transport Network Slice 🫶 in this case, the Service Level Agreement (SLA) differentiation between slices is handled entirely at the 5G control plane, for example through smart placement strategies. Figure 9 is the example here: a UPF for the Ultra-Reliable Low-Latency Communication (URLLC) slice gets set up at the edge cloud, close to the gNB CU-UP, so latency and jitter stay under control 🔥 meanwhile the 5G control plane and the UPF for the eMBB slice live in the regional cloud.
M-to-N mapping: this one combines both approaches, with a mix of shared and dedicated associations 🌈
In this scenario, some of the Transport Network Slices can be shared by multiple 5G Network Slices (for example, the control plane Transport Network Slice is shared by several 5G Network Slices) ✨
In practice, for operational and scaling reasons, M-to-N mapping is typically used, with M much greater than N 👑
+---------------------------------------------------------------+
| 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 |
+------------------------------------+
Figure 8: 1-to-N Mapping (Single 5G Network Slice to Multiple
Transport Network Slices)
+-------------+
| Edge Cloud |
| +---------+ |
| |UPF_URLLC| |
| +-----+---+ |
| | |
+-------|-----+
|
+---------------+ +-------|----------------------+
| | | | |
| Cell Site | | +-----+--------------------+ | +--------------+
| | | | | | | Regional |
| +-----------+ | | | | | | Cloud |
| |CU-UP_URLLC+-----+ Transport Network | | | +----------+ |
| +-----------+ | | | Slice ALL +-----+ 5GC CP | |
| | | | | | | +----------+ |
| +-----------+ | | | | | | |
| |CU-UP_eMBB +-----+ | | | +----------+ |
| +-----------+ | | | +-----+ UPF_eMBB | |
+---------------+ | | | | | +----------+ |
| +--------------------------+ | | |
| | +--------------+
| Transport Network |
+------------------------------+
Figure 9: M-to-1 Mapping (Multiple 5G Network Slices to Single
Transport Network Slice)Note that the way this mapping actually plays out depends on several factors 💖 like the real business cases, the NF vendor capabilities, the NF vendor reference designs, and even service provider or legal requirements 🎀
Mapping approaches that keep the 5G Network Slice identification in the TN (like the approach in Section 4.2) may make it simpler to map Transport Network Slices back to 5G Network Slices 🧚 however, those considerations aren't detailed in this document, because they're the responsibility of the 3GPP orchestration 💜
3.6. First 5G Network Slice Versus Subsequent Slices 🌸
okay so an operational 5G Network Slice has both 5G control plane and user plane capabilities 🫶 for example, in some deployments with a slice based on a split CU in the RAN, both the CU-UP and CU-CP might need to be deployed, along with the interfaces E1, F1-c, F1-u, N2, and N3, which are carried in the TN 🦋 so creating the "first slice" can follow special logic that doesn't apply to the slices that come after it ✨ Figure 10 shows this. The first 5G Network Slice uses NF-CP and NF-UP functions along with two Transport Network Slices, one for the control plane and one for the user plane (TNS-CP and TNS-UP1). Then, in lots of cases, a second slice only needs a new UPF (NF-UP2) plus a dedicated user plane Transport Network Slice (TNS-UP2) 💅 the control plane of the first slice gets updated to include the second slice, so the Transport Network Slice (TNS-CP) and the Network Functions (NF-CP) are shared 🔥
The model where the control plane is shared across multiple slices is likely to be common 👑 but it's not mandatory 🙈 deployment models with a separate control plane for each slice are also possible 🌈
Section 6.1.2 of [NG.113] 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 😭
(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 |
+---------------------------------------------------------------+
Figure 10: First and Subsequent Slice DeploymentTransport Network Slice mapping policies can be enforced by an operator (for example, handed to a TN Orchestration or 5G NSO) 🧚 they decide whether existing Transport Network Slices can be reused when a new Slice Service creation request comes in 💜 having that policy is meant to automate the realization of 5G Network Slices and cut down on the realization delay that extra cycles waiting for operator validation would add 🎀
3.7. Overview of the Transport Network Realization Model ✨
okay so this is where the realization model comes in and it's giving building blocks 🧱💖 the figure is Figure 11, and the building blocks are:
bestie, this realization model assumes Layer 3 delivery for midhaul and backhaul transport connections, and Layer 2 or Layer 3 delivery for fronthaul connections. Enhanced Common Public Radio Interface (eCPRI) [ECPRI] supports both delivery models 🦋. L2VPN/L3VPN service instances might be used as a basic form of logical slice separation. Plus, using service instances adds an additional outer header (because packets get encapsulated and decapsulated at the nodes hosting the service instances), which gives clean discrimination between 5G QoS and TN QoS, as explained in Section 5 🫶.
Note that a bunch of L2VPN mechanisms can be considered for slice realization. This is a non-comprehensive list, so it's not everything, just the highlights 💅:
- Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
- Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664])
- Various flavors of EVPNs:
The use of VPNs for realizing network slices is briefly described in Appendix A.4 of [RFC9543] 📚.
- Fine-grained resource control at the PE:
this one is sometimes called "admission control" or "traffic conditioning" 🎀. The main purpose is enforcing the bandwidth contract for the slice right at the edge of the provider network, where traffic is handed off between the customer site and the provider network. Iconic. 👑
The method 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 get dropped somewhere inside the provider network if congestion happens 💀. In the egress direction at the PE node, hierarchical schedulers/shapers can be deployed, providing guaranteed rates per slice, plus 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 Figure 11) that spans the entire provider network 🌈. Transit nodes in the provider network do not maintain any state of individual slices, which is so chill for them 😌. 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 get 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 here is to make sure the provider network capacity can be used without causing any bottlenecks 🔥. The methods can range from careful network planning that ensures a more or less equal traffic distribution (i.e., equal-cost load balancing) all the way to advanced TE techniques, with or without bandwidth reservations, that force more consistent load distribution, even in non-ECMP-friendly network topologies 🫶. See also Section 8 of [RFC9522].
..............................................
: 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
Figure 11: Resource Allocation Slicing Model with a Single NRPThe P nodes shown in Figure 11 are routers that do not interface with customer devices 🦋. See Section 5.3.1 of [RFC4026].
This document does not describe in detail how to manage an L2VPN or L3VPN, because that's already super well-documented 📖. For example, the reader may refer to [RFC4176] and [RFC6136] for those details.
4. Handoff Between Domains 🦋
okay so the 5G control plane relies on 32-bit S-NSSAIs for slice identification 🎀. The S-NSSAI is not visible to the transport domain, though 🙈. So instead, 5G network functions can expose the 5G Network Slices to the transport domain by mapping them to explicit Layer 2 or Layer 3 identifiers, like 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 are provided in [NS-APP] ✨.
4.1. VLAN Handoff 🎀
in this option, the RFC 9543 Network Slice (the one fulfilling the connectivity requirements between NFs that belong to a 5G Network Slice) gets represented at an SDP by a VLAN ID, or double VLAN IDs (commonly known as QinQ), as shown in Figure 12 🌸.
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
Figure 12: Example of 5G Network Slice with VLAN Handoff
Providing End-to-End ConnectivityEach VLAN represents a distinct logical interface on the ACs, so it's possible 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 always be possible. So 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 subnets for every slice on every AC 😭.
4.2. IP Handoff ✨
okay so in this option, we make an explicit mapping between source/destination IP addresses and a slice's specific S-NSSAI 🫶 The mapping can have either local (e.g., pertaining to a single NF attachment) or global TN significance. There are a bunch of ways to make it happen, 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) [RFC8986]
- Use of a deterministic algorithm to map S-NSSAI to an IP subnet, prefix, or pools. For example, adaptations to the algorithm defined in [RFC7422] 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). that's main character energy for an IP address 💅
One example of the IP handoff is when the slices in the TN domain get instantiated using IP tunnels (e.g., IPsec or GTP-U tunnels) set up between NFs, as shown in Figure 13. The transport for a single 5G Network Slice might be built from multiple tunnels, since a typical 5G Network Slice has lots of 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 get set up from the shared NF, and each tunnel represents a single slice 🦋
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
* SDPFigure 13: Example of 5G Network Slice with IP Handoff Providing End-to-End Connectivity
As opposed to the VLAN handoff case (Section 4.1), there is no logical interface representing a slice on the PE, so all slices get handled within a single service instance 🎀 The IP and VLAN handoffs are not mutually exclusive, so they could be used concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping table similar to the one in the VLAN handoff solution is needed (Section 4.1). 😭
The mapping table can get simpler 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 for NFs that is not disclosed to on-path nodes. IP forwarding is not altered by this method and is still achieved following BCP 198 [RFC7608]. 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. ngl this is the part that would make me panic 💀
An example of a local IPv6 addressing plan for NFs is provided in Appendix A. 🫶
4.3. 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. So the packet gets encapsulated outside the provider network with MPLS encapsulation or MPLS-in-UDP encapsulation [RFC7510], depending on the capability of the customer site, with the service label depicting the slice 🌸
There are three major methods (based upon Section 10 of [RFC4364]) for interconnecting MPLS services over multiple service domains:
- Option A (Section 4.3.1): VRF-to-VRF connections.
- Option B (Section 4.3.2): Redistribution of labeled VPN routes with next-hop change at domain boundaries.
- Option C (Section 4.3.3): Redistribution of labeled VPN routes without next-hop change and redistribution of labeled transport routes with next-hop change at domain boundaries.
Figure 14 shows the use of service-aware CE (Section 3.3.2) for the deployment discussed in Sections 4.3.2 and 4.3.3 🍓
+--------------+ +--------------+
| Customer | | Provider |
| Site | | Network |
| | | |
| | | |
| | <------MP-BGP-----> | |
| +--+-+ +-+--+ |
| | | MPLS-based AC | | |
| | CE +------------------+ PE | |
| +--+----+--+ | | |
| | VRF foo | +-+--+ |
+--------+----------+ +--------------+Figure 14: Example of MPLS-Based Attachment Circuit
4.3.1. Option A 🦋
This option is based on the VLAN handoff, described in Section 4.1. It is not based on the MPLS label handoff. Lowkey a callback to the VLAN drama 🙈
4.3.2. 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 (Figure 15, 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 (Figure 15, 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 doesn'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 🧚
<------ <------ <------
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)
* SDPFigure 15: Example of MPLS Handoff with Option B
MPLS labels are allocated dynamically in Option B deployments. At the domain boundaries, service prefixes get reflected with next-hop self (nhs), and a new label is dynamically allocated, as shown in Figure 15 (e.g., labels A, A', and A" for the first depicted slice). So for any slice-specific per-hop behavior at the provider network edge, the PE needs to figure out 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 Figure 15, 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 done 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 Figure 15. In that case, the route target extended community (Section 4 of [RFC4360]) 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 [RFC1997]) 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 the provider network is possible 🌈
4.3.3. Option C 🦋
Okay so Option B has you swapping service prefixes between customer sites and the provider network 🫶 which is lowkey a scaling nightmare in big 5G deployments, because the PE node has to carry all the service prefixes 💀 Option C fixes this by only exchanging service prefixes between customer sites. That means the provider network gets offloaded from carrying, propagating, and programming forwarding entries for service prefixes ✨ the provider is literally off the hook 👑
Option C exchanges service prefixes over multi-hop BGP sessions between customer sites, without changing the NEXT_HOP BGP attribute 💅 Also, IPv4/IPv6 labeled unicast (SAFI-4) host routes, which serve as the NEXT_HOP for service prefixes, get exchanged over direct single-hop BGP sessions between adjacent nodes in a customer site and a provider network, as shown in Figure 16 🌸 So a node in a customer site ends up doing hierarchical next-hop resolution 🧚
Here's the whole vibe 🎀
<----------------------------------------
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 Figure 16: Example of MPLS Handoff with Option CThis setup needs an end-to-end Label Switched Path (LSP) running from a packet's ingress node inside one customer site all the way 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 get programmed in the data plane 💜 And there's no extra "labeled transport" protocol on the AC (e.g., no LDP, RSVP, or SR), so nothing else to babysit 🙌
Packets go over the AC with the IPv4/IPv6 labeled unicast label as the top label, and the service label sitting deeper in the label stack 🥞 In Option C, the service label isn't used for forwarding lookup on the PE. This seriously lowers the scaling pressure on PEs 🌈 since they only need to program forwarding entries for IPv4/IPv6 labeled unicast host routes, which act as the NEXT_HOP for service prefixes. And because one IPv4/IPv6 labeled unicast host route stands for one customer site, no matter how many slices that site has, the number of forwarding entries on a PE drops a lot 📉✨
For any slice-specific per-hop behavior at the provider network edge, as described in detail in Section 3.7, the PE needs to figure out which label in the packet represents which slice 🔍 One way to do this, for example, is to allocate non-overlapping service label ranges for each slice and then use those ranges for slice identification on the PE 🎀
5. QoS Mapping Realization Models 🌈
5.1. QoS Layers
The resources are managed through various QoS policies deployed in the network 🗂️ QoS mapping models that support 5G slicing connectivity implemented over a packet switched provider network use two layers of QoS, and we'll break those down in the following subsections 💖
5.1.1. 5G QoS Layer
QoS treatment is indicated in the 5G QoS layer by the 5G QoS Indicator (5QI), as defined in [TS-23.501] 📘 The 5QI is an identifier 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 📡 Since 5QI applies to the RAN domain, it's not visible to the provider network 🙈 So if you want 5QI-aware treatment 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 too 🦋 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 a 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 [MAPPING] 📚
Each Slice Service might have flows with multiple 5QIs 🌸 5QIs (or, more precisely, the 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" 💅
5.1.2. Transport Network (TN) QoS Layer
Control of the TN resources and traffic scheduling/prioritization on provider network transit links is based on a flat (non-hierarchical) QoS model in this network slice realization 🧁 That is, RFC 9543 Network Slices get dedicated resources (e.g., QoS queues) at the edge of the provider network (at SDPs), while all RFC 9543 Network Slices share resources (sharing QoS queues) on the transit links of the provider network 🤝 Typical router hardware can support up to 8 traffic queues per port, so 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 🏷️ That indicator may be a DSCP or an MPLS Traffic Class (TC). This layer of QoS is referred to as "TN QoS Class" ("TN QoS" for short) in this document ✨
5.2. 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 asking the provider network for per-5QI differentiated treatment 🙃 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 slicing, with initial phases using only per-slice, but not per-5QI, differentiated treatment in the TN domain (see Annex F of [O-RAN.WG9.XPSAAS]) 🌷
So 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 🦋
5.2.1. 5QI-Unaware Model ✨
Okay bestie, in the 5QI-unaware model the DSCP values in packets coming in from NF at SDP just get ignored 🙈 The provider network has no QoS differentiation at the 5G QoS Class level. The entire RFC 9543 Network Slice gets mapped to a single TN QoS Class, which means a single QoS queue on the routers in the provider network. It's giving minimalism 🧚
With only a few deployed 5G Network Slices (like just two, eMBB and MIoT), you can dedicate a separate QoS queue to each slice on the transit routers in the provider network 🌸 But once private/enterprise slices show up, the number of 5G Network Slices (and so the RFC 9543 Network Slices) keeps climbing. Then one QoS queue on the transit links ends up serving multiple slices with similar characteristics. Real talk, QoS enforcement on transit links is fully coarse-grained: one NRP, with all the RFC 9543 Network Slices sharing resources. Check out Figure 17 🦋
+----------------------------------------------------------------+
+-------------------. 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)
Figure 17: Mapping of Slice to TN QoS (5QI-Unaware Model)So when the IP traffic gets handed over at the SDP from the AC to the provider network, the PE encapsulates it into MPLS (if MPLS transport is used in the provider network) or IPv6, optionally with some extra headers (if SRv6 transport is used in the provider network). Then it sends the packets out on the provider network transit link 💖
The original IP header keeps its DSCP marking (which gets ignored in the 5QI-unaware model), while the new header (MPLS or IPv6) carries the QoS marking related to the TN Class of Service (CoS). That's the MPLS Traffic Class bits for MPLS encapsulation, or DSCP for SRv6/IPv6 encapsulation. Based on that TN CoS marking, per-hop behavior for all RFC 9543 Network Slices gets executed on the provider network transit links. Provider network transit routers do not evaluate the original IP header for QoS-related decisions. Figure 18 shows this for MPLS encapsulation and Figure 19 shows it for SRv6 encapsulation 👑
+--------------+
| MPLS Header |
+-----+-----+ |
|Label|TN TC| |
+--------------+ - - - - - - - - +-----+-----+--+
| IP Header | |\ | IP Header |
| +-------+ | \ | +-------+
| |5G DSCP|---------+ \ | |5G DSCP|
+------+-------+ \ +------+-------+
| | \ | |
| | \ | |
| | | |
| Payload | / | Payload |
|(GTP-U/IPsec) | / |(GTP-U/IPsec) |
| | / | |
| |---------+ / | |
| | | / | |
| | |/ | |
+--------------+ - - - - - - - - +--------------+
Figure 18: QoS with MPLS Encapsulation
+--------------+
| IPv6 Header |
| +-------+
| |TN DSCP|
+------+-------+
: Optional :
: IPv6 :
: Headers :
+--------------+ - - - - - - - - +-----+-----+--+
| IP Header | |\ | IP Header |
| +-------+ | \ | +-------+
| |5G DSCP|---------+ \ | |5G DSCP|
+------+-------+ \ +------+-------+
| | \ | |
| | \ | |
| | | |
| Payload | / | Payload |
|(GTP-U/IPsec) | / |(GTP-U/IPsec) |
| | / | |
| |---------+ / | |
| | | / | |
| | |/ | |
+--------------+ - - - - - - - - +--------------+
Figure 19: QoS with SRv6 EncapsulationFrom a QoS perspective, both options are pretty similar 🫶 But there's one difference that matters. The MPLS TC is only 3 bits (8 possible combinations), while DSCP is 6 bits (64 possible combinations). So SRv6 gives you way more flexibility for TN CoS design, especially with soft policing that uses in-profile and out-of-profile traffic, as discussed in Section 5.2.1.1. Main character energy 💅
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 ⭐
5.2.1.1. Inbound Edge Resource Control ✨
okay so the main thing with inbound provider network edge resource control is per-slice traffic volume enforcement 💅 This is often called "admission control" or "traffic conditioning" (iykyk). The goal is to make sure traffic above the contracted rate gets dropped or deprioritized, depending on the business rules, right at the edge of the provider network 🚧 Combined with appropriate network capacity planning/management (Section 7), this is required to get proper isolation between slices in a scalable way 🫶 That means one slice's traffic has no influence on the others, even if that slice is misbehaving (think Distributed Denial-of-Service (DDoS) attacks or node/link failures) and blasting traffic above its contracted rates 😭 main character energy for the good slices, no cap.
The slice rates can be characterized with the following parameters [NSSM]:
- 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 them, the provider network's inbound policy can be implemented using one of these options:
- 1r2c (single-rate two-color) rate limiter 🎀 This is the most basic rate limiter, described in Section 2.3 of [RFC2475] (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 TCorDSCP TNmarkings) 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 [RFC2698], and an improved version is defined in [RFC4115]. In essence, the traffic is assigned to one of 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 [RFC4115], compared to [RFC2698], 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 Figure 20 🌸
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 | |
| | |
+---|--+ |
+---------+
Figure 20: Ingress Slice Admission Control (5QI-Unaware Model)5.2.1.2. 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. The 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 [RFC7806] 📚
Figure 21 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. 🍓
+---------+ 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 '--|--------------------------' /|\
| +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| |
+---------+
Figure 21: Ingress Slice Admission Control (5QI-Unaware Model) -
Output5.2.2. 5QI-Aware Model ✨
Okay bestie, so in the 5QI-aware model 🧚 a potentially huge number of 5G QoS Classes get represented by the DSCP that NFs set (the architecture scales to thousands of 5G Network Slices 🤯). Those get mapped, or multiplexed, into up to 8 TN QoS Classes that the provider network's transit equipment uses. Figure 22 shows the whole vibe 💅
+---------------------------------------------------------------+
+-------------------+ 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)
Figure 22: Mapping of Slice 5G QoS to TN QoS (5QI-Aware Model)So here's the tea 🫖 when there are loads of 5G Network Slices, the number of possible 5G QoS Classes is way bigger than the number of TN QoS Classes. That means several 5G QoS Classes with similar characteristics (potentially even from different slices) get grouped together under common operator-defined TN logic and end up in the same TN QoS Class once they're transported across the provider network 🎀 Basically, common Per-Hop Behavior (PHB) [RFC2474] runs on the transit provider network routers for every packet in that group. Figure 23 has an example of how this looks. A provider may also decide to implement Diffserv-Intercon PHBs at the boundaries of its network domain [RFC8100] 🌈
Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP, queue, etc.) are provided for illustration purposes only and should not be considered as deployment guidance.
+--------------- 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 +-----+ |
| '-----' '-------' | | | '-------' | |
+------------------------+ | '----------' |
+--------------------------------------+
Figure 23: Example of 3GPP QoS Mapped to TN QoSNow, the 3GPP SDO's current progress (Release 19) and O-RAN aren't expecting the 5QI-to-DSCP mapping to be done per slice 🙌 The 5QI-to-DSCP mapping can vary from one 3GPP slice to another, but it doesn't have to. That's why the mapping of 5G QoS DSCP values to TN QoS Classes may end up being pretty common 💜
Like in the 5QI-unaware model, the original IP header keeps the DSCP marking that corresponds to the 5QI (5G QoS Class) 🦋 Meanwhile, the new header (MPLS or IPv6) carries the QoS marking related to the TN QoS Class. Based on that TN QoS Class marking, the per-hop behavior for all the aggregated 5G QoS Classes from all RFC 9543 Network Slices gets executed on the provider network transit links. The provider network transit routers never look at the original IP header for QoS-related decisions 🙈 That original DSCP marking is used at the PE for fine-grained inbound/outbound enforcement per slice and per 5G QoS Class on the AC. Main character energy for the PE, honestly 👑
In the 5QI-aware model, compared to the 5QI-unaware model, provider network edge resources are controlled in an even more fine-grained way 🔥 There's dedicated resource allocation for each RFC 9543 Network Slice, and for a number of traffic classes within each slice (most commonly up to 4 or 8 traffic classes, depending on the hardware capability of the equipment) ✨
5.2.2.1. Inbound Edge Resource Control ✨
Okay so, compared to the 5QI-unaware model, admission control (traffic conditioning) in the 5QI-aware model is way more granular 🔍 💅. It doesn't just enforce per-slice capacity constraints, it can also enforce the constraints per 5G QoS Class within each slice. Literally so precise 🎀
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 Figure 24. Here's the thing bestie: if a premium class doesn't consume all of its available class capacity, it cannot be reused by a non-premium class (i.e., best-effort). Not me being strict about it 🙈
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 | |
| | |
+--|---+ |
+---------+
Figure 24: Ingress Slice Admission Control (5QI-Aware Model)The second option combines the advantages of the 5QI-unaware model (per-slice admission control) with per-traffic-class admission control, as outlined in Figure 25. 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 Figure 25. 🦋✨
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 | |
'-' | | |
+--|---+ |
+---------+
Figure 25: Ingress Slice Admission Control (5QI-Aware Model) -
Hierarchical5.2.2.2. Outbound Edge Resource Control 💜
Figure 26 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. Lowkey the main rule to remember 🫶
+---------+ 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 '-----------------------------' /|\
| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
+---------+
Figure 26: Egress Slice Admission Control (5QI-Aware Model)5.3. Transit Resource Control 🚂
Transit resource control is much simpler than edge resource control in the provider network. As outlined in Figure 22, 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 18 and 19) 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. Main character energy 👑
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 Section 5.2.1.1) or in non-premium (best-effort) classes. Capacity planning and management, as described in Section 7, ensures that enough capacity is available to fulfill all approved slice requests. Okay that's the whole vibe 🌈💖
6. PE Underlay Transport Mapping Models ✨
The PE underlay transport (underlay transport, for short) is a specific path forwarding behavior between PEs 🛣️ It's there to deliver packets in a way that matches the matching SLOs. This step is all about controlling which paths packets take between PEs, and it doesn't depend on how the underlying network resources are partitioned 💖
okay so, TN QoS Classes and underlay transport are each about different engineering goals, and that's the part people mix up 🙈 For example, a TN domain can run with 8 TN QoS Classes (that's 8 hardware queues in the routers 🔥) and two underlay transports. One could be a latency-optimized underlay transport that uses link-latency metrics for path calculation, and the other could be an underlay transport that follows IGP metrics. The TN QoS Class decides the per-hop behavior while packets are crossing the provider network, and the underlay transport decides which paths packets take through the provider network based on what the operator needs 🦋 That path can be optimized or constrained, bestie.
A network operator can define multiple underlay transports inside a single NRP ✨ An underlay transport can be realized in several ways, including (but not limited to) these:
- A mesh of RSVP-TE [RFC3209] or SR-TE [RFC9256] tunnels, created with specific optimization criteria and constraints. For example, mesh "A" might hold tunnels optimized for latency, and mesh "B" might hold tunnels optimized for high capacity 🌈
- A Flex-Algorithm [RFC9350] 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 [IEEE802.1AE]), or one that 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) [RFC9182] and the L2VPN Network Model (L2NM) [RFC9291] 💅
Also, underlay transports may be realized using separate NRPs. Honestly though, that approach is left out of scope given where the technology is at the time of writing this document 🙃
Just like the QoS mapping models in Section 5, both the 5QI-unaware and 5QI-aware models are defined for mapping to underlay transports at the ingress PE 🎀 Basically, entire slices can be mapped to underlay transports without any 5G QoS consideration (that's the 5QI-unaware model). Or flows with different 5G QoS Classes, even from the same slice, can be mapped to different underlay transports (that's the 5QI-aware model). Main character energy either way 👑
Figure 27 shows a simple network with two underlay transports. Each one uses a mesh of TE tunnels, with or without a Path Computation Element (PCE) [RFC5440], and with or without per-path bandwidth reservations 🦋 Section 7 goes into detail about the different bandwidth models that can be deployed in the provider network. Realizing or orchestrating underlay transports is out of scope for this document though, so we're not going there 🙈
+---------------+ +------+
| Ingress PE | +------------------------------->| PE-A |
| | | +-------------------------->>| |
| | | | +------+
| +----------+ | | +---------------------+
| | | | | |
| | x------+ +---------------------+
| |Underlay x----------|-------------+ +------+
| |Transport x----------)--+ +------------->| PE-B |
| | A x-------+ | | +---+ +------>>| |
| +----------+ | | | | | | | +------+
| | | | | | +---------+
| +----------+ | | | | |
| | | | | | | | +------+
| | o-------)--+ +--)--------------------->| PE-C |
| |Underlay o-------|--------+ +---->>| |
| |Transport o-------|-----------------+ | +------+
| | B o-----+ +---------------+ | |
| | | | | | | |
| +----------+ | | +---+ +---+ | +------+ +------+
| | | | | | | +-------------->| PE-D |
+---------------+ +---+ +---+ +--------------->>| |
+------+Figure 27: Example of Underlay Transport Relying on TE Tunnels
For illustration purposes, Figure 27 only shows single tunnels per underlay transport for an (ingress PE, egress PE) pair 💜 In reality, there might be multiple tunnels within a single underlay transport between any pair of PEs, so don't let the picture fool you 😭
6.1. 5QI-Unaware Model
As we covered in Section 5.2.1, in the 5QI-unaware model the provider network doesn't take 5G QoS into account while it executes the per-hop behavior 🌸 The entire slice gets mapped to a single TN QoS Class, so the whole slice gets the exact same per-hop behavior, no exceptions. In the 5QI-unaware PE underlay transport mapping model, the same idea applies: the entire slice is mapped to a single underlay transport, as shown in Figure 28 🧚
+-------------------------------------------+
|.. .. .. .. .. .. . |
: AC : PE |
: .--------------. : |
: | SDP | : |
: | +----------+ | : |
: | | NS 1 +-----------+ |
: | +----------+ | : | |
: '--------------' : | |
: .--------------. : | +---------+ |
: | SDP | : | | | |
: | +----------+ | : | |Underlay | |
: | | NS 2 +-------+ +--->Transport| |
: | +----------+ | : | | | A | |
: '--------------' : | | | | |
: .--------------. : | | +---------+ |
: | SDP | : | | |
: | +----------+ | : | | |
: | | NS 3 +-------+ | |
: | +----------+ | : | | +---------+ |
: '--------------' : | | | | |
: .--------------. : | | |Underlay | |
: | SDP | : +---)--->Transport| |
: | +----------+ | : | | | B | |
: | | NS 4 +-------+ | | | |
: | +----------+ | : | +---------+ |
: '--------------' : | |
: .--------------. : | |
: | SDP | : | |
: | +----------+ | : | |
: | | NS 5 +-----------+ |
: | +----------+ | : |
: '--------------' : |
'.. .. .. .. .. .. .' |
+-------------------------------------------+Figure 28: Mapping of Network Slice to Underlay Transport (5QI-Unaware Model)
6.2. 5QI-Aware Model
In the 5QI-aware model, traffic can be mapped to underlay transports at the granularity of 5G QoS Class 🦋 Since the potential number of underlay transports is limited, packets from multiple 5G QoS Classes with similar characteristics get mapped to a common underlay transport, as shown in Figure 29 💖
+---------------------------------------------+
|.. .. .. .. .. .. . |
: 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 | : |
: '--------------' : |
'.. .. .. .. .. .. ' |
+---------------------------------------------+Figure 29: Mapping of Network Slice to Underlay Transport (5QI-Aware Model)
7. Capacity Planning/Management ✨
7.1. Bandwidth Requirements 💖
Okay bestie, this part is all about what the 5G NSO tells the NSC about how much bandwidth each slice needs 🫶 It's giving spreadsheet energy, but make it cute 🎀
Figure 30 shows three DCs full of network function instances 🧚 There are PEs linking up to them, and those PEs belong to the provider network. The provider network's P-routers and transit links aren't drawn, and neither are the switches and routers inside the customer-site DCs. We're keeping the vibe focused 💅
+-------- 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)
Figure 30: Example of Multi-DC ArchitectureLet's say 5G Network Slice "X" uses some of the network functions across those three DCs 🌸 If the slice has latency requirements, the 5G NSO already factored them in when it picked which NF instances in which DCs get invoked. So the three DCs shown are part of slice "X" because of that placement decision, not some other DCs 👑 For its decision-making, the 5G NSO needs the NSC to share the observed latency between DCs. Ideally, the NSC shows the topology as an abstraction: point-to-point abstracted links between pairs of DCs, with the associated latency and, optionally, delay variation and link-loss values 🦋 It would be super valuable to have a way for the 5G NSO to tell the NSC which DC-pairs it cares about for these metrics. There could be thousands of DCs, but the 5G NSO only wants metrics for a small slice of all the possible pairs, meaning the ones in the same region of the provider network 😭 How the info actually gets conveyed is out of scope for this document, so that's a later problem bestie 🙈
Now Table 1 shows the bandwidth demand matrix for slice "X" 📊 Inside the slice, several NF instances might be sending traffic from DCi to DCj. The 5G NSO adds all those demands up into one number, though. For example, "NF1A" and "NF1B" in "DC 1" might both be sending to multiple NFs in "DC 2", but the traffic matrix only shows one value for it: the total bandwidth slice "X" needs from "DC 1" to "DC 2", which is 8 units 🍓 Each row's right-most column shows the total traffic leaving a given DC into the Transport Network, no matter the destination DC. This number can be less than the sum of that row's DC-to-DC demands, because not every NF is going to be sending at its max rate at the same time 💅 For example, the total traffic from "DC 1" for slice "X" is 11 units, which is less than the DC-to-DC demands added up in that row (13 units). Also, as Section 5 explains, a slice may have per-QoS class bandwidth requirements and may have CIR and PIR limits. That isn't in this example, but the same principles apply if it does ✨
+=========+======+======+======+===============+
| 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 |
+---------+------+------+------+---------------+
Table 1: Inter-DC Traffic Demand Matrix
(Slice X)The YANG data model defined in [NSSM] can carry everything in the traffic matrix over to an NSC 🎀 The NSC then applies policers that match the last column of the matrix to the right PE routers, so the bandwidth contract actually gets enforced 🔥 For instance, it applies a policer of 11 units to PE1A and PE1B, which face DC 1, because that's the total bandwidth DC 1 sends into the provider network for slice "X". The controller can also apply shapers in the direction from the TN to the DC if a link inside the DC might get oversubscribed 🌈 Also, a peer NF endpoint of an AC can be identified using "peer-sap-id" as defined in [RFC9408] 🧚
Here's the tea: depending on the bandwidth model used in the provider network (Section 7.2), the other values in the matrix, aka the DC-to-DC demands, might not get applied to the provider network directly 💀 Even so, the NSC might still find that info useful for capacity planning and failure simulation 🌸 On the flip side, if the NSC doesn't use the DC-to-DC demand info, the IETF YANG data models for L3VPN service delivery [RFC8299] or L2VPN service delivery [RFC8466] could be used instead of the YANG data model defined in [NSSM]. Those support conveying the bandwidth info in the right-most column of the traffic matrix, so they're a valid alternative 🦋
The provider network might be built with different kinds of paths. For example, low-latency traffic could get mapped onto a different transport path than other traffic (say a particular Flex-Algorithm, a particular set of TE paths, or a specific queue [RFC9330]), as covered in Section 5 💖 The 5G NSO can use the YANG data model defined in [NSSM] to ask for low-latency transport for a given slice when it's needed 🫶 The catch is that the YANG data models in [RFC8299] or [RFC8466] don't support requesting a particular transport type, like low-latency 😭 One option is to augment those models so they can carry this info. That can be done by reusing the "underlay-transport" construct defined in [RFC9182] and [RFC9291] ✨
7.2. Bandwidth Models 🦋
This section walks through three bandwidth management schemes that could be used in the provider network 🌈 There are lots of possible variations, but each example covers the key points of its scheme. Schemes 2 and 3 use TE, and other TE variations are possible too, as described in [RFC9522] 💅
7.2.1. Scheme 1: Shortest Path Forwarding (SPF) 🚀
Shortest path forwarding follows the IGP metric 🛣️ Since some slices will probably have latency SLOs, the IGP metric on each link can be set in proportion to that link's latency 💜 That way, all traffic follows the minimum latency path between endpoints. Iconic routing behaviour 👑
In Scheme 1, the operator does give bandwidth guarantees to slice customers, but there's no explicit end-to-end backing for that bandwidth SLO in the form of bandwidth reservations across the provider network 😬 Instead, the expected performance comes from capacity planning, based on traffic growth trends and anticipated future demands, so that network links don't get oversubscribed 🍓 This scheme is kinda like the one used in lots of existing business VPN deployments, where bandwidth guarantees are given to customers but aren't explicitly underpinned end to end across the provider network 🎀
A variation on this scheme uses Flex-Algorithm [RFC9350] 🧚 For example, one Flex-Algorithm could use latency-based metrics while another uses the IGP metric. There would be a many-to-one mapping of network slices to Flex-Algorithms ✨
Scheme 1 is technically feasible, but it's vulnerable to unexpected changes in traffic patterns and/or network element failures that cause congestion 💀 The reason is that, unlike Schemes 2 and 3, which use TE, traffic can't be diverted away from the shortest path 😭
7.2.2. Scheme 2: TE Paths with Fixed Bandwidth Reservations ✨
okay bestie, Scheme 2 uses RSVP-TE [RFC3209] or SR-TE [RFC9256] paths with fixed bandwidth reservations 🎀 "Fixed" just means the number stays the same over time 🫶 The only time it changes is when the 5G NSO tells the transport side that a slice's bandwidth needs changed, because a slice got created or modified 💅 The "reservations" can live in the transport controller, not the network itself. Reserving bandwidth at the network layer isn't required, and (ngl) current SR-TE tech literally can't do it as of writing this doc 💀 The bandwidth number just acts as a constraint whenever the controller (re)computes a path 🧚
You could have one big mesh of paths between endpoints carrying every traffic type, or a small handful of meshes 🌈 Like, one mesh for low-latency traffic that follows the minimum latency path, and another for everything else that follows the minimum IGP metric path, as described in Section 5 💜 Either way, it's a many-to-one mapping of slices to paths 🦋
Now the math, which is giving satisfying 🔥 The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj demands of the individual slices. So if only slices "X" and "Y" exist, the requirement from "DC 1" to "DC 2" is 12 units (8 units for slice "X" (Table 1) and 4 units for slice "Y" (Table 2)) 🍓 When the 5G NSO requests a new slice, the NSC, increments the bandwidth requirement by whatever the new slice needs 👑 For example, in Figure 30, say a brand new slice shows up needing 0.8 Gbps from "DC 1" to "DC 2" 😭 The transport controller bumps its notion of that requirement from 12 Gbps to 12.8 Gbps to fit the extra expected traffic ✨
+=========+======+======+======+===============+
| 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 |
+---------+------+------+------+---------------+
Table 2: Inter-DC Traffic Demand Matrix
(Slice Y)In this example, each DC has two PEs facing it, for resilience 🛡️🌸 The NSC has to figure out how to map the "DC 1" to "DC 2" bandwidth requirement onto bandwidth reservations of TE LSPs from "DC 1" to "DC 2" 🧠 Say the routing config is set up so that, with no network failure, traffic from "DC 1" to "DC 2" always enters "PE1A" and goes to "PE2A". Then the controller reserves 12.8 Gbps on the path from "PE1A" to "PE2A" 💖 But if the routing config is set up so that traffic from "DC 1" to "DC 2" always enters "PE1A" and gets load-balanced across "PE2A" and "PE2B" (still no failure), the controller reserves 6.4 Gbps on the path from "PE1A" to "PE2A" AND 6.4 Gbps on the path from "PE1A" to "PE2B" 🦋
It can get tricky, though 🙈 The NSC might not know every condition that changes how traffic lands on the various PEs, which means it might not realize it needs to change the path reservations to match. For example, an internal failure inside "DC 1" could make traffic from "DC 1" land on "PE1B" instead of "PE1A". The NSC may not be aware of that failure, so it may not know it now needs to apply bandwidth reservations to paths from "PE1B" to "PE2A" and "PE2B" 😬
7.2.3. Scheme 3: TE Paths without Bandwidth Reservation 💜
Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths 🌈 Again, you could go with one mesh of paths carrying all the traffic types, or a small handful of meshes: one for low-latency traffic following the minimum latency path, and another for the rest following the minimum IGP metric path, as described in Section 5 🫧 And yes, it's a many-to-one mapping of slices to paths, periodt 💅
The difference between Scheme 2 and Scheme 3 is that Scheme 3 doesn't have fixed bandwidth reservations for the paths 🙌 Instead, the actual measured data plane traffic volumes are used to influence where TE paths get placed 📈 One way to do this is distributed RSVP-TE with auto-bandwidth 🧚 Or, the NSC can use telemetry-driven automatic congestion avoidance ✨ In that approach, when the actual data plane traffic on a given link goes over a threshold, the controller, which knows how much real traffic is moving along each RSVP or SR-TE path, can tune one or more of those paths that use the link so they steer clear of it 🦋 This is similar to what's described in Section 4.3.1 of [RFC9522] 🎀
Moving a path whose cost function is latency, rather than some other type of path, to ease congestion would be undesirable 😭 The reason is that the moved path will typically end up with higher latency 💀 You can dodge this by designing the algorithms from the previous paragraph so they avoid moving minimum-latency paths unless there's no alternative 🫶
8. Network Slicing OAM 🔍
Deploying and maintaining slices in a network implies that a set of OAM functions [RFC6291] 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 just a portion of that slice (for troubleshooting, 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.
[RFC7276] gives an overview of the 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 addresses 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 need fast detection and repair mechanisms, while others may not be engineered with such means 🙈 The provider can use techniques such as those described in [RFC5286], [RFC5714], and [RFC8355] 🦋
- Providers may deploy means to dynamically discover the set of network slices enabled within their network 🔎 Dynamic discovery makes it easier to catch any mismatch between the view kept 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 on the L3NM [RFC9182] or the L2NM [RFC9291] to maintain the full set of L2VPNs/L3VPNs used to deliver Network Slice Services 🧚 The correlation between an L2VPN/L3VPN instance and a Network Slice Service is maintained using the
parent-service-idattribute (Section 7.3 of [RFC9182]) 💜 - Providers should provide the means to report a set of network performance metrics, so they can assess whether the agreed Slice Service objectives are being honored 📊 These means are used for SLO monitoring and violation detection 🚦 For example, the YANG data model in [RFC9375] can be used to report the one-way delay and one-way delay variation of links ⏱️ Both conventional active/passive measurement methods [RFC7799] and more recent telemetry methods (e.g., YANG Push [RFC8641]) can be used 🌈
- Providers should have the means to report and expose observed performance metrics and other OAM state to the customer 🎁 For example, the YANG data model defined in [NSSM] exposes a set of statistics per SDP, connectivity construct, and connection group 🍓
9. Scalability Implications 📈
The mapping of 5G Network Slices to Transport Network Slices (see Section 3.5) is a design choice made by service operators 🧩 It may depend on, e.g., the number of instantiated slices, the requested services, or local engineering capabilities and guidelines 🛠️ Still, operators should carefully consider ways to ease slice migration strategies 🫶 For example, a provider may start with a 1-to-1 mapping if it only has to instantiate a few network slices and serve just a few customers 🌱 That provider may decide to move to an M-to-1 mapping for aggregation and scalability purposes if sustained increased slice demand is observed 📈✨
Putting adequate automation in place to realize network slices (including adjusting the mapping of Slice Services to network slices) would make slice migration operations easier 🤖💖
The realization model described in this document inherits the scalability properties of the underlying L2VPN and L3VPN technologies (Section 3.7) 🧠 Readers can look at Section 13 of [RFC4365] or Section 1.2.5 of [RFC6624] for a scalability assessment of some of these technologies 📚 Providers may adjust the mapping model to better handle local scalability constraints 🔧🌸
10. IANA Considerations 🧾
This document has no IANA actions 🌷
11. Security Considerations 🔐
Okay bestie, security time, and it is SERIOUS 😭 Section 10 of [RFC9543] covers the generic security stuff for network slicing, and it's giving four big themes.
Conformance to security constraints: If a customer says "don't route my traffic through this particular geographical region" 🙅♀️, you can meet that by mapping the traffic onto an underlay transport (Section 6) that avoids that region. Iconic, no notes 💅
NSC authentication: Per [RFC9543], underlay networks need protection from an adversary NSC, because a bad NSC could destabilise the whole network 💀 The NSC and the underlay talk through a set of YANG modules that get accessed with YANG-based management protocols like NETCONF [RFC6241] and RESTCONF [RFC8040], which is how service provisioning requests get passed along. These protocols have to use (1) a secure transport layer (for example SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) mutual authentication 🔑
The NETCONF access control model [RFC8341] lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of protocol operations and content. Very controlled, very cute 🎀
If you want to see how NSCs actually get built, check out documents like [NSC-MODEL] 🧚
Specific isolation criteria: Adequate admission control policies should be configured at the edge of the provider network to control access to specific slice resources. Policers, like the ones in Section 5.2.1.1, are one example. This stops one slice from hogging resources at everyone else's expense 🙅♀️ Access to classification and mapping tables also has to be controlled, because an unauthorised entity could edit the table to bind traffic to a random slice, redirect it, and so on. Network devices have to check that the required access privilege is in place before they grant access to specific data or do specific actions. Gatekeeping energy 🚪✨
Data Confidentiality and Integrity of an RFC 9543 Network Slice: As described in Section 5.1.2.1 of [RFC9543], a customer might request a Service Level Expectation (SLE) that mandates encryption 🔒 One way to get that is to map the traffic onto an underlay transport (Section 6) that only uses MACsec-encrypted links. Locked down, babe 🫶
Now the spicy one 🌶️ Section 4.2 describes a way to skip needing a mapping table for matching source/destination IP addresses to slice S-NSSAIs. Instead, some or all of the S-NSSAI bits get embedded in an IPv6 address using an algorithm. The catch is that an attacker inside the Transport Network who has access to the mapping configuration can work out which slice a packet belongs to. They can also change those bits, which could steer the packet onto a different network slice and cause service disruption. An attacker like that can do even more damage, like randomly dropping packets 💀
Security considerations for each technology and protocol in the document live in each protocol's own specification documents. For a deep dive on VPN security (authentication and encryption between PEs, IPsec tunnels that end inside customer sites to protect user data, keeping illegitimate traffic out of a VPN instance, and more), check out the "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)" [RFC4111], the "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)" (Section 6 of [RFC4365]), and the "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)" [RFC4381]. And for the TE side of things, Section 9 of [RFC9522] has the tea 🍵
12. References 📚
12.1. Normative References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, https://www.rfc-editor.org/info/rfc4364.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, https://www.rfc-editor.org/info/rfc7608.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, https://www.rfc-editor.org/info/rfc8341.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, https://www.rfc-editor.org/info/rfc9543.
12.2. Informative References
[Book-5G] Peterson, L., Sunay, O., and B. Davie, "Private 5G: A Systems Approach", 2023, https://5g.systemsapproach.org/.
[ECPRI] Common Public Radio Interface, "Common Public Radio Interface: eCPRI Interface Specification", https://www.cpri.info/downloads/eCPRI_v_2.0_2019_05_10c.pdf.
[IEEE802.1AE] IEEE, "802.1AE: MAC Security (MACsec)", https://1.ieee802.org/security/802-1ae/.
[MAPPING] Contreras, L. M., Ed., Bykov, I., Ed., and K. G. Szarkowicz, Ed., "5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS", Work in Progress, Internet-Draft, draft-cbs-teas-5qi-to-dscp-mapping-05, 20 October 2025, https://datatracker.ietf.org/doc/html/draft-cbs-teas-5qi-to-dscp-mapping-05.
[NG.113] GSMA, "NG.113: 5GS Roaming Guidelines", Version 4.0, May 2021, https://www.gsma.com/newsroom/wp-content/uploads//NG.113-v4.0.pdf.
[NS-APP] Geng, X., Contreras, L. M., Ed., Rokui, R., Dong, J., and I. Bykov, "IETF Network Slice Application in 3GPP 5G End-to-End Network Slice", Work in Progress, Internet-Draft, draft-ietf-teas-5g-network-slice-application-05, 7 July 2025, https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-network-slice-application-05.
[NS-IP-MPLS] Saad, T., Beeram, V., Dong, J., Halpern, J., and S. Peng, "Realizing Network Slices in IP/MPLS Networks", Work in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-06, 20 October 2025, https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-ip-mpls-06.
[NSC-MODEL] Contreras, L. M., Rokui, R., Tantsura, J., Wu, B., and X. Liu, "IETF Network Slice Controller and its Associated Data Models", Work in Progress, Internet-Draft, draft-ietf-teas-ns-controller-models-06, 20 October 2025, https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-controller-models-06.
[NSSM] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, "A YANG Data Model for the RFC 9543 Network Slice Service", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slice-nbi-yang-25, 9 May 2025, https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-25.
[O-RAN.WG9.XPSAAS] O-RAN Alliance, "Xhaul Packet Switched Architectures and Solutions", O-RAN.WG9.XPSAAS, Version 09.00, October 2025, https://specifications.o-ran.org/specifications.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, https://www.rfc-editor.org/info/rfc1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, https://www.rfc-editor.org/info/rfc2474.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, https://www.rfc-editor.org/info/rfc2475.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, https://www.rfc-editor.org/info/rfc2698.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, https://www.rfc-editor.org/info/rfc3209.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, https://www.rfc-editor.org/info/rfc4026.
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, DOI 10.17487/RFC4111, July 2005, https://www.rfc-editor.org/info/rfc4111.
[RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2005, https://www.rfc-editor.org/info/rfc4115.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, https://www.rfc-editor.org/info/rfc4176.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, https://www.rfc-editor.org/info/rfc4252.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, https://www.rfc-editor.org/info/rfc4360.
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/RFC4365, February 2006, https://www.rfc-editor.org/info/rfc4365.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, https://www.rfc-editor.org/info/rfc4381.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, https://www.rfc-editor.org/info/rfc4664.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, https://www.rfc-editor.org/info/rfc4761.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>. 🦋
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>. 🌸
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, DOI 10.17487/RFC6136, March 2011, <https://www.rfc-editor.org/info/rfc6136>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>. This one is the official word on how to spell OAM, so it's lowkey a must-read 💅
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>. 🧚
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments", RFC 7422, DOI 10.17487/RFC7422, December 2014, <https://www.rfc-editor.org/info/rfc7422>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <https://www.rfc-editor.org/info/rfc7510>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>. ✨
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7806] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping", RFC 7806, DOI 10.17487/RFC7806, April 2016, <https://www.rfc-editor.org/info/rfc7806>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, <https://www.rfc-editor.org/info/rfc8100>. 🎀
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>. 💜
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/info/rfc8969>. 🌈
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>. Multiplexing over UDP, secure by default, absolutely iconic 👑
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, <https://www.rfc-editor.org/info/rfc9099>. 🔥
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/info/rfc9182>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, <https://www.rfc-editor.org/info/rfc9291>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, <https://www.rfc-editor.org/info/rfc9330>. ⭐
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.
[RFC9375] Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de Dios, O., and B. Wen, "A YANG Data Model for Network and VPN Service Performance Monitoring", RFC 9375, DOI 10.17487/RFC9375, April 2023, <https://www.rfc-editor.org/info/rfc9375>.
[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, June 2023, <https://www.rfc-editor.org/info/rfc9408>. 🍓
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios, O., Barguil, S., and B. Wu, "YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS)", RFC 9834, DOI 10.17487/RFC9834, September 2025, <https://www.rfc-editor.org/info/rfc9834>.
[RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O., Barguil, S., and B. Wu, "A Network YANG Data Model for Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835, September 2025, <https://www.rfc-editor.org/info/rfc9835>.
[TS-23.501] 3GPP, "System architecture for the 5G System (5GS)", Version 19.5.0, Release 19, 3GPP TS 23.501, September 2025, <https://www.3gpp.org/ftp/Specs/archive/23_series/23.501/23501-j50.zip>. 📡
[TS-28.530] 3GPP, "Management and orchestration; Concepts, use cases and requirements", Version 19.0.0, Release 19, 3GPP TS 28.530, March 2025, <https://www.3gpp.org/ftp/Specs/archive/28_series/28.530/28530-j00.zip>. 💖
Appendix A. Example of Local IPv6 Addressing Plan for Network Functions ✨
Okay bestie, so there are lots of different IPv6 address allocation schemes you can use if you follow the approach from Section 4.2 🎀 Here's one example, shown in Figure 31 💅
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)Figure 31: Example of S-NSSAI Embedded into an IPv6 Address
So in Figure 31, the most significant 96 bits of the IPv6 address are unique to the NF, but they don't carry any slice-specific info 🦋 The S-NSSAI gets embedded in the least significant 32 bits, which is so clean 🧚 The provider can structure that 96-bit part however they want, like by geographic location or DC identification 🌸 If you want the tea on why structuring your address plan around both services and locations is iconic for more structured security policies, check out Section 2.1 of [RFC9099] 🔥
Figure 32 takes the Figure 31 example and shows a slicing deployment where the whole S-NSSAI is embedded into the IPv6 addresses used by NFs 💖 Let's say "NF-A" has a bunch of tunnel termination points with unique per-slice IP addresses from 2001:db8:a::/96, and "NF-B" uses per-slice IP addresses from 2001:db8:b::/96 ✨ This example has two slices: "customer A eMBB" (SST=1, SD=00001) and "customer B MIoT" (SST=3, SD=00003) 🫶 For the "customer A eMBB" slice, the tunnel IP addresses get auto-derived as {2001:db8:a::100:1, 2001:db8:b::100:1}, where {:0100:0001} is used as the last two octets 😭 The "customer B MIoT" slice (SST=3, SD=00003) tunnel uses {2001:db8:a::300:3, 2001:db8:b::300:3} and just adds {:0300:0003} as the last two octets 🌈 Leading zeros aren't represented in the resulting IPv6 addresses, per [RFC5952] 💅
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
* SDPFigure 32: Deployment Example with S-NSSAI Embedded into IPv6 Addresses
Acknowledgments 🫶
The authors would like to thank Adrian Farrel, Joel Halpern, Tarek Saad, Greg Mirsky, Rüdiger Geib, Nicklous D. Morris, Daniele Ceccarelli, Bo Wu, Xuesong Geng, and Deborah Brungard for reviewing this document and leaving super valuable comments 💜
Special thanks to Jie Dong and Adrian Farrel for the detailed and careful reviews 👑
Thanks to Alvaro Retana and Mike McBride for the rtg-dir reviews, Yoshifumi Nishida for the tsv-art review, Timothy Winters for the int-dir review, Lars Eggert for the genart review, Joseph Salowey for the secdir review, and Tim Wicinski for the opsdir review 🌸
Thanks to Jim Guichard for the AD review 🎀
Thanks to Erik Kline, Ketan Talaulikar, and Deb Cooley for the IESG review ⭐
Contributors 💖
John Drake
Sunnyvale, CA
United States of America
Email: je_drake@yahoo.com
Ivan Bykov
Ribbon Communications
Tel Aviv
Israel
Email: ivan.bykov@rbbn.com
Reza Rokui
Ciena
Ottawa
Canada
Email: rrokui@ciena.com
Luay Jalil
Verizon
Dallas, TX
United States of America
Email: luay.jalil@verizon.com
Beny Dwi Setyawan
XL Axiata
Jakarta
Indonesia
Email: benyds@xl.co.id
Amit Dhamija
Rakuten
Bangalore
India
Email: amitd@arrcus.com
Mojdeh Amani
British Telecom
London
United Kingdom
Email: mojdeh.amani@bt.comAuthors' Addresses 🦋
Krzysztof G. Szarkowicz (editor)
HPE
Wien
Austria
Email: kszarkowicz@juniper.net
Richard Roberts (editor)
Nokia
Rennes
France
Email: richard.roberts@nokia.com
Julian Lucek
HPE
London
United Kingdom
Email: jlucek@juniper.net
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: https://lmcontreras.com/📦 where this page comes from
- ietf: rfc9889 2025-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms