Internet Engineering Task Force (IETF) K. Szarkowicz, Ed.
Request for Comments: 9889 HPE
Category: Informational R. Roberts, Ed.
ISSN: 2070-1721 Nokia
J. Lucek
HPE
M. Boucadair, Ed.
Orange
LM. Contreras
Telefonica
November 2025
Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN).
ネットワーク スライシングは、モバイル ネットワークの 3rd Generation Partnership Project (3GPP) によって導入された機能です。5G スライシングの実現には、無線アクセス ネットワーク (RAN)、コア ネットワーク (CN)、トランスポート ネットワーク (TN) を含むすべてのモバイル ドメインの要件が含まれます。
This document describes a network slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling the service objectives for 5G slicing connectivity. The realization model reuses many building blocks commonly used in service provider networks at the current time.
このドキュメントでは、5G スライシング接続のサービス目標を満たすトランスポート ネットワークに焦点を当てた、IP/MPLS ネットワークのネットワーク スライス実現モデルについて説明します。実現モデルは、現在サービス プロバイダー ネットワークで一般的に使用されている多くの構成要素を再利用します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9889.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9889 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
2.1. Definitions
2.2. Abbreviations
3. 5G Network Slicing Integration in Transport Networks
3.1. Scope of the Transport Network
3.2. 5G Network Slicing Versus Transport Network Slicing
3.3. Transport Network Reference Design
3.4. Orchestration Overview
3.5. Mapping 5G Network Slices to Transport Network Slices
3.6. First 5G Network Slice Versus Subsequent Slices
3.7. Overview of the Transport Network Realization Model
4. Handoff Between Domains
4.1. VLAN Handoff
4.2. IP Handoff
4.3. MPLS Label Handoff
5. QoS Mapping Realization Models
5.1. QoS Layers
5.2. QoS Realization Models
5.3. Transit Resource Control
6. PE Underlay Transport Mapping Models
6.1. 5QI-Unaware Model
6.2. 5QI-Aware Model
7. Capacity Planning/Management
7.1. Bandwidth Requirements
7.2. Bandwidth Models
8. Network Slicing OAM
9. Scalability Implications
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Example of Local IPv6 Addressing Plan for Network
Functions
Acknowledgments
Contributors
Authors' Addresses
This document focuses on network slicing for 5G networks, covering the connectivity between Network Functions (NFs) across multiple domains such as edge clouds, data centers, and the Wide Area Network (WAN). The document describes a network slice realization approach that fulfills 5G slicing requirements by using existing IP/MPLS technologies (at the time of publication of this document) to optimally control connectivity Service Level Agreements (SLAs) offered for 5G Network Slices. To that aim, this document describes the scope of the Transport Network in 5G architectures (Section 3.1), disambiguates 5G Network Slicing versus Transport Network Slicing (Section 3.2), draws the perimeter of the various orchestration domains to realize slices (Section 3.4), and identifies the required coordination between these orchestration domains for adequate setup of Attachment Circuits (ACs) (Section 3.4.2).
このドキュメントでは、5G ネットワークのネットワーク スライシングに焦点を当て、エッジ クラウド、データ センター、ワイド エリア ネットワーク (WAN) などの複数のドメインにわたるネットワーク機能 (NF) 間の接続について説明します。このドキュメントでは、既存の IP/MPLS テクノロジー (このドキュメントの発行時点) を使用して 5G ネットワーク スライスに提供される接続サービス レベル アグリーメント (SLA) を最適に制御することにより、5G スライス要件を満たすネットワーク スライス実現アプローチについて説明します。その目的のために、この文書では、5G アーキテクチャにおけるトランスポート ネットワークの範囲を説明し (セクション 3.1)、5G ネットワーク スライシングとトランスポート ネットワーク スライシングの曖昧さを明確にし (セクション 3.2)、スライスを実現するためのさまざまなオーケストレーション ドメインの境界を描画し (セクション 3.4)、アタッチメント サーキット (AC) を適切にセットアップするために必要なこれらのオーケストレーション ドメイン間の調整を特定します (セクション 3.4)。3.4.2)。
This work is compatible with the framework defined in [RFC9543], which describes network slicing in the context of networks built from IETF technologies. Specifically, this document describes an approach to how RFC 9543 Network Slices are realized within provider networks and how such slices are stitched to Transport Network resources in a customer site in the context of Transport Network Slices (Figure 1). The realization of an RFC 9543 Network Slice (i.e., connectivity with performance commitments) involves the provider network and partially the AC (the Provider Edge (PE) side of the AC). This document assumes that the customer site infrastructure is over-provisioned and involves short distances (low latency) where basic QoS/scheduling logic is sufficient to comply with the Service Level Objectives (SLOs).
この作業は、IETF テクノロジーから構築されたネットワークのコンテキストでのネットワーク スライシングを説明する [RFC9543] で定義されたフレームワークと互換性があります。具体的には、この文書では、RFC 9543 ネットワーク スライスがプロバイダー ネットワーク内でどのように実現されるか、またそのようなスライスがトランスポート ネットワーク スライスのコンテキストで顧客サイトのトランスポート ネットワーク リソースにどのようにステッチされるかについてのアプローチについて説明します (図 1)。RFC 9543 ネットワーク スライス (つまり、パフォーマンスを約束した接続) の実現には、プロバイダー ネットワークと部分的に AC (AC のプロバイダー エッジ (PE) 側) が関係します。このドキュメントでは、顧客サイトのインフラストラクチャがオーバープロビジョニングされており、基本的な QoS/スケジューリング ロジックでサービス レベル目標 (SLO) に準拠するのに十分な短距離 (低遅延) が含まれることを前提としています。
|------------Transport Network Slice---------|
RFC 9543 Network Slice
.-----SDP Type 3----.
| .- SDP Type 4-. |
| | | |
v v v v
+------------+ +---------------+ +------------+
| Customer | | Provider | | Customer |
| Site 1 | | Network | | Site 2 |
| | +-+--+ +-+--+ | |
| +---+ +--+-+ AC | | | | AC +-+-+ |
| |NF +...+ CE +------+ PE | | PE +----+NF | |
| +---+ +--+-+ | | | | +-+-+ |
| | +-+--+ +-+--+ | |
| | | | | |
+------------+ +---------------+ +------------+
Figure 1: Transport Network Slice and RFC 9543 Network Slice Scopes
図 1: トランスポート ネットワーク スライスと RFC 9543 ネットワーク スライスの範囲
This document focuses on RFC 9543 Network Slice deployments where the Service Demarcation Points (SDPs) are located per Types 3 and 4 in Figure 1 of [RFC9543].
この文書は、[RFC9543] の図 1 のタイプ 3 および 4 に従ってサービス境界点 (SDP) が配置される RFC 9543 ネットワーク スライスの展開に焦点を当てています。
The realization approach described in this document is typically triggered by Network Slice Service requests. How a Network Slice Service request is placed for realization, including how it is derived from a 5G Slice Service request, is out of scope. Mapping considerations between 3GPP and RFC 9543 Network Slice Service (e.g., mapping of service parameters) are discussed in documents such as [NS-APP].
このドキュメントで説明されている実現アプローチは、通常、ネットワーク スライス サービス リクエストによってトリガーされます。ネットワーク スライス サービス リクエストを実現するために配置する方法 (5G スライス サービス リクエストから派生する方法を含む) は範囲外です。3GPP と RFC 9543 ネットワーク スライス サービス間のマッピングに関する考慮事項 (サービス パラメータのマッピングなど) は、[NS-APP] などの文書で説明されています。
The 5G control plane uses the Single Network Slice Selection Assistance Information (S-NSSAI) for slice identification [TS-23.501]. Because S-NSSAIs are not visible to the transport domain, 5G domains can expose the 5G Network Slices to the transport domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or Layer 4). Passing information between customer sites and provider networks is referred to as the "handoff". Section 4 lists a set of handoff methods for slice mapping purposes.
5G コントロール プレーンは、スライスの識別に単一ネットワーク スライス選択支援情報 (S-NSSAI) を使用します [TS-23.501]。S-NSSAI はトランスポート ドメインからは見えないため、5G ドメインは、明示的なデータ プレーン識別子 (レイヤ 2、レイヤ 3、またはレイヤ 4 など) にマッピングすることによって、5G ネットワーク スライスをトランスポート ドメインに公開できます。顧客サイトとプロバイダー ネットワーク間での情報の受け渡しは、「ハンドオフ」と呼ばれます。セクション 4 では、スライス マッピングを目的とした一連のハンドオフ方法をリストします。
Unlike approaches that require new protocol extensions (e.g., [NS-IP-MPLS]), the realization model described in this document uses a set of building blocks commonly used in service provider networks (at the time of publication of this document). The model uses (1) L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for logical separation, (2) fine-grained resource control at the PEs, (3) coarse-grained resource control within the provider network, and (4) capacity planning and management. More details are provided in Sections 3.7, 5, 6, and 7.
新しいプロトコル拡張 ([NS-IP-MPLS] など) を必要とするアプローチとは異なり、この文書で説明されている実現モデルは、(この文書の発行時点で) サービス プロバイダー ネットワークで一般的に使用されている一連の構成要素を使用します。このモデルは、(1) 論理的分離のための L2VPN [RFC4664] および/または L3VPN [RFC4364] サービス インスタンス、(2) PE でのきめの細かいリソース制御、(3) プロバイダー ネットワーク内のきめの細かいリソース制御、および (4) 容量計画と管理を使用します。詳細については、セクション 3.7、5、6、および 7 を参照してください。
This realization model uses a single Network Resource Partition (NRP) (Section 7.1 of [RFC9543]). The applicability to multiple NRPs is out of scope.
この実現モデルは、単一のネットワーク リソース パーティション (NRP) ([RFC9543] のセクション 7.1) を使用します。複数の NRP への適用は範囲外です。
Although this document focuses on 5G, the realizations are not fundamentally constrained by the 5G use case. The document is not intended to be a BCP and does not claim to specify mandatory mechanisms to realize network slices. Rather, a key goal of the document is to provide pragmatic implementation approaches by leveraging existing techniques that are readily available and widely deployed. The document is also intended to align the mobile and the IETF perspectives of slicing from a realization perspective.
このドキュメントは 5G に焦点を当てていますが、実現は 5G のユースケースによって基本的に制約されません。この文書は BCP を意図したものではなく、ネットワーク スライスを実現するための必須のメカニズムを指定するとは主張していません。むしろ、この文書の主な目標は、すぐに利用でき、広く導入されている既存の技術を活用して、実用的な実装アプローチを提供することです。この文書は、モバイルと IETF のスライシングの観点を実現の観点から調整することも目的としています。
For a definitive description of 3GPP network architectures, the reader should refer to [TS-23.501]. More details can be found in [Book-5G].
3GPP ネットワーク アーキテクチャの最終的な説明については、[TS-23.501] を参照してください。詳細については、[Book-5G]を参照してください。
The document uses the terms defined in [RFC9543]. Specifically, the use of "Customer" is consistent with [RFC9543] but with the following contextualization (see also Section 3.3):
この文書では、[RFC9543] で定義されている用語を使用します。具体的には、「Customer」の使用は [RFC9543] と一致していますが、次の文脈と一致しています (セクション 3.3 も参照)。
Customer:
お客様：
An entity that is responsible for managing and orchestrating the end-to-end 5G Mobile Network, notably the Radio Access Network (RAN) and Core Network (CN).
エンドツーエンドの 5G モバイル ネットワーク、特に無線アクセス ネットワーク (RAN) とコア ネットワーク (CN) の管理と調整を担当するエンティティ。
This entity is distinct from the customer of a 5G Network Slice Service.
このエンティティは、5G ネットワーク スライス サービスの顧客とは異なります。
This document makes use of the following terms:
この文書では次の用語が使用されています。
Customer site:
顧客サイト:
A customer manages and deploys 5G NFs (e.g., gNodeB (gNB) and 5G Core (5GC)) in customer sites. A customer site can be either a physical or a virtual location. A provider is responsible for interconnecting customer sites.
顧客は、顧客サイトで 5G NF (gNodeB (gNB) や 5G Core (5GC) など) を管理および展開します。顧客サイトは、物理的な場所または仮想的な場所のいずれかになります。プロバイダーは顧客サイトを相互接続する責任があります。
Examples of customer sites are a customer private locations (e.g., Point of Presence (PoP) and Data Center (DC)), a Virtual Private Cloud (VPC), or servers hosted within the provider network or colocation service.
顧客サイトの例としては、顧客のプライベート ロケーション (ポイント オブ プレゼンス (PoP) やデータ センター (DC) など)、仮想プライベート クラウド (VPC)、プロバイダー ネットワークまたはコロケーション サービス内でホストされるサーバーなどがあります。
Resource Control:
リソース制御:
In the context of this document, resource control is used mainly to refer to buffer management and relevant Quality of Service (QoS) functions.
このドキュメントの文脈では、リソース制御は主にバッファ管理および関連するサービス品質 (QoS) 機能を指すために使用されます。
"5G Network Slicing" and "5G Network Slice":
「5G ネットワーク スライシング」と「5G ネットワーク スライス」:
Refer to "Network Slicing" and "Network Slice" as defined in [TS-28.530].
[TS-28.530] で定義されている「ネットワーク スライス」および「ネットワーク スライス」を参照してください。
3GPP:
3GPP:
3rd Generation Partnership Project
3世代パートナーシッププロジェクト
5GC:
5GC:
5G Core
5Gコア
5QI:
5QI:
5G QoS Indicator
5G QoSインジケーター
A2A:
A2A:
Any-to-Any
任意対任意
AC:
AC:
Attachment Circuit
取付回路
AMF:
AMF:
Access and Mobility Management Function
アクセスおよびモビリティ管理機能
CE:
CE:
Customer Edge
カスタマーエッジ
CIR:
CIR:
Committed Information Rate
認定情報レート
CS:
CS:
Customer Site
顧客サイト
CN:
CN:
Core Network
コアネットワーク
CoS:
CoS:
Class of Service
サービスのクラス
CP:
CP:
Control Plane
コントロールプレーン
CU:
CU:
Centralized Unit
集中ユニット
CU-CP:
CU-CP:
Centralized Unit Control Plane
集中ユニット制御プレーン
CU-UP:
キューアップ:
Centralized Unit User Plane
集中ユニットのユーザープレーン
DC:
DC:
Data Center
データセンター
DDoS:
DDoS:
Distributed Denial of Service
分散型サービス妨害
DM:
DM:
Data Model
データモデル
DSCP:
DSCP:
Differentiated Services Code Point
差別化サービスのコードポイント
eCPRI:
eCPRI:
enhanced Common Public Radio Interface
強化された共通公衆無線インターフェイス
FIB:
FIB:
Forwarding Information Base
転送情報ベース
GPRS:
GPRS:
General Packet Radio Service
一般パケット無線サービス
gNB:
gNB:
gNodeB
gNodeB
GTP:
GTP:
GPRS Tunneling Protocol
GPRS トンネリング プロトコル
GTP-U:
GTP-U:
GPRS Tunneling Protocol User Plane
GPRS トンネリング プロトコル ユーザー プレーン
IGP:
IGP:
Interior Gateway Protocol
内部ゲートウェイ プロトコル
L2VPN:
L2VPN:
Layer 2 Virtual Private Network
レイヤ 2 仮想プライベート ネットワーク
L3VPN:
L3VPN:
Layer 3 Virtual Private Network
レイヤ 3 仮想プライベート ネットワーク
LSP:
LSP:
Label Switched Path
ラベルスイッチドパス
MACsec:
MACsec:
Media Access Control Security
メディアアクセス制御セキュリティ
MIoT:
MIoT:
Massive Internet of Things
大規模なモノのインターネット
MNO:
MNO:
Mobile Network Operator
モバイルネットワークオペレーター
MPLS:
MPLS:
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
NF:
NF:
Network Function
ネットワーク機能
NS:
NS:
Network Slice
ネットワークスライス
NRP:
NRP:
Network Resource Partition
ネットワークリソースパーティション
NSC:
NSC:
Network Slice Controller
ネットワークスライスコントローラー
PE:
PE:
Provider Edge
プロバイダーエッジ
PIR:
PIR:
Peak Information Rate
ピーク情報速度
QoS:
QoS:
Quality of Service
サービスの品質
RAN:
RAN:
Radio Access Network
無線アクセスネットワーク
RIB:
RIB:
Routing Information Base
ルーティング情報ベース
RSVP:
お返事お願いします：
Resource Reservation Protocol
リソース予約プロトコル
SD:
SD:
Slice Differentiator
スライス微分器
SDP:
SDP:
Service Demarcation Point
サービス境界点
SLA:
SLA:
Service Level Agreement
サービスレベル契約
SLO:
SLO:
Service Level Objective
サービスレベル目標
S-NSSAI:
S-NSSAI:
Single Network Slice Selection Assistance Information
単一ネットワークスライスの選択に関する支援情報
SST:
SST:
Slice/Service Type
スライス/サービスの種類
SR:
SR:
Segment Routing
セグメントルーティング
SRv6:
SRv6:
Segment Routing version 6
セグメントルーティングバージョン6
TC:
TC:
Traffic Class
トラフィッククラス
TE:
TE:
Traffic Engineering
交通工学
TN:
TN:
Transport Network
トランスポートネットワーク
UP:
UP:
User Plane
ユーザープレーン
UPF:
UPF:
User Plane Function
ユーザープレーン機能
URLLC:
URLLC:
Ultra-Reliable Low-Latency Communication
非常に信頼性の高い低遅延通信
VLAN:
VLAN:
Virtual Local Area Network
仮想ローカルエリアネットワーク
VPN:
VPN:
Virtual Private Network
仮想プライベートネットワーク
VRF:
VRF:
Virtual Routing and Forwarding
仮想ルーティングと転送
VXLAN:
VXLAN:
Virtual Extensible Local Area Network
仮想拡張可能なローカル エリア ネットワーク
The main 5G network building blocks are the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). The Transport Network is defined by the 3GPP in Section 1 of [TS-28.530]:
5G ネットワークの主な構成要素は、無線アクセス ネットワーク (RAN)、コア ネットワーク (CN)、およびトランスポート ネットワーク (TN) です。トランスポート ネットワークは、3GPP によって [TS-28.530] のセクション 1 で定義されています。
part supporting connectivity within and between CN and RAN parts.
CN 部分と RAN 部分内およびそれらの間の接続をサポートする部分。
The 3GPP management system does not directly control the Transport Network; it is considered a non-3GPP managed system. This is discussed in Section 4.4.1 of [TS-28.530]:
3GPP 管理システムはトランスポート ネットワークを直接制御しません。これは、非 3GPP 管理対象システムとみなされます。これについては、[TS-28.530] のセクション 4.4.1 で説明されています。
The non-3GPP part includes TN parts. The 3GPP management system provides the network slice requirements to the corresponding management systems of those non-3GPP parts, e.g. the TN part supports connectivity within and between CN and AN parts.
非３ＧＰＰ部分には、ＴＮ部分が含まれる。3GPP 管理システムは、ネットワーク スライス要件を、非 3GPP 部分の対応する管理システムに提供します。TN パーツは、CN パーツと AN パーツ内および間の接続をサポートします。
In practice, the TN may not map to a monolithic architecture and management domain. It is frequently segmented, non-uniform, and managed by different entities. For example, Figure 2 depicts an NF instance that is deployed in an edge data center (DC) connected to an NF located in a Public Cloud via a WAN (e.g., MPLS-VPN service). In this example, the TN can be seen as an abstraction representing an end-to-end connectivity based upon three distinct domains: DC, WAN, and Public Cloud. A model for the Transport Network based on orchestration domains is introduced in Section 3.4.
実際には、TN はモノリシック アーキテクチャおよび管理ドメインにマッピングされない場合があります。多くの場合、セグメント化され、不均一で、さまざまなエンティティによって管理されます。たとえば、図 2 は、WAN (MPLS-VPN サービスなど) を介してパブリック クラウドにある NF に接続されたエッジ データ センター (DC) に展開された NF インスタンスを示しています。この例では、TN は、DC、WAN、およびパブリック クラウドの 3 つの異なるドメインに基づくエンドツーエンド接続を表す抽象化として見ることができます。オーケストレーション ドメインに基づくトランスポート ネットワークのモデルは、セクション 3.4 で紹介されます。
+----------------------------------+
+----+ 5G RAN or Core Network +----+
| +----------------------------------+ |
| |
v v
+--+ +----------------------------------+ +--+
|NF+--+ Transport Network +--+NF|
+--+ +--+---------------+------------+--+ +--+
| | |
v v v
+-- Data Center --+ +-MPLS VPN-+ +-Public-+
| | | Backbone | | Cloud |
| +----+ +----+ | +--+ +--+ +--+ |
| '----' '----' | |PE| |PE| |GW| |
| .-. .-. .-. .-. | +--+ +--+ +--+ |
| '-' '-' '-' '-' | | | | |
| | +--+ +--+ | |
| | |PE| |PE| | |
| | +--+ +--+ | |
| | | | | |
+-----------------+ +----------+ +--------+
Figure 2: Example of Transport Network Decomposition
図 2: トランスポート ネットワークの分解の例
Network slicing has a different meaning in the 3GPP mobile world and transport world. This difference can be seen from the descriptions below that set out the objectives of 5G Network Slicing (Section 3.2.1) and Transport Network Slicing (Section 3.2.2). These descriptions are not intended to be exhaustive.
ネットワーク スライシングは、3GPP モバイルの世界とトランスポートの世界では異なる意味を持ちます。この違いは、5G ネットワーク スライシング (セクション 3.2.1) とトランスポート ネットワーク スライシング (セクション 3.2.2) の目的を説明する以下の説明からわかります。これらの説明は網羅的なものではありません。
In [TS-28.530], the 3GPP defines 5G Network Slicing as an approach:
[TS-28.530] では、3GPP は 5G ネットワーク スライシングをアプローチとして定義しています。
where logical networks/partitions are created, with appropriate isolation, resources and optimized topology to serve a purpose or service category (e.g. use case/traffic category, or for MNO internal reasons) or customers (logical system created "on demand").
論理ネットワーク/パーティションが作成され、適切な分離、リソース、および最適化されたトポロジを使用して、目的またはサービス カテゴリ (例: ユース ケース/トラフィック カテゴリ、または MNO 内部の理由) または顧客 (論理システムは「オンデマンド」で作成される) に対応します。
These resources are from the TN, RAN, and CN domains together with the underlying infrastructure.
これらのリソースは、基盤となるインフラストラクチャとともに、TN、RAN、および CN ドメインからのものです。
Section 3.1 of [TS-28.530] defines a 5G Network Slice as:
[TS-28.530] のセクション 3.1 では、5G ネットワーク スライスを次のように定義しています。
a logical network that provides specific network capabilities and network characteristics, supporting various service properties for network slice customers.
特定のネットワーク機能とネットワーク特性を提供し、ネットワーク スライスの顧客向けにさまざまなサービス プロパティをサポートする論理ネットワーク。
The term "Transport Network Slice" refers to a slice in the Transport Network domain of the 5G architecture. This section elaborates on how Transport Network Slicing is defined in the context of this document. It draws on the 3GPP definitions of "Transport Network" and "Network Slicing" in [TS-28.530].
「トランスポート ネットワーク スライス」という用語は、5G アーキテクチャのトランスポート ネットワーク ドメイン内のスライスを指します。このセクションでは、このドキュメントのコンテキストでトランスポート ネットワーク スライシングがどのように定義されるかについて詳しく説明します。これは、[TS-28.530] の「トランスポート ネットワーク」と「ネットワーク スライシング」の 3GPP 定義を利用しています。
The objective of Transport Network Slicing is to isolate, guarantee, or prioritize Transport Network resources for Slice Services. Examples of such resources include buffers, link capacity, or even Routing Information Base (RIB) and Forwarding Information Base (FIB).
トランスポート ネットワーク スライシングの目的は、スライス サービス用のトランスポート ネットワーク リソースを分離、保証、または優先順位付けすることです。このようなリソースの例には、バッファ、リンク容量、さらにはルーティング情報ベース (RIB) や転送情報ベース (FIB) などがあります。
Transport Network Slicing provides various degrees of sharing of resources between slices (Section 8 of [RFC9543]). For example, the network capacity can be shared by all slices, usually with a guaranteed minimum per slice, or each individual slice can be allocated dedicated network capacity. Parts of a given network may use the former, while others use the latter. For example, in order to satisfy local engineering guidelines and specific service requirements, shared TN resources could be provided in the backhaul (or midhaul), and dedicated TN resources could be provided in the midhaul (or backhaul). The capacity partitioning strategy is deployment specific.
トランスポート ネットワーク スライシングは、スライス間でリソースをさまざまなレベルで共有します ([RFC9543] のセクション 8)。たとえば、ネットワーク容量をすべてのスライスで共有することができ、通常はスライスごとに最小値が保証されたり、個々のスライスに専用のネットワーク容量を割り当てることができます。特定のネットワークの一部では前者が使用され、他の部分では後者が使用される場合があります。たとえば、ローカル エンジニアリング ガイドラインと特定のサービス要件を満たすために、共有 TN リソースをバックホール (またはミッドホール) で提供し、専用 TN リソースをミッドホール (またはバックホール) で提供できます。容量分割戦略は展開ごとに異なります。
There are different components to implement Transport Network Slices based upon mechanisms such as Virtual Routing and Forwarding (VRF) instances for logical separation, QoS, and Traffic Engineering (TE). Whether all or a subset of these components are enabled is a deployment choice.
論理分離、QoS、トラフィック エンジニアリング (TE) のための仮想ルーティングおよび転送 (VRF) インスタンスなどのメカニズムに基づいてトランスポート ネットワーク スライスを実装するには、さまざまなコンポーネントがあります。これらのコンポーネントのすべてを有効にするかサブセットを有効にするかは、展開の選択によって決まります。
Figure 3 depicts the reference design used in this document for modeling the Transport Network based on management perimeters (customer vs. provider).
図 3 は、管理境界 (顧客対プロバイダー) に基づいてトランスポート ネットワークをモデル化するためにこのドキュメントで使用されるリファレンス デザインを示しています。
Customer Provider Customer
Orchestration Orchestration Orchestration
Domain Domain Domain
+----------------+ +---------------------+ +----------------+
| Customer | | Provider Network | | Customer |
| Site 1 | | | | Site 2 |
| +----+ | | +----+ +----+ | | +----+ |
| +--+ | | | AC | | | | | | AC | | | |
| |NF|....| CE +----------+ PE | | PE +-----------+ NF | |
| +--+ | | | | | | | | | | | | |
| +----+ | | +----+ +----+ | | +----+ |
| | | | | (CE) |
+----------------+ +---------------------+ +----------------+
<-----------------Transport Network--------------->
Figure 3: Reference Design with Customer Sites and Provider Network
図 3: 顧客サイトとプロバイダー ネットワークを使用したリファレンス デザイン
The description of the main components shown in Figure 3 is provided in the following subsections.
図 3 に示す主なコンポーネントについては、次のサブセクションで説明します。
On top of 5G NFs, a customer may manage additional TN elements (e.g., servers, routers, and switches) within a customer site.
5G NF に加えて、顧客は顧客サイト内の追加の TN 要素 (サーバー、ルーター、スイッチなど) を管理できます。
NFs may be hosted on a CE, directly connected to a CE, or located multiple IP hops from a CE.
NF は、CE 上でホストされることも、CE に直接接続されることも、CE から複数の IP ホップの場所に配置されることもあります。
In some contexts, the connectivity between NFs that belong to the same site can be achieved via the provider network.
状況によっては、同じサイトに属する NF 間の接続はプロバイダー ネットワーク経由で実現できます。
The orchestration of the TN within a customer site involves a set of controllers for automation purposes (e.g., Network Function Virtualization Infrastructure (NFVI), Container Network Interface (CNI), Fabric Managers, or Public Cloud APIs). Documenting how these controllers are implemented is out of scope for this document.
顧客サイト内の TN のオーケストレーションには、自動化を目的とした一連のコントローラー (ネットワーク機能仮想化インフラストラクチャ (NFVI)、コンテナー ネットワーク インターフェイス (CNI)、ファブリック マネージャー、またはパブリック クラウド API など) が含まれます。これらのコントローラーがどのように実装されるかを文書化することは、このドキュメントの範囲外です。
A CE is a function that provides logical connectivity of a customer site (Section 3.3.1) to the provider network (Section 3.3.3). The logical connectivity is enforced at Layer 2 and/or Layer 3 and is denominated an Attachment Circuit (AC) (Section 3.3.5). Examples of CEs include TN components (e.g., router, switch, and firewalls) and also 5G NFs (i.e., an element of the 5G domain such as Centralized Unit (CU), Distributed Unit (DU), or User Plane Function (UPF)).
CE は、顧客サイト (セクション 3.3.1) とプロバイダー ネットワーク (セクション 3.3.3) の論理接続を提供する機能です。論理接続はレイヤー 2 および/またはレイヤー 3 で強制され、アタッチメント回路 (AC) と呼ばれます (セクション 3.3.5)。CE の例には、TN コンポーネント (ルータ、スイッチ、ファイアウォールなど) や 5G NF (つまり、集中ユニット (CU)、分散ユニット (DU)、またはユーザー プレーン機能 (UPF) などの 5G ドメインの要素) が含まれます。
A CE is typically managed by the customer, but it can also be co-managed with the provider. A co-managed CE is orchestrated by both the customer and the provider. In this case, the customer and provider usually have control on distinct device configuration perimeters. A co-managed CE has both PE and CE functions, and there is no strict AC connection, although one may consider that the AC stitching logic happens internally within the CE itself. The provider manages the AC between the CE and the PE.
CE は通常、顧客によって管理されますが、プロバイダーと共同管理することもできます。共同管理される CE は、顧客とプロバイダーの両方によって調整されます。この場合、通常、顧客とプロバイダーは個別のデバイス構成境界を制御します。共同管理される CE には PE と CE の両方の機能があり、厳密な AC 接続はありませんが、AC スティッチング ロジックが CE 自体の内部で発生すると考えることもできます。プロバイダーは、CE と PE 間の AC を管理します。
This document generalizes the definition of a CE with the introduction of "distributed CE"; that is, the logical connectivity is realized by configuring multiple devices in the customer domain. The CE function is distributed. An example of distributed CE is the realization of an interconnection using an L3VPN service based on a distributed CE composed of a switch (SW) in Layer 2 and a router (RTR) in Layer 3, as shown in Figure 4. Another example of distributed CE is shown in Figure 5.
この文書では、「分散 CE」の導入により CE の定義を一般化します。つまり、論理接続は、顧客ドメイン内に複数のデバイスを構成することによって実現されます。CE機能が分散されています。分散 CE の例は、図 4 に示すように、レイヤ 2 のスイッチ (SW) とレイヤ 3 のルータ (RTR) で構成される分散 CE に基づく L3VPN サービスを使用した相互接続の実現です。分散 CE の別の例を図 5 に示します。
+--------------+ +--------------+
| Customer | | Provider |
| Site | | Network |
| +---------------+ | |
| | | | |
| | +---+ +----+ | +----+ |
| | | | | ================== | |
| | | +------------AC----------+ PE | |
| | |RTR| | SW ================== | |
| | +---+ +----+ | +----+ |
| | | | |
| +--Distributed--+ | |
| CE | | |
+--------------+ +--------------+
Figure 4: Example of Distributed CE
図 4: 分散 CE の例
In most cases, CEs connect to PEs using IP (e.g., via Layer 3 VLAN subinterfaces), but a CE may also connect to the provider network using other technologies such as MPLS (potentially over IP tunnels) or Segment Routing over IPv6 (SRv6) [RFC8986]. Thus, the CE has awareness of provider service configuration (e.g., control plane identifiers such as Route Targets (RTs) and Route Distinguishers (RDs)). However, the CE is still managed by the customer, and the AC is based on MPLS or SRv6 data plane technologies. The complete termination of the AC within the provider network may happen on distinct routers; this is another example of distributed PE. Service-aware CEs are used, for example, in the deployments discussed in Sections 4.3.2 and 4.3.3.
ほとんどの場合、CE は IP を使用して (たとえば、レイヤ 3 VLAN サブインターフェイス経由で) PE に接続しますが、CE は、MPLS (潜在的に IP トンネル経由) やセグメント ルーティング オーバー IPv6 (SRv6) [RFC8986] などの他のテクノロジーを使用してプロバイダー ネットワークに接続することもあります。したがって、CE はプロバイダーのサービス構成 (たとえば、ルート ターゲット (RT) やルート識別子 (RD) などのコントロール プレーン識別子) を認識します。ただし、CE は引き続き顧客によって管理され、AC は MPLS または SRv6 データ プレーン テクノロジーに基づいています。プロバイダー ネットワーク内の AC の完全な終了は、別のルーターで発生する可能性があります。これは分散 PE の別の例です。サービス対応 CE は、たとえば、セクション 4.3.2 および 4.3.3 で説明する展開で使用されます。
A provider uses a provider network to interconnect customer sites. This document assumes that the provider network is based on IP, MPLS, or both.
プロバイダーは、プロバイダー ネットワークを使用して顧客サイトを相互接続します。このドキュメントでは、プロバイダー ネットワークが IP、MPLS、またはその両方に基づいていることを前提としています。
A PE is a device managed by a provider that is connected to a CE. The connectivity between a CE and a PE is achieved using one or multiple ACs (Section 3.3.5).
PE は、CE に接続されているプロバイダーによって管理されるデバイスです。CE と PE 間の接続は、1 つまたは複数の AC を使用して実現されます (セクション 3.3.5)。
This document generalizes the PE definition with the introduction of "distributed PE"; that is, the logical connectivity is realized by configuring multiple devices in the provider network (i.e., the Provider Orchestration Domain). The PE function is distributed.
このドキュメントでは、「分散 PE」を導入して PE の定義を一般化します。つまり、論理接続は、プロバイダー ネットワーク (つまり、プロバイダー オーケストレーション ドメイン) 内で複数のデバイスを構成することによって実現されます。PE機能が分散されています。
An example of a distributed PE is the "managed CE service". For example, a provider delivers VPN services using CEs and PEs that are both managed by the provider (example (i) in Figure 5). The managed 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 customers. However, this device is part of the provider network.
分散型 PE の例は、「マネージド CE サービス」です。たとえば、プロバイダーは、プロバイダーが管理する CE と PE を使用して VPN サービスを提供します (図 5 の例 (i))。図 5 の例 (ii) に示すように、管理対象 CE はデータ センター ゲートウェイにすることもできます。プロバイダー管理の CE は、複数の顧客の CE に接続することができます。ただし、このデバイスはプロバイダー ネットワークの一部です。
+--------------+ +--------------+
| Customer | | Provider |
| Site | | Network |
| | +-----------------+ |
| +----+ | +----+ +----+ | |
| | ==================Mngd| | | | |
| | CE +--------AC------+ CE +---+ PE | | |
| | ================== | | | | |
| +----+ | +----+ +----+ | |
| | +---Distributed---+ |
| | | PE |
+--------------+ +--------------+
(i) Distributed PE
+--------------+ +--------------+
| Customer | | Provider |
| Site | | Network |
| +-----------------+ +-----------------+ |
| | IP Fabric | | +----+ +----+ | |
| | +----+ +----+ ============= DC | | | | |
| | '----' '----' +-----AC----+ GW +---+ PE | | |
| | .-. .-. .-. .-. ============= | | | | |
| | '-' '-' '-' '-' | | +----+ +----+ | |
| +---Distributed---+ +---Distributed---+ |
| CE | | PE |
| | | |
+--Data Center-+ +--------------+
(ii) Distributed PE and CE
Figure 5: Examples of Distributed PE
図 5: 分散 PE の例
In subsequent sections of this document, the terms "CE" and "PE" are used for both single and distributed devices.
このドキュメントの後続のセクションでは、「CE」および「PE」という用語は、単一デバイスと分散デバイスの両方を指します。
The AC is the logical connection that attaches a CE (Section 3.3.2) to a PE (Section 3.3.4). A CE is connected to a PE via one or multiple ACs.
AC は、CE (セクション 3.3.2) を PE (セクション 3.3.4) に接続する論理接続です。CE は 1 つまたは複数の AC を介して PE に接続されます。
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 consistent with the orchestration perimeters (Section 3.4). The CEs and PEs delimit the customer and provider orchestration domains, respectively, while an AC interconnects these domains.
このドキュメントでは、分散 CE および PE (セクション 3.3.2 および 3.3.4) の概念を使用して、オーケストレーション境界 (セクション 3.4) と一致する CE/AC/PE 定義を統合します。CE と PE はそれぞれ顧客とプロバイダーのオーケストレーション ドメインを区切りますが、AC はこれらのドメインを相互接続します。
For consistency with the terminology used in AC data models (e.g., the data models defined in [RFC9834] and [RFC9835]), this document assumes that an AC is configured on a "bearer", which represents the underlying connectivity. For example, the bearer is illustrated with "=" in Figures 4 and 5.
AC データ モデル ([RFC9834] および [RFC9835] で定義されているデータ モデルなど) で使用される用語との一貫性を保つために、この文書では、AC が基礎的な接続を表す「ベアラー」上に設定されていることを前提としています。たとえば、図 4 と図 5 では、ベアラーは「=」で示されています。
An AC is technology specific. Examples of ACs are VLAN ACs configured on a physical interface (bearer) or Overlay VXLAN EVI ACs configured on an IP underlay (bearer).
AC はテクノロジー固有です。AC の例としては、物理インターフェイス (ベアラー) で構成された VLAN AC、または IP アンダーレイ (ベアラー) で構成されたオーバーレイ VXLAN EVI AC があります。
Deployment cases where the AC is also managed by the provider are not discussed in this document because the setup of such an AC does not require any coordination between the customer and provider orchestration domains.
AC がプロバイダーによって管理される展開ケースについては、このドキュメントでは説明しません。そのような AC のセットアップには、顧客とプロバイダーのオーケストレーション ドメイン間の調整が必要ないためです。
Note: In order to keep the figures simple, only one AC and single-homed CEs are represented. Also, the underlying bearers are not represented in most of the figures. However, this document does not exclude the instantiation of multiple ACs between a CE and a PE nor the presence of CEs that are attached to more than one PE.
注: 図を単純にするために、1 つの AC およびシングルホーム CE のみが示されています。また、ほとんどの図には、基礎となる担い手が示されていません。ただし、この文書は、CE と PE 間の複数の AC のインスタンス化や、複数の PE に接続されている CE の存在を除外しません。
This section introduces a global framework for the orchestration of a 5G end-to-end slice (a.k.a. 5G Network Slice) with a zoom on TN parts. This framework helps to delimit the realization scope of RFC 9543 Network Slices and identify interactions that are required for the realization of such slices.
このセクションでは、TN 部分に焦点を当てた 5G エンドツーエンド スライス (別名 5G ネットワーク スライス) のオーケストレーションのためのグローバル フレームワークを紹介します。このフレームワークは、RFC 9543 ネットワーク スライスの実現範囲を制限し、そのようなスライスの実現に必要な相互作用を特定するのに役立ちます。
This framework is consistent with the management coordination example shown in Figure 4.7.1 of [TS-28.530].
このフレームワークは、[TS-28.530] の図 4.7.1 に示されている管理調整の例と一致しています。
In Figure 6, a 5G End-to-End Network Slice Orchestrator (5G NSO) is responsible for orchestrating 5G Network Slices end-to-end. The details of the 5G NSO are out of the scope of this document. The realization of the 5G Network Slices spans RAN, CN, and TN. As mentioned in Section 3.1, the RAN and CN are under the responsibility of the 3GPP management system, while the TN is not. The orchestration of the TN is split into two subdomains in conformance with the reference design in Section 3.3:
図 6 では、5G エンドツーエンド ネットワーク スライス オーケストレーター (5G NSO) が、5G ネットワーク スライスのエンドツーエンドの調整を担当します。5G NSO の詳細については、このドキュメントの範囲外です。5G ネットワーク スライスの実現は、RAN、CN、TN に及びます。セクション 3.1 で述べたように、RAN と CN は 3GPP 管理システムの責任下にありますが、TN はそうではありません。TN のオーケストレーションは、セクション 3.3 のリファレンス設計に従って 2 つのサブドメインに分割されます。
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 orchestrate RFC 9543 Network Slices in the provider network. This framework allows for managing connectivity with SLOs.
[RFC9543] で定義されているように、プロバイダーはネットワーク スライス コントローラー (NSC) に依存して、プロバイダー ネットワーク内の RFC 9543 ネットワーク スライスを管理および調整します。このフレームワークにより、SLO との接続を管理できます。
Customer Site Orchestration Domain (simply referred to as "Customer Orchestration Domain"):
顧客サイト オーケストレーション ドメイン (単に「顧客オーケストレーション ドメイン」と呼ばれます):
The orchestration of TN elements of the customer sites relies upon a variety of controllers (e.g., Fabric Manager, Element Management System, or Virtualized Infrastructure Manager (VIM)).
顧客サイトの TN 要素のオーケストレーションは、さまざまなコントローラー (ファブリック マネージャー、要素管理システム、仮想化インフラストラクチャー マネージャー (VIM) など) に依存します。
A Transport Network Slice relies upon resources that can involve both the provider and customer TN domains. More details are provided in Section 3.4.2.
トランスポート ネットワーク スライスは、プロバイダーと顧客の両方の TN ドメインが関与する可能性のあるリソースに依存します。詳細については、セクション 3.4.2 を参照してください。
A Transport Network Slice might be considered as a variant of horizontal composition of network slices mentioned in Appendix A.6 of [RFC9543].
トランスポートネットワークスライスは、[RFC9543] の付録 A.6 で言及されているネットワークスライスの水平構成の変形と考えることができます。
.---------.
| 5G NSO |
'-+---+---'
| |
v |
.-------------. |
| 3GPP domains | |
.----------+ Orchestration +-)---------------------------.
| | (RAN and CN) | | |
| '-------------' | |
| v |
| .-----------------------------------------------. |
| | Transport Network Orchestration | |
| | +--------------+ +-----------+ +--------------+ | |
| | |Customer Site | |RFC9543 NSC| |Customer Site | | |
| | |Orchestration | | | |Orchestration | | |
| | +--------------+ +-----------+ +--------------+ | |
| '---|-------------------|---------------------|-' |
| | | | |
| | | | |
| v v v |
+--|----------+ +-----------------+ +-------|--+
| | | | Provider | | | |
| v | +----+ Network +----+ +-----+ | |
| +--+ +----+ AC | | | | AC | NF |<-+ |
| |NF+....+ CE +------+ PE | | PE +------+ (CE)| |
| +--+ +----+ | | | | +-----+ |
| | +----+ +----+ | |
| Customer | | | | Customer |
| Site | | | | Site |
+-------------+ +-----------------+ +----------+
RFC 9543
|-----Network Slice---|
|-------------Transport Network Slice-----------|
Figure 6: 5G End-to-End Slice Orchestration with TN
図 6: TN を使用した 5G エンドツーエンドのスライス オーケストレーション
The various orchestrations depicted in Figure 6 encompass the 3GPP's Network Slice Subnet Management Function (NSSMF) mentioned, for instance, in Figure 5 of [NS-APP].
図 6 に示されているさまざまなオーケストレーションには、たとえば [NS-APP] の図 5 で言及されている 3GPP のネットワーク スライス サブネット管理機能 (NSSMF) が含まれています。
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) as SDP Types 3 or 4 in this document.
分散型 PE (セクション 3.3.4) の概念は、[RFC9543] のセクション 5.2 で定義されている CE ベースの SDP (つまり、タイプ 1 および 2) を、この文書では SDP タイプ 3 または 4 として同化します。
In the architecture depicted in Section 3.4.1, the connectivity between NFs can be decomposed into three main segment types:
セクション 3.4.1 で説明したアーキテクチャでは、NF 間の接続は 3 つの主要なセグメント タイプに分解できます。
Customer Site:
顧客サイト:
Either connects NFs located in the same customer site or connects an NF to a CE.
同じ顧客サイト内にある NF を接続するか、NF を CE に接続します。
This segment may not be present if the NF is the CE. In this case, the AC connects the NF to a PE.
NF が CE である場合、このセグメントは存在しない可能性があります。この場合、AC は NF を PE に接続します。
The realization of this segment is driven by the 5G Network Orchestration (e.g., NF instantiation) and the Customer Site Orchestration for the TN part.
このセグメントの実現は、5G ネットワーク オーケストレーション (NF インスタンス化など) と TN 部分の顧客サイト オーケストレーションによって推進されます。
Provider Network:
プロバイダーネットワーク:
Represents the connectivity between two PEs. The realization of this segment is controlled by an NSC (Section 6.3 of [RFC9543]).
2 つの PE 間の接続を表します。このセグメントの実現は、NSC ([RFC9543] のセクション 6.3) によって制御されます。
Attachment Circuit:
取り付け回路:
The orchestration of this segment relies partially upon an NSC for the configuration of the AC on the PE customer-facing interfaces and the Customer Site Orchestration for the configuration of the AC on the CE.
このセグメントのオーケストレーションは、PE の顧客側インターフェイス上の AC の設定については NSC に、また CE 上の AC の設定については顧客サイト オーケストレーションに部分的に依存しています。
PEs and CEs that are connected via an AC need to be provisioned with consistent data plane and control plane information (VLAN IDs, IP addresses/subnets, BGP Autonomous System Number (ASN), etc.). Hence, the realization of this interconnection is technology specific and requires coordination between the Customer Site Orchestration and an NSC. Automating the provisioning and management of the AC is thus key to automate the overall service provisioning. Aligned with [RFC8969], this document assumes that this coordination is based upon standard YANG data models and APIs.
AC 経由で接続されている PE および CE には、一貫したデータ プレーンおよびコントロール プレーン情報 (VLAN ID、IP アドレス/サブネット、BGP 自律システム番号 (ASN) など) をプロビジョニングする必要があります。したがって、この相互接続の実現はテクノロジー固有であり、顧客サイトのオーケストレーションと NSC の間の調整が必要です。したがって、AC のプロビジョニングと管理を自動化することが、サービス プロビジョニング全体を自動化するための鍵となります。[RFC8969] に準拠したこの文書では、この調整が標準の YANG データ モデルと API に基づいていることを前提としています。
The provisioning of an RFC 9543 Network Slice may rely on new or existing ACs.
RFC 9543 ネットワーク スライスのプロビジョニングは、新規または既存の AC に依存する場合があります。
Figure 7 is a basic example of a Layer 3 CE-PE link realization with shared network resources (such as VLAN IDs and IP prefixes), which are passed between orchestrators via a dedicated interface, e.g., the Network Slice Service Model (NSSM) [NSSM] or Attachment Circuits as a Service (ACaaS) [RFC9834].
図 7 は、共有ネットワーク リソース (VLAN ID や IP プレフィックスなど) を使用したレイヤ 3 CE-PE リンク実現の基本的な例です。共有ネットワーク リソースは、ネットワーク スライス サービス モデル (NSSM) [NSSM] やサービスとしての接続回線 (ACaaS) [RFC9834] などの専用インターフェイスを介してオーケストレーター間で渡されます。
.-------------. .----------------.
| | | RFC 9543 NSC |
| Customer Site | | |
| Orchestration | IETF APIs/DM |(Provider Network |
| |<----------------->| Orchestration) |
'-------------' '----------------'
| |
| |
+---------------|-+ +-|---------------+
| v | | v |
| +--+ +--+ .1| 192.0.2.0/31 |.0+--+ |
| |NF+.....+CE+---------------------------+PE| |
| +--+ +--+ | VLAN 100 | +--+ |
| Customer | | Provider |
| Site | | Network |
+-----------------+ +-----------------+
|----------- AC -----------|
Figure 7: Coordination of Transport Network Resources for AC Provisioning
図 7: AC プロビジョニングのためのトランスポート ネットワーク リソースの調整
There are multiple options for mapping 5G Network Slices to Transport Network Slices:
5G ネットワーク スライスをトランスポート ネットワーク スライスにマッピングするには、複数のオプションがあります。
1-to-N mapping:
1 対 N マッピング:
A single 5G Network Slice can be mapped to multiple Transport Network Slices. For instance, consider the scenario depicted in Figure 8, which illustrates the separation of the 5G control plane and user plane in Transport Network Slices for a single 5G Enhanced Mobile Broadband (eMBB) network slice. It is important to note that this mapping can serve as an interim step to M-to-N mapping. Further details about this scheme are described in Section 3.6.
単一の 5G ネットワーク スライスを複数のトランスポート ネットワーク スライスにマッピングできます。たとえば、単一の 5G エンハンスド モバイル ブロードバンド (eMBB) ネットワーク スライスのトランスポート ネットワーク スライスにおける 5G コントロール プレーンとユーザー プレーンの分離を示す図 8 に示すシナリオを考えてみましょう。このマッピングは、M 対 N マッピングへの暫定ステップとして機能する可能性があることに注意することが重要です。このスキームの詳細については、セクション 3.6 で説明します。
M-to-1 mapping:
M 対 1 マッピング:
Multiple 5G Network Slices may rely upon the same Transport Network Slice. In such a case, the Service Level Agreement (SLA) differentiation of slices would be entirely controlled at the 5G control plane, for example, with appropriate placement strategies. This use case is illustrated in Figure 9, where a UPF for the Ultra-Reliable Low-Latency Communication (URLLC) slice is instantiated at the edge cloud, close to the gNB CU-UP, to improve latency and jitter control. The 5G control plane and the UPF for the eMBB slice are instantiated in the regional cloud.
複数の 5G ネットワーク スライスが同じトランスポート ネットワーク スライスに依存する場合があります。このような場合、スライスのサービス レベル アグリーメント (SLA) の差別化は、たとえば、適切な配置戦略を使用して、5G コントロール プレーンで完全に制御されます。この使用例は図 9 に示されています。ここでは、超高信頼性低遅延通信 (URLLC) スライスの UPF が、gNB CU-UP に近いエッジ クラウドでインスタンス化され、遅延とジッター制御が改善されています。5G コントロール プレーンと eMBB スライスの UPF はリージョン クラウドでインスタンス化されます。
M-to-N mapping:
M 対 N マッピング:
The mapping of 5G to Transport Network Slice combines both approaches with a mix of shared and dedicated associations.
5G のトランスポート ネットワーク スライスへのマッピングでは、共有関連付けと専用関連付けを組み合わせて両方のアプローチを組み合わせます。
In this scenario, a subset of the Transport Network Slices can be intended for sharing by multiple 5G Network Slices (e.g., the control plane Transport Network Slice is shared by multiple 5G Network Slices).
このシナリオでは、トランスポート ネットワーク スライスのサブセットは、複数の 5G ネットワーク スライスによる共有を目的とすることができます (たとえば、コントロール プレーンのトランスポート ネットワーク スライスは、複数の 5G ネットワーク スライスによって共有されます)。
In practice, for operational and scaling reasons, M-to-N mapping would typically be used, with M much greater than N.
実際には、運用とスケーリングの理由から、M が N よりもはるかに大きい M 対 N マッピングが通常使用されます。
+---------------------------------------------------------------+
| 5G Network Slice eMBB |
| +------------------------------------+ |
| +-----+ N3 | +--------------------------------+ | N3 +-----+ |
| |CU-UP+------+Transport Network Slice UP_eMBB +-------+ UPF | |
| +-----+ | +--------------------------------+ | +-----+ |
| | | |
| +-----+ N2 | +--------------------------------+ | N2 +-----+ |
| |CU-CP+------+ Transport Network Slice CP +-------+ AMF | |
| +-----+ | +--------------------------------+ | +-----+ |
+------------|------------------------------------|-------------+
| |
| Transport Network |
+------------------------------------+
Figure 8: 1-to-N Mapping (Single 5G Network Slice to Multiple Transport Network Slices)
図 8: 1 対 N マッピング (単一の 5G ネットワーク スライスから複数のトランスポート ネットワーク スライスへ)
+-------------+
| Edge Cloud |
| +---------+ |
| |UPF_URLLC| |
| +-----+---+ |
| | |
+-------|-----+
|
+---------------+ +-------|----------------------+
| | | | |
| Cell Site | | +-----+--------------------+ | +--------------+
| | | | | | | Regional |
| +-----------+ | | | | | | Cloud |
| |CU-UP_URLLC+-----+ Transport Network | | | +----------+ |
| +-----------+ | | | Slice ALL +-----+ 5GC CP | |
| | | | | | | +----------+ |
| +-----------+ | | | | | | |
| |CU-UP_eMBB +-----+ | | | +----------+ |
| +-----------+ | | | +-----+ UPF_eMBB | |
+---------------+ | | | | | +----------+ |
| +--------------------------+ | | |
| | +--------------+
| Transport Network |
+------------------------------+
Figure 9: M-to-1 Mapping (Multiple 5G Network Slices to Single Transport Network Slice)
図 9: M 対 1 マッピング (複数の 5G ネットワーク スライスから単一のトランスポート ネットワーク スライスへ)
Note that the actual realization of the mapping depends on several factors, such as the actual business cases, the NF vendor capabilities, the NF vendor reference designs, as well as service provider or even legal requirements.
マッピングの実際の実現は、実際のビジネス ケース、NF ベンダーの機能、NF ベンダーのリファレンス設計、サービス プロバイダー、さらには法的要件などのいくつかの要因に依存することに注意してください。
Mapping approaches that preserve the 5G Network Slice identification in the TN (e.g., the approach in Section 4.2) may simplify required operations to map Transport Network Slices back to 5G Network Slices. However, such considerations are not detailed in this document because these are under the responsibility of the 3GPP orchestration.
TN に 5G ネットワーク スライスの識別情報を保存するマッピング手法 (セクション 4.2 の手法など) は、トランスポート ネットワーク スライスを 5G ネットワーク スライスにマップし直すために必要な操作を簡素化できる可能性があります。ただし、このような考慮事項は 3GPP オーケストレーションの責任下にあるため、この文書では詳しく説明しません。
An operational 5G Network Slice incorporates both 5G control plane and user plane capabilities. For instance, in some deployments, in the case of a slice based on split CU in the RAN, both CU-UP and CU-CP may need to be deployed along with the associated interfaces E1, F1-c, F1-u, N2, and N3, which are conveyed in the TN. In this regard, the creation of the "first slice" can be subject to a specific logic that does not apply to subsequent slices. Let us consider the example depicted in Figure 10 to illustrate this deployment. In this example, the first 5G Network Slice relies on the deployment of NF-CP and NF-UP functions together with two Transport Network Slices for the control and user planes (TNS-CP and TNS-UP1). Next, in many cases, the deployment of a second slice relies solely on the instantiation of a UPF (NF-UP2) together with a dedicated Transport Network Slice for the user plane (TNS-UP2). The control plane of the first 5G Network Slice is also updated to integrate the second slice; the Transport Network Slice (TNS-CP) and Network Functions (NF-CP) are shared.
運用中の 5G ネットワーク スライスには、5G コントロール プレーンとユーザー プレーンの両方の機能が組み込まれています。たとえば、一部の展開では、RAN 内の分割 CU に基づくスライスの場合、CU-UP と CU-CP の両方を、TN で伝達される関連インターフェイス E1、F1-c、F1-u、N2、および N3 とともに展開する必要がある場合があります。この点に関して、「最初のスライス」の作成には、後続のスライスには適用されない特定のロジックが適用される場合があります。この展開を説明するために、図 10 に示す例を考えてみましょう。この例では、最初の 5G ネットワーク スライスは、コントロール プレーンとユーザー プレーン用の 2 つのトランスポート ネットワーク スライス (TNS-CP および TNS-UP1) とともに、NF-CP および NF-UP 機能の展開に依存しています。次に、多くの場合、2 番目のスライスの展開は、ユーザー プレーン (TNS-UP2) の専用トランスポート ネットワーク スライスと合わせた UPF (NF-UP2) のインスタンス化のみに依存します。最初の 5G ネットワーク スライスのコントロール プレーンも更新され、2 番目のスライスが統合されます。トランスポート ネットワーク スライス (TNS-CP) とネットワーク機能 (NF-CP) は共有されます。
The model described here, in which the control plane is shared among multiple slices, is likely to be common; it is not mandatory, though. Deployment models with a separate control plane for each slice are also possible.
ここで説明するモデルは、コントロール プレーンが複数のスライス間で共有されるものであり、一般的である可能性があります。ただし、必須ではありません。スライスごとに個別のコントロール プレーンを使用する展開モデルも可能です。
Section 6.1.2 of [NG.113] specifies that the eMBB slice (SST=1 and no Slice Differentiator (SD)) should be supported globally. This 5G Network Slice would be the first slice in any 5G deployment.
[NG.113] のセクション 6.1.2 では、eMBB スライス (SST=1 およびスライス区別器 (SD) なし) がグローバルにサポートされるべきであると指定されています。この 5G ネットワーク スライスは、5G 導入における最初のスライスになります。
(1) Deployment of first 5G Network Slice
+---------------------------------------------------------------+
| First 5G Network Slice |
| |
| +------------------------------+ |
| +-----+ | +--------------------------+ | +-----+ |
| |NF-CP+------+ TNS-CP +------+NF-CP| |
| +-----+ | +--------------------------+ | +-----+ |
| | | |
| +-----+ | +--------------------------+ | +-----+ |
| |NF-UP+------+ TNS-UP1 +------+NF-UP| |
| +-----+ | +--------------------------+ | +-----+ |
+----------------|------------------------------|---------------+
| |
| Transport Network |
+------------------------------+
(2) Deployment of additional 5G Network Slice with shared Control
Plane
+---------------------------------------------------------------+
| First 5G Network Slice |
| |
| +------------------------------+ |
| +-----+ | +--------------------------+ | +-----+ |
| |NF-CP+------+ TNS-CP +------+NF-CP| |
| +-----+ | +--------------------------+ | +-----+ |
| SHARED | (SHARED) | SHARED |
| | | |
| +-----+ | +--------------------------+ | +-----+ |
| |NF-UP+------+ TNS-UP1 +------+NF-UP| |
| +-----+ | +--------------------------+ | +-----+ |
+----------------|------------------------------|---------------+
| |
| Transport Network |
| |
+----------------|------------------------------|---------------+
| | | |
| +------+ | +--------------------------+ | +------+ |
| |NF-UP2+-----+ TNS-UP2 +-----+NF-UP2| |
| +------+ | +--------------------------+ | +------+ |
| | | |
| +------------------------------+ |
| |
| Second 5G Network Slice |
+---------------------------------------------------------------+
Figure 10: First and Subsequent Slice Deployment
図 10: 最初とその後のスライスの展開
Transport Network Slice mapping policies can be enforced by an operator (e.g., provided to a TN Orchestration or 5G NSO) to determine whether existing Transport Network Slices can be reused for handling a new Slice Service creation request. Providing such a policy is meant to better automate the realization of 5G Network Slices and minimize the realization delay that might be induced by extra cycles to seek for operator validation.
トランスポート ネットワーク スライス マッピング ポリシーは、新しいスライス サービスの作成要求を処理するために既存のトランスポート ネットワーク スライスを再利用できるかどうかを判断するために、オペレータ (たとえば、TN オーケストレーションまたは 5G NSO に提供される) によって強制できます。このようなポリシーを提供することは、5G ネットワーク スライスの実現をより自動化し、オペレータの検証を求めるための追加のサイクルによって引き起こされる可能性のある実現の遅延を最小限に抑えることを目的としています。
The realization model described in this document is depicted in Figure 11. The following building blocks are used:
このドキュメントで説明されている実現モデルを図 11 に示します。次の構成要素が使用されます。
* L2VPN [RFC4664] and/or L3VPN [RFC4364] service instances for logical separation:
* 論理的分離のための L2VPN [RFC4664] および/または L3VPN [RFC4364] サービス インスタンス:
This realization model of transport for 5G Network Slices assumes Layer 3 delivery for midhaul and backhaul transport connections and a Layer 2 or Layer 3 delivery for fronthaul connections. Enhanced Common Public Radio Interface (eCPRI) [ECPRI] supports both delivery models. L2VPN/L3VPN service instances might be used as a basic form of logical slice separation. Furthermore, using service instances results in an additional outer header (as packets are encapsulated/decapsulated at the nodes hosting service instances), providing clean discrimination between 5G QoS and TN QoS, as explained in Section 5.
5G ネットワーク スライスのトランスポートのこの実現モデルは、ミッドホールおよびバックホール トランスポート接続のレイヤ 3 配信と、フロントホール接続のレイヤ 2 またはレイヤ 3 配信を想定しています。Enhanced Common Public Radio Interface (eCPRI) [ECPRI] は、両方の配信モデルをサポートします。L2VPN/L3VPN サービス インスタンスは、論理スライス分離の基本形式として使用される場合があります。さらに、サービス インスタンスを使用すると、(サービス インスタンスをホストするノードでパケットがカプセル化/カプセル化解除されるため) 外側のヘッダーが追加され、セクション 5 で説明したように、5G QoS と TN QoS を明確に区別できます。
Note that a variety of L2VPN mechanisms can be considered for slice realization. A non-comprehensive list is provided below:
スライスの実現にはさまざまな L2VPN メカニズムが考慮されることに注意してください。包括的ではないリストを以下に示します。
- Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
- 仮想プライベート LAN サービス (VPLS) [RFC4761] [RFC4762]
- Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664])
- 仮想私線サービス (VPWS) ([RFC4664] のセクション 3.1.1)
- Various flavors of EVPNs:
- さまざまな種類の EVPN:
o VPWS EVPN [RFC8214],
o VPWS EVPN [RFC8214]、
o Provider Backbone Bridging combined with EVPN (PBB-EVPN) [RFC7623],
o EVPN と組み合わせたプロバイダー バックボーン ブリッジング (PBB-EVPN) [RFC7623]、
o EVPN over MPLS [RFC7432], and
o EVPN over MPLS [RFC7432]、および
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 in Appendix A.4 of [RFC9543].
ネットワークスライスを実現するための VPN の使用については、[RFC9543] の付録 A.4 で簡単に説明されています。
* Fine-grained resource control at the PE:
* PE でのきめ細かいリソース制御:
This is sometimes called "admission control" or "traffic conditioning". The main purpose is the enforcement of the bandwidth contract for the slice right at the edge of the provider network where the traffic is handed off between the customer site and the provider network.
これは、「アドミッション コントロール」または「トラフィック コンディショニング」と呼ばれることもあります。主な目的は、顧客サイトとプロバイダー ネットワーク間でトラフィックが受け渡されるプロバイダー ネットワークのエッジにあるスライスの帯域幅契約を強制することです。
The method used here is granular ingress policing (rate limiting) to enforce contracted bandwidths per slice and, potentially, per traffic class within the slice. Traffic above the enforced rate might be immediately dropped or marked as high drop-probability traffic, which is more likely to be dropped somewhere inside the provider network if congestion occurs. In the egress direction at the PE node, hierarchical schedulers/shapers can be deployed, providing guaranteed rates per slice, as well as guarantees per traffic class within each slice.
ここで使用される方法は、スライスごと、場合によってはスライス内のトラフィック クラスごとに契約帯域幅を強制する粒度の高い入力ポリシング (レート制限) です。強制レートを超えるトラフィックは、直ちにドロップされるか、ドロップ確率の高いトラフィックとしてマークされる可能性があり、輻輳が発生した場合、プロバイダー ネットワーク内のどこかでドロップされる可能性が高くなります。PE ノードの出力方向では、階層型スケジューラー/シェーパーを展開して、スライスごとの保証レートと、各スライス内のトラフィック クラスごとの保証を提供できます。
For managed CEs, edge admission control can be distributed between CEs and PEs, where part of the admission control is implemented on the CE and the other part on the PE.
マネージド CE の場合、エッジ アドミッション コントロールを CE と PE の間で分散できます。アドミッション コントロールの一部は CE に実装され、他の部分は PE に実装されます。
* Coarse-grained resource control at the transit links (non-attachment circuits) in the provider network, using a single NRP (called "base NRP" in Figure 11), spanning the entire provider network. Transit nodes in the provider network do not maintain any state of individual slices. Instead, only a flat (non-hierarchical) QoS model is used on transit links in the provider network, with up to 8 traffic classes. At the PE, traffic flows from multiple Slice Services are mapped to the limited number of traffic classes used on transit links in the provider network.
* プロバイダー ネットワーク全体にわたる単一の NRP (図 11 では「ベース NRP」と呼ばれる) を使用した、プロバイダー ネットワーク内のトランジット リンク (非接続回線) での粗粒度のリソース制御。プロバイダー ネットワーク内のトランジット ノードは、個々のスライスの状態を維持しません。代わりに、プロバイダー ネットワークのトランジット リンクでは、最大 8 つのトラフィック クラスを持つフラット (非階層) QoS モデルのみが使用されます。PE では、複数のスライス サービスからのトラフィック フローが、プロバイダー ネットワークのトランジット リンクで使用される限られた数のトラフィック クラスにマッピングされます。
* Capacity planning/management for efficient usage of provider network resources:
* プロバイダーのネットワーク リソースを効率的に使用するためのキャパシティ プランニング/管理:
The role of capacity planning/management is to ensure the provider network capacity can be utilized without causing any bottlenecks. The methods used here can range from careful network planning that ensures a more or less equal traffic distribution (i.e., equal-cost load balancing) to advanced TE techniques, with or without bandwidth reservations, that force more consistent load distribution, even in non-ECMP-friendly network topologies. See also Section 8 of [RFC9522].
容量計画/管理の役割は、ボトルネックを引き起こすことなくプロバイダーのネットワーク容量を確実に利用できるようにすることです。ここで使用される方法は、ほぼ均等なトラフィック分散 (つまり、等コスト負荷分散) を保証する慎重なネットワーク計画から、帯域幅予約の有無にかかわらず、ECMP に非対応のネットワーク トポロジであっても、より一貫した負荷分散を強制する高度な TE 技術まで多岐にわたります。[RFC9522] のセクション 8 も参照してください。
..............................................
: Base NRP :
+-----:----+ +----:-----+
| PE : | | : PE |
-- -- |- -- -- --| - -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |
N *<---+ | | +--->*
S | | | +-----+ +-----+ | | |
# *<---+ | | P | | P | | +--->*
1 | | | | | | | | | |
== == | +---->o<----->o<--->o<------>o<--->o<----->o<----+ |
N | | | | | | | | | |
S *<---+ | | | | | | +--->*
# | | | +-----+ +-----+ | | |
2 *<---+ | | +--->*
-- -- |- -- -- --|-- -- -- -- -- -- -- -- -- -- -- -- | -- -- -- |
| : | | : |
+-----:----+ +----:-----+
: :
'..............................................'
* SDP, with fine-grained QoS (dedicated resources per network
slice)
o Coarse-grained QoS, with resources shared by all network slices
... Base NRP
-- -- Network slice
Figure 11: Resource Allocation Slicing Model with a Single NRP
図 11: 単一の NRP を使用したリソース割り当てスライシング モデル
The P nodes shown in Figure 11 are routers that do not interface with customer devices. See Section 5.3.1 of [RFC4026].
図 11 に示す P ノードは、顧客のデバイスとインターフェースを持たないルーターです。[RFC4026] のセクション 5.3.1 を参照してください。
This document does not describe in detail how to manage an L2VPN or L3VPN, as this is already well-documented. For example, the reader may refer to [RFC4176] and [RFC6136] for such details.
L2VPN または L3VPN の管理方法についてはすでに十分に文書化されているため、このドキュメントでは詳細には説明しません。たとえば、読者はそのような詳細について [RFC4176] および [RFC6136] を参照することができます。
The 5G control plane relies upon 32-bit S-NSSAIs for slice identification. The S-NSSAI is not visible to the transport domain. So instead, 5G network functions can expose the 5G Network Slices to the transport domain by mapping to explicit Layer 2 or Layer 3 identifiers, such as VLAN-IDs, IP addresses, or Differentiated Services Code Point (DSCP) values. The following subsections list a few handoff methods for slice mapping between customer sites and provider networks.
5G コントロール プレーンは、スライスの識別に 32 ビット S-NSSAI に依存します。S-NSSAI はトランスポート ドメインからは認識されません。したがって、代わりに、5G ネットワーク機能は、VLAN-ID、IP アドレス、Differentiated Services Code Point (DSCP) 値などの明示的なレイヤー 2 またはレイヤー 3 識別子にマッピングすることで、5G ネットワーク スライスをトランスポート ドメインに公開できます。次のサブセクションでは、顧客サイトとプロバイダー ネットワーク間のスライス マッピングのためのいくつかのハンドオフ方法をリストします。
More details about the mapping between 3GPP and RFC 9543 Network Slices is provided in [NS-APP].
3GPP と RFC 9543 ネットワーク スライス間のマッピングの詳細については、[NS-APP] で提供されています。
In this option, the RFC 9543 Network Slice, fulfilling connectivity requirements between NFs that belong to a 5G Network Slice, is represented at an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in Figure 12.
このオプションでは、図 12 に示すように、5G ネットワーク スライスに属する NF 間の接続要件を満たす RFC 9543 ネットワーク スライスが VLAN ID (または一般に QinQ として知られるダブル VLAN ID) によって SDP で表されます。
VLANs representing slices VLANs representing slices
| +-------------------+ | |
| | | | |
+------+ | +-+----+ Provider +---+--+ | +-----+ | +------+
| | v | | | | v | | v | |
| x------x * | | * x------x x.......x |
| NF x------x * PE | | PE * x------xL2/L3x.......x NF |
| x------x * | | * x------x x.......x |
| | | | | | | | | |
+------+ AC +--+---+ Network +---+--+ AC +-----+ +------+
| |
+------------------+
x Logical interface represented by a VLAN on a physical interface
* SDP
Figure 12: Example of 5G Network Slice with VLAN Handoff Providing End-to-End Connectivity
図 12: エンドツーエンド接続を提供する VLAN ハンドオフを備えた 5G ネットワーク スライスの例
Each VLAN represents a distinct logical interface on the ACs and hence provides the possibility to place these logical interfaces in distinct Layer 2 or Layer 3 service instances and implement separation between slices via service instances. Since the 5G interfaces are IP-based interfaces (with the exception of the F2 fronthaul interface, where eCPRI with Ethernet encapsulation is used), this VLAN is typically not transported across the provider network. Typically, it has only local significance at a particular SDP. For simplification, a deployment may rely on the same VLAN identifier for all ACs. However, that may not be always possible. As such, SDPs for the same slice at different locations may use different VLAN values. Therefore, a table mapping VLANs to RFC 9543 Network Slices is maintained for each AC, and the VLAN allocation is coordinated between customer orchestration and provider orchestration.
各 VLAN は AC 上の個別の論理インターフェイスを表すため、これらの論理インターフェイスを個別のレイヤ 2 またはレイヤ 3 サービス インスタンスに配置し、サービス インスタンスを介してスライス間の分離を実装する可能性を提供します。5G インターフェイスは IP ベースのインターフェイスであるため (イーサネット カプセル化による eCPRI が使用される F2 フロントホール インターフェイスを除く)、この VLAN は通常、プロバイダー ネットワークを介して転送されません。通常、これは特定の SDP でのみローカルな意味を持ちます。簡略化するために、展開はすべての AC に対して同じ VLAN 識別子に依存する場合があります。ただし、それが常に可能であるとは限りません。したがって、異なる場所にある同じスライスの SDP は異なる VLAN 値を使用する可能性があります。したがって、VLAN を RFC 9543 ネットワーク スライスにマッピングするテーブルが AC ごとに維持され、VLAN の割り当てが顧客オーケストレーションとプロバイダー オーケストレーションの間で調整されます。
While VLAN handoff is simple for NFs, it adds complexity at the provider network because of the requirement of maintaining mapping tables for each SDP and performing a configuration task for new VLANs and IP subnet for every slice on every AC.
VLAN ハンドオフは NF にとっては簡単ですが、各 SDP のマッピング テーブルを維持し、すべての AC 上のすべてのスライスに対して新しい VLAN と IP サブネットの構成タスクを実行する必要があるため、プロバイダー ネットワークでは複雑さが増します。
In this option, an explicit mapping between source/destination IP addresses and a slice's specific S-NSSAI is used. The mapping can have either local (e.g., pertaining to a single NF attachment) or global TN significance. The mapping can be realized in multiple ways, including (but not limited to):
このオプションでは、送信元/宛先 IP アドレスとスライスの特定の S-NSSAI 間の明示的なマッピングが使用されます。マッピングは、ローカル (たとえば、単一の NF アタッチメントに関係する) またはグローバル TN の重要性を持つことができます。マッピングは、次のような複数の方法で実現できます (ただし、これらに限定されません)。
* S-NSSAI to a dedicated IP address for each NF
* S-NSSAI から各 NF の専用 IP アドレスへ
* S-NSSAI to a pool of IP addresses for global TN deployment
* グローバル TN 導入のための IP アドレスのプールへの S-NSSAI
* S-NSSAI to a subset of bits of an IP address
* S-NSSAI から IP アドレスのビットのサブセットへ
* S-NSSAI to a DSCP value
* S-NSSAI から DSCP 値へ
* S-NSSAI to SRv6 Locators or Segment Identifiers (SIDs) [RFC8986]
* S-NSSAI から SRv6 ロケーターまたはセグメント識別子 (SID) [RFC8986]
* Use of a deterministic algorithm to map S-NSSAI to an IP subnet, prefix, or pools. For example, adaptations to the algorithm defined in [RFC7422] may be considered.
* S-NSSAI を IP サブネット、プレフィックス、またはプールにマッピングするための決定論的アルゴリズムの使用。たとえば、[RFC7422] で定義されているアルゴリズムへの適応が考慮される場合があります。
Mapping S-NSSAIs to IP addresses makes IP addresses an identifier for slice-related policy enforcement in the Transport Network (e.g., differentiated services, traffic steering, bandwidth allocation, security policies, and monitoring).
S-NSSAI を IP アドレスにマッピングすると、IP アドレスがトランスポート ネットワークでのスライス関連のポリシー適用 (差別化されたサービス、トラフィック ステアリング、帯域幅割り当て、セキュリティ ポリシー、モニタリングなど) の識別子になります。
One example of the IP handoff realization is the arrangement in which the slices in the TN domain are instantiated using IP tunnels (e.g., IPsec or GTP-U tunnels) established between NFs, as depicted in Figure 13. The transport for a single 5G Network Slice might be constructed with multiple such tunnels, since a typical 5G Network Slice contains many NFs, especially DUs and CUs. If a shared NF (i.e., an NF that serves multiple slices, such as a shared DU) is deployed, multiple tunnels from the shared NF are established, each tunnel representing a single slice.
IP ハンドオフ実現の一例は、図 13 に示すように、NF 間で確立された IP トンネル (IPsec または GTP-U トンネルなど) を使用して TN ドメイン内のスライスがインスタンス化される構成です。典型的な 5G ネットワーク スライスには多くの NF、特に DU と CU が含まれるため、単一の 5G ネットワーク スライスのトランスポートは、複数のそのようなトンネルで構築される場合があります。共有 NF (共有 DU など、複数のスライスにサービスを提供する NF) が展開される場合、共有 NF からの複数のトンネルが確立され、各トンネルは単一のスライスを表します。
Tunnels representing slices
+------------------+ |
| | |
+------+ +-+---+ Provider +---+-+ +-----+ | +------+
| | | | | | | | v | |
| o============*================*==========================o |
| NF +-------+ PE | | PE +-------+L2/L3+.......+ NF |
| o============*================*==========================o |
| | | | | | | | | |
+------+ AC +-+---+ Network +---+-+ AC +-----+ +------+
| |
+------------------+
o Tunnel (IPsec, GTP-U, etc.) termination point
* SDP
Figure 13: Example of 5G Network Slice with IP Handoff Providing End-to-End Connectivity
図 13: エンドツーエンド接続を提供する IP ハンドオフを備えた 5G ネットワーク スライスの例
As opposed to the VLAN handoff case (Section 4.1), there is no logical interface representing a slice on the PE; hence, all slices are handled within a single service instance. The IP and VLAN handoffs are not mutually exclusive but instead could be used concurrently. Since the TN doesn't recognize S-NSSAIs, a mapping table similar to the VLAN handoff solution is needed (Section 4.1).
VLAN ハンドオフの場合 (セクション 4.1) とは対照的に、PE 上にはスライスを表す論理インターフェイスはありません。したがって、すべてのスライスは単一のサービス インスタンス内で処理されます。IP ハンドオフと VLAN ハンドオフは相互に排他的ではなく、同時に使用できます。TN は S-NSSAI を認識しないため、VLAN ハンドオフ ソリューションと同様のマッピング テーブルが必要です (セクション 4.1)。
The mapping table can be simplified if, for example, IPv6 addressing is used to address NFs. An IPv6 address is a 128-bit field, while the S-NSSAI is a 32-bit field: The Slice/Service Type (SST) is 8 bits, and the Slice Differentiator (SD) is 24 bits. Out of the 128 bits of the IPv6 address, 32 bits may be used to encode the S-NSSAI, which makes an IP-to-slice mapping table unnecessary.
たとえば、IPv6 アドレス指定を使用して NF をアドレス指定する場合、マッピング テーブルを簡素化できます。IPv6 アドレスは 128 ビット フィールドですが、S-NSSAI は 32 ビット フィールドです。スライス/サービス タイプ (SST) は 8 ビット、スライス区別子 (SD) は 24 ビットです。IPv6 アドレスの 128 ビットのうち、32 ビットを S-NSSAI のエンコードに使用できるため、IP からスライスへのマッピング テーブルが不要になります。
The S-NSSAI/IPv6 mapping is a local IPv6 address allocation method to NFs not disclosed to on-path nodes. IP forwarding is not altered by this method and is still achieved following BCP 198 [RFC7608]. Intermediary TN nodes are not required to associate any additional semantic with the IPv6 address.
S-NSSAI/IPv6 マッピングは、パス上のノードに公開されない NF へのローカル IPv6 アドレス割り当て方法です。IP 転送はこの方法では変更されず、引き続き BCP 198 [RFC7608] に従って実現されます。中間 TN ノードは、追加のセマンティクスを IPv6 アドレスに関連付ける必要はありません。
However, operators using such mapping methods should be aware of the implications of any change of S-NSSAI on the IPv6 addressing plans. For example, modifications of the S-NSSAIs in use will require updating the IP addresses used by NFs involved in the associated slices.
ただし、このようなマッピング方法を使用する通信事業者は、S-NSSAI の変更が IPv6 アドレス計画に与える影響を認識しておく必要があります。たとえば、使用中の S-NSSAI を変更するには、関連するスライスに関与する NF によって使用される IP アドレスを更新する必要があります。
An example of a local IPv6 addressing plan for NFs is provided in Appendix A.
NF のローカル IPv6 アドレス指定計画の例は、付録 A に記載されています。
In this option, the service instances representing different slices are created directly on the NF, or within the customer site hosting the NF, and attached to the provider network. Therefore, the packet is encapsulated outside the provider network with MPLS encapsulation or MPLS-in-UDP encapsulation [RFC7510], depending on the capability of the customer site, with the service label depicting the slice.
このオプションでは、さまざまなスライスを表すサービス インスタンスが NF 上に直接作成されるか、NF をホストする顧客サイト内に作成され、プロバイダー ネットワークに接続されます。したがって、パケットは、顧客サイトの機能に応じて、スライスを表すサービス ラベルとともに MPLS カプセル化または MPLS-in-UDP カプセル化 [RFC7510] を使用してプロバイダー ネットワークの外側でカプセル化されます。
There are three major methods (based upon Section 10 of [RFC4364]) for interconnecting MPLS services over multiple service domains:
複数のサービス ドメイン上で MPLS サービスを相互接続するには、([RFC4364] のセクション 10 に基づく) 3 つの主な方法があります。
Option A (Section 4.3.1):
オプション A (セクション 4.3.1):
VRF-to-VRF connections.
VRF 間の接続。
Option B (Section 4.3.2):
オプション B (セクション 4.3.2):
Redistribution of labeled VPN routes with next-hop change at domain boundaries.
ドメイン境界でのネクストホップ変更によるラベル付き VPN ルートの再配布。
Option C (Section 4.3.3):
オプション C (セクション 4.3.3):
Redistribution of labeled VPN routes without next-hop change and redistribution of labeled transport routes with next-hop change at domain boundaries.
ネクストホップを変更しないラベル付き VPN ルートの再配布と、ドメイン境界でネクストホップを変更するラベル付きトランスポート ルートの再配布。
Figure 14 illustrates the use of service-aware CE (Section 3.3.2) for the deployment discussed in Sections 4.3.2 and 4.3.3.
図 14 は、セクション 4.3.2 および 4.3.3 で説明した展開におけるサービス認識 CE (セクション 3.3.2) の使用を示しています。
+--------------+ +--------------+
| Customer | | Provider |
| Site | | Network |
| | | |
| | | |
| | <------MP-BGP-----> | |
| +--+-+ +-+--+ |
| | | MPLS-based AC | | |
| | CE +------------------+ PE | |
| +--+----+--+ | | |
| | VRF foo | +-+--+ |
+--------+----------+ +--------------+
Figure 14: Example of MPLS-Based Attachment Circuit
図 14: MPLS ベースの接続回路の例
This option is based on the VLAN handoff, described in Section 4.1; it is not based on the MPLS label handoff.
このオプションは、セクション 4.1 で説明されている VLAN ハンドオフに基づいています。MPLS ラベル ハンドオフには基づいていません。
In this option, L3VPN service instances are instantiated outside the provider network. These L3VPN service instances are instantiated in the customer site, which could be, for example, either on the compute that hosts mobile NFs (Figure 15, left-hand side) or within the DC/ cloud infrastructure itself (e.g., on the top of the rack or leaf switch within cloud IP fabric (Figure 15, right-hand side)). On the AC connected to a PE, packets are already MPLS encapsulated (or MPLS-in-UDP/MPLS-in-IP encapsulated, if cloud or compute infrastructure don't support MPLS encapsulation). Therefore, the PE uses neither a VLAN nor an IP address for slice identification at the SDP but instead uses the MPLS label.
このオプションでは、L3VPN サービス インスタンスがプロバイダー ネットワークの外部でインスタンス化されます。これらの L3VPN サービス インスタンスは、顧客サイトでインスタンス化されます。これは、たとえば、モバイル NF をホストするコンピューティング上 (図 15、左側)、または DC/クラウド インフラストラクチャ自体内 (たとえば、クラウド IP ファブリック内のラックまたはリーフ スイッチの上部 (図 15、右側)) のいずれかになります。PE に接続されている AC では、パケットはすでに MPLS カプセル化されています (クラウドまたはコンピューティング インフラストラクチャが MPLS カプセル化をサポートしていない場合は、MPLS-in-UDP/MPLS-in-IP カプセル化されています)。したがって、PE は SDP でのスライス識別に VLAN も IP アドレスも使用せず、代わりに MPLS ラベルを使用します。
<------ <------ <------
BGP VPN BGP VPN BGP VPN
COM=1, L=A" COM=1, L=A' COM=1, L=A
COM=2, L=B" COM=2, L=B' COM=2, L=B
COM=3, L=C" COM=3, L=C' COM=3, L=C
<-----------><-------------><------------>
nhs nhs nhs nhs
VLANs
service instances service instances representing
representing slices representing slices slices
| | |
+---+ | +-------------+ +-|--------|----------+
| | | | Provider | | | | |
| +-+--v-+ +--+--+ +--+--+ +-+-v----+ v +-----+ |
| | # | | * | | * | | #<><>x......x | |
| | NF # +------+ * PE| |PE * +------+ #<><>x......x NF | |
| | # | AC | * | | * | AC | #<><>x......x | |
| +--+---+ +--+--+ +--+--+ +-+------+ +-----+ |
| CS1| | Network | | L2/L3 CS2 |
+----+ +-------------+ +---------------------+
x Logical interface represented by a VLAN on a physical interface
# Service instances (with unique MPLS labels)
* SDP
Figure 15: Example of MPLS Handoff with Option B
図 15: オプション B を使用した MPLS ハンドオフの例
MPLS labels are allocated dynamically in Option B deployments, where, at the domain boundaries, service prefixes are reflected with next-hop self (nhs), and a new label is dynamically allocated, as shown in 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 network edge, the PE needs to determine which label represents which slice. In the BGP control plane, when exchanging service prefixes over an AC, each slice might be represented by a unique BGP community, so tracking label assignment to the slice might be possible. For example, in Figure 15, for the slice identified with COM=1, the PE advertises a dynamically allocated label A". Since, based on the community, the label-to-slice association is known, the PE can use this dynamically allocated label A" to identify incoming packets as belonging to "slice 1" and execute appropriate edge per-hop behavior.
MPLS ラベルはオプション B 展開で動的に割り当てられます。図 15 に示すように、ドメイン境界でサービス プレフィックスがネクスト ホップ セルフ (nhs) に反映され、新しいラベルが動的に割り当てられます (たとえば、最初に示されたスライスのラベル A、A'、および A")。したがって、プロバイダー ネットワーク エッジでのスライス固有のホップごとの動作について、PE はどのラベルがどのスライスを表すかを判断する必要があります。BGP コントロール プレーンでは、サービスを交換するときに、たとえば、図 15 では、COM=1 で識別されるスライスに対して、PE が動的に割り当てられたラベル A" をアドバタイズします。コミュニティに基づいてラベルとスライスの関連付けがわかっているため、PE はこの動的に割り当てられたラベル A" を使用して、受信パケットが「スライス 1」に属するものとして識別し、ホップごとの適切なエッジ動作を実行できます。
It is worth noting that slice identification in the BGP control plane might be with per-prefix granularity. In the extreme case, each prefix can have a different community representing a different slice. Depending on the business requirements, each slice could be represented by a different service instance as outlined in Figure 15. In that case, the route target extended community (Section 4 of [RFC4360]) might be used as a slice differentiator. In other deployments, all prefixes (representing different slices) might be handled by a single "mobile" service instance, and some other BGP attribute (e.g., a standard community [RFC1997]) might be used for slice differentiation. There could also be a deployment option that groups multiple slices together into a single service instance, resulting in a handful of service instances. In any case, fine-grained per-hop behavior at the edge of provider network is possible.
BGP コントロール プレーンでのスライス識別はプレフィックスごとの粒度で行われる可能性があることに注意してください。極端な場合には、各プレフィックスが異なるスライスを表す異なるコミュニティを持つ可能性があります。ビジネス要件に応じて、図 15 に示すように、各スライスを異なるサービス インスタンスで表すことができます。その場合、ルート ターゲット拡張コミュニティ ([RFC4360] のセクション 4) がスライスの差別化要素として使用される可能性があります。他の展開では、すべてのプレフィックス (異なるスライスを表す) が単一の「モバイル」サービス インスタンスによって処理され、他の BGP 属性 (標準コミュニティ [RFC1997] など) がスライスの区別に使用される可能性があります。複数のスライスを 1 つのサービス インスタンスにグループ化して、少数のサービス インスタンスを作成するデプロイ オプションもある可能性があります。いずれの場合も、プロバイダー ネットワークのエッジでのホップごとのきめ細かい動作が可能です。
Option B relies upon exchanging service prefixes between customer sites and the provider network. This may lead to scaling challenges in large-scale 5G deployments as the PE node needs to carry all service prefixes. To alleviate this scaling challenge, in Option C, service prefixes are exchanged between customer sites only. In doing so, the provider network is offloaded from carrying, propagating, and programming appropriate forwarding entries for service prefixes.
オプション B は、顧客サイトとプロバイダー ネットワークの間でサービス プレフィックスを交換することに依存します。PE ノードはすべてのサービス プレフィックスを伝送する必要があるため、大規模な 5G 導入ではスケーリングの課題が発生する可能性があります。このスケーリングの課題を軽減するために、オプション C では、サービス プレフィックスは顧客サイト間でのみ交換されます。そうすることで、プロバイダー ネットワークは、サービス プレフィックスの適切な転送エントリの搬送、伝播、プログラミングから解放されます。
Option C relies upon exchanging service prefixes via multi-hop BGP sessions between customer sites, without changing the NEXT_HOP BGP attribute. Additionally, IPv4/IPv6 labeled unicast (SAFI-4) host routes, used as NEXT_HOP for service prefixes, are exchanged via direct single-hop BGP sessions between adjacent nodes in a customer site and a provider network, as depicted in Figure 16. As a result, a node in a customer site performs hierarchical next-hop resolution.
オプション C は、NEXT_HOP BGP 属性を変更せずに、顧客サイト間のマルチホップ BGP セッションを介してサービス プレフィックスを交換することに依存します。さらに、サービス プレフィックスの NEXT_HOP として使用される IPv4/IPv6 ラベル付きユニキャスト (SAFI-4) ホスト ルートは、図 16 に示すように、顧客サイトの隣接ノードとプロバイダー ネットワークの間で直接シングルホップ BGP セッションを介して交換されます。その結果、顧客サイトのノードは階層的なネクストホップ解決を実行します。
<----------------------------------------
BGP VPN
COM=1, L=A, NEXT_HOP=CS2
COM=2, L=B, NEXT_HOP=CS2
COM=3, L=C, NEXT_HOP=CS2
<--------------------------------------->
<------ <------ <------
BGP LU BGP LU BGP LU
CS2, L=X" CS2, L=X' CS2, L=X
<-----------><--------------><---------->
nhs nhs nhs nhs
VLANs
service instances service instances representing
representing slices representing slices slices
| | |
+---+ | +-------------+ +-|--------|----------+
| | | | Provider | | | | |
| +-+-v-+ +--+--+ +--+--+ +-+-v----+ v +-----+ |
| | # | | * | | * | | #<><>x......x | |
| |NF # +-------+ * PE| |PE * +------+ #<><>x......x NF | |
| | # | AC | * | | * | AC | #<><>x......x | |
| +--+--+ +--+--+ +--+--+ +-+------+ +-----+ |
| CS1| | Network | | L2/L3 CS2 |
+----+ +-------------+ +---------------------+
x Logical interface represented by a VLAN on a physical interface
# Service instances (with unique MPLS label)
* SDP
Figure 16: Example of MPLS Handoff with Option C
図 16: オプション C を使用した MPLS ハンドオフの例
This architecture requires an end-to-end Label Switched Path (LSP) leading from a packet's ingress node inside one customer site to its egress inside another customer site, through a provider network. Hence, at the domain (customer site and provider network) boundaries, the NEXT_HOP attribute for IPv4/IPv6 labeled unicast needs to be modified to next-hop self (nhs), which results in a new IPv4/IPv6 labeled unicast label allocation. Appropriate forwarding entries for label swaps for IPv4/IPv6 labeled unicast labels are programmed in the data plane. There is no additional "labeled transport" protocol on the AC (e.g., no LDP, RSVP, or SR).
このアーキテクチャには、プロバイダー ネットワークを介して、ある顧客サイト内のパケットの入口ノードから別の顧客サイト内の出口までつながる、エンドツーエンドのラベル スイッチ パス (LSP) が必要です。したがって、ドメイン (顧客サイトとプロバイダー ネットワーク) の境界では、IPv4/IPv6 ラベル付きユニキャストの NEXT_HOP 属性をネクストホップ自己 (nhs) に変更する必要があり、その結果、新しい IPv4/IPv6 ラベル付きユニキャスト ラベルが割り当てられます。IPv4/IPv6 ラベル付きユニキャスト ラベルのラベル スワップに適切な転送エントリがデータ プレーンにプログラムされています。AC には追加の「ラベル付きトランスポート」プロトコルはありません (LDP、RSVP、SR など)。
Packets are transmitted over the AC with the IPv4/IPv6 labeled unicast as the top label, with the service label deeper in the label stack. In Option C, the service label is not used for forwarding lookup on the PE. This significantly lowers the scaling pressure on PEs, as PEs need to program forwarding entries only for IPv4/IPv6 labeled unicast host routes, which are used as NEXT_HOP for service prefixes. Also, since one IPv4/IPv6 labeled unicast host route represents one customer site, regardless of the number of slices in the customer site, the number of forwarding entries on a PE is considerably reduced.
パケットは、ユニキャストとラベル付けされた IPv4/IPv6 を最上位のラベルとして AC 経由で送信され、サービス ラベルはラベル スタックのさらに奥にあります。オプション C では、サービス ラベルは PE での転送ルックアップに使用されません。これにより、PE はサービス プレフィックスの NEXT_HOP として使用される IPv4/IPv6 ラベル付きユニキャスト ホスト ルートに対してのみ転送エントリをプログラムする必要があるため、PE に対するスケーリング プレッシャーが大幅に軽減されます。また、1 つの IPv4/IPv6 ラベル付きユニキャスト ホスト ルートが 1 つの顧客サイトを表すため、顧客サイト内のスライスの数に関係なく、PE 上の転送エントリの数が大幅に減少します。
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 which label in the packet represents which slice. This can be achieved, for example, by allocating non-overlapping service label ranges for each slice and using those ranges for slice identification purposes on the PE.
セクション 3.7 で詳しく説明されているように、プロバイダー ネットワーク エッジでのスライス固有のホップごとの動作については、PE はパケット内のどのラベルがどのスライスを表しているかを判断する必要があります。これは、たとえば、各スライスに重複しないサービス ラベル範囲を割り当て、それらの範囲を PE でのスライス識別目的に使用することによって実現できます。
The resources are managed via various QoS policies deployed in the network. QoS mapping models to support 5G slicing connectivity implemented over a packet switched provider network use two layers of QoS, which are discussed in the following subsections.
リソースは、ネットワークに導入されたさまざまな QoS ポリシーによって管理されます。パケット交換プロバイダー ネットワーク上に実装された 5G スライシング接続をサポートする QoS マッピング モデルは、次のサブセクションで説明する 2 つの QoS 層を使用します。
QoS treatment is indicated in the 5G QoS layer by the 5G QoS Indicator (5QI), as defined in [TS-23.501]. The 5QI is an identifier that is used as a reference to 5G QoS characteristics (e.g., scheduling weights, admission thresholds, queue management thresholds, and link-layer protocol configuration) in the RAN domain. Given that 5QI applies to the RAN domain, it is not visible to the provider network. Therefore, if 5QI-aware treatment is desired in the provider network, 5G network functions might set DSCP with a value representing 5QI so that differentiated treatment can be implemented in the provider network as well. Based on these DSCP values, very granular QoS enforcement might be implemented at the SDP of each provider network segment used to construct transport for given 5G Network Slice.
QoS 処理は、[TS-23.501] で定義されているように、5G QoS インジケーター (5QI) によって 5G QoS レイヤーで示されます。5QI は、RAN ドメイン内の 5G QoS 特性 (スケジューリング重み、アドミッションしきい値、キュー管理しきい値、リンク層プロトコル構成など) への参照として使用される識別子です。5QI が RAN ドメインに適用されるとすると、プロバイダー ネットワークには認識されません。したがって、プロバイダー ネットワークで 5QI を意識した処理が必要な場合、5G ネットワーク機能は、プロバイダー ネットワークでも差別化された処理を実装できるように、5QI を表す値で DSCP を設定する可能性があります。これらの DSCP 値に基づいて、特定の 5G ネットワーク スライスのトランスポートを構築するために使用される各プロバイダー ネットワーク セグメントの SDP で、非常に詳細な QoS 強制が実装される可能性があります。
The exact mapping between 5QI and DSCP is out of scope for this document. Mapping recommendations are documented, e.g., in [MAPPING].
5QI と DSCP の間の正確なマッピングは、このドキュメントの範囲外です。マッピングの推奨事項は、[MAPPING] などに文書化されています。
Each Slice Service might have flows with multiple 5QIs. 5QIs (or, more precisely, corresponding DSCP values) are visible to the provider network at SDPs (i.e., at the edge of the provider network).
各スライス サービスには、複数の 5QI を含むフローが含まれる場合があります。5QI (より正確には、対応する DSCP 値) は、SDP (つまり、プロバイダー ネットワークのエッジ) のプロバイダー ネットワークから見えます。
In this document, this layer of QoS is referred to as "5G QoS Class" ("5G QoS" in short) or "5G DSCP".
本書では、この QoS 層を「5G QoS クラス」（略して「5G QoS」）または「5G DSCP」と呼びます。
Control of the TN resources and traffic scheduling/prioritization on provider network transit links are based on a flat (non-hierarchical) QoS model in this network slice realization. That is, RFC 9543 Network Slices are assigned dedicated resources (e.g., QoS queues) at the edge of the provider network (at SDPs), while all RFC 9543 Network Slices are sharing resources (sharing QoS queues) on the transit links of the provider network. Typical router hardware can support up to 8 traffic queues per port; therefore, this document assumes support for 8 traffic queues per port in general.
プロバイダー ネットワークの中継リンクでの TN リソースの制御とトラフィックのスケジューリング/優先順位付けは、このネットワーク スライスの実現におけるフラット (非階層) QoS モデルに基づいています。つまり、RFC 9543 ネットワーク スライスにはプロバイダー ネットワークのエッジ (SDP で) の専用リソース (QoS キューなど) が割り当てられますが、すべての RFC 9543 ネットワーク スライスはプロバイダー ネットワークのトランジット リンク上でリソースを共有しています (QoS キューを共有しています)。一般的なルーター ハードウェアは、ポートごとに最大 8 つのトラフィック キューをサポートできます。したがって、このドキュメントでは、一般的にポートごとに 8 つのトラフィック キューがサポートされることを前提としています。
At this layer, QoS treatment is indicated by a QoS indicator specific to the encapsulation used in the provider network. Such an indicator may be a DSCP or MPLS Traffic Class (TC). This layer of QoS is referred to as "TN QoS Class" ("TN QoS" for short) in this document.
この層では、QoS 処理は、プロバイダー ネットワークで使用されるカプセル化に固有の QoS インジケーターによって示されます。このようなインジケータは、DSCP または MPLS トラフィック クラス (TC) である場合があります。この QoS 層は、本書では「TN QoS クラス」(略して「TN QoS」) と呼ばれます。
While 5QI might be exposed to the provider network via the DSCP value (corresponding to a specific 5QI value) set in the IP packet generated by NFs, some 5G deployments might use 5QI in the RAN domain only, without requesting per-5QI differentiated treatment from the provider network. This might be due to an NF limitation (e.g., no capability to set DSCP), or it might simply depend on the overall slicing deployment model. The O-RAN Alliance, for example, defines a phased approach to the slicing, with initial phases utilizing only per-slice, but not per-5QI, differentiated treatment in the TN domain (see Annex F of [O-RAN.WG9.XPSAAS]).
5QI は、NF によって生成された IP パケットに設定された DSCP 値 (特定の 5QI 値に対応) を介してプロバイダー ネットワークに公開される可能性がありますが、一部の 5G 導入では、プロバイダー ネットワークに 5QI ごとの差別化された処理を要求せずに、RAN ドメインでのみ 5QI を使用する場合があります。これは、NF の制限 (DSCP を設定できないなど) が原因である可能性がありますが、単に全体的なスライシング展開モデルに依存している可能性もあります。たとえば、O-RAN Alliance は、スライシングに対する段階的アプローチを定義しており、初期段階では TN ドメインでの差別化された処理ではなく、スライスごとのみを利用し、5QI ごとには利用しません ([O-RAN.WG9.XPSAAS] の付録 F を参照)。
Therefore, from a QoS perspective, the 5G slicing connectivity realization defines two high-level realization models for slicing in the TN domain: a 5QI-unaware model and a 5QI-aware model. Both slicing models in the TN domain could be used concurrently within the same 5G Network Slice. For example, the TN segment for 5G midhaul (F1-U interface) might be 5QI-aware, while at the same time, the TN segment for 5G backhaul (N3 interface) might follow the 5QI-unaware model.
したがって、QoS の観点から見ると、5G スライシング接続の実現では、TN ドメインでのスライシングのための 2 つの高レベルの実現モデル、つまり 5QI 非対応モデルと 5QI 対応モデルが定義されます。TN ドメインの両方のスライシング モデルは、同じ 5G ネットワーク スライス内で同時に使用できます。たとえば、5G ミッドホール (F1-U インターフェイス) の TN セグメントは 5QI 対応であると同時に、5G バックホール (N3 インターフェイス) の TN セグメントは 5QI 非対応モデルに従う場合があります。
These models are further elaborated in the following two subsections.
これらのモデルについては、次の 2 つのサブセクションでさらに詳しく説明します。
In the 5QI-unaware model, the DSCP values in the packets received from NF at SDP are ignored. In the provider network, there is no QoS differentiation at the 5G QoS Class level. The entire RFC 9543 Network Slice is mapped to a single TN QoS Class and therefore to a single QoS queue on the routers in the provider network. With a low number of deployed 5G Network Slices (for example, only two 5G Network Slices: eMBB and MIoT), it is possible to dedicate a separate QoS queue for each slice on transit routers in the provider network. However, with the introduction of private/enterprises slices, as the number of 5G Network Slices (and thus the corresponding RFC 9543 Network Slices) increases, a single QoS queue on transit links in the provider network serves multiple slices with similar characteristics. QoS enforcement on transit links is fully coarse-grained (single NRP, sharing resources among all RFC 9543 Network Slices), as displayed in Figure 17.
5QI 非対応モデルでは、SDP で NF から受信したパケット内の DSCP 値は無視されます。プロバイダー ネットワークでは、5G QoS クラス レベルでの QoS の区別はありません。RFC 9543 ネットワーク スライス全体は単一の TN QoS クラスにマッピングされ、したがってプロバイダー ネットワーク内のルーター上の単一の QoS キューにマッピングされます。導入された 5G ネットワーク スライスの数が少ない場合 (たとえば、eMBB と MIoT の 5G ネットワーク スライスが 2 つだけ)、プロバイダー ネットワーク内のトランジット ルーター上のスライスごとに個別の QoS キューを専用にすることができます。ただし、プライベート/エンタープライズ スライスの導入により、5G ネットワーク スライス (および対応する RFC 9543 ネットワーク スライス) の数が増加するにつれて、プロバイダー ネットワークのトランジット リンク上の単一の QoS キューが、同様の特性を持つ複数のスライスにサービスを提供します。図 17 に示すように、トランジット リンクに対する QoS の適用は完全に粗粒化されています (単一の NRP、すべての RFC 9543 ネットワーク スライス間でリソースを共有)。
+----------------------------------------------------------------+
+-------------------. PE |
| .--------------+ | |
| | SDP | | .------------------------------+
| | +----------+ | | | Transit link |
| | | NS 1 +-------------+ | .------------------------. |
| | +----------+ | | +-----|--> TN QoS Class 1 | |
| '--------------' | | | '------------------------' |
| .--------------+ | | | .------------------------. |
| | SDP | | | | | TN QoS Class 2 | |
| | +----------+ | | | | '------------------------' |
| | | NS 2 +---------+ | | .------------------------. |
| | +----------+ | | | | | | TN QoS Class 3 | |
| '--------------' | | | | '------------------------' |
| .--------------+ | | | | .------------------------. |
| | SDP | | +---)-----|--> TN QoS Class 4 | |
| | +----------+ | | | | '------------------------' |
| | | NS 3 +-------------+ | .------------------------. |
| | +----------+ | | +---------|--> TN QoS Class 5 | |
| '--------------' | | | '------------------------' |
| .--------------+ | | | .------------------------. |
| | SDP | | | | | TN QoS Class 6 | |
| | +----------+ | | | | '------------------------' |
| | | NS 4 +---------+ | .------------------------. |
| | +----------+ | | | | | TN QoS Class 7 | |
| '--------------' | | | '------------------------' |
| .--------------+ | | | .------------------------. |
| | SDP | | | | | TN QoS Class 8 | |
| | +----------+ | | | | '------------------------' |
| | | NS 5 +---------+ | Max 8 TN Classes |
| | +----------+ | | '------------------------------+
| '--------------' | |
+-------------------' |
+----------------------------------------------------------------+
Fine-grained QoS enforcement Coarse-grained QoS enforcement
(dedicated resources per (resources shared by multiple
RFC 9543 Network Slice) RFC 9543 Network Slices)
Figure 17: Mapping of Slice to TN QoS (5QI-Unaware Model)
図 17: TN QoS へのスライスのマッピング (5QI 非認識モデル)
When the IP traffic is handed over at the SDP from the AC to the provider network, the PE encapsulates the traffic into MPLS (if MPLS transport is used in the provider network) or IPv6, optionally with some additional headers (if SRv6 transport is used in the provider network), and sends out the packets on the provider network transit link.
IP トラフィックが SDP で AC からプロバイダー ネットワークにハンドオーバーされると、PE はトラフィックを MPLS (プロバイダー ネットワークで MPLS トランスポートが使用されている場合) または IPv6 にカプセル化し、オプションでいくつかの追加ヘッダー (プロバイダー ネットワークで SRv6 トランスポートが使用されている場合) を付けて、プロバイダー ネットワークの中継リンク上にパケットを送信します。
The original IP header retains the DSCP marking (which is ignored in the 5QI-unaware model), while the new header (MPLS or IPv6) carries the QoS marking (MPLS Traffic Class bits for MPLS encapsulation or DSCP for SRv6/IPv6 encapsulation) related to the TN Class of Service (CoS). Based on the TN CoS marking, per-hop behavior for all RFC 9543 Network Slices is executed on provider network transit links. Provider network transit routers do not evaluate the original IP header for QoS-related decisions. This model is outlined in Figure 18 for MPLS encapsulation and in Figure 19 for SRv6 encapsulation.
元の IP ヘッダーは DSCP マーキング (5QI 非対応モデルでは無視されます) を保持しますが、新しいヘッダー (MPLS または IPv6) は、TN サービス クラス (CoS) に関連する QoS マーキング (MPLS カプセル化の MPLS トラフィック クラス ビット、または SRv6/IPv6 カプセル化の DSCP) を伝送します。TN CoS マーキングに基づいて、すべての RFC 9543 ネットワーク スライスのホップごとの動作がプロバイダー ネットワークの中継リンク上で実行されます。プロバイダーのネットワーク中継ルーターは、QoS 関連の決定のために元の IP ヘッダーを評価しません。このモデルの概要を MPLS カプセル化については図 18 に、SRv6 カプセル化については図 19 に示します。
+--------------+
| MPLS Header |
+-----+-----+ |
|Label|TN TC| |
+--------------+ - - - - - - - - +-----+-----+--+
| IP Header | |\ | IP Header |
| +-------+ | \ | +-------+
| |5G DSCP|---------+ \ | |5G DSCP|
+------+-------+ \ +------+-------+
| | \ | |
| | \ | |
| | | |
| Payload | / | Payload |
|(GTP-U/IPsec) | / |(GTP-U/IPsec) |
| | / | |
| |---------+ / | |
| | | / | |
| | |/ | |
+--------------+ - - - - - - - - +--------------+
Figure 18: QoS with MPLS Encapsulation
図 18: MPLS カプセル化による QoS
+--------------+
| IPv6 Header |
| +-------+
| |TN DSCP|
+------+-------+
: Optional :
: IPv6 :
: Headers :
+--------------+ - - - - - - - - +-----+-----+--+
| IP Header | |\ | IP Header |
| +-------+ | \ | +-------+
| |5G DSCP|---------+ \ | |5G DSCP|
+------+-------+ \ +------+-------+
| | \ | |
| | \ | |
| | | |
| Payload | / | Payload |
|(GTP-U/IPsec) | / |(GTP-U/IPsec) |
| | / | |
| |---------+ / | |
| | | / | |
| | |/ | |
+--------------+ - - - - - - - - +--------------+
Figure 19: QoS with SRv6 Encapsulation
図 19: SRv6 カプセル化による QoS
From a QoS perspective, both options are similar. However, there is one difference between the two options. The MPLS TC is only 3 bits (8 possible combinations), while DSCP is 6 bits (64 possible combinations). Hence, SRv6 provides more flexibility for TN CoS design, especially in combination with soft policing with in-profile and out-of-profile traffic, as discussed in Section 5.2.1.1.
From a QoS perspective, both options are similar.However, there is one difference between the two options.The MPLS TC is only 3 bits (8 possible combinations), while DSCP is 6 bits (64 possible combinations).したがって、SRv6 は、セクション 5.2.1.1 で説明したように、特にプロファイル内およびプロファイル外のトラフィックによるソフト ポリシングと組み合わせた場合に、TN CoS 設計の柔軟性を高めます。
Provider network edge resources are controlled in a fine-grained manner, with dedicated resource allocation for each RFC 9543 Network Slice. Resource control and enforcement happens at each SDP in two directions: inbound and outbound.
プロバイダーのネットワーク エッジ リソースは、RFC 9543 ネットワーク スライスごとに専用のリソース割り当てを使用して、きめ細かい方法で制御されます。リソースの制御と強制は、各 SDP でインバウンドとアウトバウンドの 2 方向で行われます。
The main aspect of inbound provider network edge resource control is per-slice traffic volume enforcement. This kind of enforcement is often called "admission control" or "traffic conditioning". The goal of this inbound enforcement is to ensure that the traffic above the contracted rate is dropped or deprioritized, depending on the business rules, right at the edge of provider network. This, combined with appropriate network capacity planning/management (Section 7), is required to ensure proper isolation between slices in a scalable manner. As a result, traffic of one slice has no influence on the traffic of other slices, even if the slice is misbehaving (e.g., Distributed Denial-of-Service (DDoS) attacks or node/link failures) and generates traffic volumes above the contracted rates.
受信プロバイダーのネットワーク エッジ リソース制御の主な側面は、スライスごとのトラフィック量の強制です。この種の強制は、「アドミッション コントロール」または「トラフィック コンディショニング」と呼ばれることがよくあります。このインバウンド強制の目的は、プロバイダー ネットワークのエッジで、ビジネス ルールに応じて、契約速度を超えるトラフィックが確実にドロップまたは優先順位を下げられるようにすることです。これは、適切なネットワーク容量計画/管理 (セクション 7) と組み合わせることで、スケーラブルな方法でスライス間の適切な分離を確保するために必要です。その結果、スライスが不正に動作し（分散サービス拒否（DDoS）攻撃やノード/リンク障害など）、契約レートを超えるトラフィック量を生成した場合でも、1 つのスライスのトラフィックは他のスライスのトラフィックに影響を与えません。
The slice rates can be characterized with the following parameters [NSSM]:
スライス レートは、次のパラメータで特徴付けることができます [NSSM]。
* CIR: Committed Information Rate (i.e., guaranteed bandwidth)
* CIR: 認定情報速度 (つまり、保証された帯域幅)
* PIR: Peak Information Rate (i.e., maximum bandwidth)
* PIR: ピーク情報レート (つまり、最大帯域幅)
These parameters define the traffic characteristics of the slice and are part of the SLO parameter set provided by the 5G NSO to an NSC. Based on these parameters, the provider network's inbound policy can be implemented using one of following options:
これらのパラメータはスライスのトラフィック特性を定義し、5G NSO によって NSC に提供される SLO パラメータ セットの一部です。これらのパラメーターに基づいて、次のいずれかのオプションを使用してプロバイダー ネットワークの受信ポリシーを実装できます。
* 1r2c (single-rate two-color) rate limiter
* 1r2c (シングルレート 2 色) レート リミッタ
This is the most basic rate limiter, described in Section 2.3 of [RFC2475] (though not termed "1r2c" in that document). At the SDP, it meters a traffic stream of a given slice and marks its packets as in-profile (below CIR being enforced) or out-of-profile (above CIR being enforced). In-profile packets are accepted and forwarded. Out-of-profile packets are either dropped right at the SDP (hard rate limiting) or re-marked (with different MPLS TC or DSCP TN markings) to signify "this packet should be dropped in the first place, if there is congestion" (soft rate limiting), depending on the business policy of the provider network. In the latter case, while packets above CIR are forwarded at the SDP, they are subject to being dropped during any congestion event at any place in the provider network.
これは、[RFC2475] のセクション 2.3 で説明されている最も基本的なレート リミッターです (ただし、この文書では「1r2c」とは呼ばれていません)。SDP では、特定のスライスのトラフィック ストリームを計測し、そのパケットをプロファイル内 (適用されている CIR を下回る) またはプロファイル外 (CIR を適用している以上) としてマークします。プロファイル内パケットは受け入れられ、転送されます。プロファイル外のパケットは、プロバイダー ネットワークのビジネス ポリシーに応じて、SDP で直接ドロップされるか (ハード レート制限)、「輻輳が発生した場合は最初にこのパケットをドロップする必要がある」ことを示すために (別の MPLS TC または DSCP TN マーキングで) 再マークされます (ソフト レート制限)。後者の場合、CIR を超えるパケットは SDP で転送されますが、プロバイダー ネットワーク内のあらゆる場所で輻輳イベントが発生すると、パケットがドロップされる可能性があります。
* 2r3c (two-rate three-color) rate limiter
* 2r3c (2 レート 3 カラー) レート リミッター
This was initially defined in [RFC2698], and an improved version is defined in [RFC4115]. In essence, the traffic is assigned to one of the these three categories:
これは最初に [RFC2698] で定義され、改良版は [RFC4115] で定義されています。基本的に、トラフィックは次の 3 つのカテゴリのいずれかに割り当てられます。
- Green, for traffic under CIR
- 緑、CIR 下のトラフィック用
- Yellow, for traffic between CIR and PIR
- 黄色、CIR と PIR 間のトラフィック用
- Red, for traffic above PIR
- 赤、PIR を超えるトラフィックの場合
An inbound 2r3c meter implemented with [RFC4115], compared to [RFC2698], is more "customer friendly" as it doesn't impose outbound peak-rate shaping requirements on CE devices. In general, 2r3c meters give greater flexibility for provider network edge enforcement regarding accepting the traffic (green), deprioritizing and potentially dropping the traffic on transit during congestion (yellow), or hard-dropping the traffic (red).
[RFC4115] で実装されたインバウンド 2r3c メーターは、CE デバイスにアウトバウンドのピークレートシェーピング要件を課さないため、[RFC2698] と比較してより「顧客に優しい」ものです。一般に、2r3c メーターは、トラフィックの受け入れ (緑)、輻輳時の通過中のトラフィックの優先順位を下げて潜在的にドロップする (黄色)、またはトラフィックのハード ドロップ (赤) に関して、プロバイダー ネットワーク エッジの適用の柔軟性を高めます。
Inbound provider network edge enforcement for the 5QI-unaware model, where all packets belonging to the slice are treated the same way in the provider network (no 5G QoS Class differentiation in the provider), is outlined in Figure 20.
スライスに属するすべてのパケットがプロバイダー ネットワーク内で同じように扱われる (プロバイダー内で 5G QoS クラスの区別がない) 5QI 非対応モデルの受信プロバイダー ネットワーク エッジの適用の概要を図 20 に示します。
Slice
policer +---------+
| +---|--+ |
| | | |
| | S | |
| | l | |
v | i | |
-------------<>----|--> c | |
| e | A |
| | t |
| 1 | t |
| | a |
------ c |
| | h |
| S | m |
| l | e |
| i | n |
-------------<>----|--> c | t |
| e | |
| | C |
| 2 | i |
| | r |
------ c |
| | u |
| S | i |
| l | t |
| i | |
-------------<>----|--> c | |
| e | |
| | |
| 3 | |
| | |
+---|--+ |
+---------+
Figure 20: Ingress Slice Admission Control (5QI-Unaware Model)
図 20: イングレス スライス アドミッション コントロール (5QI 非認識モデル)
While inbound slice admission control at the provider network edge is mandatory in the architecture described in this document, outbound provider network edge resource control might not be required in all use cases. Use cases that specifically call for outbound provider network edge resource control are:
このドキュメントで説明するアーキテクチャでは、プロバイダー ネットワーク エッジでの受信スライス アドミッション コントロールが必須ですが、アウトバウンド プロバイダー ネットワーク エッジのリソース制御は、すべての使用例で必要なわけではありません。アウトバウンドプロバイダーのネットワークエッジリソース制御を特に必要とするユースケースは次のとおりです。
* Slices use both CIR and PIR parameters, and provider network edge links (ACs) are dimensioned to fulfill the aggregate of slice CIRs. If, at any given time, some slices send the traffic above CIR, congestion in the outbound direction on the provider network edge link (AC) might happen. Therefore, fine-grained resource control to guarantee at least CIR for each slice is required.
* スライスは CIR パラメータと PIR パラメータの両方を使用し、プロバイダー ネットワーク エッジ リンク (AC) はスライス CIR の集合体を満たすように寸法設定されます。特定の時点で、一部のスライスが CIR を超えるトラフィックを送信すると、プロバイダー ネットワーク エッジ リンク (AC) でアウトバウンド方向の輻輳が発生する可能性があります。したがって、各スライスに対して少なくとも CIR を保証するきめ細かいリソース制御が必要です。
* Any-to-Any (A2A) connectivity constructs are deployed, again resulting in potential congestion in the outbound direction on the provider network edge links, even if only slice CIR parameters are used. This again requires fine-grained resource control per slice in the outbound direction at the provider network edge links.
* Any-to-Any（A2A）接続構造が導入されているため、スライス CIR パラメータのみが使用されている場合でも、プロバイダー ネットワークのエッジ リンクでアウトバウンド方向に輻輳が発生する可能性があります。この場合も、プロバイダー ネットワーク エッジ リンクでのアウトバウンド方向のスライスごとのきめ細かいリソース制御が必要になります。
As opposed to inbound provider network edge resource control, typically implemented with rate-limiters/policers, outbound resource control is typically implemented with a weighted/priority queuing, potentially combined with optional shapers (per slice). A detailed analysis of different queuing mechanisms is out of scope for this document but is provided in [RFC7806].
通常、レート リミッター/ポリサーを使用して実装されるインバウンド プロバイダー ネットワーク エッジ リソース制御とは対照的に、アウトバウンド リソース制御は通常、重み付け/優先キューイングを使用して実装され、オプションのシェーパー (スライスごと) と組み合わせられる可能性があります。さまざまなキューイングメカニズムの詳細な分析はこの文書の範囲外ですが、[RFC7806] で提供されています。
Figure 21 outlines the outbound provider network edge resource control model for 5QI-unaware slices. Each slice is assigned a single egress queue. The sum of slice CIRs, used as the weight in weighted queueing model, should not exceed the physical capacity of the AC. Slice requests above this limit should be rejected by the NSC, unless an already-established slice with lower priority, if such exists, is preempted.
図 21 は、5QI 非対応スライスのアウトバウンド プロバイダー ネットワーク エッジ リソース制御モデルの概要を示しています。各スライスには 1 つの出力キューが割り当てられます。加重キューイング モデルの重みとして使用されるスライス CIR の合計は、AC の物理容量を超えてはなりません。この制限を超えるスライス要求は、より低い優先順位の既に確立されたスライスが存在する場合にそれがプリエンプトされない限り、NSC によって拒否される必要があります。
+---------+ QoS output queues
| |
| +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| | S | \|/
| | l | |
| | i | |
| A | c | | weight-Slice-1-CIR
| t | e .--|--------------------------. | shaping-Slice-1-PIR
---|--t--|---|--> | |
| a | 1 '--|--------------------------' /|\
| c ------ - - - - - - - - - - - - - - - - - - - - - - - - - -
| h | S | \|/
| m | l | |
| e | i | |
| n | c | | weight-Slice-2-CIR
| t | e .--|--------------------------. | shaping-Slice-2-PIR
---|-----|---|--> | |
| C | 2 '--|--------------------------' /|\
| i ------ - - - - - - - - - - - - - - - - - - - - - - - - - -
| r | S | \|/
| c | l | |
| u | i | |
| i | c | | weight-Slice-3-CIR
| t | e .--|--------------------------. | shaping-Slice-3-PIR
---|-----|---|--> | |
| | 3 '--|--------------------------' /|\
| +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| |
+---------+
Figure 21: Ingress Slice Admission Control (5QI-Unaware Model) - Output
図 21: イングレス スライス アドミッション コントロール (5QI 非認識モデル) - 出力
In the 5QI-aware model, a potentially large number of 5G QoS Classes, represented via the DSCP set by NFs (the architecture scales to thousands of 5G Network Slices), is mapped (multiplexed) to up to 8 TN QoS Classes used in a provider network transit equipment, as outlined in Figure 22.
5QI 対応モデルでは、NF によって設定された DSCP を介して表される潜在的に多数の 5G QoS クラス (アーキテクチャは数千の 5G ネットワーク スライスに拡張) が、図 22 に概要が示されているように、プロバイダー ネットワーク中継装置で使用される最大 8 つの TN QoS クラスにマッピング (多重化) されます。
+---------------------------------------------------------------+
+-------------------+ PE |
| .--------------+ | |
R | | SDP | | +-----------------------------+
F | | .---------. | | | Transit link |
C | | | 5G DSCP A +---------------+ | .-----------------------. |
9 | | '---------' | | +---|--> TN QoS Class 1 | |
5 | | .---------. | | | | '-----------------------' |
4 | | | 5G DSCP B +------------+ | | .-----------------------. |
3 | | '---------' | | | | | | TN QoS Class 2 | |
| | .---------. | | | | | '-----------------------' |
N | | | 5G DSCP C +---------+ | | | .-----------------------. |
S | | '---------' | | | | | | | TN QoS Class 3 | |
| | .---------. | | | | | | '-----------------------' |
1 | | | 5G DSCP D +------+ | | | | .-----------------------. |
| | '---------' | | | | +--)---|--> TN QoS Class 4 | |
| '--------------' | | | | | | '-----------------------' |
R | .--------------+ | | | | | | .-----------------------. |
F | | .---------. | | | +--)--|---|--> TN QoS Class 5 | |
C | | | 5G DSCP A +------)--|--|--+ | '-----------------------' |
9 | | '---------' | | | | | | .-----------------------. |
5 | | .---------. | | | | | | | TN QoS Class 6 | |
4 | | | 5G DSCP E +------)--)--+ | '-----------------------' |
3 | | '---------' | | | | | .-----------------------. |
| | .---------. | | | | | | TN QoS Class 7 | |
N | | | 5G DSCP F +------)--+ | '-----------------------' |
S | | '---------' | | | | .-----------------------. |
| | .---------. | | +------------|--> TN QoS Class 8 | |
2 | | | 5G DSCP G +------+ | '-----------------------' |
| | '---------' | | | Max 8 TN Classes |
| | SDP | | +-----------------------------+
| '--------------' | |
+-------------------+ |
+---------------------------------------------------------------+
Fine-grained QoS enforcement Coarse-grained QoS enforcement
(dedicated resources per (resources shared by multiple
RFC 9543 Network Slice) RFC 9543 Network Slices)
Figure 22: Mapping of Slice 5G QoS to TN QoS (5QI-Aware Model)
図 22: スライス 5G QoS から TN QoS へのマッピング (5QI 対応モデル)
Given that in deployments with a large number of 5G Network Slices, the number of potential 5G QoS Classes is much higher than the number of TN QoS Classes, multiple 5G QoS Classes with similar characteristics -- potentially from different slices -- would be grouped with common operator-defined TN logic and mapped to the same TN QoS Class when transported in the provider network. That is, common Per-Hop Behavior (PHB) [RFC2474] is executed on transit provider network routers for all packets grouped together. An example of this approach is outlined in Figure 23. A provider may decide to implement Diffserv-Intercon PHBs at the boundaries of its network domain [RFC8100].
多数の 5G ネットワーク スライスを使用した展開では、潜在的な 5G QoS クラスの数が TN QoS クラスの数よりもはるかに多いことを考慮すると、同様の特性を持つ複数の 5G QoS クラス (異なるスライスに由来する可能性があります) は、共通のオペレータ定義の TN ロジックでグループ化され、プロバイダー ネットワークで転送されるときに同じ TN QoS クラスにマッピングされます。つまり、グループ化されたすべてのパケットに対して、共通のホップごとの動作 (PHB) [RFC2474] が中継プロバイダーのネットワーク ルーター上で実行されます。このアプローチの例の概要を図 23 に示します。プロバイダーは、そのネットワーク ドメイン [RFC8100] の境界で Diffserv-Intercon PHB を実装することを決定する場合があります。
Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP, queue, etc.) are provided for illustration purposes only and should not be considered as deployment guidance.
注: 図 23 に示されている番号 (S-NSSAI、5QI、DSCP、キューなど) は説明のみを目的として提供されており、展開のガイダンスとして考慮されるべきではありません。
+--------------- PE -----------------+
+------ NF-A ------------+ | |
| | | .----------+ |
| 3GPP S-NSSAI 100 | | | SDP | |
| .-----. .-------. | | | .------. | |
| |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ |
| '-----' '-------' | | | '------' | | |
| .-----. .-------. | | | .------. | | |
| |5QI=65 +->+DSCP=46 +----->+DSCP=46 +----+ |
| '-----' '-------' | | | '------' | | |
| .-----. .-------. | | | .------. | | |
| |5QI=7 +->+DSCP=10 +----->+DSCP=10 +----)-+ .------------. |
| '-----' '-------' | | | '------' | | | |TN QoS Class 5| |
+------------------------+ | '----------' +-)--> Queue 5 | |
| | | '------------' |
+------- NF-B -----------+ | | | |
| | | .----------+ | | |
| 3GPP S-NSSAI 200 | | | SDP | | | |
| .-----. .-------. | | | .------. | | | |
| |5QI=1 +->+ DSCP=46 +----->+DSCP=46 +----+ | .------------. |
| '-----' '-------' | | | '------' | | | |TN QoS Class 1| |
| .-----. .-------. | | | .-------. | | +--> Queue 1 | |
| |5QI=65 +->+DSCP=46 +----->+DSCP=46 +---+ | '------------' |
| '-----' '-------' | | | '-------' | | |
| .-----. .-------. | | | .-------. | | |
| |5QI=7 +->+DSCP=10 +----->+DSCP=10 +-----+ |
| '-----' '-------' | | | '-------' | |
+------------------------+ | '----------' |
+--------------------------------------+
Figure 23: Example of 3GPP QoS Mapped to TN QoS
図 23: TN QoS にマッピングされた 3GPP QoS の例
In current SDO progress of 3GPP (Release 19) and O-RAN, the mapping of 5QI to DSCP is not expected to be in a per-slice fashion, where 5QI-to-DSCP mapping may vary from 3GPP slice to 3GPP slice; hence, the mapping of 5G QoS DSCP values to TN QoS Classes may be rather common.
3GPP (リリース 19) および O-RAN の現在の SDO の進行状況では、5QI から DSCP へのマッピングがスライスごとに行われることは期待されておらず、5QI から DSCP へのマッピングは 3GPP スライスごとに異なる場合があります。したがって、5G QoS DSCP 値の TN QoS クラスへのマッピングはかなり一般的である可能性があります。
Like in the 5QI-unaware model, the original IP header retains the DSCP marking corresponding to 5QI (5G QoS Class), while the new header (MPLS or IPv6) carries the QoS marking related to TN QoS Class. Based on the TN QoS Class marking, per-hop behavior for all aggregated 5G QoS Classes from all RFC 9543 Network Slices is executed on the provider network transit links. Provider network transit routers do not evaluate the original IP header for QoS-related decisions. The original DSCP marking retained in the original IP header is used at the PE for fine-grained inbound/ outbound enforcement per slice and per 5G QoS Class on the AC.
5QI 非対応モデルと同様に、元の IP ヘッダーは 5QI (5G QoS クラス) に対応する DSCP マーキングを保持しますが、新しいヘッダー (MPLS または IPv6) は TN QoS クラスに関連する QoS マーキングを保持します。TN QoS クラス マーキングに基づいて、すべての RFC 9543 ネットワーク スライスからのすべての集約された 5G QoS クラスのホップごとの動作がプロバイダー ネットワーク トランジット リンク上で実行されます。プロバイダーのネットワーク中継ルーターは、QoS 関連の決定のために元の IP ヘッダーを評価しません。元の IP ヘッダーに保持されている元の DSCP マーキングは、AC 上のスライスごとおよび 5G QoS クラスごとにきめ細かい受信/送信の適用のために PE で使用されます。
In the 5QI-aware model, compared to the 5QI-unaware model, provider network edge resources are controlled in an even more fine-grained manner, with dedicated resource allocation for each RFC 9543 Network Slice and for a number of traffic classes (most commonly, up to 4 or 8 traffic classes, depending on the hardware capability of the equipment) within each RFC 9543 Network Slice.
5QI 対応モデルでは、5QI 非対応モデルと比較して、プロバイダー ネットワーク エッジ リソースは、各 RFC 9543 ネットワーク スライスおよび各 RFC 9543 ネットワーク スライス内のいくつかのトラフィック クラス (最も一般的には、機器のハードウェア機能に応じて最大 4 または 8 つのトラフィック クラス) に専用のリソースが割り当てられることで、さらにきめ細かい方法で制御されます。
Compared to the 5QI-unaware model, admission control (traffic conditioning) in the 5QI-aware model is more granular, as it not only enforces per-slice capacity constraints, but may also enforce the constraints per 5G QoS Class within each slice.
5QI 非対応モデルと比較して、5QI 対応モデルのアドミッション コントロール (トラフィック コンディショニング) は、スライスごとの容量制約を強制するだけでなく、各スライス内の 5G QoS クラスごとの制約も強制する場合があるため、より細分化されています。
A 5G Network Slice using multiple 5QIs can potentially specify rates in one of the following ways:
複数の 5QI を使用する 5G ネットワーク スライスでは、次のいずれかの方法でレートを指定できる可能性があります。
* Rates per traffic class (CIR or CIR+PIR), no rate per slice (sum of rates per class gives the rate per slice).
* トラフィック クラスごとのレート（CIR または CIR+PIR）、スライスごとのレートなし（クラスごとのレートの合計がスライスごとのレートを示します）。
* Rate per slice (CIR or CIR+PIR), and rates per prioritized (premium) traffic classes (CIR only). A best-effort traffic class uses the bandwidth (within slice CIR/PIR) not consumed by prioritized classes.
* スライスごとのレート (CIR または CIR+PIR)、および優先順位付き (プレミアム) トラフィック クラスごとのレート (CIR のみ)。ベストエフォート トラフィック クラスは、優先クラスによって消費されない帯域幅 (スライス CIR/PIR 内) を使用します。
In the first option, the slice admission control is executed with traffic class granularity, as outlined in Figure 24. In this model, if a premium class doesn't consume all available class capacity, it cannot be reused by a non-premium class (i.e., best-effort).
最初のオプションでは、図 24 に示すように、スライス アドミッション コントロールがトラフィック クラスの粒度で実行されます。このモデルでは、プレミアム クラスが利用可能なクラス容量をすべて消費しない場合、非プレミアム クラス (つまり、ベストエフォート) で再利用することはできません。
Class +---------+
policer +--|---+ |
| | |
5Q-QoS-A: CIR-1A ------<>-----------|--> S | |
5Q-QoS-B: CIR-1B ------<>-----------|--> l | |
5Q-QoS-C: CIR-1C ------<>-----------|--> i | |
| c | |
| e | |
BE CIR/PIR-1D ------<>-----------|--> | A |
| 1 | t |
| | t |
------ a |
| | c |
5Q-QoS-A: CIR-2A ------<>-----------|--> S | h |
5Q-QoS-B: CIR-2B ------<>-----------|--> l | m |
5Q-QoS-C: CIR-2C ------<>-----------|--> i | e |
| c | n |
| e | t |
BE CIR/PIR-2D ------<>-----------|--> | |
| 2 | C |
| | i |
------ r |
| | c |
5Q-QoS-A: CIR-3A ------<>-----------|--> S | u |
5Q-QoS-B: CIR-3B ------<>-----------|--> l | i |
5Q-QoS-C: CIR-3C ------<>-----------|--> i | t |
| c | |
| e | |
BE CIR/PIR-3D-------<>-----------|--> | |
| 3 | |
| | |
+--|---+ |
+---------+
Figure 24: Ingress Slice Admission Control (5QI-Aware Model)
図 24: イングレス スライス アドミッション コントロール (5QI 対応モデル)
The second option combines the advantages of the 5QI-unaware model (per-slice admission control) with per-traffic-class admission control, as outlined in Figure 24. Ingress admission control is at class granularity for premium classes (CIR only). A non-premium class (i.e., best-effort class) has no separate class admission control policy, but it is allowed to use the entire slice capacity, which is available at any given moment (i.e., slice capacity, which is not consumed by premium classes). It is a hierarchical model, as depicted in Figure 25.
2 番目のオプションは、図 24 に概要が示されているように、5QI 非対応モデル (スライスごとのアドミッション コントロール) とトラフィック クラスごとのアドミッション コントロールの利点を組み合わせたものです。イングレス アドミッション コントロールは、プレミアム クラスのクラス粒度です (CIR のみ)。非プレミアム クラス (つまり、ベストエフォート クラス) には、別個のクラス アドミッション コントロール ポリシーはありませんが、いつでも利用可能なスライス容量全体 (つまり、プレミアム クラスによって消費されないスライス容量) を使用することが許可されます。図 25 に示すように、これは階層モデルです。
Slice
policer +---------+
Class +--|---+ |
policer .-. | | |
5Q-QoS-A: CIR-1A ----<>--------|-|--|--> S | |
5Q-QoS-B: CIR-1B ----<>--------|-|--|--> l | |
5Q-QoS-C: CIR-1C ----<>--------|-|--|--> i | |
| | | c | |
| | | e | |
BE CIR/PIR-1D --------------|-|--|--> | A |
| | | 1 | t |
'-' | | t |
------ a |
.-. | | c |
5Q-QoS-A: CIR-2A ----<>--------|-|--|--> S | h |
5Q-QoS-B: CIR-2B ----<>--------|-|--|--> l | m |
5Q-QoS-C: CIR-2C ----<>--------|-|--|--> i | e |
| | | c | n |
| | | e | t |
BE CIR/PIR-2D --------------|-|--|--> | |
| | | 2 | C |
'-' | | i |
------ r |
.-. | | c |
5Q-QoS-A: CIR-3A ----<>--------|-|--|--> S | u |
5Q-QoS-B: CIR-3B ----<>--------|-|--|--> l | i |
5Q-QoS-C: CIR-3C ----<>---- ---|-|--|--> i | t |
| | | c | |
| | | e | |
BE CIR/PIR-3D --------------|-|--|--> | |
| | | 3 | |
'-' | | |
+--|---+ |
+---------+
Figure 25: Ingress Slice Admission Control (5QI-Aware Model) - Hierarchical
図 25: イングレス スライス アドミッション コントロール (5QI 対応モデル) - 階層型
Figure 26 outlines the outbound edge resource control model at the Transport Network layer for 5QI-aware slices. Each slice is assigned multiple egress queues. The sum of queue weights, which are 5G QoS queue CIRs within the slice, should not exceed the CIR of the slice itself. And, similar to the 5QI-aware model, the sum of slice CIRs should not exceed the physical capacity of the AC.
図 26 は、5QI 対応スライスのトランスポート ネットワーク層におけるアウトバウンド エッジ リソース制御モデルの概要を示しています。各スライスには複数の出力キューが割り当てられます。スライス内の 5G QoS キュー CIR であるキュー重みの合計は、スライス自体の CIR を超えてはなりません。また、5QI 対応モデルと同様に、スライス CIR の合計が AC の物理容量を超えてはなりません。
+---------+ QoS output queues
| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
| | .--|--------------------------. \|/
---|-----|---|--> 5Q-QoS-A: w-5Q-QoS-A-CIR | |
| | S '-----------------------------' |
| | l .-----------------------------. |
---|-----|-i-|--> 5Q-QoS-B: w-5Q-QoS-B-CIR | |
| | c '-----------------------------' | weight-Slice-1-CIR
| | e .-----------------------------. | shaping-Slice-1-PIR
---|-----|---|--> 5Q-QoS-C: w-5Q-QoS-C-CIR | |
| | 1 '-----------------------------' |
| | .-----------------------------. |
---|-----|---|--> Best Effort (remainder) | |
| | '--|--------------------------' /|\
| A +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| t | .--|--------------------------. \|/
| t | | | |
| a | '-----------------------------' |
| c | S | |
| h | l |
| m | i | ... | weight-Slice-2-CIR
| e | c | | shaping-Slice-2-PIR
| n | e .-----------------------------. |
| t | | | |
| | 2 '-----------------------------' /|\
| C +-------+ - - - - - - - - - - - - - - - - - - - - - - - - -
| i | | \|/
| r + .-----------------------------. |
| c | | | |
| u | '-----------------------------' |
| i | S | |
| t | l | |
| | i | ... | weight-Slice-3-CIR
| | c | | shaping-Slice-3-PIR
| | e .-----------------------------. |
| | | | |
| | 3 '-----------------------------' /|\
| +---|---+ - - - - - - - - - - - - - - - - - - - - - - - - -
+---------+
Figure 26: Egress Slice Admission Control (5QI-Aware Model)
図 26: 出力スライス アドミッション コントロール (5QI 対応モデル)
Transit resource control is much simpler than edge resource control in the provider network. As outlined in Figure 22, at the provider network edge, 5G QoS Class marking (represented by DSCP related to 5QI set by Mobile Network functions in the packets handed off to the TN) is mapped to the TN QoS Class. Based on TN QoS Class, when the packet is encapsulated with an outer header (MPLS or IPv6), the TN QoS Class marking (MPLS TC or IPv6 DSCP in outer header, as depicted in Figures 18 and 19) is set in the outer header. PHB in provider network transit routers is based exclusively on that TN QoS Class marking, i.e., original 5G QoS Class DSCP is not taken into consideration on transit.
トランジット リソース制御は、プロバイダー ネットワークのエッジ リソース制御よりもはるかに簡単です。図 22 に概説されているように、プロバイダー ネットワーク エッジでは、5G QoS クラス マーキング (TN に渡されるパケット内のモバイル ネットワーク機能によって設定される 5QI に関連する DSCP で表されます) が TN QoS クラスにマッピングされます。TN QoS クラスに基づいて、パケットが外部ヘッダー（MPLS または IPv6）でカプセル化されると、TN QoS クラス マーキング（図 18 および 19 に示すように、外部ヘッダーの MPLS TC または IPv6 DSCP）が外部ヘッダーに設定されます。プロバイダー ネットワーク トランジット ルーターの PHB は、その TN QoS クラス マーキングのみに基づいています。つまり、オリジナルの 5G QoS クラス DSCP はトランジット時に考慮されません。
Provider network transit resource control does not use any inbound interface policy but only uses an outbound interface policy, which is based on the priority queue combined with a weighted or deficit queuing model, without any shaper. The main purpose of transit resource control is to ensure that during network congestion events (for example, events caused by network failures or temporary rerouting), premium classes are prioritized, and any drops only occur in traffic that was deprioritized by ingress admission control (see Section 5.2.1.1) or in non-premium (best-effort) classes. Capacity planning and management, as described in Section 7, ensures that enough capacity is available to fulfill all approved slice requests.
プロバイダー ネットワーク トランジット リソース制御は、受信インターフェイス ポリシーを使用せず、シェーパーを使用せずに、重み付きキュー モデルまたは不足キュー モデルと組み合わせた優先キューに基づく送信インターフェイス ポリシーのみを使用します。トランジット リソース制御の主な目的は、ネットワーク輻輳イベント（たとえば、ネットワーク障害や一時的な再ルーティングによって引き起こされるイベント）中にプレミアム クラスが優先され、ドロップがイングレス アドミッション コントロール（セクション 5.2.1.1 を参照）によって優先順位が下げられたトラフィックまたは非プレミアム（ベストエフォート）クラスでのみ発生することを保証することです。セクション 7 で説明されているように、容量の計画と管理により、承認されたすべてのスライス要求を満たすのに十分な容量が確保されます。
The PE underlay transport (underlay transport, for short) refers to a specific path forwarding behavior between PEs in order to provide packet delivery that is consistent with the corresponding SLOs. This realization step focuses on controlling the paths that will be used for packet delivery between PEs, independent of the underlying network resource partitioning.
PE アンダーレイ トランスポート (略称、アンダーレイ トランスポート) は、対応する SLO と一致したパケット配信を提供するための、PE 間の特定のパス転送動作を指します。この実現ステップは、基礎となるネットワーク リソースの分割とは独立して、PE 間のパケット配信に使用されるパスの制御に焦点を当てます。
It is worth noting that TN QoS Classes and underlay transport are each related to different engineering objectives. For example, the TN domain can be operated with 8 TN QoS Classes (representing 8 hardware queues in the routers) and two underlay transports (e.g., a latency-optimized underlay transport using link-latency metrics for path calculation and an underlay transport following IGP metrics). The TN QoS Class determines the per-hop behavior when the packets are transiting through the provider network, while underlay transport determines the paths for packets through the provider network based on the operator's requirements. This path can be optimized or constrained.
TN QoS クラスとアンダーレイ トランスポートはそれぞれ異なるエンジニアリング目標に関連していることに注意してください。たとえば、TN ドメインは、8 つの TN QoS クラス (ルーター内の 8 つのハードウェア キューを表す) と 2 つのアンダーレイ トランスポート (たとえば、パス計算のリンク遅延メトリックを使用した遅延最適化されたアンダーレイ トランスポートと、IGP メトリックに従うアンダーレイ トランスポート) で動作できます。TN QoS クラスは、パケットがプロバイダー ネットワークを通過するときのホップごとの動作を決定します。一方、アンダーレイ トランスポートは、オペレーターの要件に基づいてプロバイダー ネットワークを通過するパケットのパスを決定します。このパスは最適化または制限できます。
A network operator can define multiple underlay transports within a single NRP. An underlay transport may be realized in multiple ways such as (but not limited to):
ネットワーク オペレータは、単一の NRP 内で複数のアンダーレイ トランスポートを定義できます。アンダーレイ トランスポートは、次のような複数の方法で実現できます (ただし、これらに限定されません)。
* A mesh of RSVP-TE [RFC3209] or SR-TE [RFC9256] tunnels created with specific optimization criteria and constraints. For example, mesh "A" might represent tunnels optimized for latency, and mesh "B" might represent tunnels optimized for high capacity.
* 特定の最適化基準と制約を使用して作成された RSVP-TE [RFC3209] または SR-TE [RFC9256] トンネルのメッシュ。たとえば、メッシュ「A」は遅延について最適化されたトンネルを表し、メッシュ「B」は高容量について最適化されたトンネルを表す場合があります。
* A Flex-Algorithm [RFC9350] with a particular metric-type (e.g., latency), or one that only uses links with particular properties (e.g., a Media Access Control Security (MACsec) link [IEEE802.1AE]) or excludes links that are within a particular geography.
* 特定のメトリック タイプ (例: 遅延) を持つフレックス アルゴリズム [RFC9350]、または特定のプロパティを持つリンクのみを使用するもの (例: Media Access Control Security (MACsec) リンク [IEEE802.1AE])、または特定の地理内にあるリンクを除外するもの。
These protocols can be controlled, e.g., by tuning the protocol list under the "underlay-transport" data node defined in the L3VPN Network Model (L3NM) [RFC9182] and the L2VPN Network Model (L2NM) [RFC9291].
これらのプロトコルは、たとえば、L3VPN ネットワーク モデル (L3NM) [RFC9182] および L2VPN ネットワーク モデル (L2NM) [RFC9291] で定義されている「アンダーレイ トランスポート」データ ノードの下のプロトコル リストを調整することによって制御できます。
Also, underlay transports may be realized using separate NRPs. However, such an approach is left out of the scope given the current state of the technology at the time of writing this document.
また、アンダーレイトランスポートは、別個の NRP を使用して実現することもできます。ただし、このドキュメントの執筆時点でのテクノロジーの現状を考慮すると、そのようなアプローチは範囲外となります。
Similar to the QoS mapping models discussed in Section 5, for mapping to underlay transports at the ingress PE, both the 5QI-unaware and 5QI-aware models are defined. Essentially, entire slices can be mapped to underlay transports without 5G QoS consideration (5QI-unaware model). For example, flows with different 5G QoS Classes, even from same slice, can be mapped to different underlay transports (5QI-aware model).
セクション 5 で説明した QoS マッピング モデルと同様に、入力 PE でのアンダーレイ トランスポートへのマッピングについては、5QI 非対応モデルと 5QI 対応モデルの両方が定義されます。基本的に、5G QoS を考慮せずにスライス全体をアンダーレイ トランスポートにマッピングできます (5QI 非対応モデル)。たとえば、異なる 5G QoS クラスを持つフローは、同じスライスからであっても、異なるアンダーレイ トランスポートにマッピングできます (5QI 対応モデル)。
Figure 27 depicts an example of a simple network with two underlay transports, each using a mesh of TE tunnels with or without Path Computation Element (PCE) [RFC5440] and with or without per-path bandwidth reservations. Section 7 discusses in detail different bandwidth models that can be deployed in the provider network. However, discussion about how to realize or orchestrate underlay transports is out of scope for this document.
図 27 は、2 つのアンダーレイ トランスポートを持つ単純なネットワークの例を示しています。各アンダーレイ トランスポートは、パス計算要素 (PCE) [RFC5440] の有無およびパスごとの帯域幅予約の有無にかかわらず、TE トンネルのメッシュを使用します。セクション 7 では、プロバイダー ネットワークに導入できるさまざまな帯域幅モデルについて詳しく説明します。ただし、アンダーレイ トランスポートを実現または調整する方法については、このドキュメントの範囲外です。
+---------------+ +------+
| Ingress PE | +------------------------------->| PE-A |
| | | +-------------------------->>| |
| | | | +------+
| +----------+ | | +---------------------+
| | | | | |
| | x------+ +---------------------+
| |Underlay x----------|-------------+ +------+
| |Transport x----------)--+ +------------->| PE-B |
| | A x-------+ | | +---+ +------>>| |
| +----------+ | | | | | | | +------+
| | | | | | +---------+
| +----------+ | | | | |
| | | | | | | | +------+
| | o-------)--+ +--)--------------------->| PE-C |
| |Underlay o-------|--------+ +---->>| |
| |Transport o-------|-----------------+ | +------+
| | B o-----+ +---------------+ | |
| | | | | | | |
| +----------+ | | +---+ +---+ | +------+ +------+
| | | | | | | +-------------->| PE-D |
+---------------+ +---+ +---+ +--------------->>| |
+------+
Figure 27: Example of Underlay Transport Relying on TE Tunnels
図 27: TE トンネルに依存するアンダーレイ トランスポートの例
For illustration purposes, Figure 27 shows only single tunnels per underlay transport for an (ingress PE, egress PE) pair. However, there might be multiple tunnels within a single underlay transport between any pair of PEs.
説明のために、図 27 では、(入力 PE、出力 PE) ペアのアンダーレイ トランスポートごとに 1 つのトンネルのみを示しています。ただし、PE のペア間の単一のアンダーレイ トランスポート内に複数のトンネルが存在する可能性があります。
As discussed in Section 5.2.1, in the 5QI-unaware model, the provider network doesn't take into account 5G QoS during execution of per-hop behavior. The entire slice is mapped to a single TN QoS Class; therefore, the entire slice is subject to the same per-hop behavior. Similarly, in the 5QI-unaware PE underlay transport mapping model, the entire slice is mapped to a single underlay transport, as depicted in Figure 28.
セクション 5.2.1 で説明したように、5QI 非対応モデルでは、プロバイダー ネットワークはホップごとの動作の実行中に 5G QoS を考慮しません。スライス全体が単一の TN QoS クラスにマッピングされます。したがって、スライス全体が同じホップごとの動作の影響を受けます。同様に、5QI 非対応 PE アンダーレイ トランスポート マッピング モデルでは、図 28 に示すように、スライス全体が単一のアンダーレイ トランスポートにマッピングされます。
+-------------------------------------------+
|.. .. .. .. .. .. . |
: AC : PE |
: .--------------. : |
: | SDP | : |
: | +----------+ | : |
: | | NS 1 +-----------+ |
: | +----------+ | : | |
: '--------------' : | |
: .--------------. : | +---------+ |
: | SDP | : | | | |
: | +----------+ | : | |Underlay | |
: | | NS 2 +-------+ +--->Transport| |
: | +----------+ | : | | | A | |
: '--------------' : | | | | |
: .--------------. : | | +---------+ |
: | SDP | : | | |
: | +----------+ | : | | |
: | | NS 3 +-------+ | |
: | +----------+ | : | | +---------+ |
: '--------------' : | | | | |
: .--------------. : | | |Underlay | |
: | SDP | : +---)--->Transport| |
: | +----------+ | : | | | B | |
: | | NS 4 +-------+ | | | |
: | +----------+ | : | +---------+ |
: '--------------' : | |
: .--------------. : | |
: | SDP | : | |
: | +----------+ | : | |
: | | NS 5 +-----------+ |
: | +----------+ | : |
: '--------------' : |
'.. .. .. .. .. .. .' |
+-------------------------------------------+
Figure 28: Mapping of Network Slice to Underlay Transport (5QI-Unaware Model)
図 28: ネットワーク スライスとアンダーレイ トランスポートのマッピング (5QI 非対応モデル)
In the 5QI-aware model, the traffic can be mapped to underlay transports at the granularity of 5G QoS Class. Given that the potential number of underlay transports is limited, packets from multiple 5G QoS Classes with similar characteristics are mapped to a common underlay transport, as depicted in Figure 29.
5QI 対応モデルでは、トラフィックを 5G QoS クラスの粒度でアンダーレイ トランスポートにマッピングできます。アンダーレイ トランスポートの潜在的な数が制限されていることを考慮すると、図 29 に示すように、同様の特性を持つ複数の 5G QoS クラスからのパケットが共通のアンダーレイ トランスポートにマッピングされます。
+---------------------------------------------+
|.. .. .. .. .. .. . |
: AC : PE |
: .--------------. : |
R : | SDP | : |
F : | .---------. | : |
C : | | 5G QoS A +-------+ |
9 : | '---------' | : | |
5 : | .---------. | : | |
4 : | | 5G QoS B +-------+ |
3 : | '---------' | : | +---------+ |
: | .---------. | : | | | |
N : | | 5G QoS C +-------)----+ |Underlay | |
S : | '---------' | : +----)---->Transport| |
: | .---------. | : | | | A | |
1 : | | 5G QoS D +-------)----+ | | |
: | '---------' | : | | +---------+ |
: '--------------' : | | |
R : .--------------. : | | |
F : | .---------. | : | | |
C : | | 5G QoS A +-------+ | +---------+ |
9 : | '---------' | : | | | | |
5 : | .---------. | : | | |Underlay | |
4 : | | 5G QoS E +-------+ +---->Transport| |
3 : | '---------' | : | | B | |
: | .---------. | : | | | |
N : | | 5G QoS F +------------+ +---------+ |
S : | '---------' | : | |
: | .---------. | : | |
2 : | | 5G QoS G +------------+ |
: | '---------' | : |
: | SDP | : |
: '--------------' : |
'.. .. .. .. .. .. ' |
+---------------------------------------------+
Figure 29: Mapping of Network Slice to Underlay Transport (5QI-Aware Model)
図 29: ネットワーク スライスとアンダーレイ トランスポートのマッピング (5QI 対応モデル)
This section describes the information conveyed by the 5G NSO to the NSC with respect to slice bandwidth requirements.
このセクションでは、スライス帯域幅要件に関して 5G NSO によって NSC に伝達される情報について説明します。
Figure 30 shows three DCs that contain instances of network functions. Also shown are PEs that have links to the DCs. The PEs belong to the provider network. Other details of the provider network, such as P-routers and transit links, are not shown. In addition, details of the DC infrastructure in customer sites, such as switches and routers, are not shown.
図 30 は、ネットワーク機能のインスタンスを含む 3 つの DC を示しています。DC へのリンクを持つ PE も表示されます。PE はプロバイダー ネットワークに属します。P ルーターや中継リンクなどのプロバイダー ネットワークのその他の詳細は示されていません。さらに、スイッチやルーターなど、顧客サイトの DC インフラストラクチャの詳細は示されていません。
The 5G NSO is aware of the existence of the network functions and their locations. However, it is not aware of the details of the provider network. The NSC has the opposite view -- it is aware of the provider network infrastructure and the links between the PEs and the DCs, but it is not aware of the individual network functions at customer sites.
5G NSO は、ネットワーク機能の存在とその位置を認識しています。ただし、プロバイダー ネットワークの詳細については認識していません。NSC は逆の見解を持っています。NSC は、プロバイダーのネットワーク インフラストラクチャと PE と DC の間のリンクを認識していますが、顧客サイトの個々のネットワーク機能は認識していません。
+-------- DC 1-------+ +-----------------+ +-------- DC 2-------+
| | | | | |
| +------+ | +-----+ +-----+ | +------+ |
| | NF1A | +--* PE1A| |PE2A *--+ | NF2A | |
| +------+ | +-----+ +-----+ | +------+ |
| +------+ | | | | +------+ |
| | NF1B | | | | | | NF2B | |
| +------+ | | | | +------+ |
| +------+ | +-----+ +-----+ | +------+ |
| | NF1C | +--* PE1B| |PE2B *--+ | NF2C | |
| +------+ | +-----+ +-----+ | +------+ |
+--------------------+ | | +--------------------+
| Provider |
| Network | +--------DC 3--------+
| +-----+ | +------+ |
| |PE3A *--+ | NF3A | |
| +-----+ | +------+ |
| | | +------+ |
| | | | NF3B | |
| | | +------+ |
| +-----+ | +------+ |
| |PE3B *--+ | NF3C | |
| +-----+ | +------+ |
| | | |
+-----------------+ +--------------------+
* SDP, with fine-grained QoS (dedicated resources per RFC 9543 Network
Slices)
Figure 30: Example of Multi-DC Architecture
図 30: マルチ DC アーキテクチャの例
Let us consider 5G Network Slice "X" that uses some of the network functions in the three DCs. If this slice has latency requirements, the 5G NSO will have taken those into account when deciding which NF instances in which DC are to be invoked for this slice. As a result of such a placement decision, the three DCs shown are involved in 5G Network Slice "X", rather than other DCs. For its decision-making, the 5G NSO needs information from the NSC about the observed latency between DCs. Preferably, the NSC would present the topology in an abstracted form, consisting of point-to-point abstracted links between pairs of DCs and associated latency and, optionally, delay variation and link-loss values. It would be valuable to have a mechanism for the 5G NSO to inform the NSC which DC-pairs are of interest for these metrics; there may be thousands of DCs, but the 5G NSO will only be interested in these metrics for a small fraction of all the possible DC-pairs, i.e., those in the same region of the provider network. The mechanism for conveying the information is out of scope for this document.
3 つの DC のネットワーク機能の一部を使用する 5G ネットワーク スライス「X」を考えてみましょう。このスライスにレイテンシー要件がある場合、5G NSO は、このスライスに対して DC のどの NF インスタンスを呼び出すかを決定する際に、それらの要件を考慮します。このような配置決定の結果、示されている 3 つの DC は、他の DC ではなく 5G ネットワーク スライス "X" に含まれています。5G NSO は、意思決定を行うために、DC 間で観測された遅延に関する NSC からの情報を必要とします。好ましくは、NSC は、DC のペア間のポイントツーポイントの抽象化されたリンクと、関連する遅延、およびオプションで遅延変動とリンク損失の値から構成される抽象化された形式でトポロジを提示します。5G NSO が、どの DC ペアがこれらのメトリクスに関係しているかを NSC に通知するメカニズムを持つことは価値があります。何千もの DC が存在する可能性がありますが、5G NSO は、考えられるすべての DC ペアのうちのごく一部、つまりプロバイダー ネットワークの同じリージョンにある DC ペアについてのみ、これらのメトリクスに関心を持ちます。情報を伝達するメカニズムについては、このドキュメントの範囲外です。
Table 1 shows the matrix of bandwidth demands for 5G Network Slice "X". Within the slice, multiple NF instances might be sending traffic from DCi to DCj. However, the 5G NSO sums the associated demands into one value. For example, "NF1A" and "NF1B" in "DC 1" might be sending traffic to multiple NFs in "DC 2", but this is expressed as one value in the traffic matrix: the total bandwidth required for 5G Network Slice "X" from "DC 1" to "DC 2" (8 units). Each row in the right-most column in the traffic matrix shows the total amount of traffic going from a given DC into the Transport Network, regardless of the destination DC. Note that this number can be less than the sum of DC-to-DC demands in the same row, on the basis that not all the NFs are likely to be sending at their maximum rate simultaneously. For example, the total traffic from "DC 1" for slice "X" is 11 units, which is less than the sum of the DC-to-DC demands in the same row (13 units). Note, as described in Section 5, a slice may have per-QoS class bandwidth requirements and may have CIR and PIR limits. This is not included in the example, but the same principles apply in such cases.
表 1 は、5G ネットワーク スライス「X」の帯域幅需要のマトリックスを示しています。スライス内では、複数の NF インスタンスが DCi から DCj にトラフィックを送信している可能性があります。ただし、5G NSO は、関連する要求を 1 つの値に合計します。たとえば、「DC 1」の「NF1A」と「NF1B」は「DC 2」の複数の NF にトラフィックを送信している可能性がありますが、これはトラフィック マトリックスの 1 つの値、つまり「DC 1」から「DC 2」までの 5G ネットワーク スライス「X」に必要な合計帯域幅 (8 ユニット) として表されます。トラフィック マトリックスの右端の列の各行は、宛先 DC に関係なく、特定の DC からトランスポート ネットワークに入るトラフィックの総量を示します。すべての NF が同時に最大レートで送信しているわけではないことに基づいて、この数は同じ行の DC-to-DC 要求の合計よりも小さくなる可能性があることに注意してください。たとえば、スライス「X」の「DC 1」からのトラフィックの合計は 11 ユニットですが、これは同じ行の DC 間の需要の合計 (13 ユニット) よりも少なくなります。セクション 5 で説明したように、スライスには QoS クラスごとの帯域幅要件があり、CIR および PIR 制限がある場合があることに注意してください。これは例には含まれていませんが、そのような場合にも同じ原則が適用されます。
+=========+======+======+======+===============+
| From/To | DC 1 | DC 2 | DC 3 | Total from DC |
+=========+======+======+======+===============+
| DC 1 | n/a | 8 | 5 | 11.0 |
+---------+------+------+------+---------------+
| DC 2 | 1 | n/a | 2 | 2.5 |
+---------+------+------+------+---------------+
| DC 3 | 4 | 7 | n/a | 10.0 |
+---------+------+------+------+---------------+
Table 1: Inter-DC Traffic Demand Matrix (Slice X)
表 1: DC 間のトラフィック需要マトリックス (スライス X)
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 policers corresponding to the last column in the traffic matrix to the appropriate PE routers, in order to enforce the bandwidth contract. For example, it applies a policer of 11 units to PE1A and PE1B that face DC 1, as this is the total bandwidth that DC 1 sends into the provider network corresponding to slice "X". Also, the controller may apply shapers in the direction from the TN to the DC if there is the possibility of a link in the DC being oversubscribed. Note that a peer NF endpoint of an AC can be identified using "peer-sap-id" as defined in [RFC9408].
[NSSM] で定義されている YANG データ モデルは、トラフィック マトリックスのすべての情報を NSC に伝達するために使用できます。NSC は、帯域幅契約を強制するために、トラフィック マトリックスの最後の列に対応するポリサーを適切な PE ルーターに適用します。たとえば、DC 1 がスライス "X" に対応するプロバイダー ネットワークに送信する合計帯域幅であるため、DC 1 に面する PE1A と PE1B に 11 ユニットのポリサーが適用されます。また、DC 内のリンクがオーバーサブスクライブされる可能性がある場合、コントローラーは TN から DC の方向にシェーパーを適用することがあります。AC のピア NF エンドポイントは、[RFC9408] で定義されている「peer-sap-id」を使用して識別できることに注意してください。
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 demands, may not be directly applied to the provider network. Even so, the information may be useful to the NSC for capacity planning and failure simulation purposes. On the other hand, if the DC-to-DC demand information is not used by the NSC, the IETF YANG data models for L3VPN service delivery [RFC8299] or L2VPN service delivery [RFC8466] could be used instead of the YANG data model defined in [NSSM], as they support conveying the bandwidth information in the right-most column of the traffic matrix.
プロバイダー ネットワークで使用される帯域幅モデル (セクション 7.2) によっては、マトリックスの他の値、つまり DC 間の要求がプロバイダー ネットワークに直接適用されない場合があります。それでも、この情報は NSC のキャパシティ プランニングや障害シミュレーションの目的に役立つ可能性があります。一方、DC-to-DC デマンド情報が NSC によって使用されない場合、[NSSM] で定義されている YANG データ モデルの代わりに、L3VPN サービス配信 [RFC8299] または L2VPN サービス配信用の IETF YANG データ モデル [RFC8466] を使用できます。これは、これらがトラフィック マトリックスの右端の列の帯域幅情報の伝達をサポートしているためです。
The provider network may be implemented in such a way that it has various types of paths, for example, low-latency traffic might be mapped onto a different transport path from other traffic (for example, a particular Flex-Algorithm, a particular set of TE paths, or a specific queue [RFC9330]), as discussed in Section 5. The 5G NSO can use the YANG data model defined in [NSSM] to request low-latency transport for a given slice if required. However, the YANG data models in [RFC8299] or [RFC8466] do not support requesting a particular transport-type, e.g., low-latency. One option is to augment these models to convey this information. This can be achieved by reusing the "underlay-transport" construct defined in [RFC9182] and [RFC9291].
プロバイダー ネットワークは、さまざまなタイプのパスを持つように実装できます。たとえば、セクション 5 で説明したように、低遅延トラフィックが他のトラフィックとは異なるトランスポート パス (たとえば、特定のフレックス アルゴリズム、特定の TE パスのセット、または特定のキュー [RFC9330]) にマッピングされる場合があります。5G NSO は、必要に応じて、[NSSM] で定義されている YANG データ モデルを使用して、特定のスライスの低遅延トランスポートを要求できます。ただし、[RFC8299] または [RFC8466] の YANG データ モデルは、特定のトランスポート タイプ (低遅延など) のリクエストをサポートしていません。1 つのオプションは、これらのモデルを拡張してこの情報を伝えることです。これは、[RFC9182] および [RFC9291] で定義されている「underlay-transport」構造を再利用することで実現できます。
This section describes three bandwidth management schemes that could be employed in the provider network. Many variations are possible, but each example describes the salient points of the corresponding scheme. Schemes 2 and 3 use TE; other variations on TE are possible as described in [RFC9522].
このセクションでは、プロバイダー ネットワークで使用できる 3 つの帯域幅管理スキームについて説明します。多くのバリエーションが可能ですが、各例では対応するスキームの重要な点を説明します。スキーム 2 と 3 は TE を使用します。[RFC9522] で説明されているように、TE の他のバリエーションも可能です。
Shortest path forwarding is used according to the IGP metric. Given that some slices are likely to have latency SLOs, the IGP metric on each link can be set to be in proportion to the latency of the link. In this way, all traffic follows the minimum latency path between endpoints.
IGP メトリックに従って最短パス転送が使用されます。一部のスライスには遅延 SLO がある可能性があることを考慮して、各リンクの IGP メトリックをリンクの遅延に比例するように設定できます。このようにして、すべてのトラフィックはエンドポイント間の最小遅延パスに従います。
In Scheme 1, although the operator provides bandwidth guarantees to the slice customers, there is no explicit end-to-end underpinning of the bandwidth SLO, in the form of bandwidth reservations across the provider network. Rather, the expected performance is achieved via capacity planning, based on traffic growth trends and anticipated future demands, in order to ensure that network links are not over-subscribed. This scheme is analogous to that used in many existing business VPN deployments, in that bandwidth guarantees are provided to the customers but are not explicitly underpinned end to end across the provider network.
スキーム 1 では、オペレーターはスライス顧客に帯域幅保証を提供しますが、プロバイダー ネットワーク全体にわたる帯域幅予約の形で、帯域幅 SLO の明示的なエンドツーエンドの基盤はありません。むしろ、ネットワーク リンクがオーバーサブスクリプションにならないように、トラフィックの増加傾向と予想される将来の需要に基づいた容量計画を通じて、期待されるパフォーマンスが達成されます。このスキームは、帯域幅保証が顧客に提供されますが、プロバイダー ネットワーク全体でエンドツーエンドで明示的に裏付けられていないという点で、多くの既存のビジネス VPN 導入で使用されているスキームに似ています。
A variation on the scheme is that Flex-Algorithm [RFC9350] is used. For example, one Flex-Algorithm could use latency-based metrics, and another Flex-Algorithm could use the IGP metric. There would be a many-to-one mapping of network slices to Flex-Algorithms.
このスキームのバリエーションとして、Flex-Algorithm [RFC9350] が使用されます。たとえば、あるフレックス アルゴリズムでは遅延ベースのメトリックを使用し、別のフレックス アルゴリズムでは IGP メトリックを使用できます。ネットワーク スライスからフレックス アルゴリズムへの多対 1 のマッピングが存在します。
While Scheme 1 is technically feasible, it is vulnerable to unexpected changes in traffic patterns and/or network element failures resulting in congestion. This is because, unlike Schemes 2 and 3, which employ TE, traffic cannot be diverted from the shortest path.
スキーム 1 は技術的には実現可能ですが、トラフィック パターンの予期せぬ変化や輻輳を引き起こすネットワーク要素の障害に対して脆弱です。これは、TE を使用する方式 2 および 3 とは異なり、トラフィックを最短パスから迂回できないためです。
Scheme 2 uses RSVP-TE [RFC3209] or SR-TE [RFC9256] paths with fixed bandwidth reservations. By "fixed", we mean a value that stays constant over time, unless the 5G NSO communicates a change in slice bandwidth requirements, due to the creation or modification of a slice. Note that the "reservations" may be maintained by the transport controller; it is not necessary (or indeed possible for current SR-TE technology at the time of writing this document) to reserve bandwidth at the network layer. The bandwidth requirement acts as a constraint whenever the controller (re)computes a path. There could be a single mesh of paths between endpoints that carry all of the traffic types, or there could be a small handful of meshes, for example, one mesh for low-latency traffic that follows the minimum latency path and another mesh for the other traffic that follows the minimum IGP metric path, as described in Section 5. There would be a many-to-one mapping of slices to paths.
スキーム 2 は、固定帯域幅予約を持つ RSVP-TE [RFC3209] または SR-TE [RFC9256] パスを使用します。「固定」とは、5G NSO がスライスの作成または変更によるスライス帯域幅要件の変更を通知しない限り、時間が経っても一定のままである値を意味します。「予約」はトランスポート コントローラによって維持される場合があることに注意してください。ネットワーク層で帯域幅を予約する必要はありません (または、このドキュメントの執筆時点での現在の SR-TE テクノロジーでは実際に可能です)。帯域幅要件は、コントローラーがパスを (再) 計算するたびに制約として機能します。すべてのトラフィック タイプを伝送するエンドポイント間に単一のパス メッシュが存在することも、たとえば、セクション 5 で説明したように、最小遅延パスに従う低遅延トラフィック用の 1 つのメッシュと、最小 IGP メトリック パスに従う他のトラフィック用の別のメッシュなど、少数のメッシュが存在する可能性があります。スライスとパスの多対 1 マッピングが存在します。
The bandwidth requirement from DCi to DCj is the sum of the DCi-DCj demands of the individual slices. For example, if only slices "X" and "Y" are present, then the bandwidth requirement from "DC 1" to "DC 2" is 12 units (8 units for slice "X" (Table 1) and 4 units for slice "Y" (Table 2)). When the 5G NSO requests a new slice, the NSC, increments the bandwidth requirement according to the requirements of the new slice. For example, in Figure 30, suppose a new slice is instantiated that needs 0.8 Gbps from "DC 1" to "DC 2". The transport controller would increase its notion of the bandwidth requirement from "DC 1" to "DC 2" from 12 Gbps to 12.8 Gbps to accommodate the additional expected traffic.
DCi から DCj までの帯域幅要件は、個々のスライスの DCi-DCj 要求の合計です。たとえば、スライス「X」と「Y」のみが存在する場合、「DC 1」から「DC 2」までの帯域幅要件は 12 ユニット（スライス「X」（表 1）では 8 ユニット、スライス「Y」（表 2）では 4 ユニット）です。5G NSO が新しいスライスを要求すると、NSC は新しいスライスの要件に従って帯域幅要件を増分します。たとえば、図 30 で、「DC 1」から「DC 2」まで 0.8 Gbps を必要とする新しいスライスがインスタンス化されたとします。トランスポート コントローラーは、予想される追加のトラフィックに対応するために、「DC 1」から「DC 2」までの帯域幅要件の概念を 12 Gbps から 12.8 Gbps に増加します。
+=========+======+======+======+===============+
| From/To | DC 1 | DC 2 | DC 3 | Total from DC |
+=========+======+======+======+===============+
| DC 1 | n/a | 4 | 2.5 | 6.0 |
+---------+------+------+------+---------------+
| DC 2 | 0.5 | n/a | 0.8 | 1.0 |
+---------+------+------+------+---------------+
| DC 3 | 2.6 | 3 | n/a | 5.1 |
+---------+------+------+------+---------------+
Table 2: Inter-DC Traffic Demand Matrix (Slice Y)
表 2: DC 間のトラフィック需要マトリックス (スライス Y)
In the example, each DC has two PEs facing it for reasons of resilience. The NSC needs to determine how to map the "DC 1" to "DC 2" bandwidth requirement to bandwidth reservations of TE LSPs from "DC 1" to "DC 2". For example, if the routing configuration is arranged such that in the absence of any network failure, traffic from "DC 1" to "DC 2" always enters "PE1A" and goes to "PE2A", the controller reserves 12.8 Gbps of bandwidth on the path from "PE1A" to "PE2A". On the other hand, if the routing configuration is arranged such that in the absence of any network failure, traffic from "DC 1" to "DC 2" always enters "PE1A" and is load-balanced across "PE2A" and "PE2B", the controller reserves 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2A" and 6.4 Gbps of bandwidth on the path from "PE1A" to "PE2B". It might be tricky for the NSC to be aware of all conditions that change the way traffic lands on the various PEs and therefore know that it needs to change bandwidth reservations of paths accordingly. For example, there might be an internal failure within "DC 1" that causes traffic from "DC 1" to land on "PE1B" rather than "PE1A". The NSC may not be aware of the failure and therefore may not know that it now needs to apply bandwidth reservations to paths from "PE1B" to "PE2A" and "PE2B".
この例では、復元力の理由から、各 DC には 2 つの PE が対向しています。NSC は、「DC 1」から「DC 2」までの TE LSP の帯域幅予約に「DC 1」から「DC 2」の帯域幅要件をマッピングする方法を決定する必要があります。たとえば、ネットワーク障害がない場合、「DC 1」から「DC 2」へのトラフィックが常に「PE1A」に入り、「PE2A」に向かうようにルーティング設定が設定されている場合、コントローラは「PE1A」から「PE2A」へのパス上に 12.8 Gbps の帯域幅を予約します。一方、ネットワーク障害がない場合、「DC 1」から「DC 2」へのトラフィックが常に「PE1A」に入り、「PE2A」と「PE2B」の間でロード バランシングされるようにルーティング設定が設定されている場合、コントローラは「PE1A」から「PE2A」へのパスで 6.4 Gbps の帯域幅を予約し、「PE1A」から「PE1A」へのパスで 6.4 Gbps の帯域幅を予約します。「PE2B」。NSC が、トラフィックがさまざまな PE に到達する方法を変更するすべての条件を認識し、それに応じてパスの帯域幅予約を変更する必要があることを認識するのは難しい場合があります。たとえば、「DC 1」内に内部障害が発生し、「DC 1」からのトラフィックが「PE1A」ではなく「PE1B」に到達する可能性があります。NSC は障害を認識していない可能性があるため、「PE1B」から「PE2A」および「PE2B」へのパスに帯域幅予約を適用する必要があることを認識していない可能性があります。
Like Scheme 2, Scheme 3 uses RSVP-TE or SR-TE paths. There could be a single mesh of paths between endpoints that carry all of the traffic types, or there could be a small handful of meshes, for example, one mesh for low-latency traffic that follows the minimum latency path and another mesh for the other traffic that follows the minimum IGP metric path, as described in Section 5. There would be a many-to-one mapping of slices to paths.
スキーム 2 と同様に、スキーム 3 は RSVP-TE または SR-TE パスを使用します。すべてのトラフィック タイプを伝送するエンドポイント間に単一のパス メッシュが存在することも、たとえば、セクション 5 で説明したように、最小遅延パスに従う低遅延トラフィック用の 1 つのメッシュと、最小 IGP メトリック パスに従う他のトラフィック用の別のメッシュなど、少数のメッシュが存在する可能性があります。スライスとパスの多対 1 マッピングが存在します。
The difference between Scheme 2 and Scheme 3 is that Scheme 3 does not have fixed bandwidth reservations for the paths. Instead, actual measured data plane traffic volumes are used to influence the placement of TE paths. One way of achieving this is to use distributed RSVP-TE with auto-bandwidth. Alternatively, the NSC can use telemetry-driven automatic congestion avoidance. In this approach, when the actual traffic volume in the data plane on a given link exceeds a threshold, the controller, knowing how much actual data plane traffic is currently traveling along each RSVP or SR-TE path, can tune one or more paths using the link such that they avoid that link. This approach is similar to that described in Section 4.3.1 of [RFC9522].
方式 2 と方式 3 の違いは、方式 3 にはパスの固定帯域幅予約がないことです。代わりに、実際に測定されたデータ プレーン トラフィック量が TE パスの配置に影響を与えるために使用されます。これを実現する 1 つの方法は、自動帯域幅を備えた分散型 RSVP-TE を使用することです。あるいは、NSC はテレメトリ主導の自動輻輳回避を使用できます。このアプローチでは、特定のリンク上のデータ プレーンの実際のトラフィック量がしきい値を超えると、各 RSVP または SR-TE パスに沿って実際にどれだけのデータ プレーン トラフィックが現在移動しているかを把握しているコントローラは、そのリンクを回避するようにリンクを使用して 1 つ以上のパスを調整できます。このアプローチは、[RFC9522] のセクション 4.3.1 で説明されているものと似ています。
It would be undesirable to move a path that has latency as its cost function, rather than another type of path, in order to ease the congestion, as the altered path will typically have a higher latency. This can be avoided by designing the algorithms described in the previous paragraph such that they avoid moving minimum-latency paths unless there is no alternative.
変更されたパスの遅延は通常より高くなるため、輻輳を緩和するために別のタイプのパスではなく、コスト関数として遅延を持つパスを移動することは望ましくありません。これは、代替手段がない限り、最小遅延パスの移動を回避するように、前の段落で説明したアルゴリズムを設計することで回避できます。
The deployment and maintenance of slices within a network imply that a set of OAM functions [RFC6291] need to be deployed by the providers, for example:
ネットワーク内でのスライスの展開とメンテナンスは、プロバイダーによって一連の OAM 機能 [RFC6291] を展開する必要があることを意味します。次に例を示します。
* Providers should be able to execute OAM tasks on a per-network-slice basis. These tasks can cover the "full" slice within a domain or a portion of that slice (for troubleshooting purposes, for example).
* プロバイダーは、ネットワーク スライスごとに OAM タスクを実行できる必要があります。これらのタスクは、ドメイン内の「完全な」スライス、またはそのスライスの一部をカバーできます (トラブルシューティング目的など)。
For example, per-slice OAM tasks can consist of (but not limited to):
たとえば、スライスごとの OAM タスクは次のもので構成できます (ただし、これらに限定されません)。
- tracing resources that are bound to a given network slice,
- 特定のネットワークスライスにバインドされているリソースをトレースします。
- tracing resources that are invoked when forwarding a given flow bound to a given network slice,
- 特定のネットワークスライスにバインドされた特定のフローを転送するときに呼び出されるリソースをトレースします。
- assessing whether flow isolation characteristics are in conformance with the Network Slice Service requirements, or
- フロー分離特性がネットワーク スライス サービスの要件に準拠しているかどうかを評価する、または
- assessing the compliance of the allocated network slice resources against flow and customer service requirements.
- 割り当てられたネットワーク スライス リソースがフローと顧客サービスの要件に準拠しているかを評価します。
[RFC7276] provides an overview of available OAM tools. These technology-specific tools can be reused in the context of network slicing. Providers that deploy network slicing capabilities should be able to select whatever OAM technology or specific feature that would address their needs.
[RFC7276] は、利用可能な OAM ツールの概要を提供します。これらのテクノロジー固有のツールは、ネットワーク スライシングのコンテキストで再利用できます。ネットワーク スライシング機能を導入するプロバイダーは、ニーズに対応する OAM テクノロジーや特定の機能を選択できる必要があります。
* Providers may want to enable differentiated failure detection and repair features for a subset of network slices. For example, a given network slice may require fast detection and repair mechanisms, while others may not be engineered with such means. The provider can use techniques such as those described in [RFC5286], [RFC5714], and [RFC8355].
* プロバイダーは、ネットワーク スライスのサブセットに対して差別化された障害検出および修復機能を有効にしたい場合があります。たとえば、特定のネットワーク スライスには高速な検出および修復メカニズムが必要な場合がありますが、他のネットワーク スライスにはそのような手段が設計されていない場合があります。プロバイダーは、[RFC5286]、[RFC5714]、および [RFC8355] で説明されているような技術を使用できます。
* Providers may deploy means to dynamically discover the set of network slices that are enabled within its network. Such dynamic discovery capability facilitates the detection of any mismatch between the view maintained by the control/management plane and the actual network configuration. When mismatches are detected, corrective actions should be undertaken accordingly. For example, a provider may rely upon the L3NM [RFC9182] or the L2NM [RFC9291] to maintain the full set of L2VPN/L3VPNs that are used to deliver Network Slice Services. The correlation between an L2VPN/L3VPN instance and a Network Slice Service is maintained using the "parent-service-id" attribute (Section 7.3 of [RFC9182]).
* プロバイダーは、ネットワーク内で有効になっているネットワーク スライスのセットを動的に検出する手段を展開する場合があります。このような動的な検出機能により、制御/管理プレーンによって維持されるビューと実際のネットワーク構成の間の不一致の検出が容易になります。不一致が検出された場合は、それに応じて修正措置を講じる必要があります。たとえば、プロバイダーは、ネットワーク スライス サービスの提供に使用される L2VPN/L3VPN の完全なセットを維持するために、L3NM [RFC9182] または L2NM [RFC9291] に依存する場合があります。L2VPN/L3VPN インスタンスとネットワーク スライス サービス間の相関関係は、「parent-service-id」属性 ([RFC9182] のセクション 7.3) を使用して維持されます。
* Providers should provide the means to report a set of network performance metrics to assess whether the agreed Slice Service objectives are honored. These means are used for SLO monitoring and violation detection purposes. For example, the YANG data model in [RFC9375] can be used to report the one-way delay and one-way delay variation of links. Both conventional active/ passive measurement methods [RFC7799] and more recent telemetry methods (e.g., YANG Push [RFC8641]) can be used.
* プロバイダーは、合意されたスライス サービスの目標が遵守されているかどうかを評価するために、一連のネットワーク パフォーマンス メトリックを報告する手段を提供する必要があります。これらの手段は、SLO の監視と違反の検出の目的で使用されます。たとえば、[RFC9375] の YANG データ モデルを使用して、リンクの一方向遅延と一方向遅延変動を報告できます。従来のアクティブ/パッシブ測定方法 [RFC7799] と、より最近のテレメトリ方法 (YANG Push [RFC8641] など) の両方を使用できます。
* Providers should have the means to report and expose observed performance metrics and other OAM state to customer. For example, the YANG data model defined in [NSSM] exposes a set of statistics per SDP, connectivity construct, and connection group.
* プロバイダーは、観察されたパフォーマンス メトリクスやその他の OAM 状態を報告し、顧客に公開する手段を備えている必要があります。たとえば、[NSSM] で定義されている YANG データ モデルは、SDP、接続構成、および接続グループごとの統計のセットを公開します。
The mapping of 5G Network Slices to Transport Network Slices (see Section 3.5) is a design choice of service operators that may be a function of, e.g., the number of instantiated slices, requested services, or local engineering capabilities and guidelines. However, operators should carefully consider means to ease slice migration strategies. For example, a provider may initially adopt a 1-to-1 mapping if it has to instantiate just a few network slices and accommodate the need of only a few customers. That provider may decide to move to an M-to-1 mapping for aggregation/scalability purposes if sustained increased slice demand is observed.
5G ネットワーク スライスのトランスポート ネットワーク スライスへのマッピング (セクション 3.5 を参照) は、サービス オペレータの設計上の選択であり、インスタンス化されたスライスの数、要求されたサービス、またはローカル エンジニアリング能力とガイドラインなどに応じて決まります。ただし、オペレータは、スライスの移行戦略を容易にする手段を慎重に検討する必要があります。たとえば、プロバイダーは、少数のネットワーク スライスをインスタンス化し、少数の顧客のニーズのみに対応する必要がある場合、最初に 1 対 1 マッピングを採用することがあります。スライス需要の継続的な増加が観察された場合、そのプロバイダーは、集約/スケーラビリティの目的で M 対 1 マッピングへの移行を決定する可能性があります。
Putting in place adequate automation means to realize network slices (including the adjustment of the mapping of Slice Services to network slices) would ease slice migration operations.
ネットワーク スライスを実現するための適切な自動化手段 (ネットワーク スライスへのスライス サービスのマッピングの調整を含む) を導入すると、スライスの移行操作が容易になります。
The realization model described in this document inherits the scalability properties of the underlying L2VPN and L3VPN technologies (Section 3.7). Readers may refer, for example, to Section 13 of [RFC4365] or Section 1.2.5 of [RFC6624] for a scalability assessment of some of these technologies. Providers may adjust the mapping model to better handle local scalability constraints.
このドキュメントで説明されている実現モデルは、基礎となる L2VPN および L3VPN テクノロジーのスケーラビリティ特性を継承しています (セクション 3.7)。読者は、これらのテクノロジーの一部のスケーラビリティ評価について、たとえば [RFC4365] のセクション 13 または [RFC6624] のセクション 1.2.5 を参照することができます。プロバイダーは、ローカルのスケーラビリティ制約をより適切に処理するためにマッピング モデルを調整する場合があります。
This document has no IANA actions.
この文書には IANA のアクションはありません。
Section 10 of [RFC9543] discusses generic security considerations that are applicable to network slicing, with a focus on the following considerations:
[RFC9543] のセクション 10 では、次の考慮事項に焦点を当てて、ネットワーク スライシングに適用できる一般的なセキュリティに関する考慮事項について説明します。
Conformance to security constraints:
セキュリティ制約への準拠:
Specific security requests, such as not routing traffic through a particular geographical region can be met by mapping the traffic to an underlay transport (Section 6) that avoids that region.
特定の地理的領域を介してトラフィックをルーティングしないなどの特定のセキュリティ要求は、その領域を回避するアンダーレイ トランスポート (セクション 6) にトラフィックをマッピングすることで満たすことができます。
NSC authentication:
NSC認証:
Per [RFC9543], underlay networks need to be protected against attacks from an adversary NSC as this could destabilize overall network operations. The interaction between an NSC and the underlay network is used to pass service provisioning requests following a set of YANG modules that are designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols have to use (1) a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) mutual authentication.
[RFC9543] によれば、アンダーレイ ネットワークは、ネットワーク運用全体を不安定にする可能性があるため、敵対的な NSC からの攻撃から保護する必要があります。NSC とアンダーレイ ネットワーク間の対話は、NETCONF [RFC6241] や RESTCONF [RFC8040] などの YANG ベースの管理プロトコル経由でアクセスするように設計された一連の YANG モジュールに続くサービス プロビジョニング リクエストを渡すために使用されます。これらの YANG ベースの管理プロトコルは、(1) 安全なトランスポート層 (SSH [RFC4252]、TLS [RFC8446]、QUIC [RFC9000] など)、および (2) 相互認証を使用する必要があります。
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
NETCONF アクセス制御モデル [RFC8341] は、特定の NETCONF または RESTCONF ユーザーのアクセスを、利用可能なすべての NETCONF または RESTCONF プロトコルの操作およびコンテンツの事前設定されたサブセットに制限する手段を提供します。
Readers may refer to documents that describe NSC realization, such as [NSC-MODEL].
読者は、[NSC-MODEL] など、NSC の実現について説明した文書を参照できます。
Specific isolation criteria:
具体的な隔離基準:
Adequate admission control policies, for example, policers as described in Section 5.2.1.1, should be configured in the edge of the provider network to control access to specific slice resources. This prevents the possibility of one slice consuming resources at the expense of other slices. Likewise, access to classification and mapping tables have to be controlled to prevent misbehaviors (an unauthorized entity may modify the table to bind traffic to a random slice, redirect the traffic, etc.). Network devices have to check that a required access privilege is provided before granting access to specific data or performing specific actions.
特定のスライス リソースへのアクセスを制御するには、適切なアドミッション コントロール ポリシー (セクション 5.2.1.1 で説明するポリサーなど) をプロバイダー ネットワークのエッジに設定する必要があります。これにより、1 つのスライスが他のスライスを犠牲にしてリソースを消費する可能性が回避されます。同様に、分類テーブルとマッピング テーブルへのアクセスは、不正行為を防ぐために制御する必要があります (無許可のエンティティがテーブルを変更して、トラフィックをランダム スライスにバインドしたり、トラフィックをリダイレクトしたりする可能性があります)。ネットワーク デバイスは、特定のデータへのアクセスを許可したり、特定のアクションを実行したりする前に、必要なアクセス権限が提供されていることを確認する必要があります。
Data Confidentiality and Integrity of an RFC 9543 Network Slice:
RFC 9543 ネットワーク スライスのデータの機密性と完全性:
As described in Section 5.1.2.1 of [RFC9543], the customer might request a Service Level Expectation (SLE) that mandates encryption.
[RFC9543] のセクション 5.1.2.1 に記載されているように、顧客は暗号化を義務付ける Service Level Expectation (SLE) を要求する場合があります。
This can be achieved, e.g., by mapping the traffic to an underlay transport (Section 6) that uses only MACsec-encrypted links.
これは、たとえば、MACsec で暗号化されたリンクのみを使用するアンダーレイ トランスポート (セクション 6) にトラフィックをマッピングすることによって実現できます。
In order to avoid the need for a mapping table to associate source/ destination IP addresses and the specific S-NSSAIs of slices, 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 from within the Transport Network who has access to the mapping configuration may infer the slices to which a packet belongs. It may also alter these bits, which may lead to steering the packet via a distinct network slice and thus to service disruption. Note that such an attacker from within the Transport Network may inflict more damage (e.g., randomly drop packets).
送信元/宛先 IP アドレスとスライスの特定の S-NSSAI を関連付けるマッピング テーブルの必要性を回避するために、セクション 4.2 では、アルゴリズム アプローチを使用して一部またはすべての S-NSSAI ビットを IPv6 アドレスに埋め込むアプローチについて説明します。マッピング構成にアクセスできるトランスポート ネットワーク内からの攻撃者は、パケットが属するスライスを推測する可能性があります。また、これらのビットが変更される可能性があり、これにより、別個のネットワーク スライスを介してパケットがステアリングされ、サービスが中断される可能性があります。トランスポート ネットワーク内からのこのような攻撃者は、さらに多くの損害を与える可能性があることに注意してください (パケットをランダムにドロップするなど)。
Security considerations specific to each of the technologies and protocols listed in the document are discussed in the specification documents of each of these protocols. In particular, readers should refer to the "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)" [RFC4111], the "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)" (Section 6 of [RFC4365]), and the "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)" [RFC4381] for a comprehensive discussion about security considerations related to VPN technologies (including authentication and encryption between PEs, use of IPsec tunnels that terminate within the customer sites to protect user data, prevention of illegitimate traffic from entering a VPN instance, etc.). Also, readers may refer to Section 9 of [RFC9522] for a discussion about security considerations related to TE mechanisms.
この文書に記載されている各テクノロジーおよびプロトコルに固有のセキュリティに関する考慮事項は、これらの各プロトコルの仕様文書で説明されています。特に、読者は「プロバイダー提供の仮想プライベート ネットワーク (PPVPN) のセキュリティ フレームワーク」[RFC4111]、「BGP/MPLS IP 仮想プライベート ネットワーク (VPN) の適用性声明」([RFC4365] のセクション 6)、および「BGP/MPLS IP 仮想プライベート ネットワーク (VPN) のセキュリティの分析」を参照する必要があります。[RFC4381] VPN テクノロジーに関連するセキュリティ上の考慮事項 (PE 間の認証と暗号化、ユーザー データを保護するための顧客サイト内で終端する IPsec トンネルの使用、VPN インスタンスへの不正なトラフィックの侵入の防止などを含む) に関する包括的な議論については。また、TE メカニズムに関連するセキュリティ上の考慮事項については、[RFC9522] のセクション 9 を参照してください。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015,
<https://www.rfc-editor.org/info/rfc7608>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
[Book-5G] Peterson, L., Sunay, O., and B. Davie, "Private 5G: A
Systems Approach", 2023,
<https://5g.systemsapproach.org/>.
[ECPRI] Common Public Radio Interface, "Common Public Radio
Interface: eCPRI Interface Specification",
<https://www.cpri.info/downloads/
eCPRI_v_2.0_2019_05_10c.pdf>.
[IEEE802.1AE]
IEEE, "802.1AE: MAC Security (MACsec)",
<https://1.ieee802.org/security/802-1ae/>.
[MAPPING] Contreras, L. M., Ed., Bykov, I., Ed., and K. G.
Szarkowicz, Ed., "5QI to DiffServ DSCP Mapping Example for
Enforcement of 5G End-to-End Network Slice QoS", Work in
Progress, Internet-Draft, draft-cbs-teas-5qi-to-dscp-
mapping-05, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-cbs-teas-5qi-
to-dscp-mapping-05>.
[NG.113] GSMA, "NG.113: 5GS Roaming Guidelines", Version 4.0, May
2021, <https://www.gsma.com/newsroom/wp-content/
uploads//NG.113-v4.0.pdf>.
[NS-APP] Geng, X., Contreras, L. M., Ed., Rokui, R., Dong, J., and
I. Bykov, "IETF Network Slice Application in 3GPP 5G End-
to-End Network Slice", Work in Progress, Internet-Draft,
draft-ietf-teas-5g-network-slice-application-05, 7 July
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-5g-network-slice-application-05>.
[NS-IP-MPLS]
Saad, T., Beeram, V., Dong, J., Halpern, J., and S. Peng,
"Realizing Network Slices in IP/MPLS Networks", Work in
Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-06,
20 October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-ns-ip-mpls-06>.
[NSC-MODEL]
Contreras, L. M., Rokui, R., Tantsura, J., Wu, B., and X.
Liu, "IETF Network Slice Controller and its Associated
Data Models", Work in Progress, Internet-Draft, draft-
ietf-teas-ns-controller-models-06, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-
controller-models-06>.
[NSSM] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
"A YANG Data Model for the RFC 9543 Network Slice
Service", Work in Progress, Internet-Draft, draft-ietf-
teas-ietf-network-slice-nbi-yang-25, 9 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-nbi-yang-25>.
[O-RAN.WG9.XPSAAS]
O-RAN Alliance, "Xhaul Packet Switched Architectures and
Solutions", O-RAN.WG9.XPSAAS, Version 09.00, October 2025,
<https://specifications.o-ran.org/specifications>.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<https://www.rfc-editor.org/info/rfc2698>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4111] Fang, L., Ed., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
DOI 10.17487/RFC4111, July 2005,
<https://www.rfc-editor.org/info/rfc4111>.
[RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service
Two-Rate, Three-Color Marker with Efficient Handling of
in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July
2005, <https://www.rfc-editor.org/info/rfc4115>.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual Private
Networks (L3VPN) Operations and Management", RFC 4176,
DOI 10.17487/RFC4176, October 2005,
<https://www.rfc-editor.org/info/rfc4176>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4365,
DOI 10.17487/RFC4365, February 2006,
<https://www.rfc-editor.org/info/rfc4365>.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4381,
DOI 10.17487/RFC4381, February 2006,
<https://www.rfc-editor.org/info/rfc4381>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<https://www.rfc-editor.org/info/rfc4664>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual
Private Network (L2VPN) Operations, Administration, and
Maintenance (OAM) Requirements and Framework", RFC 6136,
DOI 10.17487/RFC6136, March 2011,
<https://www.rfc-editor.org/info/rfc6136>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<https://www.rfc-editor.org/info/rfc6624>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier-Grade NAT Deployments", RFC 7422,
DOI 10.17487/RFC7422, December 2014,
<https://www.rfc-editor.org/info/rfc7422>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7806] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping",
RFC 7806, DOI 10.17487/RFC7806, April 2016,
<https://www.rfc-editor.org/info/rfc7806>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <https://www.rfc-editor.org/info/rfc8100>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R.
Shakir, "Resiliency Use Cases in Source Packet Routing in
Networking (SPRING) Networks", RFC 8355,
DOI 10.17487/RFC8355, March 2018,
<https://www.rfc-editor.org/info/rfc8355>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
"Operational Security Considerations for IPv6 Networks",
RFC 9099, DOI 10.17487/RFC9099, August 2021,
<https://www.rfc-editor.org/info/rfc9099>.
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/info/rfc9182>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
S., and L. Munoz, "A YANG Network Data Model for Layer 2
VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
<https://www.rfc-editor.org/info/rfc9291>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/info/rfc9330>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9375] Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de
Dios, O., and B. Wen, "A YANG Data Model for Network and
VPN Service Performance Monitoring", RFC 9375,
DOI 10.17487/RFC9375, April 2023,
<https://www.rfc-editor.org/info/rfc9375>.
[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,
Q., and V. Lopez, "A YANG Network Data Model for Service
Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,
June 2023, <https://www.rfc-editor.org/info/rfc9408>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,
O., Barguil, S., and B. Wu, "YANG Data Models for Bearers
and Attachment Circuits as a Service (ACaaS)", RFC 9834,
DOI 10.17487/RFC9834, September 2025,
<https://www.rfc-editor.org/info/rfc9834>.
[RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O.,
Barguil, S., and B. Wu, "A Network YANG Data Model for
Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835,
September 2025, <https://www.rfc-editor.org/info/rfc9835>.
[TS-23.501]
3GPP, "System architecture for the 5G System (5GS)",
Version 19.5.0, Release 19, 3GPP TS 23.501, September
2025, <https://www.3gpp.org/ftp/Specs/
archive/23_series/23.501/23501-j50.zip>.
[TS-28.530]
3GPP, "Management and orchestration; Concepts, use cases
and requirements", Version 19.0.0, Release 19, 3GPP
TS 28.530, March 2025, <https://www.3gpp.org/ftp/Specs/
archive/28_series/28.530/28530-j00.zip>.
Different IPv6 address allocation schemes following the approach in Section 4.2 may be used, with one example allocation shown in Figure 31.
セクション 4.2 のアプローチに従ったさまざまな IPv6 アドレス割り当てスキームを使用できます。割り当ての一例を図 31 に示します。
NF-specific Reserved
(not slice specific) for S-NSSAI
<----------------------------><--------->
+----+----+----+----+----+----+----+----+
|xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ttdd:dddd|
+----+----+----+----+----+----+----+----+
<------------------128 bits------------->
tt - SST (8 bits)
dddddd - SD (24 bits)
Figure 31: Example of S-NSSAI Embedded into an IPv6 Address
図 31: IPv6 アドレスに埋め込まれた S-NSSAI の例
In reference to Figure 31, the most significant 96 bits of the IPv6 address are unique to the NF but do not carry any slice-specific information. The S-NSSAI information is embedded in the least significant 32 bits. The 96-bit part of the address may be structured by the provider, for example, on the geographical location or the DC identification. Refer to Section 2.1 of [RFC9099] for a discussion on the benefits of structuring an address plan around both services and geographic locations for more structured security policies in a network.
図 31 を参照すると、IPv6 アドレスの最上位 96 ビットは NF に固有ですが、スライス固有の情報は含まれません。S-NSSAI 情報は、最下位 32 ビットに埋め込まれます。アドレスの 96 ビット部分は、地理的位置や DC ID などに基づいてプロバイダーによって構築される場合があります。ネットワーク内でより構造化されたセキュリティ ポリシーを実現するために、サービスと地理的位置の両方に基づいてアドレス プランを構築する利点については、[RFC9099] のセクション 2.1 を参照してください。
Figure 32 uses the example from Figure 31 to demonstrate a slicing deployment, where the entire S-NSSAI is embedded into IPv6 addresses used by NFs. Let us consider that "NF-A" has a set of tunnel termination points with unique per-slice IP addresses allocated from 2001:db8:a::/96, while "NF-B" uses a set of tunnel termination points with per-slice IP addresses allocated from 2001:db8:b::/96. This example shows two slices: "customer A eMBB" (SST=1, SD=00001) and "customer B MIoT" (SST=3, SD=00003). For "customer A eMBB" slice, the tunnel IP addresses are auto-derived as the IP addresses {2001:db8:a::100:1, 2001:db8:b::100:1}, where {:0100:0001} is used as the last two octets. "customer B MIoT" slice (SST=3, SD=00003) tunnel uses the IP addresses {2001:db8:a::300:3, 2001:db8:b::300:3} and simply adds {:0300:0003} as the last two octets. Leading zeros are not represented in the resulting IPv6 addresses as per [RFC5952].
図 32 は、図 31 の例を使用して、S-NSSAI 全体が NF によって使用される IPv6 アドレスに埋め込まれているスライシング展開を示しています。「NF-A」には 2001:db8:a::/96 から割り当てられた一意のスライスごとの IP アドレスを持つ一連のトンネル終端ポイントがあり、「NF-B」には 2001:db8:b::/96 から割り当てられるスライスごとの IP アドレスを持つ一連のトンネル終端ポイントが使用されると考えてみましょう。この例では、「顧客 A eMBB」(SST=1、SD=00001) と「顧客 B MIoT」(SST=3、SD=00003) の 2 つのスライスを示しています。「顧客 A eMBB」スライスの場合、トンネル IP アドレスは IP アドレス {2001:db8:a::100:1, 2001:db8:b::100:1} として自動導出されます。ここで、{:0100:0001} は最後の 2 オクテットとして使用されます。「顧客 B MIoT」スライス (SST=3、SD=00003) トンネルは、IP アドレス {2001:db8:a::300:3, 2001:db8:b::300:3} を使用し、最後の 2 オクテットとして {:0300:0003} を追加するだけです。[RFC5952] に従って、結果の IPv6 アドレスでは先頭のゼロは表現されません。
2001:db8:a::/96 (NF-A) 2001:db8:b::/96 (NF-B)
2001:db8:a::100:1/128 2001:db8:b::100:1/128
| |
| + - - - - - - - - + eMBB (SST=1) |
| | | | |
+----v-+ +--+--+ Provider +---+-+ | +-----+ +-v----+
| | | | | | v | | | |
| o============*================*==========================o |
| NF +-------+ PE | | PE +-------+L2/L3+.......+ NF |
| o============*================*==========================o |
| | | | | | ^ | | | |
+----^-+ +--+--+ Network +---+-+ | +-----+ +-^----+
| | | | |
| + - - - - - - - - + MIoT (SST=3) |
| |
2001:db8:a::300:3/128 2001:db8:b::300:3/128
o Tunnel (IPsec, GTP-U, etc.) termination point
* SDP
Figure 32: Deployment Example with S-NSSAI Embedded into IPv6 Addresses
図 32: IPv6 アドレスに S-NSSAI が埋め込まれた展開例
The authors would like to thank Adrian Farrel, Joel Halpern, Tarek Saad, Greg Mirsky, Rüdiger Geib, Nicklous D. Morris, Daniele Ceccarelli, Bo Wu, Xuesong Geng, and Deborah Brungard for their review of this document and for providing valuable comments.
著者らは、この文書のレビューと貴重なコメントを提供してくれた Adrian Farrel、Joel Halpern、Tarek Saad、Greg Mirsky、Rüdiger Geib、Nicklous D. Morris、Daniele Ceccarelli、Bo Wu、Xuesong Geng、および Deborah Brungard に感謝の意を表します。
Special thanks to Jie Dong and Adrian Farrel for the detailed and careful reviews.
詳細かつ慎重なレビューをくださった Jie Dong 氏と Adrian Farrel 氏に心より感謝いたします。
Thanks to Alvaro Retana and Mike McBride for the rtg-dir reviews, Yoshifumi Nishida for the tsv-art review, Timothy Winters for the int-dir review, Lars Eggert for the genart review, Joseph Salowey for the secdir review, and Tim Wicinski for the opsdir review.
rtg-dir レビューの Alvaro Retana 氏と Mike McBride 氏、tsv-art レビューの西田佳史氏、int-dir レビューの Timothy Winters 氏、genart レビューの Lars Eggert 氏、secdir レビューの Joseph Salowey 氏、opsdir レビューの Tim Wicinski 氏に感謝します。
Thanks to Jim Guichard for the AD review.
AD のレビューをしてくれた Jim Guichard に感謝します。
Thanks to Erik Kline, Ketan Talaulikar, and Deb Cooley for the IESG review.
IESG のレビューに協力してくれた Erik Kline、Ketan Talaulikar、Deb Cooley に感謝します。
John Drake
Sunnyvale, CA
United States of America
Email: je_drake@yahoo.com
Ivan Bykov
Ribbon Communications
Tel Aviv
Israel
Email: ivan.bykov@rbbn.com
Reza Rokui
Ciena
Ottawa
Canada
Email: rrokui@ciena.com
Luay Jalil
Verizon
Dallas, TX
United States of America
Email: luay.jalil@verizon.com
Beny Dwi Setyawan
XL Axiata
Jakarta
Indonesia
Email: benyds@xl.co.id
Amit Dhamija
Rakuten
Bangalore
India
Email: amitd@arrcus.com
Mojdeh Amani
British Telecom
London
United Kingdom
Email: mojdeh.amani@bt.com
Krzysztof G. Szarkowicz (editor)
HPE
Wien
Austria
Email: kszarkowicz@juniper.net
Richard Roberts (editor)
Nokia
Rennes
France
Email: richard.roberts@nokia.com
Julian Lucek
HPE
London
United Kingdom
Email: jlucek@juniper.net
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
Luis M. Contreras
Telefonica
Ronda de la Comunicacion, s/n
Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: https://lmcontreras.com/