Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 9543 Old Dog Consulting
Category: Informational J. Drake, Ed.
ISSN: 2070-1721 Individual
R. Rokui
Ciena
S. Homma
NTT
K. Makhijani
Futurewei
L. Contreras
Telefonica
J. Tantsura
Nvidia
March 2024
This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.
このドキュメントでは、IETFテクノロジーから構築されたネットワークのコンテキストでのネットワークスライスについて説明しています。このタイプのネットワークスライスを記述するための「IETFネットワークスライス」という用語を定義し、IETFコンテキストでネットワークスライスの一般原則を確立します。
The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.
このドキュメントでは、IETFネットワークスライスを要求および操作するための一般的なフレームワーク、IETFネットワークスライスの特性、必要なシステムコンポーネントとインターフェイス、およびより特定のテクノロジーへの抽象要求のマッピングについて説明します。このドキュメントでは、関連する考慮事項についても監視とセキュリティを説明しています。
This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices.
このドキュメントは、IETFネットワークスライスの側面を説明または使用する他のIETFドキュメントで一貫した使用法を有効にするための関連用語の定義も提供します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9543.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9543で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Background
3. Terms and Abbreviations
3.1. Abbreviations
3.2. Core Terminology
4. IETF Network Slice
4.1. Definition and Scope of IETF Network Slice
4.2. IETF Network Slice Service
4.2.1. Connectivity Constructs
4.2.2. Mapping Traffic Flows to Network Realizations
4.2.3. Ancillary CEs
5. IETF Network Slice System Characteristics
5.1. Objectives for IETF Network Slices
5.1.1. Service Level Objectives
5.1.2. Service Level Expectations
5.2. IETF Network Slice Service Demarcation Points
5.3. IETF Network Slice Composition
6. Framework
6.1. IETF Network Slice Stakeholders
6.2. Expressing Connectivity Intents
6.3. IETF Network Slice Controller (NSC)
6.3.1. IETF Network Slice Controller Interfaces
6.3.2. Management Architecture
7. Realizing IETF Network Slices
7.1. An Architecture to Realize IETF Network Slices
7.2. Procedures to Realize IETF Network Slices
7.3. Applicability of ACTN to IETF Network Slices
7.4. Applicability of Enhanced VPNs to IETF Network Slices
7.5. Network Slicing and Aggregation in IP/MPLS Networks
7.6. Network Slicing and Service Function Chaining (SFC)
8. Isolation in IETF Network Slices
8.1. Isolation as a Service Requirement
8.2. Isolation in IETF Network Slice Realization
9. Management Considerations
10. Security Considerations
11. Privacy Considerations
12. IANA Considerations
13. Informative References
Appendix A. Examples
A.1. Multi-Point to Point Service
A.2. Service Function Chaining and Ancillary CEs
A.3. Hub and Spoke
A.4. Layer 3 VPN
A.5. Hierarchical Composition of Network Slices
A.6. Horizontal Composition of Network Slices
Acknowledgments
Contributors
Authors' Addresses
A number of use cases would benefit from a network service that supplements connectivity, such as that offered by a VPN service, with an assurance of meeting a set of specific network performance objectives. This connectivity and resource commitment is referred to as a "network slice" and is expressed in terms of connectivity constructs (see Section 4) and service objectives (see Section 5). Since the term "network slice" is rather generic and has wider or different interpretations within other standards bodies, the qualifying term "IETF" is used in this document to limit the scope of the network slices described to network technologies defined and standardized by the IETF. This document defines the concept of "IETF Network Slices" that provide connectivity coupled with a set of specific commitments of network resources between a number of endpoints (known as Service Demarcation Points (SDPs); see Sections 3.2 and 5.2) over a shared underlay network that utilizes IETF technology. The term "IETF Network Slice Service" is also introduced to describe the service requested by and provided to the service provider's customer.
多くのユースケースは、特定のネットワークパフォーマンス目標のセットを満たすことを保証するために、VPNサービスによって提供されるような接続性を補完するネットワークサービスの恩恵を受けるでしょう。この接続とリソースのコミットメントは「ネットワークスライス」と呼ばれ、接続コンストラクト（セクション4を参照）とサービス目標（セクション5を参照）で表現されます。「ネットワークスライス」という用語はかなり一般的であり、他の標準団体内でより広くまたは異なる解釈を持っているため、このドキュメントでは、IETFによって定義および標準化されたネットワークテクノロジーに記載されているネットワークスライスの範囲を制限するために、適格な用語「IETF」が使用されています。。このドキュメントでは、共有されたアンダーレイネットワーク上の多くのエンドポイント（Service Demarcation Points（SDPS）として知られている（SDP）として知られる多くのエンドポイント間のネットワークリソースの特定のコミットメントのセットと組み合わせた接続性を提供する「IETFネットワークスライス」の概念を定義します。IETFテクノロジーを利用します。「IETFネットワークスライスサービス」という用語は、サービスプロバイダーの顧客に要求され、提供されたサービスを説明するために導入されています。
It is intended that the terms "IETF Network Slice" and "IETF Network Slice Service" be used only in this document. Other documents that need to indicate the type of network slice or network slice service described in this document can use the terms "RFC 9543 Network Slice" and "RFC 9543 Network Slice Service".
このドキュメントでは、「IETFネットワークスライス」および「IETFネットワークスライスサービス」という用語を使用することを意図しています。このドキュメントで説明されているネットワークスライスまたはネットワークスライスサービスのタイプを示す必要がある他のドキュメントでは、「RFC 9543ネットワークスライス」および「RFC 9543ネットワークスライスサービス」という用語を使用できます。
This document also provides a general framework for requesting and operating IETF Network Slices. The framework is intended as a structure for discussing interfaces and technologies.
このドキュメントは、IETFネットワークスライスを要求および操作するための一般的なフレームワークも提供します。フレームワークは、インターフェイスとテクノロジーを議論するための構造として意図されています。
Services that might benefit from IETF Network Slices include but are not limited to:
IETFネットワークスライスの恩恵を受ける可能性のあるサービスには、以下が含まれますが、これらに限定されません。
* 5G services (e.g., enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC) -- see [TS23.501])
* 5Gサービス（例：強化されたモバイルブロードバンド（EMBB）、超信頼性および低レイテンシ通信（URLLC）、および大規模な機械型通信（MMTC） - [TS23.501]を参照）
* Network wholesale services
* ネットワーク卸売サービス
* Network infrastructure sharing among operators
* オペレーター間のネットワークインフラストラクチャ共有
* Network Function Virtualization (NFV) [NFVArch] connectivity and Data Center Interconnect
* ネットワーク関数仮想化（NFV）[NFVARCH]接続とデータセンターの相互接続
Further analysis of the needs of IETF Network Slice Service customers is provided in [USE-CASES].
IETFネットワークスライスサービスの顧客のニーズのさらなる分析は、[ユースケース]で提供されています。
IETF Network Slices are created and managed within the scope of one or more network technologies (e.g., IP, MPLS, and optical) that use an IETF-specified data plane and/or management/control plane. They are intended to enable a diverse set of applications with different requirements to coexist over a shared underlay network. A request for an IETF Network Slice Service is agnostic to the technology in the underlay network so as to allow customers to describe their network connectivity objectives in a common format, independent of the underlay technologies used.
IETFネットワークスライスは、IETF指定のデータプレーンおよび/または管理/コントロールプレーンを使用する1つ以上のネットワークテクノロジー（IP、MPLS、光学）の範囲内で作成および管理されます。これらは、共有されたアンダーレイネットワークを介して共存するさまざまな要件を持つ多様なアプリケーションセットを有効にすることを目的としています。IETFネットワークスライスサービスのリクエストは、使用されるアンダーレイテクノロジーとは無関係に、顧客が一般的な形式でネットワーク接続目標を説明できるようにするために、アンダーレイネットワークのテクノロジーに不可知論されます。
Many preexisting approaches to service delivery and traffic engineering already use mechanisms that can be considered as network slicing. For example, Virtual Private Networks (VPNs) have served the industry well as a means of providing different groups of users with logically isolated access to a common network. The common or base network that is used to support the VPNs is often referred to as an "underlay network", and the VPN is often called an "overlay network". An overlay network may, in turn, serve as an underlay network to support another overlay network.
サービス提供とトラフィックエンジニアリングに対する多くの既存のアプローチは、ネットワークスライスと見なすことができるメカニズムをすでに使用しています。たとえば、仮想プライベートネットワーク（VPN）は、一般的なネットワークへの論理的に孤立したアクセスをユーザーのさまざまなグループに提供する手段として業界に役立っています。VPNをサポートするために使用される一般的またはベースネットワークは、しばしば「アンダーレイネットワーク」と呼ばれ、VPNは「オーバーレイネットワーク」と呼ばれることがよくあります。オーバーレイネットワークは、別のオーバーレイネットワークをサポートするためのアンダーレイネットワークとして機能する場合があります。
Note that it is conceivable that extensions to IETF technologies are needed in order to fully support all the capabilities that can be implemented with network slices. Evaluation of existing technologies, proposed extensions to existing protocols and interfaces, and creation of new protocols or interfaces are outside the scope of this document.
ネットワークスライスで実装できるすべての機能を完全にサポートするためには、IETFテクノロジーへの拡張が必要であると考えられることに注意してください。既存のテクノロジーの評価、既存のプロトコルとインターフェイスへの拡張提案、および新しいプロトコルまたはインターフェイスの作成は、このドキュメントの範囲外です。
The concept of network slicing has gained traction, driven largely by needs surfacing from 5G (see [NGMN-NS-Concept], [TS23.501], and [TS28.530]). In [TS23.501], a Network Slice is defined as a "logical network that provides specific network capabilities and network characteristics", and a Network Slice Instance is defined as a "set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice". According to [TS28.530], an end-to-end (E2E) network slice consists of three major types of network segments: Radio Access Network (RAN), Transport Network (TN), and Core Network (CN). An IETF Network Slice provides the required connectivity between different entities in RAN and CN segments of an end-to-end network slice, with a specific performance commitment (for example, serving as a TN slice). For each end-to-end network slice, the topology and performance requirement on a customer's use of an IETF Network Slice can be very different, which requires the underlay network to have the capability of supporting multiple different IETF Network Slices.
ネットワークスライスの概念は、主に5G（[NGMN-NS概念]、[TS23.501]、[TS28.530]を参照）から浮上するニーズによって主に駆動される牽引力を獲得しました。[TS23.501]では、ネットワークスライスは「特定のネットワーク機能とネットワーク特性を提供する論理ネットワーク」として定義され、ネットワークスライスインスタンスは「ネットワーク機能インスタンスのセットと必要なリソース（例：Compute、Compute、展開されたネットワークスライスを形成するストレージおよびネットワーキングリソース）。[TS28.530]によれば、エンドツーエンド（E2E）ネットワークスライスは、3つの主要なタイプのネットワークセグメントで構成されています：ラジオアクセスネットワーク（RAN）、トランスポートネットワーク（TN）、およびコアネットワーク（CN）。IETFネットワークスライスは、特定のパフォーマンスコミットメントを備えた、End-to-EndネットワークスライスのRANおよびCNセグメントの異なるエンティティ間の必要な接続を提供します（たとえば、TNスライスとして機能します）。各エンドツーエンドネットワークスライスについて、IETFネットワークスライスの顧客の使用に関するトポロジとパフォーマンスの要件は非常に異なる場合があります。これにより、アンダーレイネットワークは、複数の異なるIETFネットワークスライスをサポートする機能を持つ必要があります。
While network slices are commonly discussed in the context of 5G, it is important to note that IETF Network Slices are a narrower concept with a broader usage profile and focus primarily on particular network connectivity aspects. Other systems, including 5G deployments, may use IETF Network Slices as a component to create entire systems and concatenated constructs that match their needs, including end-to-end connectivity.
ネットワークスライスは5Gのコンテキストで一般的に説明されていますが、IETFネットワークスライスはより広い使用法プロファイルを備えた狭い概念であり、主に特定のネットワーク接続の側面に焦点を当てることに注意することが重要です。5G展開を含む他のシステムは、IETFネットワークスライスをコンポーネントとして使用して、エンドツーエンドの接続を含むニーズに合ったシステム全体と連結構成要素を作成する場合があります。
An IETF Network Slice could span multiple technologies and multiple administrative domains. Depending on the IETF Network Slice Service customer's requirements, an IETF Network Slice could be isolated from other, often concurrent, IETF Network Slices in terms of data, control, and management planes.
IETFネットワークスライスは、複数のテクノロジーと複数の管理ドメインにまたがる可能性があります。IETFネットワークスライスサービスの顧客の要件に応じて、IETFネットワークスライスは、データ、制御、および管理プレーンの観点から、他の、同時のIETFネットワークスライスから分離できます。
The customer expresses requirements for a particular IETF Network Slice Service by specifying what is required rather than how the requirement is to be fulfilled. That is, the IETF Network Slice Service customer's view of an IETF Network Slice Service is an abstract one.
顧客は、要件がどのように満たされるかではなく、必要なものを指定することにより、特定のIETFネットワークスライスサービスの要件を表明します。つまり、IETFネットワークスライスサービス顧客のIETFネットワークスライスサービスのビューは、抽象的なものです。
Thus, there is a need to create logical network structures with required characteristics. The customer of such a logical network can require a level of isolation and performance that previously might not have been satisfied by overlay VPNs. Additionally, the IETF Network Slice Service customer might ask for some level of control to, e.g., customize the service paths in a network slice.
したがって、必要な特性を持つ論理ネットワーク構造を作成する必要があります。このような論理ネットワークの顧客は、以前はオーバーレイVPNで満たされていなかったかもしれないレベルの分離とパフォーマンスを必要とする場合があります。さらに、IETFネットワークスライスサービスの顧客は、たとえば、ネットワークスライスのサービスパスをカスタマイズするためのある程度の制御を要求する場合があります。
This document specifies definitions and a framework for the provision of an IETF Network Slice Service. Section 7 briefly indicates some candidate technologies for realizing IETF Network Slices.
このドキュメントは、IETFネットワークスライスサービスの提供のための定義とフレームワークを指定します。セクション7では、IETFネットワークスライスを実現するためのいくつかの候補技術を簡単に示します。
The following abbreviations are used in this document.
このドキュメントでは、次の略語が使用されています。
NSC:
NSC：
Network Slice Controller
ネットワークスライスコントローラー
SDP:
SDP：
Service Demarcation Point
サービス境界点
SLA:
SLA：
Service Level Agreement
サービスレベル契約
SLE:
SLE：
Service Level Expectation
サービスレベルの期待
SLI:
SLI：
Service Level Indicator
サービスレベルインジケーター
SLO:
SLO：
Service Level Objective
サービスレベルの目的
The meaning of these abbreviations is defined in greater detail in the remainder of this document.
これらの略語の意味は、このドキュメントの残りの部分でより詳細に定義されています。
The following terms are presented here to give context. Other terminology is defined in the remainder of this document.
ここでは、コンテキストを提供するために次の用語を示します。他の用語は、このドキュメントの残りの部分で定義されています。
Customer:
お客様：
The requester of an IETF Network Slice Service. Customers may request monitoring of SLOs. A customer may be an entity such as an enterprise network or a network operator, an individual working at such an entity, a private individual contracting for a service, or an application or software component. A customer may be an external party (classically, a paying customer) or a division of a network operator that uses the service provided by another division of the same operator. Other terms that have been applied to the customer role are "client" and "consumer".
IETFネットワークスライスサービスの要求者。顧客はスロの監視を要求する場合があります。顧客は、エンタープライズネットワークやネットワークオペレーターなどのエンティティ、そのようなエンティティで働く個人、サービスのために契約する個人、またはアプリケーションまたはソフトウェアコンポーネントです。顧客は、外部の当事者（古典的に、有料顧客）または同じオペレーターの別の部門が提供するサービスを使用するネットワークオペレーターの部門である場合があります。顧客の役割に適用されたその他の用語は、「クライアント」と「消費者」です。
Provider:
プロバイダー：
The organization that delivers an IETF Network Slice Service. A provider is the network operator that controls the network resources used to construct the network slice (that is, the network that is sliced). The provider's network may be a physical network or a virtual network created within the operator's network or supplied by another service provider.
IETFネットワークスライスサービスを提供する組織。プロバイダーは、ネットワークスライス（つまりスライスされたネットワーク）の構築に使用されるネットワークリソースを制御するネットワークオペレーターです。プロバイダーのネットワークは、オペレーターのネットワーク内で作成された、または別のサービスプロバイダーによって提供される物理ネットワークまたは仮想ネットワークである場合があります。
Customer Edge (CE):
カスタマーエッジ（CE）：
The customer device that provides connectivity to a service provider. Examples include routers, Ethernet switches, firewalls, 4G/5G RAN or Core nodes, application accelerators, server load balancers, HTTP header enrichment functions (such as proxy components adding the Forwarded HTTP Extension Header [RFC7239]), and Performance Enhancing Proxies (PEPs). In some circumstances, CEs are provided to the customer and managed by the provider.
サービスプロバイダーへの接続を提供する顧客デバイス。例には、ルーター、イーサネットスイッチ、ファイアウォール、4G/5G RANまたはコアノード、アプリケーションアクセラレータ、サーバーロードバランサー、HTTPヘッダー濃縮関数（転送されたHTTP拡張ヘッダーの追加プロキシコンポーネント[RFC7239]など）、およびパフォーマンスエンパニエーション（Peps）。状況によっては、CESが顧客に提供され、プロバイダーによって管理されます。
Provider Edge (PE):
プロバイダーエッジ（PE）：
The device within the provider network to which a CE is attached. A CE may be attached to multiple PEs, and multiple CEs may be attached to a given PE.
CEが接続されているプロバイダーネットワーク内のデバイス。CEが複数のPEに取り付けられ、複数のCEが特定のPEに接続される場合があります。
Attachment Circuit (AC):
アタッチメント回路（AC）：
A channel connecting a CE and a PE over which packets that belong to an IETF Network Slice Service are exchanged. An AC is, by definition, technology specific: that is, the AC defines how customer traffic is presented to the provider network. The customer and provider agree (for example, through configuration) on which values in which combination of Layer 2 (L2) and Layer 3 (L3) header and payload fields within a packet identify to which {IETF Network Slice Service, connectivity construct, and SLOs/SLEs} that packet is assigned. The customer and provider may agree to police or shape traffic, based on the specific IETF Network Slice Service including connectivity construct and SLOs/SLEs, on the AC in both the ingress (CE to PE) direction and egress (PE to CE) direction. This ensures that the traffic is within the capacity profile that is agreed upon in an IETF Network Slice Service. Excess traffic is dropped by default, unless specific out-of-profile policies are agreed upon between the customer and the provider. As described in Section 5.2, the AC may be part of the IETF Network Slice Service or may be external to it. Because SLOs and SLEs characterize the performance of the underlay network between a sending SDP and a set of receiving SDPs, the traffic policers and traffic shapers apply to a specific connectivity construct on an AC.
CEとPEを接続するチャネルと、IETFネットワークスライスサービスに属するパケットが交換されます。ACは、定義上、テクノロジー固有です。つまり、ACは顧客トラフィックがプロバイダーネットワークにどのように提示されるかを定義します。顧客とプロバイダーは、パケット内のレイヤー2（L2）とレイヤー3（L3）ヘッダーとペイロードフィールドの組み合わせが{IETFネットワークスライスサービス、接続コンストラクト、およびどのような識別されるかについて、顧客とプロバイダーが同意します（構成を通じて）同意します。そのパケットが割り当てられているスロ/スレ}。顧客とプロバイダーは、接続（CEからPE）方向と出口（PEからCE）方向の両方のACで、接続コンストラクトとスロ/スレースを含む特定のIETFネットワークスライスサービスに基づいて、警察または交通型に同意する場合があります。これにより、トラフィックがIETFネットワークスライスサービスで合意された容量プロファイル内にあることが保証されます。顧客とプロバイダーの間で特定のプロファイル外のポリシーが合意されていない限り、過剰なトラフィックはデフォルトで削除されます。セクション5.2で説明されているように、ACはIETFネットワークスライスサービスの一部であるか、外部である場合があります。SLOとSLEは、送信SDPとSDPを受信するセットの間のアンダーレイネットワークのパフォーマンスを特徴付けるため、トラフィックポリサーとトラフィックシェイパーがACの特定の接続コンストラクトに適用されます。
Service Demarcation Point (SDP):
サービス境界点（SDP）：
The point at which an IETF Network Slice Service is delivered by a service provider to a customer. Depending on the service delivery model (see Section 5.2), this may be a CE or a PE and could be a device, a software component, or an abstract virtual function supported within the provider's network. Each SDP must have a unique identifier (e.g., an IP address or Media Access Control (MAC) address) within a given IETF Network Slice Service and may use the same identifier in multiple IETF Network Slice Services.
IETFネットワークスライスサービスがサービスプロバイダーによって顧客に配信されるポイント。サービス提供モデル（セクション5.2を参照）に応じて、これはCEまたはPEであり、プロバイダーのネットワーク内でサポートされるデバイス、ソフトウェアコンポーネント、または抽象的な仮想関数である可能性があります。各SDPには、特定のIETFネットワークスライスサービス内に一意の識別子（例：IPアドレスまたはメディアアクセス制御（MAC）アドレス）が必要であり、複数のIETFネットワークスライスサービスで同じ識別子を使用することができます。
An SDP may be abstracted as a Service Attachment Point (SAP) [RFC9408] for the purpose of generalizing the concept across multiple service types and representing it in management and configuration systems.
SDPは、複数のサービスタイプに概念を一般化し、管理および構成システムで表現する目的で、サービスアタッチメントポイント（SAP）[RFC9408]として抽出される場合があります。
Connectivity Construct:
接続コンストラクト：
A set of SDPs together with a communication type that defines how traffic flows between the SDPs. An IETF Network Slice Service is specified in terms of a set of SDPs, the associated connectivity constructs, and the service objectives that the customer wishes to see fulfilled. Connectivity constructs may be grouped for administrative purposes.
SDPのセットと、SDP間のトラフィックがどのように流れるかを定義する通信タイプ。IETFネットワークスライスサービスは、SDPのセット、関連する接続コンストラクト、および顧客が満たされたいと考えているサービス目標の観点から指定されています。接続コンストラクトは、管理目的でグループ化できます。
IETF Network Slices are created to meet specific requirements, typically expressed as bandwidth, latency, latency variation, and other desired or required characteristics. Creation of an IETF Network Slice is initiated by a management system or other application used to specify network-related conditions for particular traffic flows in response to an actual or logical IETF Network Slice Service request.
IETFネットワークスライスは、通常、帯域幅、遅延、レイテンシの変動、およびその他の望ましいまたは必要な特性として表される特定の要件を満たすために作成されます。IETFネットワークスライスの作成は、実際のIETFネットワークスライスサービス要求に応じて、特定のトラフィックフローのネットワーク関連条件を指定するために使用される管理システムまたはその他のアプリケーションによって開始されます。
Once created, these slices can be monitored, modified, deleted, and otherwise managed.
作成されると、これらのスライスは監視、変更、削除、およびその他の方法で管理できます。
Applications and components will be able to use these IETF Network Slices to move packets between the specified endpoints of the service in accordance with specified characteristics.
アプリケーションとコンポーネントは、これらのIETFネットワークスライスを使用して、指定された特性に従って指定されたサービスの指定されたエンドポイント間でパケットを移動できます。
A clear distinction should be made between the "IETF Network Slice Service" and the IETF Network Slice:
「IETFネットワークスライスサービス」とIETFネットワークスライスを明確に区別する必要があります。
IETF Network Slice Service:
IETFネットワークスライスサービス：
The function delivered to the customer (see Section 4.2). It is agnostic to the technologies and mechanisms used by the service provider.
顧客に配信される機能（セクション4.2を参照）。これは、サービスプロバイダーが使用する技術とメカニズムに不可知論されています。
IETF Network Slice:
IETFネットワークスライス：
The realization of the service in the provider's network achieved by partitioning network resources and by applying certain tools and techniques within the network (see Sections 4.1 and 7).
プロバイダーのネットワークでのサービスの実現は、ネットワークリソースを分割し、ネットワーク内の特定のツールと手法を適用することによって達成されました（セクション4.1および7を参照）。
The term "Slice" refers to a set of characteristics and behaviors that differentiate one type of user traffic from another within a network. An IETF Network Slice is a logical partition of a network that uses IETF technology. An IETF Network Slice assumes that an underlay network is capable of changing the configurations of the network devices on demand, through in-band signaling, or via controllers.
「スライス」という用語は、ネットワーク内のあるタイプのユーザートラフィックを別のタイプと区別する一連の特性と動作を指します。IETFネットワークスライスは、IETFテクノロジーを使用するネットワークの論理パーティションです。IETFネットワークスライスは、アンダーレイネットワークが、帯域内の信号、またはコントローラーを介して、デマンドでネットワークデバイスの構成を変更できると想定しています。
An IETF Network Slice enables connectivity between a set of SDPs with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) (see Section 5) over a common underlay network. The SLOs and SLEs characterize the performance of the underlay network between a sending SDP and a set of receiving SDPs. Thus, an IETF Network Slice delivers a service to a customer by meeting connectivity resource requirements and associated network capabilities such as bandwidth, latency, jitter, and network functions with other resource behaviors such as compute and storage availability.
IETFネットワークスライスは、特定のサービスレベル目標（SLO）とサービスレベルの期待（SLE）（SLE）（セクション5を参照）を持つ一連のSDP間の接続を可能にします。SLOSとSLESは、送信SDPとSDPの受信セットの間のアンダーレイネットワークのパフォーマンスを特徴付けます。したがって、IETFネットワークスライスは、接続リソースの要件と帯域幅、レイテンシ、ジッター、ネットワーク機能などの関連するネットワーク機能を、コンピューティングやストレージの可用性などの他のリソース動作との関連するネットワーク機能を満たすことにより、顧客にサービスを提供します。
IETF Network Slices may be combined hierarchically so that a network slice may itself be sliced. They may also be combined sequentially so that various different networks can each be sliced and the network slices placed into a sequence to provide an end-to-end service. This form of sequential combination is utilized in some services such as in 3GPP's 5G network [TS23.501].
IETFネットワークスライスを階層的に結合して、ネットワークスライス自体がスライスされる可能性があります。また、さまざまな異なるネットワークをスライスし、ネットワークスライスをシーケンスに配置してエンドツーエンドサービスを提供できるように、連続的に組み合わせることもできます。この形式の連続した組み合わせは、3GPPの5Gネットワーク[TS23.501]などの一部のサービスで使用されます。
It is intended that the term "IETF Network Slice" be used only in this document. Other documents that need to indicate the type of network slice described in this document can use the term "RFC 9543 Network Slice".
「IETFネットワークスライス」という用語は、このドキュメントでのみ使用することを意図しています。このドキュメントで説明されているネットワークスライスのタイプを示す必要がある他のドキュメントでは、「RFC 9543ネットワークスライス」という用語を使用できます。
A service provider delivers an IETF Network Slice Service for a customer by realizing an IETF Network Slice in the underlay network. The IETF Network Slice Service is agnostic to the technology of the underlay network, and its realization may be selected based upon multiple considerations, including its service requirements and the capabilities of the underlay network. This allows an IETF Network Slice Service customer to describe their network connectivity and relevant objectives in a common format, independent of the underlay technologies used.
サービスプロバイダーは、アンダーレイネットワークでIETFネットワークスライスを実現することにより、顧客向けのIETFネットワークスライスサービスを提供します。IETFネットワークスライスサービスは、アンダーレイネットワークのテクノロジーに対して不可知論されており、そのサービス要件やアンダーレイネットワークの機能など、複数の考慮事項に基づいてその実現が選択される場合があります。これにより、IETFネットワークスライスサービス顧客は、使用されるアンダーレイテクノロジーとは無関係に、共通の形式でネットワーク接続と関連する目標を説明できます。
The IETF Network Slice Service is specified in terms of a set of SDPs, a set of one or more connectivity constructs between subsets of these SDPs, and a set of SLOs and SLEs (see Section 5) for each SDP sending to each connectivity construct. A communication type (Point-to-Point (P2P), Point-to-Multipoint (P2MP), or Any-to-Any (A2A)) is specified for each connectivity construct. That is, in a given IETF Network Slice Service:
IETFネットワークスライスサービスは、SDPのセット、これらのSDPのサブセット間の1つまたは複数の接続コンストラクトのセット、および各SDPが各接続コンストラクトに送信する各SDPのSLOとSLEのセット（セクション5を参照）の観点から指定されています。通信型（ポイントツーポイント（P2P）、ポイントツーマルチポイント（P2MP）、または任意の（A2A））は、各接続コンストラクトに指定されています。つまり、特定のIETFネットワークスライスサービスで：
* There may be one or more connectivity constructs of the same or different type.
* 同じタイプまたは異なるタイプの1つ以上の接続コンストラクトがある場合があります。
* Each connectivity construct may be between a different subset of SDPs.
* 各接続コンストラクトは、SDPの異なるサブセット間にある場合があります。
* Each sending SDP has its own set of SLOs and SLEs for a given connectivity construct, and the SLOs and SLEs in each set may be different.
* それぞれの送信SDPには、特定の接続コンストラクト用の独自のスロとスレのセットがあり、各セットのスロとスレが異なる場合があります。
Note that different connectivity constructs can be specified in the service request, but the service provider may decide how many connectivity constructs per IETF Network Slice Service it wishes to support such that an IETF Network Slice Service may be limited to one connectivity construct or may support many.
さまざまな接続コンストラクトをサービスリクエストで指定できることに注意してくださいが、サービスプロバイダーは、IETFネットワークスライスサービスが1つの接続コンストラクトに制限されるか、多くのサポートできるようにサポートしたいIETFネットワークスライスサービスごとの接続コンストラクトの数を決定する場合があります。。
An IETF Network Slice Service customer may provide IETF Network Slice Services to other customers in a mode sometimes referred to as "carrier's carrier" (see Section 9 of [RFC4364]). In this case, the relationship between IETF Network Slice Service providers may be internal to a commercial organization or may be external through service provision contracts. As noted in Section 5.3, network slices may be composed hierarchically or serially.
IETFネットワークスライスサービスの顧客は、「キャリアのキャリア」と呼ばれるモードで、他の顧客にIETFネットワークスライスサービスを提供する場合があります（[RFC4364]のセクション9を参照）。この場合、IETFネットワークスライスサービスプロバイダー間の関係は、商業組織の内部であるか、サービス提供契約を通じて外部である場合があります。セクション5.3で述べたように、ネットワークスライスは階層的または連続的に構成される場合があります。
Section 5.2 provides a description of SDPs as endpoints in the context of IETF network slicing. For a given IETF Network Slice Service, the customer and provider agree, on a per-SDP basis, which end of the attachment circuit provides the SDP (i.e., whether the attachment circuit is inside or outside the IETF Network Slice Service). This determines whether the attachment circuit is subject to the set of SLOs and SLEs at the specific SDP.
セクション5.2は、IETFネットワークスライシングのコンテキストでのエンドポイントとしてのSDPの説明を示しています。特定のIETFネットワークスライスサービスの場合、顧客とプロバイダーはSDPごとに同意します。アタッチメント回路の終わりはSDPを提供します（つまり、アタッチメント回路がIETFネットワークスライスサービスの内側または外側にあるかどうか）。これにより、アタッチメント回路が特定のSDPでのSLOとSLESのセットの対象かどうかを決定します。
It is intended that the term "IETF Network Slice Service" be used only in this document. Other documents that need to indicate the type of network slice service described in this document can use the term "RFC 9543 Network Slice Service".
「IETFネットワークスライスサービス」という用語は、このドキュメントでのみ使用することを意図しています。このドキュメントで説明されているネットワークスライスサービスのタイプを示す必要がある他のドキュメントでは、「RFC 9543ネットワークスライスサービス」という用語を使用できます。
The approach of specifying a Network Slice Service as a set of SDPs with connectivity constructs results in the following possible connectivity constructs:
ネットワークスライスサービスを接続コンストラクトを持つSDPのセットとして指定するアプローチは、次の可能な接続コンストラクトをもたらします。
* For a P2P connectivity construct, there is one sending SDP and one receiving SDP. This construct is like a private wire or a tunnel. All traffic injected at the sending SDP is intended to be received by the receiving SDP. The SLOs and SLEs apply at the sender (and implicitly, at the receiver).
* P2P接続コンストラクトの場合、SDPを送信し、SDPを受信します。このコンストラクトは、プライベートワイヤーやトンネルのようなものです。送信SDPで注入されたすべてのトラフィックは、受信SDPが受信することを目的としています。SLOSとSLESは、送信者（および暗黙的にレシーバーに）に適用されます。
* For a P2MP connectivity construct, there is only one sending SDP and more than one receiving SDP. This is like a P2MP tunnel or multi-access VLAN segment. All traffic from the sending SDP is intended to be received by all the receiving SDPs. There is one set of SLOs and SLEs that applies at the sending SDP (and implicitly, at all receiving SDPs).
* P2MP接続コンストラクトの場合、SDPを送信するのは1つだけで、SDPを複数受信しています。これは、P2MPトンネルまたはマルチアクセスVLANセグメントのようなものです。送信SDPからのすべてのトラフィックは、受信するすべてのSDPが受信することを目的としています。送信SDPに適用されるSLOとSLESのセットが1つあります（および暗黙的に、すべてのSDPを受信します）。
* With an A2A connectivity construct, any sending SDP may send to any one receiving SDP or any set of receiving SDPs in the construct. There is an implicit level of routing in this connectivity construct that is not present in the other connectivity constructs because the provider's network must determine to which receiving SDPs to deliver each packet. This construct may be used to support P2P traffic between any pair of SDPs or to support multicast or broadcast traffic from one SDP to a set of other SDPs. In the latter case, whether the service is delivered using multicast within the provider's network or using "ingress replication" or some other means is out of scope of the specification of the service. A service provider may choose to support A2A constructs but to limit the traffic to unicast.
* A2A接続コンストラクトを使用すると、SDPを送信すると、SDPを受信しているSDPまたはコンストラクト内のSDPを受信するセットに送信できます。プロバイダーのネットワークが各パケットを配信するためにどのSDPを受信するかを決定する必要があるため、他の接続コンストラクトには存在しないこの接続コンストラクトには、暗黙のレベルのルーティングがあります。このコンストラクトは、SDPの任意のペア間のP2Pトラフィックをサポートしたり、1つのSDPから他のSDPのセットまでのマルチキャストまたはブロードキャストトラフィックをサポートするために使用できます。後者の場合、プロバイダーのネットワーク内でマルチキャストを使用してサービスが配信されるか、「イングレスレプリケーション」を使用するか、その他の手段を使用して、サービスの仕様の範囲外です。サービスプロバイダーは、A2Aコンストラクトをサポートするが、トラフィックをユニキャストに制限することを選択できます。
* The SLOs/SLEs in an A2A connectivity construct apply to individual sending SDPs regardless of the receiving SDPs, and there is no linkage between sender and receiver in the specification of the connectivity construct. A sending SDP may be "disappointed" if the receiver is over-subscribed. If a customer wants to be more specific about different behaviors from one SDP to another SDP, they should use P2P connectivity constructs.
* A2A接続コンストラクトのSLOS/SLESは、受信SDPに関係なく個々の送信SDPに適用され、接続コンストラクトの仕様には送信者とレシーバーの間にリンクはありません。受信者が過剰に登録されている場合、送信SDPは「失望」する場合があります。顧客が、あるSDPから別のSDPまでの異なる動作についてより具体的になりたい場合は、P2P接続コンストラクトを使用する必要があります。
A given sending SDP may be part of multiple connectivity constructs within a single IETF Network Slice Service, and the SDP may have different SLOs and SLEs for each connectivity construct to which it is sending. Note that a given sending SDP's SLOs and SLEs for a given connectivity construct apply between it and each of the receiving SDPs for that connectivity construct.
特定の送信SDPは、単一のIETFネットワークスライスサービス内の複数の接続コンストラクトの一部である可能性があり、SDPには、送信中の各接続コンストラクトのSLOとSLEが異なる場合があります。特定の接続コンストラクトのSDPのSLOとSLESを送信して、ITとその接続コンストラクトの受信SDPのそれぞれとの間に適用されることに注意してください。
An IETF Network Slice Service provider may freely make a deployment choice as to whether to offer a 1:1 relationship between an IETF Network Slice Service and connectivity construct or to support multiple connectivity constructs in a single IETF Network Slice Service. In the former case, the provider might need to deliver multiple IETF Network Slice Services to achieve the function of the second case.
IETFネットワークスライスサービスプロバイダーは、IETFネットワークスライスサービスと接続コンストラクトの間に1：1の関係を提供するか、単一のIETFネットワークスライスサービスで複数の接続コンストラクトをサポートするかについて、展開を選択することができます。前者の場合、プロバイダーは、2番目のケースの機能を実現するために、複数のIETFネットワークスライスサービスを提供する必要がある場合があります。
A customer traffic flow may be unicast or multicast, and various network realizations are possible:
顧客のトラフィックフローはユニキャストまたはマルチキャストである可能性があり、さまざまなネットワークの実現が可能です。
* Unicast traffic may be mapped to a P2P connectivity construct for direct delivery or to an A2A connectivity construct for the service provider to perform routing to the destination SDP. It would be unusual to use a P2MP connectivity construct to deliver unicast traffic because all receiving SDPs would get a copy, but this can still be done if the receivers are capable of dropping the unwanted traffic.
* ユニキャストトラフィックは、直接配信用のP2P接続コンストラクトにマッピングされ、サービスプロバイダーが宛先SDPへのルーティングを実行するためのA2A接続コンストラクトにマッピングできます。P2MP接続コンストラクトを使用してユニキャストトラフィックを提供することは珍しいことです。これは、すべてのSDPがコピーを取得するため、ユニキャストトラフィックを提供しますが、受信機が不要なトラフィックを削除できる場合でもこれは実行できます。
* A bidirectional unicast service can be constructed by specifying two P2P connectivity constructs. An additional SLE may specify fate-sharing in this case.
* 2つのP2P接続コンストラクトを指定することにより、双方向ユニキャストサービスを構築できます。この場合、追加のSLEが運命共有を指定する場合があります。
* Multicast traffic may be mapped to a set of P2P connectivity constructs, a single P2MP connectivity construct, or a mixture of P2P and P2MP connectivity constructs. Multicast may also be supported by an A2A connectivity construct. The choice clearly influences how and where traffic is replicated in the network. With a P2MP or A2A connectivity construct, it is the operator's choice whether to realize the construct with ingress replication, multicast in the core, P2MP tunnels, or hub-and-spoke. This choice should not change how the customer perceives the service.
* マルチキャストトラフィックは、P2P接続コンストラクトのセット、単一のP2MP接続コンストラクト、またはP2PとP2MPの接続コンストラクトの混合物にマッピングできます。マルチキャストは、A2A接続コンストラクトによってサポートされる場合もあります。選択は、ネットワーク内のトラフィックがどのように、どこで複製されるかに明らかに影響します。P2MPまたはA2A接続コンストラクトを使用すると、イングレスレプリケーション、コアのマルチキャスト、P2MPトンネル、またはハブアンドスポークを備えたコンストラクトを実現するかどうかがオペレーターの選択です。この選択は、顧客がサービスをどのように知覚するかを変えるべきではありません。
* The concept of a Multipoint-to-Point (MP2P) service can be realized with multiple P2P connectivity constructs. Note that, in this case, the egress may simultaneously receive traffic from all ingresses. The SLOs at the sending SDPs must be set with this in mind because the provider's network is not capable of coordinating the policing of traffic across multiple distinct source SDPs. It is assumed that the customer, requesting SLOs for the various P2P connectivity constructs, is aware of the capabilities of the receiving SDP. If the receiver receives more traffic than it can handle, it may drop some and introduce queuing delays.
* 複数のP2P接続コンストラクトを使用して、マルチポイントツーポイント（MP2P）サービスの概念を実現できます。この場合、出口はすべての侵入から同時にトラフィックを受ける可能性があることに注意してください。プロバイダーのネットワークは、複数の異なるソースSDPにわたるトラフィックのポリシングを調整できないため、送信SDPのSLOはこれを念頭に置いて設定する必要があります。さまざまなP2P接続コンストラクトのSLOを要求する顧客は、受信SDPの機能を認識していると想定されています。受信者が処理できるよりも多くのトラフィックを受け取った場合、一部を落としてキューイングの遅延を導入する可能性があります。
* The concept of a Multipoint-to-Multipoint (MP2MP) service can best be realized using a set of P2MP connectivity constructs but could be delivered over an A2A connectivity construct if each sender is using multicast. As with MP2P, the customer is assumed to be familiar with the capabilities of all receivers. A customer may wish to achieve an MP2MP service using a hub-and-spoke architecture where they control the hub; that is, the hub may be an SDP or an ancillary CE (see Section 4.2.3), and the service may be achieved by using a set of P2P connectivity constructs to the hub and a single P2MP connectivity construct from the hub.
* Multipoint-to-Multipoint（MP2MP）サービスの概念は、P2MP接続コンストラクトのセットを使用して最適に実現できますが、各送信者がマルチキャストを使用している場合はA2A接続コンストラクトを介して配信できます。MP2Pと同様に、顧客はすべてのレシーバーの機能に精通していると想定されています。顧客は、ハブを制御するハブアンドスポークアーキテクチャを使用してMP2MPサービスを達成したい場合があります。つまり、ハブはSDPまたは補助CEである可能性があり（セクション4.2.3を参照）、HUBへのP2P接続コンストラクトのセットを使用して、ハブからの単一のP2MP接続コンストラクトを使用することでサービスを実現できます。
From the above, it can be seen that the SLOs of the senders define the SLOs for the receivers on any connectivity construct. In particular, the network may be expected to handle the traffic volume from a sender to all destinations. This extends to all connectivity constructs in an IETF Network Slice Service.
上記から、送信者のスロが、接続コンストラクトのレシーバーのスロを定義していることがわかります。特に、ネットワークは、送信者からすべての目的地までのトラフィック量を処理することが期待される場合があります。これは、IETFネットワークスライスサービスのすべての接続コンストラクトに拡張されます。
Note that the realization of an IETF Network Slice Service does not need to map the connectivity constructs one-to-one onto underlying network constructs (such as tunnels). The service provided to the customer is distinct from how the provider decides to deliver that service.
IETFネットワークスライスサービスの実現は、接続コンストラクトを1対1の基礎となるネットワークコンストラクト（トンネルなど）にマッピングする必要がないことに注意してください。顧客に提供されるサービスは、プロバイダーがそのサービスを提供することを決定する方法とは異なります。
If a CE has multiple attachment circuits to PEs within a given IETF Network Slice Service and they are operating in single-active mode, then all traffic between the CE and its attached PEs transits a single attachment circuit; if they are operating in all-active mode, then traffic between the CE and its attached PEs is distributed across all of the active attachment circuits.
CEに特定のIETFネットワークスライスサービス内のPESへの複数のアタッチメントサーキットがあり、それらが単一アクティブモードで動作している場合、CEとその接続されたPES間のすべてのトラフィックは単一のアタッチメント回路を通過します。それらがオールアクティブモードで動作している場合、CEとその接続されたPESの間のトラフィックは、すべてのアクティブなアタッチメントサーキットに分布しています。
It may be the case that the set of SDPs that delimits an IETF Network Slice Service needs to be supplemented with additional senders or receivers within the network that are not customer sites. An additional sender could be, for example, an IPTV or DNS server either within the provider's network or attached to it, while an extra receiver could be, for example, a node reachable via the Internet. This is modeled in the Network Slicing architecture as a set of ancillary CEs that supplement the other SDPs in one or more connectivity constructs or that are linked by their own connectivity constructs. Note that an ancillary CE can either have a resolvable address (e.g., an IP address or MAC address), or it may be a placeholder (e.g., a named IPTV or DNS service or server) that is resolved within the provider's network when the IETF Network Slice Service is instantiated.
IETFネットワークスライスサービスを区切るSDPのセットには、顧客サイトではないネットワーク内の追加の送信者またはレシーバーを補充する必要があります。追加の送信者は、たとえば、プロバイダーのネットワーク内またはそれに添付されているIPTVまたはDNSサーバーである可能性がありますが、追加のレシーバーは、たとえば、インターネットを介して到達可能なノードになる可能性があります。これは、1つまたは複数の接続コンストラクトで他のSDPを補完する、または独自の接続コンストラクトによってリンクされている補助CESのセットとして、ネットワークスライスアーキテクチャでモデル化されています。補助的なCEには、解決可能なアドレス（IPアドレスまたはMACアドレスなど）があるか、IETFがプロバイダーのネットワーク内で解決されるプレースホルダー（例：名前付きIPTVまたはDNSサービスまたはサーバー）のいずれかであることに注意してください。ネットワークスライスサービスはインスタンス化されています。
Thus, an ancillary CE may be a node within the provider network (i.e., not a node at the edge of the customer's network). An example is a node that provides a service function. Another example is a node that acts as a hub. There will be times when the customer wishes to explicitly select one of these. Alternatively, an ancillary CE may be a service function at an unknown point in the provider's network. In this case, the function may be a placeholder that has its addresses resolved as part of the realization of the slice service.
したがって、補助的なCEは、プロバイダーネットワーク内のノードである場合があります（つまり、顧客のネットワークの端にあるノードではありません）。例は、サービス機能を提供するノードです。別の例は、ハブとして機能するノードです。顧客がこれらのいずれかを明示的に選択したい場合があります。あるいは、補助的なCEは、プロバイダーのネットワークの未知のポイントでのサービス機能である場合があります。この場合、この機能は、スライスサービスの実現の一部としてアドレスを解決するプレースホルダーである可能性があります。
Appendices A.2 and A.3 give simple worked examples of the use of ancillary CEs that may aid understanding the concept.
付録A.2およびA.3は、概念の理解を支援する可能性のある補助CEの使用の簡単な例を示しています。
The following subsections describe the characteristics of IETF Network Slices in addition to the list of SDPs, the connectivity constructs, and the technology of the ACs.
以下のサブセクションでは、SDP、接続コンストラクト、およびACSのテクノロジーのリストに加えて、IETFネットワークスライスの特性について説明します。
An IETF Network Slice Service is defined in terms of quantifiable characteristics known as Service Level Objectives (SLOs) and unquantifiable characteristics known as Service Level Expectations (SLEs). SLOs are expressed in terms Service Level Indicators (SLIs) and together with the SLEs form the contractual agreement between service customer and service provider known as a Service Level Agreement (SLA).
IETFネットワークスライスサービスは、サービスレベル目標（SLO）として知られる定量化可能な特性と、サービスレベルの期待（SLE）として知られる定量化できない特性の観点から定義されます。SLOは、サービスレベルのインジケータ（SLI）という用語で表現され、SLEとともに、サービスレベル契約（SLA）として知られるサービス顧客とサービスプロバイダーの間の契約上の契約を形成します。
The terms are defined as follows:
用語は次のように定義されています。
Service Level Indicator (SLI):
サービスレベルインジケーター（SLI）：
A quantifiable measure of an aspect of the performance of a network. For example, it may be a measure of throughput in bits per second, or it may be a measure of latency in milliseconds.
ネットワークのパフォーマンスの側面の定量化可能な尺度。たとえば、1秒あたりのビットでのスループットの尺度であるか、ミリ秒のレイテンシの尺度である場合があります。
Service Level Objective (SLO):
サービスレベルの目的（SLO）：
A target value or range for the measurements returned by observation of an SLI. For example, an SLO may be expressed as "SLI <= target" or "lower bound <= SLI <= upper bound". A customer can determine whether the provider is meeting the SLOs by performing measurements on the traffic.
SLIの観察によって返される測定の目標値または範囲。たとえば、SLOは「sli <=ターゲット」または「下限<= sli <=上限」として表現できます。顧客は、トラフィックの測定を実行することにより、プロバイダーがSLOを満たしているかどうかを判断できます。
Service Level Expectation (SLE):
サービスレベルの期待（SLE）：
An expression of an unmeasurable service-related request that a customer of an IETF Network Slice Service makes of the provider. An SLE is distinct from an SLO because the customer may have little or no way of determining whether the SLE is being met, but they still contract with the provider for a service that meets the expectation.
IETFネットワークスライスサービスの顧客がプロバイダーを作成するという測定不可能なサービス関連の要求の表現。SLEは、SLOが満たされているかどうかを判断する方法がほとんどまたはまったくない可能性があるため、SLOとは異なりますが、期待を満たすサービスのためにプロバイダーと契約します。
Service Level Agreement (SLA):
サービスレベル契約（SLA）：
An explicit or implicit contract between the customer of an IETF Network Slice Service and the provider of the slice. The SLA is expressed in terms of a set of SLOs and SLEs that are to be applied for a given connectivity construct between a sending SDP and the set of receiving SDPs. The SLA may describe the extent to which divergence from individual SLOs and SLEs can be tolerated, and commercial terms as well as any consequences for violating these SLOs and SLEs.
IETFネットワークスライスサービスの顧客とスライスのプロバイダーとの間の明示的または暗黙的な契約。SLAは、送信SDPと受信SDPのセットとの間の特定の接続コンストラクトに適用されるSLOおよびSLESのセットで表されます。SLAは、個々のSLOやSLEからの発散が許容できる程度、およびこれらのSLOとSLEに違反するための商業用語と商業用語を説明する場合があります。
SLOs define a set of measurable network attributes and characteristics that describe an IETF Network Slice Service. SLOs do not describe how an IETF Network Slice Service is implemented or realized in the underlying network layers. Instead, they are defined in terms of dimensions of operation (time, capacity, etc.), availability, and other attributes.
SLOSは、IETFネットワークスライスサービスを記述する測定可能なネットワーク属性と特性のセットを定義します。SLOは、IETFネットワークスライスサービスが基礎となるネットワークレイヤーでどのように実装または実現されるかを説明していません。代わりに、操作の次元（時間、容量など）、可用性、およびその他の属性の観点から定義されます。
An IETF Network Slice Service may include multiple connectivity constructs that associate sets of endpoints (SDPs). SLOs apply to a given connectivity construct and apply to a specific direction of traffic flow. That is, they apply to a specific sending SDP and the set of receiving SDPs.
IETFネットワークスライスサービスには、エンドポイントのセット（SDP）を関連付ける複数の接続コンストラクトが含まれる場合があります。SLOSは、特定の接続コンストラクトに適用され、交通フローの特定の方向に適用されます。つまり、特定の送信SDPと受信SDPのセットに適用されます。
SLOs can be described as "Directly Measurable Objectives"; they are always measurable. See Section 5.1.2 for the description of Service Level Expectations, which are unmeasurable service-related requests sometimes known as "Indirectly Measurable Objectives".
スロは「直接測定可能な目的」と説明できます。それらは常に測定可能です。「間接的に測定可能な目的」として知られていることもあるサービスレベルの期待の説明については、セクション5.1.2を参照してください。
Objectives such as guaranteed minimum bandwidth, guaranteed maximum latency, maximum permissible delay variation, maximum permissible packet loss ratio, and availability are "Directly Measurable Objectives". Future specifications (such as IETF Network Slice Service YANG models) may precisely define these SLOs, and other SLOs may be introduced as described in Section 5.1.1.2.
保証された最小帯域幅、保証された最大遅延、最大許容遅延変動、最大許容パケット損失率、可用性などの目標は「直接測定可能な目標」です。将来の仕様（IETFネットワークスライスサービスヤンモデルなど）は、これらのスロを正確に定義する場合があり、セクション5.1.1.2で説明されているように、他のスロが導入される場合があります。
The definition of these objectives are as follows:
これらの目的の定義は次のとおりです。
Guaranteed Minimum Bandwidth:
保証最小帯域幅：
Minimum guaranteed bandwidth between two endpoints at any time. The bandwidth is measured in data rate units of bits per second and is measured unidirectionally.
いつでも2つのエンドポイント間の最小保証帯域幅。帯域幅は、1秒あたりのビットのデータレート単位で測定され、一方向に測定されます。
Guaranteed Maximum Latency:
保証された最大遅延：
Upper bound of network latency when transmitting between two endpoints. The latency is measured in terms of network characteristics (excluding application-level latency). [RFC7679] discusses one-way metrics.
2つのエンドポイント間を送信するときのネットワークレイテンシの上限。遅延は、ネットワーク特性（アプリケーションレベルのレイテンシを除く）の観点から測定されます。[RFC7679]は一方向のメトリックについて説明します。
Maximum Permissible Delay Variation:
最大許容遅延変動：
Packet Delay Variation (PDV) as defined by [RFC3393] is the difference in the one-way delay between sequential packets in a flow. This SLO sets a maximum value PDV for packets between two endpoints.
[RFC3393]で定義されているパケット遅延変動（PDV）は、フロー内のシーケンシャルパケット間の一元配置遅延の違いです。このSLOは、2つのエンドポイント間のパケットの最大値PDVを設定します。
Maximum Permissible Packet Loss Ratio:
最大許容パケット損失比：
The ratio of packets dropped to packets transmitted between two endpoints over a period of time. See [RFC7680].
パケットの比率は、一定期間にわたって2つのエンドポイント間に送信されるパケットにドロップされました。[RFC7680]を参照してください。
Availability:
可用性：
The ratio of uptime to the sum of uptime and downtime, where uptime is the time the connectivity construct is available in accordance with all of the SLOs associated with it. Availability will often be expressed along with the time period over which the availability is measured and the maximum allowed single period of downtime.
稼働時間とダウンタイムの合計と稼働時間の比率は、稼働時間とともに、それに関連するすべてのSLOに従って接続コンストラクトが利用できる時間です。多くの場合、可用性は、可用性が測定されている期間と、最大許可された単一期間のダウンタイムとともに表現されます。
Additional SLOs may be defined to provide additional description of the IETF Network Slice Service that a customer requests. These would be specified in further documents.
追加のSLOを定義して、顧客が要求するIETFネットワークスライスサービスの追加の説明を提供する場合があります。これらは、さらなるドキュメントで指定されます。
If the IETF Network Slice Service is traffic-aware, other traffic-specific characteristics may be valuable including MTU, traffic type (e.g., IPv4, IPv6, Ethernet, or unstructured), or a higher-level behavior to process traffic according to user application (which may be realized using network functions).
IETFネットワークスライスサービスがトラフィックアウェアである場合、MTU、トラフィックタイプ（IPv4、IPv6、イーサネット、または非構造化）、またはユーザーアプリケーションに従ってトラフィックを処理するための高レベルの動作など、他のトラフィック固有の特性が価値がある場合があります。（ネットワーク機能を使用して実現する場合があります）。
SLEs define a set of network attributes and characteristics that describe an IETF Network Slice Service but are not directly measurable by the customer (e.g., diversity, isolation, and geographical restrictions). Even though the delivery of an SLE cannot usually be determined by the customer, the SLEs form an important part of the contract between customer and provider.
SLESは、IETFネットワークスライスサービスを記述するが、顧客が直接測定できるネットワーク属性と特性のセットを定義します（例：多様性、分離、地理的制限）。通常、SLEの配信は顧客によって決定されることはできませんが、SLESは顧客とプロバイダーの間の契約の重要な部分を形成します。
Quite often, an SLE will imply some details of how an IETF Network Slice Service is realized by the provider, although most aspects of the implementation in the underlying network layers remain a free choice for the provider. For example, activating unicast or multicast capabilities to deliver an IETF Network Slice Service could be explicitly requested by a customer or could be left as an engineering decision for the service provider based on capabilities of the network and operational choices.
多くの場合、SLEはプロバイダーによってIETFネットワークスライスサービスがどのように実現されるかの詳細を暗示していますが、基礎となるネットワークレイヤーの実装のほとんどの側面は、プロバイダーにとって自由な選択肢のままです。たとえば、ユニキャストまたはマルチキャスト機能をアクティブにしてIETFネットワークスライスサービスを提供することは、顧客が明示的に要求したり、ネットワークの機能と運用上の選択に基づいてサービスプロバイダーのエンジニアリング決定として任せることができます。
SLEs may be seen as aspirational on the part of the customer, and they are expressed as behaviors that the provider is expected to apply to the network resources used to deliver the IETF Network Slice Service. Of course, over time, it is possible that mechanisms will be developed that enable a customer to verify the provision of an SLE, at which point it effectively becomes an SLO.
SLEは、顧客側の意欲的であると見なされる場合があり、プロバイダーがIETFネットワークスライスサービスの提供に使用されるネットワークリソースに適用されると予想される行動として表現されています。もちろん、時間が経つにつれて、顧客がSLEの提供を検証できるようにするメカニズムが開発される可能性があります。
An IETF Network Slice Service may include multiple connectivity constructs that associate sets of endpoints (SDPs). SLEs apply to a given connectivity construct and apply to specific directions of traffic flow. That is, they apply to a specific sending SDP and the set of receiving SDPs. However, being more general in nature than SLOs, SLEs may commonly be applied to all connectivity constructs in an IETF Network Slice Service.
IETFネットワークスライスサービスには、エンドポイントのセット（SDP）を関連付ける複数の接続コンストラクトが含まれる場合があります。SLEは、特定の接続コンストラクトに適用され、トラフィックフローの特定の方向に適用されます。つまり、特定の送信SDPと受信SDPのセットに適用されます。ただし、SLOSよりも本質的に一般的であるため、SLESは一般に、IETFネットワークスライスサービスのすべての接続コンストラクトに適用される場合があります。
SLEs can be described as "Indirectly Measurable Objectives"; they are not generally directly measurable by the customer.
SLEは、「間接的に測定可能な目的」と説明できます。それらは一般に顧客が直接測定可能ではありません。
Security, geographic restrictions, maximum occupancy level, and isolation are example SLEs as follows.
セキュリティ、地理的制限、最大占有率、および分離は、次のようにSLEの例です。
Security:
安全：
A customer may request that the provider applies encryption or other security techniques to traffic flowing between SDPs of a connectivity construct within an IETF Network Slice Service. For example, the customer could request that only network links that have Media Access Control Security (MACsec) [MACsec] enabled are used to realize the connectivity construct.
顧客は、IETFネットワークスライスサービス内の接続コンストラクトのSDP間のトラフィックに暗号化またはその他のセキュリティテクニックを適用することを要求する場合があります。たとえば、顧客は、メディアアクセス制御セキュリティ（MACSEC）[MACSEC]を有効にするネットワークリンクのみが、接続コンストラクトを実現するために使用されることを要求できます。
This SLE may include a request for encryption (e.g., [RFC4303]) between the two SDPs explicitly to meet the architectural recommendations in [TS33.210] or for compliance with the HIPAA Security Rule [HIPAA] or the PCI Data Security Standard [PCI].
このSLEには、[TS33.210]のアーキテクチャの推奨事項を満たすために、またはHIPAAセキュリティルール[HIPAA]またはPCIデータセキュリティ標準[PCI）のコンプライアンスのために、2つのSDPの間の暗号化の要求（[RFC4303]など）が明示的に含まれる場合があります。]。
Whether or not the provider has met this SLE is generally not directly observable by the customer and cannot be measured as a quantifiable metric.
プロバイダーがこのSLEを満たしているかどうかは、一般に顧客が直接観察できず、定量化可能なメトリックとして測定することはできません。
Please see further discussion on security in Section 10.
セクション10のセキュリティに関する詳細な議論をご覧ください。
Geographic Restrictions:
地理的制限：
A customer may request that certain geographic limits are applied to how the provider routes traffic for the IETF Network Slice Service. For example, the customer may have a preference that its traffic does not pass through a particular country for political or security reasons.
顧客は、特定の地理的制限が、IETFネットワークスライスサービスのトラフィックをルーティングする方法に特定の地理的制限を適用するよう要求する場合があります。たとえば、顧客は、政治的またはセキュリティ上の理由から、トラフィックが特定の国を通過しないという好みを持っている場合があります。
Whether or not the provider has met this SLE is generally not directly observable by the customer and cannot be measured as a quantifiable metric.
プロバイダーがこのSLEを満たしているかどうかは、一般に顧客が直接観察できず、定量化可能なメトリックとして測定することはできません。
Maximal Occupancy Level:
最大占有率：
The maximal occupancy level specifies the number of flows to be admitted and optionally a maximum number of countable resource units (e.g., IP or MAC addresses) an IETF Network Slice Service can consume. Because an IETF Network Slice Service may include multiple connectivity constructs, this SLE should state whether it applies to all connectivity constructs, a specified subset of them, or an individual connectivity construct.
最大占有レベルは、入院するフローの数と、オプションでは、IETFネットワークスライスサービスが消費できる最大数の可算リソースユニット（IPまたはMACアドレスなど）を指定します。IETFネットワークスライスサービスには複数の接続コンストラクトが含まれる場合があるため、このSLEは、すべての接続コンストラクト、それらの指定されたサブセット、または個別の接続コンストラクトに適用されるかどうかを述べる必要があります。
Again, a customer may not be able to fully determine whether this SLE is being met by the provider.
繰り返しますが、顧客はこのSLEがプロバイダーによって満たされているかどうかを完全に判断できない場合があります。
Isolation:
分離：
As described in Section 8, a customer may request that its traffic within its IETF Network Slice Service is isolated from the effects of other network services supported by the same provider. That is, if another service exceeds capacity or has a burst of traffic, the customer's IETF Network Slice Service should remain unaffected, and there should be no noticeable change to the quality of traffic delivered.
セクション8で説明したように、顧客は、IETFネットワークスライスサービス内のトラフィックが、同じプロバイダーによってサポートされている他のネットワークサービスの効果から分離されることを要求する場合があります。つまり、別のサービスが容量を超えている場合、またはトラフィックのバーストがある場合、顧客のIETFネットワークスライスサービスは影響を受けないようにする必要があり、配信されるトラフィックの品質に顕著な変更はないはずです。
In general, a customer cannot tell whether a service provider is meeting this SLE. They cannot tell whether the variation of an SLI is because of changes in the underlay network or because of interference from other services carried by the network. If the service varies within the allowed bounds of the SLOs, there may be no noticeable indication that this SLE has been violated.
一般に、顧客はサービスプロバイダーがこのSLEを満たしているかどうかを知ることができません。彼らは、SLIの変動がアンダーレイネットワークの変化によるものであるか、ネットワークが運ぶ他のサービスからの干渉のためであるかどうかを知ることはできません。サービスがSLOの許可境界内で異なる場合、このSLEが違反されていることを示す顕著な兆候はない場合があります。
Diversity:
多様性：
A customer may request that different connectivity constructs use different underlay network resources. This might be done to enhance the availability of the connectivity constructs within an IETF Network Slice Service.
顧客は、異なる接続コンストラクトが異なるアンダーレイネットワークリソースを使用するように要求する場合があります。これは、IETFネットワークスライスサービス内の接続コンストラクトの可用性を高めるために行われる場合があります。
While availability is a measurable objective (see Section 5.1.1.1), this SLE requests a finer grade of control and is not directly measurable (although the customer might become suspicious if two connectivity constructs fail at the same time).
可用性は測定可能な目的ですが（セクション5.1.1.1を参照）、このSLEはより細かいグレードのコントロールを要求し、直接測定可能ではありません（ただし、2つの接続コンストラクトが同時に故障した場合、顧客は疑われる可能性があります）。
As noted in Section 4.1, an IETF Network Slice provides connectivity between sets of SDPs with specific SLOs and SLEs. Section 4.2 goes on to describe how the IETF Network Slice Service is composed of a set of one or more connectivity constructs that describe connectivity between the Service Demarcation Points (SDPs) across the underlay network.
セクション4.1で述べたように、IETFネットワークスライスは、特定のSLOとSLEを使用したSDPのセット間の接続性を提供します。セクション4.2は、IETFネットワークスライスサービスが、アンダーレイネットワーク全体のサービス境界ポイント（SDP）間の接続性を記述する1つ以上の接続コンストラクトのセットで構成されている方法を説明します。
The characteristics of IETF Network Slice SDPs are as follows.
IETFネットワークスライスSDPの特性は次のとおりです。
* An SDP is the point of attachment to an IETF Network Slice Service. As such, SDPs serve as the IETF Network Slice ingress/ egress points.
* SDPは、IETFネットワークスライスサービスへの添付のポイントです。そのため、SDPはIETFネットワークスライスイングレス/出力ポイントとして機能します。
* An SDP is identified by a unique identifier in the context of an IETF Network Slice Service customer.
* SDPは、IETFネットワークスライスサービスの顧客のコンテキストで一意の識別子によって識別されます。
* The provider associates each SDP with a set of provider-scope identifiers such as IP addresses, encapsulation-specific identifiers (e.g., VLAN tag and MPLS Label), interface/port numbers, node ID, etc.
* プロバイダーは、各SDPを、IPアドレス、カプセル化固有の識別子（VLANタグおよびMPLSラベルなど）、インターフェイス/ポート番号、ノードIDなどのプロバイダースコープ識別子のセットに関連付けます。
* SDPs are mapped to endpoints of services/tunnels/paths within the IETF Network Slice during its initialization and realization.
* SDPは、初期化と実現中にIETFネットワークスライス内のサービス/トンネル/パスのエンドポイントにマッピングされます。
- A combination of the SDP identifier and SDP provider-network-scope identifiers define an SDP in the context of the Network Slice Controller (NSC) (see Section 6.3).
- SDP識別子とSDPプロバイダーネットワークスコープ識別子の組み合わせは、ネットワークスライスコントローラー（NSC）のコンテキストでSDPを定義します（セクション6.3を参照）。
- The NSC will use the SDP provider-network-scope identifiers as part of the process of realizing the IETF Network Slice.
- NSCは、IETFネットワークスライスを実現するプロセスの一部として、SDPプロバイダーネットワークスコープ識別子を使用します。
Note that an ancillary CE (see Section 4.2.3) is the endpoint of a connectivity construct and so is an SDP in this discussion.
補助CE（セクション4.2.3を参照）は接続コンストラクトのエンドポイントであり、この議論のSDPも同様です。
For a given IETF Network Slice Service, the customer and provider agree where the SDP is located. This determines what resources at the edge of the network form part of the IETF Network Slice and are subject to the set of SLOs and SLEs for a specific SDP.
特定のIETFネットワークスライスサービスの場合、顧客とプロバイダーはSDPがどこにあるかに同意します。これにより、ネットワークの端にあるIETFネットワークスライスの一部を形成するリソースが決定され、特定のSDPのSLOとSLEのセットの対象となります。
Figure 1 shows different potential scopes of an IETF Network Slice that are consistent with the different SDP locations. For the purpose of this discussion and without loss of generality, the figure shows Customer Edge (CE) and Provider Edge (PE) nodes connected by Attachment Circuits (ACs). Notes after the figure give some explanations.
図1は、異なるSDP位置と一致するIETFネットワークスライスの異なる潜在的なスコープを示しています。この議論の目的のために、一般性を失うことなく、この図は顧客エッジ（CE）とプロバイダーエッジ（PE）ノードをアタッチメントサーキット（ACS）で接続していることを示しています。数字の後のメモはいくつかの説明をします。
|<---------------------- (1) ---------------------->|
| |
| |<-------------------- (2) -------------------->| |
| | | |
| | |<----------- (3) ----------->| | |
| | | | | |
| | | |<-------- (4) -------->| | | |
| | | | | | | |
V V AC V V V V AC V V
+-----+ | +-----+ +-----+ | +-----+
| |--------| | | |--------| |
| CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 |
| |--------| | | |--------| |
+-----+ | +-----+ +-----+ | +-----+
^ ^ ^ ^
| | | |
| | | |
Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2
Figure 1: Positioning IETF Service Demarcation Points
図1：IETFサービス境界ポイントの配置
Explanatory notes for Figure 1 are as follows:
図1の説明ノートは次のとおりです。
1. If the CE is operated by the IETF Network Slice Service provider, then the edge of the IETF Network Slice may be within the CE. In this case, the IETF Network Slicing process may utilize resources from within the CE such as buffers and queues on the outgoing interfaces.
1. CEがIETFネットワークスライスサービスプロバイダーによって操作されている場合、IETFネットワークスライスのエッジがCE内にある場合があります。この場合、IETFネットワークスライスプロセスは、発信インターフェイスのバッファやキューなど、CE内からリソースを利用する場合があります。
2. The IETF Network Slice may be extended as far as the CE to include the AC but not to include any part of the CE. In this case, the CE may be operated by the customer or the provider. Slicing the resources on the AC may require the use of traffic tagging (such as through Ethernet VLAN tags) or may require traffic policing at the AC link ends.
2. IETFネットワークスライスは、CEまで拡張されてACを含めるが、CEの一部を含めないようにすることができます。この場合、CEは顧客またはプロバイダーによって運用される場合があります。ACのリソースをスライスすると、トラフィックタグ（イーサネットVLANタグなど）の使用が必要になる場合があります。また、ACリンクの端でトラフィックポリシングが必要になる場合があります。
3. The SDPs of the IETF Network Slice are the customer-facing ports on the PEs. This case can be managed in a way that is similar to a port-based VPN: each port (AC) or virtual port (e.g., VLAN tag) identifies the IETF Network Slice and maps to an IETF Network Slice SDP.
3. IETFネットワークスライスのSDPは、PESの顧客向けポートです。このケースは、ポートベースのVPNに似た方法で管理できます。各ポート（AC）または仮想ポート（VLANタグなど）は、IETFネットワークスライスを識別し、IETFネットワークスライスSDPにマップします。
4. Finally, the SDP may be within the PE. In this mode, the PE classifies the traffic coming from the AC according to information (such as the source and destination IP addresses, payload protocol and port numbers, etc.) in order to place it onto an IETF Network Slice.
4. 最後に、SDPはPE内にある可能性があります。このモードでは、PEは、IETFネットワークスライスに配置するために、情報（ソースおよび宛先IPアドレス、ペイロードプロトコル、ポート番号など）に従ってACからのトラフィックを分類します。
The choice of which of these options to apply is entirely up to the network operator. It may limit or enable the provisioning of particular managed services, and the operator will want to consider how they want to manage CEs and what control they wish to offer the customer over AC resources.
適用するこれらのオプションの選択は、完全にネットワークオペレーター次第です。特定のマネージドサービスのプロビジョニングを制限または有効にする可能性があり、オペレーターはCESをどのように管理したいか、どのようなコントロールをACリソースよりも顧客に提供したいかを検討したいと思うでしょう。
Note that Figure 1 shows a symmetrical positioning of SDPs, but this decision can be taken on a per-SDP basis through agreement between the customer and provider.
図1は、SDPの対称的な位置決めを示していますが、この決定は、顧客とプロバイダーの間の合意を通じてSDPごとに行うことができます。
In practice, it may be necessary to map traffic not only onto an IETF Network Slice but also onto a specific connectivity construct if the IETF Network Slice supports more than one with a source at the specific SDP. The mechanism used will be one of the mechanisms described above, dependent on how the SDP is realized.
実際には、IETFネットワークスライスが特定のSDPのソースを使用して複数をサポートする場合、トラフィックをIETFネットワークスライスにマッピングするだけでなく、特定の接続コンストラクトにもマッピングする必要がある場合があります。使用されるメカニズムは、SDPがどのように実現されるかに応じて、上記のメカニズムの1つです。
Finally, note (as described in Section 3.2) that an SDP is an abstract endpoint of an IETF Network Slice Service and as such may be a device, interface, or software component. An ancillary CE (Section 4.2.3) should also be thought of as an SDP.
最後に、SDPはIETFネットワークスライスサービスの抽象的なエンドポイントであり、デバイス、インターフェイス、またはソフトウェアコンポーネントである可能性があることに注意してください（セクション3.2で説明しているように）。補助的なCE（セクション4.2.3）もSDPと考える必要があります。
Operationally, an IETF Network Slice may be composed of two or more IETF Network Slices as specified below. Decomposed network slices are independently realized and managed.
操作的に、IETFネットワークスライスは、以下に指定する2つ以上のIETFネットワークスライスで構成されている場合があります。分解されたネットワークスライスは、独立して実現および管理されます。
Hierarchical (i.e., recursive) composition:
階層的（つまり、再帰的）構成：
An IETF Network Slice can be further sliced into other network slices. Recursive composition allows an IETF Network Slice at one layer to be used by the other layers. This type of multi-layer vertical IETF Network Slice associates resources at different layers.
IETFネットワークスライスは、他のネットワークスライスにさらにスライスできます。再帰構成により、1つのレイヤーでIETFネットワークスライスを他のレイヤーで使用できます。このタイプの多層垂直IETFネットワークスライススライスは、リソースをさまざまなレイヤーに関連付けます。
Sequential composition:
シーケンシャル構成：
Different IETF Network Slices can be placed into a sequence to provide an end-to-end service. In sequential composition, each IETF Network Slice would potentially support different data planes that need to be stitched together.
さまざまなIETFネットワークスライスをシーケンスに配置して、エンドツーエンドサービスを提供できます。順次構成では、各IETFネットワークスライスは、一緒にステッチする必要があるさまざまなデータプレーンを潜在的にサポートします。
A number of IETF Network Slice Services will typically be provided over a shared underlay network infrastructure. Each IETF Network Slice consists of both the overlay connectivity and a specific set of dedicated network resources and/or functions allocated in a shared underlay network to satisfy the needs of the IETF Network Slice Service customer. In at least some examples of underlay network technologies, integration between the overlay and various underlay resources is needed to ensure the guaranteed performance requested for different IETF Network Slices.
通常、多くのIETFネットワークスライスサービスが、共有されたアンダーレイネットワークインフラストラクチャを介して提供されます。各IETFネットワークスライスは、オーバーレイ接続性と、IETFネットワークスライスサービス顧客のニーズを満たすために共有アンダーレイネットワークに割り当てられた専用ネットワークリソースおよび/または関数の特定のセットの両方で構成されています。少なくともアンダーレイネットワークテクノロジーの例では、異なるIETFネットワークスライスに対してリクエストされた保証されたパフォーマンスを確保するために、オーバーレイとさまざまなアンダーレイリソースの統合が必要です。
This section sets out the principal stakeholders in an IETF Network Slice and describes how the IETF Network Slice Service customer requests connectivity. It then introduces the IETF Network Slice Controller (the functional component responsible for receiving requests from customers and converting them into network configuration commands) and describes its interfaces.
このセクションでは、IETFネットワークスライスの主要な利害関係者を設定し、IETFネットワークスライスサービスの顧客が接続を要求する方法について説明します。次に、IETFネットワークスライスコントローラー（顧客からリクエストを受信し、ネットワーク構成コマンドに変換する機能コンポーネント）を導入し、そのインターフェイスについて説明します。
An IETF Network Slice and its realization involve the following stakeholders.
IETFネットワークスライスとその実現には、次の利害関係者が含まれます。
Orchestrator:
オーケストレーター：
An orchestrator is an entity that composes different services, resource, and network requirements. It interfaces with the IETF NSC when composing a complex service such as an end-to-end network slice.
オーケストレーターは、さまざまなサービス、リソース、ネットワークの要件を構成するエンティティです。エンドツーエンドネットワークスライスなどの複雑なサービスを作成するときに、IETF NSCとインターフェイスします。
IETF Network Slice Controller (NSC):
IETFネットワークスライスコントローラー（NSC）：
The NSC realizes an IETF Network Slice in the underlay network and maintains and monitors the run-time state of resources and topologies associated with it. A well-defined interface is needed to support interworking between different NSC implementations and different orchestrator implementations.
NSCは、アンダーレイネットワーク内のIETFネットワークスライスを実現し、それに関連するリソースとトポロジのランタイム状態を維持および監視します。さまざまなNSC実装と異なるオーケストレーターの実装との間のインターワーキングをサポートするには、明確に定義されたインターフェイスが必要です。
Network Controller:
ネットワークコントローラー：
The Network Controller is a form of network infrastructure controller that offers network resources to the NSC to realize a particular network slice. This may be an existing network controller associated with one or more specific technologies that may be adapted to the function of realizing IETF Network Slices in a network.
ネットワークコントローラーは、特定のネットワークスライスを実現するためにNSCにネットワークリソースを提供するネットワークインフラストラクチャコントローラーの形式です。これは、ネットワーク内のIETFネットワークスライスを実現する機能に適合する可能性のある1つまたは複数の特定のテクノロジーに関連付けられた既存のネットワークコントローラーです。
The IETF Network Slice Service customer and IETF Network Slice Service provider (see Section 3.2) are also stakeholders. Clearly, the service provider operates the network that is sliced to provide the IETF Network Slice Service to the customer. The Network Controller and NSC are management components used by the service provider to operate their networks and deliver IETF Network Slice Services. As indicated in Figures 2 and 3, the Orchestrator may be a component in the customer environment that requests and coordinates IETF Network Slice Services from one or more service providers. In other circumstances, however, the Orchestrator may be a component used by the service provider to request and administer IETF Network Slices to deliver them to customers or to construct an infrastructure to deliver other services to the customer.
IETFネットワークスライスサービスの顧客とIETFネットワークスライスサービスプロバイダー（セクション3.2を参照）も利害関係者です。明らかに、サービスプロバイダーは、IETFネットワークスライスサービスを顧客に提供するためにスライスされたネットワークを操作します。ネットワークコントローラーとNSCは、サービスプロバイダーがネットワークを運用し、IETFネットワークスライスサービスを提供するために使用する管理コンポーネントです。図2および3に示されているように、オーケストレーターは、1つ以上のサービスプロバイダーからIETFネットワークスライスサービスを要求および調整する顧客環境のコンポーネントである可能性があります。ただし、他の状況では、オーケストレーターは、IETFネットワークスライスを要求および管理して顧客に配信したり、顧客に他のサービスを提供したりするインフラストラクチャを構築するためにサービスプロバイダーが使用するコンポーネントである場合があります。
An IETF Network Slice Service customer communicates with the NSC using the IETF Network Slice Service Interface.
IETFネットワークスライスサービスの顧客は、IETFネットワークスライスサービスインターフェイスを使用してNSCと通信します。
An IETF Network Slice Service customer may be a network operator who, in turn, uses the IETF Network Slice to provide a service for another IETF Network Slice Service customer.
IETFネットワークスライスサービスの顧客は、IETFネットワークスライスを使用して別のIETFネットワークスライスサービス顧客にサービスを提供するネットワークオペレーターである可能性があります。
Using the IETF Network Slice Service Interface, a customer expresses requirements for a particular slice by specifying what is required rather than how that is to be achieved. That is, the customer's view of a slice is an abstract one. Customers normally have limited (or no) visibility into the provider network's actual topology and resource availability information.
IETFネットワークスライスサービスインターフェイスを使用して、顧客は、それを達成する方法ではなく、必要なものを指定することにより、特定のスライスの要件を表明します。つまり、スライスの顧客の見解は抽象的なものです。顧客は通常、プロバイダーネットワークの実際のトポロジとリソースの可用性情報に対する可視性が限られています（またはなし）。
This should be true even if both the customer and provider are associated with a single administrative domain, in order to reduce the potential for adverse interactions between IETF Network Slice Service customers and other users of the underlay network infrastructure.
IETFネットワークスライスサービス顧客とアンダーレイネットワークインフラストラクチャの他のユーザーとの間の不利な相互作用の可能性を減らすために、顧客とプロバイダーの両方が単一の管理ドメインに関連付けられている場合でも、これは真実でなければなりません。
The benefits of this model can include the following.
このモデルの利点には、以下を含めることができます。
Security:
安全：
The underlay network components are less exposed to attack because the underlay network (or network operator) does not need to expose network details (topology, capacity, etc.) to the IETF Network Slice Service customers.
アンダーレイネットワーク（またはネットワークオペレーター）がネットワークの詳細（トポロジ、容量など）をIETFネットワークスライスサービスの顧客に公開する必要がないため、アンダーレイネットワークコンポーネントは攻撃にさらされていません。
Layered Implementation:
階層化された実装：
The underlay network comprises network elements that belong to a different layer network than customer applications. Network information (advertisements, protocols, etc.) that a customer cannot interpret or respond to is not exposed to the customer. (Note that a customer should not rely on network information not exposed directly to the customer by the network operator, such as via the IETF Network Slice Service Interface.)
アンダーレイネットワークは、顧客アプリケーションとは異なるレイヤーネットワークに属するネットワーク要素で構成されています。顧客が解釈または応答できないネットワーク情報（広告、プロトコルなど）は、顧客にさらされていません。（顧客は、IETFネットワークスライスサービスインターフェイスなど、ネットワークオペレーターによって顧客に直接公開されないネットワーク情報に依存してはならないことに注意してください。）
Scalability:
スケーラビリティ：
Customers do not need to know any information concerning network topology, capabilities, or state beyond that which is exposed via the IETF Network Slice Service Interface. This protects the customer site from having to hold and process extra information and from receiving frequent updates about the status of the network.
顧客は、IETFネットワークスライスサービスインターフェイスを介して公開されているものを超えて、ネットワークトポロジ、機能、または状態に関する情報を知る必要はありません。これにより、顧客サイトが追加の情報を保持して処理する必要がなく、ネットワークのステータスに関する頻繁な更新を受信する必要があります。
The general issues of abstraction in a Traffic Engineered (TE) network are described more fully in [RFC7926].
[RFC7926]では、トラフィックエンジニアリング（TE）ネットワークにおける抽象化の一般的な問題がより完全に説明されています。
This framework document does not assume any particular technology layer at which IETF Network Slices operate. A number of layers (including virtual L2, Ethernet, or IP connectivity) could be employed.
このフレームワークドキュメントでは、IETFネットワークスライスが動作する特定のテクノロジーレイヤーを想定していません。多くのレイヤー（仮想L2、イーサネット、またはIP接続を含む）を使用できます。
Data models and interfaces are needed to set up IETF Network Slices, and specific interfaces may have capabilities that allow creation of slices within specific technology layers.
IETFネットワークスライスをセットアップするには、データモデルとインターフェイスが必要であり、特定のテクノロジーレイヤー内でスライスの作成を可能にする特定のインターフェイスには機能があります。
Layered virtual connections are comprehensively discussed in other IETF documents. For instance, GMPLS-based networks are discussed in [RFC5212] and [RFC4397], and Abstraction and Control of TE Networks (ACTN) is discussed in [RFC8453] and [RFC8454]. The principles and mechanisms associated with layered networking are applicable to IETF Network Slices.
階層化された仮想接続は、他のIETFドキュメントで包括的に議論されています。たとえば、GMPLSベースのネットワークは[RFC5212]および[RFC4397]で説明されており、TEネットワーク（ACTN）の抽象化と制御については[RFC8453]および[RFC8454]で説明しています。階層化されたネットワークに関連する原則とメカニズムは、IETFネットワークスライスに適用されます。
There are several IETF-defined mechanisms for expressing the need for a desired logical network. The IETF Network Slice Service Interface carries data either in a protocol-defined format or in a formalism associated with a modeling language.
目的の論理ネットワークの必要性を表現するためのIETF定義のメカニズムがいくつかあります。IETFネットワークスライスサービスインターフェイスは、プロトコル定義の形式またはモデリング言語に関連する形式主義のいずれかでデータを伝達します。
For instance:
例えば：
* The Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE [RFC4208] use a TLV-based binary encoding to transmit data.
* RSVP-TE [RFC4208]を使用して、PATH計算要素（PCE）通信プロトコル（PCEP）[RFC5440]およびGMPLSユーザーネットワークインターフェイス（UNI）を使用してTLVベースのバイナリエンコードを使用してデータを送信します。
* The Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF Protocol [RFC8040] use XML and JSON encoding.
* ネットワーク構成プロトコル（NetConf）[RFC6241]およびRESTCONFプロトコル[RFC8040]は、XMLおよびJSONエンコードを使用します。
* gRPC and gRPC Network Management Interface (gNMI) [GNMI] use a binary encoded programmable interface. ProtoBufs can be used to model gRPC and gNMI data.
* GRPCおよびGRPCネットワーク管理インターフェイス（GNMI）[GNMI]バイナリエンコードされたプログラム可能なインターフェイスを使用します。ProtoBufsは、GRPCおよびGNMIデータをモデル化するために使用できます。
* For data modeling, YANG [RFC6020] [RFC7950] may be used to model configuration and other data for NETCONF, RESTCONF, and gNMI, among others.
* データモデリングの場合、Yang [RFC6020] [RFC7950]を使用して、NetConf、RestConf、GNMIなどの構成とその他のデータをモデル化できます。
While several generic formats and data models for specific purposes exist, it is expected that IETF Network Slice management may require enhancement or augmentation of existing data models. Further, it is possible that mechanisms will be needed to determine the feasibility of service requests before they are actually made.
特定の目的のためのいくつかの一般的な形式とデータモデルが存在しますが、IETFネットワークスライス管理には既存のデータモデルの強化または増強が必要になる場合があります。さらに、メカニズムが実際に作成される前にサービス要求の実現可能性を判断するために必要である可能性があります。
An IETF NSC takes requests for IETF Network Slice Services and implements them using a suitable underlay technology. An IETF NSC is the key component for control and management of the IETF Network Slice. It provides the creation/modification/deletion, monitoring, and optimization of IETF Network Slices in a multi-domain, multi-technology, and multi-vendor environment.
IETF NSCは、IETFネットワークスライスサービスのリクエストを受け取り、適切なアンダーレイテクノロジーを使用してそれらを実装します。IETF NSCは、IETFネットワークスライスの制御と管理の重要なコンポーネントです。マルチドメイン、マルチテクノロジー、およびマルチベンダー環境でのIETFネットワークスライスの作成/変更/削除、監視、および最適化を提供します。
The main task of an IETF NSC is to map abstract IETF Network Slice Service requirements to concrete technologies and establish required connectivity, ensuring that resources are allocated to the IETF Network Slice as necessary.
IETF NSCの主なタスクは、抽象IETFネットワークスライスサービス要件を具体的なテクノロジーにマッピングし、必要に応じてリソースがIETFネットワークスライスに割り当てられるようにすることです。
The IETF Network Slice Service Interface is used for communicating details of an IETF Network Slice Service (configuration, selected policies, operational state, etc.) as well as information about status and performance of the IETF Network Slice. The details for this IETF Network Slice Service Interface are not in scope for this document, but further considerations of the requirements are discussed in [USE-CASES].
IETFネットワークスライスサービスインターフェイスは、IETFネットワークスライスサービス（構成、選択されたポリシー、運用状態など）の詳細と、IETFネットワークスライスのステータスとパフォーマンスに関する情報を伝えるために使用されます。このIETFネットワークスライスサービスインターフェイスの詳細は、このドキュメントの範囲ではありませんが、要件のさらなる考慮事項については[ユースケース]で説明します。
The controller provides the following functions.
コントローラーは、次の機能を提供します。
* Exposes an IETF Network Slice Service Interface for creation/modification/deletion of the IETF Network Slices that are agnostic to the technology of the underlay network. This API communicates the Service Demarcation Points of the IETF Network Slice, SLO parameters (and possibly monitoring thresholds), applicable input selection (filtering), and various policies. If SLEs have been agreed between the customer and the network operator, and if they are supported for the IETF Network Slice Service, the API will also allow SLEs to be selected for the IETF Network Slice and will allow any associated parameters to be set. The API also provides a way to monitor the slice.
* IETFネットワークスライスサービスインターフェイスを公開して、アンダーレイネットワークのテクノロジーに不可知のIETFネットワークスライスの作成/変更/削除を行います。このAPIは、IETFネットワークスライス、SLOパラメーター（およびおそらく監視しきい値）、適用可能な入力選択（フィルタリング）、およびさまざまなポリシーのサービス境界点を伝えます。SLEが顧客とネットワークオペレーターの間で合意されている場合、およびIETFネットワークスライスサービスのサポートされている場合、APIはIETFネットワークスライスに対してSLEを選択し、関連するパラメーターを設定できるようにします。APIは、スライスを監視する方法も提供します。
* Determines an abstract topology connecting the SDPs of the IETF Network Slice that meets criteria specified via the IETF Network Slice Service Interface. The NSC also retains information about the mapping of this abstract topology to underlay components of the IETF Network Slice as necessary to monitor IETF Network Slice status and performance.
* IETFネットワークスライスサービスインターフェイスを介して指定された基準を満たすIETFネットワークスライスのSDPを接続する抽象トポロジを決定します。また、NSCは、IETFネットワークスライスのステータスとパフォーマンスを監視するために必要に応じて、この抽象トポロジのマッピングに関する情報を保持します。
* Supports "Mapping Functions" for the realization of IETF Network Slices. In other words, it will use the mapping functions that:
* IETFネットワークスライスを実現するための「マッピング関数」をサポートします。言い換えれば、次のマッピング関数を使用します。
- Map IETF Network Slice Service Interface requests that are agnostic to the technology of the underlay network to technology-specific network configuration interfaces.
- MAP IETFネットワークスライスサービスインターフェイスリクエストは、テクノロジー固有のネットワーク構成インターフェイスに対するアンダーレイネットワークのテクノロジーに不可知論されます。
- Map filtering/selection information to entities in the underlay network so that those entities are able to identify which traffic is associated with which connectivity construct and IETF Network Slice.
- アンダーレイネットワーク内のエンティティへのフィルタリング/選択情報をマップして、それらのエンティティがどのトラフィックがどの接続構成とIETFネットワークスライスに関連付けられているかを特定できるようにします。
- Depending on the realization solution, map to entities in the underlay network according to how traffic should be treated to meet the SLOs and SLEs of the connectivity construct.
- 実現ソリューションに応じて、接続コンストラクトのSLOとSLESを満たすためにトラフィックをどのように処理するかに従って、アンダーレイネットワーク内のエンティティにマッピングします。
* Collects telemetry data (e.g., Operations, Administration, and Maintenance (OAM) results, statistics, states, etc.) via a network configuration interface for all elements in the abstract topology used to realize the IETF Network Slice.
* IETFネットワークスライスを実現するために使用される抽象トポロジのすべての要素のネットワーク構成インターフェイスを介して、テレメトリデータ（操作、管理、およびメンテナンス（OAM）の結果、統計、状態など）を収集します。
* Evaluates the current performance against IETF Network Slice SLO parameters using telemetry data from the underlying realization of an IETF Network Slice (e.g., services, paths, and tunnels). Exposes this performance to the IETF Network Slice Service customer via the IETF Network Slice Service Interface. The IETF Network Slice Service Interface may also include the capability to provide notifications if the IETF Network Slice performance reaches threshold values defined by the IETF Network Slice Service customer.
* IETFネットワークスライスのテレメトリデータを使用して、IETFネットワークスライスSLOパラメーターに対する現在のパフォーマンスを評価します（IETFネットワークスライス（サービス、パス、トンネルなど）の基礎となる実現。このパフォーマンスは、IETFネットワークスライスサービスインターフェイスを介してIETFネットワークスライスサービス顧客に公開します。IETFネットワークスライスサービスインターフェイスには、IETFネットワークスライスパフォーマンスがIETFネットワークスライスサービス顧客によって定義されたしきい値に達する場合に通知を提供する機能も含まれます。
The interworking and interoperability among the different stakeholders to provide common means of provisioning, operating, and monitoring the IETF Network Slices is enabled by the following communication interfaces (see Figure 2).
IETFネットワークスライスのプロビジョニング、操作、および監視の一般的な手段を提供するさまざまな利害関係者間の相互作用と相互運用性は、次の通信インターフェイスによって有効になります（図2を参照）。
IETF Network Slice Service Interface:
IETFネットワークスライスサービスインターフェイス：
An interface between a customer's higher-level operation system (e.g., a network slice orchestrator or a customer network management system) and an NSC. It is agnostic to the technology of the underlay network. The customer can use this interface to communicate the requested characteristics and other requirements for the IETF Network Slice Service, and an NSC can use the interface to report the operational state of an IETF Network Slice Service to the customer. More discussion of the functionalities for the IETF Network Slice Service Interface can be found in [USE-CASES].
顧客の高レベルの操作システム（ネットワークスライスオーケストレーターまたは顧客ネットワーク管理システムなど）とNSCの間のインターフェイス。これは、アンダーレイネットワークのテクノロジーにとって不可知論です。顧客は、このインターフェイスを使用して、IETFネットワークスライスサービスの要求された特性とその他の要件を伝えることができ、NSCはインターフェイスを使用して、IETFネットワークスライスサービスの運用状態を顧客に報告できます。IETFネットワークスライスサービスインターフェイスの機能の詳細については、[ユースケース]に記載されています。
Network Configuration Interface:
ネットワーク構成インターフェイス：
An interface between an NSC and network controllers. It is technology specific and may be built around the many network models already defined within the IETF.
NSCコントローラーとネットワークコントローラー間のインターフェイス。それはテクノロジー固有であり、IETF内ですでに定義されている多くのネットワークモデルを中心に構築される場合があります。
These interfaces can be considered in the context of the Service Model and Network Service Model described in [RFC8309] and, together with the Device Configuration Interface used by the Network Controllers, provides a consistent view of service delivery and realization.
これらのインターフェイスは、[RFC8309]で説明されているサービスモデルおよびネットワークサービスモデルのコンテキストで考慮することができ、ネットワークコントローラーが使用するデバイス構成インターフェイスとともに、サービス提供と実現の一貫したビューを提供します。
+------------------------------------------+
| Customer higher-level operation system |
| (e.g., E2E network slice orchestrator, |
| customer network management system) |
+------------------------------------------+
A
| IETF Network Slice Service Interface
V
+------------------------------------------+
| IETF Network Slice Controller (NSC) |
+------------------------------------------+
A
| Network Configuration Interface
V
+------------------------------------------+
| Network Controllers |
+------------------------------------------+
Figure 2: Interfaces of the IETF Network Slice Controller
図2：IETFネットワークスライスコントローラーのインターフェイス
The IETF Network Slice Controller provides an IETF Network Slice Service Interface that allows customers to manage IETF Network Slice Services. Customers operate on abstract IETF Network Slice Services, with details related to their realization hidden.
IETFネットワークスライスコントローラーは、顧客がIETFネットワークスライスサービスを管理できるIETFネットワークスライスサービスインターフェイスを提供します。顧客は、抽象IETFネットワークスライスサービスで動作し、その詳細は実現に関連して隠されています。
The IETF Network Slice Service Interface is also independent of the type of network functions or services that need to be connected, i.e., it is independent of any specific storage, software, protocol, or platform used to realize physical or virtual network connectivity or functions in support of IETF Network Slices.
IETFネットワークスライスサービスインターフェイスは、接続する必要があるネットワーク機能またはサービスの種類にも依存しません。つまり、特定のストレージ、ソフトウェア、プロトコル、または物理的または仮想ネットワーク接続または機能を実現するために使用されるプラットフォームとは無関係です。IETFネットワークスライスのサポート。
The IETF Network Slice Service Interface uses protocol mechanisms and information passed over those mechanisms to convey desired attributes for IETF Network Slices and their status. The information is expected to be represented as a well-defined data model and should include at least SDP and connectivity information, SLO/SLE specification, and status information.
IETFネットワークスライスサービスインターフェイスは、これらのメカニズムに渡されたプロトコルメカニズムと情報を使用して、IETFネットワークスライスとそのステータスの望ましい属性を伝えます。情報は明確に定義されたデータモデルとして表されると予想され、少なくともSDPおよび接続情報、SLO/SLE仕様、およびステータス情報を含める必要があります。
The management architecture described in Figure 2 may be further decomposed as shown in Figure 3. This should also be seen in the context of the component architecture shown in Figure 4 and corresponds to the architecture in [RFC8309].
図3に示すように、図2に説明する管理アーキテクチャは、図4に示すコンポーネントアーキテクチャのコンテキストでも見られるべきであり、[RFC8309]のアーキテクチャにも対応する必要があります。
Note that the customer higher-level operation system of Figure 2 and the Network Slice Orchestrator of Figure 3 may be considered equivalent to the Service Management & Orchestration (SMO) of [ORAN].
図2の顧客の高レベルの動作システムと図3のネットワークスライスオーケストレーターは、[Oran]のサービス管理とオーケストレーション（SMO）に相当すると見なされる場合があることに注意してください。
--------------
| Network |
| Slice |
| Orchestrator |
--------------
| IETF Network Slice
| Service Request
| Customer view
....|................................
-v------------------- Operator view
|Controller |
| ------------ |
| | IETF | |
| | Network | |--> Virtual Network
| | Slice | |
| | Controller | |
| | (NSC) | |
| ------------ |
..| | Network |............
| | Configuration | Underlay Network
| v |
| ------------ |
| | Network | |
| | Controller | |
| | (NC) | |
| ------------ |
---------------------
| Device Configuration
v
Figure 3: Interface of IETF Network Slice Management Architecture
図3：IETFネットワークスライス管理アーキテクチャのインターフェース
Realization of IETF Network Slices is a mapping of the definition of the IETF Network Slice to the underlying infrastructure and is necessarily technology specific and achieved by an NSC over the Network Configuration Interface. Details of how realizations may be achieved is out of scope of this document; however, this section provides an overview of the components and processes involved in realizing an IETF Network Slice.
IETFネットワークスライスの実現は、IETFネットワークスライスの基礎となるインフラストラクチャへの定義のマッピングであり、必然的にテクノロジー固有であり、ネットワーク構成インターフェイスを介したNSCによって達成されます。実現がどのように達成されるかの詳細は、このドキュメントの範囲外です。ただし、このセクションでは、IETFネットワークスライスの実現に関与するコンポーネントとプロセスの概要を説明します。
The architecture described in this section is deliberately at a high level. It is not intended to be prescriptive: implementations and technical solutions may vary freely. However, this approach provides a common framework that other documents may reference in order to facilitate a shared understanding of the work.
このセクションで説明するアーキテクチャは、意図的に高レベルにあります。規範的であることを意図したものではありません。実装と技術的なソリューションは自由に異なる場合があります。ただし、このアプローチは、作業の共通の理解を促進するために、他の文書が参照できる一般的なフレームワークを提供します。
Figure 4 shows the architectural components of a network managed to provide IETF Network Slices. The customer's view is of individual IETF Network Slice Services with their SDPs and connectivity constructs. Requests for IETF Network Slice Services are delivered to an NSC.
図4は、ネットワークのアーキテクチャコンポーネントを、IETFネットワークスライスを提供できることを示しています。顧客の見解は、SDPと接続コンストラクトを備えた個々のIETFネットワークスライスサービスのものです。IETFネットワークスライスサービスのリクエストは、NSCに配信されます。
Figure 4 shows, without loss of generality, the CEs, ACs, and PEs that exist in the network. The SDPs are not shown and can be placed in any of the ways described in Section 5.2.
図4は、一般性を失うことなく、ネットワークに存在するCES、ACS、およびPEを示しています。SDPは表示されず、セクション5.2で説明されている方法のいずれかに配置できます。
-- -- --
|CE| |CE| |CE|
-- -- --
AC : AC : AC :
---------------------- -------
( |PE|....|PE|....|PE| ) ( IETF )
IETF Network ( --: -- :-- ) ( Network )
Slice Service ( :............: ) ( Slice )
Request ( IETF Network Slice ) ( ) Customer
v ---------------------- ------- View
v ............................\........./...............
v \ / Provider
v >>>>>>>>>>>>>>> Grouping/Mapping v v View
v ^ -----------------------------------------
v ^ ( |PE|.......|PE|........|PE|.......|PE| )
--------- ( --: -- :-- -- )
| | ( :...................: )
| NSC | ( Network Resource Partition )
| | -----------------------------------------
| | ^
| |>>>>> Resource Partitioning |
--------- of Filtered Topology |
v v |
v v ----------------------------- --------
v v (|PE|..-..|PE|... ..|PE|..|PE|) ( )
v v ( :-- |P| -- :-: -- :-- ) ( Filter )
v v ( :.- -:.......|P| :- ) ( Topology )
v v ( |P|...........:-:.......|P| ) ( )
v v ( - Filtered Topology ) --------
v v ----------------------------- ^
v >>>>>>>>>>>> Topology Filter ^ /
v ...........................\............../...........
v \ / Underlay
---------- \ / (Physical)
| | \ / Network
| Network | ----------------------------------------------
|Controller| ( |PE|.....-.....|PE|...... |PE|.......|PE| )
| | ( -- |P| -- :-...:-- -..:-- )
---------- ( : -:.............|P|.........|P| )
v ( -......................:-:..- - )
>>>>>>> ( |P|.........................|P|......: )
Program the ( - - )
Network ----------------------------------------------
Figure 4: Architecture of an IETF Network Slice
図4：IETFネットワークスライスのアーキテクチャ
The network itself (at the bottom of Figure 4) comprises an underlay network. This could be a physical network but may be a virtual network. The underlay network is provisioned through network controllers [RFC8309] that may, themselves, utilize device controllers.
ネットワーク自体（図4の下部）は、アンダーレイネットワークで構成されています。これは物理的なネットワークかもしれませんが、仮想ネットワークかもしれません。アンダーレイネットワークは、デバイスコントローラーを使用する可能性のあるネットワークコントローラー[RFC8309]を介してプロビジョニングされます。
The underlay network may optionally be filtered or customized by the network operator to produce a number of network topologies that we call "Filtered Topologies". Customization is just a way of selecting specific resources (e.g., nodes and links) from the underlay network according to their capabilities and connectivity in the underlay network. Filtering and customization are configuration options or operator policies that preselect links and nodes with certain performance characteristics to enable easier construction of Network Resource Partitions (NRPs; see below) that can reliably support specific IETF Network Slice SLAs, for example, preselection of links with certain security characteristics, preselection of links with specific geographic properties, or mapping to colored topologies. The resulting topologies can be used as candidates to host IETF Network Slices and provide a useful way for the network operator to know in advance that all of the resources they are using to plan an IETF Network Slice would be able to meet specific SLOs and SLEs. The creation of a Filtered Topology could be an offline planning activity or could be performed dynamically as new demands arise. The use of Filtered Topologies is entirely optional in the architecture, and IETF Network Slices could be hosted directly on the underlay network.
アンダーレイネットワークは、オプションでネットワークオペレーターによってフィルタリングまたはカスタマイズされ、「フィルタリングされたトポロジ」と呼ばれる多くのネットワークトポロジを生成できます。カスタマイズは、アンダーレイネットワークの機能と接続性に応じて、アンダーレイネットワークから特定のリソース（ノードやリンクなど）を選択する方法にすぎません。フィルタリングとカスタマイズは、特定のパフォーマンス特性を使用してリンクとノードを事前に選択する構成オプションまたはオペレーターポリシーです。たとえば、特定のIETFネットワークスライスSLAS、特定のリンクの事前選択を確実にサポートできるネットワークリソースパーティション（NRP;以下を参照）を可能にします。セキュリティ特性、特定の地理的特性とのリンクの事前選択、または色付きトポロジーへのマッピング。結果のトポロジは、IETFネットワークスライスをホストし、ネットワークオペレーターがIETFネットワークスライスを計画するために使用しているすべてのリソースが特定のSLOとSLEを満たすことができることを事前に知るための有用な方法を提供する候補として使用できます。ろ過されたトポロジの作成は、オフライン計画アクティビティである可能性があるか、新しい要求が生じるにつれて動的に実行される可能性があります。フィルタリングされたトポロジの使用は、アーキテクチャでは完全にオプションであり、IETFネットワークスライスはアンダーレイネットワークで直接ホストできます。
Recall that an IETF Network Slice is a service requested by and/or provided for the customer. The IETF Network Slice Service is expressed in terms of one or more connectivity constructs. An implementation or operator is free to limit the number of connectivity constructs in an IETF Network Slice to exactly one. Each connectivity construct is associated within the IETF Network Slice Service request with a set of SLOs and SLEs. The set of SLOs and SLEs does not need to be the same for every connectivity construct in the IETF Network Slice, but an implementation or operator is free to require that all connectivity constructs in an IETF Network Slice have the same set of SLOs and SLEs.
IETFネットワークスライスは、顧客に要求された、および/または提供されるサービスであることを思い出してください。IETFネットワークスライスサービスは、1つ以上の接続コンストラクトで表されます。実装またはオペレーターは、IETFネットワークスライス内の接続コンストラクトの数を正確に1つに制限できます。各接続コンストラクトは、SLOとSLEのセットを使用して、IETFネットワークスライスサービス要求内に関連付けられています。SLOSとSLEのセットは、IETFネットワークスライスのすべての接続コンストラクトで同じである必要はありませんが、実装またはオペレーターは、IETFネットワークスライスのすべての接続コンストラクトが同じスロとSLEのセットを持つことを自由に要求できます。
An NRP is a subset of the buffer/queuing/scheduling resources and associated policies on each of a connected set of links in the underlay network (for example, as achieved in [RESOURCE-AWARE-SEGMENTS]). The connected set of links could be the entire set of links with all of their buffer/queuing/scheduling resources and behaviors in the underlay network, and in this case, there would be just one NRP supported in the underlay network. The amount and granularity of resources allocated in an NRP is flexible and depends on the operator's policy. Some NRP realizations may build NRPs with dedicated topologies, while other realizations may use a shared topology for multiple NRPs. Realizations of an NRP may be built on a range of existing or new technologies, and this document does not constrain solution technologies.
NRPは、アンダーレイネットワーク内の接続された各リンクセットのバッファ/キューイング/スケジューリングリソースと関連するポリシーのサブセットです（たとえば、[Resource-Aware-Segments]で達成されます）。接続された一連のリンクは、アンダーレイネットワーク内のすべてのバッファ/キューイング/スケジューリングリソースと動作を伴うすべてのリンクセットである可能性があり、この場合、アンダーレイネットワークでサポートされているNRPは1つだけです。NRPに割り当てられたリソースの量と粒度は柔軟であり、オペレーターのポリシーに依存します。一部のNRP実現は、専用トポロジを使用してNRPを構築する場合がありますが、他の実現では複数のNRPに対して共有トポロジを使用する場合があります。NRPの実現は、さまざまな既存または新しいテクノロジーに基づいて構築される場合があり、このドキュメントはソリューションテクノロジーを制約しません。
One or more connectivity constructs from one or more IETF Network Slices are mapped to an NRP. A single connectivity construct is mapped to only one NRP (that is, the relationship is many to one). Thus, all traffic flows in a connectivity construct assigned to an NRP are assigned to that NRP. Further, all PEs connected by a connectivity construct must be present in the NRP to which that connectivity construct is assigned.
1つ以上のIETFネットワークスライスからの1つ以上の接続コンストラクトがNRPにマッピングされます。単一の接続コンストラクトは、1つのNRPのみにマッピングされます（つまり、関係は多くのものです）。したがって、NRPに割り当てられた接続コンストラクト内のすべてのトラフィックフローは、そのNRPに割り当てられます。さらに、接続コンストラクトで接続されたすべてのPEは、その接続コンストラクトが割り当てられるNRPに存在する必要があります。
An NRP may be chosen to support a specific connectivity construct because of its ability to support a specific set of SLOs and SLEs, its ability to support particular connectivity constructs, or any administrative or operational reason. An implementation or operator is free to map each connectivity construct to a separate NRP, although there may be scaling implications depending on the solution implemented. Thus, the connectivity constructs from one slice may be mapped to one or more NRPs. By implication from the above, an implementation or operator is free to map all the connectivity constructs in a slice to a single NRP and to not share that NRP with connectivity constructs from another slice.
特定のSLOとSLESセットをサポートする能力、特定の接続コンストラクトをサポートする能力、または管理または運用上の理由により、特定の接続コンストラクトをサポートするためにNRPを選択する場合があります。実装またはオペレーターは、各接続コンストラクトを個別のNRPに自由にマッピングできますが、実装されたソリューションに応じてスケーリングの意味がある場合があります。したがって、1つのスライスからの接続構築は、1つ以上のNRPにマッピングできます。上記の意味により、実装または演算子は、すべての接続コンストラクトをスライス内のすべての接続コンストラクトを単一のNRPにマッピングし、そのNRPを別のスライスの接続コンストラクトと共有しないように自由にマッピングできます。
An NRP may use work-conserving schedulers, non-work-conserving schedulers, or both (see Section 2 of [RFC3290]) according to the function that it needs to deliver. The choice of how network resources are allocated and managed for an NRP, and whether a work-conserving scheduling approach or a non-work-conserving scheduling approach is adopted, is technology specific: an implementation or operator is free to choose the set of techniques for NRP realization.
NRPは、配信する必要がある機能に従って、ワークコンサイティングスケジューラ、非作業継続スケジューラー、またはその両方（[RFC3290]のセクション2を参照）を使用する場合があります。NRPにネットワークリソースが割り当てられ管理される方法の選択、および作業継続的なスケジューリングアプローチまたは非作業保存スケジューリングアプローチが採用されているかどうかは、テクノロジー固有のものです。NRP実現のため。
The process of determining the NRP may be made easier if the underlay network topology is first filtered into a Filtered Topology in order to be aware of the subset of network resources that are suitable for specific NRPs. In this case, each Filtered Topology is treated as an underlay network on which NRPs can be constructed. The stage of generating Filtered Topologies is optional within this framework.
特定のNRPに適したネットワークリソースのサブセットを認識するために、アンダーレイネットワークトポロジが最初にフィルタリングされたトポロジにフィルタリングされている場合、NRPを決定するプロセスが容易になる場合があります。この場合、各フィルタリングされたトポロジーは、NRPを構築できるアンダーレイネットワークとして扱われます。このフレームワーク内では、フィルタリングされたトポロジを生成する段階がオプションです。
The steps described here can be applied in a variety of orders according to implementation and deployment preferences. Furthermore, the steps may be iterative so that the components are continually refined and modified as network conditions change and as service requests are received or relinquished, and even the underlay network could be extended if necessary to meet the customers' demands.
ここで説明する手順は、実装と展開の好みに応じて、さまざまな注文で適用できます。さらに、コンポーネントがネットワーク条件が変更され、サービスリクエストが受信または放棄されるにつれてコンポーネントが継続的に洗練され、変更され、必要に応じて顧客の要求を満たすためにアンダーレイネットワークを拡張できるように、手順が反復的である可能性があります。
There are a number of different technologies that can be used in the underlay, including physical connections, MPLS, Time-Sensitive Networking (TSN), Flex-E, etc.
物理的な接続、MPLS、時間依存ネットワーキング（TSN）、Flex-Eなどを含む、アンダーレイで使用できるさまざまなテクノロジーがあります。
An IETF Network Slice can be realized in a network, using specific underlay technology or technologies. The creation of a new IETF Network Slice will be realized with the following steps:
特定のアンダーレイテクノロジーまたはテクノロジーを使用して、ネットワークでIETFネットワークスライスを実現できます。新しいIETFネットワークスライスの作成は、次の手順で実現されます。
1. An NSC exposes the network slicing capabilities that it offers for the network it manages so that the customer can determine whether to request services and what features are in scope.
1. NSCは、顧客がサービスを要求するかどうか、どの機能が範囲内にあるかを決定できるように、管理するネットワークに提供するネットワークスライス機能を公開します。
2. The customer may issue a request to determine whether a specific IETF Network Slice Service could be supported by the network. An NSC may respond indicating a simple yes or no and may supplement a negative response with information about what it could support were the customer to change some requirements.
2. 顧客は、特定のIETFネットワークスライスサービスがネットワークによってサポートできるかどうかを判断するためのリクエストを発行する場合があります。NSCは、単純な「はい」または「いいえ」を示す応答があり、いくつかの要件を変更するために顧客がサポートできるものについての否定的な応答を補足する場合があります。
3. The customer requests an IETF Network Slice Service. An NSC may respond that the slice has or has not been created and may supplement a negative response with information about what it could support were the customer to change some requirements.
3. 顧客は、IETFネットワークスライスサービスを要求します。NSCは、スライスが作成されている、または作成されていないことに応答する場合があり、いくつかの要件を変更するために顧客がサポートできることについての情報を否定的な応答を補完する場合があります。
4. When processing a customer request for an IETF Network Slice Service, an NSC maps the request to the network capabilities and applies provider policies before creating or supplementing the NRP.
4. IETFネットワークスライスサービスの顧客要求を処理する場合、NSCはNRPを作成または補足する前に、ネットワーク機能にリクエストをマップし、プロバイダーポリシーを適用します。
Regardless of how an IETF Network Slice is realized in the network (e.g., using tunnels of different types), the definition of the IETF Network Slice Service does not change at all. The only difference is how the slice is realized. The following sections briefly introduce how some existing architectural approaches can be applied to realize IETF Network Slices.
ネットワークでIETFネットワークスライスがどのように実現されるかに関係なく（例：さまざまなタイプのトンネルを使用する）、IETFネットワークスライスサービスの定義はまったく変更されません。唯一の違いは、スライスの実現方法です。次のセクションでは、IETFネットワークスライスを実現するために、既存のアーキテクチャアプローチを適用する方法を簡単に紹介します。
Abstraction and Control of TE Networks (ACTN) [RFC8453] is a management architecture and toolkit used to create virtual networks (VNs) on top of a TE underlay network. The VNs can be presented to customers for them to operate as private networks.
TEネットワーク（ACTN）[RFC8453]の抽象化と制御は、TEアンダーレイネットワークの上に仮想ネットワーク（VNS）を作成するために使用される管理アーキテクチャとツールキットです。VNSは、プライベートネットワークとして運営するために顧客に提示できます。
In many ways, the function of ACTN is similar to IETF network slicing. Customer requests for connectivity-based overlay services are mapped to dedicated or shared resources in the underlay network in a way that meets customer guarantees for SLOs and for separation from other customers' traffic. [RFC8453] describes the function of ACTN as collecting resources to establish a logically dedicated virtual network over one or more TE networks. Thus, in the case of a TE-enabled underlay network, the ACTN VN can be used as a basis to realize IETF network slicing.
多くの点で、ACTNの機能はIETFネットワークスライスに似ています。接続ベースのオーバーレイサービスの顧客リクエストは、SLOの顧客保証を満たし、他の顧客のトラフィックから分離するために、アンダーレイネットワーク内の専用または共有リソースにマッピングされます。[RFC8453]は、ACTNの機能を、1つ以上のTEネットワークを介して論理的に専用の仮想ネットワークを確立するためのリソースの収集として説明しています。したがって、TE対応のアンダーレイネットワークの場合、ACTN VNをIETFネットワークスライスを実現するための基礎として使用できます。
While the ACTN framework is a generic VN framework that can be used for VN services beyond the IETF Network Slice, it is also a suitable basis for delivering and realizing IETF Network Slices.
ACTNフレームワークは、IETFネットワークスライスを超えたVNサービスに使用できる汎用VNフレームワークですが、IETFネットワークスライスを提供および実現するのに適した基盤でもあります。
Further discussion of the applicability of ACTN to IETF Network Slices, including a discussion of the relevant YANG models, can be found in [ACTN-NS].
関連するYangモデルの議論を含むIETFネットワークスライスへのACTNの適用性に関するさらなる議論は、[ACTN-NS]にあります。
An enhanced VPN is designed to support the needs of new applications, particularly applications that are associated with 5G services. The approach is based on existing VPN and TE technologies but adds characteristics that specific services require over and above those previously associated with VPN services.
拡張VPNは、新しいアプリケーション、特に5Gサービスに関連付けられているアプリケーションのニーズをサポートするように設計されています。このアプローチは、既存のVPNおよびTEテクノロジーに基づいていますが、特定のサービスが以前にVPNサービスに関連付けられているサービス以上の特性を追加します。
An enhanced VPN can be used to provide enhanced connectivity services between customer sites and can be used to create the infrastructure to underpin an IETF Network Slice Service.
拡張されたVPNを使用して、顧客サイト間で強化された接続サービスを提供し、IETFネットワークスライスサービスを支えるインフラストラクチャを作成するために使用できます。
It is envisaged that enhanced VPNs will be delivered using a combination of existing, modified, and new networking technologies.
拡張されたVPNは、既存、修正、および新しいネットワーキングテクノロジーの組み合わせを使用して配信されることを想定しています。
[ENHANCED-VPN] describes the framework for enhanced VPN services.
[Enhanced-VPN]は、VPNサービスの拡張フレームワークについて説明しています。
Network slicing provides the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. The support of resource preemption between IETF Network Slices is deployment specific.
ネットワークスライスは、さまざまなサイズ、構造、機能の複数の論理ネットワークに物理ネットワークを分割する機能を提供し、各スライスを特定のサービスまたは顧客に専念できるようにします。IETFネットワークスライス間のリソースプリエンプションのサポートは、展開固有です。
Many approaches are currently being worked on to support IETF Network Slices in IP and MPLS networks with or without the use of Segment Routing. Most of these approaches utilize a way of marking packets so that network nodes can apply specific routing and forwarding behaviors to packets that belong to different IETF Network Slices. Different mechanisms for marking packets have been proposed (including using MPLS labels and Segment Routing segment IDs), and those mechanisms are agnostic to the path control technology used within the underlay network.
現在、セグメントルーティングの使用の有無にかかわらず、IPおよびMPLSネットワークのIETFネットワークスライスをサポートするために多くのアプローチが取り組んでいます。これらのアプローチのほとんどは、ネットワークノードが異なるIETFネットワークスライスに属するパケットに特定のルーティングと転送の動作を適用できるように、パケットをマークする方法を利用しています。マークパケットのさまざまなメカニズムが提案されています（MPLSラベルとセグメントルーティングセグメントIDを使用するなど）。これらのメカニズムは、アンダーレイネットワーク内で使用されるパス制御テクノロジーに不可知論されます。
These approaches are also sensitive to the scaling concerns of supporting a large number of IETF Network Slices within a single IP or MPLS network and so offer ways to aggregate the connectivity constructs of slices (or whole slices) so that the packet markings indicate an aggregate or grouping where all of the packets are subject to the same routing and forwarding behavior.
これらのアプローチは、単一のIPまたはMPLSネットワーク内の多数のIETFネットワークスライスをサポートするというスケーリングの懸念にも敏感であるため、パケットマーキングが凝集またはまたはそれを示すようにスライス（またはスライス全体）の接続コンストラクトを集約する方法を提供します。すべてのパケットが同じルーティングと転送の動作の対象となるグループ。
At this stage, it is inappropriate to cite any of these proposed solutions that are currently work in progress and not yet adopted as IETF work.
この段階では、現在進行中であり、IETFの動作としてまだ採用されていないこれらの提案されたソリューションのいずれかを引用することは不適切です。
A customer may request an IETF Network Slice Service that involves a set of service functions (SFs) together with the order in which these SFs are invoked. Also, the customer can specify the service objectives to be met by the underlay network (e.g., one-way delay to cross a service function path, one-way delay to reach a specific SF). These SFs are considered as ancillary CEs and are possibly placeholders (i.e., the SFs are identified, but not their locators).
顧客は、これらのSFが呼び出される順序とともに、一連のサービス関数（SFS）を含むIETFネットワークスライスサービスを要求する場合があります。また、顧客は、アンダーレイネットワークによって満たされるサービス目標を指定できます（たとえば、サービス関数パスを越えるための一元配置遅延、特定のSFに到達するための一元配置遅延）。これらのSFは補助CEと見なされ、おそらくプレースホルダーです（つまり、SFは識別されますが、ロケーターではありません）。
Service Function Chaining (SFC) [RFC7665] techniques can be used by a provider to instantiate such an IETF Network Slice Service. An NSC may proceed as follows.
サービス関数チェーン（SFC）[RFC7665]手法は、プロバイダーがそのようなIETFネットワークスライスサービスをインスタンス化するために使用できます。NSCは次のように進行する場合があります。
* Expose a set of ancillary CEs that are hosted in the underlay network.
* アンダーレイネットワークでホストされている補助CESのセットを公開します。
* Capture the SFC requirements (including traffic performance metrics) from the customer. One or more service chains may be associated with the same IETF Network Slice Service as connectivity constructs.
* 顧客からSFC要件（トラフィックパフォーマンスメトリックを含む）をキャプチャします。1つ以上のサービスチェーンは、接続コンストラクトと同じIETFネットワークスライスサービスに関連付けられている場合があります。
* Execute an SF placement algorithm to decide where to locate the ancillary CEs in order to fulfill the service objectives.
* SF配置アルゴリズムを実行して、サービス目標を達成するために補助CEを見つける場所を決定します。
* Generate SFC classification rules to identify part of the slice traffic that will be bound to an SFC. These classification rules may be the same as or distinct from the identification rules used to bind incoming traffic to the associated IETF Network Slice.
* SFC分類ルールを生成して、SFCにバインドされるスライストラフィックの一部を識別します。これらの分類ルールは、着信トラフィックを関連するIETFネットワークスライスにバインドするために使用される識別ルールと同じまたは異なる場合があります。
* An NSC also generates a set of SFC forwarding policies that govern how the traffic will be forwarded along a Service Function Path (SFP).
* NSCは、サービス関数パス（SFP）に沿ってトラフィックの転送方法を支配するSFC転送ポリシーのセットも生成します。
* Identify the appropriate Classifiers in the underlay network and provision them with the classification rules. Likewise, an NSC communicates the SFC forwarding policies to the appropriate Service Function Forwarders (SFFs).
* アンダーレイネットワーク内の適切な分類器を特定し、分類ルールを提供します。同様に、NSCはSFC転送ポリシーを適切なサービス機能フォワード（SFF）に伝えます。
The provider can enable an SFC data plane mechanism, such as those described in [RFC8300], [RFC8596], or [RFC9491].
プロバイダーは、[RFC8300]、[RFC8596]、または[RFC9491]に記載されているようなSFCデータプレーンメカニズムを有効にできます。
An IETF Network Slice Service customer may request that the IETF Network Slice delivered to them is such that changes to other IETF Network Slices or to other services do not have any negative impact on the delivery of the IETF Network Slice. The IETF Network Slice Service customer may specify the extent to which their IETF Network Slice Service is unaffected by changes in the provider network or by the behavior of other IETF Network Slice Service customers. The customer may express this via an SLE it agrees with the provider. This concept is termed "isolation".
IETFネットワークスライスサービスの顧客は、それらに配信されるIETFネットワークスライスが、他のIETFネットワークスライスまたは他のサービスの変更がIETFネットワークスライスの配信にマイナスの影響を与えないようにすることを要求する場合があります。IETFネットワークスライスサービスの顧客は、IETFネットワークスライスサービスがプロバイダーネットワークの変更または他のIETFネットワークスライスサービス顧客の動作によって影響を受けない範囲を指定する場合があります。顧客は、プロバイダーと一致するSLEを介してこれを表現する場合があります。この概念は「分離」と呼ばれます。
In general, a customer cannot tell whether a service provider is meeting an isolation SLE. If the service varies such that an SLO is breached, then the customer will become aware of the problem, and if the service varies within the allowed bounds of the SLOs, there may be no noticeable indication that this SLE has been violated.
一般に、顧客はサービスプロバイダーが隔離SLEを満たしているかどうかを判断できません。SLOが違反されるようにサービスが異なる場合、顧客は問題を認識し、サービスがSLOの許可境界内で異なる場合、このSLEが違反していることを顕著な兆候はない場合があります。
Isolation may be achieved in the underlay network by various forms of resource partitioning, ranging from dedicated allocation of resources for a specific IETF Network Slice to sharing of resources with safeguards. For example, traffic separation between different IETF Network Slices may be achieved using VPN technologies, such as L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing in using shared network resources, etc. Finally, service continuity may be ensured by reserving backup paths for critical traffic and dedicating specific network resources for a selected number of IETF Network Slices.
特定のIETFネットワークスライスのリソースの専用割り当てから、保護とのリソースの共有に至るまで、さまざまな形式のリソースパーティション化によって、アンダーレイネットワークで分離が達成される場合があります。たとえば、L3VPN、L2VPN、EVPNなどのVPNテクノロジーを使用して、異なるIETFネットワークスライス間のトラフィック分離を実現できます。干渉回避は、ネットワーク容量の計画、専用ネットワークリソースの割り当て、トラフィックポリシングまたは形成によって達成される場合があります。共有ネットワークリソースなど。最後に、重要なトラフィックのバックアップパスを予約し、選択した数のIETFネットワークスライスに特定のネットワークリソースを捧げることにより、サービスの継続性を確保できます。
IETF Network Slice realization needs to be instrumented in order to track how it is working, and it might be necessary to modify the IETF Network Slice as requirements change. Dynamic reconfiguration might be needed.
IETFネットワークスライスの実現は、それがどのように機能しているかを追跡するために計装する必要があり、要件が変更されるにつれてIETFネットワークスライスを変更する必要があるかもしれません。動的な再構成が必要になる場合があります。
The various management interfaces and components are discussed in Section 6.
さまざまな管理インターフェイスとコンポーネントについて説明します。セクション6で説明します。
This document specifies terminology and has no direct effect on the security of implementations or deployments. In this section, a few of the security aspects are identified.
このドキュメントは用語を指定し、実装または展開のセキュリティに直接的な影響を与えません。このセクションでは、セキュリティの側面のいくつかを特定します。
Conformance to security constraints:
セキュリティの制約への適合：
Specific security requests from customer-defined IETF Network Slice Services will be mapped to their realization in the underlay networks. Underlay networks will require capabilities to conform to customer's requests as some aspects of security may be expressed in SLEs.
顧客定義のIETFネットワークスライスサービスからの特定のセキュリティリクエストは、アンダーレイネットワークでの実現にマッピングされます。アンダーレイネットワークでは、セキュリティのいくつかの側面がSLEで表現される可能性があるため、顧客の要求に準拠する機能が必要です。
IETF NSC authentication:
IETF NSC認証：
Underlay networks need to be protected against attacks from an adversary NSC as this could destabilize overall network operations. An IETF Network Slice may span different networks; therefore, an NSC should have strong authentication with each of these networks. Furthermore, both the IETF Network Slice Service Interface and the Network Configuration Interface need to be secured with a robust authentication and authorization mechanism and associated auditing mechanism.
アンダーレイネットワークは、敵のNSCからの攻撃から保護する必要があります。これは、ネットワーク操作全体を不安定にする可能性があるためです。IETFネットワークスライスは、異なるネットワークにまたがる場合があります。したがって、NSCは、これらの各ネットワークに対して強力な認証を持つ必要があります。さらに、IETFネットワークスライスサービスインターフェイスとネットワーク構成インターフェイスの両方を、堅牢な認証と承認メカニズムと関連する監査メカニズムで保護する必要があります。
Specific isolation criteria:
特定の分離基準：
The nature of conformance to isolation requests means that it should not be possible to attack an IETF Network Slice Service by varying the traffic on other services or slices carried by the same underlay network. In general, isolation is expected to strengthen the IETF Network Slice security.
分離要求への適合性の性質は、同じアンダーレイネットワークによって運ばれる他のサービスまたはスライスのトラフィックを変更することにより、IETFネットワークスライスサービスを攻撃することができないことを意味します。一般に、分離はIETFネットワークスライスセキュリティを強化すると予想されます。
Data confidentiality and integrity of an IETF Network Slice:
IETFネットワークスライスのデータの機密性と整合性：
An IETF Network Slice might include encryption and other security features as part of the service (for example, as SLEs). However, a customer wanting to guarantee that their data is secure from inspection or modification as it passes through the network of the operator that provides the IETF Network Slice Service will need to provision their own security solutions (e.g., with IPsec) or send only already otherwise-encrypted traffic through the slice.
IETFネットワークスライスには、サービスの一部として暗号化やその他のセキュリティ機能が含まれる場合があります（たとえば、SLESなど）。ただし、IETFネットワークスライスサービスを提供するオペレーターのネットワークを通過する際に、データが検査または変更から安全であることを保証したい顧客は、独自のセキュリティソリューション（IPSECなど）をプロビジョニングするか、すでに送信する必要があります。それ以外の場合は、スライスを介した暗号化されたトラフィック。
See [NGMN-SEC] on 5G network slice security for discussion relevant to this section.
このセクションに関連するディスカッションについては、5Gネットワークスライスセキュリティについて[NGMN-SEC]を参照してください。
IETF Network Slices might use underlying virtualized networking. All types of virtual networking require special consideration to be given to the separation of traffic between distinct virtual networks, as well as some amount of protection from effects of traffic use of underlay network (and other) resources from other virtual networks sharing those resources.
IETFネットワークスライスは、基礎となる仮想化ネットワークを使用する場合があります。あらゆるタイプの仮想ネットワーキングには、異なる仮想ネットワーク間のトラフィックの分離に特別な検討が必要であり、これらのリソースを共有する他の仮想ネットワークからのトラフィック使用（およびその他の）リソースのトラフィック使用の影響からのある程度の保護が必要です。
For example, if a service requires a specific upper bound on latency, then that service could be degraded with added delay caused by the processing of packets from another service or application that shares the same network resources. Thus, without careful planning or traffic policing, it may be possible to attack an IETF Network Slice Service simply by increasing the traffic on another service in the network.
たとえば、サービスがレイテンシで特定の上限を必要とする場合、そのサービスは、同じネットワークリソースを共有する別のサービスまたはアプリケーションからのパケットの処理によって引き起こされる追加の遅延で分解される可能性があります。したがって、慎重な計画やトラフィックポリシングなしでは、ネットワーク内の別のサービスのトラフィックを増やすだけで、IETFネットワークスライスサービスを攻撃することが可能かもしれません。
Similarly, in a network with virtual functions, noticeably impeding access to a function used by another IETF Network Slice (for instance, compute resources) can be just as service-degrading as delaying physical transmission of associated packet in the network. Again, careful planning and policing of service demands may mitigate such attacks.
同様に、仮想関数を備えたネットワークでは、別のIETFネットワークスライス（たとえば、計算リソース）で使用される関数へのアクセスを顕著に妨げ、ネットワーク内の関連パケットの物理的伝送を遅らせるのと同じようにサービスを分解することができます。繰り返しますが、サービスの要求の慎重な計画と警察は、そのような攻撃を軽減する可能性があります。
Both of these forms of attack may also be mitigated by reducing the access to information about how IETF Network Slice Services are supported in a network.
これらの形式の攻撃は両方とも、ネットワークでIETFネットワークスライスサービスがどのようにサポートされているかについての情報へのアクセスを削減することで緩和される場合があります。
Privacy of IETF Network Slice Service customers must be preserved. It should not be possible for one IETF Network Slice Service customer to discover the presence of other customers, nor should sites that are members of one IETF Network Slice be visible outside the context of that IETF Network Slice.
IETFネットワークスライスサービスのプライバシーは、顧客を保存する必要があります。1つのIETFネットワークスライスサービスの顧客が他の顧客の存在を発見することはできません。また、1つのIETFネットワークスライスのメンバーであるサイトが、そのIETFネットワークスライスのコンテキストの外に表示されるべきではありません。
In this sense, it is of paramount importance that the system uses the privacy protection mechanism defined for the specific underlay technologies that support the slice, including in particular those mechanisms designed to preclude acquiring identifying information associated with any IETF Network Slice Service customer.
この意味で、特にIETFネットワークスライスサービス顧客に関連する識別情報を取得するために設計されたメカニズムを含む、スライスをサポートする特定のアンダーレイテクノロジーに対して定義されたプライバシー保護メカニズムをシステムが使用することが最も重要です。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[ACTN-NS] King, D., Drake, J., Zheng, H., and A. Farrel,
"Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Network Slicing", Work in
Progress, Internet-Draft, draft-ietf-teas-applicability-
actn-slicing-05, 11 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
applicability-actn-slicing-05>.
[ENHANCED-VPN]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for NRP-based Enhanced Virtual Private Network",
Work in Progress, Internet-Draft, draft-ietf-teas-
enhanced-vpn-17, 25 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-17>.
[GNMI] Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
C., and C. Morrow, "gRPC Network Management Interface
(gNMI)", Work in Progress, Internet-Draft, draft-
openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-openconfig-
rtgwg-gnmi-spec-01>.
[HIPAA] HHS, "The Security Rule", <https://www.hhs.gov/hipaa/for-
professionals/security/index.html>.
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
[NFVArch] ETSI, "Network Functions Virtualisation (NFV);
Architectural Framework", V1.1.1, ETSI GS NFV 002, October
2013, <http://www.etsi.org/deliver/etsi_gs/
nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>.
[NGMN-NS-Concept]
NGMN Alliance, "Description of Network Slicing Concept",
January 2016, <https://ngmn.org/wp-content/
uploads/160113_NGMN_Network_Slicing_v1_0.pdf>.
[NGMN-SEC] NGMN, "5G security recommendations Package #2 - Network
Slicing", April 2016, <https://www.ngmn.org/wp-
content/uploads/Publications/2016/160429_NGMN_5G_Security_
Network_Slicing_v1_0.pdf>.
[ORAN] O-RAN, "O-RAN Working Group 1 Slicing Architecture",
O-RAN.WG1 v06.00, 2022,
<https://orandownloadsweb.azurewebsites.net/
specifications>.
[PCI] PCI Security Standards Council, "PCI DSS", March 2022,
<https://www.pcisecuritystandards.org/document_library>.
[RESOURCE-AWARE-SEGMENTS]
Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li,
"Introducing Resource Awareness to SR Segments", Work in
Progress, Internet-Draft, draft-ietf-spring-resource-
aware-segments-08, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
resource-aware-segments-08>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[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>.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, DOI 10.17487/RFC4397, February
2006, <https://www.rfc-editor.org/info/rfc4397>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008,
<https://www.rfc-editor.org/info/rfc5212>.
[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>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>.
[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>.
[RFC9491] Guichard, J., Ed. and J. Tantsura, Ed., "Integration of
the Network Service Header (NSH) and Segment Routing for
Service Function Chaining (SFC)", RFC 9491,
DOI 10.17487/RFC9491, November 2023,
<https://www.rfc-editor.org/info/rfc9491>.
[TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501, 2019.
[TS28.530] 3GPP, "Management and orchestration; Concepts, use cases
and requirements", 3GPP TS 28.530, 2019.
[TS33.210] 3GPP, "Network Domain Security (NDS); IP network layer
security", Release 14, December 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2279>.
[USE-CASES]
Contreras, L. M., Homma, S., Ordonez-Lucena, J. A.,
Tantsura, J., and H. Nishihara, "IETF Network Slice Use
Cases and Attributes for the Slice Service Interface of
IETF Network Slice Controllers", Work in Progress,
Internet-Draft, draft-ietf-teas-ietf-network-slice-use-
cases-01, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-use-cases-01>.
This appendix contains realization examples. This is not intended to be a complete set of possible deployments, nor does it provide definitive ways to realize these deployments.
この付録には、実現例が含まれています。これは、可能な展開の完全なセットであることを意図したものではなく、これらの展開を実現するための決定的な方法を提供しません。
The examples shown here must not be considered to be normative. The descriptions of terms and concepts in the body of the document take precedence.
ここに示す例は、規範的と見なされてはなりません。ドキュメントの本文における用語と概念の説明が優先されます。
As described in Section 4.2, an MP2P service can be realized with multiple P2P connectivity constructs. Figure 5 shows a simple MP2P service where traffic is sent from any of CE1, CE2, and CE3 to the receiver, which is CE4. The service comprises three P2P connectivity constructs: CE1-CE4, CE2-CE4, and CE3-CE4.
セクション4.2で説明したように、複数のP2P接続コンストラクトでMP2Pサービスを実現できます。図5は、CE1、CE2、およびCE3のいずれかからトラフィックが受信機であるCE4である単純なMP2Pサービスを示しています。このサービスは、CE1-CE4、CE2-CE4、およびCE3-CE4の3つのP2P接続コンストラクトで構成されています。
CE1
___|________
/ \ \
( \______ )
( \)
CE2---(--------------)---CE4
( _______/)
( / )
\___|________/
|
CE3
Figure 5: Example MP2P Service with P2P Connections
図5：P2P接続を備えたMP2Pサービスの例
Section 4.2.3 introduces the concept of ancillary CEs. Figure 6 shows a simple example of IETF Network Slices with connectivity constructs that are used to deliver traffic from CE1 to CE3, taking in a service function along the path.
セクション4.2.3では、補助CEの概念を紹介します。図6は、CE1からCE3へのトラフィックを配信するために使用される接続コンストラクトを備えたIETFネットワークスライスの簡単な例を示しており、パスに沿ってサービス機能を取り入れています。
CE1 CE2 CE3
xo* * * *ox
____xo*_________*_*_________*ox____
_/ xo* * * *ox \_
/ xo*********** ***********ox \
( xo ox )
( xooooooooo(ACE1)oooooooooox )
( x x )
( x ------------------ x )
( x | Service Function | x )
( x | ....(ACE2).... | x )
( x | : : | x )
( xxxx.:....(ACE3)....:.xxxxx )
( | : : | )
( | ....(ACE4).... | )
( | | )
( ------------------ )
( )
\_ Operator Network _/
\___________________________________/
Figure 6: Example with Ancillary CEs
図6：補助CEの例
A customer may want to utilize a service where traffic is delivered from CE1 to CE3, including a service function sited within the customer's network at CE2. To achieve this, the customer may request an IETF Network Slice Service comprising two P2P connectivity constructs: CE1-CE2 and CE2-CE3 (represented with "*" in Figure 6).
顧客は、CE2の顧客ネットワーク内に配置されたサービス機能を含む、CE1からCE3にトラフィックが配信されるサービスを利用したい場合があります。これを達成するために、顧客は、2つのP2P接続コンストラクトを含むIETFネットワークスライスサービスを要求する場合があります：CE1-CE2とCE2-CE3（図6の「*」で表されます）。
Alternatively, the service function for the same CE1 to CE3 flow may be hosted at a node within the network operator's infrastructure. This is an ancillary CE in the IETF Network Slice Service that the customer requests. This service contains two P2P connectivity constructs: CE1-ACE1 and ACE1-CE3 (represented with "o" in Figure 6). How the customer knows of the existence of the ancillary CE and the service functions it offers is a matter for agreement between the customer and the network operator.
あるいは、同じCE1からCE3フローのサービス関数は、ネットワークオペレーターのインフラストラクチャ内のノードでホストされる場合があります。これは、顧客が要求するIETFネットワークスライスサービスの補助的なCEです。このサービスには、2つのP2P接続コンストラクトが含まれています。CE1-ACE1とACE1-CE3（図6の「O」で表されます）。顧客が補助CEの存在とそれが提供するサービス機能をどのように知っているかは、顧客とネットワークオペレーターの間の合意の問題です。
Finally, it may be that the customer knows that the network operator is able to provide the service function but does not know the location of the ancillary CE at which the service function is hosted. Indeed, it may be that the service function is hosted at a number of ancillary CEs (ACE2, ACE3, and ACE4 in Figure 6); the customer may know the identities of the ancillary CEs but be unwilling or unable to choose one, or the customer may not know about the ancillary CEs. In this case, the IETF Network Slice Service request contains two P2P connectivity constructs: CE1-ServiceFunction and ServiceFunction-CE3 (represented with "x" in Figure 6). It is left as a choice for the network operator as to which ancillary CE to use and how to realize the connectivity constructs.
最後に、ネットワークオペレーターがサービス機能を提供できることを顧客が知っているかもしれませんが、サービス機能がホストされている補助CEの位置を知りません。実際、サービス関数は、図6の多くの補助CE（ACE2、ACE3、およびACE4）でホストされている可能性があります。顧客は、補助的なCEのアイデンティティを知っているかもしれませんが、それを選択することを嫌がっている、または選択できない場合や、顧客が補助CEについて知らない場合があります。この場合、IETFネットワークスライスサービスリクエストには、CE1-ServiceFunctionとService-Function-CE3（図6の「X」で表される）2つのP2P接続コンストラクトが含まれています。ネットワークオペレーターが使用する補助CEと、接続コンストラクトをどのように実現するかについての選択肢として残されています。
Hub and spoke is a popular way to realize A2A connectivity in support of multiple P2P traffic flows (where the hub performs routing) or P2MP flows (where the hub is responsible for replication). In many cases, it is the network operator's choice whether to use hub and spoke to realize a mesh of P2P connectivity constructs or P2MP connectivity constructs; this is entirely their business as the customer is not aware of how the connectivity constructs are supported within the network.
Hub and Spokeは、複数のP2Pトラフィックフロー（ハブがルーティングを実行する場所）またはP2MPフロー（ハブが複製の原因）をサポートするA2A接続を実現するための一般的な方法です。多くの場合、ハブを使用してP2P接続コンストラクトのメッシュまたはP2MP接続コンストラクトのメッシュを実現するかどうかは、ネットワークオペレーターの選択です。これは、顧客がネットワーク内で接続コンストラクトがどのようにサポートされているかを認識していないため、完全に彼らのビジネスです。
However, it may be the case that the customer wants to control the behavior and location of the hub. In this case, the hub appears as an ancillary CE as shown in Figure 7.
ただし、顧客がハブの動作と場所を制御したい場合があります。この場合、図7に示すように、ハブは補助的なCEとして表示されます。
For the P2P mesh case, the customer does not specify a mesh of P2P connectivity constructs (such as CE1-CE2, CE1-CE3, CE2-CE3, and the equivalent reverse direction connectivity) but connects each CE to the hub with P2P connectivity constructs (as CE1-Hub, CE2-Hub, CE3-Hub, and the equivalent reverse direction connectivity). This scales better in terms of provisioning compared to a full mesh but requires that the hub is capable of routing traffic between connectivity constructs.
P2Pメッシュの場合、顧客はP2P接続コンストラクトのメッシュ（CE1-CE2、CE1-CE3、CE2-CE3、同等の逆方向接続など）のメッシュを指定しませんが、P2P接続コンストラクトで各CEをハブに接続します。（CE1-HUB、CE2-HUB、CE3-HUB、および同等の逆方向接続として）。これは、フルメッシュと比較してプロビジョニングの点でより良くスケーリングしますが、ハブは接続コンストラクト間のトラフィックをルーティングできる必要があります。
For the P2MP case, the customer does not specify a single P2MP connectivity construct (in this case, CE3-{CE1+CE2}) but requests three P2P connectivity constructs (as CE3-Hub, Hub-CE1, and Hub-CE2). It is the hub's responsibility to replicate the traffic from CE3 and send it to both CE1 and CE2.
P2MPの場合、顧客は単一のP2MP接続コンストラクト（この場合はCE3- {CE1 CE2}）を指定しませんが、3つのP2P接続コンストラクト（CE3-HUB、HUB-CE1、およびHUB-CE2として）を要求します。CE3からトラフィックを複製し、CE1とCE2の両方に送信することは、ハブの責任です。
------------
CE1 | Hub | CE2
|| ------------ ||
___||_____||__||__||_____||___
/ || || || || || \
( ====== || ====== )
( || )
( || )
\______________||______________/
||
CE3
Figure 7: Example Hub and Spoke under Customer Control
図7：ハブの例と顧客管理下で話す
Layer 3 VPNs are a common service offered by network operators to their customers. They may be modeled as an A2A service but are often realized as a mesh of P2P connections, or if multicast is supported, they may be realized as a mesh of P2MP connections.
レイヤー3 VPNは、ネットワークオペレーターが顧客に提供する一般的なサービスです。それらはA2Aサービスとしてモデル化される可能性がありますが、P2P接続のメッシュとして実現することが多い、またはマルチキャストがサポートされている場合、P2MP接続のメッシュとして実現される場合があります。
Figure 8 shows an IETF Network Slice Service with a single A2A connectivity construct between the SDPs CE1, CE2, CE3, and CE4. It is a free choice how the network operator realizes this service. They may use a full mesh of P2P connections, a hub-and-spoke configuration, or some combination of these approaches.
図8は、SDPS CE1、CE2、CE3、およびCE4の間に単一のA2A接続コンストラクトを備えたIETFネットワークスライスサービスを示しています。ネットワークオペレーターがこのサービスを実現する方法は自由な選択です。P2P接続の完全なメッシュ、ハブアンドスポーク構成、またはこれらのアプローチの組み合わせを使用する場合があります。
CE1 CE2
____|_______________|____
/ :...............: \
( :. . : )
( : ...... . : )
( : ..... : )
( : .... . : )
( : . .... : )
( : . . : )
( :...............: )
\____:_______________:____/
| |
CE3 CE4
Figure 8: Example L3VPN Service
図8：L3VPNサービスの例
As mentioned in Section 5.3, IETF Network Slices may be arranged hierarchically. There is nothing special or novel about such an arrangement, and it models the hierarchical arrangement of services of virtual networks in many other environments.
セクション5.3で述べたように、IETFネットワークスライスは階層的に配置される場合があります。このような配置について特別なものや小説は何もありません。また、他の多くの環境で仮想ネットワークのサービスの階層的配置をモデル化しています。
As shown in Figure 9, an Operator's Controller (NSC) that is requested to provide an IETF Network Slice Service for a customer may, in turn, request an IETF Network Slice Service from another carrier. The Operator's NSC may manage and control the underlay IETF Network Slice by modifying the requested connectivity constructs and changing the SLAs. The customer is entirely unaware of the hierarchy of slices, and the underlay carrier is entirely unaware of how its slice is being used.
図9に示すように、顧客にIETFネットワークスライスサービスを提供するように要求されるオペレーターのコントローラー（NSC）は、別のキャリアからIETFネットワークスライスサービスを要求することができます。オペレーターのNSCは、要求された接続コンストラクトを変更してSLAを変更することにより、アンダーレイIETFネットワークスライスを管理および制御できます。顧客はスライスの階層を完全に知らず、アンダーレイキャリアはスライスがどのように使用されているかをまったく知らない。
This stacking of IETF Network Slice constructs is not different to the way virtual networks may be arranged.
IETFネットワークスライスコンストラクトのこの積み重ねは、仮想ネットワークの配置方法と違いはありません。
--------------
| Network |
| Slice |
| Orchestrator |
--------------
| IETF Network Slice
| Service Request
| Customer view
....|................................
-v---------------- Operator view
|Controller |
| ------------ |
| | IETF | |
| | Network |---|---
| | Slice | | |
| | Controller | | |
| | (NSC) | | |
| ------------ | |
------------------ |
| IETF Network Slice
| Service Request
|
.........................|.....................
----------v------- Carrier view
|Controller |
| ------------ |
| | IETF | |
| | Network | |
| | Slice | |
| | Controller | |
| | (NSC) | |
| ------------ |
....| | Network |............
| | Configuration | Underlay Network
| v |
| ------------ |
| | Network | |
| | Controller | |
| | (NC) | |
| ------------ |
------------------
| Device Configuration
v
Figure 9: Example Hierarchical Arrangement of IETF Network Slices
図9：IETFネットワークスライスの階層的配置の例
In this case, the network hierarchy may also be used to provide connectivity between points in the higher-layer network, as shown in Figure 10. Here, an IETF Network Slice may be requested of the lower-layer network to provide the desired connectivity constructs to supplement the connectivity in the higher-layer network where this connectivity might be presented as a virtual link.
この場合、図10に示すように、ネットワーク階層を使用して、高層ネットワークのポイント間の接続を提供することもできます。この接続が仮想リンクとして提示される可能性のある高層ネットワークの接続性を補完する。
CE1 CE2
| |
| |
_|_________________________________________|_
( : : )
( :.............. ..............: )
(_______________:_____________:_______________)
__|_____________|__
( : : )
( :.............: )
(___________________)
Figure 10: Example Hierarchical Arrangement of IETF Network Slices to Bridge Connectivity
図10：接続性をブリッジするIETFネットワークスライスの階層的配置の例
It may be that end-to-end connectivity is achieved using a set of cooperating networks as described in Section 5.3. For example, there may be multiple interconnected networks that provide the required connectivity as shown in Figure 11. The networks may utilize different technologies and may be under separate administrative control.
セクション5.3で説明されているように、協力ネットワークのセットを使用してエンドツーエンドの接続性が達成される可能性があります。たとえば、図11に示すように、必要な接続を提供する複数の相互接続ネットワークがある場合があります。ネットワークは、異なるテクノロジーを利用し、別々の管理制御下にある場合があります。
CE1 CE2
| |
SDP1 SDP2
| |
_|____ ______ ______ ____|_
( ) ( ) ( ) ( )
( )---( )---( )---( )
(______) (______) (______) (______)
Figure 11: Example Customer View of Interconnected Networks Providing End-to-End Connectivity
図11：エンドツーエンドの接続を提供する相互接続されたネットワークの顧客ビューの例
In this scenario, the customer (represented by CE1 and CE2) may request an IETF Network Slice Service connecting the CEs. The customer considers the SDPs at the edge (shown as SDP1 and SDP2 in Figure 11) and might not be aware of how the end-to-end connectivity is composed.
このシナリオでは、顧客（CE1およびCE2で表される）がCESを接続するIETFネットワークスライスサービスを要求する場合があります。顧客は、SDPをエッジで検討し（図11でSDP1およびSDP2として表示）、エンドツーエンドの接続性がどのように構成されているかを認識していない場合があります。
However, because the various networks may be of different technologies and under separate administrative control, the networks are sliced individually, and coordination is necessary to deliver the desired connectivity. The Network-to-Network Interfaces (NNIs) are present as SDPs for the IETF Network Slices in each network, so that each network is individually sliced. In the example in Figure 12, this is illustrated as network 1 (N/w1) being sliced between SDP1 and SDPX, N/w2 being sliced between SDPY and SDPU, etc. The coordination activity involves binding the SDPs, and hence the connectivity constructs, to achieve end-to-end connectivity with the required SLOs and SLEs. In this way, simple and complex end-to-end connectivity can be achieved with a variety of connectivity constructs in the IETF Network Slices of different networks "stitched" together.
ただし、さまざまなネットワークは異なるテクノロジーであり、別々の管理制御下にある可能性があるため、ネットワークは個別にスライスされており、目的の接続性を提供するために調整が必要です。ネットワーク間インターフェイス（NNIS）は、各ネットワークのIETFネットワークスライスのSDPとして存在するため、各ネットワークが個別にスライスされます。図12の例では、これはSDP1とSDPXの間でスライスされているネットワーク1（N/W1）として示されています。N/W2はSDPYとSDPUなどの間でスライスされます。、必要なSLOおよびSLESとのエンドツーエンドの接続を実現します。このようにして、さまざまなネットワークのIETFネットワークスライスのさまざまな接続コンストラクトを使用して、シンプルで複雑なエンドツーエンドの接続性を実現できます。
CE1 CE2
| |
SDP1 SDP2
| |
_|____ ______ ______ ____|_
( ) SDPX ( ) SDPU ( ) SDPS ( )
( N/w1 )------( N/w2 )------( N/w3 )------( N/w4 )
(______) SDPY (______) SDPV (______) SDPT (______)
Figure 12: Example Delivery of an End-to-End IETF Network Slice with Interconnected Networks
図12：相互接続されたネットワークを備えたエンドツーエンドのIETFネットワークスライスの例の例
The controller/coordinator relationship is shown in Figure 13.
コントローラー/コーディネーターの関係を図13に示します。
--------------
| Network |
| Slice |
| Orchestrator |
--------------
| IETF Network Slice
| Service Request
| Customer view
....|................................
-v---------------- Coordinator view
|Coordinator |
| |
------------------
| |_________________
| |
| |
....|....................... ....|.....................
-v-------------- -v--------------
|Controller1 | Operator1 |Controller2 | Operator2
| ------------ | | ------------ |
| | IETF | | | | IETF | |
| | Network | | | | Network | |
| | Slice | | | | Slice | |
| | Controller | | | | Controller | |
| | (NSC) | | | | (NSC) | |
| ------------ | | ------------ |
....| | Network |............ | | Network |............
| | Config | Underlay1 | | Config | Underlay2
| v | | v |
| ------------ | | ------------ |
| | Network | | | | Network | |
| | Controller | | | | Controller | |
| | (NC) | | | | (NC) | |
| ------------ | | ------------ |
---------------- ----------------
| Device Configuration
v
Figure 13: Example Relationship of IETF Network Slice Coordination
図13：IETFネットワークスライス調整の例の例
The entire TEAS Network Slicing design team and everyone participating in related discussions has contributed to this document. Some text fragments in the document have been copied from the [ENHANCED-VPN], for which we are grateful.
TEASネットワークスライシングデザインチーム全体と関連する議論に参加する全員がこのドキュメントに貢献しています。ドキュメント内のいくつかのテキストフラグメントは、[Enhanced-VPN]からコピーされており、感謝しています。
Significant contributions to this document were gratefully received from the contributing authors listed in the "Contributors" section. In addition, we would like to also thank those others who have attended one or more of the design team meetings, including the following people not listed elsewhere:
この文書への重要な貢献は、「貢献者」セクションにリストされている貢献著者から感謝します。さらに、他の場所にリストされていない以下の人々を含む、1つ以上のデザインチームの会議に参加した他の人々にも感謝したいと思います。
* Aihua Guo
* aihua guo
* Bo Wu
* Bo Wu
* Greg Mirsky
* グレッグ・ミルスキー
* Lou Berger
* ルーバーガー
* Rakesh Gandhi
* Rakesh Gandhi
* Ran Chen
* 走ったチェン
* Sergio Belotti
* セルジオ・ベロッティ
* Stewart Bryant
* スチュワート・ブライアント
* Tomonobu Niwa
* トモノブ・ニワ
* Xuesong Geng
* Xuesong Geng
Further useful comments were received from Daniele Ceccarelli, Uma Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel Halpern, John Scudder, John Mullooly, Krzysztof Szarkowicz, Jingrong Xie, Jia He, Reese Enghardt, Dirk Von Hugo, Erik Kline, and Éric Vyncke.
ダニエレ・セッカレッリ、ウマ・チュンドゥリ、パヴァン・ビアラム、タレク・サード、オガキ、オスカー・ゴンザレス・デ・ディオス、Xiaobing Niu、ダン・ヴォイヤー、イゴール・ブリスキン、ルアー・ジャリル、ジョエル・ハルパーン、ジョン・マルルー、ジョン・マルルーリー、ジョン・スカッド、ジョン・スカッドからJingrong Xie、Jia He、Reese Enghardt、Dirk von Hugo、Erik Kline、およびEric Vyncke。
This work is partially supported by the European Commission under Horizon 2020 grant agreement number 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow).
この作業は、Horizon 2020 Grant契約番号101015857の下で欧州委員会によって部分的にサポートされています。
The following people contributed substantially to the content of this document and should be considered coauthors. Eric Gray was the original editor of the foundation documents.
次の人々は、この文書の内容に大きく貢献し、共著者と見なされるべきです。エリック・グレイは、財団文書の元の編集者でした。
Eric Gray
Retired
Jari Arkko
Ericsson
Email: jari.arkko@piuha.net
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Jie Dong
Huawei
Email: jie.dong@huawei.com
Xufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.com
Adrian Farrel (editor)
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
John Drake (editor)
Individual
United States of America
Email: je_drake@yahoo.com
Reza Rokui
Ciena
Email: rrokui@ciena.com
Shunsuke Homma
NTT
Japan
Email: shunsuke.homma.ietf@gmail.com
Kiran Makhijani
Futurewei
United States of America
Email: kiran.ietf@gmail.com
Luis M. Contreras
Telefonica
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Jeff Tantsura
Nvidia
Email: jefftant.ietf@gmail.com