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
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)
软件定义网络（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.
软件定义网络（SDN）主张在网络节点中将控制平面与数据平面分离，并将其逻辑集中在一个或一组控制实体上。大多数网络和/或服务智能都转移到这些控制实体。通常，这种实体被视为以垂直、紧密集成的方式交互控制功能的概要。将控制功能从多个分布式网络节点重新定位到逻辑中心实体在概念上将多个具有不同用途的控制功能放在一起。因此，现有的解决方案没有明确区分运输控制和依赖运输能力的服务。
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）的协作分层体系结构（Cooperative Layered Architecture for Software Defined Networking，CLAS）的方法，其中，与传输相关的控制功能与与与服务相关的控制功能是不同的，它们可以独立提供和维护，并且可以遵循自己的演进路径。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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
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控制器）上的控制逻辑集中化；可以部署一个或多个控制器。然后在转发实体（在网络节点处）和控制实体之间定义编程接口。通过该接口，控制实体指示转发平面中涉及的节点，并相应地修改其流量转发行为。通过这种编程接口[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]中，这被称为“地层”，这两个术语可以互换使用。
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
软件定义的网络
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.
当前的运营商网络支持多种传输技术上的多种服务（例如，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体系结构假定逻辑集中控制功能分为两个功能层。其中一个功能层包含与服务相关的功能，而另一个功能层包含与传输相关的功能。两层之间的协作预计将通过标准接口实现。
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体系结构。它基于ITU-T在[Y.2011]中定义的下一代网络（NGN）架构中的功能分离，其中定义了两个功能层。这些层是服务层，包括与服务相关的功能；运输层，包括与运输相关的功能。这些层中的每一层的功能都进一步分组到控制、管理和用户（或数据）平面中。
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. | | . |
| +--------------+ . | |-----+ . |
| . | | . |
| . +--------------+ . |
| ........................... |
| |
| |
+----------------------------------------------------+
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体系结构中，控制和管理功能都被视为由一个或一组SDN控制器执行（例如，由于可伸缩性、可靠性），以服务和传输层中存在分离的SDN控制器的方式提供SDN智能。管理功能被认为是SDN智能的一部分，以允许在服务提供商生态系统中有效运行[RCF7149]，虽然一些初始命题没有考虑这样的管理作为SDN环境的一部分[OnFrCH]。
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 Intelligence向运输SDN Intelligence发出提供运输能力的请求。
The Service SDN Intelligence acts as a client of the Transport SDN Intelligence.
服务SDN Intelligence充当传输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.
传输层包括专注于通信端点之间（例如，终端用户设备之间、两个服务网关之间等）的数据传输的功能。数据转发节点由传输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智能中的控制平面负责指示转发设备为每次通信建立端到端数据路径，或确保正确设置转发服务。转发不能仅依赖预先配置的条目；可以启用方法，以便相关节点可以动态构建路由和转发路径（这需要节点保留一些用于启用此功能的控制和管理功能）。最后，作为传输层能力的一部分，管理平面在这些设备上执行管理功能（即FCAP），如故障或性能管理。
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]).
递归分层可以发生在某些使用场景中，其中传输层本身是在服务和传输层中构造的。除了纯数据传输（例如，维护给定的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节所述。
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节所述，每个地层考虑三个不同的平面。这三个平面（与其他地层中的相应平面）之间的通信基于开放的标准接口。
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.
资源平面包括用于传输或服务功能的资源。在某些情况下，服务资源可以连接到传输资源（例如，作为传输功能的终止点）；在其他情况下，它可以与传输资源分离（例如，一个数据库为最终用户保留一个寄存器）。[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.
分别位于服务层和传输层的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.
从服务的角度来看，服务SDN智能需要通过定义良好的API轻松访问传输资源，以检索传输层提供的功能。获取此类传输感知信息可能有不同的方式，即通过发现或发布机制。在前一种情况下，服务SDN智能可以处理有关传输层提供的传输能力（包括资源）的完整信息。在后一种情况下，传输层显示可用的功能，例如，通过目录，减少底层网络的详细信息量。
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.
单个运输层可以向多个服务层提供传递函数。传输层为每个服务层提供标准接口。服务层是运输层的客户。传输层提供的一些功能可以是传输资源的隔离（切片）、独立路由等。
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.
一个单一的服务层可以利用不同的运输层来提供某种服务。服务层调用每个传输层的标准接口，并协调提供的传输功能，以构建端到端传输需求。
This case considers scenarios where one of the strata is totally or partly legacy.
本案例考虑了其中一个地层全部或部分为遗留地层的情况。
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服务层可以通过互通功能与传统传输层交互，该互通功能能够使基于SDN的控制和管理服务相关命令适应传统传输相关协议，正如传统传输层所期望的那样。
The SDN Intelligence in the Service Stratum is not aware of the legacy nature of the underlying Transport Stratum.
服务层中的SDN智能不知道底层传输层的遗留性质。
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].
传输层的多运营商场景应支持以编程方式跨相关网络建立端到端路径。例如，这可以通过每个管理域交换其流量工程信息来实现[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环境提供两种可能的SDN控制级别[GSNFV-EVE005]。一个层次是需要控制NFV基础设施（NFVI），以提供VNF（虚拟网络功能）之间或VNF和PNF（物理网络功能）之间的端到端连接。第二个层次是VNF本身的控制和配置（换句话说，这些VNF实现的网络服务的配置），这得益于SDN带来的可编程性。这两个控制问题本质上是分开的。然而，为了优化、扩大或影响彼此，可以预期两者之间的相互作用。
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:
服务和运输问题的区别给这两个阶层之间的沟通带来了许多挑战。以下列表反映了一些已确定的挑战：
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 多提供商感知：在多域场景中，在传输级别涉及多个提供商，服务层可能知道也可能不知道域的这种多样性。
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.
如果服务层不知道多域情况，那么作为服务层请求入口点的传输层应该负责管理多域问题。
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).
相反，如果服务层知道多域情况，它应该负责协调对不同底层传输层的请求，以组成服务端点（即服务功能）之间的最终端到端路径。
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，“连接供应协商协议（CPNP）”，正在进行的工作，草稿-Boucadair-Connectivity-Provisioning-Protocol-15，2017年12月。
[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，“网络功能虚拟化（NFV）；生态系统；关于NFV架构框架中SDN使用情况的报告”，ETSI GS NFV-EVE 005，V1.1.12015年12月<https://www.etsi.org/deliver/etsi_gs/ NFV-EVE/001_099/005/01.01.01_60/gs_NFV-EVE005V00101P.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>.
开放网络基础，“SDN架构，发布1”，2014年6月，<https://www.opennetworking.org/images/stories/ 下载/sdn资源/技术报告/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]Haleplis，E.，Ed.，Pentikousis，K.，Ed.，Denazis，S.，Hadi Salim，J.，Meyer，D.，和O.Koufopavlou，“软件定义网络（SDN）：层和架构术语”，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.Lee，Ed.，“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的合作分层体系结构”，正在进行的工作，草稿-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 ]开放网络基础，“交通API的功能要求”，2016年6月，<https://www.opennetworking.org/wp-content/uploads/ 2014/10/TR-527_TAPI_功能要求。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，“交通北行接口适用性声明”，正在进行的工作，草案-ietf-ccamp-Transport-nbi-app-Statement-052019年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]通过定义多个平面、抽象层以及它们之间的接口或API来介绍SDN分类法，以澄清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.
本文件先前作为[SDN-ARCH]在IRTF SDN RG中讨论和采用。在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.
作者要感谢（按字母顺序排列）巴托斯·贝尔特、吉诺·卡罗佐、拉蒙·卡塞拉斯、格特·格拉梅尔、阿里·海德尔、埃文盖洛斯·哈利普利迪斯、郑浩勉、乔治·卡拉贾尼斯、加布里埃尔·洛佩兹、玛丽亚·丽塔·巴拉泰拉、克里斯蒂安·埃斯特夫·罗滕伯格和雅切克·怀特博维茨的评论和建议。
Thanks to Adrian Farrel for the review.
感谢阿德里安·法雷尔的评论。
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 Comunicion，s/n Sur-3大楼三楼西班牙马德里28050
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://lmcontreras.com
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·贝尔纳多斯大学卡洛斯三世马德里大道。西班牙马德里勒冈30号大学28911
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
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
西班牙马德里南3号楼三楼迭戈R.洛佩斯电信隆达通讯社28050
Email: diego.r.lopez@telefonica.com
Email: diego.r.lopez@telefonica.com
Mohamed Boucadair Orange Rennes 35000 France
穆罕默德·布卡代尔·奥兰治·雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com
Paola Iovanna Ericsson Pisa Italy
爱立信意大利比萨酒店
Email: paola.iovanna@ericsson.com
Email: paola.iovanna@ericsson.com