rfc9889v1.txt   rfc9889.txt 
Internet Engineering Task Force (IETF) K. Szarkowicz, Ed. Internet Engineering Task Force (IETF) K. Szarkowicz, Ed.
Request for Comments: 9889 R. Roberts, Ed. Request for Comments: 9889 HPE
Category: Informational J. Lucek Category: Informational R. Roberts, Ed.
ISSN: 2070-1721 Juniper Networks ISSN: 2070-1721 Nokia
J. Lucek
Juniper Networks
M. Boucadair, Ed. M. Boucadair, Ed.
Orange Orange
L. Contreras L. Contreras
Telefonica Telefonica
October 2025 October 2025
Realization of Network Slices for 5G Networks Using Current IP/MPLS A Realization of Network Slices for 5G Networks Using Current IP/MPLS
Technologies Technologies
Abstract Abstract
Network slicing is a feature that was introduced by the 3rd Network slicing is a feature that was introduced by the 3rd
Generation Partnership Project (3GPP) in mobile networks. Generation Partnership Project (3GPP) in Mobile Networks.
Realization of 5G slicing implies requirements for all mobile Realization of 5G slicing implies requirements for all mobile
domains, including the Radio Access Network (RAN), Core Network (CN), domains, including the Radio Access Network (RAN), Core Network (CN),
and Transport Network (TN). and Transport Network (TN).
This document describes a Network Slice realization model for IP/MPLS This document describes a network slice realization model for IP/MPLS
networks with a focus on the Transport Network fulfilling the service networks with a focus on the Transport Network fulfilling the service
objectives for 5G slicing connectivity. The realization model reuses objectives for 5G slicing connectivity. The realization model reuses
many building blocks currently commonly used in service provider many building blocks commonly used in service provider networks at
networks. the current time.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
skipping to change at line 72 skipping to change at line 74
1. Introduction 1. Introduction
2. Terminology 2. Terminology
2.1. Definitions 2.1. Definitions
2.2. Abbreviations 2.2. Abbreviations
3. 5G Network Slicing Integration in Transport Networks 3. 5G Network Slicing Integration in Transport Networks
3.1. Scope of the Transport Network 3.1. Scope of the Transport Network
3.2. 5G Network Slicing Versus Transport Network Slicing 3.2. 5G Network Slicing Versus Transport Network Slicing
3.3. Transport Network Reference Design 3.3. Transport Network Reference Design
3.4. Orchestration Overview 3.4. Orchestration Overview
3.5. Mapping 5G Network Slices to Transport Network Slices 3.5. Mapping 5G Network Slices to Transport Network Slices
3.6. First 5G Slice Versus Subsequent Slices 3.6. First 5G Network Slice Versus Subsequent Slices
3.7. Overview of the Transport Network Realization Model 3.7. Overview of the Transport Network Realization Model
4. Handoff Between Domains 4. Handoff Between Domains
4.1. VLAN Handoff 4.1. VLAN Handoff
4.2. IP Handoff 4.2. IP Handoff
4.3. MPLS Label Handoff 4.3. MPLS Label Handoff
5. QoS Mapping Realization Models 5. QoS Mapping Realization Models
5.1. QoS Layers 5.1. QoS Layers
5.2. QoS Realization Models 5.2. QoS Realization Models
5.3. Transit Resource Control 5.3. Transit Resource Control
6. PE Underlay Transport Mapping Models 6. PE Underlay Transport Mapping Models
skipping to change at line 106 skipping to change at line 108
Functions Functions
Acknowledgments Acknowledgments
Contributors Contributors
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
This document focuses on network slicing for 5G networks, covering This document focuses on network slicing for 5G networks, covering
the connectivity between Network Functions (NFs) across multiple the connectivity between Network Functions (NFs) across multiple
domains such as edge clouds, data centers, and the Wide Area Network domains such as edge clouds, data centers, and the Wide Area Network
(WAN). The document describes a Network Slice realization approach (WAN). The document describes a network slice realization approach
that fulfills 5G slicing requirements by using existing IP/MPLS that fulfills 5G slicing requirements by using existing IP/MPLS
technologies (at the time of publication of this document) to technologies (at the time of publication of this document) to
optimally control connectivity Service Level Agreements (SLAs) optimally control connectivity Service Level Agreements (SLAs)
offered for 5G slices. To that aim, this document describes the offered for 5G Network Slices. To that aim, this document describes
scope of the Transport Network in 5G architectures (Section 3.1), the scope of the Transport Network in 5G architectures (Section 3.1),
disambiguates 5G Network Slicing versus Transport Network Slicing disambiguates 5G Network Slicing versus Transport Network Slicing
(Section 3.2), draws the perimeter of the various orchestration (Section 3.2), draws the perimeter of the various orchestration
domains to realize slices (Section 3.4), and identifies the required domains to realize slices (Section 3.4), and identifies the required
coordination between these orchestration domains for adequate setup coordination between these orchestration domains for adequate setup
of Attachment Circuits (ACs) (Section 3.4.2). of Attachment Circuits (ACs) (Section 3.4.2).
This work is compatible with the framework defined in [RFC9543], This work is compatible with the framework defined in [RFC9543],
which describes network slicing in the context of networks built from which describes network slicing in the context of networks built from
IETF technologies. Specifically, this document describes an approach IETF technologies. Specifically, this document describes an approach
to how RFC 9543 Network Slices are realized within provider networks to how RFC 9543 Network Slices are realized within provider networks
and how such slices are stitched to Transport Network resources in a and how such slices are stitched to Transport Network resources in a
customer site in the context of Transport Network Slices (Figure 1). customer site in the context of Transport Network Slices (Figure 1).
The realization of an RFC 9543 Network Slice (i.e., connectivity with The realization of an RFC 9543 Network Slice (i.e., connectivity with
performance commitments) involves the provider network and partially performance commitments) involves the provider network and partially
the AC (the Provider Edge (PE) side of the AC). This document the AC (the Provider Edge (PE) side of the AC). This document
assumes that the customer site infrastructure is over-provisioned and assumes that the customer site infrastructure is over-provisioned and
involves short distances (low latency) where basic QoS/scheduling involves short distances (low latency) where basic QoS/scheduling
logic is sufficient to comply with the Service Level Objectives logic is sufficient to comply with the Service Level Objectives
(SLOs). (SLOs).
|------------------TN Slice------------------| |------------Transport Network Slice---------|
RFC 9543 Network Slice RFC 9543 Network Slice
.-----SDP Type 3----. .-----SDP Type 3----.
| .- SDP Type 4-. | | .- SDP Type 4-. |
| | | | | | | |
v v v v v v v v
+------------+ +---------------+ +------------+ +------------+ +---------------+ +------------+
| Customer | | Provider | | Customer | | Customer | | Provider | | Customer |
| Site 1 | | Network | | Site 2 | | Site 1 | | Network | | Site 2 |
| | +-+--+ +-+--+ | | | | +-+--+ +-+--+ | |
skipping to change at line 160 skipping to change at line 162
Figure 1: Transport Network Slice and RFC 9543 Network Slice Scopes Figure 1: Transport Network Slice and RFC 9543 Network Slice Scopes
This document focuses on RFC 9543 Network Slice deployments where the This document focuses on RFC 9543 Network Slice deployments where the
Service Demarcation Points (SDPs) are located per Types 3 and 4 in Service Demarcation Points (SDPs) are located per Types 3 and 4 in
Figure 1 of [RFC9543]. Figure 1 of [RFC9543].
The realization approach described in this document is typically The realization approach described in this document is typically
triggered by Network Slice Service requests. How a Network Slice triggered by Network Slice Service requests. How a Network Slice
Service request is placed for realization, including how it is Service request is placed for realization, including how it is
derived from a 5G Slice Service request, is out of scope. Mapping derived from a 5G Slice Service request, is out of scope. Mapping
considerations between 3GPP and IETF Network Slice Service (e.g., considerations between 3GPP and RFC 9543 Network Slice Service (e.g.,
mapping of service parameters) are discussed, e.g., in [NS-APP]. mapping of service parameters) are discussed in documents such as
[NS-APP].
The 5G control plane uses the Single Network Slice Selection The 5G control plane uses the Single Network Slice Selection
Assistance Information (S-NSSAI) for slice identification Assistance Information (S-NSSAI) for slice identification
[TS-23.501]. Because S-NSSAIs are not visible to the transport [TS-23.501]. Because S-NSSAIs are not visible to the transport
domain, 5G domains can expose the 5G slices to the transport domain domain, 5G domains can expose the 5G Network Slices to the transport
by mapping to explicit data plane identifiers (e.g., Layer 2, Layer domain by mapping to explicit data plane identifiers (e.g., Layer 2,
3, or Layer 4). Passing information between customer sites and Layer 3, or Layer 4). Passing information between customer sites and
provider networks is referred to as the "handoff". Section 4 lists a provider networks is referred to as the "handoff". Section 4 lists a
set of handoff methods for slice mapping purposes. set of handoff methods for slice mapping purposes.
Unlike approaches that require new protocol extensions (e.g., Unlike approaches that require new protocol extensions (e.g.,
[NS-IP-MPLS]), the realization model described in this document uses [NS-IP-MPLS]), the realization model described in this document uses
a set of building blocks commonly used in service provider networks a set of building blocks commonly used in service provider networks
(at the time of publication of this document). The model uses (1) (at the time of publication of this document). The model uses (1)
L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for logical L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for logical
separation, (2) fine-grained resource control at the PEs, (3) coarse- separation, (2) fine-grained resource control at the PEs, (3) coarse-
grained resource control within the provider network, and (4) grained resource control within the provider network, and (4)
skipping to change at line 245 skipping to change at line 248
3GPP: 3rd Generation Partnership Project 3GPP: 3rd Generation Partnership Project
5GC: 5G Core 5GC: 5G Core
5QI: 5G QoS Indicator 5QI: 5G QoS Indicator
A2A: Any-to-Any A2A: Any-to-Any
AC: Attachment Circuit AC: Attachment Circuit
AMF: Access and Mobility Management Function
CE: Customer Edge CE: Customer Edge
CIR: Committed Information Rate CIR: Committed Information Rate
CS: Customer Site CS: Customer Site
CN: Core Network CN: Core Network
CoS: Class of Service CoS: Class of Service
skipping to change at line 267 skipping to change at line 272
CU: Centralized Unit CU: Centralized Unit
CU-CP: Centralized Unit Control Plane CU-CP: Centralized Unit Control Plane
CU-UP: Centralized Unit User Plane CU-UP: Centralized Unit User Plane
DC: Data Center DC: Data Center
DDoS: Distributed Denial of Service DDoS: Distributed Denial of Service
DM: Data Model
DSCP: Differentiated Services Code Point DSCP: Differentiated Services Code Point
eCPRI: enhanced Common Public Radio Interface eCPRI: enhanced Common Public Radio Interface
FIB: Forwarding Information Base FIB: Forwarding Information Base
GPRS: General Packet Radio Service GPRS: General Packet Radio Service
gNB: gNodeB gNB: gNodeB
skipping to change at line 424 skipping to change at line 431
3.2.1. 5G Network Slicing 3.2.1. 5G Network Slicing
In [TS-28.530], the 3GPP defines 5G Network Slicing as an approach: In [TS-28.530], the 3GPP defines 5G Network Slicing as an approach:
| where logical networks/partitions are created, with appropriate | where logical networks/partitions are created, with appropriate
| isolation, resources and optimized topology to serve a purpose or | isolation, resources and optimized topology to serve a purpose or
| service category (e.g. use case/traffic category, or for MNO | service category (e.g. use case/traffic category, or for MNO
| internal reasons) or customers (logical system created "on | internal reasons) or customers (logical system created "on
| demand"). | demand").
These resources are from the TN, RAN, CN domains, and the underlying These resources are from the TN, RAN, and CN domains together with
infrastructure. the underlying infrastructure.
Section 3.1 of [TS-28.530] defines a 5G Network Slice as: Section 3.1 of [TS-28.530] defines a 5G Network Slice as:
| a logical network that provides specific network capabilities and | a logical network that provides specific network capabilities and
| network characteristics, supporting various service properties for | network characteristics, supporting various service properties for
| network slice customers. | network slice customers.
3.2.2. Transport Network Slicing 3.2.2. Transport Network Slicing
The term "TN slice" refers to a slice in the Transport Network domain The term "Transport Network Slice" refers to a slice in the Transport
of the 5G architecture. This section elaborates on how Transport Network domain of the 5G architecture. This section elaborates on
Network Slicing is defined in the context of this document. It draws how Transport Network Slicing is defined in the context of this
on the 3GPP definitions of "Transport Network" and "Network Slicing" document. It draws on the 3GPP definitions of "Transport Network"
in [TS-28.530]. and "Network Slicing" in [TS-28.530].
The objective of Transport Network Slicing is to isolate, guarantee, The objective of Transport Network Slicing is to isolate, guarantee,
or prioritize Transport Network resources for Slice Services. or prioritize Transport Network resources for Slice Services.
Examples of such resources include buffers, link capacity, or even Examples of such resources include buffers, link capacity, or even
Routing Information Base (RIB) and Forwarding Information Base (FIB). Routing Information Base (RIB) and Forwarding Information Base (FIB).
Transport Network Slicing provides various degrees of sharing of Transport Network Slicing provides various degrees of sharing of
resources between slices (Section 8 of [RFC9543]). For example, the resources between slices (Section 8 of [RFC9543]). For example, the
network capacity can be shared by all slices, usually with a network capacity can be shared by all slices, usually with a
guaranteed minimum per slice, or each individual slice can be guaranteed minimum per slice, or each individual slice can be
allocated dedicated network capacity. Parts of a given network may allocated dedicated network capacity. Parts of a given network may
use the former, while others use the latter. For example, in order use the former, while others use the latter. For example, in order
to satisfy local engineering guidelines and specific service to satisfy local engineering guidelines and specific service
requirements, shared TN resources could be provided in the backhaul requirements, shared TN resources could be provided in the backhaul
(or midhaul), and dedicated TN resources could be provided in the (or midhaul), and dedicated TN resources could be provided in the
midhaul (or backhaul). The capacity partitioning strategy is midhaul (or backhaul). The capacity partitioning strategy is
deployment specific. deployment specific.
There are different components to implement TN slices based upon There are different components to implement Transport Network Slices
mechanisms such as Virtual Routing and Forwarding (VRF) instances for based upon mechanisms such as Virtual Routing and Forwarding (VRF)
logical separation, QoS, and Traffic Engineering (TE). Whether all instances for logical separation, QoS, and Traffic Engineering (TE).
or a subset of these components are enabled is a deployment choice. Whether all or a subset of these components are enabled is a
deployment choice.
3.3. Transport Network Reference Design 3.3. Transport Network Reference Design
Figure 3 depicts the reference design used in this document for Figure 3 depicts the reference design used in this document for
modeling the Transport Network based on management perimeters modeling the Transport Network based on management perimeters
(customer vs. provider). (customer vs. provider).
Customer Provider Customer Customer Provider Customer
Orchestration Orchestration Orchestration Orchestration Orchestration Orchestration
Domain Domain Domain Domain Domain Domain
skipping to change at line 486 skipping to change at line 494
| +----+ | | +----+ +----+ | | +----+ | | +----+ | | +----+ +----+ | | +----+ |
| +--+ | | | AC | | | | | | AC | | | | | +--+ | | | AC | | | | | | AC | | | |
| |NF|....| CE +----------+ PE | | PE +-----------+ NF | | | |NF|....| CE +----------+ PE | | PE +-----------+ NF | |
| +--+ | | | | | | | | | | | | | | +--+ | | | | | | | | | | | | |
| +----+ | | +----+ +----+ | | +----+ | | +----+ | | +----+ +----+ | | +----+ |
| | | | | (CE) | | | | | | (CE) |
+----------------+ +---------------------+ +----------------+ +----------------+ +---------------------+ +----------------+
<-----------------Transport Network---------------> <-----------------Transport Network--------------->
Figure 3: Reference Design with Customer Site and Provider Network Figure 3: Reference Design with Customer Sites and Provider Network
The description of the main components shown in Figure 3 is provided The description of the main components shown in Figure 3 is provided
in the following subsections. in the following subsections.
3.3.1. Customer Site (CS) 3.3.1. Customer Site (CS)
On top of 5G NFs, a customer may manage additional TN elements (e.g., On top of 5G NFs, a customer may manage additional TN elements (e.g.,
servers, routers, and switches) within a customer site. servers, routers, and switches) within a customer site.
NFs may be hosted on a CE, directly connected to a CE, or located NFs may be hosted on a CE, directly connected to a CE, or located
skipping to change at line 532 skipping to change at line 540
perimeters. A co-managed CE has both PE and CE functions, and there perimeters. A co-managed CE has both PE and CE functions, and there
is no strict AC connection, although one may consider that the AC is no strict AC connection, although one may consider that the AC
stitching logic happens internally within the CE itself. The stitching logic happens internally within the CE itself. The
provider manages the AC between the CE and the PE. provider manages the AC between the CE and the PE.
This document generalizes the definition of a CE with the This document generalizes the definition of a CE with the
introduction of "distributed CE"; that is, the logical connectivity introduction of "distributed CE"; that is, the logical connectivity
is realized by configuring multiple devices in the customer domain. is realized by configuring multiple devices in the customer domain.
The CE function is distributed. An example of distributed CE is the The CE function is distributed. An example of distributed CE is the
realization of an interconnection using an L3VPN service based on a realization of an interconnection using an L3VPN service based on a
distributed CE composed of a switch (Layer 2) and a router (Layer 3) distributed CE composed of a switch (SW) in Layer 2 and a router
(Figure 4). Another example of distributed CE is shown in Figure 5. (RTR) in Layer 3, as shown in Figure 4. Another example of
distributed CE is shown in Figure 5.
+--------------+ +--------------+ +--------------+ +--------------+
| Customer | | Provider | | Customer | | Provider |
| Site | | Network | | Site | | Network |
| +---------------+ | | | +---------------+ | |
| | | | | | | | | |
| | +---+ +----+ | +----+ | | | +---+ +----+ | +----+ |
| | | | | ================== | | | | | | | ================== | |
| | | +------------AC----------+ PE | | | | | +------------AC----------+ PE | |
| | |RTR| | SW ================== | | | | |RTR| | SW ================== | |
skipping to change at line 580 skipping to change at line 589
3.3.4. Provider Edge (PE) 3.3.4. Provider Edge (PE)
A PE is a device managed by a provider that is connected to a CE. 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 The connectivity between a CE and a PE is achieved using one or
multiple ACs (Section 3.3.5). multiple ACs (Section 3.3.5).
This document generalizes the PE definition with the introduction of This document generalizes the PE definition with the introduction of
"distributed PE"; that is, the logical connectivity is realized by "distributed PE"; that is, the logical connectivity is realized by
configuring multiple devices in the provider network (i.e., the configuring multiple devices in the provider network (i.e., the
provider orchestration domain). The PE function is distributed. Provider Orchestration Domain). The PE function is distributed.
An example of a distributed PE is the "managed CE service". For An example of a distributed PE is the "managed CE service". For
example, a provider delivers VPN services using CEs and PEs that are example, a provider delivers VPN services using CEs and PEs that are
both managed by the provider (example (i) in Figure 5). The managed both managed by the provider (example (i) in Figure 5). The managed
CE can also be a Data Center Gateway as depicted in example (ii) of CE can also be a Data Center Gateway as depicted in example (ii) of
Figure 5. A provider-managed CE may attach to CEs of multiple Figure 5. A provider-managed CE may attach to CEs of multiple
customers. However, this device is part of the provider network. customers. However, this device is part of the provider network.
+--------------+ +--------------+ +--------------+ +--------------+
| Customer | | Provider | | Customer | | Provider |
skipping to change at line 639 skipping to change at line 648
This document uses the concept of distributed CE and PE (Sections This document uses the concept of distributed CE and PE (Sections
3.3.2 and 3.3.4) to consolidate a CE/AC/PE definition that is 3.3.2 and 3.3.4) to consolidate a CE/AC/PE definition that is
consistent with the orchestration perimeters (Section 3.4). The CEs consistent with the orchestration perimeters (Section 3.4). The CEs
and PEs delimit the customer and provider orchestration domains, and PEs delimit the customer and provider orchestration domains,
respectively, while an AC interconnects these domains. respectively, while an AC interconnects these domains.
For consistency with the terminology used in AC data models (e.g., For consistency with the terminology used in AC data models (e.g.,
the data models defined in [RFC9834] and [RFC9835]), this document the data models defined in [RFC9834] and [RFC9835]), this document
assumes that an AC is configured on a "bearer", which represents the assumes that an AC is configured on a "bearer", which represents the
underlying connectivity. For example, the bearer is illustrated with underlying connectivity. For example, the bearer is illustrated with
"===" in Figures 4 and 5. "=" in Figures 4 and 5.
An AC is technology specific. Examples of ACs are Virtual Local Area An AC is technology specific. Examples of ACs are VLAN ACs
Networks (VLANs) (AC) configured on a physical interface (bearer) or configured on a physical interface (bearer) or Overlay VXLAN EVI ACs
an Overlay VXLAN EVI (AC) configured on an IP underlay (bearer). configured on an IP underlay (bearer).
Deployment cases where the AC is also managed by the provider are not Deployment cases where the AC is also managed by the provider are not
discussed in this document because the setup of such an AC does not discussed in this document because the setup of such an AC does not
require any coordination between the customer and provider require any coordination between the customer and provider
orchestration domains. orchestration domains.
| Note: In order to keep the figures simple, only one AC and | Note: In order to keep the figures simple, only one AC and
| single-homed CEs are represented. Also, the underlying bearers | single-homed CEs are represented. Also, the underlying bearers
| are not represented in most of the figures. However, this | are not represented in most of the figures. However, this
| document does not exclude the instantiation of multiple ACs | document does not exclude the instantiation of multiple ACs
skipping to change at line 679 skipping to change at line 688
In Figure 6, a 5G End-to-End Network Slice Orchestrator (5G NSO) is In Figure 6, a 5G End-to-End Network Slice Orchestrator (5G NSO) is
responsible for orchestrating 5G Network Slices end-to-end. The responsible for orchestrating 5G Network Slices end-to-end. The
details of the 5G NSO are out of the scope of this document. The details of the 5G NSO are out of the scope of this document. The
realization of the 5G Network Slices spans RAN, CN, and TN. As realization of the 5G Network Slices spans RAN, CN, and TN. As
mentioned in Section 3.1, the RAN and CN are under the responsibility mentioned in Section 3.1, the RAN and CN are under the responsibility
of the 3GPP management system, while the TN is not. The of the 3GPP management system, while the TN is not. The
orchestration of the TN is split into two subdomains in conformance orchestration of the TN is split into two subdomains in conformance
with the reference design in Section 3.3: with the reference design in Section 3.3:
Provider Network Orchestration domain: As defined in [RFC9543], the Provider Network Orchestration Domain (simply referred to as
"Provider Orchestration Domain"): As defined in [RFC9543], the
provider relies on a Network Slice Controller (NSC) to manage and provider relies on a Network Slice Controller (NSC) to manage and
orchestrate RFC 9543 Network Slices in the provider network. This orchestrate RFC 9543 Network Slices in the provider network. This
framework allows for managing connectivity with SLOs. framework allows for managing connectivity with SLOs.
Customer Site Orchestration domain: The orchestration of TN elements Customer Site Orchestration Domain (simply referred to as
"Customer Orchestration Domain"): The orchestration of TN elements
of the customer sites relies upon a variety of controllers (e.g., of the customer sites relies upon a variety of controllers (e.g.,
Fabric Manager, Element Management System, or Virtualized Fabric Manager, Element Management System, or Virtualized
Infrastructure Manager (VIM)). Infrastructure Manager (VIM)).
A TN slice relies upon resources that can involve both the provider A Transport Network Slice relies upon resources that can involve both
and customer TN domains. More details are provided in Section 3.4.2. the provider and customer TN domains. More details are provided in
Section 3.4.2.
A TN slice might be considered as a variant of horizontal composition A Transport Network Slice might be considered as a variant of
of Network Slices mentioned in Appendix A.6 of [RFC9543]. horizontal composition of network slices mentioned in Appendix A.6 of
[RFC9543].
.---------. .---------.
| 5G NSO | | 5G NSO |
'-+---+---' '-+---+---'
| | | |
v | v |
.-------------. | .-------------. |
| 3GPP domains | | | 3GPP domains | |
.----------+ Orchestration +-)---------------------------. .----------+ Orchestration +-)---------------------------.
| | (RAN and CN) | | | | | (RAN and CN) | | |
| '-------------' | | | '-------------' | |
| v | | v |
| .-----------------------------------------------. | | .-----------------------------------------------. |
| | TN Orchestration | | | | Transport Network Orchestration | |
| | +--------------+ +-----------+ +--------------+ | | | | +--------------+ +-----------+ +--------------+ | |
| | |Customer Site | |RFC9543 NSC| |Customer Site | | | | | |Customer Site | |RFC9543 NSC| |Customer Site | | |
| | |Orchestration | | | |Orchestration | | | | | |Orchestration | | | |Orchestration | | |
| | +--------------+ +-----------+ +--------------+ | | | | +--------------+ +-----------+ +--------------+ | |
| '---|-------------------|---------------------|-' | | '---|-------------------|---------------------|-' |
| | | | | | | | | |
| | | | | | | | | |
| v v v | | v v v |
+--|----------+ +-----------------+ +-------|--+ +--|----------+ +-----------------+ +-------|--+
| | | | Provider | | | | | | | | Provider | | | |
skipping to change at line 729 skipping to change at line 742
| +--+ +----+ AC | | | | AC | NF |<-+ | | +--+ +----+ AC | | | | AC | NF |<-+ |
| |NF+....+ CE +------+ PE | | PE +------+ (CE)| | | |NF+....+ CE +------+ PE | | PE +------+ (CE)| |
| +--+ +----+ | | | | +-----+ | | +--+ +----+ | | | | +-----+ |
| | +----+ +----+ | | | | +----+ +----+ | |
| Customer | | | | Customer | | Customer | | | | Customer |
| Site | | | | Site | | Site | | | | Site |
+-------------+ +-----------------+ +----------+ +-------------+ +-----------------+ +----------+
RFC 9543 RFC 9543
|-----Network Slice---| |-----Network Slice---|
|--------------------TN Slice-------------------| |-------------Transport Network Slice-----------|
Figure 6: 5G End-to-End Slice Orchestration with TN Figure 6: 5G End-to-End Slice Orchestration with TN
The various orchestration depicted in Figure 6 encompass the 3GPP's The various orchestrations depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned, e.g., in Network Slice Subnet Management Function (NSSMF) mentioned, for
Figure 5 of [NS-APP]. instance, in Figure 5 of [NS-APP].
3.4.2. Transport Network Segments and Network Slice Instantiation 3.4.2. Transport Network Segments and Network Slice Instantiation
The concept of distributed PE (Section 3.3.4) assimilates the CE- The concept of distributed PE (Section 3.3.4) assimilates the CE-
based SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2) based SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2)
as SDP Types 3 or 4 in this document. as SDP Types 3 or 4 in this document.
In the architecture depicted in Section 3.4.1, the connectivity In the architecture depicted in Section 3.4.1, the connectivity
between NFs can be decomposed into three main segment types: between NFs can be decomposed into three main segment types:
skipping to change at line 809 skipping to change at line 822
| Site | | Network | | Site | | Network |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
|----------- AC -----------| |----------- AC -----------|
Figure 7: Coordination of Transport Network Resources for AC Figure 7: Coordination of Transport Network Resources for AC
Provisioning Provisioning
3.5. Mapping 5G Network Slices to Transport Network Slices 3.5. Mapping 5G Network Slices to Transport Network Slices
There are multiple options for mapping 5G Network Slices to TN There are multiple options for mapping 5G Network Slices to Transport
slices: Network Slices:
1-to-N mapping: A single 5G Network Slice can be mapped to multiple 1-to-N mapping: A single 5G Network Slice can be mapped to multiple
TN slices. For instance, consider the scenario depicted in Transport Network Slices. For instance, consider the scenario
Figure 8, which illustrates the separation of the 5G control plane depicted in Figure 8, which illustrates the separation of the 5G
and user plane in TN slices for a single 5G Enhanced Mobile control plane and user plane in Transport Network Slices for a
Broadband (eMBB) network slice. It is important to note that this single 5G Enhanced Mobile Broadband (eMBB) network slice. It is
mapping can serve as an interim step to M-to-N mapping. Further important to note that this mapping can serve as an interim step
details about this scheme are described in Section 3.6. to M-to-N mapping. Further details about this scheme are
described in Section 3.6.
M-to-1 mapping: Multiple 5G Network Slices may rely upon the same TN M-to-1 mapping: Multiple 5G Network Slices may rely upon the same
slice. In such a case, the Service Level Agreement (SLA) Transport Network Slice. In such a case, the Service Level
differentiation of slices would be entirely controlled at the 5G Agreement (SLA) differentiation of slices would be entirely
control plane, for example, with appropriate placement strategies. controlled at the 5G control plane, for example, with appropriate
This use case is illustrated in Figure 9, where a User Plane placement strategies. This use case is illustrated in Figure 9,
Function (UPF) for the Ultra-Reliable Low-Latency Communication where a UPF for the Ultra-Reliable Low-Latency Communication
(URLLC) slice is instantiated at the edge cloud, close to the gNB (URLLC) slice is instantiated at the edge cloud, close to the gNB
CU-UP, to improve latency and jitter control. The 5G control CU-UP, to improve latency and jitter control. The 5G control
plane and the UPF for the eMBB slice are instantiated in the plane and the UPF for the eMBB slice are instantiated in the
regional cloud. regional cloud.
M-to-N mapping: The mapping of 5G to TN slice combines both M-to-N mapping: The mapping of 5G to Transport Network Slice
approaches with a mix of shared and dedicated associations. combines both approaches with a mix of shared and dedicated
associations.
In this scenario, a subset of the TN slices can be intended for In this scenario, a subset of the Transport Network Slices can be
sharing by multiple 5G Network Slices (e.g., the control plane TN intended for sharing by multiple 5G Network Slices (e.g., the
slice is shared by multiple 5G Network Slices). control plane Transport Network Slice is shared by multiple 5G
Network Slices).
In practice, for operational and scaling reasons, M-to-N mapping In practice, for operational and scaling reasons, M-to-N mapping
would typically be used, with M >> N. would typically be used, with M much greater than N.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| 5G Slice eMBB | | 5G Network Slice eMBB |
| +------------------------------------+ | | +------------------------------------+ |
| +-----+ N3 | +--------------------------------+ | N3 +-----+ | | +-----+ N3 | +--------------------------------+ | N3 +-----+ |
| |CU-UP+------+ TN Slice UP_eMBB +-------+ UPF | | | |CU-UP+------+Transport Network Slice UP_eMBB +-------+ UPF | |
| +-----+ | +--------------------------------+ | +-----+ | | +-----+ | +--------------------------------+ | +-----+ |
| | | | | | | |
| +-----+ N2 | +--------------------------------+ | N2 +-----+ | | +-----+ N2 | +--------------------------------+ | N2 +-----+ |
| |CU-CP+------+ TN Slice CP +-------+ AMF | | | |CU-CP+------+ Transport Network Slice CP +-------+ AMF | |
| +-----+ | +--------------------------------+ | +-----+ | | +-----+ | +--------------------------------+ | +-----+ |
+------------|------------------------------------|-------------+ +------------|------------------------------------|-------------+
| | | |
| Transport Network | | Transport Network |
+------------------------------------+ +------------------------------------+
Figure 8: 1 (5G Slice) to N (TN Slice) Mapping Figure 8: 1-to-N Mapping (Single 5G Network Slice to Multiple
Transport Network Slices)
+-------------+ +-------------+
| Edge Cloud | | Edge Cloud |
| +---------+ | | +---------+ |
| |UPF_URLLC| | | |UPF_URLLC| |
| +-----+---+ | | +-----+---+ |
| | | | | |
+-------|-----+ +-------|-----+
| |
+---------------+ +-------|----------------------+ +---------------+ +-------|----------------------+
| | | | | | | | | |
| Cell Site | | +-----+--------------------+ | +--------------+ | Cell Site | | +-----+--------------------+ | +--------------+
| | | | | | | Regional | | | | | | | | Regional |
| +-----------+ | | | | | | Cloud | | +-----------+ | | | | | | Cloud |
| |CU-UP_URLLC+-----+ | | | +----------+ | | |CU-UP_URLLC+-----+ Transport Network | | | +----------+ |
| +-----------+ | | | TN Slice ALL +-----+ 5GC CP | | | +-----------+ | | | Slice ALL +-----+ 5GC CP | |
| | | | | | | +----------+ | | | | | | | | +----------+ |
| +-----------+ | | | | | | | | +-----------+ | | | | | | |
| |CU-UP_eMBB +-----+ | | | +----------+ | | |CU-UP_eMBB +-----+ | | | +----------+ |
| +-----------+ | | | +-----+ UPF_eMBB | | | +-----------+ | | | +-----+ UPF_eMBB | |
+---------------+ | | | | | +----------+ | +---------------+ | | | | | +----------+ |
| +--------------------------+ | | | | +--------------------------+ | | |
| | +--------------+ | | +--------------+
| Transport Network | | Transport Network |
+------------------------------+ +------------------------------+
Figure 9: N (5G Slice) to 1 (TN Slice) Mapping Figure 9: M-to-1 Mapping (Multiple 5G Network Slices to Single
Transport Network Slice)
Note that the actual realization of the mapping depends on several Note that the actual realization of the mapping depends on several
factors, such as the actual business cases, the NF vendor factors, such as the actual business cases, the NF vendor
capabilities, the NF vendor reference designs, as well as service capabilities, the NF vendor reference designs, as well as service
provider or even legal requirements. provider or even legal requirements.
Mapping approaches that preserve the 5G slice identification in the Mapping approaches that preserve the 5G Network Slice identification
TN (e.g., the approach in Section 4.2) may simplify required in the TN (e.g., the approach in Section 4.2) may simplify required
operations to map TN slices back to 5G slices. However, such operations to map Transport Network Slices back to 5G Network Slices.
considerations are not detailed in this document because these are However, such considerations are not detailed in this document
under the responsibility of the 3GPP orchestration domain. because these are under the responsibility of the 3GPP orchestration.
3.6. First 5G Slice Versus Subsequent Slices 3.6. First 5G Network Slice Versus Subsequent Slices
An operational 5G Network Slice incorporates both 5G control plane An operational 5G Network Slice incorporates both 5G control plane
and user plane capabilities. For instance, in some deployments, in and user plane capabilities. For instance, in some deployments, in
the case of a slice based on split CU in the RAN, both CU-UP and CU- the case of a slice based on split CU in the RAN, both CU-UP and CU-
CP may need to be deployed along with the associated interfaces E1, CP may need to be deployed along with the associated interfaces E1,
F1-c, F1-u, N2, and N3, which are conveyed in the TN. In this F1-c, F1-u, N2, and N3, which are conveyed in the TN. In this
regard, the creation of the "first slice" can be subject to a regard, the creation of the "first slice" can be subject to a
specific logic that does not apply to subsequent slices. Let us specific logic that does not apply to subsequent slices. Let us
consider the example depicted in Figure 10 to illustrate this consider the example depicted in Figure 10 to illustrate this
deployment. In this example, the first 5G slice relies on the deployment. In this example, the first 5G Network Slice relies on
deployment of NF-CP and NF-UP functions together with two TN slices the deployment of NF-CP and NF-UP functions together with two
for the control and user planes (TNS-CP and TNS-UP1). Next, in many Transport Network Slices for the control and user planes (TNS-CP and
cases, the deployment of a second slice relies solely on the TNS-UP1). Next, in many cases, the deployment of a second slice
instantiation of a UPF (NF-UP2) together with a dedicated TN slice relies solely on the instantiation of a UPF (NF-UP2) together with a
for the user plane (TNS-UP2). The control plane of the first 5G dedicated Transport Network Slice for the user plane (TNS-UP2). The
slice is also updated to integrate the second slice; the TN slice control plane of the first 5G Network Slice is also updated to
(TNS-CP) and Network Functions (NF-CP) are shared. integrate the second slice; the Transport Network Slice (TNS-CP) and
Network Functions (NF-CP) are shared.
The model described here, in which the control plane is shared among The model described here, in which the control plane is shared among
multiple slices, is likely to be common; it is not mandatory, though. multiple slices, is likely to be common; it is not mandatory, though.
Deployment models with a separate control plane for each slice are Deployment models with a separate control plane for each slice are
also possible. also possible.
Section 6.1.2 of [NG.113] specifies that the eMBB slice (SST-1 and no 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 Slice Differentiator (SD)) should be supported globally. This 5G
slice would be the first slice in any 5G deployment. Network Slice would be the first slice in any 5G deployment.
(1) Deployment of first 5G slice (1) Deployment of first 5G Network Slice
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| First 5G Slice | | First 5G Network Slice |
| | | |
| +------------------------------+ | | +------------------------------+ |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| |NF-CP+------+ CP TN Slice (TNS-CP) +------+NF-CP| | | |NF-CP+------+ TNS-CP +------+NF-CP| |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| | | | | | | |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| |NF-UP+------+ UP TN Slice (TNS-UP1) +------+NF-UP| | | |NF-UP+------+ TNS-UP1 +------+NF-UP| |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
+----------------|------------------------------|---------------+ +----------------|------------------------------|---------------+
| | | |
| Transport Network | | Transport Network |
+------------------------------+ +------------------------------+
(2) Deployment of additional 5G slice with shared control plane (2) Deployment of additional 5G Network Slice with shared Control
Plane
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| First 5G Slice | | First 5G Network Slice |
| | | |
| +------------------------------+ | | +------------------------------+ |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| |NF-CP+------+ CP TN Slice (TNS-CP) +------+NF-CP| | | |NF-CP+------+ TNS-CP +------+NF-CP| |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| SHARED | (SHARED) | SHARED | | SHARED | (SHARED) | SHARED |
| | | | | | | |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
| |NF-UP+------+ UP TN Slice (TNS-UP1) +------+NF-UP| | | |NF-UP+------+ TNS-UP1 +------+NF-UP| |
| +-----+ | +--------------------------+ | +-----+ | | +-----+ | +--------------------------+ | +-----+ |
+----------------|------------------------------|---------------+ +----------------|------------------------------|---------------+
| | | |
| Transport Network | | Transport Network |
| | | |
+----------------|------------------------------|---------------+ +----------------|------------------------------|---------------+
| | | | | | | |
| +------+ | +--------------------------+ | +------+ | | +------+ | +--------------------------+ | +------+ |
| |NF-UP2+-----+ UP TN Slice (TNS-UP2) +-----+NF-UP2| | | |NF-UP2+-----+ TNS-UP2 +-----+NF-UP2| |
| +------+ | +--------------------------+ | +------+ | | +------+ | +--------------------------+ | +------+ |
| | | | | | | |
| +------------------------------+ | | +------------------------------+ |
| | | |
| Second 5G Slice | | Second 5G Network Slice |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 10: First and Subsequent Slice Deployment Figure 10: First and Subsequent Slice Deployment
TN slice mapping policies can be enforced by an operator (e.g., Transport Network Slice mapping policies can be enforced by an
provided to a TN Orchestration or 5G NSO) to instruct whether operator (e.g., provided to a TN Orchestration or 5G NSO) to
existing TN slices can be reused for handling a new slice service determine whether existing Transport Network Slices can be reused for
creation request. Providing such a policy is meant to better handling a new Slice Service creation request. Providing such a
automate the realization of 5G slices and minimize the realization policy is meant to better automate the realization of 5G Network
delay that might be induced by extra cycles to seek for operator Slices and minimize the realization delay that might be induced by
validation. extra cycles to seek for operator validation.
3.7. Overview of the Transport Network Realization Model 3.7. Overview of the Transport Network Realization Model
The realization model described in this document is depicted in The realization model described in this document is depicted in
Figure 11. The following building blocks are used: Figure 11. The following building blocks are used:
* L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for * L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for
logical separation: logical separation:
This realization model of transport for 5G slices assumes Layer 3 This realization model of transport for 5G Network Slices assumes
delivery for midhaul and backhaul transport connections and a Layer 3 delivery for midhaul and backhaul transport connections
Layer 2 or Layer 3 delivery for fronthaul connections. Enhanced and a Layer 2 or Layer 3 delivery for fronthaul connections.
Common Public Radio Interface (eCPRI) [ECPRI] supports both Enhanced Common Public Radio Interface (eCPRI) [ECPRI] supports
delivery models. L2VPN/L3VPN service instances might be used as a both delivery models. L2VPN/L3VPN service instances might be used
basic form of logical slice separation. Furthermore, using as a basic form of logical slice separation. Furthermore, using
service instances results in an additional outer header (as service instances results in an additional outer header (as
packets are encapsulated/decapsulated at the nodes hosting service packets are encapsulated/decapsulated at the nodes hosting service
instances), providing clean discrimination between 5G QoS and TN instances), providing clean discrimination between 5G QoS and TN
QoS, as explained in Section 5. QoS, as explained in Section 5.
Note that a variety of L2VPN mechanisms can be considered for Note that a variety of L2VPN mechanisms can be considered for
slice realization. A non-comprehensive list is provided below: slice realization. A non-comprehensive list is provided below:
- Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762] - Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
skipping to change at line 1019 skipping to change at line 1039
o VPWS EVPN [RFC8214], o VPWS EVPN [RFC8214],
o Provider Backbone Bridging combined with EVPN (PBB-EVPN) o Provider Backbone Bridging combined with EVPN (PBB-EVPN)
[RFC7623], [RFC7623],
o EVPN over MPLS [RFC7432], and o EVPN over MPLS [RFC7432], and
o EVPN over Virtual Extensible LAN (VXLAN) [RFC8365]. o EVPN over Virtual Extensible LAN (VXLAN) [RFC8365].
The use of VPNs for realizing Network Slices is briefly described The use of VPNs for realizing network slices is briefly described
in Appendix A.4 of [RFC9543]. in Appendix A.4 of [RFC9543].
* Fine-grained resource control at the PE: * Fine-grained resource control at the PE:
This is sometimes called "admission control" or "traffic This is sometimes called "admission control" or "traffic
conditioning". The main purpose is the enforcement of the conditioning". The main purpose is the enforcement of the
bandwidth contract for the slice right at the edge of the provider bandwidth contract for the slice right at the edge of the provider
network where the traffic is handed off between the customer site network where the traffic is handed off between the customer site
and the provider network. and the provider network.
skipping to change at line 1051 skipping to change at line 1071
CEs and PEs, where part of the admission control is implemented on CEs and PEs, where part of the admission control is implemented on
the CE and the other part on the PE. the CE and the other part on the PE.
* Coarse-grained resource control at the transit links (non- * Coarse-grained resource control at the transit links (non-
attachment circuits) in the provider network, using a single NRP attachment circuits) in the provider network, using a single NRP
(called "base NRP" in Figure 11), spanning the entire provider (called "base NRP" in Figure 11), spanning the entire provider
network. Transit nodes in the provider network do not maintain network. Transit nodes in the provider network do not maintain
any state of individual slices. Instead, only a flat (non- any state of individual slices. Instead, only a flat (non-
hierarchical) QoS model is used on transit links in the provider hierarchical) QoS model is used on transit links in the provider
network, with up to 8 traffic classes. At the PE, traffic flows network, with up to 8 traffic classes. At the PE, traffic flows
from multiple slice services are mapped to the limited number of from multiple Slice Services are mapped to the limited number of
traffic classes used on transit links in the provider network. traffic classes used on transit links in the provider network.
* Capacity planning/management for efficient usage of provider * Capacity planning/management for efficient usage of provider
network resources: network resources:
The role of capacity planning/management is to ensure the provider The role of capacity planning/management is to ensure the provider
network capacity can be utilized without causing any bottlenecks. network capacity can be utilized without causing any bottlenecks.
The methods used here can range from careful network planning, to The methods used here can range from careful network planning that
ensure a more or less equal traffic distribution (i.e., equal-cost ensures a more or less equal traffic distribution (i.e., equal-
load balancing), to advanced TE techniques, with or without cost load balancing) to advanced TE techniques, with or without
bandwidth reservations, to force more consistent load bandwidth reservations, that force more consistent load
distribution, even in non-ECMP-friendly network topologies. See distribution, even in non-ECMP-friendly network topologies. See
also Section 8 of [RFC9522]. also Section 8 of [RFC9522].
.............................................. ..............................................
: Base NRP : : Base NRP :
+-----:----+ +----:-----+ +-----:----+ +----:-----+
| PE : | | : PE | | PE : | | : PE |
-- -- |- -- -- --| - -- -- -- -- -- -- -- -- -- -- -- | -- -- -- | -- -- |- -- -- --| - -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |
N *<---+ | | +--->* N *<---+ | | +--->*
S | | | +-----+ +-----+ | | | S | | | +-----+ +-----+ | | |
skipping to change at line 1086 skipping to change at line 1106
N | | | | | | | | | | N | | | | | | | | | |
S *<---+ | | | | | | +--->* S *<---+ | | | | | | +--->*
# | | | +-----+ +-----+ | | | # | | | +-----+ +-----+ | | |
2 *<---+ | | +--->* 2 *<---+ | | +--->*
-- -- |- -- -- --|-- -- -- -- -- -- -- -- -- -- -- -- | -- -- -- | -- -- |- -- -- --|-- -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |
| : | | : | | : | | : |
+-----:----+ +----:-----+ +-----:----+ +----:-----+
: : : :
'..............................................' '..............................................'
* SDP, with fine-grained QoS (dedicated resources per Network * SDP, with fine-grained QoS (dedicated resources per network
Slice) slice)
o Coarse-grained QoS, with resources shared by all Network Slices o Coarse-grained QoS, with resources shared by all network slices
... Base NRP ... Base NRP
-- -- Network Slice -- -- Network slice
Figure 11: Resource Allocation Slicing Model with a Single NRP Figure 11: Resource Allocation Slicing Model with a Single NRP
The P nodes shown in Figure 11 are routers that do not interface with The P nodes shown in Figure 11 are routers that do not interface with
customer devices. See Section 5.3.1 of [RFC4026]. customer devices. See Section 5.3.1 of [RFC4026].
This document does not describe in detail how to manage an L2VPN or This document does not describe in detail how to manage an L2VPN or
L3VPN, as this is already well-documented. For example, the reader L3VPN, as this is already well-documented. For example, the reader
may refer to [RFC4176] and [RFC6136] for such details. may refer to [RFC4176] and [RFC6136] for such details.
4. Handoff Between Domains 4. Handoff Between Domains
The 5G control plane relies upon 32-bit S-NSSAIs for slice The 5G control plane relies upon 32-bit S-NSSAIs for slice
identification. The S-NSSAI is not visible to the transport domain. identification. The S-NSSAI is not visible to the transport domain.
So instead, 5G network functions can expose the 5G slices to the So instead, 5G network functions can expose the 5G Network Slices to
transport domain by mapping to explicit Layer 2 or Layer 3 the transport domain by mapping to explicit Layer 2 or Layer 3
identifiers, such as VLAN-IDs, IP addresses, or Differentiated identifiers, such as VLAN-IDs, IP addresses, or Differentiated
Services Code Point (DSCP) values. The following subsections list a Services Code Point (DSCP) values. The following subsections list a
few handoff methods for slice mapping between customer sites and few handoff methods for slice mapping between customer sites and
provider networks. provider networks.
More details about the mapping between 3GPP and RFC 9543 Network More details about the mapping between 3GPP and RFC 9543 Network
Slices is provided in [NS-APP]. Slices is provided in [NS-APP].
4.1. VLAN Handoff 4.1. VLAN Handoff
In this option, the RFC 9543 Network Slice, fulfilling connectivity In this option, the RFC 9543 Network Slice, fulfilling connectivity
requirements between NFs that belong to a 5G slice, is represented at requirements between NFs that belong to a 5G Network Slice, is
an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as represented at an SDP by a VLAN ID (or double VLAN IDs, commonly
depicted in Figure 12. known as QinQ), as depicted in Figure 12.
VLANs representing slices VLANs representing slices VLANs representing slices VLANs representing slices
| +------------------+ | | | +-------------------+ | |
| | | | | | | | | |
+------+ | +-+---+ Provider +---+-+ | +-----+ | +------+ +------+ | +-+----+ Provider +---+--+ | +-----+ | +------+
| | v | | | | v | | v | | | | v | | | | v | | v | |
| +-------+* | | *+-------+ +.......+ | | x------x * | | * x------x x.......x |
| NF +-------+* PE | | PE *+-------+L2/L3+.......+ NF | | NF x------x * PE | | PE * x------xL2/L3x.......x NF |
| +-------+* | | *+-------+ +.......+ | | x------x * | | * x------x x.......x |
| | | | | | | | | | | | | | | | | | | |
+------+ AC +-+---+ Network +---+-+ AC +-----+ +------+ +------+ AC +--+---+ Network +---+--+ AC +-----+ +------+
| | | |
+------------------+ +------------------+
+ Logical interface represented by a VLAN on a physical interface x Logical interface represented by a VLAN on a physical interface
* SDP
Figure 12: Example of 5G Slice with VLAN Handoff Providing End-to-End * SDP
Connectivity
Figure 12: Example of 5G Network Slice with VLAN Handoff
Providing End-to-End Connectivity
Each VLAN represents a distinct logical interface on the ACs and Each VLAN represents a distinct logical interface on the ACs and
hence provides the possibility to place these logical interfaces in hence provides the possibility to place these logical interfaces in
distinct Layer 2 or Layer 3 service instances and implement distinct Layer 2 or Layer 3 service instances and implement
separation between slices via service instances. Since the 5G separation between slices via service instances. Since the 5G
interfaces are IP-based interfaces (with the exception of the F2 interfaces are IP-based interfaces (with the exception of the F2
fronthaul interface, where eCPRI with Ethernet encapsulation is fronthaul interface, where eCPRI with Ethernet encapsulation is
used), this VLAN is typically not transported across the provider used), this VLAN is typically not transported across the provider
network. Typically, it has only local significance at a particular network. Typically, it has only local significance at a particular
SDP. For simplification, a deployment may rely on the same VLAN SDP. For simplification, a deployment may rely on the same VLAN
skipping to change at line 1193 skipping to change at line 1214
defined in [RFC7422] may be considered. defined in [RFC7422] may be considered.
Mapping S-NSSAIs to IP addresses makes IP addresses an identifier for Mapping S-NSSAIs to IP addresses makes IP addresses an identifier for
slice-related policy enforcement in the Transport Network (e.g., slice-related policy enforcement in the Transport Network (e.g.,
differentiated services, traffic steering, bandwidth allocation, differentiated services, traffic steering, bandwidth allocation,
security policies, and monitoring). security policies, and monitoring).
One example of the IP handoff realization is the arrangement in which One example of the IP handoff realization is the arrangement in which
the slices in the TN domain are instantiated using IP tunnels (e.g., the slices in the TN domain are instantiated using IP tunnels (e.g.,
IPsec or GTP-U tunnels) established between NFs, as depicted in IPsec or GTP-U tunnels) established between NFs, as depicted in
Figure 13. The transport for a single 5G slice might be constructed Figure 13. The transport for a single 5G Network Slice might be
with multiple such tunnels, since a typical 5G slice contains many constructed with multiple such tunnels, since a typical 5G Network
NFs, especially DUs and CUs. If a shared NF (i.e., an NF that serves Slice contains many NFs, especially DUs and CUs. If a shared NF
multiple slices, such as a shared DU) is deployed, multiple tunnels (i.e., an NF that serves multiple slices, such as a shared DU) is
from the shared NF are established, each tunnel representing a single deployed, multiple tunnels from the shared NF are established, each
slice. tunnel representing a single slice.
Tunnels representing slices Tunnels representing slices
+------------------+ | +------------------+ |
| | | | | |
+------+ +-+---+ Provider +---+-+ +-----+ | +------+ +------+ +-+---+ Provider +---+-+ +-----+ | +------+
| | | | | | | | v | | | | | | | | | | v | |
| o============*================*==========================o | | o============*================*==========================o |
| NF +-------+ PE | | PE +-------+L2/L3+.......+ NF | | NF +-------+ PE | | PE +-------+L2/L3+.......+ NF |
| o============*================*==========================o | | o============*================*==========================o |
| | | | | | | | | | | | | | | | | | | |
+------+ AC +-+---+ Network +---+-+ AC +-----+ +------+ +------+ AC +-+---+ Network +---+-+ AC +-----+ +------+
| | | |
+------------------+ +------------------+
o Tunnel (IPsec, GTP-U, etc.) termination point o Tunnel (IPsec, GTP-U, etc.) termination point
* SDP * SDP
Figure 13: Example of 5G Slice with IP Handoff Providing End-to- Figure 13: Example of 5G Network Slice with IP Handoff Providing
End Connectivity End-to-End Connectivity
As opposed to the VLAN handoff case (Section 4.1), there is no As opposed to the VLAN handoff case (Section 4.1), there is no
logical interface representing a slice on the PE; hence, all slices logical interface representing a slice on the PE; hence, all slices
are handled within a single service instance. The IP and VLAN are handled within a single service instance. The IP and VLAN
handoffs are not mutually exclusive but instead could be used handoffs are not mutually exclusive but instead could be used
concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping
table similar to the VLAN handoff solution is needed (Section 4.1). table similar to the VLAN handoff solution is needed (Section 4.1).
The mapping table can be simplified if, for example, IPv6 addressing The mapping table can be simplified if, for example, IPv6 addressing
is used to address NFs. An IPv6 address is a 128-bit field, while is used to address NFs. An IPv6 address is a 128-bit field, while
skipping to change at line 1306 skipping to change at line 1327
the customer site, which could be, for example, either on the compute 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/ 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 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 switch within cloud IP fabric (Figure 15, right-hand side)). On the
AC connected to a PE, packets are already MPLS encapsulated (or MPLS- AC connected to a PE, packets are already MPLS encapsulated (or MPLS-
in-UDP/MPLS-in-IP encapsulated, if cloud or compute infrastructure in-UDP/MPLS-in-IP encapsulated, if cloud or compute infrastructure
don't support MPLS encapsulation). Therefore, the PE uses neither a don't support MPLS encapsulation). Therefore, the PE uses neither a
VLAN nor an IP address for slice identification at the SDP but VLAN nor an IP address for slice identification at the SDP but
instead uses the MPLS label. instead uses the MPLS label.
<------ <------ <------ <------ <------ <------
BGP VPN BGP VPN BGP VPN BGP VPN BGP VPN BGP VPN
COM=1, L=A" COM=1, L=A' COM=1, L=A 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=2, L=B" COM=2, L=B' COM=2, L=B
COM=3, L=C" COM=3, L=C' COM=3, L=C COM=3, L=C" COM=3, L=C' COM=3, L=C
<-------------><------------><-------------> <-----------><-------------><------------>
nhs nhs nhs nhs nhs nhs nhs nhs
VLANs VLANs
service instances service instances representing service instances service instances representing
representing slices representing slices slices representing slices representing slices slices
| | | | | |
+---+ | +--------------+ +-|--------|----------+ +---+ | +-------------+ +-|--------|----------+
| | | | Provider | | | | | | | | | Provider | | | | |
| +-+--v-+ +-+---+ +--+--+ +-+-v----+ v +-----+ | | +-+--v-+ +--+--+ +--+--+ +-+-v----+ v +-----+ |
| | # | |* | | *| | #<><>x......x | | | | # | | * | | * | | #<><>x......x | |
| | NF # +------+* PE | | PE *+------+ #<><>x......x NF | | | | NF # +------+ * PE| |PE * +------+ #<><>x......x NF | |
| | # | AC |* | | *| AC | #<><>x......x | | | | # | AC | * | | * | AC | #<><>x......x | |
| +--+---+ +-+---+ +---+-+ +-+------+ +-----+ | | +--+---+ +--+--+ +--+--+ +-+------+ +-----+ |
| CS1| | Network | | L2/L3 CS2 | | CS1| | Network | | L2/L3 CS2 |
+----+ +---------------+ +---------------------+ +----+ +-------------+ +---------------------+
x Logical interface represented by a VLAN on a physical interface x Logical interface represented by a VLAN on a physical interface
# Service instances (with unique MPLS labels) # Service instances (with unique MPLS labels)
* SDP * SDP
Figure 15: Example of MPLS Handoff with Option B Figure 15: Example of MPLS Handoff with Option B
MPLS labels are allocated dynamically in Option B deployments, where, MPLS labels are allocated dynamically in Option B deployments, where,
at the domain boundaries, service prefixes are reflected with next- at the domain boundaries, service prefixes are reflected with next-
hop self (nhs), and a new label is dynamically allocated, as shown in 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). Figure 15 (e.g., labels A, A', and A" for the first depicted slice).
Therefore, for any slice-specific per-hop behavior at the provider Therefore, for any slice-specific per-hop behavior at the provider
network edge, the PE needs to determine which label represents which network edge, the PE needs to determine which label represents which
slice. In the BGP control plane, when exchanging service prefixes slice. In the BGP control plane, when exchanging service prefixes
over an AC, each slice might be represented by a unique BGP over an AC, each slice might be represented by a unique BGP
community, so tracking label assignment to the slice might be community, so tracking label assignment to the slice might be
possible. For example, in Figure 15, for the slice identified with possible. For example, in Figure 15, for the slice identified with
COM-1, the PE advertises a dynamically allocated label A". Since, COM=1, the PE advertises a dynamically allocated label A". Since,
based on the community, the label-to-slice association is known, the based on the community, the label-to-slice association is known, the
PE can use this dynamically allocated label A" to identify incoming PE can use this dynamically allocated label A" to identify incoming
packets as belonging to "slice 1" and execute appropriate edge per- packets as belonging to "slice 1" and execute appropriate edge per-
hop behavior. hop behavior.
It is worth noting that slice identification in the BGP control plane It is worth noting that slice identification in the BGP control plane
might be with per-prefix granularity. In the extreme case, each might be with per-prefix granularity. In the extreme case, each
prefix can have a different community representing a different slice. prefix can have a different community representing a different slice.
Depending on the business requirements, each slice could be Depending on the business requirements, each slice could be
represented by a different service instance as outlined in Figure 15. represented by a different service instance as outlined in Figure 15.
skipping to change at line 1382 skipping to change at line 1403
programming appropriate forwarding entries for service prefixes. programming appropriate forwarding entries for service prefixes.
Option C relies upon exchanging service prefixes via multi-hop BGP Option C relies upon exchanging service prefixes via multi-hop BGP
sessions between customer sites, without changing the NEXT_HOP BGP sessions between customer sites, without changing the NEXT_HOP BGP
attribute. Additionally, IPv4/IPv6 labeled unicast (SAFI-4) host attribute. Additionally, IPv4/IPv6 labeled unicast (SAFI-4) host
routes, used as NEXT_HOP for service prefixes, are exchanged via routes, used as NEXT_HOP for service prefixes, are exchanged via
direct single-hop BGP sessions between adjacent nodes in a customer direct single-hop BGP sessions between adjacent nodes in a customer
site and a provider network, as depicted in Figure 16. As a result, site and a provider network, as depicted in Figure 16. As a result,
a node in a customer site performs hierarchical next-hop resolution. a node in a customer site performs hierarchical next-hop resolution.
<------------------------------------------- <----------------------------------------
BGP VPN BGP VPN
COM=1, L=A, NEXT_HOP=CS2 COM=1, L=A, NEXT_HOP=CS2
COM=2, L=B, NEXT_HOP=CS2 COM=2, L=B, NEXT_HOP=CS2
COM=3, L=C, NEXT_HOP=CS2 COM=3, L=C, NEXT_HOP=CS2
<------------------------------------------> <--------------------------------------->
<------ <------ <------ <------ <------ <------
BGP LU BGP LU BGP LU BGP LU BGP LU BGP LU
CS2, L=X" CS2, L=X' CS2, L=X CS2, L=X" CS2, L=X' CS2, L=X
<-------------><------------><-------------> <-----------><--------------><---------->
nhs nhs nhs nhs nhs nhs nhs nhs
VLANs VLANs
service instances service instances representing service instances service instances representing
representing slices representing slices slices representing slices representing slices slices
| | | | | |
+---+ | +--------------+ +-|--------|----------+ +---+ | +-------------+ +-|--------|----------+
| | | | Provider | | | | | | | | | Provider | | | | |
| +-+-v-+ +-+---+ +--+--+ +-+-v----+ v +-----+ | | +-+-v-+ +--+--+ +--+--+ +-+-v----+ v +-----+ |
| | # | |* | | *| | #<><>x......x | | | | # | | * | | * | | #<><>x......x | |
| |NF # +-------+* PE | | PE *+------+ #<><>x......x NF | | | |NF # +-------+ * PE| |PE * +------+ #<><>x......x NF | |
| | # | AC |* | | *| AC | #<><>x......x | | | | # | AC | * | | * | AC | #<><>x......x | |
| +--+--+ +-+---+ +---+-+ +-+------+ +-----+ | | +--+--+ +--+--+ +--+--+ +-+------+ +-----+ |
| CS1| | Network | | L2/L3 CS2 | | CS1| | Network | | L2/L3 CS2 |
+----+ +---------------+ +---------------------+ +----+ +-------------+ +---------------------+
x Logical interface represented by a VLAN on a physical interface x Logical interface represented by a VLAN on a physical interface
# Service instances (with unique MPLS label) # Service instances (with unique MPLS label)
* SDP * SDP
Figure 16: Example of MPLS Handoff with Option C Figure 16: Example of MPLS Handoff with Option C
This architecture requires an end-to-end Label Switched Path (LSP) This architecture requires an end-to-end Label Switched Path (LSP)
leading from a packet's ingress node inside one customer site to its leading from a packet's ingress node inside one customer site to its
egress inside another customer site, through a provider network. egress inside another customer site, through a provider network.
Hence, at the domain (customer site and provider network) boundaries, Hence, at the domain (customer site and provider network) boundaries,
the NEXT_HOP attribute for IPv4/IPv6 labeled unicast needs to be 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 modified to next-hop self (nhs), which results in a new IPv4/IPv6
labeled unicast label allocation. Appropriate label swap forwarding labeled unicast label allocation. Appropriate forwarding entries for
entries for IPv4/IPv6 labeled unicast labels are programmed in the label swaps for IPv4/IPv6 labeled unicast labels are programmed in
data plane. There is no additional "labeled transport" protocol on the data plane. There is no additional "labeled transport" protocol
the AC (e.g., no LDP, RSVP, or SR). on the AC (e.g., no LDP, RSVP, or SR).
Packets are transmitted over the AC with the IPv4/IPv6 labeled Packets are transmitted over the AC with the IPv4/IPv6 labeled
unicast as the top label, with the service label deeper in the label unicast as the top label, with the service label deeper in the label
stack. In Option C, the service label is not used for forwarding stack. In Option C, the service label is not used for forwarding
lookup on the PE. This significantly lowers the scaling pressure on lookup on the PE. This significantly lowers the scaling pressure on
PEs, as PEs need to program forwarding entries only for IPv4/IPv6 PEs, as PEs need to program forwarding entries only for IPv4/IPv6
labeled unicast host routes, used as NEXT_HOP for service prefixes. labeled unicast host routes, which are used as NEXT_HOP for service
Also, since one IPv4/IPv6 labeled unicast host route represents one prefixes. Also, since one IPv4/IPv6 labeled unicast host route
customer site, regardless of the number of slices in the customer represents one customer site, regardless of the number of slices in
site, the number of forwarding entries on a PE is considerably the customer site, the number of forwarding entries on a PE is
reduced. considerably reduced.
For any slice-specific per-hop behavior at the provider network edge, For any slice-specific per-hop behavior at the provider network edge,
as described in detail in Section 3.7, the PE needs to determine as described in detail in Section 3.7, the PE needs to determine
which label in the packet represents which slice. This can be which label in the packet represents which slice. This can be
achieved, for example, by allocating non-overlapping service label achieved, for example, by allocating non-overlapping service label
ranges for each slice and using those ranges for slice identification ranges for each slice and using those ranges for slice identification
purposes on the PE. purposes on the PE.
5. QoS Mapping Realization Models 5. QoS Mapping Realization Models
skipping to change at line 1466 skipping to change at line 1487
that is used as a reference to 5G QoS characteristics (e.g., that is used as a reference to 5G QoS characteristics (e.g.,
scheduling weights, admission thresholds, queue management scheduling weights, admission thresholds, queue management
thresholds, and link-layer protocol configuration) in the RAN domain. thresholds, and link-layer protocol configuration) in the RAN domain.
Given that 5QI applies to the RAN domain, it is not visible to the Given that 5QI applies to the RAN domain, it is not visible to the
provider network. Therefore, if 5QI-aware treatment is desired in provider network. Therefore, if 5QI-aware treatment is desired in
the provider network, 5G network functions might set DSCP with a the provider network, 5G network functions might set DSCP with a
value representing 5QI so that differentiated treatment can be value representing 5QI so that differentiated treatment can be
implemented in the provider network as well. Based on these DSCP implemented in the provider network as well. Based on these DSCP
values, very granular QoS enforcement might be implemented at the SDP values, very granular QoS enforcement might be implemented at the SDP
of each provider network segment used to construct transport for of each provider network segment used to construct transport for
given 5G slice. given 5G Network Slice.
The exact mapping between 5QI and DSCP is out of scope for this The exact mapping between 5QI and DSCP is out of scope for this
document. Mapping recommendations are documented, e.g., in document. Mapping recommendations are documented, e.g., in
[MAPPING]. [MAPPING].
Each slice service might have flows with multiple 5QIs. 5QIs (or, Each Slice Service might have flows with multiple 5QIs. 5QIs (or,
more precisely, corresponding DSCP values) are visible to the more precisely, corresponding DSCP values) are visible to the
provider network at SDPs (i.e., at the edge of the provider network). 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" In this document, this layer of QoS is referred to as "5G QoS Class"
("5G QoS" in short) or "5G DSCP". ("5G QoS" in short) or "5G DSCP".
5.1.2. Transport Network (TN) QoS Layer 5.1.2. Transport Network (TN) QoS Layer
Control of the TN resources and traffic scheduling/prioritization on Control of the TN resources and traffic scheduling/prioritization on
provider network transit links are based on a flat (non-hierarchical) provider network transit links are based on a flat (non-hierarchical)
QoS model in this Network Slice realization. That is, RFC 9543 QoS model in this network slice realization. That is, RFC 9543
Network Slices are assigned dedicated resources (e.g., QoS queues) at Network Slices are assigned dedicated resources (e.g., QoS queues) at
the edge of the provider network (at SDPs), while all RFC 9543 the edge of the provider network (at SDPs), while all RFC 9543
Network Slices are sharing resources (sharing QoS queues) on the Network Slices are sharing resources (sharing QoS queues) on the
transit links of the provider network. Typical router hardware can transit links of the provider network. Typical router hardware can
support up to 8 traffic queues per port; therefore, this document support up to 8 traffic queues per port; therefore, this document
assumes support for 8 traffic queues per port in general. assumes support for 8 traffic queues per port in general.
At this layer, QoS treatment is indicated by a QoS indicator specific At this layer, QoS treatment is indicated by a QoS indicator specific
to the encapsulation used in the provider network. Such an indicator to the encapsulation used in the provider network. Such an indicator
may be a DSCP or MPLS Traffic Class (TC). This layer of QoS is may be a DSCP or MPLS Traffic Class (TC). This layer of QoS is
skipping to change at line 1513 skipping to change at line 1534
capability to set DSCP), or it might simply depend on the overall capability to set DSCP), or it might simply depend on the overall
slicing deployment model. The O-RAN Alliance, for example, defines a slicing deployment model. The O-RAN Alliance, for example, defines a
phased approach to the slicing, with initial phases utilizing only phased approach to the slicing, with initial phases utilizing only
per-slice, but not per-5QI, differentiated treatment in the TN domain per-slice, but not per-5QI, differentiated treatment in the TN domain
(see Annex F of [O-RAN.WG9.XPSAAS]). (see Annex F of [O-RAN.WG9.XPSAAS]).
Therefore, from a QoS perspective, the 5G slicing connectivity Therefore, from a QoS perspective, the 5G slicing connectivity
realization defines two high-level realization models for slicing in realization defines two high-level realization models for slicing in
the TN domain: a 5QI-unaware model and a 5QI-aware model. Both 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 slicing models in the TN domain could be used concurrently within the
same 5G slice. For example, the TN segment for 5G midhaul (F1-U same 5G Network Slice. For example, the TN segment for 5G midhaul
interface) might be 5QI-aware, while at the same time, the TN segment (F1-U interface) might be 5QI-aware, while at the same time, the TN
for 5G backhaul (N3 interface) might follow the 5QI-unaware model. segment for 5G backhaul (N3 interface) might follow the 5QI-unaware
model.
These models are further elaborated in the following two subsections. These models are further elaborated in the following two subsections.
5.2.1. 5QI-Unaware Model 5.2.1. 5QI-Unaware Model
In the 5QI-unaware model, the DSCP values in the packets received In the 5QI-unaware model, the DSCP values in the packets received
from NF at SDP are ignored. In the provider network, there is no QoS from NF at SDP are ignored. In the provider network, there is no QoS
differentiation at the 5G QoS Class level. The entire RFC 9543 differentiation at the 5G QoS Class level. The entire RFC 9543
Network Slice is mapped to a single TN QoS Class and therefore to a Network Slice is mapped to a single TN QoS Class and therefore to a
single QoS queue on the routers in the provider network. With a low single QoS queue on the routers in the provider network. With a low
number of deployed 5G slices (for example, only two 5G slices: eMBB number of deployed 5G Network Slices (for example, only two 5G
and MIoT), it is possible to dedicate a separate QoS queue for each Network Slices: eMBB and MIoT), it is possible to dedicate a separate
slice on transit routers in the provider network. However, with the QoS queue for each slice on transit routers in the provider network.
introduction of private/enterprises slices, as the number of 5G However, with the introduction of private/enterprises slices, as the
slices (and thus the corresponding RFC 9543 Network Slices) number of 5G Network Slices (and thus the corresponding RFC 9543
increases, a single QoS queue on transit links in the provider Network Slices) increases, a single QoS queue on transit links in the
network serves multiple slices with similar characteristics. QoS provider network serves multiple slices with similar characteristics.
enforcement on transit links is fully coarse-grained (single NRP, QoS enforcement on transit links is fully coarse-grained (single NRP,
sharing resources among all RFC 9543 Network Slices), as displayed in sharing resources among all RFC 9543 Network Slices), as displayed in
Figure 17. Figure 17.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
+-------------------. PE | +-------------------. PE |
| .--------------+ | | | .--------------+ | |
| | SDP | | .------------------------------+ | | SDP | | .------------------------------+
| | +----------+ | | | Transit link | | | +----------+ | | | Transit link |
| | | NS 1 +-------------+ | .------------------------. | | | | NS 1 +-------------+ | .------------------------. |
| | +----------+ | | +-----|--> TN QoS Class 1 | | | | +----------+ | | +-----|--> TN QoS Class 1 | |
skipping to change at line 1641 skipping to change at line 1663
| | \ | | | | \ | |
| | | | | | | |
| Payload | / | Payload | | Payload | / | Payload |
|(GTP-U/IPsec) | / |(GTP-U/IPsec) | |(GTP-U/IPsec) | / |(GTP-U/IPsec) |
| | / | | | | / | |
| |---------+ / | | | |---------+ / | |
| | | / | | | | | / | |
| | |/ | | | | |/ | |
+--------------+ - - - - - - - - +--------------+ +--------------+ - - - - - - - - +--------------+
Figure 19: QoS with IPv6 Encapsulation Figure 19: QoS with SRv6 Encapsulation
From a QoS perspective, both options are similar. However, there is From a QoS perspective, both options are similar. However, there is
one difference between the two options. The MPLS TC is only 3 bits one difference between the two options. The MPLS TC is only 3 bits
(8 possible combinations), while DSCP is 6 bits (64 possible (8 possible combinations), while DSCP is 6 bits (64 possible
combinations). Hence, SRv6 provides more flexibility for TN CoS combinations). Hence, SRv6 provides more flexibility for TN CoS
design, especially in combination with soft policing with in-profile design, especially in combination with soft policing with in-profile
and out-of-profile traffic, as discussed in Section 5.2.1.1. and out-of-profile traffic, as discussed in Section 5.2.1.1.
Provider network edge resources are controlled in a fine-grained Provider network edge resources are controlled in a fine-grained
manner, with dedicated resource allocation for each RFC 9543 Network manner, with dedicated resource allocation for each RFC 9543 Network
skipping to change at line 1686 skipping to change at line 1708
* PIR: Peak Information Rate (i.e., maximum bandwidth) * PIR: Peak Information Rate (i.e., maximum bandwidth)
These parameters define the traffic characteristics of the slice and 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. are part of the SLO parameter set provided by the 5G NSO to an NSC.
Based on these parameters, the provider network's inbound policy can Based on these parameters, the provider network's inbound policy can
be implemented using one of following options: be implemented using one of following options:
* 1r2c (single-rate two-color) rate limiter * 1r2c (single-rate two-color) rate limiter
This is the most basic rate limiter, described in Section 2.3 of This is the most basic rate limiter, described in Section 2.3 of
[RFC2475]. At the SDP, it meters a traffic stream of a given [RFC2475] (though not termed “1r2c” in that document). At the
slice and marks its packets as in-profile (below CIR being SDP, it meters a traffic stream of a given slice and marks its
enforced) or out-of-profile (above CIR being enforced). In- packets as in-profile (below CIR being enforced) or out-of-profile
profile packets are accepted and forwarded. Out-of-profile (above CIR being enforced). In-profile packets are accepted and
packets are either dropped right at the SDP (hard rate limiting) forwarded. Out-of-profile packets are either dropped right at the
or re-marked (with different MPLS TC or DSCP TN markings) to SDP (hard rate limiting) or re-marked (with different MPLS TC or
signify "this packet should be dropped in the first place, if DSCP TN markings) to signify "this packet should be dropped in the
there is congestion" (soft rate limiting), depending on the first place, if there is congestion" (soft rate limiting),
business policy of the provider network. In the latter case, depending on the business policy of the provider network. In the
while packets above CIR are forwarded at the SDP, they are subject latter case, while packets above CIR are forwarded at the SDP,
to being dropped during any congestion event at any place in the they are subject to being dropped during any congestion event at
provider network. any place in the provider network.
* 2r3c (two-rate three-color) rate limiter * 2r3c (two-rate three-color) rate limiter
This was initially defined in [RFC2698], and an improved version This was initially defined in [RFC2698], and an improved version
is defined in [RFC4115]. In essence, the traffic is assigned to is defined in [RFC4115]. In essence, the traffic is assigned to
one of the these three categories: one of the these three categories:
- Green, for traffic under CIR - Green, for traffic under CIR
- Yellow, for traffic between CIR and PIR - Yellow, for traffic between CIR and PIR
skipping to change at line 1721 skipping to change at line 1743
An inbound 2r3c meter implemented with [RFC4115], compared to An inbound 2r3c meter implemented with [RFC4115], compared to
[RFC2698], is more "customer friendly" as it doesn't impose [RFC2698], is more "customer friendly" as it doesn't impose
outbound peak-rate shaping requirements on CE devices. In outbound peak-rate shaping requirements on CE devices. In
general, 2r3c meters give greater flexibility for provider network general, 2r3c meters give greater flexibility for provider network
edge enforcement regarding accepting the traffic (green), edge enforcement regarding accepting the traffic (green),
deprioritizing and potentially dropping the traffic on transit deprioritizing and potentially dropping the traffic on transit
during congestion (yellow), or hard-dropping the traffic (red). during congestion (yellow), or hard-dropping the traffic (red).
Inbound provider network edge enforcement for the 5QI-unaware model, Inbound provider network edge enforcement for the 5QI-unaware model,
where all packets belonging to the slice are treated the same way in where all packets belonging to the slice are treated the same way in
the provider network (no 5Q QoS Class differentiation in the the provider network (no 5G QoS Class differentiation in the
provider), is outlined in Figure 20. provider), is outlined in Figure 20.
Slice Slice
policer +---------+ policer +---------+
| +---|--+ | | +---|--+ |
| | | | | | | |
| | S | | | | S | |
| | l | | | | l | |
v | i | | v | i | |
-------------<>----|--> c | | -------------<>----|--> c | |
skipping to change at line 1834 skipping to change at line 1856
| | | |
+---------+ +---------+
Figure 21: Ingress Slice Admission Control (5QI-Unaware Model) - Figure 21: Ingress Slice Admission Control (5QI-Unaware Model) -
Output Output
5.2.2. 5QI-Aware Model 5.2.2. 5QI-Aware Model
In the 5QI-aware model, a potentially large number of 5G QoS Classes, In the 5QI-aware model, a potentially large number of 5G QoS Classes,
represented via the DSCP set by NFs (the architecture scales to represented via the DSCP set by NFs (the architecture scales to
thousands of 5G slices), is mapped (multiplexed) to up to 8 TN QoS thousands of 5G Network Slices), is mapped (multiplexed) to up to 8
Classes used in a provider network transit equipment, as outlined in TN QoS Classes used in a provider network transit equipment, as
Figure 22. outlined in Figure 22.
+---------------------------------------------------------------+ +---------------------------------------------------------------+
+-------------------+ PE | +-------------------+ PE |
| .--------------+ | | | .--------------+ | |
R | | SDP | | +-----------------------------+ R | | SDP | | +-----------------------------+
F | | .---------. | | | Transit link | F | | .---------. | | | Transit link |
C | | | 5G DSCP A +---------------+ | .-----------------------. | C | | | 5G DSCP A +---------------+ | .-----------------------. |
9 | | '---------' | | +---|--> TN QoS Class 1 | | 9 | | '---------' | | +---|--> TN QoS Class 1 | |
5 | | .---------. | | | | '-----------------------' | 5 | | .---------. | | | | '-----------------------' |
4 | | | 5G DSCP B +------------+ | | .-----------------------. | 4 | | | 5G DSCP B +------------+ | | .-----------------------. |
skipping to change at line 1876 skipping to change at line 1898
2 | | | 5G DSCP G +------+ | '-----------------------' | 2 | | | 5G DSCP G +------+ | '-----------------------' |
| | '---------' | | | Max 8 TN Classes | | | '---------' | | | Max 8 TN Classes |
| | SDP | | +-----------------------------+ | | SDP | | +-----------------------------+
| '--------------' | | | '--------------' | |
+-------------------+ | +-------------------+ |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Fine-grained QoS enforcement Coarse-grained QoS enforcement Fine-grained QoS enforcement Coarse-grained QoS enforcement
(dedicated resources per (resources shared by multiple (dedicated resources per (resources shared by multiple
RFC 9543 Network Slice) RFC 9543 Network Slices) RFC 9543 Network Slice) RFC 9543 Network Slices)
Figure 22: Mapping of Slice 5Q QoS to TN QoS (5QI-Aware Model) Figure 22: Mapping of Slice 5G QoS to TN QoS (5QI-Aware Model)
Given that in deployments with a large number of 5G slices, the Given that in deployments with a large number of 5G Network Slices,
number of potential 5G QoS Classes is much higher than the number of the number of potential 5G QoS Classes is much higher than the number
TN QoS Classes, multiple 5G QoS Classes with similar characteristics of TN QoS Classes, multiple 5G QoS Classes with similar
-- potentially from different slices -- would be grouped with common characteristics -- potentially from different slices -- would be
operator-defined TN logic and mapped to the same TN QoS Class when grouped with common operator-defined TN logic and mapped to the same
transported in the provider network. That is, common Per-Hop TN QoS Class when transported in the provider network. That is,
Behavior (PHB) [RFC2474] is executed on transit provider network common Per-Hop Behavior (PHB) [RFC2474] is executed on transit
routers for all packets grouped together. An example of this provider network routers for all packets grouped together. An
approach is outlined in Figure 23. A provider may decide to example of this approach is outlined in Figure 23. A provider may
implement Diffserv-Intercon PHBs at the boundaries of its network decide to implement Diffserv-Intercon PHBs at the boundaries of its
domain [RFC8100]. network domain [RFC8100].
| Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP, | Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP,
| queue, etc.) are provided for illustration purposes only and | queue, etc.) are provided for illustration purposes only and
| should not be considered as deployment guidance. | should not be considered as deployment guidance.
+--------------- PE -----------------+ +--------------- PE -----------------+
+------ NF-A ---------+ | | +------ NF-A ------------+ | |
| | | .----------+ | | | | .----------+ |
| 3GPP S-NSSAI 100 | | | SDP | | | 3GPP S-NSSAI 100 | | | SDP | |
| .------. .-------. | | | .-------. | | | .-----. .-------. | | | .------. | |
| |5QI=1 +->DSCP=46 +------>DSCP=46 +---+ | | |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ |
| '------' '-------' | | | '-------' | | | | '-----' '-------' | | | '------' | | |
| .------. .-------. | | | .-------. | | | | .-----. .-------. | | | .------. | | |
| |5QI=65+->DSCP=46 +------>DSCP=46 +---+ | | |5QI=65 +->+DSCP=46 +----->+DSCP=46 +----+ |
| '------' '-------' | | | '-------' | | | | '-----' '-------' | | | '------' | | |
| .------. .-------. | | | .-------. | | | | .-----. .-------. | | | .------. | | |
| |5QI=7 +->DSCP=10 +------>DSCP=10 +---)-+ .------------. | | |5QI=7 +->+DSCP=10 +----->+DSCP=10 +----)-+ .------------. |
| '------' '-------' | | | '-------' | | | |TN QoS Class 5| | | '-----' '-------' | | | '------' | | | |TN QoS Class 5| |
+---------------------+ | '----------' +-)--> Queue 5 | | +------------------------+ | '----------' +-)--> Queue 5 | |
| | | '------------' | | | | '------------' |
+------- NF-B --------+ | | | | +------- NF-B -----------+ | | | |
| | | .----------+ | | | | | | .----------+ | | |
| 3GPP S-NSSAI 200 | | | SDP | | | | | 3GPP S-NSSAI 200 | | | SDP | | | |
| .------. .-------. | | | .-------. | | | | | .-----. .-------. | | | .------. | | | |
| |5QI=1 +->DSCP=46 +------>DSCP=46 +---+ | .------------. | | |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ | .------------. |
| '------' '-------' | | | '-------' | | | |TN QoS Class 1| | | '-----' '-------' | | | '------' | | | |TN QoS Class 1| |
| .------. .-------. | | | .-------. | | +--> Queue 1 | | | .-----. .-------. | | | .-------. | | +--> Queue 1 | |
| |5QI=65+->DSCP=46 +------>DSCP=46 +---+ | '------------' | | |5QI=65 +->+DSCP=46 +----->+DSCP=46 +---+ | '------------' |
| '------' '-------' | | | '-------' | | | | '-----' '-------' | | | '-------' | | |
| .------. .-------. | | | .-------. | | | | .-----. .-------. | | | .-------. | | |
| |5QI=7 +->DSCP=10 +------>DSCP=10 +-----+ | | |5QI=7 +->+DSCP=10 +----->+DSCP=10 +-----+ |
| '------' '-------' | | | '-------' | | | '-----' '-------' | | | '-------' | |
+---------------------+ | '----------' | +------------------------+ | '----------' |
+--------------------------------------+ +--------------------------------------+
Figure 23: Example of 3GPP QoS Mapped to TN QoS Figure 23: Example of 3GPP QoS Mapped to TN QoS
In current SDO progress of 3GPP (Release 17) and O-RAN, the mapping In current SDO progress of 3GPP (Release 19) and O-RAN, the mapping
of 5QI to DSCP is not expected to be in a per-slice fashion, where of 5QI to DSCP is not expected to be in a per-slice fashion, where
5QI-to-DSCP mapping may vary from 3GPP slice to 3GPP slice; hence, 5QI-to-DSCP mapping may vary from 3GPP slice to 3GPP slice; hence,
the mapping of 5G QoS DSCP values to TN QoS Classes may be rather the mapping of 5G QoS DSCP values to TN QoS Classes may be rather
common. common.
Like in the 5QI-unaware model, the original IP header retains the Like in the 5QI-unaware model, the original IP header retains the
DSCP marking corresponding to 5QI (5G QoS Class), while the new DSCP marking corresponding to 5QI (5G QoS Class), while the new
header (MPLS or IPv6) carries the QoS marking related to TN QoS header (MPLS or IPv6) carries the QoS marking related to TN QoS
Class. Based on the TN QoS Class marking, per-hop behavior for all Class. Based on the TN QoS Class marking, per-hop behavior for all
aggregated 5G QoS Classes from all RFC 9543 Network Slices is aggregated 5G QoS Classes from all RFC 9543 Network Slices is
executed on the provider network transit links. Provider network executed on the provider network transit links. Provider network
transit routers do not evaluate the original IP header for QoS- transit routers do not evaluate the original IP header for QoS-
related decisions. The original DSCP marking retained in the related decisions. The original DSCP marking retained in the
original IP header is used at the PE for fine-grained inbound/ original IP header is used at the PE for fine-grained inbound/
outbound enforcement per slice and per 5G QoS Class on the AC. outbound enforcement per slice and per 5G QoS Class on the AC.
In the 5QI-aware model, compared to the 5QI-unaware model, provider In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more granular, fine- network edge resources are controlled in an even more fine-grained
grained manner, with dedicated resource allocation for each RFC 9543 manner, with dedicated resource allocation for each RFC 9543 Network
Network Slice and for a number of traffic classes (most commonly up 4 Slice and for a number of traffic classes (most commonly, up to 4 or
or 8 traffic classes, depending on the hardware capability of the 8 traffic classes, depending on the hardware capability of the
equipment) within each RFC 9543 Network Slice. equipment) within each RFC 9543 Network Slice.
5.2.2.1. Inbound Edge Resource Control 5.2.2.1. Inbound Edge Resource Control
Compared to the 5QI-unaware model, admission control (traffic Compared to the 5QI-unaware model, admission control (traffic
conditioning) in the 5QI-aware model is more granular, as it not only conditioning) in the 5QI-aware model is more granular, as it not only
enforces per-slice capacity constraints, but may also enforce the enforces per-slice capacity constraints, but may also enforce the
constraints per 5G QoS Class within each slice. constraints per 5G QoS Class within each slice.
A 5G slice using multiple 5QIs can potentially specify rates in one A 5G Network Slice using multiple 5QIs can potentially specify rates
of the following ways: in one of the following ways:
* Rates per traffic class (CIR or CIR+PIR), no rate per slice (sum * Rates per traffic class (CIR or CIR+PIR), no rate per slice (sum
of rates per class gives the rate per slice). of rates per class gives the rate per slice).
* Rate per slice (CIR or CIR+PIR), and rates per prioritized * Rate per slice (CIR or CIR+PIR), and rates per prioritized
(premium) traffic classes (CIR only). A best-effort traffic class (premium) traffic classes (CIR only). A best-effort traffic class
uses the bandwidth (within slice CIR/PIR) not consumed by uses the bandwidth (within slice CIR/PIR) not consumed by
prioritized classes. prioritized classes.
In the first option, the slice admission control is executed with In the first option, the slice admission control is executed with
traffic class granularity, as outlined in Figure 24. In this model, traffic class granularity, as outlined in Figure 24. In this model,
if a premium class doesn't consume all available class capacity, it if a premium class doesn't consume all available class capacity, it
cannot be reused by a non-premium (i.e., best effort) class. cannot be reused by a non-premium class (i.e., best-effort).
Class +---------+ Class +---------+
policer +--|---+ | policer +--|---+ |
| | | | | |
5Q-QoS-A: CIR-1A ------<>-----------|--> S | | 5Q-QoS-A: CIR-1A ------<>-----------|--> S | |
5Q-QoS-B: CIR-1B ------<>-----------|--> l | | 5Q-QoS-B: CIR-1B ------<>-----------|--> l | |
5Q-QoS-C: CIR-1C ------<>-----------|--> i | | 5Q-QoS-C: CIR-1C ------<>-----------|--> i | |
| c | | | c | |
| e | | | e | |
BE CIR/PIR-1D ------<>-----------|--> | A | BE CIR/PIR-1D ------<>-----------|--> | A |
skipping to change at line 2060 skipping to change at line 2082
'-' | | | '-' | | |
+--|---+ | +--|---+ |
+---------+ +---------+
Figure 25: Ingress Slice Admission Control (5QI-Aware Model) - Figure 25: Ingress Slice Admission Control (5QI-Aware Model) -
Hierarchical Hierarchical
5.2.2.2. Outbound Edge Resource Control 5.2.2.2. Outbound Edge Resource Control
Figure 26 outlines the outbound edge resource control model at the Figure 26 outlines the outbound edge resource control model at the
transport network layer for 5QI-aware slices. Each slice is assigned Transport Network layer for 5QI-aware slices. Each slice is assigned
multiple egress queues. The sum of queue weights, which are 5Q QoS 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 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 itself. And, similar to the 5QI-aware model, the sum of slice CIRs
should not exceed the physical capacity of the AC. should not exceed the physical capacity of the AC.
+---------+ QoS output queues +---------+ QoS output queues
| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - - | +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
| | .--|--------------------------. \|/ | | .--|--------------------------. \|/
---|-----|---|--> 5Q-QoS-A: w-5Q-QoS-A-CIR | | ---|-----|---|--> 5Q-QoS-A: w-5Q-QoS-A-CIR | |
| | S '-----------------------------' | | | S '-----------------------------' |
| | l .-----------------------------. | | | l .-----------------------------. |
skipping to change at line 2086 skipping to change at line 2108
| | 1 '-----------------------------' | | | 1 '-----------------------------' |
| | .-----------------------------. | | | .-----------------------------. |
---|-----|---|--> Best Effort (remainder) | | ---|-----|---|--> Best Effort (remainder) | |
| | '--|--------------------------' /|\ | | '--|--------------------------' /|\
| A +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | A +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| t | .--|--------------------------. \|/ | t | .--|--------------------------. \|/
| t | | | | | t | | | |
| a | '-----------------------------' | | a | '-----------------------------' |
| c | S | | | c | S | |
| h | l | | h | l |
| m | i ... | weight-Slice-2-CIR | m | i | ... | weight-Slice-2-CIR
| e | c | | shaping-Slice-2-PIR | e | c | | shaping-Slice-2-PIR
| n | e .-----------------------------. | | n | e .-----------------------------. |
| t | | | | | t | | | |
| | 2 '-----------------------------' /|\ | | 2 '-----------------------------' /|\
| C +-------+ - - - - - - - - - - - - - - - - - - - - - - - - - | C +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| i | | \|/ | i | | \|/
| r + .-----------------------------. | | r + .-----------------------------. |
| c | | | | | c | | | |
| u | '-----------------------------' | | u | '-----------------------------' |
| i | S | | | i | S | |
| t | l | | | t | l | |
| | i ... | weight-Slice-3-CIR | | i | ... | weight-Slice-3-CIR
| | c | | shaping-Slice-3-PIR | | c | | shaping-Slice-3-PIR
| | e .-----------------------------. | | | e .-----------------------------. |
| | | | | | | | | |
| | 3 '-----------------------------' /|\ | | 3 '-----------------------------' /|\
| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - - | +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
+---------+ +---------+
Figure 26: Egress Slice Admission Control (5QI-Aware Model) Figure 26: Egress Slice Admission Control (5QI-Aware Model)
5.3. Transit Resource Control 5.3. Transit Resource Control
Transit resource control is much simpler than edge resource control Transit resource control is much simpler than edge resource control
in the provider network. As outlined in Figure 22, at the provider in the provider network. As outlined in Figure 22, at the provider
network edge, 5Q QoS Class marking (represented by DSCP related to network edge, 5G QoS Class marking (represented by DSCP related to
5QI set by mobile network functions in the packets handed off to the 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 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 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 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 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 network transit routers is based exclusively on that TN QoS Class
marking, i.e., original 5G QoS Class DSCP is not taken into marking, i.e., original 5G QoS Class DSCP is not taken into
consideration on transit. consideration on transit.
Provider network transit resource control does not use any inbound Provider network transit resource control does not use any inbound
interface policy but only uses an outbound interface policy, which is interface policy but only uses an outbound interface policy, which is
skipping to change at line 2176 skipping to change at line 2198
(e.g., a Media Access Control Security (MACsec) link (e.g., a Media Access Control Security (MACsec) link
[IEEE802.1AE]) or excludes links that are within a particular [IEEE802.1AE]) or excludes links that are within a particular
geography. geography.
These protocols can be controlled, e.g., by tuning the protocol list These protocols can be controlled, e.g., by tuning the protocol list
under the "underlay-transport" data node defined in the L3VPN Network under the "underlay-transport" data node defined in the L3VPN Network
Model (L3NM) [RFC9182] and the L2VPN Network Model (L2NM) [RFC9291]. Model (L3NM) [RFC9182] and the L2VPN Network Model (L2NM) [RFC9291].
Also, underlay transports may be realized using separate NRPs. Also, underlay transports may be realized using separate NRPs.
However, such an approach is left out of the scope given the current However, such an approach is left out of the scope given the current
state of the technology (2024). state of the technology at the time of writing this document.
Similar to the QoS mapping models discussed in Section 5, for mapping Similar to the QoS mapping models discussed in Section 5, for mapping
to underlay transports at the ingress PE, both the 5QI-unaware and to underlay transports at the ingress PE, both the 5QI-unaware and
5QI-aware models are defined. Essentially, entire slices can be 5QI-aware models are defined. Essentially, entire slices can be
mapped to underlay transports without 5G QoS consideration (5QI- mapped to underlay transports without 5G QoS consideration (5QI-
unaware model). For example, flows with different 5G QoS Classes, unaware model). For example, flows with different 5G QoS Classes,
even from same slice, can be mapped to different underlay transports even from same slice, can be mapped to different underlay transports
(5QI-aware model). (5QI-aware model).
Figure 27 depicts an example of a simple network with two underlay Figure 27 depicts an example of a simple network with two underlay
skipping to change at line 2342 skipping to change at line 2364
addition, details of the DC infrastructure in customer sites, such as addition, details of the DC infrastructure in customer sites, such as
switches and routers, are not shown. switches and routers, are not shown.
The 5G NSO is aware of the existence of the network functions and The 5G NSO is aware of the existence of the network functions and
their locations. However, it is not aware of the details of the their locations. However, it is not aware of the details of the
provider network. The NSC has the opposite view -- it is aware of provider network. The NSC has the opposite view -- it is aware of
the provider network infrastructure and the links between the PEs and the provider network infrastructure and the links between the PEs and
the DCs, but it is not aware of the individual network functions at the DCs, but it is not aware of the individual network functions at
customer sites. customer sites.
+-------- DC 1-------+ +-----------------+ +-------- DC 2-------+ +-------- DC 1-------+ +-----------------+ +-------- DC 2-------+
| | | | | | | | | | | |
| +------+ | +----+ +----+ | +------+ | | +------+ | +-----+ +-----+ | +------+ |
| | NF1A | +--*PE1A| |PE2A*--+ | NF2A | | | | NF1A | +--* PE1A| |PE2A *--+ | NF2A | |
| +------+ | +----+ +----+ | +------+ | | +------+ | +-----+ +-----+ | +------+ |
| +------+ | | | | +------+ | | +------+ | | | | +------+ |
| | NF1B | | | | | | NF2B | | | | NF1B | | | | | | NF2B | |
| +------+ | | | | +------+ | | +------+ | | | | +------+ |
| +------+ | +----+ +----+ | +------+ | | +------+ | +-----+ +-----+ | +------+ |
| | NF1C | +--*PE1B| |PE2B*--+ | NF2C | | | | NF1C | +--* PE1B| |PE2B *--+ | NF2C | |
| +------+ | +----+ +----+ | +------+ | | +------+ | +-----+ +-----+ | +------+ |
+--------------------+ | Provider | +--------------------+ +--------------------+ | | +--------------------+
| | | Provider |
| Network | +--------DC 3--------+ | Network | +--------DC 3--------+
| +----+ | +------+ | | +-----+ | +------+ |
| |PE3A*--+ | NF3A | | | |PE3A *--+ | NF3A | |
| +----+ | +------+ | | +-----+ | +------+ |
| | | +------+ | | | | +------+ |
| | | | NF3B | | | | | | NF3B | |
| | | +------+ | | | | +------+ |
| +----+ | +------+ | | +-----+ | +------+ |
| |PE3B*--+ | NF3C | | | |PE3B *--+ | NF3C | |
| +----+ | +------+ | | +-----+ | +------+ |
| | | | | | | |
+-----------------+ +--------------------+ +-----------------+ +--------------------+
* SDP, with fine-grained QoS (dedicated resources per RFC 9543 NS) * SDP, with fine-grained QoS (dedicated resources per RFC 9543 Network
Slices)
Figure 30: Example of Multi-DC Architecture Figure 30: Example of Multi-DC Architecture
Let us consider 5G slice "X" that uses some of the network functions Let us consider 5G Network Slice "X" that uses some of the network
in the three DCs. If this slice has latency requirements, the 5G NSO functions in the three DCs. If this slice has latency requirements,
will have taken those into account when deciding which NF instances the 5G NSO will have taken those into account when deciding which NF
in which DC are to be invoked for this slice. As a result of such a instances in which DC are to be invoked for this slice. As a result
placement decision, the three DCs shown are involved in 5G slice "X", of such a placement decision, the three DCs shown are involved in 5G
rather than other DCs. For its decision-making, the 5G NSO needs Network Slice "X", rather than other DCs. For its decision-making,
information from the NSC about the observed latency between DCs. the 5G NSO needs information from the NSC about the observed latency
Preferably, the NSC would present the topology in an abstracted form, between DCs. Preferably, the NSC would present the topology in an
consisting of point-to-point abstracted links between pairs of DCs abstracted form, consisting of point-to-point abstracted links
and associated latency and, optionally, delay variation and link-loss between pairs of DCs and associated latency and, optionally, delay
values. It would be valuable to have a mechanism for the 5G NSO to variation and link-loss values. It would be valuable to have a
inform the NSC which DC-pairs are of interest for these metrics; mechanism for the 5G NSO to inform the NSC which DC-pairs are of
there may be thousands of DCs, but the 5G NSO will only be interested interest for these metrics; there may be thousands of DCs, but the 5G
in these metrics for a small fraction of all the possible DC-pairs, NSO will only be interested in these metrics for a small fraction of
i.e., those in the same region of the provider network. The all the possible DC-pairs, i.e., those in the same region of the
mechanism for conveying the information is out of scope for this provider network. The mechanism for conveying the information is out
document. of scope for this document.
Table 1 shows the matrix of bandwidth demands for 5G slice "X". Table 1 shows the matrix of bandwidth demands for 5G Network Slice
Within the slice, multiple NF instances might be sending traffic from "X". Within the slice, multiple NF instances might be sending
DCi to DCj. However, the 5G NSO sums the associated demands into one traffic from DCi to DCj. However, the 5G NSO sums the associated
value. For example, "NF1A" and "NF1B" in "DC1" might be sending demands into one value. For example, "NF1A" and "NF1B" in "DC 1"
traffic to multiple NFs in "DC2", but this is expressed as one value might be sending traffic to multiple NFs in "DC 2", but this is
in the traffic matrix: the total bandwidth required for 5G slice "X" expressed as one value in the traffic matrix: the total bandwidth
from "DC1" to "DC2" (8 units). Each row in the right-most column in required for 5G Network Slice "X" from "DC 1" to "DC 2" (8 units).
the traffic matrix shows the total amount of traffic going from a Each row in the right-most column in the traffic matrix shows the
given DC into the transport network, regardless of the destination total amount of traffic going from a given DC into the Transport
DC. Note that this number can be less than the sum of DC-to-DC Network, regardless of the destination DC. Note that this number can
demands in the same row, on the basis that not all the NFs are likely be less than the sum of DC-to-DC demands in the same row, on the
to be sending at their maximum rate simultaneously. For example, the basis that not all the NFs are likely to be sending at their maximum
total traffic from "DC1" for slice "X" is 11 units, which is less rate simultaneously. For example, the total traffic from "DC 1" for
than the sum of the DC-to-DC demands in the same row (13 units). slice "X" is 11 units, which is less than the sum of the DC-to-DC
Note, as described in Section 5, a slice may have per-QoS class demands in the same row (13 units). Note, as described in Section 5,
bandwidth requirements and may have CIR and PIR limits. This is not a slice may have per-QoS class bandwidth requirements and may have
included in the example, but the same principles apply in such cases. CIR and PIR limits. This is not included in the example, but the
same principles apply in such cases.
+=========+======+======+======+===============+ +=========+======+======+======+===============+
| From/To | DC 1 | DC 2 | DC 3 | Total from DC | | From/To | DC 1 | DC 2 | DC 3 | Total from DC |
+=========+======+======+======+===============+ +=========+======+======+======+===============+
| DC 1 | n/a | 8 | 5 | 11.0 | | DC 1 | n/a | 8 | 5 | 11.0 |
+---------+------+------+------+---------------+ +---------+------+------+------+---------------+
| DC 2 | 1 | n/a | 2 | 2.5 | | DC 2 | 1 | n/a | 2 | 2.5 |
+---------+------+------+------+---------------+ +---------+------+------+------+---------------+
| DC 3 | 4 | 7 | n/a | 10.0 | | DC 3 | 4 | 7 | n/a | 10.0 |
+---------+------+------+------+---------------+ +---------+------+------+------+---------------+
Table 1: Inter-DC Traffic Demand Matrix Table 1: Inter-DC Traffic Demand Matrix
(Slice X) (Slice X)
The YANG data model defined in [NSSM] can be used to convey all of The YANG data model defined in [NSSM] can be used to convey all of
the information in the traffic matrix to an NSC. The NSC applies the information in the traffic matrix to an NSC. The NSC applies
policers corresponding to the last column in the traffic matrix to policers corresponding to the last column in the traffic matrix to
the appropriate PE routers, in order to enforce the bandwidth the appropriate PE routers, in order to enforce the bandwidth
contract. For example, it applies a policer of 11 units to PE1A and contract. For example, it applies a policer of 11 units to PE1A and
PE1B that face DC1, as this is the total bandwidth that DC1 sends PE1B that face DC 1, as this is the total bandwidth that DC 1 sends
into the provider network corresponding to slice "X". Also, the into the provider network corresponding to slice "X". Also, the
controller may apply shapers in the direction from the TN to the DC controller may apply shapers in the direction from the TN to the DC
if there is the possibility of a link in the DC being oversubscribed. if there is the possibility of a link in the DC being oversubscribed.
Note that a peer NF endpoint of an AC can be identified using "peer- Note that a peer NF endpoint of an AC can be identified using "peer-
sap-id" as defined in [RFC9408]. sap-id" as defined in [RFC9408].
Depending on the bandwidth model used in the provider network Depending on the bandwidth model used in the provider network
(Section 7.2), the other values in the matrix, i.e., the DC-to-DC (Section 7.2), the other values in the matrix, i.e., the DC-to-DC
demands, may not be directly applied to the provider network. Even demands, may not be directly applied to the provider network. Even
so, the information may be useful to the NSC for capacity planning so, the information may be useful to the NSC for capacity planning
skipping to change at line 2487 skipping to change at line 2511
capacity planning, based on traffic growth trends and anticipated capacity planning, based on traffic growth trends and anticipated
future demands, in order to ensure that network links are not over- future demands, in order to ensure that network links are not over-
subscribed. This scheme is analogous to that used in many existing subscribed. This scheme is analogous to that used in many existing
business VPN deployments, in that bandwidth guarantees are provided business VPN deployments, in that bandwidth guarantees are provided
to the customers but are not explicitly underpinned end to end across to the customers but are not explicitly underpinned end to end across
the provider network. the provider network.
A variation on the scheme is that Flex-Algorithm [RFC9350] is used. A variation on the scheme is that Flex-Algorithm [RFC9350] is used.
For example, one Flex-Algorithm could use latency-based metrics, and For example, one Flex-Algorithm could use latency-based metrics, and
another Flex-Algorithm could use the IGP metric. There would be a another Flex-Algorithm could use the IGP metric. There would be a
many-to-one mapping of Network Slices to Flex-Algorithms. many-to-one mapping of network slices to Flex-Algorithms.
While Scheme 1 is technically feasible, it is vulnerable to While Scheme 1 is technically feasible, it is vulnerable to
unexpected changes in traffic patterns and/or network element unexpected changes in traffic patterns and/or network element
failures resulting in congestion. This is because, unlike Schemes 2 failures resulting in congestion. This is because, unlike Schemes 2
and 3, which employ TE, traffic cannot be diverted from the shortest and 3, which employ TE, traffic cannot be diverted from the shortest
path. path.
7.2.2. Scheme 2: TE Paths with Fixed Bandwidth Reservations 7.2.2. Scheme 2: TE Paths with Fixed Bandwidth Reservations
Scheme 2 uses RSVP-TE [RFC3209] or SR-TE [RFC9256] paths with fixed Scheme 2 uses RSVP-TE [RFC3209] or SR-TE [RFC9256] paths with fixed
bandwidth reservations. By "fixed", we mean a value that stays bandwidth reservations. By "fixed", we mean a value that stays
constant over time, unless the 5G NSO communicates a change in slice constant over time, unless the 5G NSO communicates a change in slice
bandwidth requirements, due to the creation or modification of a bandwidth requirements, due to the creation or modification of a
slice. Note that the "reservations" may be maintained by the slice. Note that the "reservations" may be maintained by the
transport controller; it is not necessary (or indeed possible for transport controller; it is not necessary (or indeed possible for
current SR-TE technology in 2024) to reserve bandwidth at the network current SR-TE technology at the time of writing this document) to
layer. The bandwidth requirement acts as a constraint whenever the reserve bandwidth at the network layer. The bandwidth requirement
controller (re)computes a path. There could be a single mesh of acts as a constraint whenever the controller (re)computes a path.
paths between endpoints that carry all of the traffic types, or there There could be a single mesh of paths between endpoints that carry
could be a small handful of meshes, for example, one mesh for low- all of the traffic types, or there could be a small handful of
latency traffic that follows the minimum latency path and another meshes, for example, one mesh for low-latency traffic that follows
mesh for the other traffic that follows the minimum IGP metric path, the minimum latency path and another mesh for the other traffic that
as described in Section 5. There would be a many-to-one mapping of follows the minimum IGP metric path, as described in Section 5.
slices to paths. There would be a many-to-one mapping of slices to paths.
The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj
demands of the individual slices. For example, if only slices "X" demands of the individual slices. For example, if only slices "X"
and "Y" are present, then the bandwidth requirement from "DC1" to and "Y" are present, then the bandwidth requirement from "DC 1" to
"DC2" is 12 units (8 units for slice "X" (Table 1) and 4 units for "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, slice "Y" (Table 2)). When the 5G NSO requests a new slice, the NSC,
increments the bandwidth requirement according to the requirements of increments the bandwidth requirement according to the requirements of
the new slice. For example, in Figure 30, suppose a new slice is the new slice. For example, in Figure 30, suppose a new slice is
instantiated that needs 0.8 Gbps from "DC1" to "DC2". The transport instantiated that needs 0.8 Gbps from "DC 1" to "DC 2". The
controller would increase its notion of the bandwidth requirement transport controller would increase its notion of the bandwidth
from "DC1" to "DC2" from 12 Gbps to 12.8 Gbps to accommodate the requirement from "DC 1" to "DC 2" from 12 Gbps to 12.8 Gbps to
additional expected traffic. accommodate the additional expected traffic.
+=========+======+======+======+===============+ +=========+======+======+======+===============+
| From/To | DC 1 | DC 2 | DC 3 | Total from DC | | From/To | DC 1 | DC 2 | DC 3 | Total from DC |
+=========+======+======+======+===============+ +=========+======+======+======+===============+
| DC 1 | n/a | 4 | 2.5 | 6.0 | | DC 1 | n/a | 4 | 2.5 | 6.0 |
+---------+------+------+------+---------------+ +---------+------+------+------+---------------+
| DC 2 | 0.5 | n/a | 0.8 | 1.0 | | DC 2 | 0.5 | n/a | 0.8 | 1.0 |
+---------+------+------+------+---------------+ +---------+------+------+------+---------------+
| DC 3 | 2.6 | 3 | n/a | 5.1 | | DC 3 | 2.6 | 3 | n/a | 5.1 |
+---------+------+------+------+---------------+ +---------+------+------+------+---------------+
Table 2: Inter-DC Traffic Demand Matrix Table 2: Inter-DC Traffic Demand Matrix
(Slice Y) (Slice Y)
In the example, each DC has two PEs facing it for reasons of In the example, each DC has two PEs facing it for reasons of
resilience. The NSC needs to determine how to map the "DC1" to "DC2" resilience. The NSC needs to determine how to map the "DC 1" to "DC
bandwidth requirement to bandwidth reservations of TE LSPs from "DC1" 2" bandwidth requirement to bandwidth reservations of TE LSPs from
to "DC2". For example, if the routing configuration is arranged such "DC 1" to "DC 2". For example, if the routing configuration is
that in the absence of any network failure, traffic from "DC1" to arranged such that in the absence of any network failure, traffic
"DC2" always enters "PE1A" and goes to "PE2A", the controller from "DC 1" to "DC 2" always enters "PE1A" and goes to "PE2A", the
reserves 12.8 Gbps of bandwidth on the path from "PE1A" to "PE2A". controller reserves 12.8 Gbps of bandwidth on the path from "PE1A" to
On the other hand, if the routing configuration is arranged such that "PE2A". On the other hand, if the routing configuration is arranged
in the absence of any network failure, traffic from "DC1" to "DC2" such that in the absence of any network failure, traffic from "DC 1"
always enters "PE1A" and is load-balanced across "PE2A" and "PE2B", to "DC 2" always enters "PE1A" and is load-balanced across "PE2A" and
the controller reserves 6.4 Gbps of bandwidth on the path from "PE1A" "PE2B", the controller reserves 6.4 Gbps of bandwidth on the path
to "PE2A" and 6.4 Gbps of bandwidth on the path from "PE1A" to from "PE1A" to "PE2A" and 6.4 Gbps of bandwidth on the path from
"PE2B". It might be tricky for the NSC to be aware of all conditions "PE1A" to "PE2B". It might be tricky for the NSC to be aware of all
that change the way traffic lands on the various PEs and therefore conditions that change the way traffic lands on the various PEs and
know that it needs to change bandwidth reservations of paths therefore know that it needs to change bandwidth reservations of
accordingly. For example, there might be an internal failure within paths accordingly. For example, there might be an internal failure
"DC1" that causes traffic from "DC1" to land on "PE1B" rather than within "DC 1" that causes traffic from "DC 1" to land on "PE1B"
"PE1A". The NSC may not be aware of the failure and therefore may rather than "PE1A". The NSC may not be aware of the failure and
not know that it now needs to apply bandwidth reservations to paths therefore may not know that it now needs to apply bandwidth
from "PE1B" to "PE2A" and "PE2B". reservations to paths from "PE1B" to "PE2A" and "PE2B".
7.2.3. Scheme 3: TE Paths without Bandwidth Reservation 7.2.3. Scheme 3: TE Paths without Bandwidth Reservation
Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths. There could be Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths. There could be
a single mesh of paths between endpoints that carry all of the a single mesh of paths between endpoints that carry all of the
traffic types, or there could be a small handful of meshes, for traffic types, or there could be a small handful of meshes, for
example, one mesh for low-latency traffic that follows the minimum example, one mesh for low-latency traffic that follows the minimum
latency path and another mesh for the other traffic that follows the latency path and another mesh for the other traffic that follows the
minimum IGP metric path, as described in Section 5. There would be a minimum IGP metric path, as described in Section 5. There would be a
many-to-one mapping of slices to paths. many-to-one mapping of slices to paths.
The difference between Scheme 2 and Scheme 3 is that Scheme 3 does The difference between Scheme 2 and Scheme 3 is that Scheme 3 does
not have fixed bandwidth reservations for the paths. Instead, actual not have fixed bandwidth reservations for the paths. Instead, actual
measured data plane traffic volumes are used to influence the measured data plane traffic volumes are used to influence the
placement of TE paths. One way of achieving this is to use placement of TE paths. One way of achieving this is to use
distributed RSVP-TE with auto-bandwidth. Alternatively, the NSC can distributed RSVP-TE with auto-bandwidth. Alternatively, the NSC can
use telemetry-driven automatic congestion avoidance. In this use telemetry-driven automatic congestion avoidance. In this
approach, when the actual traffic volume in the data plane on a given approach, when the actual traffic volume in the data plane on a given
link exceeds a threshold, the controller, knowing how much actual link exceeds a threshold, the controller, knowing how much actual
data plane traffic is currently traveling along each RSVP or SR-TE data plane traffic is currently traveling along each RSVP or SR-TE
path, can tune the paths of one or more paths using the link such path, can tune one or more paths using the link such that they avoid
that they avoid that link. This approach is similar to that that link. This approach is similar to that described in
described in Section 4.3.1 of [RFC9522]. Section 4.3.1 of [RFC9522].
It would be undesirable to move a path that has latency as its cost It would be undesirable to move a path that has latency as its cost
function, rather than another type of path, in order to ease the function, rather than another type of path, in order to ease the
congestion, as the altered path will typically have a higher latency. congestion, as the altered path will typically have a higher latency.
This can be avoided by designing the algorithms described in the This can be avoided by designing the algorithms described in the
previous paragraph such that they avoid moving minimum-latency paths previous paragraph such that they avoid moving minimum-latency paths
unless there is no alternative. unless there is no alternative.
8. Network Slicing OAM 8. Network Slicing OAM
The deployment and maintenance of slices within a network imply that The deployment and maintenance of slices within a network imply that
a set of OAM functions [RFC6291] need to be deployed by the a set of OAM functions [RFC6291] need to be deployed by the
providers, for example: providers, for example:
* Providers should be able to execute OAM tasks on a per Network * Providers should be able to execute OAM tasks on a per-network-
Slice basis. These tasks can cover the "full" slice within a slice basis. These tasks can cover the "full" slice within a
domain or a portion of that slice (for troubleshooting purposes, domain or a portion of that slice (for troubleshooting purposes,
for example). for example).
For example, per-slice OAM tasks can consist of (but not limited For example, per-slice OAM tasks can consist of (but not limited
to): to):
- tracing resources that are bound to a given Network Slice, - tracing resources that are bound to a given network slice,
- tracing resources that are invoked when forwarding a given flow - tracing resources that are invoked when forwarding a given flow
bound to a given Network Slice, bound to a given network slice,
- assessing whether flow isolation characteristics are in - assessing whether flow isolation characteristics are in
conformance with the Network Slice Service requirements, or conformance with the Network Slice Service requirements, or
- assessing the compliance of the allocated Network Slice - assessing the compliance of the allocated network slice
resources against flow and customer service requirements. resources against flow and customer service requirements.
[RFC7276] provides an overview of available OAM tools. These [RFC7276] provides an overview of available OAM tools. These
technology-specific tools can be reused in the context of network technology-specific tools can be reused in the context of network
slicing. Providers that deploy network slicing capabilities slicing. Providers that deploy network slicing capabilities
should be able to select whatever OAM technology or specific should be able to select whatever OAM technology or specific
feature that would address their needs. feature that would address their needs.
* Providers may want to enable differentiated failure detection and * Providers may want to enable differentiated failure detection and
repair features for a subset of network slices. For example, a repair features for a subset of network slices. For example, a
given Network Slice may require fast detection and repair given network slice may require fast detection and repair
mechanisms, while others may not be engineered with such means. mechanisms, while others may not be engineered with such means.
The provider can use techniques such as those described in The provider can use techniques such as those described in
[RFC5286], [RFC5714], and [RFC8355]. [RFC5286], [RFC5714], and [RFC8355].
* Providers may deploy means to dynamically discover the set of * Providers may deploy means to dynamically discover the set of
Network Slices that are enabled within its network. Such dynamic network slices that are enabled within its network. Such dynamic
discovery capability facilitates the detection of any mismatch discovery capability facilitates the detection of any mismatch
between the view maintained by the control/management plane and between the view maintained by the control/management plane and
the actual network configuration. When mismatches are detected, the actual network configuration. When mismatches are detected,
corrective actions should be undertaken accordingly. For example, corrective actions should be undertaken accordingly. For example,
a provider may rely upon the L3NM [RFC9182] or the L2NM [RFC9291] a provider may rely upon the L3NM [RFC9182] or the L2NM [RFC9291]
to maintain the full set of L3VPN/L2VPNs that are used to deliver to maintain the full set of L2VPN/L3VPNs that are used to deliver
Network Slice Services. The correlation between an LxVPN instance Network Slice Services. The correlation between an L2VPN/L3VPN
and a Network Slice Service is maintained using the "parent- instance and a Network Slice Service is maintained using the
service-id" attribute (Section 7.3 of [RFC9182]). "parent-service-id" attribute (Section 7.3 of [RFC9182]).
* The means to report a set of network performance metrics to assess * Providers should provide the means to report a set of network
whether the agreed slice service objectives are honored. These performance metrics to assess whether the agreed Slice Service
means are used for SLO monitoring and violation detection objectives are honored. These means are used for SLO monitoring
purposes. For example, the YANG data model in [RFC9375] can be and violation detection purposes. For example, the YANG data
used to report the one-way delay and one-way delay variation of model in [RFC9375] can be used to report the one-way delay and
links. Both conventional active/passive measurement methods one-way delay variation of links. Both conventional active/
[RFC7799] and more recent telemetry methods (e.g., YANG Push passive measurement methods [RFC7799] and more recent telemetry
[RFC8641]) can be used. methods (e.g., YANG Push [RFC8641]) can be used.
* The means to report and expose observed performance metrics and * Providers should have the means to report and expose observed
other OAM state to customer. For example, the YANG data model performance metrics and other OAM state to customer. For example,
defined in [NSSM] exposes a set of statistics per SDP, the YANG data model defined in [NSSM] exposes a set of statistics
connectivity construct, and connection group. per SDP, connectivity construct, and connection group.
9. Scalability Implications 9. Scalability Implications
The mapping of 5G slices to TN slices (see Section 3.5) is a design The mapping of 5G Network Slices to Transport Network Slices (see
choice of service operators that may be a function of, e.g., the Section 3.5) is a design choice of service operators that may be a
number of instantiated slices, requested services, or local function of, e.g., the number of instantiated slices, requested
engineering capabilities and guidelines. However, operators should services, or local engineering capabilities and guidelines. However,
carefully consider means to ease slice migration strategies. For operators should carefully consider means to ease slice migration
example, a provider may initially adopt a 1-to-1 mapping if it has to strategies. For example, a provider may initially adopt a 1-to-1
instantiate just a few Network Slices and accommodate the need of mapping if it has to instantiate just a few network slices and
only a few customers. That provider may decide to move to an N-to-1 accommodate the need of only a few customers. That provider may
mapping for aggregation/scalability purposes if sustained increased decide to move to an M-to-1 mapping for aggregation/scalability
slice demand is observed. purposes if sustained increased slice demand is observed.
Putting in place adequate automation means to realize Network Slices Putting in place adequate automation means to realize network slices
(including the adjustment of the mapping of Slice Services to Network (including the adjustment of the mapping of Slice Services to network
Slices) would ease slice migration operations. slices) would ease slice migration operations.
The realization model described in this document inherits the The realization model described in this document inherits the
scalability properties of the underlying L2VPN and L3VPN technologies scalability properties of the underlying L2VPN and L3VPN technologies
(Section 3.7). Readers may refer, for example, to Section 13 of (Section 3.7). Readers may refer, for example, to Section 13 of
[RFC4365] or Section 1.2.5 of [RFC6624] for a scalability assessment [RFC4365] or Section 1.2.5 of [RFC6624] for a scalability assessment
of some of these technologies. Providers may adjust the mapping of some of these technologies. Providers may adjust the mapping
model to better handle local scalability constraints. model to better handle local scalability constraints.
10. IANA Considerations 10. IANA Considerations
skipping to change at line 2724 skipping to change at line 2748
the provider network to control access to specific slice the provider network to control access to specific slice
resources. This prevents the possibility of one slice consuming resources. This prevents the possibility of one slice consuming
resources at the expense of other slices. Likewise, access to resources at the expense of other slices. Likewise, access to
classification and mapping tables have to be controlled to prevent classification and mapping tables have to be controlled to prevent
misbehaviors (an unauthorized entity may modify the table to bind misbehaviors (an unauthorized entity may modify the table to bind
traffic to a random slice, redirect the traffic, etc.). Network traffic to a random slice, redirect the traffic, etc.). Network
devices have to check that a required access privilege is provided devices have to check that a required access privilege is provided
before granting access to specific data or performing specific before granting access to specific data or performing specific
actions. actions.
Data Confidentiality and Integrity of an IETF Network Slice: Data Confidentiality and Integrity of an RFC 9543 Network Slice:
As described in Section 5.1.2.1 of [RFC9543], the customer might As described in Section 5.1.2.1 of [RFC9543], the customer might
request a Service Level Expectation (SLE) that mandates request a Service Level Expectation (SLE) that mandates
encryption. encryption.
This can be achieved, e.g., by mapping the traffic to an underlay This can be achieved, e.g., by mapping the traffic to an underlay
transport (Section 6) that uses only MACsec-encrypted links. transport (Section 6) that uses only MACsec-encrypted links.
In order to avoid the need for a mapping table to associate source/ In order to avoid the need for a mapping table to associate source/
destination IP addresses and the specific S-NSSAIs of slices, destination IP addresses and the specific S-NSSAIs of slices,
Section 4.2 describes an approach where some or all S-NSSAI bits are Section 4.2 describes an approach where some or all S-NSSAI bits are
embedded in an IPv6 address using an algorithm approach. An attacker embedded in an IPv6 address using an algorithm approach. An attacker
from within the transport network who has access to the mapping from within the Transport Network who has access to the mapping
configuration may infer the slices to which a packet belongs. It may configuration may infer the slices to which a packet belongs. It may
also alter these bits, which may lead to steering the packet via a also alter these bits, which may lead to steering the packet via a
distinct network slice and thus to service disruption. Note that distinct network slice and thus to service disruption. Note that
such an attacker from within the transport network may inflict more such an attacker from within the Transport Network may inflict more
damage (e.g., randomly drop packets). damage (e.g., randomly drop packets).
Security considerations specific to each of the technologies and Security considerations specific to each of the technologies and
protocols listed in the document are discussed in the specification protocols listed in the document are discussed in the specification
documents of each of these protocols. In particular, readers should documents of each of these protocols. In particular, readers should
refer to the "Security Framework for Provider-Provisioned Virtual refer to the "Security Framework for Provider-Provisioned Virtual
Private Networks (PPVPNs)" [RFC4111], the "Applicability Statement Private Networks (PPVPNs)" [RFC4111], the "Applicability Statement
for BGP/MPLS IP Virtual Private Networks (VPNs)" (Section 6 of for BGP/MPLS IP Virtual Private Networks (VPNs)" (Section 6 of
[RFC4365]), and the "Analysis of the Security of BGP/MPLS IP Virtual [RFC4365]), and the "Analysis of the Security of BGP/MPLS IP Virtual
Private Networks (VPNs)" [RFC4381] for a comprehensive discussion Private Networks (VPNs)" [RFC4381] for a comprehensive discussion
skipping to change at line 2840 skipping to change at line 2864
[NSSM] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, [NSSM] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
"A YANG Data Model for the RFC 9543 Network Slice "A YANG Data Model for the RFC 9543 Network Slice
Service", Work in Progress, Internet-Draft, draft-ietf- Service", Work in Progress, Internet-Draft, draft-ietf-
teas-ietf-network-slice-nbi-yang-25, 9 May 2025, teas-ietf-network-slice-nbi-yang-25, 9 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-nbi-yang-25>. ietf-network-slice-nbi-yang-25>.
[O-RAN.WG9.XPSAAS] [O-RAN.WG9.XPSAAS]
O-RAN Alliance, "Xhaul Packet Switched Architectures and O-RAN Alliance, "Xhaul Packet Switched Architectures and
Solutions", O-RAN.WG9.XPSAAS, Version 04.00, March 2023, Solutions", O-RAN.WG9.XPSAAS, Version 09.00, October 2025,
<https://specifications.o-ran.org/specifications>. <https://specifications.o-ran.org/specifications>.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>. <https://www.rfc-editor.org/info/rfc1997>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
skipping to change at line 3114 skipping to change at line 3138
and Attachment Circuits as a Service (ACaaS)", RFC 9834, and Attachment Circuits as a Service (ACaaS)", RFC 9834,
DOI 10.17487/RFC9834, September 2025, DOI 10.17487/RFC9834, September 2025,
<https://www.rfc-editor.org/info/rfc9834>. <https://www.rfc-editor.org/info/rfc9834>.
[RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O., [RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O.,
Barguil, S., and B. Wu, "A Network YANG Data Model for Barguil, S., and B. Wu, "A Network YANG Data Model for
Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835, Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835,
September 2025, <https://www.rfc-editor.org/info/rfc9835>. September 2025, <https://www.rfc-editor.org/info/rfc9835>.
[TS-23.501] [TS-23.501]
3GPP, "System architecture for the 5G System (5GS)", 3GPP 3GPP, "System architecture for the 5G System (5GS)",
TS 23.501, Version 19.5.0, Release 19, 3GPP TS 23.501, September
<https://portal.3gpp.org/desktopmodules/Specifications/ 2025, <https://www.3gpp.org/ftp/Specs/
SpecificationDetails.aspx?specificationId=3144>. archive/23_series/23.501/23501-j50.zip>.
[TS-28.530] [TS-28.530]
3GPP, "Management and orchestration; Concepts, use cases 3GPP, "Management and orchestration; Concepts, use cases
and requirements", 3GPP TS 28.530, and requirements", Version 19.0.0, Release 19, 3GPP
<https://portal.3gpp.org/desktopmodules/Specifications/ TS 28.530, March 2025, <https://www.3gpp.org/ftp/Specs/
SpecificationDetails.aspx?specificationId=3273>. archive/28_series/28.530/28530-j00.zip>.
Appendix A. Example of Local IPv6 Addressing Plan for Network Functions Appendix A. Example of Local IPv6 Addressing Plan for Network Functions
Different IPv6 address allocation schemes following the above Different IPv6 address allocation schemes following the approach in
approach may be used, with one example allocation shown in Figure 31. Section 4.2 may be used, with one example allocation shown in
Figure 31.
NF-specific Reserved NF-specific Reserved
(not slice specific) for S-NSSAI (not slice specific) for S-NSSAI
<----------------------------><---------> <----------------------------><--------->
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
|xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd| |xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd|
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
<------------------128 bits-------------> <------------------128 bits------------->
tt - SST (8 bits) tt - SST (8 bits)
skipping to change at line 3157 skipping to change at line 3182
structured by the provider, for example, on the geographical location structured by the provider, for example, on the geographical location
or the DC identification. Refer to Section 2.1 of [RFC9099] for a or the DC identification. Refer to Section 2.1 of [RFC9099] for a
discussion on the benefits of structuring an address plan around both discussion on the benefits of structuring an address plan around both
services and geographic locations for more structured security services and geographic locations for more structured security
policies in a network. policies in a network.
Figure 32 uses the example from Figure 31 to demonstrate a slicing Figure 32 uses the example from Figure 31 to demonstrate a slicing
deployment, where the entire S-NSSAI is embedded into IPv6 addresses deployment, where the entire S-NSSAI is embedded into IPv6 addresses
used by NFs. Let us consider that "NF-A" has a set of tunnel used by NFs. Let us consider that "NF-A" has a set of tunnel
termination points with unique per-slice IP addresses allocated from termination points with unique per-slice IP addresses allocated from
2001:db8:a:0::/96, while "NF-B" uses a set of tunnel termination 2001:db8:a::/96, while "NF-B" uses a set of tunnel termination points
points with per-slice IP addresses allocated from 2001:db8:b:0::/96. with per-slice IP addresses allocated from 2001:db8:b::/96. This
This example shows two slices: "customer A eMBB" (SST-01, SD-00001) example shows two slices: "customer A eMBB" (SST=1, SD=00001) and
and "customer B MIoT" (SST-03, SD-00003). For "customer A eMBB" "customer B MIoT" (SST=3, SD=00003). For "customer A eMBB" slice,
slice, the tunnel IP addresses are auto-derived as the IP addresses the tunnel IP addresses are auto-derived as the IP addresses
{2001:db8:a::100:1, 2001:db8:b::100:1}, where {:0100:0001} is used as {2001:db8:a::100:1, 2001:db8:b::100:1}, where {:0100:0001} is used as
the last two octets. "customer B MIoT" slice (SST-3, SD-00003) tunnel the last two octets. "customer B MIoT" slice (SST=3, SD=00003) tunnel
uses the IP addresses {2001:db8:a::300:3, 2001:db8:b::300:3} and uses the IP addresses {2001:db8:a::300:3, 2001:db8:b::300:3} and
simply adds {:0300:0003} as the last two octets. Leading zeros are simply adds {:0300:0003} as the last two octets. Leading zeros are
not represented in the resulting IPv6 addresses as per [RFC5952]. not represented in the resulting IPv6 addresses as per [RFC5952].
2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B) 2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B)
2001:db8:a::100:1/128 2001:db8:b::100:1/128 2001:db8:a::100:1/128 2001:db8:b::100:1/128
| | | |
| + - - - - - - - - + eMBB (SST=1) | | + - - - - - - - - + eMBB (SST=1) |
| | | | | | | | | |
+----v-+ +--+--+ Provider +---+-+ | +-----+ +-v----+ +----v-+ +--+--+ Provider +---+-+ | +-----+ +-v----+
| | | | | | v | | | | | | | | | | v | | | |
| o============*================*==========================o | | o============*================*==========================o |
| NF +-------+ PE | | PE +-------+L2/L3+.......+ NF | | NF +-------+ PE | | PE +-------+L2/L3+.......+ NF |
| o============*================*==========================o | | o============*================*==========================o |
| | | | | | v | | | | | | | | | | ^ | | | |
+----^-+ +--+--+ Network +---+-+ ^ +-----+ +-^----+ +----^-+ +--+--+ Network +---+-+ | +-----+ +-^----+
| | | | | | | | | |
| + - - - - - - - - + MIoT (SST=3) | | + - - - - - - - - + MIoT (SST=3) |
| | | |
2001:db8:a::300:3/128 2001:db8:b::300:3/128 2001:db8:a::300:3/128 2001:db8:b::300:3/128
o Tunnel (IPsec, GTP-U, etc.) termination point o Tunnel (IPsec, GTP-U, etc.) termination point
* SDP * SDP
Figure 32: Deployment Example with S-NSSAI Embedded into IPv6 Figure 32: Deployment Example with S-NSSAI Embedded into IPv6
Addresses Addresses
skipping to change at line 3258 skipping to change at line 3283
Mojdeh Amani Mojdeh Amani
British Telecom British Telecom
London London
United Kingdom United Kingdom
Email: mojdeh.amani@bt.com Email: mojdeh.amani@bt.com
Authors' Addresses Authors' Addresses
Krzysztof G. Szarkowicz (editor) Krzysztof G. Szarkowicz (editor)
Juniper Networks HPE
Wien Wien
Austria Austria
Email: kszarkowicz@juniper.net Email: kszarkowicz@juniper.net
Richard Roberts (editor) Richard Roberts (editor)
Juniper Networks Nokia
Rennes Rennes
France France
Email: rroberts@juniper.net Email: richard.roberts@nokia.com
Julian Lucek Julian Lucek
Juniper Networks Juniper Networks
London London
United Kingdom United Kingdom
Email: jlucek@juniper.net Email: jlucek@juniper.net
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
France France
 End of changes. 137 change blocks. 
432 lines changed or deleted 457 lines changed or added

This html diff was produced by rfcdiff 1.48.