软件定义网络 （SDN）：分层和架构术语

Software-Defined Networking （SDN）: Layers and Architecture Terminology，January 2015

梗概

软件定义网络（Software-Defined Networking，SDN）是一种网络可编程性的新方法，即通过开放接口动态初始化、控制、更改和管理网络行为的能力。SDN 通过引入数据转发平面的抽象概念来强调软件在运行网络中的作用，并通过这样做将其与控制平面分离。正如经验已经表明的那样，这种分离允许在两个层面加快创新周期。然而，对于 SDN 到底是什么、SDN 架构中的层结构是什么以及层如何相互连接，人们越来越困惑。本文档是 IRTF 软件定义网络研究组 （Software-Defined Networking Research Group，SDNRG） 的产品，基于相关同行评审文献、RFC 系列和其他标准组织的相关文档，解决了这些问题并为 SDN 研究社区提供了简明的参考.

本备忘录的状态

本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。

本文档是互联网研究任务组（Internet Research Task Force，IRTF） 的产品。IRTF 发布与互联网相关的研究和开发活动的结果。这些结果可能不适合部署。该 RFC 代表了互联网研究任务组 （IRTF） 的软件定义网络研究组的共识。IRSG 批准发布的文件不是任何级别的 Internet 标准的候选文件；请参阅 RFC 5741 的第 2 节。

有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7426。

版权声明

版权所有 （c） 2015 IETF Trust 和确定为文档作者的人员。版权所有。

本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 （http://trustee.ietf.org/license-info） 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。

1、 简介

“软件定义网络 （Software-Defined Networking，SDN）”是可编程网络范式 [PNSurvey99] [OF08] 的一个术语。简而言之，SDN 是指软件应用程序能够动态地对单个网络设备进行编程，从而控制整个网络的行为 [NV09]。Boucadair 和 Jacquenet [RFC7149] 指出，SDN 是一组技术，用于以确定性、动态和可扩展的方式促进网络服务的设计、交付和操作。

SDN 中的一个关键元素是在（传统）转发和控制平面之间引入抽象概念，以便将它们分开并为应用程序提供以编程方式控制网络所需的手段。目标是利用这种分离和相关的可编程性，以降低复杂性并在两个平面上实现更快的创新 [A4D05]。

[SDNHistory] [SDNSurvey] 详细回顾了可编程网络研发领域的历史演变，从 1980 年代的努力开始。正如 [SDNHistory] 所记录的，许多想法、概念和关注点都适用于 SDN（和 SDN 标准化）的最新研究和发展，并且在相当长的一段时间内已经在研究社区中进行了广泛的调查和讨论。例如，Rooney等人的[Tempest] 讨论如何在不危及网络完整性的情况下允许第三方访问网络，或者如何在他们的（当时是新的）可编程环境中适应传统的网络解决方案。此外，在 SDN 中很突出的分离控制和转发平面的概念甚至在 1998 年 [Tempest] [P1520] 之前就已经在 SS7 网络 [ITUSS7]、Ipsilon Flow Switching [RFC1953] [RFC2297] 和ATM [ITUATM]。

SDN 研究通常侧重于可编程性的不同方面，我们经常面临关于 SDN 究竟是什么的相互矛盾的观点。例如，我们发现由于各种原因（例如，工作专注于一个领域，因此不一定适用于其他领域），某些广为接受的定义彼此之间并没有很好的相关性。例如，OpenFlow [OpenFlow] 和网络配置协议 （NETCONF） [RFC6241] 都被描述为 SDN 接口，但它们分别指的是控制和管理。

这促使我们整合文献中 SDN 的定义，并将它们与 IETF 和研究社区的早期工作相关联。例如，特别感兴趣的是确定哪些层构成 SDN 架构以及哪些接口及其相应的属性最适合在它们之间使用。因此，本文档的目的不是标准化任何特定层或接口，而是提供一个简明的参考，以反映有关 SDN 层架构的当前方法。我们希望本文档对 SDNRG 即将开展的工作以及整个 SDN 社区内的未来讨论有用。

本文档解决了 SDNRG 章程中题为“SDN 方法和分类法调查”的工作项目，以技术公正和业务不可知的方式促进对主要 SDN 技术的更好理解，但不构成新的 IETF 标准。它旨在作为进一步讨论的共同基础。因此，我们不会做出任何价值陈述，也不会讨论本文档中审查的任何框架针对任何特定目的的适用性。相反，我们记录它们的特征和属性并对它们进行分类，从而提供分类法。本文档不打算提供 SDN 研究问题的详尽列表；感兴趣的读者应该考虑复习 [SLTSDN] 和 [SDNACS]。特别是，Jarraya 等人的[SLTSDN] 概述了与 SDN 相关的研究主题，例如控制分区，它与第 3.5.4 节中讨论的一致性、可用性和分区 （Consistency, Availability and Partitioning，CAP） 定理相关。

SDNRG 的绝大多数成员已经对这份文件进行了广泛的审查、讨论和评论，该社区肯定超过 100 人。SDNRG 的共识是该文档应该发布在 RFC 系列的 IRTF 流中 [RFC5743]。

本文档的其余部分组织如下：第 2 节解释了本文档中使用的术语，第 3 节介绍了当前 SDN 架构抽象概念的高级概述，最后，第 4 节讨论了 SDN 层架构如何与突出的 SDN 使能技术相关联。

2、 术语

本文档使用以下术语：

** 软件定义网络 （Software-Defined Networking，SDN）：一种可编程网络方法，支持通过标准化接口分离控制和转发平面。

** 资源（Resource）：系统内可用的物理或虚拟组件。资源可以非常简单或细粒度（例如，端口或队列）或复杂，由多个资源（例如，网络设备）组成。

** 网络设备（Network Device）：执行一个或多个与数据包操作和转发相关的网络操作的设备。此参考模型不区分网络设备是物理设备还是虚拟设备。设备也可以被认为是资源的容器，它本身也可以是一种资源。

** 接口（Interface）：两个实体之间的交互点。当实体被放置在不同的位置时，接口通常是通过网络协议来实现的。如果实体位于同一物理位置，则可以使用软件应用程序编程接口 （application programming interface，API）、进程间通信 （inter-process communication，IPC） 或网络协议来实现该接口。

** 应用程序（Application/App）：SDN上下文中的应用程序是一种利用底层服务来执行功能的软件。应用程序操作可以参数化，例如，通过在调用时传递某些参数，但它意味着是一个独立的软件；应用程序不提供与其他应用程序或服务的任何接口。

** 服务（Service）：一种软件，它执行一个或多个功能，并向应用程序或相同或不同层的其他服务提供一个或多个 API，以使用所述功能并返回一个或多个结果。服务可以与其他服务结合，或者以某种序列化的方式调用，来创建一个新的服务。

** 转发平面 （Forwarding Plane，FP）：负责转发流量的所有网络设备的资源集合。

** 操作平面 （Operational Plane，OP）：负责管理单个网络设备的整体操作的资源集合。

** 控制平面 （Control Plane，CP）：负责控制一个或多个网络设备的功能集合。CP 指示网络设备如何处理和转发数据包。控制平面主要与转发平面交互，在较小程度上与操作平面交互。

** 管理平面 （Management Plane，MP）：负责监控、配置和维护一个或多个网络设备或部分网络设备的功能集合。管理平面主要与操作平面相关（与转发平面相关较少）。

** 应用程序平面（Application Plane）：对网络行为进行编程的应用程序和服务的集合。

** 设备和资源抽象概念层 （Device and resource Abstraction Layer，DAL）：基于一个或多个模型的设备资源抽象概念层。如果是物理设备，则可以将其称为硬件抽象概念层 （Hardware Abstraction Layer，HAL）。DAL 为设备的转发和操作平面资源提供统一的参考点。

** 控制抽象概念层 （Control Abstraction Layer，CAL）：控制平面的抽象概念层。CAL 提供对控制平面南向接口的访问。

** 管理抽象概念层 （Management Abstraction Layer，MAL）：管理平面的抽象概念层。MAL 提供对管理平面南向接口的访问。

** 网络服务抽象概念层 （Network Services Abstraction Layer，NSAL）：提供可供应用程序和服务使用的服务抽象概念。

3、 SDN 分层和架构

图 1 以详细的高级示意图的形式总结了 SDN 架构抽象概念。请注意，在特定实现中，平面可以与其他平面并置或物理分离，如下所述。

SDN基于受控实体和控制器实体分离的概念。控制器通过接口操纵受控实体。本地接口主要是通过某些库或系统调用进行的 API 调用。然而，这些接口可以通过一些协议定义进行扩展，它可以使用本地进程间通信（IPC）或也可以远程操作的协议；该协议可以定义为开放标准或专有方式。

Day [PiNA] 探讨了使用 IPC 作为定义具有不同程度和操作范围的递归网络架构的主要支柱。递归网络架构 [RINA] 概述了基于 IPC 的递归网络架构，该架构利用重复模式和结构。本文档不提出新架构——我们只是通过分类法记录以前的工作。尽管递归超出了这项工作的范围，但图 1 展示了一个分层模型，其中的层可以相互堆叠并根据需要递归使用。

图 1：SDN 层架构

3.1、 概述

本文档遵循以网络设备为中心的方法：控制主要是指设备数据包处理能力，而管理通常是指整个设备操作的各个方面。我们将网络设备视为一个复杂的资源，它包含类似于 [DIOPR] 的多个资源，并且是多个资源的一部分。资源可以是简单的网络设备的单个组件，例如设备的端口或队列，也可以聚合为复杂的资源，例如网卡或完整的网络设备。

读者应该记住，我们在本文档中不区分“物理”和“虚拟”资源或“硬件”和“软件”实现，因为我们没有深入研究实现或性能方面。换句话说，资源可以完全在硬件中、完全在软件中或两者之间的任何混合组合中实现。此外，我们不区分资源是作为覆盖物还是作为其他设备的一部分/组件来实现的。通常，网络设备软件可以在所谓的“裸金属”或虚拟化基板上运行。最后，本文档不讨论如何分配、编排和释放资源。实际上，编排超出了本文档的范围。

SDN 跨越多个平面，如图 1 所示。从图的底部开始，向上移动，我们确定了以下平面：

** 转发平面 - 负责根据从控制平面收到的指令处理数据路径中的数据包。转发平面的动作包括但不限于转发、丢弃和改变报文。转发平面通常是控制平面服务和应用程序的终点。转发平面可以包含分类器等转发资源。转发平面也被广泛称为“数据平面”或“数据路径”。

** 操作平面 - 负责管理网络设备的运行状态，例如，设备处于活动状态还是非活动状态，可用端口数量，每个端口的状态等。操作平面通常是管理平面服务和应用程序的终点。操作平面与端口、内存等网络设备资源相关。我们注意到，IRTF SDNRG 的一些参与者对操作平面的定义有不同的看法。也就是说，可以争辩说，操作平面本身并不构成“平面”，但实际上，它是转发平面上功能的合并。然而，对于其他人来说，“平面”允许人们区分不同的行动领域；因此，操作平面作为“平面”包含在图 1 中。我们在本文档中采用了后一种视图。

** 控制平面 - 负责决定一个或多个网络设备应如何转发数据包，并将此类决定下推至网络设备以执行。控制平面通常主要关注转发平面，较少关注设备的操作平面。控制平面可能对操作平面信息感兴趣，其中可以包括例如特定端口的当前状态或其能力。控制平面的主要工作是根据网络拓扑或外部服务请求微调驻留在转发平面中的转发表。

** 管理平面 - 负责监控、配置和维护网络设备，例如，做出有关网络设备状态的决策。管理平面通常主要关注设备的操作平面，较少关注转发平面。管理平面可用于配置转发平面，但与控制平面相比，它很少这样做，并且通过更大规模的方法来配置。例如，管理平面可以一次设置全部或部分转发规则，尽管预计会谨慎地采取此类行动。

** 应用程序平面 - 定义网络行为的应用程序和服务所在的平面。直接（或主要）支持转发平面操作的应用程序（例如控制平面内的路由进程）不被视为应用程序平面的一部分。请注意，应用程序可能以模块化和分布式方式实现，因此，通常可以跨越图 1 中的多个平面。

[RFC7276] 在操作、管理和维护 （Operations, Administration, and Maintenance，OAM） 方面定义了数据、控制和管理平面。本文档试图扩大 [RFC7276] 中定义的术语，以反映 SDN 架构的所有方面。

上面提到的所有平面都是通过接口连接的（图1中用“Y”表示。根据连接的平面是否位于同一个（物理或虚拟）设备上，一个接口可以扮演多个角色。如果各个平面被设计为使得它们不必驻留在同一个设备中，那么接口只能采用协议的形式，如果平面配置在同一个设备上，那么接口可以通过开放/专有协议、开放/专有软件实现进程间通信 API，或操作系统内核系统调用。

应用程序，即执行特定计算、消费服务而不提供对其他应用程序的访问的软件程序，可以在一个平面内本地实现，也可以跨越多个平面。例如，应用程序或服务可以跨越控制平面和管理平面，因此能够同时使用控制平面南向接口 （Control-Plane Southbound Interface，CPSI） 和管理平面南向接口 （Management-Plane Southbound Interface，MPSI），尽管这在图 1 中只是隐式说明。这种情况的一个例子是同时使用 [OpenFlow] 和 [OF-CONFIG] 的应用程序。

服务，即为其他应用程序或服务提供 API 的软件程序，也可以在特定平面上本地实现。跨多个平面的服务也属于应用程序平面。

虽然图 1 中没有明确显示，但服务、应用程序和整个平面可以以递归方式放置，从而为模型提供覆盖语义。例如，可以通过 NSAL 向其他应用程序或服务提供应用程序平面服务。其他示例包括在物理资源和分层控制平面控制器 [KANDOO] 之上实现的虚拟资源。

请注意，本文档的重点当然是不同位面实体之间的南北通信。但这显然不排除任何一个位面内的实体通信。

然而，必须注意的是，在图 1 中，我们呈现了各种平面的抽象概念视图，其中没有实现细节。过去的许多实现都选择将管理平面置于控制平面之上。这可以解释为让控制平面充当管理平面的服务。此外，在许多网络中，尤其是在 Internet 路由器和以太网交换机中，控制平面通常被实现为与网络设备紧密耦合。作为一个整体，控制平面已经分布在网络范围内。另一方面，管理平面传统上是集中的，负责管理控制平面和设备。但是，随着 SDN 原则的采用，这种区别不再那么明显。

此外，本文档考虑了四个抽象概念层：

** 设备和资源抽象概念层 （DAL） 将设备转发和操作平面的资源抽象概念到控制和管理平面。DAL 的变体可以抽象概念两个平面或两者之一，并且可以将设备的任何平面抽象概念为控制平面或管理平面。

** 控制抽象概念层 （CAL） 从控制平面的应用程序和服务中抽象概念出控制平面南向接口和 DAL。

** 管理抽象概念层 （MAL） 从管理平面的应用程序和服务中抽象概念出管理平面南向接口和 DAL。

** 网络服务抽象概念层 （NSAL） 提供供应用程序和其他服务使用的服务抽象概念。

在撰写本文时，其他 SDO 已开始开展与 SDN 相关的活动。例如，在国际电联，关于架构[ITUSG13]和信令要求和协议[ITUSG11]的工作已经开始，但除了[ITUY3300]之外，各自的研究组尚未发布他们的文件。[ITUY3300] 和 [ONFArch] 中提出的观点与本文件完全一致。

3.2、 网络设备

网络设备是在其端口上接收数据包并在其上执行一个或多个网络功能的实体。例如，网络设备可以转发接收到的数据包、丢弃它、更改数据包头（或有效载荷）、转发数据包等等。网络设备是端口、CPU、内存、队列等多种资源的集合。资源可以是简单的，也可以聚合形成可以视为一种资源的复杂资源。网络设备本身就是一个复杂的资源。网络设备的示例包括交换机和路由器。其他示例包括可以在 IP 之上的层（例如防火墙、负载均衡和视频转码器）或 IP 之下（例如第 2 层交换机和光或微波网络元件）运行的网络元件。

网络设备可以用硬件或软件实现，可以是物理的也可以是虚拟的。正如之前已经提到的，本文档没有做这样的区分。每个网络设备都存在于转发平面和操作平面中。

转发平面，通常称为“数据路径”，负责处理和转发数据包。转发平面提供交换、路由、数据包转换和过滤功能。转发平面的资源包括但不限于过滤器、仪表、标记和分类器。

操作平面负责网络设备的操作状态，例如，关于网络端口和接口的状态。操作平面资源包括但不限于内存、CPU、端口、接口和队列。

转发和操作平面通过设备和资源抽象概念层 （DAL） 公开，可以由一个或多个抽象概念模型表示。转发平面抽象概念模型的示例是转发和控制元素分离 （Forwarding and Control Element Separation，ForCES） [RFC5812]、OpenFlow [OpenFlow]、YANG 模型 [RFC6020] 和 SNMP MIB [RFC3418]。操作平面抽象概念模型的示例包括 ForCES 模型 [RFC5812]、YANG 模型 [RFC6020] 和 SNMP MIB [RFC3418]。

请注意，应用程序也可以驻留在网络设备中。此类应用的示例包括设备本身中的事件监控和处理（卸载）拓扑发现或 ARP [RFC0826]，而不是将此类流量转发到控制平面。

3.3、 控制平面

控制平面通常是分布式的，主要负责使用以 DAL 作为参考点的控制平面南向接口 （CPSI） 来配置转发平面。CP 负责指示 FP 如何处理网络数据包。

控制平面实体之间的通信，通俗地称为“东西向”接口，通常通过网关协议（例如 BGP [RFC4271]）或其他协议（例如路径计算元素 （Path Computation Element，PCE） 通信协议 （PCEP） [RFC5440] 来实现） ]。这些相应的协议消息通常在带内交换，然后由转发平面重定向到控制平面以进行进一步处理。此类别中的示例包括 [RCP]、[SoftRouter] 和 [RouteFlow]。

控制平面功能通常包括：

** 拓扑发现和维护

** 数据包路由选择和实例化

** 路径故障转移机制

CPSI 通常定义为具有以下特征：

** 时间要求严格的接口，需要低延迟和有时需要高带宽才能在短时间内执行许多操作

** 面向线效率和设备表示，而不是人类可读性

示例包括快速和高频的流或表更新、高吞吐量以及数据包处理和事件的稳健性。

CPSI 可以使用协议、API 甚至进程间通信来实现。如果控制平面和网络设备没有并置，那么这个接口肯定是一个协议。CPSI 的示例是 ForCES [RFC5810] 和 OpenFlow 协议 [OpenFlow]。

控制抽象概念层 （CAL） 为各种 CPSI 提供对控制应用程序和服务的访问。控制平面可以支持一个以上的CPSI。

控制应用程序可以使用 CAL 来控制网络设备，而无需向上层提供任何服务。示例包括执行控制功能的应用程序，例如 OSPF、IS-IS 和 BGP。

控制平面服务示例包括虚拟专用 LAN 服务、服务隧道、拓扑服务等。

3.4、 管理平面

管理平面通常是集中式的，旨在通过使用管理平面南向接口 （MPSI） 以 DAL 作为参考点与网络设备的操作平面进行通信，从而确保整个网络以最佳方式运行。

管理平面功能通常基于整体网络视图启动，并且传统上以人为中心。然而，最近，算法正在取代大多数人为干预。管理平面功能 [FCAPS] 通常包括：

** 故障及监控管理

** 配置管理

此外，管理平面功能还可能包括协调器、虚拟网络功能管理器（Virtual Network Function Managers，VNF 管理器）和虚拟化基础设施管理器等实体，如 [NFVArch] 中所述。这样的实体可以使用操作平面资源的管理接口来请求和提供虚拟功能的资源，以及在物理转发功能之上指示虚拟转发功能的实例化。[SDNNFV] 探讨了 SDN 和网络功能虚拟化 （Network Function Virtualization，NFV） 的通用抽象概念模型的可能性。但是请注意，这些只是管理平面中的应用程序和服务的示例，而不是本文档中实体的正式定义。如上所述，编排以及任何关联实体的定义超出了本文档的范围。

与 CPSI 相比，MPSI 通常不是一个时间关键的接口并且不共享 CPSI 要求。

MPSI 通常比 CPSI 更接近于人类交互（参见 [RFC3535]）；因此，MPSI通常具有以下特点：

** 它更注重可用性，最佳的线路性能是次要问题。

** 消息的频率往往低于 CPSI。

作为可用性与性能的示例，我们参考 2002 IAB Workshop [RFC3535] 的共识：网络管理技术的关键要求是易用性，而不是性能。根据 [RFC6632]，文本配置文件应该能够包含国际字符。人类可读的字符串应该使用 UTF-8，协议元素应该是不区分大小写的 ASCII，这需要更多的处理能力来解析。

MPSI 的范围可以从协议到 API 甚至进程间通信。如果管理平面没有嵌入到网络设备中，那么 MPSI 肯定是一种协议。MPSI 的示例包括 ForCES [RFC5810]、NETCONF [RFC6241]、IP 流信息导出 （IP Flow Information Export，IPFIX） [RFC7011]、Syslog [RFC5424]、Open vSwitch 数据库 （Open vSwitch Database，OVSDB） [RFC7047] 和 SNMP [RFC3411]。

管理抽象概念层 （MAL） 为各种 MPSI 提供对管理应用程序和服务的访问。管理平面可以支持一个以上的 MPSI。

管理应用程序可以使用 MAL 来管理网络设备，而无需向上层提供任何服务。管理应用程序的示例包括网络监控、故障检测和恢复应用程序。

管理平面服务提供对管理平面之上的其他服务或应用程序的访问。

3.5、 控制和管理平面的讨论

在编写本文档期间，SDN 上下文中“控制”和“管理”之间明确区别的定义受到了社区的极大关注。我们观察到，管理平面的作用早先在很大程度上被忽略或指定为超出 SDN 生态系统的范围。在本小节的其余部分，我们总结了区分两个平面的特征，以便清楚地了解每个接口的机制、功能和需求。

3.5.1、 时间表

关于控制和管理平面的参考时间尺度提出了一个观点，即各个平面需要多快地对设备的转发或操作平面做出反应，或者需要多快地操纵设备的转发或操作平面。通常，控制平面需要“经常”发送更新，大致转换为毫秒范围；这需要高带宽和低延迟的链接。相比之下，管理平面通常在更长的时间范围内做出反应，即几分钟、几小时甚至几天；因此，线效率并不总是一个关键问题。一个很好的例子是改变设备的配置状态。

3.5.2、 持久性

控制平面和管理平面之间的另一个区别与状态持久性有关。如果一个状态的生命周期非常有限并且被认为没有必要存储在非易失性存储器上，则该状态被认为是短暂的。一个很好的例子是确定路由，它通常与控制平面相关联。另一方面，持久状态具有更长的生命周期，可能从几小时到几天和几个月不等，旨在在创建它的进程的生命周期之外使用，因此在设备重新启动时使用。持久状态通常与管理平面相关联。

3.5.3、 本地性

如前所述，传统上，控制平面在网络设备上本地执行并且本质上是分布式的，而管理平面通常以集中方式在远离设备的地方执行。然而，随着SDN集中化或“逻辑集中化”的出现，控制器倾向于混淆基于局部性的控制和管理平面的区别。

3.5.4、 CAP 定理见解

CAP 定理将分布式计算系统视为由多个计算资源（即 CPU、内存、存储）组成，这些资源通过通信网络连接并一起执行任务。该定理或某些人的猜想确定了分布式系统的三个普遍需要的特征：

** 一致性，意味着无论哪个节点收到请求（或根本不响应），系统都会对查询做出相同的响应。

** 可用性，即系统始终响应请求（尽管响应可能不一致或不正确）。

** 分区容错性，即即使特定节点或通信网络出现故障，系统仍能继续运行。

2000 年，Eric Brewer [CAPBR] 推测分布式系统可以同时满足这些保证中的任何两个，但不能同时满足所有三个。这个猜想后来被吉尔伯特和林奇 [CAPGL] 证明，现在通常被称为 CAP 定理 [CAPFN]。

通过网络正确转发数据包是一个计算问题。SDN 提出的主要抽象概念之一是所有网络元素都是计算资源，它们执行简单的计算任务，即检查传入数据包中的字段并决定如何转发它。由于将数据包从网络入口转发到网络出口的任务显然是由大量转发元素来执行的，因此转发设备网络是一个分布式计算系统。因此，CAP 定理适用于数据包的转发。

在 CAP 定理的背景下，如果考虑最重要的分区容错性，传统的控制平面操作通常是本地和快速的（可用），而管理平面操作通常是集中的（一致的）并且可能很慢。

CAP 定理还提供了对 SDN 架构的洞察。例如，集中式 SDN 控制器充当一致的全局数据库，特定的 SDN 机制确保进入网络的数据包由所有 SDN 交换机一致处理。基本 SDN 模型没有解决控制器连接丢失的容忍问题。当SDN交换机无法到达其控制器时，流量将不可用，直到连接恢复。已经提出使用多个非并置的 SDN 控制器（例如，通过使用控制器列表配置 SDN 交换机）；这可能会提高分区容错性，但代价是绝对一致性的损失。Panda等人的 [CAPFN] 首次探索了 CAP 定理如何应用于 SDN。

3.6、 网络服务抽象概念层

网络服务抽象概念层 （NSAL） 提供从控制、管理和应用程序平面的服务到其他服务和应用程序的访问。我们注意到术语“SAL”被过度使用，因为它经常用于从系统设计到面向服务的体系结构的多种上下文中；因此，我们在该层的标题中明确添加“网络”以强调该术语与图 1 相关，并且我们在第 4 节中将其相应地映射到突出的 SDN 方法。

服务接口可以采用与其特定要求相关的多种形式。服务接口的示例包括但不限于 RESTful API、开放协议（例如 NETCONF）、进程间通信、CORBA [CORBA] 接口等。服务接口的两种主要方法是 RESTful 接口和远程过程调用 （Remote Procedure Call，RPC） 接口。两者都遵循客户端-服务器架构并使用 XML 或 JSON 来传递消息，但每个都有一些略有不同的特征。

RESTful 接口，根据表征状态转移设计范式 [REST] 设计，具有以下特点：

** 资源标识 - 使用资源标识符（例如 URI）标识单个资源。

** 通过表示操作资源 - 资源以 JSON、XML 或 HTML 等格式表示。

** 自描述消息 - 每条消息都有足够的信息来描述如何处理消息。

** 超媒体作为应用程序状态的引擎——客户端不需要事先知道如何与服务器交互，因为 API 不是固定的，而是由服务器动态提供的。

远程过程调用 （RPC） [RFC5531]，例如 XML-RPC 等，具有以下特征：

** 单个程序使用标识符进行标识。

** 客户端需要知道过程名称和相关参数。

3.7、 应用平面

使用来自控制和/或管理平面的服务的应用程序和服务构成了应用程序平面。

此外，驻留在应用程序平面中的服务可以通过服务接口向驻留在应用程序平面中的其他服务和应用程序提供服务。

应用示例包括网络拓扑发现、网络配置、路径预留等。

4、 SDN 模型视图

我们主张SDN南向接口应该同时包含CPSI和MPSI。

[NOX] 和 [Beacon] 等 SDN 控制器是实现 CPSI（[NOX] 和 [Beacon] 均使用 OpenFlow）并为应用程序提供北向接口的控制平面应用程序和服务的集合。控制器的 SDN 北向接口在图 1 的网络服务抽象概念层 （NSAL） 中实现。

上述模型可用于以简洁的方式描述所有突出的支持 SDN 的技术，我们将在以下小节中进行解释。

4.1、 ForCES

IETF 转发和控制元素分离 （ForCES） 框架 [RFC3746] 由一个模型和两个协议组成。ForCES 通过开放接口将转发平面与控制平面分离，即 ForCES 协议 [RFC5810]，该协议在转发平面的实体上运行，这些实体已使用 ForCES 模型 [RFC5812] 建模。

ForCES 模型 [RFC5812] 基于这样一个事实，即网络元素由许多逻辑上独立的实体组成，这些实体合作提供给定的功能（例如路由或 IP 交换），但对于外部实体却表现为正常的集成网络元素。

ForCES 使用逻辑功能块 （Logical Functional Blocks，LFB） 对转发平面进行建模，逻辑功能块 （LFB） 在连接到图中时构成转发元素 （Forwarding Element，FE）。LFB 以 XML 描述，基于 XML 模式。

LFB 定义包括基本和自定义数据类型；元数据定义；输入和输出端口；操作参数或组件；以及能力和事件定义。

ForCES 模型可用于根据需要定义从细粒度到粗粒度的 LFB，无论它们是物理的还是虚拟的。

ForCES 协议与模型无关，可用于监视、配置和控制任何 ForCES 建模元素。该协议具有非常简单的命令：Set、Get 和 Del（ete）。ForCES 协议旨在实现高吞吐量和快速更新。

关于图 1，ForCES 模型 [RFC5812] 适用于 DAL，无论是操作平面还是转发平面，都使用 LFB。ForCES 协议 [RFC5810] 已经设计并适用于 CPSI，尽管它也可以用于 MPSI。

4.2、 NETCONF/YANG

网络配置协议 （NETCONF） [RFC6241] 是 IETF 网络管理协议 [RFC6632]。NETCONF 提供了安装、操作和删除网络设备配置的机制。

NETCONF 协议操作实现为远程过程调用 （RPC）。NETCONF 协议对配置数据和协议消息使用基于 XML 的数据编码。最近的研究，例如 [ESNet] 和 [PENet]，表明 NETCONF 的性能优于 SNMP [RFC3411]。

此外，YANG 数据建模语言 [RFC6020] 已开发用于指定 NETCONF 数据模型和协议操作。YANG 是一种数据建模语言，用于对由 NETCONF 协议、NETCONF 远程过程调用和 NETCONF 通知操作的配置和状态数据进行建模。

YANG 将数据的分层组织建模为树，其中每个节点都有一个值或一组子节点。此外，YANG 将数据模型构建为模块和子模块，从而实现可重用性和扩充性。YANG 模型可以描述要对数据实施的约束。此外，YANG 有一组基本数据类型，也允许自定义数据类型。

YANG 允许定义 NETCONF RPC，这允许协议具有可扩展数量的命令。对于 RPC 定义，操作名称、输入参数和输出参数是使用 YANG 数据定义语句定义的。

关于图 1，YANG 模型 [RFC6020] 适用于为转发和操作平面指定 DAL。NETCONF [RFC6241] 适用于 MPSI。NETCONF 是一个管理协议 [RFC6632]，它（最初）不是为快速 CP 更新而设计的，它可能不适合解决 CPSI 的要求。

4.3、 OpenFlow

OpenFlow 是最初在斯坦福大学开发的框架，目前正在通过开放网络基金会 （Open Networking Foundation，ONF） 进行积极的标准开发 [OpenFlow]。最初，目标是为研究人员提供一种在生产网络中运行实验协议的方法 [OF08]。OpenFlow 经历了多次修订，可能还会有其他修订。以下描述反映了版本 1.4 [OpenFlow]。简而言之，OpenFlow 定义了一种协议，通过该协议，逻辑上集中的控制器可以控制 OpenFlow 交换机。每个 OpenFlow 兼容交换机维护一个或多个流表，用于执行数据包查找。将针对数据包查找和转发采取不同的操作。组表和到外部控制器的 OpenFlow 通道也是交换机规范的一部分。

关于图 1，OpenFlow 交换机规范 [OpenFlow] 为转发平面以及 CPSI 定义了 DAL。OF-CONFIG协议[OF-CONFIG]基于YANG模型[RFC6020]，为OpenFlow交换机的转发和操作平面提供DAL，并指定NETCONF[RFC6241]作为MPSI。OF-CONFIG 与 OpenFlow DAL 重叠，但使用 NETCONF [RFC6241] 作为传输协议，它共享上一节中描述的限制。

4.4、 路由系统接口

路由系统接口 （Interface to the Routing System，I2RS） 为路由系统提供标准接口，用于通过基于协议的控制或管理接口集合进行实时或事件驱动交互。从本质上讲，I2RS 的主要目标之一是使路由信息库 （Routing Information Base，RIB） 可编程，从而实现新型网络配置和操作。

I2RS 最初并不打算创建新接口，而是利用或扩展现有接口并为路由系统定义信息模型。例如，最新的 I2RS 问题陈述 [I2RSProb] 讨论了先前定义的 IETF 协议，例如 ForCES [RFC5810]、NETCONF [RFC6241] 和 SNMP [RFC3417]。关于信息和数据模型的定义，I2RS 工作组选择使用 YANG [RFC6020] 建模语言。

目前，I2RS 工作组正在为 I2RS 代理开发关于网络服务抽象概念层的信息模型 [I2RSInfo]。

关于图 1，I2RS 架构 [I2RSArch] 包含控制和应用平面，并使用任何可用的 CPSI 和 DAL，无论是 ForCES [RFC5810]、OpenFlow [OpenFlow] 或其他接口。此外，I2RS 代理是一种控制平面服务。在此之上的所有服务或应用程序属于控制、管理或应用程序平面。在 I2RS 文档中，对代理的管理访问可能由 SNMP 和 NETCONF 等管理协议提供。I2RS 协议也可以映射到服务接口，因为它甚至可以提供对控制平面服务和应用程序以外的服务和应用程序的访问。

4.5、 SNMP

简单网络管理协议 （Simple Network Management Protocol，SNMP） 是 IETF 标准化管理协议，目前处于第三次修订 （SNMPv3） [RFC3417] [RFC3412] [RFC3414]。它由一组网络管理标准组成，包括应用层协议、数据库模式和一组数据对象。SNMP 在管理系统上以变量的形式公开管理数据（管理对象），描述系统配置。然后可以通过管理应用程序来查询和设置这些变量。

SNMP 使用可扩展设计来描述数据，由管理信息库 （Management Information Bases，MIB） 定义。MIB 描述了设备子系统的管理数据的结构。MIB 使用包含对象标识符 （object identifiers，OID） 的分层命名空间。每个 OID 标识一个可以通过 SNMP 读取或设置的变量。MIB 使用由结构管理信息版本 2 [RFC2578] 定义的符号。

[Peregrine] 中讨论了 SDN 上下文中 SNMP 的早期示例。

关于图 1，SNMP MIB 可用于描述转发和操作平面的 DAL。与 YANG 类似，SNMP MIB 能够为转发平面描述 DAL。SNMP 类似于 NETCONF，适用于 MPSI。

4.6、 PCEP

路径计算元素 （Path Computation Element，PCE） [RFC4655] 架构定义了一个能够计算单个服务或一组服务的路径的实体。PCE 可能是一个网络节点、网络管理站或专用计算平台，它具有资源感知能力，能够为各种路径计算问题和交换技术考虑多种约束。 PCE 通信协议 （PCE Communication Protocol，PCEP） [RFC5440] 用于路径计算客户端 （Path Computation Client，PCC） 和 PCE 之间，或多个 PCE 之间。

PCE 架构代表了一种网络愿景，它将服务的路径计算、端到端连接的信令和实际的数据包转发分开。在线和离线路径计算的定义取决于 PCE 从网络和网络管理系统 （Network Management System，NMS） 节点的可达性以及可能显着影响从 PCE 到 PCC 的优化响应时间的优化请求的类型。

PCEP 消息传递机制促进了计算端点（源和目标节点地址）、目标函数（请求的算法和优化标准）以及相关的约束（例如流量参数（例如，请求的带宽）、交换能力和编码类型）的规范。

关于图 1，PCE 是一种控制平面服务，为控制平面应用程序提供服务。PCEP 可用作 PCE 之间的东西向接口，可充当域控制实体（服务和应用程序）。PCE 工作组正在指定扩展 [PCEActive]，允许活动 PCE 使用 PCEP、MPLS 或 GMPLS 标签交换路径 （Label Switched Paths，LSP） 进行控制，从而使其适用于 MPLS 和 GMPLS 交换机的 CPSI。

4.7、 BFD

双向转发检测 （Bidirectional Forwarding Detection，BFD） [RFC5880] 是一种 IETF 标准化网络协议，设计用于检测两个转发元素之间的路径故障，包括物理接口、子接口、数据链路以及转发引擎本身，潜在的非常低的延迟。BFD 可以在系统之间的任何类型的路径上提供低开销故障检测，包括直接物理链路、虚拟电路、隧道、MPLS LSP、多跳路由路径以及存在返回路径的单向链路。在转发引擎和控制引擎分离的情况下，它通常在系统转发引擎的某些组件中实现。

关于图 1，BFD 代理可以实现为控制平面服务或应用程序，该服务或应用程序将使用 CPSI 向转发平面发送/接收 BFD 数据包。但是，BFD 代理通常作为设备上的应用程序实现，并使用转发平面来发送/接收 BFD 数据包并相应地更新操作平面资源。监控或订阅资源变化的控制和管理平面的服务和应用程序可以通过它们各自的接口了解这些变化，并根据需要采取任何行动。

5、 总结

本文档是在对相关同行评审文献、RFC 系列和其他相关标准组织生成的文档进行彻底和详细分析后制定的。它已被更广泛的 SDN 社区公开审查，我们希望它可以在未来几年成为网络研究人员、工程师和从业人员的便捷工具。

我们通过对 SDN 层架构的术语的简要总结来结束本文档。通常，我们将网络元素视为资源的组合。每个网络元素都有一个转发平面 （forwarding plane，FP） 负责处理数据路径中的数据包，还有一个操作平面 （operational plane，OP） 负责管理设备的操作状态。网络元素中的资源由设备和资源抽象概念层 （Device and resource Abstraction Layer，DAL） 抽象概念，由属于控制或管理平面的服务或应用程序控制和管理。控制平面 （control plane，CP） 负责决定如何转发数据包。管理平面（management plane，MP）负责监控、配置和维护网络设备。服务接口由网络服务抽象概念层 （Network Services Abstraction Layer，NSAL） 抽象概念，其他网络应用程序或服务可以使用它们。本文档中介绍的分类法定义了不同的 SDN 平面、抽象概念层和接口；它旨在澄清 SDN 术语并建立整个 SDN 社区普遍接受的参考定义，而不管具体的实现选择。

6、 安全考虑

本文档不提出新的网络架构或协议，因此不会对互联网的安全产生任何影响。也就是说，安全性在网络中是最重要的。因此，在设计网络架构或运营部署时应充分考虑。SDN 中的安全性在文献中进行了讨论，例如，在 [SDNSecurity]、[SDNSecServ] 和 [SDNSecOF] 中。有关特定接口（例如 ForCES、I2RS、SNMP 或 NETCONF）的安全考虑在其各自的文档以及 [RFC7149] 中进行了说明。

7. 参考资料

[A4D05] Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan, J., and H. Zhang, "A Clean Slate 4D Approach to Network Control and Management", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 5, pp. 41-54, 2005.
[ALIEN] Parniewicz, D., Corin, R., Ogrodowczyk, L., Fard, M., Matias, J., Gerola, M., Fuentes, V., Toseef, U., Zaalouk, A., Belter, B., Jacob, E., and K. Pentikousis, "Design and Implementation of an OpenFlow Hardware Abstraction Layer", In Proceedings of the ACM SIGCOMM Workshop on Distributed Cloud Computing （DCC）, Chicago, Illinois, USA, pp. 71-76, doi 10.1145/2627566.2627577, August 2014.
[Beacon] Erickson, D., "The Beacon OpenFlow Controller", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 13-18, 2013.
[CAPBR] Brewer, E., "Towards Robust Distributed Systems", In Proceedings of the Symposium on Principles of Distributed Computing （PODC）, 2000.
[CAPFN] Panda, A., Scott, C., Ghodsi, A., Koponen, T., and S. Shenker, "CAP for Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 91-96, 2013.
[CAPGL] Gilbert, S. and N. Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services", ACM SIGACT News, Volume 33, Issue 2, pp. 51-59, 2002.
[CORBA] Object Management Group, "CORBA Version 3.3", November 2012, <http://www.omg.org/spec/CORBA/3.3/>.
[DIOPR] Denazis, S., Miki, K., Vicente, J., and A. Campbell, "Designing Interfaces for Open Programmable Routers", In "Active Networks", Springer Berlin Heidelberg, pp. 13-24, 1999.
[ESNet] Yu, J. and I. Al Ajarmeh, "An Empirical Study of the NETCONF Protocol", Sixth International Conference on Networking and Services, pp. 253-258, 2010.
[FCAPS] ITU, "Management Framework For Open Systems Interconnection （OSI） For CCITT Applications", ITU Recommendation X.700, September 1992, <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
[I2RSArch] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", Work in Progress, draft-ietf-i2rs-architecture-07, December 2014.
[I2RSInfo] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", Work in Progress, draft-ietf-i2rs-rib-info-model-04, December 2014.
[I2RSProb] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Problem Statement", Work in Progress, draft-ietf-i2rs-problem-statement-05, January 2015.
[ITUATM] ITU, "B-ISDN ATM Layer Specification", ITU Recommendation I.361, 1990, <http://www.itu.int/rec/T-REC-I.361-199902-I/en>.
[ITUSG11] ITU, "ITU-T Study Group 11: Protocols and test specifications", <http://www.itu.int/en/ITU-T/ studygroups/2013-2016/11/Pages/default.aspx>.
[ITUSG13] ITU, "ITU-T Study Group 13: Future networks including cloud computing, mobile and next-generation networks", <http://www.itu.int/en/ITU-T/studygroups/ 2013-2016/13/Pages/default.aspx>.
[ITUSS7] ITU, "Introduction to CCITT Signalling System No. 7", ITU Recommendation Q.700, 1993, <http://www.itu.int/rec/T-REC-Q.700-199303-I/e>.
[ITUY3300] ITU, "Framework of software-defined networking", ITU Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
[KANDOO] Yeganeh, S. and Y. Ganjali, "Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications", In Proceedings of the first ACM SIGCOMM workshop on Hot Topics in Software Defined Networks, pp. 19-24, 2012.
[NFVArch] ETSI, "Network Functions Virtualisation （NFV）: Architectural Framework", ETSI GS NFV 002, October 2013, <http://www.etsi.org/deliver/etsi_gs/ nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>.
[NOX] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and S. Shenker, "NOX: Towards an Operating System for Networks", ACM SIGCOMM Computer Communication Review, Volume 38, Issue 3, pp. 105-110, July 2008.
[NV09] Chowdhury, N. and R. Boutaba, "Network Virtualization: State of the Art and Research Challenges", Communications Magazine, IEEE, Volume 47, Issue 7, pp. 20-26, 2009.
[OF-CONFIG] Open Networking Foundation, "OpenFlow Management and Configuration Protocol （OF-Config 1.1.1）", March 2013, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/onf-specifications/ openflow-config/of-config-1-1-1.pdf>.
[OF08] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and J. Turner, "OpenFlow: Enabling Innovation in Campus Networks", ACM SIGCOMM Computer Communication Review, Volume 38, Issue 2, pp. 69-74, 2008.
[ONFArch] Open Networking Foundation, "SDN Architecture, Version 1", June 2014, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/technical-reports/ TR_SDN_ARCH_1.0_06062014.pdf>.
[OpenFlow] Open Networking Foundation, "The OpenFlow Switch Specification, Version 1.4.0", October 2013, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/onf-specifications/openflow/ openflow-spec-v1.4.0.pdf>.
[P1520] Biswas, J., Lazar, A., Huard, J., Lim, K., Mahjoub, S., Pau, L., Suzuki, M., Torstensson, S., Wang, W., and S. Weinstein, "The IEEE P1520 standards initiative for programmable network interfaces", IEEE Communications Magazine, Volume 36, Issue 10, pp. 64-70, 1998.
[PCEActive] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
[PENet] Hedstrom, B., Watwe, A., and S. Sakthidharan, "Protocol Efficiencies of NETCONF versus SNMP for Configuration Management Functions", Master's thesis, University of Colorado, 2011.
[PNSurvey99] Campbell, A., De Meer, H., Kounavis, M., Miki, K., Vicente, J., and D. Villela, "A Survey of Programmable Networks", ACM SIGCOMM Computer Communication Review, Volume 29, Issue 2, pp. 7-23, September 1992.
[Peregrine] Chiueh, D., Tu, C., Wang, Y., Wang, P., Li, K., and Y. Huang, "Peregrine: An All-Layer-2 Container Computer Network", In Proceedings of the 2012 IEEE 5th International Conference on Cloud Computing, pp. 686-693, 2012.
[PiNA] Day, J., "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, ISBN 0132252422, 2008.
[RCP] Caesar, M., Caldwell, D., Feamster, N., Rexford, J., Shaikh, A., and J. van der Merwe, "Design and Implementation of a Routing Control Platform", In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation Volume 2, pp. 15-28, 2005.
[REST] Fielding, Roy, "Chapter 5: Representational State Transfer （REST）", in Disseration "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC1953] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T., and G. Minshall, "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", RFC 1953, May 1996, <http://www.rfc-editor.org/info/rfc1953>.
[RFC2297] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Liaw, F., Lyon, T., and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 2.0", RFC 2297, March 1998, <http://www.rfc-editor.org/info/rfc2297>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 （SMIv2）", STD 58, RFC 2578, April 1999, <http://www.rfc-editor.org/info/rfc2578>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol （SNMP） Management Frameworks", STD 62, RFC 3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol （SNMP）", STD 62, RFC 3412, December 2002, <http://www.rfc-editor.org/info/rfc3412>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model （USM） for version 3 of the Simple Network Management Protocol （SNMPv3）", STD 62, RFC 3414, December 2002, <http://www.rfc-editor.org/info/rfc3414>.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol （SNMP）", STD 62, RFC 3417, December 2002, <http://www.rfc-editor.org/info/rfc3417>.
[RFC3418] Presuhn, R., "Management Information Base （MIB） for the Simple Network Management Protocol （SNMP）", STD 62, RFC 3418, December 2002, <http://www.rfc-editor.org/info/rfc3418>.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003, <http://www.rfc-editor.org/info/rfc3535>.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation （ForCES） Framework", RFC 3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 （BGP-4）", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element （PCE）-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element （PCE） Communication Protocol （PCEP）", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5743] Falk, A., "Definition of an Internet Research Task Force （IRTF） Document Stream", RFC 5743, December 2009, <http://www.rfc-editor.org/info/rfc5743>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation （ForCES） Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation （ForCES） Forwarding Element Model", RFC 5812, March 2010, <http://www.rfc-editor.org/info/rfc5812>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection （BFD）", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol （NETCONF）", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol （NETCONF）", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012, <http://www.rfc-editor.org/info/rfc6632>.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export （IPFIX） Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7047] Pfaff, B. and B. Davie, "The Open vSwitch Database Management Protocol", RFC 7047, December 2013, <http://www.rfc-editor.org/info/rfc7047>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014, <http://www.rfc-editor.org/info/rfc7149>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance （OAM） Tools", RFC 7276, June 2014, <http://www.rfc-editor.org/info/rfc7276>.
[RINA] Day, J., Matta, I., and K. Mattar, "Networking is IPC: A Guiding Principle to a Better Internet", In Proceedings of the 2008 ACM CoNEXT Conference, Article No. 67, 2008.
[RouteFlow] Nascimento, M., Rothenberg, C., Salvador, M., Correa, C., de Lucena, S., and M. Magalhaes, "Virtual Routers as a Service: The RouteFlow Approach Leveraging Software-Defined Networks", In Proceedings of the 6th International Conference on Future Internet Technologies, pp. 34-37, 2011.
[SDNACS] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S., and S. Uhlig, "Software-Defined Networking: A Comprehensive Survey", Networking and Internet Architecture （cs.NI）, arXiv:1406.0440, 2014.
[SDNHistory] Feamster, N., Rexford, J., and E. Zegura, "The Road to SDN: An Intellectual History of Programmable Networks", ACM Queue, Volume 11, Issue 12, 2013.
[SDNNFV] Haleplidis, E., Hadi Salim, J., Denazis, S., and O. Koufopavlou, "Towards a Network Abstraction Model for SDN", Journal of Network and Systems Management: Special Issue on Management of Software Defined Networks, pp. 1-19, 2014.
[SDNSecOF] Kloti, R., Kotronis, V., and P. Smith, "OpenFlow: A Security Analysis", 21st IEEE International Conference on Network Protocols （ICNP） pp. 1-6, October 2013.
[SDNSecServ] Scott-Hayward, S., O'Callaghan, G., and S. Sezer, "SDN Security: A Survey", In IEEE SDN for Future Networks and Services （SDN4FNS）, pp. 1-7, 2013.
[SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure and Dependable Software-Defined Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 55-60, 2013.
[SDNSurvey] Nunes, B., Mendonca, M., Nguyen, X., Obraczka, K., and T. Turletti, "A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks", IEEE Communications Surveys and Tutorials, DOI:10.1109/SURV.2014.012214.00180, 2014.
[SLTSDN] Jarraya, Y., Madi, T., and M. Debbabi, "A Survey and a Layered Taxonomy of Software-Defined Networking", IEEE Communications Surveys and Tutorials, Volume 16, Issue 4, pp. 1955-1980, 2014.
[SoftRouter] Lakshman, T., Nandagopal, T., Ramjee, R., Sabnani, K., and T. Woo, "The SoftRouter Architecture", In Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Networking, 2004.
[Tempest] Rooney, S., van der Merwe, J., Crosby, S., and I. Leslie, "The Tempest: A Framework for Safe, Resource Assured, Programmable Networks", Communications Magazine, IEEE, Volume 36, Issue 10, pp. 42-53, 1998.

致谢

作者要感谢 Salvatore Loreto 和 Sudhir Modali 在 SDNRG 邮件列表的初步讨论中做出的贡献以及他们针对特定文件的评论；他们帮助改进了这份文件。

此外，我们要感谢（按字母顺序）Shivleela Arlimatti、Roland Bless、Scott Brim、Alan Clark、Luis Miguel Contreras Murillo、Tim Copley、Linda Dunbar、Ken Gray、Deniz Gurkan、Dave Hood、Georgios Karagiannis、Bhumip Khasnabish、 Sriganesh Kini、Ramki Krishnan、Dirk Kutscher、Diego Lopez、Scott Mansfield、Pedro Martinez-Julia、David E. Mcdysan、Erik Nordmark、Carlos Pignataro、Robert Raszuk、Bless Roland、Francisco Javier Ros Munoz、Dimitri Staessens、Yakov Stein、Eve Var 、Stuart Venters、Russ White 和 Lee Young 在 IETF 88、IETF 89 和 IETF 90 以及 SDNRG 邮件列表上的批评性评论和讨论，我们在修订本文档时考虑了这些意见和讨论。

我们还要感谢（按字母顺序）Spencer Dawkins 和 Eliot Lear 对 IRSG 的审查，他们进一步完善了本文件。

最后，我们感谢 Nobo Akiya 对 BFD 部分的审阅、Julien Meuric 对 PCE 部分的审阅，以及 Adrian Farrel 和 Benoit Claise 对本文档的 IESG 审阅。

Kostas Pentikousis 得到 [ALIEN] 的支持，这是一项由欧洲共同体根据第七框架计划（资助协议编号 317880）部分资助的研究项目。此处表达的观点仅代表作者的观点。欧盟委员会对本文件中信息的任何使用不承担任何责任。

贡献者

作者要感谢（按字母顺序）以下人员为本文档的贡献者。他们都提供了使本文档更加完整的文本、指针和注释：

** Daniel King 提供了与 PCEP 相关的文本。

** Scott Mansfield 了解有关 ITU 当前在 SDN 方面的工作的信息。

** Yaakov Stein 提供了与 CAP 定理和 SDO 相关信息相关的文本。

** Russ White 关于控制、管理和应用定义的文本建议。