[要約] RFC 8597は、ソフトウェア定義ネットワーキング（SDN）のための協調レイヤーアーキテクチャ（CLAS）に関するものであり、SDNの柔軟性と拡張性を向上させることを目的としています。
Independent Submission LM. Contreras
Request for Comments: 8597 Telefonica
Category: Informational CJ. Bernardos
ISSN: 2070-1721 UC3M
D. Lopez
Telefonica
M. Boucadair
Orange
P. Iovanna
Ericsson
May 2019
Cooperating Layered Architecture for Software-Defined Networking (CLAS)
Software-Defined Networking（CLAS）の協調型レイヤードアーキテクチャ
Abstract
概要
Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.
Software-Defined Networking（SDN）は、ネットワークノードのデータプレーンからのコントロールプレーンの分離と、1つまたは一連のコントロールエンティティでの論理的な集中化を提唱しています。ほとんどのネットワークおよび/またはサービスインテリジェンスは、これらの制御エンティティに移動されます。通常、このようなエンティティは、垂直に緊密に統合された方法で相互作用する制御機能の概要と見なされます。複数の分散ネットワークノードから論理的な中央エンティティへの制御機能の再配置は、概念的に、さまざまな目的を持つ複数の制御機能をまとめます。その結果、既存のソリューションでは、トランスポートコントロールとトランスポート機能に依存するサービスを明確に分離できません。
This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.
このドキュメントでは、ソフトウェア定義ネットワーキング（CLAS）の協調型レイヤードアーキテクチャと呼ばれるアプローチについて説明します。トランスポートに関連する制御機能は、サービスに関連する制御機能とは異なり、独自に提供および保守でき、独自の進化をたどることができます。道。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8597.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8597で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6
3.1. Functional Strata . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Transport Stratum . . . . . . . . . . . . . . . . . . 9
3.1.2. Service Stratum . . . . . . . . . . . . . . . . . . . 10
3.1.3. Recursiveness . . . . . . . . . . . . . . . . . . . . 10
3.2. Plane Separation . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Management Plane . . . . . . . . . . . . . . . . . . 11
3.2.3. Resource Plane . . . . . . . . . . . . . . . . . . . 11
4. Required Features . . . . . . . . . . . . . . . . . . . . . . 11
5. Communication between SDN Controllers . . . . . . . . . . . . 12
6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 12
6.1. Full SDN Environments . . . . . . . . . . . . . . . . . . 13
6.1.1. Multiple Service Strata Associated with a Single
Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.1.2. Single Service Stratum Associated with Multiple
Transport Strata . . . . . . . . . . . . . . . . . . 13
6.2. Hybrid Environments . . . . . . . . . . . . . . . . . . . 13
6.2.1. SDN Service Stratum Associated with a Legacy
Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.2.2. Legacy Service Stratum Associated with an SDN
Transport Stratum . . . . . . . . . . . . . . . . . . 13
6.3. Multi-domain Scenarios in the Transport Stratum . . . . . 14
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Network Function Virtualization (NFV) . . . . . . . . . . 14
7.2. Abstraction and Control of TE Networks . . . . . . . . . 15
8. Challenges for Implementing Actions between Service and
Transport Strata . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Relationship with RFC 7426 . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Network softwarization advances are facilitating the introduction of programmability in the services and infrastructures of telecommunications operators. This is generally achieved through the introduction of Software-Defined Networking (SDN) [RFC7149] [RFC7426] capabilities in the network, including controllers and orchestrators.
ネットワークのソフトウォーライゼーションの進歩により、通信事業者のサービスとインフラストラクチャにプログラマビリティを導入することが容易になっています。これは一般的に、ソフトウェア定義ネットワーク（SDN）[RFC7149] [RFC7426]機能をコントローラーやオーケストレーターなどのネットワークに導入することで実現されます。
However, there are concerns of a different nature that these SDN capabilities have to resolve. On the one hand, actions focused on programming the network to handle the connectivity or forwarding of digital data between distant nodes are needed. On the other hand, actions devoted to programming the functions or services that process (or manipulate) such digital data are also needed.
ただし、これらのSDN機能が解決しなければならない異なる性質の懸念があります。一方で、離れたノード間のデジタルデータの接続または転送を処理するためのネットワークのプログラミングに焦点を当てたアクションが必要です。一方、そのようなデジタルデータを処理（または操作）する機能またはサービスのプログラミングに特化したアクションも必要です。
SDN advocates for the separation of the control plane from the data plane in the network nodes by introducing abstraction among both planes, allowing the control logic on a functional entity, which is commonly referred as SDN Controller, to be centralized; one or multiple controllers may be deployed. A programmatic interface is then defined between a forwarding entity (at the network node) and a control entity. Through that interface, a control entity instructs the nodes involved in the forwarding plane and modifies their traffic-forwarding behavior accordingly. Support for additional capabilities (e.g., performance monitoring, fault management, etc.) could be expected through this kind of programmatic interface [RFC7149].
SDNは、両方のプレーン間に抽象化を導入することにより、ネットワークノードのデータプレーンからコントロールプレーンを分離することを提唱しており、機能エンティティ上のコントロールロジック（一般的にSDNコントローラーと呼ばれます）を集中化できます。 1つまたは複数のコントローラーを展開できます。次に、プログラムインターフェイスが転送エンティティ（ネットワークノード）と制御エンティティの間に定義されます。そのインターフェースを介して、制御エンティティは転送プレーンに関与するノードに指示し、それに応じてトラフィック転送動作を変更します。この種のプログラムインターフェース[RFC7149]により、追加機能（パフォーマンスモニタリング、障害管理など）のサポートが期待できます。
Most of the intelligence is moved to this kind of functional entity. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion.
インテリジェンスのほとんどは、この種の機能エンティティに移動します。通常、このようなエンティティは、垂直に緊密に統合された方法で相互作用する制御機能の概要と見なされます。
The approach of considering an omnipotent control entity governing the overall aspects of a network, especially both the transport network and the services to be supported on top of it, presents a number of issues:
ネットワークの全体的な側面、特にトランスポートネットワークとその上でサポートされるサービスの両方を管理する全能性制御エンティティを検討するアプローチには、いくつかの問題があります。
o From a provider perspective, where different departments usually are responsible for handling service and connectivity (i.e., transport capabilities for the service on top), the mentioned approach offers unclear responsibilities for complete service provision and delivery.
o プロバイダーの観点から見ると、通常、さまざまな部門がサービスと接続（つまり、サービスのトランスポート機能）の処理を担当しているため、前述のアプローチでは、完全なサービスの提供と配信について、不明確な責任が生じます。
o Complex reuse of functions for the provision of services.
o サービスの提供のための機能の複雑な再利用。
o Closed, monolithic control architectures.
o 閉じたモノリシック制御アーキテクチャ。
o Difficult interoperability and interchangeability of functional components.
o 機能コンポーネントの相互運用性と互換性が難しい。
o Blurred business boundaries among providers, especially in situations where one provider provides only connectivity while another provider offers a more sophisticated service on top of that connectivity.
o 特に、あるプロバイダーが接続のみを提供し、別のプロバイダーがその接続に加えてより高度なサービスを提供する状況では、プロバイダー間のビジネス境界がぼやけています。
o Complex service/network diagnosis and troubleshooting, particularly to determine which layer is responsible for a failure.
o 複雑なサービス/ネットワークの診断とトラブルシューティング、特に障害の原因となっている層を特定するため。
The relocation of the control functions from a number of distributed network nodes to another entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing SDN solutions do not provide a clear separation between services and transport control. Here, the separation between service and transport follows the distinction provided by [Y.2011] and as defined in Section 2 of this document.
複数の分散ネットワークノードから別のエンティティへの制御機能の再配置では、概念的に、さまざまな目的を持つ複数の制御機能をまとめます。その結果、既存のSDNソリューションでは、サービスとトランスポート制御を明確に分離できません。ここで、サービスとトランスポートの分離は、[Y.2011]によって提供され、このドキュメントのセクション2で定義されている区別に従います。
This document describes an approach called Cooperating Layered Architecture for SDN (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.
このドキュメントでは、SDN向けの協調型レイヤードアーキテクチャ（CLAS）と呼ばれるアプローチについて説明します。トランスポートに関連する制御機能は、サービスに関連する制御機能とは異なり、サービスを個別に提供および維持し、独自の進化経路をたどることができます。
Despite such differentiation, close cooperation between the service and transport layers (or strata in [Y.2011]) and the associated components are necessary to provide efficient usage of the resources.
このような差別化にもかかわらず、リソースを効率的に使用するには、サービスレイヤーとトランスポートレイヤー（または[Y.2011]の階層）と関連コンポーネントとの緊密な連携が必要です。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
o Transport: denotes the transfer capabilities offered by a networking infrastructure. The transfer capabilities can rely upon pure IP techniques or other means, such as MPLS or optics.
o トランスポート：ネットワークインフラストラクチャによって提供される転送機能を示します。転送機能は、純粋なIP技術や、MPLSやオプティクスなどの他の手段に依存する場合があります。
o Service: denotes a logical construct that makes use of transport capabilities.
o サービス：トランスポート機能を利用する論理構造を示します。
This document does not make any assumptions about the functional perimeter of a service that can be built above a transport infrastructure. As such, a service can be offered to customers or invoked for the delivery of another (added-value) service.
このドキュメントでは、トランスポートインフラストラクチャの上に構築できるサービスの機能境界については想定していません。そのため、サービスは顧客に提供したり、別の（付加価値）サービスの提供のために呼び出すことができます。
o Layer: refers to the set of elements that enable either transport or service capabilities, as defined previously. In [Y.2011], this is referred to as a "stratum", and the two terms are used interchangeably.
o レイヤー：前に定義したように、トランスポートまたはサービス機能を有効にする要素のセットを指します。 [Y.2011]では、これは「層」と呼ばれ、2つの用語は同じ意味で使用されます。
o Domain: is a set of elements that share a common property or characteristic. In this document, it applies to the administrative domain (i.e., elements pertaining to the same organization), technological domain (elements implementing the same kind of technology, such as optical nodes), etc.
o ドメイン：共通のプロパティまたは特性を共有する要素のセットです。このドキュメントでは、管理ドメイン（つまり、同じ組織に属する要素）、技術ドメイン（光ノードなど、同じ種類のテクノロジを実装する要素）などに適用されます。
o SDN Intelligence: refers to the decision-making process that is hosted by a node or a set of nodes. These nodes are called SDN controllers.
o SDNインテリジェンス：ノードまたはノードのセットによってホストされる意思決定プロセスを指します。これらのノードはSDNコントローラーと呼ばれます。
The intelligence can be centralized or distributed. Both schemes are within the scope of this document.
インテリジェンスは一元化または分散できます。どちらのスキームもこのドキュメントの範囲内です。
An SDN Intelligence relies on inputs from various functional blocks, such as: network topology discovery, service topology discovery, resource allocation, business guidelines, customer profiles, service profiles, etc.
SDNインテリジェンスは、ネットワークトポロジ検出、サービストポロジ検出、リソース割り当て、ビジネスガイドライン、顧客プロファイル、サービスプロファイルなどのさまざまな機能ブロックからの入力に依存しています。
The exact decomposition of an SDN Intelligence, apart from the layering discussed here, is out of the scope of this document.
SDNインテリジェンスの正確な分解は、ここで説明されている階層化は別として、このドキュメントの範囲外です。
Additionally, the following acronyms are used in this document:
さらに、このドキュメントでは次の頭字語が使用されています。
CLAS: Cooperating Layered Architecture for SDN
CLAS：SDNの協調型レイヤードアーキテクチャ
FCAPS: Fault, Configuration, Accounting, Performance, and Security
FCAPS：障害、構成、アカウンティング、パフォーマンス、およびセキュリティ
SDN: Software-Defined Networking
SDN：ソフトウェア定義ネットワーキング
SLA: Service Level Agreement
SLA：サービスレベルアグリーメント
Current operator networks support multiple services (e.g., Voice over IP (VoIP), IPTV, mobile VoIP, critical mission applications, etc.) on a variety of transport technologies. The provision and delivery of a service independent of the underlying transport capabilities require a separation of the service-related functionalities and an abstraction of the transport network to hide the specifics of the underlying transfer techniques while offering a common set of capabilities.
現在の事業者ネットワークは、さまざまなトランスポートテクノロジーで複数のサービス（Voice over IP（VoIP）、IPTV、モバイルVoIP、重要なミッションアプリケーションなど）をサポートしています。基盤となるトランスポート機能とは独立したサービスの提供と配信には、サービス関連の機能の分離とトランスポートネットワークの抽象化が必要で、基盤となる転送技術の詳細を隠しながら、機能の共通セットを提供します。
Such separation can provide configuration flexibility and adaptability from the point of view of either the services or the transport network. Multiple services can be provided on top of a common transport infrastructure; similarly, different technologies can accommodate the connectivity requirements of a certain service. Close coordination among these elements is required for consistent service delivery (inter-layer cooperation).
このような分離により、サービスまたはトランスポートネットワークのいずれかの観点から、構成の柔軟性と適応性を提供できます。共通の輸送インフラの上に複数のサービスを提供できます。同様に、さまざまなテクノロジーが特定のサービスの接続要件に対応できます。これらの要素間の緊密な調整は、一貫したサービス提供（層間の協力）のために必要です。
This document focuses particularly on the means to:
このドキュメントでは、特に次の手段に焦点を当てています。
o expose transport capabilities to services.
o トランスポート機能をサービスに公開します。
o capture transport requirements of services.
o サービスのトランスポート要件をキャプチャします。
o notify service intelligence of underlying transport events, for example, to adjust a service decision-making process with underlying transport events.
o たとえば、基になるトランスポートイベントでサービスの意思決定プロセスを調整するために、基になるトランスポートイベントのサービスインテリジェンスに通知します。
o instruct the underlying transport capabilities to accommodate new requirements, etc.
o 新しい要件などに対応するために、基になる転送機能を指示します。
An example is guaranteeing some Quality-of-Service (QoS) levels. Different QoS-based offerings could be present at both the service and transport layers. Vertical mechanisms for linking both service and transport QoS mechanisms should be in place to provide quality guarantees to the end user.
例としては、一部のサービス品質（QoS）レベルの保証があります。サービス層とトランスポート層の両方に、さまざまなQoSベースの製品が存在する可能性があります。エンドユーザーに品質保証を提供するために、サービスとトランスポートの両方のQoSメカニズムをリンクする垂直メカニズムを導入する必要があります。
CLAS architecture assumes that the logically centralized control functions are separated into two functional layers. One of the functional layers comprises the service-related functions, whereas the other one contains the transport-related functions. The cooperation between the two layers is expected to be implemented through standard interfaces.
CLASアーキテクチャは、論理的に集中化された制御機能が2つの機能層に分離されていることを前提としています。機能層の1つはサービス関連機能を含み、もう1つはトランスポート関連機能を含みます。 2つのレイヤー間の連携は、標準インターフェースを介して実装されることが期待されています。
Figure 1 shows the CLAS architecture. It is based on functional separation in the Next Generation Network (NGN) architecture defined by the ITU-T in [Y.2011], where two strata of functionality are defined. These strata are the Service Stratum, comprising the service-related functions, and the Transport Stratum, covering the transport-related functions. The functions of each of these layers are further grouped into the control, management, and user (or data) planes.
図1にCLASアーキテクチャーを示します。これは、[Y.2011]でITU-Tによって定義された次世代ネットワーク（NGN）アーキテクチャの機能分離に基づいており、機能の2つの階層が定義されています。これらの階層は、サービス関連機能を含むサービス層と、トランスポート関連機能をカバーするトランスポート層です。これらの各層の機能は、制御、管理、およびユーザー（またはデータ）の各プレーンにさらにグループ化されます。
CLAS adopts the same structured model described in [Y.2011] but applies it to the objectives of programmability through SDN [RFC7149]. In this respect, CLAS advocates for addressing services and transport in a separated manner because of their differentiated concerns.
CLASは[Y.2011]で説明されているのと同じ構造化モデルを採用しますが、SDN [RFC7149]を介したプログラマビリティの目的にそれを適用します。この点で、CLASは、サービスとトランスポートに個別の方法で対処することを提唱しています。
Applications
/\
||
||
+-------------------------------------||-------------+
| Service Stratum || |
| \/ |
| ........................... |
| . SDN Intelligence . |
| . . |
| +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mgmt. Pl. | . |
| | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| /\ |
| || |
+-------------------------------------||-------------+
|| Standard
-- || -- API
||
+-------------------------------------||-------------+
| Transport Stratum || |
| \/ |
| ........................... |
| . SDN Intelligence . |
| . . |
| +--------------+ . +--------------+ . |
| | Resource Pl. | . | Mgmt. Pl. | . |
| | |<===>. +--------------+ | . |
| | | . | Control Pl. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| |
| |
+----------------------------------------------------+
Figure 1: Cooperating Layered Architecture for SDN
図1：SDNの協調型レイヤードアーキテクチャ
In the CLAS architecture, both the control and management functions are considered to be performed by one or a set of SDN controllers (due to, for example, scalability, reliability), providing the SDN Intelligence in such a way that separated SDN controllers are present in the Service and Transport Strata. Management functions are considered to be part of the SDN Intelligence to allow for effective operation in a service provider ecosystem [RFC7149], although some initial propositions did not consider such management as part of the SDN environment [ONFArch].
CLASアーキテクチャーでは、制御機能と管理機能の両方が1つまたは一連のSDNコントローラーによって実行されると見なされ（たとえば、スケーラビリティ、信頼性により）、SDNインテリジェンスを分離したSDNコントローラーが存在するように提供しますサービスと輸送層で。管理機能は、サービスプロバイダーエコシステム[RFC7149]での効果的な運用を可能にするSDNインテリジェンスの一部と見なされますが、最初の提案では、このような管理をSDN環境[ONFArch]の一部と見なしていませんでした。
Furthermore, the generic user- or data-plane functions included in the NGN architecture are referred to here as resource-plane functions. The resource plane in each stratum is controlled by the corresponding SDN Intelligence through a standard interface.
さらに、NGNアーキテクチャに含まれる一般的なユーザープレーンまたはデータプレーンの機能は、ここではリソースプレーン機能と呼ばれます。各ストラタムのリソースプレーンは、標準インターフェースを介して対応するSDNインテリジェンスによって制御されます。
The SDN controllers cooperate in the provision and delivery of services. There is a hierarchy in which the Service SDN Intelligence makes requests of the Transport SDN Intelligence for the provision of transport capabilities.
SDNコントローラーは、サービスの提供と配信に協力します。サービスSDNインテリジェンスがトランスポートSDNインテリジェンスにトランスポート機能のプロビジョニングを要求する階層があります。
The Service SDN Intelligence acts as a client of the Transport SDN Intelligence.
Service SDN Intelligenceは、Transport SDN Intelligenceのクライアントとして機能します。
Furthermore, the Transport SDN Intelligence interacts with the Service SDN Intelligence to inform it about events in the transport network that can motivate actions in the service layer.
さらに、トランスポートSDNインテリジェンスは、サービスSDNインテリジェンスと対話して、サービスレイヤーでのアクションの動機となるトランスポートネットワークのイベントについて通知します。
Despite not being shown in Figure 1, the resource planes of each stratum could be connected. This will depend on the kind of service provided. Furthermore, the Service Stratum could offer an interface to applications to expose network service capabilities to those applications or customers.
図1には示されていませんが、各層のリソースプレーンを接続できます。これは、提供されるサービスの種類によって異なります。さらに、サービス層は、アプリケーションへのインターフェイスを提供して、ネットワークサービス機能をそれらのアプリケーションまたは顧客に公開することができます。
As aforementioned, there is a functional split that separates transport-related functions from service-related functions. Both strata cooperate for consistent service delivery.
前述のように、トランスポート関連の機能とサービス関連の機能を分離する機能分割があります。両方の層は、一貫したサービス提供のために協力しています。
Consistency is determined and characterized by the service layer.
一貫性は、サービス層によって決定され、特徴付けられます。
The Transport Stratum comprises the functions focused on the transfer of data between the communication endpoints (e.g., between end-user devices, between two service gateways, etc.). The data-forwarding nodes are controlled and managed by the Transport SDN component.
トランスポート層は、通信エンドポイント間（たとえば、エンドユーザーデバイス間、2つのサービスゲートウェイ間など）でのデータ転送に重点を置いた機能で構成されています。データ転送ノードは、Transport SDNコンポーネントによって制御および管理されます。
The control plane in the SDN Intelligence is in charge of instructing the forwarding devices to build the end-to-end data path for each communication or to make sure the forwarding service is appropriately set up. Forwarding may not be rely solely on the preconfigured entries; means can be enabled so that involved nodes can dynamically build routing and forwarding paths (this would require that the nodes retain some of the control and management capabilities for enabling this). Finally, the management plane performs management functions (i.e., FCAPS) on those devices, like fault or performance management, as part of the Transport Stratum capabilities.
SDNインテリジェンスのコントロールプレーンは、各通信のエンドツーエンドのデータパスを構築するか、転送サービスが適切に設定されていることを確認するように転送デバイスに指示する役割を果たします。転送は、事前設定されたエントリのみに依存することはできません。関係するノードがルーティングおよび転送パスを動的に構築できるように手段を有効にすることができます（これには、ノードがこれを有効にするための制御および管理機能の一部を保持する必要があります）。最後に、管理プレーンは、Transport Stratum機能の一部として、障害管理やパフォーマンス管理などのデバイスで管理機能（FCAPSなど）を実行します。
The Service Stratum contains the functions related to the provision of services and the capabilities offered to external applications. The resource plane consists of the resources involved in the service delivery, such as computing resources, registries, databases, etc.
サービス層には、サービスの提供に関連する機能と、外部アプリケーションに提供される機能が含まれています。リソースプレーンは、コンピューティングリソース、レジストリ、データベースなど、サービスの提供に関連するリソースで構成されます。
The control plane is in charge of controlling and configuring those resources as well as interacting with the control plane of the Transport Stratum in client mode to request transport capabilities for a given service. In the same way, the management plane implements management actions on the service-related resources and interacts with the management plane in the Transport Stratum to ensure management cooperation between layers.
コントロールプレーンは、これらのリソースを制御および構成し、クライアントモードでトランスポート層のコントロールプレーンと対話して、特定のサービスのトランスポート機能を要求します。同様に、管理プレーンは、サービス関連リソースに管理アクションを実装し、トランスポート層の管理プレーンと対話して、レイヤー間の管理連携を確保します。
Recursive layering can happen in some usage scenarios in which the Transport Stratum is itself structured in the Service and Transport Strata. This could be the case in the provision of a transport service complemented with advanced capabilities in addition to the pure data transport (e.g., maintenance of a given SLA [RFC7297]).
再帰的な階層化は、Transport Stratum自体がService and Transport Strataで構造化されている一部の使用シナリオで発生する可能性があります。これは、純粋なデータトランスポート（たとえば、特定のSLA [RFC7297]のメンテナンス）に加えて高度な機能で補完されたトランスポートサービスのプロビジョニングの場合に当てはまる可能性があります。
Recursiveness has also been discussed in [ONFArch] as a way of reaching scalability and modularity, where each higher level can provide greater abstraction capabilities. Additionally, recursiveness can allow some multi-domain scenarios where single or multiple administrative domains are involved, such as those described in Section 6.3.
再帰性はスケーラビリティとモジュール性を実現する方法として[ONFArch]でも説明されており、レベルが高くなるほど抽象化機能が向上します。さらに、再帰性により、セクション6.3で説明されているような、1つまたは複数の管理ドメインが関係するいくつかのマルチドメインシナリオが可能になります。
The CLAS architecture leverages plane separation. As mentioned in Sections 3.1.1 and 3.1.2, three different planes are considered for each stratum. The communication among these three planes (with the corresponding plane in other strata) is based on open, standard interfaces.
CLASアーキテクチャは、プレーンの分離を活用しています。セクション3.1.1と3.1.2で述べたように、3つの異なるプレーンが各層で考慮されます。これら3つのプレーン間の通信（他の階層の対応するプレーンとの通信）は、オープンな標準インターフェースに基づいています。
The control plane logically centralizes the control functions of each stratum and directly controls the corresponding resources. [RFC7426] introduces the role of the control plane in an SDN architecture. This plane is part of an SDN Intelligence and can interact with other control planes in the same or different strata to perform control functions.
コントロールプレーンは、各階層の制御機能を論理的に集中化し、対応するリソースを直接制御します。 [RFC7426]は、SDNアーキテクチャにおけるコントロールプレーンの役割を紹介します。このプレーンはSDNインテリジェンスの一部であり、同じまたは異なる階層の他のコントロールプレーンと対話して、コントロール機能を実行できます。
The management plane logically centralizes the management functions for each stratum, including the management of the control and resource planes. [RFC7426] describes the functions of the management plane in an SDN environment. This plane is also part of the SDN Intelligence and can interact with the corresponding management planes residing in SDN controllers of the same or different strata.
管理プレーンは、コントロールプレーンとリソースプレーンの管理を含む、各層の管理機能を論理的に集中化します。 [RFC7426]は、SDN環境での管理プレーンの機能について説明しています。このプレーンもSDNインテリジェンスの一部であり、同じまたは異なる階層のSDNコントローラーにある対応する管理プレーンと対話できます。
The resource plane comprises the resources for either the transport or the service functions. In some cases, the service resources can be connected to the transport ones (e.g., being the terminating points of a transport function); in other cases, it can be decoupled from the transport resources (e.g., one database keeping a register for the end user). Both the forwarding and operational planes proposed in [RFC7426] would be part of the resource plane in this architecture.
リソースプレーンは、トランスポートまたはサービス機能のいずれかのリソースで構成されます。場合によっては、サービスリソースをトランスポートリソースに接続できます（トランスポート機能の終端など）。他の場合では、トランスポートリソースから切り離すことができます（たとえば、1つのデータベースがエンドユーザーのレジスタを保持する）。 [RFC7426]で提案されている転送プレーンと運用プレーンの両方が、このアーキテクチャのリソースプレーンの一部になります。
Since the CLAS architecture implies the interaction of different layers with different purposes and responsibilities, a number of features are required to be supported:
CLASアーキテクチャは、異なる目的と責任を持つ異なるレイヤーの相互作用を意味するため、サポートする必要のある機能がいくつかあります。
o Abstraction: the mapping of physical resources into the corresponding abstracted resources.
o 抽象化：物理リソースの対応する抽象化されたリソースへのマッピング。
o Service-Parameter Translation: the translation of service parameters (e.g., in the form of SLAs) to transport parameters (or capabilities) according to different policies.
o サービスパラメータ変換：サービスパラメータ（SLAなどの形式）をさまざまなポリシーに従ってトランスポートパラメータ（または機能）に変換します。
o Monitoring: mechanisms (e.g., event notifications) available in order to dynamically update the (abstracted) resources' status while taking into account, for example, the traffic load.
o 監視：トラフィック負荷などを考慮しながら、（抽象化された）リソースのステータスを動的に更新するために使用可能なメカニズム（イベント通知など）。
o Resource Computation: functions able to decide which resources will be used for a given service request. As an example, functions like PCE could be used to compute/select/decide a certain path.
o リソースの計算：特定のサービス要求に使用するリソースを決定できる関数。例として、PCEのような関数を使用して、特定のパスを計算/選択/決定できます。
o Orchestration: the ability to combine diverse resources (e.g., IT and network resources) in an optimal way.
o オーケストレーション：さまざまなリソース（ITリソースやネットワークリソースなど）を最適な方法で組み合わせる機能。
o Accounting: record of resource usage.
o アカウンティング：リソースの使用状況の記録。
o Security: secure communication among components, preventing, for example, DoS attacks.
o セキュリティ：コンポーネント間の安全な通信。DoS攻撃などを防ぎます。
The SDN controllers residing respectively in the Service and Transport Strata need to establish tight coordination. Mechanisms for transferring relevant information for each stratum should be defined.
ServiceおよびTransport Strataにそれぞれ存在するSDNコントローラーは、緊密な調整を確立する必要があります。各階層の関連情報を転送するメカニズムを定義する必要があります。
From the service perspective, the Service SDN Intelligence needs to easily access transport resources through well-defined APIs to retrieve the capabilities offered by the Transport Stratum. There could be different ways of obtaining such transport-aware information, i.e., by discovering or publishing mechanisms. In the former case, the Service SDN Intelligence could be able to handle complete information about the transport capabilities (including resources) offered by the Transport Stratum. In the latter case, the Transport Stratum reveals the available capabilities, for example, through a catalog, reducing the amount of detail of the underlying network.
サービスの観点から見ると、Service SDN Intelligenceは、明確に定義されたAPIを介してトランスポートリソースに簡単にアクセスし、Transport Stratumが提供する機能を取得する必要があります。このようなトランスポート対応情報を取得するには、メカニズムを発見または公開するなど、さまざまな方法があります。前者の場合、Service SDN Intelligenceは、Transport Stratumが提供するトランスポート機能（リソースを含む）に関する完全な情報を処理できる可能性があります。後者の場合、Transport Stratumは、たとえばカタログを通じて利用可能な機能を明らかにし、基礎となるネットワークの詳細の量を減らします。
On the other hand, the Transport Stratum must properly capture the Service requirements. These can include SLA requirements with specific metrics (such as delay), the level of protection to be provided, maximum/minimum capacity, applicable resource constraints, etc.
一方、トランスポート層は、サービス要件を適切にキャプチャする必要があります。これらには、特定のメトリック（遅延など）を備えたSLA要件、提供される保護のレベル、最大/最小容量、適用可能なリソース制約などが含まれます。
The communication between controllers must also be secure, e.g., by preventing denial of service or any other kind of threat (similarly, communications with the network nodes must be secure).
コントローラ間の通信も安全でなければなりません。たとえば、サービス拒否やその他の種類の脅威を防止します（同様に、ネットワークノードとの通信も安全でなければなりません）。
Different situations can be found depending on the characteristics of the networks involved in a given deployment.
特定の展開に含まれるネットワークの特性に応じて、さまざまな状況が見られます。
This case considers that the networks involved in the provision and delivery of a given service have SDN capabilities.
このケースでは、特定のサービスの提供と配信に関与するネットワークにSDN機能があると見なします。
6.1.1. Multiple Service Strata Associated with a Single Transport Stratum
6.1.1. 単一のトランスポート層に関連付けられた複数のサービス層
A single Transport Stratum can provide transfer functions to more than one Service Stratum. The Transport Stratum offers a standard interface(s) to each of the Service Strata. The Service Strata are the clients of the Transport Stratum. Some of the capabilities offered by the Transport Stratum can be isolation of the transport resources (slicing), independent routing, etc.
1つのTransport Stratumは、複数のService Stratumに転送機能を提供できます。 Transport Stratumは、各Service Strataへの標準インターフェースを提供します。 Service StrataはTransport Stratumのクライアントです。 Transport Stratumが提供する機能には、トランスポートリソースの分離（スライス）、独立したルーティングなどがあります。
A single Service Stratum can make use of different Transport Strata for the provision of a certain service. The Service Stratum invokes standard interfaces to each of the Transport Strata, and orchestrates the provided transfer capabilities for building the end-to-end transport needs.
単一のサービス層は、特定のサービスの提供のために異なるトランスポート層を利用できます。 Service Stratumは、各Transport Strataへの標準インターフェースを呼び出し、エンドツーエンドのトランスポートニーズを構築するために提供されている転送機能を調整します。
This case considers scenarios where one of the strata is totally or partly legacy.
このケースでは、層の1つが完全にまたは部分的にレガシーであるシナリオを検討します。
An SDN service Stratum can interact with a legacy Transport Stratum through an interworking function that is able to adapt SDN-based control and management service-related commands to legacy transport-related protocols, as expected by the legacy Transport Stratum.
SDNサービスStratumは、SDNベースの制御および管理サービス関連コマンドをレガシートランスポート関連プロトコルに適合させることができるインターワーキング機能を通じて、レガシートランスポートストラタムと対話できます。
The SDN Intelligence in the Service Stratum is not aware of the legacy nature of the underlying Transport Stratum.
Service StratumのSDNインテリジェンスは、基になるTransport Stratumのレガシーな性質を認識していません。
A legacy Service Stratum can work with an SDN-enabled Transport Stratum through the mediation of an interworking function capable of interpreting commands from the legacy service functions and translating them into SDN protocols for operation with the SDN-enabled Transport Stratum.
レガシーサービス層は、レガシーサービス機能からのコマンドを解釈し、SDNプロトコルに変換してSDN対応トランスポート層で動作するインターワーキング機能を仲介することにより、SDN対応トランスポート層と連携できます。
The Transport Stratum can be composed of transport resources that are part of different administrative, topological, or technological domains. The Service Stratum can interact with a single entity in the Transport Stratum in case some abstraction capabilities are provided in the transport part to emulate a single stratum.
トランスポート層は、さまざまな管理、トポロジー、または技術ドメインの一部であるトランスポートリソースで構成できます。単一のストラタムをエミュレートするためにトランスポートパーツにいくつかの抽象化機能が提供されている場合、サービスストラタムはトランスポートストラタムの単一のエンティティと対話できます。
Those abstraction capabilities constitute a service itself offered by the Transport Stratum to the services making use of this stratum. This service is focused on the provision of transport capabilities, which is different from the final communication service using such capabilities.
これらの抽象化機能は、トランスポート層がこの層を利用するサービスに提供するサービス自体を構成します。このサービスは、トランスポート機能の提供に重点を置いています。これは、そのような機能を使用する最終的な通信サービスとは異なります。
In this particular case, this recursion allows multi-domain scenarios at the transport level.
この特定のケースでは、この再帰により、トランスポートレベルでのマルチドメインシナリオが可能になります。
Multi-domain situations can happen in both single-operator and multi-operator scenarios.
マルチドメインの状況は、単一オペレーターと複数オペレーターの両方のシナリオで発生する可能性があります。
In single-operator scenarios, a multi-domain or end-to-end abstraction component can provide a homogeneous abstract view of the underlying heterogeneous transport capabilities for all the domains.
単一オペレーターのシナリオでは、マルチドメインまたはエンドツーエンドの抽象化コンポーネントにより、すべてのドメインの基礎となる異種トランスポート機能の同種の抽象ビューを提供できます。
Multi-operator scenarios at the Transport Stratum should support the establishment of end-to-end paths in a programmatic manner across the involved networks. For example, this could be accomplished by each of the administrative domains exchanging their traffic-engineered information [RFC7926].
Transport Stratumでのマルチオペレーターシナリオは、関係するネットワーク全体でプログラムによるエンドツーエンドパスの確立をサポートする必要があります。たとえば、これは、トラフィックエンジニアリング情報[RFC7926]を交換する各管理ドメインによって達成できます。
This section presents a number of use cases as examples of the applicability of the CLAS approach.
このセクションでは、CLASアプローチの適用可能性の例として、いくつかの使用例を示します。
NFV environments offer two possible levels of SDN control [GSNFV-EVE005]. One level is the need to control the NFV Infrastructure (NFVI) to provide end-to-end connectivity among VNFs (Virtual Network Functions) or among VNFs and PNFs (Physical Network Functions). A second level is the control and configuration of the VNFs themselves (in other words, the configuration of the network service implemented by those VNFs), which benefits from the programmability brought by SDN. The two control concerns are separate in nature. However, interaction between the two can be expected in order to optimize, scale, or influence one another.
NFV環境は、2つのレベルのSDN制御を提供します[GSNFV-EVE005]。 1つのレベルは、NFVインフラストラクチャ（NFVI）を制御して、VNF（仮想ネットワーク機能）間またはVNFとPNF（物理ネットワーク機能）間のエンドツーエンド接続を提供する必要性です。 2番目のレベルは、VNF自体の制御と構成（つまり、それらのVNFによって実装されるネットワークサービスの構成）であり、SDNによってもたらされるプログラマビリティからメリットを得ます。 2つの管理上の懸念は本質的に別々です。ただし、最適化、スケーリング、または相互に影響を与えるために、2つの間の相互作用が期待できます。
Abstraction and Control of TE Networks (ACTN) [RFC8453] presents a framework that allows the creation of virtual networks to be offered to customers. The concept of "provider" in ACTN is limited to the offering of virtual network services. These services are essentially transport services and would correspond to the Transport Stratum in CLAS. On the other hand, the Service Stratum in CLAS can be assimilated as a customer in the context of ACTN.
TEネットワークの抽象化と制御（ACTN）[RFC8453]は、仮想ネットワークの作成を顧客に提供できるようにするフレームワークを提示します。 ACTNの「プロバイダー」の概念は、仮想ネットワークサービスの提供に限定されています。これらのサービスは本質的に輸送サービスであり、CLASの輸送層に対応します。一方、CLASのサービス層は、ACTNのコンテキストで顧客として同化できます。
ACTN defines a hierarchy of controllers to facilitate the creation and operation of the virtual networks. An interface is defined for the relationship between the customers requesting these virtual network services and the controller in charge of orchestrating and serving such a request. Such an interface is equivalent to the one defined in Figure 1 (Section 3) between the Service and Transport Strata.
ACTNは、仮想ネットワークの作成と操作を容易にするためにコントローラーの階層を定義します。これらの仮想ネットワークサービスを要求する顧客と、そのような要求の調整と提供を担当するコントローラーとの間の関係に対して、インターフェイスが定義されています。このようなインターフェースは、図1（セクション3）で定義されているサービスとトランスポート層の間のインターフェースと同等です。
8. Challenges for Implementing Actions between Service and Transport Strata
8. サービスとトランスポート層の間のアクションを実装するための課題
The distinction of service and transport concerns raises a number of challenges in the communication between the two strata. The following list reflects some of the identified challenges:
サービスと輸送に関する懸念の区別は、2つの階層間の通信において多くの課題を引き起こします。次のリストは、特定された課題の一部を反映しています。
o Standard mechanisms for interaction between layers: Nowadays, there are a number of proposals that could accommodate requests from the Service Stratum to the Transport Stratum.
o レイヤー間の相互作用の標準メカニズム：現在、サービス層からトランスポート層への要求に対応できる多くの提案があります。
Some of the proposals could be solutions like the Connectivity Provisioning Negotiation Protocol [CPNP] or the Intermediate-Controller Plane Interface (I-CPI) [ONFArch].
一部の提案は、接続性プロビジョニングネゴシエーションプロトコル[CPNP]または中間コントローラプレーンインターフェース（I-CPI）[ONFArch]などのソリューションである可能性があります。
Other potential candidates could be the Transport API [TAPI] or the Transport Northbound Interface [TRANS-NORTH]. Each of these options has a different scope.
他の潜在的な候補は、トランスポートAPI [TAPI]またはトランスポートノースバウンドインターフェイス[TRANS-NORTH]である可能性があります。これらのオプションにはそれぞれ異なるスコープがあります。
o Multi-provider awareness: In multi-domain scenarios involving more than one provider at the transport level, the Service Stratum may or may not be aware of such multiplicity of domains.
o マルチプロバイダーの認識：トランスポートレベルで複数のプロバイダーが関与するマルチドメインシナリオでは、Service Stratumはそのようなドメインの多様性を認識している場合と認識していない場合があります。
If the Service Stratum is unaware of the multi-domain situation, then the Transport Stratum acting as the entry point of the Service Stratum request should be responsible for managing the multi-domain issue.
Service Stratumがマルチドメインの状況を認識していない場合、Service Stratumリクエストのエントリポイントとして機能するTransport Stratumがマルチドメインの問題を管理する必要があります。
On the contrary, if the Service Stratum is aware of the multi-domain situation, it should be in charge of orchestrating the requests to the different underlying Transport Strata to compose the final end-to-end path among service endpoints (i.e., service functions).
逆に、Service Stratumがマルチドメインの状況を認識している場合は、サービスエンドポイント間の最終的なエンドツーエンドパス（つまり、サービス機能）を構成するために、異なる基になるTransport Strataへのリクエストを調整する責任があります。 ）。
o SLA mapping: Both strata will handle SLAs, but the nature of those SLAs could differ. Therefore, it is required for the entities in each stratum to map service SLAs to connectivity SLAs in order to ensure proper service delivery.
o SLAマッピング：両方の層がSLAを処理しますが、それらのSLAの性質は異なる場合があります。したがって、適切なサービスを確実に配信するには、各ストラタムのエンティティがサービスSLAを接続SLAにマップする必要があります。
o Association between strata: The association between strata could be configured beforehand, or both strata could require the use of a discovery mechanism that dynamically establishes the association between the strata.
o 層間の関連付け：層間の関連付けは事前に構成できます。または、両方の層に、層間の関連付けを動的に確立する検出メカニズムの使用が必要になる場合があります。
o Security: As reflected before, the communication between strata must be secure to prevent attacks and threats. Additionally, privacy should be enforced, especially when addressing multi-provider scenarios at the transport level.
o セキュリティ：以前に反映したように、攻撃と脅威を防ぐために、階層間の通信は安全でなければなりません。さらに、特にトランスポートレベルでマルチプロバイダーシナリオに対処する場合は、プライバシーを強化する必要があります。
o Accounting: The control and accountancy of resources used and consumed by services should be supported in the communication among strata.
o 会計：サービスによって使用および消費されるリソースの制御と会計は、階層間の通信でサポートされる必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The CLAS architecture relies upon the functional entities that are introduced in [RFC7149] and [RFC7426]. As such, security considerations discussed in Section 5 of [RFC7149], in particular, must be taken into account.
CLASアーキテクチャは、[RFC7149]と[RFC7426]で導入された機能エンティティに依存しています。そのため、特に[RFC7149]のセクション5で説明されているセキュリティの考慮事項を考慮する必要があります。
The communication between the service and transport SDN controllers must rely on secure means that achieve the following:
サービスとトランスポートSDNコントローラー間の通信は、以下を実現する安全な手段に依存する必要があります。
o Mutual authentication must be enabled before taking any action.
o アクションを実行する前に、相互認証を有効にする必要があります。
o Message integrity protection.
o メッセージ整合性保護。
Each of the controllers must be provided with instructions regarding the set of information (and granularity) that can be disclosed to a peer controller. Means to prevent the leaking of privacy data (e.g., from the Service Stratum to the Transport Stratum) must be enabled. The exact set of information to be shared is deployment specific.
各コントローラーには、ピアコントローラーに開示できる一連の情報（および粒度）に関する指示を提供する必要があります。プライバシーデータの漏洩を防止する手段（サービス層からトランスポート層へなど）を有効にする必要があります。共有される正確な情報のセットは、デプロイメント固有です。
A corrupted controller may induce some disruption on another controller. Protection against such attacks should be enabled.
破損したコントローラーは、別のコントローラーに何らかの障害を引き起こす可能性があります。このような攻撃に対する保護を有効にする必要があります。
Security in the communication between the strata described here should apply to the APIs (and/or protocols) to be defined among them. Consequently, security concerns will correspond to the specific solution.
ここで説明する層間の通信のセキュリティは、それらの間で定義されるAPI（またはプロトコル）に適用される必要があります。したがって、セキュリティ上の懸念は特定のソリューションに対応します。
[Y.2011] International Telecommunication Union, "General principles and general reference model for Next Generation Networks", ITU-T Recommendation Y.2011, October 2004, <https://www.itu.int/rec/T-REC-Y.2011-200410-I/en>.
[Y.2011]国際電気通信連合、「次世代ネットワークの一般原則および一般参照モデル」、ITU-T勧告Y.2011、2004年10月、<https://www.itu.int/rec/T-REC- Y.2011-200410-I / en>。
[CPNP] Boucadair, M., Jacquenet, C., Zhang, D., and P. Georgatsos, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, draft-boucadair-connectivity-provisioning-protocol-15, December 2017.
[CPNP] Boucadair、M.、Jacquenet、C.、Zhang、D。、およびP. Georgatsos、「Connectivity Provisioning Negotiation Protocol（CPNP）」、Work in Progress、draft-boucadair-connectivity-provisioning-protocol-15、12月2017。
[GSNFV-EVE005] ETSI, "Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural Framework", ETSI GS NFV-EVE 005, V1.1.1, December 2015, <https://www.etsi.org/deliver/etsi_gs/ NFV-EVE/001_099/005/01.01.01_60/ gs_nfv-eve005v010101p.pdf>.
[GSNFV-EVE005] ETSI、「Network Functions Virtualization（NFV）; Ecosystem; Report in SDN Usage in NFV Architectural Framework」、ETSI GS NFV-EVE 005、V1.1.1、2015年12月、<https：//www.etsi。 org / deliver / etsi_gs / NFV-EVE / 001_099 / 005 / 01.01.01_60 / gs_nfv-eve005v010101p.pdf>。
[ONFArch] Open Networking Foundation, "SDN Architecture, Issue 1", June 2014, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/technical-reports/ TR_SDN_ARCH_1.0_06062014.pdf>.
[ONFArch] Open Networking Foundation、「SDN Architecture、Issue 1」、2014年6月、<https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M。およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの展望」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：//www.rfc-editor。 org / info / rfc7149>。
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.
[RFC7297] Boucadair、M.、Jacquenet、C。、およびN. Wang、「IP接続プロビジョニングプロファイル（CPP）」、RFC 7297、DOI 10.17487 / RFC7297、2014年7月、<https：//www.rfc-editor。 org / info / rfc7297>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D.、O。Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[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>.
[RFC7926] Farrel、A.、Ed。、Drake、J.、Bitar、N.、Swallow、G.、Ceccarelli、D。、およびX. Zhang、「相互接続されたトラフィックエンジニアリングネットワーク間の情報交換のための問題ステートメントとアーキテクチャ"、BCP 206、RFC 7926、DOI 10.17487 / RFC7926、2016年7月、<https://www.rfc-editor.org/info/rfc7926>。
[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>.
[RFC8453] Ceccarelli、D.、Ed。 Y.リー、編、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453> 。
[SDN-ARCH] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., and P. Iovanna, "Cooperating Layered Architecture for SDN", Work in Progress, draft-irtf-sdnrg-layered-sdn-01, October 2016.
[SDN-ARCH] Contreras、LM。、Bernardos、CJ。、Lopez、D.、Boucadair、M。、およびP. Iovanna、「SDNのための協力型レイヤードアーキテクチャ」、作業中、draft-irtf-sdnrg-layered- sdn-01、2016年10月。
[TAPI] Open Networking Foundation, "Functional Requirements for Transport API", June 2016, <https://www.opennetworking.org/wp-content/uploads/ 2014/10/TR-527_TAPI_Functional_Requirements.pdf>.
[TAPI] Open Networking Foundation、「Functional Requirements for Transport API」、2016年6月、<https://www.opennetworking.org/wp-content/uploads/ 2014/10 / TR-527_TAPI_Functional_Requirements.pdf>。
[TRANS-NORTH] Busi, I., King, D., Zheng, H., and Y. Xu, "Transport Northbound Interface Applicability Statement", Work in Progress, draft-ietf-ccamp-transport-nbi-app-statement-05, March 2019.
[TRANS-NORTH] Busi、I.、King、D.、Zheng、H.、Y。Xu、「Transport Northbound Interface Applicability Statement」、Work in Progress、draft-ietf-ccamp-transport-nbi-app-statement -05、2019年3月。
[RFC7426] introduces an SDN taxonomy by defining a number of planes, abstraction layers, and interfaces or APIs among them as a means of clarifying how the different parts constituent of SDN (network devices, control and management) relate. A number of planes are defined, including:
[RFC7426]は、SDNのさまざまな構成要素（ネットワークデバイス、制御、管理）がどのように関連しているかを明確にする手段として、プレーン、抽象化レイヤー、およびそれらの間のインターフェースまたはAPIを定義することにより、SDNタクソノミーを導入します。以下を含む多数の平面が定義されています。
o Forwarding Plane: focused on delivering packets in the data path based on the instructions received from the control plane.
o フォワーディングプレーン：コントロールプレーンから受信した指示に基づいて、データパスでパケットを配信することに重点を置いています。
o Operational Plane: centered on managing the operational state of the network device.
o 運用面：ネットワークデバイスの運用状態の管理を中心に。
o Control Plane: dedicated to instructing the device on how packets should be forwarded.
o コントロールプレーン：パケットの転送方法をデバイスに指示することを目的としています。
o Management Plane: in charge of monitoring and maintaining network devices.
o 管理プレーン：ネットワークデバイスの監視と保守を担当します。
o Application Plane: enabling the usage for different purposes (as determined by each application) of all the devices controlled in this manner.
o アプリケーションプレーン：この方法で制御されるすべてのデバイスのさまざまな目的（各アプリケーションによって決定される）の使用を可能にします。
Apart from these, [RFC7426] proposes a number of abstraction layers that permit the integration of the different planes through common interfaces. CLAS focuses on control, management, and resource planes as the basic pieces of its architecture. Essentially, the control plane modifies the behavior and actions of the controlled resources. The management plane monitors and retrieves the status of those resources. And finally, the resource plane groups all the resources related to the concerns of each stratum.
これらとは別に、[RFC7426]は、共通のインターフェースを介して異なるプレーンの統合を可能にするいくつかの抽象化レイヤーを提案しています。 CLASは、そのアーキテクチャの基本部分として、制御、管理、およびリソースプレーンに焦点を当てています。基本的に、コントロールプレーンは、制御されるリソースの動作とアクションを変更します。管理プレーンは、これらのリソースのステータスを監視して取得します。そして最後に、リソースプレーンは、各層の懸念に関連するすべてのリソースをグループ化します。
From this point of view, CLAS planes can be seen as a superset of those defined in [RFC7426]. However, in some cases, not all the planes considered in [RFC7426] may be totally present in CLAS representation (e.g., the forwarding plane in the Service Stratum).
この観点から、CLAS平面は[RFC7426]で定義された平面のスーパーセットと見なすことができます。ただし、場合によっては、[RFC7426]で検討されているすべてのプレーンがCLAS表現で完全に存在するとは限りません（たとえば、サービス層の転送プレーン）。
That being said, the internal structure of CLAS strata could follow the taxonomy defined in [RFC7426]. What is different is the specialization of the SDN environments through the distinction between service and transport.
とはいえ、CLAS層の内部構造は、[RFC7426]で定義されている分類法に従うことができます。違いは、サービスとトランスポートの区別によるSDN環境の特殊化です。
Acknowledgements
謝辞
This document was previously discussed and adopted in the IRTF SDN RG as [SDN-ARCH]. After the closure of the IRTF SDN RG, this document was progressed as an Independent Submission to record (some of) that group's discussions.
この文書は以前に議論され、IRTF SDN RGで[SDN-ARCH]として採用されました。 IRTF SDN RGの閉鎖後、このドキュメントは、そのグループの議論（の一部）を記録するための独立した提出物として作成されました。
The authors would like to thank (in alphabetical order) Bartosz Belter, Gino Carrozzo, Ramon Casellas, Gert Grammel, Ali Haider, Evangelos Haleplidis, Zheng Haomian, Giorgios Karagianis, Gabriel Lopez, Maria Rita Palatella, Christian Esteve Rothenberg, and Jacek Wytrebowicz for their comments and suggestions.
著者は（アルファベット順で）Bartosz Belter、Gino Carrozzo、Ramon Casellas、Gert Grammel、Ali Haider、Evangelos Haleplidis、Zheng Haomian、Giorgios Karagianis、Gabriel Lopez、Maria Rita Palatella、Christian Esteve Rothenberg、Jacek Wytrebowicに感謝します彼らのコメントと提案。
Thanks to Adrian Farrel for the review.
レビューを提供してくれたAdrian Farrelに感謝します。
Authors' Addresses
著者のアドレス
Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain
Luis M. Contreras Telefonica Ronda de la Comunicacion、s / n Sur-3建物、3階マドリード28050スペイン
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
カルロスJ.ベルナルドスカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Diego R. Lopez Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 3rd floor Madrid 28050 Spain
Diego R. Lopez Telefonica Ronda de la Comunicacion、s / n Sur-3ビルディング、3階マドリード28050スペイン
Email: diego.r.lopez@telefonica.com Mohamed Boucadair Orange Rennes 35000 France
メール：diego.r.lopez@telefonica.com Mohamed Boucadair Orange Rennes 35000 France
Email: mohamed.boucadair@orange.com
Paola Iovanna Ericsson Pisa Italy
パオライオバンナエリクソンピサイタリア
Email: paola.iovanna@ericsson.com