RFC8597：Cooperating Layered Architecture for Software-Defined Networking (CLAS)，May 2019
梗概
软件定义网络 (Software-Defined Networking，SDN) 提倡将网络节点中的控制平面与数据平面分离，并将其逻辑集中在一个或一组控制实体上。大多数网络和/或服务智能被转移到这些控制实体。通常，这样的实体被视为以垂直、紧密集成的方式交互控制功能的概要。将控制功能从多个分布式网络节点重新定位到逻辑中央实体，在概念上将具有不同目的的多个控制功能放在一起。因此，现有的解决方案没有明确区分传输控制和依赖传输能力的服务。
本文档描述了一种称为软件定义网络协作分层架构 (Cooperating Layered Architecture for Software-Defined Networking，CLAS) 的方法，其中与传输相关的控制功能与与服务相关的控制功能以这样一种方式区分，即它们可以独立提供和维护，并且可以遵循自己的演进路径。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
这是对 RFC 系列的贡献，独立于任何其他 RFC 流。RFC 编辑已选择自行决定发布此文档，并且不对其实施或部署的价值作出任何声明。由 RFC 编辑批准发布的文件不适合任何级别的 Internet 标准；请参阅 RFC 7841 的第 2 节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8597。
版权声明
版权所有 (c) 2019 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
1、 简介
网络软件化的进步正在促进在电信运营商的服务和基础设施中引入可编程性。这通常是通过在网络中引入软件定义网络 (SDN) [RFC7149] [RFC7426] 功能来实现的，包括控制器和协调器。
然而，这些 SDN 功能必须解决不同性质的问题。一方面，需要采取侧重于对网络进行编程以处理远程节点之间数字数据的连接或转发的操作。另一方面，还需要专门对处理（或操纵）此类数字数据的功能或服务进行编程的操作。
SDN主张通过在网络节点中引入控制平面与数据平面之间的抽象，将网络节点中的控制平面与数据平面分离，使功能实体（通常称为SDN控制器）上的控制逻辑集中；可以部署一个或多个控制器。然后在转发实体（在网络节点处）和控制实体之间定义编程接口。通过该接口，控制实体指示转发平面中涉及的节点并相应地修改它们的流量转发行为。通过这种编程接口 [RFC7149]，可以预期支持其他功能（例如，性能监控、故障管理等）。
大多数智能都转移到这种功能实体上。通常，这样的实体被视为以垂直、紧密集成的方式交互控制功能的概要。
考虑一个全能控制实体管理网络的整体方面，尤其是传输网络和在其上支持的服务的方法，提出了许多问题：
** 从供应商的角度来看，不同的部门通常负责处理服务和连接（即顶部服务的传输能力），上述方法为完整的服务提供和交付提供了不明确的责任。
** 复杂的功能重用以提供服务。
** 封闭的单片控制架构。
** 功能组件难以实现互操作性和互换性。
** 供应商之间的业务界限模糊，特别是在一个供应商仅提供连接而另一供应商在该连接之上提供更复杂服务的情况下。
** 复杂的服务/网络诊断和故障排除，特别是确定哪一层对故障负责。
将控制功能从多个分布式网络节点重新定位到另一个实体，在概念上将具有不同目的的多个控制功能放在一起。因此，现有的 SDN 解决方案没有明确区分服务和传输控制。这里，服务和传输之间的分离遵循 [Y.2011] 提供的区别，并在本文档的第 2 节中定义。
本文档描述了一种称为 SDN 协作分层架构 (CLAS) 的方法，其中与传输相关的控制功能与与服务相关的控制功能以可以独立提供和维护的方式进行区分，并且可以遵循自己的演进路径。
尽管存在这种差异，服务层和传输层（或 [Y.2011] 中的层）和相关组件之间的密切合作对于提供资源的有效利用是必要的。
2、 术语
本文档使用了以下术语：
** Transport：传输，表示网络基础设施提供的传输能力。传输能力可以依赖于纯 IP 技术或其他方式，例如 MPLS 或光学。
** Service：服务，表示利用传输能力的逻辑结构。
本文档不对可以在传输基础设施之上构建的服务的功能范围做出任何假设。因此，可以向客户提供服务或调用服务以交付另一项（增值）服务。
** Layer：层，指支持传输或服务能力的元素集，如前文所定义。在 [Y.2011] 中，这被称为“stratum”，这两个术语可以互换使用。
** Domain：域，是一组具有共同属性或特征的元素。在本文档中，它适用于管理域（即属于同一组织的元素）、技术域（实现同类技术的元素，如光节点）等。
** SDN Intelligence：SDN智能，指由一个节点或一组节点托管的决策过程。这些节点称为SDN控制器。
智能可以是集中式的，也可以是分布式的。这两种方案都在本文件的范围内。
SDN 智能依赖于来自各种功能块的输入，例如：网络拓扑发现、服务拓扑发现、资源分配、业务指南、客户档案、服务档案等。
除了此处讨论的分层之外，SDN 智能的确切分解超出了本文档的范围。
此外，本文档中使用了以下首字母缩略词：
CLAS：Cooperating Layered Architecture for SDN，SDN 的协作分层架构
FCAPS：Fault, Configuration, Accounting, Performance, and Securit，故障、配置、计费、性能和安全
SDN：Software-Defined Networkin，软件定义网络
SLA：Service Level Agreemen，服务水平协议
3、 架构概述
当前运营商网络支持多种传输技术上的多种服务（例如，IP 电话 (VoIP)、IPTV、移动 VoIP、关键任务应用等）。独立于底层传输能力的服务的提供和交付需要分离与服务相关的功能和传输网络的抽象，以隐藏底层传输技术的细节，同时提供一组通用的能力。
从服务或传输网络的角度来看，这种分离可以提供配置灵活性和适应性。可以在公共传输基础设施之上提供多种服务；同样，不同的技术可以适应某种服务的连接要求。一致的服务交付（层间合作）需要这些元素之间的密切协调。
本文件特别关注以下方法：
** 向服务公开传输能力。
** 获取服务的传输需求。
** 通知服务智能底层传输事件，例如，根据底层传输事件调整服务决策过程。
** 指示底层传输能力以适应新的要求等。
一个示例是保证某些服务质量 (Quality-of-Service，QoS) 级别。不同的基于 QoS 的产品可以出现在服务层和传输层。应该建立用于链接服务和传输 QoS 机制的垂直机制，以便为最终用户提供质量保证。
CLAS 架构假定逻辑上集中的控制功能被分成两个功能层。功能层之一包括与服务相关的功能，而另一层包含与传输相关的功能。两层之间的合作有望通过标准接口实现。
图 1 显示了 CLAS 架构。它基于 ITU-T 在 [Y.2011] 中定义的下一代网络 (Next Generation Network，NGN) 架构中的功能分离，其中定义了两个功能层。这些层是服务层，包括与服务相关的功能，以及传输层，包括与传输相关的功能。这些层中每一层的功能进一步分为控制、管理和用户（或数据）平面。
CLAS 采用 [Y.2011] 中描述的相同结构模型，但通过 SDN [RFC7149] 将其应用于可编程性目标。在这方面，CLAS 提倡以分开的方式处理服务和传输，因为它们的关注点不同。
图 1：SDN 的协作分层架构
在 CLAS 架构中，控制和管理功能都被认为是由一个或一组 SDN 控制器执行的（例如，由于可扩展性、可靠性），以存在分离的 SDN 控制器的方式提供 SDN 智能在服务和传输层。管理功能被认为是 SDN 智能的一部分，以允许在服务供应商生态系统中进行有效操作 [RFC7149]，尽管一些最初的提议并未将此类管理视为 SDN 环境 [ONFArch] 的一部分。
此外，NGN 架构中包含的通用用户或数据平面功能在此称为资源平面功能。每个层中的资源平面由相应的SDN智能通过标准接口控制。
SDN 控制器在服务的提供和交付方面进行合作。存在一个层次结构，其中服务 SDN 智能向传输 SDN 智能发出请求以提供传输功能。
服务 SDN 智能充当传输 SDN 智能的客户端。
此外，传输 SDN 智能与服务 SDN 智能交互以通知它有关传输网络中可以激发服务层中的操作的事件。
尽管未在图 1 中显示，但每个层的资源平面都可以连接。这将取决于所提供的服务类型。此外，服务层可以为应用程序提供一个接口，以向这些应用程序或客户公开网络服务功能。
3.1、 功能层
如前所述，存在将传输相关功能与服务相关功能分开的功能拆分。两个层级合作以提供一致的服务。
一致性由服务层确定和表征。
3.1.1、 传输层
传输层包括专注于通信端点之间（例如，最终用户设备之间、两个服务网关之间等）之间数据传输的功能。数据转发节点由传输 SDN 组件控制和管理。
SDN智能中的控制平面负责指示转发设备为每次通信建立端到端的数据路径或确保转发服务正确设置。转发不能仅仅依赖于预先配置的条目；可以启用手段，以便涉及的节点可以动态地构建路由和转发路径（这将要求节点保留一些控制和管理能力来启用它）。最后，作为传输层功能的一部分，管理平面在这些设备上执行管理功能（即 FCAPS），例如故障或性能管理。
3.1.2、 服务层
服务层包含与提供服务和提供给外部应用程序的能力相关的功能。资源平面由服务交付所涉及的资源组成，如计算资源、注册中心、数据库等。
控制平面负责控制和配置这些资源，并在客户端模式下与传输层的控制平面交互以请求给定服务的传输能力。同理，管理平面对业务相关资源进行管理动作，并与传输层中的管理平面进行交互，保证各层之间的管理协作。
3.1.3、 递归性
递归分层可能发生在某些使用场景中，其中传输层本身是在服务和传输层中构建的。除了纯数据传输（例如，给定 SLA [RFC7297] 的维护）之外，在提供补充有高级功能的传输服务时可能就是这种情况。
[ONFArch] 中也讨论了递归性作为实现可扩展性和模块化的一种方式，其中每个更高的级别都可以提供更大的抽象能力。此外，递归可以允许一些涉及单个或多个管理域的多域场景，例如第 6.3 节中描述的那些。
3.2、 平面分离
CLAS 架构利用平面分离。如第 3.1.1 和 3.1.2 节所述，每个层都考虑三个不同的平面。这三个平面（与其他层中的相应平面）之间的通信基于开放的标准接口。
3.2.1、 控制平面
控制平面在逻辑上集中了各层的控制功能，直接控制相应的资源。[RFC7426] 介绍了控制平面在 SDN 架构中的作用。该平面是 SDN 智能的一部分，可以与相同或不同层中的其他控制平面交互以执行控制功能。
3.2.2、 管理平面
管理平面在逻辑上集中了每个层的管理功能，包括控制平面和资源平面的管理。[RFC7426]描述了SDN环境中管理平面的功能。该平面也是SDN智能的一部分，可以与驻留在同一层或不同层的SDN控制器中的相应管理平面进行交互。
3.2.3、 资源平面
资源平面包括用于传输或服务功能的资源。在某些情况下，服务资源可以连接到传输资源（例如，作为传输功能的终止点）；在其他情况下，它可以与传输资源分离（例如，一个数据库为最终用户保留注册）。[RFC7426] 中提出的转发和操作平面都将成为该架构中资源平面的一部分。
4、 必备功能
由于 CLAS 架构意味着具有不同目的和职责的不同层的交互，因此需要支持许多功能：
** Abstraction：抽象，将物理资源映射到相应的抽象资源。
** Service-Parameter Translation：服务参数转换，根据不同的策略将服务参数（例如，以 SLA 的形式）转换为传输参数（或能力）。
** Monitoring：监控，为了动态更新（抽象的）资源状态同时考虑到例如流量负载的可用机制（例如，事件通知）。
** Resource Computation：资源计算，能够决定哪些资源将用于给定服务请求的功能。例如，可以使用 PCE 之类的函数来计算/选择/决定某个路径。
** Orchestration：编排，以最佳方式组合不同资源（例如 IT 和网络资源）的能力。
** Accounting：计费，资源使用记录。
** Security：安全性，组件之间的安全通信，例如防止 DoS 攻击。
5、 SDN 控制器之间的通信
分别驻留在 Service 和 Transport Strata 中的 SDN 控制器需要建立紧密的协调。应定义为每一层传输相关信息的机制。
从服务的角度来看，Service SDN Intelligence 需要通过定义良好的 API 轻松访问传输资源，以检索传输层提供的能力。可能有不同的方式来获取这种传输感知信息，即通过发现或发布机制。在前一种情况下，服务 SDN 智能可以处理有关传输层提供的传输能力（包括资源）的完整信息。在后一种情况下，传输层揭示可用功能，例如，通过目录，减少底层网络的详细信息量。
另一方面，传输层必须正确捕获服务需求。这些可以包括具有特定指标（例如延迟）的 SLA 要求、要提供的保护级别、最大/最小容量、适用的资源限制等。
控制器之间的通信也必须是安全的，例如，通过防止拒绝服务或任何其他类型的威胁（同样，与网络节点的通信必须是安全的）。
6、 部署场景
根据给定部署中涉及的网络的特性，可以发现不同的情况。
6.1、 全 SDN 环境
本案例认为，提供和交付给定服务所涉及的网络具有 SDN 功能。
6.1.1、 与单个传输层相关联的多个服务层
单个传输层可以向多个服务层提供传输功能。传输层为每个服务层提供标准接口。服务层是传输层的客户。传输层提供的一些功能可以是传输资源的隔离（切片）、独立路由等。
6.1.2、 与多个传输层相关联的单一服务层
单个服务层可以利用不同的传输层来提供特定服务。服务层调用每个传输层的标准接口，并编排提供的传输功能以构建端到端的传输需求。
6.2、 混合环境
这种情况考虑了其中一个层完全或部分遗留的情况。
6.2.1、 与传统传输层相关联的 SDN 服务层
SDN 服务层可以通过互通功能与传统传输层交互，该功能能够使基于 SDN 的控制和管理服务相关命令适应传统传输相关协议，正如传统传输层所期望的那样。
服务层中的 SDN 智能不知道底层传输层的遗留性质。
6.2.2、 与 SDN 传输层相关联的传统服务层
传统服务层可以通过互通功能的中介与支持 SDN 的传输层一起工作，该功能能够解释来自传统服务功能的命令并将它们转换为 SDN 协议，以便与支持 SDN 的传输层一起操作。
6.3、 传输层多领域场景
传输层可以由属于不同管理、拓扑或技术领域的传输资源组成。服务层可以与传输层中的单个实体交互，以防传输部分提供一些抽象功能来模拟单个层。
这些抽象能力构成了传输层向使用该层的服务提供的服务本身。该服务侧重于提供传输能力，这与使用此类能力的最终通信服务不同。
在这种特殊情况下，这种递归允许传输级别的多域场景。
多域情况可能发生在单运营商和多运营商场景中。
在单运营商场景中，多域或端到端抽象组件可以为所有域提供底层异构传输能力的同构抽象视图。
传输层的多运营商场景应支持以编程方式跨相关网络建立端到端路径。例如，这可以通过每个管理域交换其流量工程信息 [RFC7926] 来实现。
7、 用例
本节介绍了许多用例，作为 CLAS 方法适用性的示例。
7.1、 网络功能虚拟化 (NFV)
NFV 环境提供两种可能的 SDN 控制级别 [GSNFV-EVE005]。一层是需要控制 NFV 基础设施 (Network Function Virtualization Infrastructure，NFVI) 以提供 VNF（Virtual Network Functions，虚拟网络功能）之间或 VNF 和 PNF（Physical Network Functions，物理网络功能）之间的端到端连接。第二个层次是VNF本身的控制和配置（换言之，这些VNF实现的网络服务的配置），这得益于SDN带来的可编程性。这两个控制问题本质上是分开的。然而，为了优化、扩展或影响彼此，可以预期两者之间的交互。
7.2、 TE网络的抽象与控制
TE 网络的抽象和控制 (Abstraction and Control of TE Networks，ACTN) [RFC8453] 提出了一个框架，该框架允许向客户提供虚拟网络的创建。ACTN 中“provider”的概念仅限于提供虚拟网络服务。这些服务本质上是传输服务，对应于 CLAS 中的传输层。另一方面，CLAS 中的服务层可以被同化为 ACTN 上下文中的客户。
ACTN 定义了控制器的层次结构，以促进虚拟网络的创建和操作。为请求这些虚拟网络服务的客户与负责编排和服务此类请求的控制器之间的关系定义了一个接口。这种接口等同于图 1（第 3 节）中定义的服务和传输层之间的接口。
8、 服务和传输层之间实施操作的挑战
服务和传输问题的区别在两个层级之间的通信中提出了许多挑战。以下列表反映了一些已确定的挑战：
** 层间交互的标准机制：如今，有许多提案可以满足从服务层到传输层的请求。
一些提案可能是解决方案，如连接供应协商协议（Connectivity Provisioning Negotiation Protocol）[CPNP] 或中间控制器平面接口 (Intermediate-Controller Plane Interface，I-CPI) [ONFArch]。
其他潜在的候选者可能是传输 API [TAPI] 或传输北向接口 [TRANS-NORTH]。这些选项中的每一个都有不同的范围。
** 多供应商感知：在涉及多个传输级别供应商的多域场景中，服务层可能会或可能不会感知到这种域的多样性。
如果服务层不知道多域情况，那么作为服务层请求入口点的传输层应该负责管理多域问题。
相反，如果服务层感知到多域情况，它应该负责协调对不同底层传输层的请求，以组成服务端点（即服务功能）之间的最终端到端路径）。
** SLA 映射：两个层都将处理 SLA，但这些 SLA 的性质可能不同。因此，每个层中的实体都需要将服务 SLA 映射到连接 SLA，以确保正确的服务交付。
** 层之间的关联：层之间的关联可以预先配置，或者两个层都可以要求使用动态建立层之间关联的发现机制。
** 安全性：如前所述，层之间的通信必须是安全的，以防止攻击和威胁。此外，应强制执行隐私，尤其是在传输级别解决多供应商场景时。
** 计费：在层间的通信中应该支持对服务使用和消耗的资源的控制和计费。
9、 IANA 考虑
本文档没有 IANA 操作。
10. 安全考虑
CLAS 架构依赖于在 [RFC7149] 和 [RFC7426] 中引入的功能实体。因此，必须特别考虑 [RFC7149] 第 5 节中讨论的安全注意事项。
服务和传输 SDN 控制器之间的通信必须依赖于实现以下目标的安全方法：
** 在采取任何操作之前，必须启用相互认证。
** 消息完整性保护。
必须向每个控制器提供有关可以向对等控制器公开的信息集（和粒度）的指令。必须启用防止隐私数据泄露的手段（例如，从服务层到传输层）。要共享的确切信息集是特定于部署的。
损坏的控制器可能会对另一个控制器造成一些干扰。应启用针对此类攻击的保护。
此处描述的层之间通信的安全性应适用于要在它们之间定义的 API（和/或协议）。因此，安全问题将对应于特定的解决方案。
11、 参考文献
11.1、 规范参考
[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>.
11.2、 参考资料
[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. [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>. [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>. [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>. [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>. [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>. [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>. [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>. [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. [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>. [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.
附录 A、 与 RFC 7426 的关系
[RFC7426] 通过定义多个平面、抽象层和其中的接口或 API 来引入 SDN 分类法，作为阐明 SDN 的不同组成部分（网络设备、控制和管理）如何关联的手段。定义了许多平面，包括：
** 转发平面：专注于根据从控制平面收到的指令在数据路径中传递数据包。
** 操作平面：以管理网络设备的操作状态为中心。
** 控制平面：专用于指示设备应如何转发数据包。
** 管理平面：负责监控和维护网络设备。
** 应用平面：允许以这种方式控制的所有设备用于不同目的（由每个应用程序确定）。
除此之外，[RFC7426] 提出了许多抽象层，允许通过公共接口集成不同的平面。CLAS 将控制、管理和资源平面作为其架构的基本部分。本质上，控制平面修改受控资源的行为和动作。管理平面监控和检索这些资源的状态。最后，资源平面将与每个层的关注点相关的所有资源进行分组。
从这个角度来看，CLAS 平面可以看作是 [RFC7426] 中定义的那些平面的超集。然而，在某些情况下，并非 [RFC7426] 中考虑的所有平面都可能完全存在于 CLAS 表示中（例如，服务层中的转发平面）。
话虽如此，CLAS 层的内部结构可以遵循 [RFC7426] 中定义的分类法。不同之处在于通过区分服务和传输来实现 SDN 环境的专业化。
致谢
该文档之前在 IRTF SDN RG 中被讨论并采用为 [SDN-ARCH]。IRTF SDN RG 关闭后，该文件作为独立提交文件进行处理，以记录（部分）该小组的讨论。
作者要感谢（按字母顺序） Bartosz Belter、Gino Carrozzo、Ramon Casellas、Gert Grammel、Ali Haider、Evangelos Haleplidis、Zheng Haomian、Giorgios Karagiani、Gabriel Lopez、Maria Rita Palatella、Christian Esteve Rothenberg 和 Jacek Wytrebowicz他们的意见和建议。
感谢 Adrian Farrel 的评论。
