Internet Research Task Force (IRTF) E. Haleplidis, Ed.
Request for Comments: 7426 University of Patras
Category: Informational K. Pentikousis, Ed.
ISSN: 2070-1721 EICT
S. Denazis
University of Patras
J. Hadi Salim
Mojatatu Networks
D. Meyer
Brocade
O. Koufopavlou
University of Patras
January 2015
Internet Research Task Force (IRTF) E. Haleplidis, Ed.
Request for Comments: 7426 University of Patras
Category: Informational K. Pentikousis, Ed.
ISSN: 2070-1721 EICT
S. Denazis
University of Patras
J. Hadi Salim
Mojatatu Networks
D. Meyer
Brocade
O. Koufopavlou
University of Patras
January 2015
Software-Defined Networking (SDN): Layers and Architecture Terminology
软件定义网络（SDN）：层和体系结构术语
Abstract
摘要
Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.
软件定义网络（SDN）是指一种新的网络可编程性方法，即通过开放接口动态初始化、控制、更改和管理网络行为的能力。SDN通过引入数据转发平面的抽象来强调软件在网络运行中的作用，并通过这样做将其与控制平面分离。经验已经表明，这种分离可以加快两个层面的创新周期。然而，对于SDN到底是什么、SDN体系结构中的层结构是什么以及层之间如何交互，人们越来越困惑。本文件是IRTF软件定义网络研究小组（SDNRG）的产品，解决了这些问题，并根据相关同行评审文献、RFC系列和其他标准组织的相关文件为SDN研究社区提供了简明参考。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Software-Defined Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究任务组（IRTF）软件定义网络研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7426.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7426.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. SDN Layers and Architecture .....................................7
3.1. Overview ...................................................9
3.2. Network Devices ...........................................12
3.3. Control Plane .............................................13
3.4. Management Plane ..........................................14
3.5. Discussion of Control and Management Planes ...............16
3.5.1. Timescale ..........................................16
3.5.2. Persistence ........................................16
3.5.3. Locality ...........................................16
3.5.4. CAP Theorem Insights ...............................17
3.6. Network Services Abstraction Layer ........................18
3.7. Application Plane .........................................19
4. SDN Model View .................................................19
4.1. ForCES ....................................................19
4.2. NETCONF/YANG ..............................................20
4.3. OpenFlow ..................................................21
4.4. Interface to the Routing System ...........................21
4.5. SNMP ......................................................22
4.6. PCEP ......................................................23
4.7. BFD .......................................................23
5. Summary ........................................................24
6. Security Considerations ........................................24
7. Informative References .........................................25
Acknowledgements ..................................................33
Contributors ......................................................34
Authors' Addresses ................................................34
1. Introduction ....................................................4
2. Terminology .....................................................5
3. SDN Layers and Architecture .....................................7
3.1. Overview ...................................................9
3.2. Network Devices ...........................................12
3.3. Control Plane .............................................13
3.4. Management Plane ..........................................14
3.5. Discussion of Control and Management Planes ...............16
3.5.1. Timescale ..........................................16
3.5.2. Persistence ........................................16
3.5.3. Locality ...........................................16
3.5.4. CAP Theorem Insights ...............................17
3.6. Network Services Abstraction Layer ........................18
3.7. Application Plane .........................................19
4. SDN Model View .................................................19
4.1. ForCES ....................................................19
4.2. NETCONF/YANG ..............................................20
4.3. OpenFlow ..................................................21
4.4. Interface to the Routing System ...........................21
4.5. SNMP ......................................................22
4.6. PCEP ......................................................23
4.7. BFD .......................................................23
5. Summary ........................................................24
6. Security Considerations ........................................24
7. Informative References .........................................25
Acknowledgements ..................................................33
Contributors ......................................................34
Authors' Addresses ................................................34
"Software-Defined Networking (SDN)" is a term of the programmable networks paradigm [PNSurvey99] [OF08]. In short, SDN refers to the ability of software applications to program individual network devices dynamically and therefore control the behavior of the network as a whole [NV09]. Boucadair and Jacquenet [RFC7149] point out that SDN is a set of techniques used to facilitate the design, delivery, and operation of network services in a deterministic, dynamic, and scalable manner.
“软件定义网络（SDN）”是可编程网络范例[PNSurvey99][OF08]的一个术语。简而言之，SDN是指软件应用程序动态编程单个网络设备的能力，从而控制整个网络的行为[NV09]。Boucadair和Jacquenet[RFC7149]指出，SDN是一组技术，用于以确定性、动态和可扩展的方式促进网络服务的设计、交付和操作。
A key element in SDN is the introduction of an abstraction between the (traditional) forwarding and control planes in order to separate them and provide applications with the means necessary to programmatically control the network. The goal is to leverage this separation, and the associated programmability, in order to reduce complexity and enable faster innovation at both planes [A4D05].
SDN中的一个关键元素是在（传统）转发和控制平面之间引入抽象，以便将它们分开，并为应用程序提供以编程方式控制网络所需的手段。目标是利用这种分离和相关的可编程性，以降低复杂性并在两个层面实现更快的创新[A4D05]。
The historical evolution of the research and development area of programmable networks is reviewed in detail in [SDNHistory] [SDNSurvey], starting with efforts dating back to the 1980s. As documented in [SDNHistory], many of the ideas, concepts, and concerns are applicable to the latest research and development in SDN (and SDN standardization) and have been under extensive investigation and discussion in the research community for quite some time. For example, Rooney, et al. [Tempest] discuss how to allow third-party access to the network without jeopardizing network integrity or how to accommodate legacy networking solutions in their (then new) programmable environment. Further, the concept of separating the control and forwarding planes, which is prominent in SDN, has been extensively discussed even prior to 1998 [Tempest] [P1520] in SS7 networks [ITUSS7], Ipsilon Flow Switching [RFC1953] [RFC2297], and ATM [ITUATM].
[SDNHistory][SDNSurvey]详细回顾了可编程网络研究和开发领域的历史演变，从20世纪80年代开始。如[SDN历史]所述，许多想法、概念和关注点适用于SDN（和SDN标准化）的最新研究和开发，并在研究界进行了相当长一段时间的广泛调查和讨论。例如，Rooney等人[Tempest]讨论了如何允许第三方访问网络而不损害网络完整性，或者如何在其（当时是新的）可编程环境中容纳传统网络解决方案。此外，在SDN中突出的分离控制和转发平面的概念甚至在1998年[Tempest][P1520]之前在SS7网络[ITUS7]、Ipsilon流交换[RFC1953][RFC2297]和ATM[ITUATM]中已被广泛讨论。
SDN research often focuses on varying aspects of programmability, and we are frequently confronted with conflicting points of view regarding what exactly SDN is. For instance, we find that for various reasons (e.g., work focusing on one domain and therefore not necessarily applicable as-is to other domains), certain well-accepted definitions do not correlate well with each other. For example, both OpenFlow [OpenFlow] and the Network Configuration Protocol (NETCONF) [RFC6241] have been characterized as SDN interfaces, but they refer to control and management, respectively.
SDN研究通常关注可编程性的不同方面，我们经常遇到关于SDN到底是什么的相互冲突的观点。例如，我们发现，由于各种原因（例如，工作集中在一个领域，因此不一定适用于其他领域），某些公认的定义彼此之间没有很好的相关性。例如，OpenFlow[OpenFlow]和网络配置协议（NETCONF）[RFC6241]都被描述为SDN接口，但它们分别涉及控制和管理。
This motivates us to consolidate the definitions of SDN in the literature and correlate them with earlier work at the IETF and the research community. Of particular interest is, for example, to determine which layers comprise the SDN architecture and which
这促使我们在文献中整合SDN的定义，并将其与IETF和研究社区的早期工作相关联。特别感兴趣的是，例如，确定哪些层构成SDN架构，哪些层构成SDN架构
interfaces and their corresponding attributes are best suited to be used between them. As such, the aim of this document is not to standardize any particular layer or interface but rather to provide a concise reference that reflects current approaches regarding the SDN layer architecture. We expect that this document would be useful to upcoming work in SDNRG as well as future discussions within the SDN community as a whole.
接口及其对应的属性最适合在它们之间使用。因此，本文件的目的不是标准化任何特定的层或接口，而是提供一个简明的参考，反映SDN层架构的当前方法。我们希望本文件将有助于SDNRG即将开展的工作以及整个SDN社区内的未来讨论。
This document addresses the work item in the SDNRG charter titled "Survey of SDN approaches and Taxonomies", fostering better understanding of prominent SDN technologies in a technology-impartial and business-agnostic manner but does not constitute a new IETF standard. It is meant as a common base for further discussion. As such, we do not make any value statements nor discuss the applicability of any of the frameworks examined in this document for any particular purpose. Instead, we document their characteristics and attributes and classify them, thus providing a taxonomy. This document does not intend to provide an exhaustive list of SDN research issues; interested readers should consider reviewing [SLTSDN] and [SDNACS]. In particular, Jarraya, et al. [SLTSDN] provide an overview of SDN-related research topics, e.g., control partitioning, which is related to the Consistency, Availability and Partitioning (CAP) theorem discussed in Section 3.5.4.
本文件阐述了SDNRG章程中题为“SDN方法和分类调查”的工作项目，以技术公正和业务不可知的方式促进对重要SDN技术的更好理解，但不构成新的IETF标准。这是作为进一步讨论的共同基础。因此，我们不作任何价值陈述，也不讨论本文件中任何框架在任何特定目的下的适用性。相反，我们记录它们的特征和属性并对它们进行分类，从而提供分类。本文件不打算提供SDN研究问题的详尽清单；感兴趣的读者应该考虑复习[SLTSDDN]和[SDCNAC]。特别是，Jarraya等人[SLTSDN]概述了SDN相关的研究主题，例如控制分区，这与第3.5.4节中讨论的一致性、可用性和分区（CAP）定理有关。
This document has been extensively reviewed, discussed, and commented by the vast majority of SDNRG members, a community that certainly exceeds 100 individuals. It is the consensus of SDNRG that this document should be published in the IRTF stream of the RFC series [RFC5743].
绝大多数SDNRG成员对本文件进行了广泛的审查、讨论和评论，该社区的人数肯定超过了100人。SDNRG一致认为，本文件应在RFC系列[RFC5743]的IRTF流中发布。
The remainder of this document is organized as follows. Section 2 explains the terminology used in this document. Section 3 introduces a high-level overview of current SDN architecture abstractions. Finally, Section 4 discusses how the SDN layer architecture relates to prominent SDN-enabling technologies.
本文件的其余部分组织如下。第2节解释了本文件中使用的术语。第3节介绍了当前SDN体系结构抽象的高级概述。最后，第4节讨论了SDN层架构如何与突出的SDN支持技术相关联。
This document uses the following terms:
本文件使用以下术语：
o Software-Defined Networking (SDN) - A programmable networks approach that supports the separation of control and forwarding planes via standardized interfaces.
o 软件定义网络（SDN）-一种可编程网络方法，支持通过标准化接口分离控制和转发平面。
o Resource - A physical or virtual component available within a system. Resources can be very simple or fine-grained (e.g., a port or a queue) or complex, comprised of multiple resources (e.g., a network device).
o 资源-系统中可用的物理或虚拟组件。资源可以是非常简单或细粒度的（例如，端口或队列）或复杂的，由多个资源（例如，网络设备）组成。
o Network Device - A device that performs one or more network operations related to packet manipulation and forwarding. This reference model makes no distinction whether a network device is physical or virtual. A device can also be considered as a container for resources and can be a resource in itself.
o 网络设备-执行与数据包操作和转发相关的一个或多个网络操作的设备。此参考模型不区分网络设备是物理设备还是虚拟设备。设备也可以被视为资源的容器，其本身也可以是资源。
o Interface - A point of interaction between two entities. When the entities are placed at different locations, the interface is usually implemented through a network protocol. If the entities are collocated in the same physical location, the interface can be implemented using a software application programming interface (API), inter-process communication (IPC), or a network protocol.
o 接口-两个实体之间的交互点。当实体放置在不同的位置时，接口通常通过网络协议实现。如果实体并置在同一物理位置，则可以使用软件应用程序编程接口（API）、进程间通信（IPC）或网络协议来实现该接口。
o Application (App) - An application in the context of SDN is a piece of software that utilizes underlying services to perform a function. Application operation can be parameterized, for example, by passing certain arguments at call time, but it is meant to be a standalone piece of software; an App does not offer any interfaces to other applications or services.
o 应用程序（App）-SDN上下文中的应用程序是一种利用底层服务执行功能的软件。应用程序操作可以参数化，例如，通过在调用时传递某些参数，但它是一个独立的软件；应用程序不提供与其他应用程序或服务的任何接口。
o Service - A piece of software that performs one or more functions and provides one or more APIs to applications or other services of the same or different layers to make use of said functions and returns one or more results. Services can be combined with other services, or called in a certain serialized manner, to create a new service.
o 服务-执行一个或多个功能并向相同或不同层的应用程序或其他服务提供一个或多个API以使用所述功能并返回一个或多个结果的软件。服务可以与其他服务组合，或以某种序列化方式调用，以创建新服务。
o Forwarding Plane (FP) - The collection of resources across all network devices responsible for forwarding traffic.
o 转发平面（FP）-负责转发流量的所有网络设备上的资源集合。
o Operational Plane (OP) - The collection of resources responsible for managing the overall operation of individual network devices.
o 操作平面（OP）-负责管理单个网络设备整体操作的资源集合。
o Control Plane (CP) - The collection of functions responsible for controlling one or more network devices. CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane.
o 控制平面（CP）-负责控制一个或多个网络设备的功能集合。CP指示网络设备如何处理和转发数据包。控制平面主要与转发平面交互，并在较小程度上与操作平面交互。
o Management Plane (MP) - The collection of functions responsible for monitoring, configuring, and maintaining one or more network devices or parts of network devices. The management plane is mostly related to the operational plane (it is related less to the forwarding plane).
o 管理平面（MP）-负责监视、配置和维护一个或多个网络设备或网络设备的一部分的功能集合。管理平面主要与操作平面相关（与转发平面的关系较小）。
o Application Plane - The collection of applications and services that program network behavior.
o 应用程序平面-对网络行为进行编程的应用程序和服务的集合。
o Device and resource Abstraction Layer (DAL) - The device's resource abstraction layer based on one or more models. If it is a physical device, it may be referred to as the Hardware Abstraction Layer (HAL). DAL provides a uniform point of reference for the device's forwarding- and operational-plane resources.
o 设备和资源抽象层（DAL）-基于一个或多个模型的设备资源抽象层。如果它是一个物理设备，它可以被称为硬件抽象层（HAL）。DAL为设备的转发和操作平面资源提供统一的参考点。
o Control Abstraction Layer (CAL) - The control plane's abstraction layer. CAL provides access to the Control-Plane Southbound Interface.
o 控制抽象层（CAL）-控制平面的抽象层。CAL提供对控制平面南行接口的访问。
o Management Abstraction Layer (MAL) - The management plane's abstraction layer. MAL provides access to the Management-Plane Southbound Interface.
o 管理抽象层（MAL）-管理平面的抽象层。MAL提供对管理平面南行接口的访问。
o Network Services Abstraction Layer (NSAL) - Provides service abstractions that can be used by applications and services.
o 网络服务抽象层（NSAL）-提供可由应用程序和服务使用的服务抽象。
Figure 1 summarizes the SDN architecture abstractions in the form of a detailed, high-level schematic. Note that in a particular implementation, planes can be collocated with other planes or can be physically separated, as we discuss below.
图1以详细的高级示意图的形式总结了SDN体系结构抽象。请注意，在一个特定的实现中，平面可以与其他平面并置，也可以物理分离，我们将在下面讨论。
SDN is based on the concept of separation between a controlled entity and a controller entity. The controller manipulates the controlled entity via an interface. Interfaces, when local, are mostly API invocations through some library or system call. However, such interfaces may be extended via some protocol definition, which may use local inter-process communication (IPC) or a protocol that could also act remotely; the protocol may be defined as an open standard or in a proprietary manner.
SDN基于受控实体和控制器实体之间的分离概念。控制器通过接口操纵受控实体。本地接口主要是通过一些库或系统调用进行的API调用。然而，这些接口可以通过一些协议定义进行扩展，这些协议定义可以使用本地进程间通信（IPC）或也可以远程操作的协议；协议可定义为开放标准或专有方式。
Day [PiNA] explores the use of IPC as the mainstay for the definition of recursive network architectures with varying degrees of scope and range of operation. The Recursive InterNetwork Architecture [RINA] outlines a recursive network architecture based on IPC that capitalizes on repeating patterns and structures. This document does not propose a new architecture -- we simply document previous work through a taxonomy. Although recursion is out of the scope of this work, Figure 1 illustrates a hierarchical model in which layers can be stacked on top of each other and employed recursively as needed.
Day[PiNA]探讨了IPC作为定义递归网络体系结构的主体的使用，该结构具有不同程度的范围和操作范围。递归网络体系结构[RINA]概述了一种基于IPC的递归网络体系结构，它利用重复模式和结构。本文档并没有提出一种新的体系结构——我们只是通过分类法来记录以前的工作。尽管递归不在本工作的范围内，但图1展示了一个分层模型，在该模型中，层可以相互堆叠，并根据需要递归使用。
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
Figure 1: SDN Layer Architecture
图1:SDN层架构
This document follows a network-device-centric approach: control mostly refers to the device packet-handling capability, while management typically refers to aspects of the overall device operation. We view a network device as a complex resource that contains and is part of multiple resources similar to [DIOPR]. Resources can be simple, single components of a network device, for example, a port or a queue of the device, and can also be aggregated into complex resources, for example, a network card or a complete network device.
本文档遵循以网络设备为中心的方法：控制主要指设备数据包处理能力，而管理通常指整个设备操作的各个方面。我们将网络设备视为一个复杂的资源，它包含多个类似于[DIOPR]的资源，并且是多个资源的一部分。资源可以是网络设备的简单、单一组件，例如设备的端口或队列，也可以聚合为复杂资源，例如网卡或完整的网络设备。
The reader should keep in mind that we make no distinction between "physical" and "virtual" resources or "hardware" and "software" realizations in this document, as we do not delve into implementation or performance aspects. In other words, a resource can be implemented fully in hardware, fully in software, or any hybrid combination in between. Further, we do not distinguish whether a resource is implemented as an overlay or as a part/component of some other device. In general, network device software can run on so-called "bare metal" or on a virtualized substrate. Finally, this document does not discuss how resources are allocated, orchestrated, and released. Indeed, orchestration is out of the scope of this document.
读者应记住，在本文档中，我们不区分“物理”和“虚拟”资源或“硬件”和“软件”实现，因为我们不深入研究实现或性能方面。换句话说，资源可以完全在硬件、软件或两者之间的任何混合组合中实现。此外，我们不区分资源是作为覆盖实现的，还是作为其他设备的一部分/组件实现的。一般来说，网络设备软件可以在所谓的“裸机”或虚拟化基板上运行。最后，本文不讨论如何分配、编排和发布资源。事实上，编排超出了本文档的范围。
SDN spans multiple planes as illustrated in Figure 1. Starting from the bottom part of the figure and moving towards the upper part, we identify the following planes:
SDN跨越多个平面，如图1所示。从图的底部开始，向上部移动，我们确定以下平面：
o Forwarding Plane - Responsible for handling packets in the data path based on the instructions received from the control plane. Actions of the forwarding plane include, but are not limited to, forwarding, dropping, and changing packets. The forwarding plane is usually the termination point for control-plane services and applications. The forwarding plane can contain forwarding resources such as classifiers. The forwarding plane is also widely referred to as the "data plane" or the "data path".
o 转发平面-负责根据从控制平面接收的指令处理数据路径中的数据包。转发平面的动作包括但不限于转发、丢弃和改变分组。转发平面通常是控制平面服务和应用程序的终止点。转发平面可以包含诸如分类器之类的转发资源。转发平面也被广泛地称为“数据平面”或“数据路径”。
o Operational Plane - Responsible for managing the operational state of the network device, e.g., whether the device is active or inactive, the number of ports available, the status of each port, and so on. The operational plane is usually the termination point for management-plane services and applications. The operational plane relates to network device resources such as ports, memory, and so on. We note that some participants of the IRTF SDNRG have a different opinion in regards to the definition of the operational plane. That is, one can argue that the operational plane does not constitute a "plane" per se, but it is, in
o 操作平面-负责管理网络设备的操作状态，例如，设备是否处于活动状态、可用端口数、每个端口的状态等。操作平面通常是管理平面服务和应用程序的终止点。操作平面涉及网络设备资源，如端口、内存等。我们注意到，IRTF SDNRG的一些参与者对作战飞机的定义持有不同意见。也就是说，人们可以说，作战飞机本身并不构成“飞机”，但实际上是这样的
practice, an amalgamation of functions on the forwarding plane. For others, however, a "plane" allows one to distinguish between different areas of operations; therefore, the operational plane is included as a "plane" in Figure 1. We have adopted this latter view in this document.
实践中，转发平面上的功能合并。然而，对于其他人来说，“飞机”允许人们区分不同的作战区域；因此，在图1中，操作平面包括为“平面”。我们在本文件中采纳了后一种观点。
o Control Plane - Responsible for making decisions on how packets should be forwarded by one or more network devices and pushing such decisions down to the network devices for execution. The control plane usually focuses mostly on the forwarding plane and less on the operational plane of the device. The control plane may be interested in operational-plane information, which could include, for instance, the current state of a particular port or its capabilities. The control plane's main job is to fine-tune the forwarding tables that reside in the forwarding plane, based on the network topology or external service requests.
o 控制平面-负责决定一个或多个网络设备应如何转发数据包，并将此类决定下推至网络设备执行。控制平面通常主要关注转发平面，较少关注设备的操作平面。控制平面可能对操作平面信息感兴趣，操作平面信息可以包括例如特定端口的当前状态或其能力。控制平面的主要工作是根据网络拓扑或外部服务请求微调驻留在转发平面中的转发表。
o Management Plane - Responsible for monitoring, configuring, and maintaining network devices, e.g., making decisions regarding the state of a network device. The management plane usually focuses mostly on the operational plane of the device and less on the forwarding plane. The management plane may be used to configure the forwarding plane, but it does so infrequently and through a more wholesale approach than the control plane. For instance, the management plane may set up all or part of the forwarding rules at once, although such action would be expected to be taken sparingly.
o 管理平面-负责监控、配置和维护网络设备，例如，就网络设备的状态做出决策。管理平面通常主要关注设备的操作平面，而较少关注转发平面。管理平面可用于配置转发平面，但它很少这样做，并且通过比控制平面更全面的方法。例如，管理层可以一次设置全部或部分转发规则，尽管这样的操作预计会谨慎进行。
o Application Plane - The plane where applications and services that define network behavior reside. Applications that directly (or primarily) support the operation of the forwarding plane (such as routing processes within the control plane) are not considered part of the application plane. Note that applications may be implemented in a modular and distributed fashion and, therefore, can often span multiple planes in Figure 1.
o 应用程序平面-定义网络行为的应用程序和服务所在的平面。直接（或主要）支持转发平面操作的应用程序（如控制平面内的路由过程）不被视为应用程序平面的一部分。请注意，应用程序可以以模块化和分布式方式实现，因此，通常可以跨越图1中的多个平面。
[RFC7276] has defined the data, control, and management planes in terms of Operations, Administration, and Maintenance (OAM). This document attempts to broaden the terms defined in [RFC7276] in order to reflect all aspects of an SDN architecture.
[RFC7276]定义了操作、管理和维护（OAM）方面的数据、控制和管理平面。本文件试图扩展[RFC7276]中定义的术语，以反映SDN体系结构的所有方面。
All planes mentioned above are connected via interfaces (indicated with "Y" in Figure 1. An interface may take multiple roles depending on whether the connected planes reside on the same (physical or virtual) device. If the respective planes are designed so that they do not have to reside in the same device, then the interface can only take the form of a protocol. If the planes are collocated on the
上面提到的所有平面都是通过接口连接的（图1中用“Y”表示）。一个接口可以扮演多个角色，这取决于连接的平面是否位于同一个平面上（物理或虚拟）设备。如果相应的平面设计为不必驻留在同一设备中，则接口只能采用协议的形式。如果平面并置在
same device, then the interface could be implemented via an open/ proprietary protocol, an open/proprietary software inter-process communication API, or operating system kernel system calls.
同一设备，则该接口可以通过开放/专有协议、开放/专有软件进程间通信API或操作系统内核系统调用来实现。
Applications, i.e., software programs that perform specific computations that consume services without providing access to other applications, can be implemented natively inside a plane or can span multiple planes. For instance, applications or services can span both the control and management planes and thus be able to use both the Control-Plane Southbound Interface (CPSI) and Management-Plane Southbound Interface (MPSI), although this is only implicitly illustrated in Figure 1. An example of such a case would be an application that uses both [OpenFlow] and [OF-CONFIG].
应用程序，即执行特定计算的软件程序，在不提供对其他应用程序的访问的情况下使用服务，可以在一个平面内本机实现，也可以跨越多个平面。例如，应用程序或服务可以跨越控制平面和管理平面，因此可以同时使用控制平面南向接口（CPSI）和管理平面南向接口（MPSI），尽管这仅在图1中进行了隐式说明。这种情况的一个例子是同时使用[OpenFlow]和[of-CONFIG]的应用程序。
Services, i.e., software programs that provide APIs to other applications or services, can also be natively implemented in specific planes. Services that span multiple planes belong to the application plane as well.
服务，即为其他应用程序或服务提供API的软件程序，也可以在特定平面上本机实现。跨多个平面的服务也属于应用程序平面。
While not shown explicitly in Figure 1, services, applications, and entire planes can be placed in a recursive manner, thus providing overlay semantics to the model. For example, application-plane services can be provided to other applications or services through NSAL. Additional examples include virtual resources that are realized on top of a physical resources and hierarchical control-plane controllers [KANDOO].
虽然图1中没有明确显示，但服务、应用程序和整个平面可以以递归方式放置，从而为模型提供覆盖语义。例如，应用程序平面服务可以通过NSAL提供给其他应用程序或服务。其他示例包括在物理资源和分层控制平面控制器[KANDOO]之上实现的虚拟资源。
Note that the focus in this document is, of course, on the north/ south communication between entities in different planes. But this, clearly, does not exclude entity communication within any one plane.
请注意，本文档的重点当然是不同平面中实体之间的北/南通信。但这显然并不排除任何一个平面内的实体通信。
It must be noted, however, that in Figure 1, we present an abstract view of the various planes, which is devoid of implementation details. Many implementations in the past have opted for placing the management plane on top of the control plane. This can be interpreted as having the control plane acting as a service to the management plane. Further, in many networks, especially in Internet routers and Ethernet switches, the control plane has been usually implemented as tightly coupled with the network device. When taken as a whole, the control plane has been distributed network-wide. On the other hand, the management plane has been traditionally centralized and has been responsible for managing the control plane and the devices. However, with the adoption of SDN principles, this distinction is no longer so clear-cut.
然而，必须注意的是，在图1中，我们展示了各种平面的抽象视图，其中没有实现细节。过去的许多实现都选择将管理平面置于控制平面之上。这可以解释为使控制平面充当管理平面的服务。此外，在许多网络中，特别是在因特网路由器和以太网交换机中，控制平面通常被实现为与网络设备紧密耦合。作为一个整体，控制平面分布在网络范围内。另一方面，管理平面传统上是集中的，负责管理控制平面和设备。然而，随着SDN原则的采用，这一区别不再如此明确。
Additionally, this document considers four abstraction layers:
此外，本文档考虑了四个抽象层：
o The Device and resource Abstraction Layer (DAL) abstracts the resources of the device's forwarding and operational planes to the control and management planes. Variations of DAL may abstract both planes or either of the two and may abstract any plane of the device to either the control or management plane.
o 设备和资源抽象层（DAL）将设备的转发和操作平面的资源抽象到控制和管理平面。DAL的变体可以抽象两个平面或两个平面中的任一个，并且可以将设备的任何平面抽象到控制平面或管理平面。
o The Control Abstraction Layer (CAL) abstracts the Control-Plane Southbound Interface and the DAL from the applications and services of the control plane.
o 控制抽象层（CAL）从控制平面的应用程序和服务中抽象出控制平面南向接口和DAL。
o The Management Abstraction Layer (MAL) abstracts the Management-Plane Southbound Interface and the DAL from the applications and services of the management plane.
o 管理抽象层（MAL）从管理平面的应用程序和服务中抽象出管理平面南向接口和DAL。
o The Network Services Abstraction Layer (NSAL) provides service abstractions for use by applications and other services.
o 网络服务抽象层（NSAL）提供应用程序和其他服务使用的服务抽象。
At the time of this writing, SDN-related activities have begun in other SDOs. For example, at the ITU, work on architectural [ITUSG13] and signaling requirements and protocols [ITUSG11] has commenced, but the respective study groups have yet to publish their documents, with the exception of [ITUY3300]. The views presented in [ITUY3300] as well as in [ONFArch] are well aligned with this document.
在撰写本文时，与SDN相关的活动已经在其他SDO中开始。例如，在国际电联，关于体系结构[ITUSG13]和信令要求与协议[ITUSG11]的工作已经开始，但除了[ITUY3300]之外，各研究小组尚未公布其文件。[ITUY3300]和[ONFArch]中提出的观点与本文件完全一致。
A network device is an entity that receives packets on its ports and performs one or more network functions on them. For example, the network device could forward a received packet, drop it, alter the packet header (or payload), forward the packet, and so on. A network device is an aggregation of multiple resources such as ports, CPU, memory, and queues. Resources are either simple or can be aggregated to form complex resources that can be viewed as one resource. The network device is in itself a complex resource. Examples of network devices include switches and routers. Additional examples include network elements that may operate at a layer above IP (such as firewalls, load balancers, and video transcoders) or below IP (such as Layer 2 switches and optical or microwave network elements).
网络设备是在其端口上接收数据包并在其上执行一个或多个网络功能的实体。例如，网络设备可以转发接收到的分组、丢弃它、改变分组报头（或有效载荷）、转发分组，等等。网络设备是多个资源（如端口、CPU、内存和队列）的集合。资源可以是简单的，也可以聚合起来形成复杂的资源，这些资源可以看作一个资源。网络设备本身就是一种复杂的资源。网络设备的示例包括交换机和路由器。其他示例包括可在IP之上的层（例如防火墙、负载均衡器和视频转码器）或IP之下的层（例如第2层交换机和光学或微波网络元件）上操作的网络元件。
Network devices can be implemented in hardware or software and can be either physical or virtual. As has already been mentioned before, this document makes no such distinction. Each network device has a presence in a forwarding plane and an operational plane.
网络设备可以用硬件或软件实现，可以是物理的，也可以是虚拟的。如前所述，本文件不作这种区分。每个网络设备在转发平面和操作平面中存在。
The forwarding plane, commonly referred to as the "data path", is responsible for handling and forwarding packets. The forwarding plane provides switching, routing, packet transformation, and filtering functions. Resources of the forwarding plane include but are not limited to filters, meters, markers, and classifiers.
转发平面（通常称为“数据路径”）负责处理和转发数据包。转发平面提供交换、路由、分组转换和过滤功能。转发平面的资源包括但不限于过滤器、仪表、标记和分类器。
The operational plane is responsible for the operational state of the network device, for instance, with respect to status of network ports and interfaces. Operational-plane resources include, but are not limited to, memory, CPU, ports, interfaces, and queues.
操作平面负责网络设备的操作状态，例如，关于网络端口和接口的状态。操作平面资源包括但不限于内存、CPU、端口、接口和队列。
The forwarding and the operational planes are exposed via the Device and resource Abstraction Layer (DAL), which may be expressed by one or more abstraction models. Examples of forwarding-plane abstraction models are Forwarding and Control Element Separation (ForCES) [RFC5812], OpenFlow [OpenFlow], YANG model [RFC6020], and SNMP MIBs [RFC3418]. Examples of the operational-plane abstraction model include the ForCES model [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418].
转发和操作平面通过设备和资源抽象层（DAL）公开，设备和资源抽象层可以由一个或多个抽象模型表示。转发平面抽象模型的示例包括转发和控制元素分离（ForCES）[RFC5812]、OpenFlow[OpenFlow]、YANG模型[RFC6020]和SNMP MIB[RFC3418]。作战平面抽象模型的示例包括部队模型[RFC5812]、YANG模型[RFC6020]和SNMP MIB[RFC3418]。
Note that applications can also reside in a network device. Examples of such applications include event monitoring and handling (offloading) topology discovery or ARP [RFC0826] in the device itself instead of forwarding such traffic to the control plane.
请注意，应用程序也可以驻留在网络设备中。此类应用的示例包括设备本身中的事件监视和处理（卸载）拓扑发现或ARP[RFC0826]，而不是将此类流量转发到控制平面。
The control plane is usually distributed and is responsible mainly for the configuration of the forwarding plane using a Control-Plane Southbound Interface (CPSI) with DAL as a point of reference. CP is responsible for instructing FP about how to handle network packets.
控制平面通常是分布式的，主要负责使用以DAL为参考点的控制平面南向接口（CPSI）配置转发平面。CP负责指导FP如何处理网络数据包。
Communication between control-plane entities, colloquially referred to as the "east-west" interface, is usually implemented through gateway protocols such as BGP [RFC4271] or other protocols such as the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440]. These corresponding protocol messages are usually exchanged in-band and subsequently redirected by the forwarding plane to the control plane for further processing. Examples in this category include [RCP], [SoftRouter], and [RouteFlow].
控制平面实体之间的通信，通俗地称为“东西”接口，通常通过网关协议（如BGP[RFC4271]）或其他协议（如路径计算元素（PCE）通信协议（PCEP）[RFC5440]）实现。这些相应的协议消息通常在频带内交换，随后由转发平面重定向到控制平面以进行进一步处理。此类示例包括[RCP]、[SoftRouter]和[RouteFlow]。
Control-plane functionalities usually include:
控制平面功能通常包括：
o Topology discovery and maintenance
o 拓扑发现与维护
o Packet route selection and instantiation
o 分组路由选择与实例化
o Path failover mechanisms
o 路径故障切换机制
The CPSI is usually defined with the following characteristics:
CPSI通常具有以下特征：
o time-critical interface that requires low latency and sometimes high bandwidth in order to perform many operations in short order
o 时间关键型接口，需要低延迟，有时需要高带宽，以便在短时间内执行许多操作
o oriented towards wire efficiency and device representation instead of human readability
o 面向电线效率和设备表示，而不是人类可读性
Examples include fast- and high-frequency of flow or table updates, high throughput, and robustness for packet handling and events.
示例包括流或表更新的快速和高频率、高吞吐量以及数据包处理和事件的健壮性。
CPSI can be implemented using a protocol, an API, or even inter-process communication. If the control plane and the network device are not collocated, then this interface is certainly a protocol. Examples of CPSIs are ForCES [RFC5810] and the OpenFlow protocol [OpenFlow].
CPSI可以使用协议、API甚至进程间通信来实现。如果控制平面和网络设备没有并置，那么这个接口肯定是一个协议。CPSI的示例包括ForCES[RFC5810]和OpenFlow协议[OpenFlow]。
The Control Abstraction Layer (CAL) provides access to control applications and services to various CPSIs. The control plane may support more than one CPSI.
控制抽象层（CAL）提供对各种CPSI的控制应用程序和服务的访问。控制平面可支持多个CPSI。
Control applications can use CAL to control a network device without providing any service to upper layers. Examples include applications that perform control functions, such as OSPF, IS-IS, and BGP.
控制应用程序可以使用CAL来控制网络设备，而无需向上层提供任何服务。示例包括执行控制功能的应用程序，如OSPF、IS-IS和BGP。
Control-plane service examples include a virtual private LAN service, service tunnels, topology services, etc.
控制平面服务示例包括虚拟专用LAN服务、服务隧道、拓扑服务等。
The management plane is usually centralized and aims to ensure that the network as a whole is running optimally by communicating with the network devices' operational plane using a Management-Plane Southbound Interface (MPSI) with DAL as a point of reference.
管理平面通常是集中式的，旨在通过使用以DAL为参考点的管理平面南行接口（MPSI）与网络设备的操作平面进行通信，确保整个网络以最佳方式运行。
Management-plane functionalities are typically initiated, based on an overall network view, and traditionally have been human-centric. However, lately, algorithms are replacing most human intervention. Management-plane functionalities [FCAPS] typically include:
管理平面功能通常基于整体网络视图启动，并且传统上以人为中心。然而，最近，算法正在取代大多数人工干预。管理平面功能[FCAP]通常包括：
o Fault and monitoring management
o 故障和监测管理
o Configuration management
o 配置管理
In addition, management-plane functionalities may also include entities such as orchestrators, Virtual Network Function Managers (VNF Managers) and Virtualised Infrastructure Managers, as described in [NFVArch]. Such entities can use management interfaces to
此外，管理平面功能还可以包括诸如编排器、虚拟网络功能管理器（VNF管理器）和虚拟化基础设施管理器等实体，如[NFVArch]中所述。这些实体可以使用管理接口来
operational-plane resources to request and provision resources for virtual functions as well as instruct the instantiation of virtual forwarding functions on top of physical forwarding functions. The possibility of a common abstraction model for both SDN and Network Function Virtualization (NFV) is explored in [SDNNFV]. Note, however, that these are only examples of applications and services in the management plane and not formal definitions of entities in this document. As has been noted above, orchestration and therefore the definition of any associated entities is out of the scope of this document.
操作平面资源，用于请求和提供虚拟功能的资源，以及在物理转发功能的基础上指示虚拟转发功能的实例化。[SDNNFV]探讨了SDN和网络功能虚拟化（NFV）通用抽象模型的可能性。但是，请注意，这些只是管理层中应用程序和服务的示例，而不是本文档中实体的正式定义。如上所述，编排以及任何相关实体的定义不在本文档的范围内。
The MPSI, in contrast to the CPSI, is usually not a time-critical interface and does not share the CPSI requirements.
与CPSI相比，MPSI通常不是时间关键型接口，不共享CPSI要求。
MPSI is typically closer to human interaction than CPSI (cf. [RFC3535]); therefore, MPSI usually has the following characteristics:
MPSI通常比CPSI更接近人类交互（参见[RFC3535]）；因此，MPSI通常具有以下特征：
o It is oriented more towards usability, with optimal wire performance being a secondary concern.
o 它更倾向于可用性，而最佳导线性能是次要考虑因素。
o Messages tend to be less frequent than in the CPSI.
o 消息的频率往往低于CPSI中的频率。
As an example of usability versus performance, we refer to the consensus of the 2002 IAB Workshop [RFC3535]: the key requirement for a network management technology is ease of use, not performance. As per [RFC6632], textual configuration files should be able to contain international characters. Human-readable strings should utilize UTF-8, and protocol elements should be in case-insensitive ASCII, which requires more processing capabilities to parse.
作为可用性与性能的对比示例，我们参考了2002年IAB研讨会[RFC3535]的共识：网络管理技术的关键要求是易用性，而不是性能。根据[RFC6632]，文本配置文件应该能够包含国际字符。人类可读的字符串应该使用UTF-8，协议元素应该是不区分大小写的ASCII，这需要更多的处理能力来解析。
MPSI can range from a protocol, to an API or even inter-process communication. If the management plane is not embedded in the network device, the MPSI is certainly a protocol. Examples of MPSIs are ForCES [RFC5810], NETCONF [RFC6241], IP Flow Information Export (IPFIX) [RFC7011], Syslog [RFC5424], Open vSwitch Database (OVSDB) [RFC7047], and SNMP [RFC3411].
MPSI的范围从协议到API甚至进程间通信。如果管理平面没有嵌入到网络设备中，那么MPSI肯定是一个协议。MPSI的示例包括：强制[RFC5810]、网络配置[RFC6241]、IP流信息导出（IPFIX）[RFC7011]、系统日志[RFC5424]、开放vSwitch数据库（OVSDB）[RFC7047]和SNMP[RFC3411]。
The Management Abstraction Layer (MAL) provides access to management applications and services to various MPSIs. The management plane may support more than one MPSI.
管理抽象层（MAL）提供对各种MPSI的管理应用程序和服务的访问。管理平面可以支持多个MPSI。
Management applications can use MAL to manage the network device without providing any service to upper layers. Examples of management applications include network monitoring, fault detection, and recovery applications.
管理应用程序可以使用MAL来管理网络设备，而无需向上层提供任何服务。管理应用程序的示例包括网络监控、故障检测和恢复应用程序。
Management-plane services provide access to other services or applications above the management plane.
管理平面服务提供对管理平面上方的其他服务或应用程序的访问。
The definition of a clear distinction between "control" and "management" in the context of SDN received significant community attention during the preparation of this document. We observed that the role of the management plane has been earlier largely ignored or specified as out-of-scope for the SDN ecosystem. In the remainder of this subsection, we summarize the characteristics that differentiate the two planes in order to have a clear understanding of the mechanics, capabilities, and needs of each respective interface.
在编制本文件过程中，SDN中“控制”和“管理”之间的明确区分受到了社区的广泛关注。我们观察到，管理层面的作用在早期基本上被忽略，或被指定为超出SDN生态系统的范围。在本小节的剩余部分中，我们总结了区分这两个平面的特征，以便清楚地了解每个接口的机制、功能和需求。
A point has been raised regarding the reference timescales for the control and management planes regarding how fast the respective plane is required to react to, or how fast it needs to manipulate, the forwarding or operational plane of the device. In general, the control plane needs to send updates "often", which translates roughly to a range of milliseconds; that requires high-bandwidth and low-latency links. In contrast, the management plane reacts generally at longer time frames, i.e., minutes, hours, or even days; thus, wire efficiency is not always a critical concern. A good example of this is the case of changing the configuration state of the device.
已经提出了关于控制和管理平面的参考时间刻度的一点，关于要求相应平面对设备的转发或操作平面作出反应的速度或需要操纵设备的转发或操作平面的速度。一般来说，控制平面需要“经常”发送更新，这大致相当于毫秒的范围；这需要高带宽和低延迟链路。相反，管理平面通常在更长的时间范围内作出反应，即分钟、小时甚至几天；因此，导线效率并不总是一个关键问题。一个很好的例子是改变设备的配置状态。
Another distinction between the control and management planes relates to state persistence. A state is considered ephemeral if it has a very limited lifespan and is not deemed necessary to be stored on non-volatile memory. A good example is determining routing, which is usually associated with the control plane. On the other hand, a persistent state has an extended lifespan that may range from hours to days and months, is meant to be used beyond the lifetime of the process that created it, and is thus used across device reboots. Persistent state is usually associated with the management plane.
控制平面和管理平面之间的另一个区别与状态持久性有关。如果一个状态的寿命非常有限，并且没有必要存储在非易失性存储器中，则该状态被认为是短暂的。一个很好的例子是确定布线，这通常与控制平面相关。另一方面，持久状态的使用寿命可能从数小时延长到数天或数月，用于创建持久状态的进程的生命周期之外，因此在设备重新启动期间使用持久状态。持久状态通常与管理平面相关联。
As mentioned earlier, traditionally, the control plane has been executed locally on the network device and is distributed in nature whilst the management plane is usually executed in a centralized manner, remotely from the device. However, with the advent of SDN centralizing, or "logically centralizing", the controller tends to muddle the distinction of the control and management plane based on locality.
如前所述，传统上，控制平面在网络设备上本地执行，并且在本质上是分布式的，而管理平面通常以集中的方式从设备远程执行。然而，随着SDN集中或“逻辑集中”的出现，控制器倾向于混淆基于位置的控制和管理平面的区别。
The CAP theorem views a distributed computing system as composed of multiple computational resources (i.e., CPU, memory, storage) that are connected via a communications network and together perform a task. The theorem, or conjecture by some, identifies three characteristics of distributed systems that are universally desirable:
CAP定理将分布式计算系统视为由多个计算资源（即CPU、内存、存储器）组成，这些资源通过通信网络连接在一起，共同执行任务。该定理或某些人的推测确定了分布式系统普遍需要的三个特征：
o Consistency, meaning that the system responds identically to a query no matter which node receives the request (or does not respond at all).
o 一致性，这意味着无论哪个节点收到请求（或根本不响应），系统都会以相同的方式响应查询。
o Availability, i.e., that the system always responds to a request (although the response may not be consistent or correct).
o 可用性，即系统始终响应请求（尽管响应可能不一致或不正确）。
o Partition tolerance, namely that the system continues to function even when specific nodes or the communications network fail.
o 分区容差，即即使特定节点或通信网络出现故障，系统仍能继续运行。
In 2000, Eric Brewer [CAPBR] conjectured that a distributed system can satisfy any two of these guarantees at the same time but not all three. This conjecture was later proven by Gilbert and Lynch [CAPGL] and is now usually referred to as the CAP theorem [CAPFN].
2000年，Eric Brewer[CAPBR]推测分布式系统可以同时满足其中任意两种保证，但不能同时满足所有三种保证。这个猜想后来被吉尔伯特和林奇[CAPGL]证明，现在通常被称为CAP定理[CAPFN]。
Forwarding a packet through a network correctly is a computational problem. One of the major abstractions that SDN posits is that all network elements are computational resources that perform the simple computational task of inspecting fields in an incoming packet and deciding how to forward it. Since the task of forwarding a packet from network ingress to network egress is obviously carried out by a large number of forwarding elements, the network of forwarding devices is a distributed computational system. Hence, the CAP theorem applies to forwarding of packets.
正确地通过网络转发数据包是一个计算问题。SDN提出的主要抽象之一是，所有网络元素都是计算资源，执行简单的计算任务，即检查传入数据包中的字段并决定如何转发。由于将数据包从网络入口转发到网络出口的任务显然是由大量转发元件执行的，因此转发设备网络是一个分布式计算系统。因此，CAP定理适用于数据包的转发。
In the context of the CAP theorem, if one considers partition tolerance of paramount importance, traditional control-plane operations are usually local and fast (available), while management-plane operations are usually centralized (consistent) and may be slow.
在CAP定理的背景下，如果考虑到分区容差的重要性，传统的控制平面操作通常是局部的和快速的（可用的），而管理平面操作通常是集中的（一致的），并且可能是缓慢的。
The CAP theorem also provides insights into SDN architectures. For example, a centralized SDN controller acts as a consistent global database and specific SDN mechanisms ensure that a packet entering the network is handled consistently by all SDN switches. The issue of tolerance to loss of connectivity to the controller is not addressed by the basic SDN model. When an SDN switch cannot reach its controller, the flow will be unavailable until the connection is restored. The use of multiple non-collocated SDN controllers has
CAP定理还提供了对SDN体系结构的见解。例如，集中式SDN控制器充当一致的全局数据库，特定的SDN机制确保所有SDN交换机一致地处理进入网络的数据包。基本SDN模型未解决控制器连接中断的容差问题。当SDN交换机无法到达其控制器时，流量将不可用，直到连接恢复。多个非并置SDN控制器的使用
been proposed (e.g., by configuring the SDN switch with a list of controllers); this may improve partition tolerance but at the cost of loss of absolute consistency. Panda, et al. [CAPFN] provide a first exploration of how the CAP theorem applies to SDN.
已提出（例如，通过使用控制器列表配置SDN交换机）；这可能会提高分区容差，但代价是失去绝对一致性。Panda等人[CAPFN]首次探索了CAP定理如何应用于SDN。
The Network Services Abstraction Layer (NSAL) provides access from services of the control, management, and application planes to other services and applications. We note that the term "SAL" is overloaded, as it is often used in several contexts ranging from system design to service-oriented architectures; therefore, we explicitly add "Network" to the title of this layer to emphasize that this term relates to Figure 1, and we map it accordingly in Section 4 to prominent SDN approaches.
网络服务抽象层（NSAL）提供从控制、管理和应用程序平面的服务到其他服务和应用程序的访问。我们注意到术语“SAL”是重载的，因为它经常用于从系统设计到面向服务的体系结构的多个上下文中；因此，我们明确地将“网络”添加到该层的标题中，以强调该术语与图1相关，并在第4节中相应地将其映射到突出的SDN方法。
Service interfaces can take many forms pertaining to their specific requirements. Examples of service interfaces include, but are not limited to, RESTful APIs, open protocols such as NETCONF, inter-process communication, CORBA [CORBA] interfaces, and so on. The two leading approaches for service interfaces are RESTful interfaces and Remote Procedure Call (RPC) interfaces. Both follow a client-server architecture and use XML or JSON to pass messages, but each has some slightly different characteristics.
服务接口可以根据其特定需求采取多种形式。服务接口的示例包括但不限于RESTful API、开放协议（如NETCONF）、进程间通信、CORBA[CORBA]接口等。服务接口的两种主要方法是RESTful接口和远程过程调用（RPC）接口。两者都遵循客户机-服务器体系结构，并使用XML或JSON传递消息，但它们都有一些稍有不同的特征。
RESTful interfaces, designed according to the representational state transfer design paradigm [REST], have the following characteristics:
根据代表性状态转移设计范式[REST]设计的RESTful接口具有以下特征：
o Resource identification - Individual resources are identified using a resource identifier, for example, a URI.
o 资源标识-使用资源标识符（例如URI）标识单个资源。
o Manipulation of resources through representations - Resources are represented in a format like JSON, XML, or HTML.
o 通过表示操作资源-资源以JSON、XML或HTML等格式表示。
o Self-descriptive messages - Each message has enough information to describe how the message is to be processed.
o 自描述性消息-每条消息都有足够的信息来描述如何处理消息。
o Hypermedia as the engine of application state - A client needs no prior knowledge of how to interact with a server, as the API is not fixed but dynamically provided by the server.
o 作为应用程序状态引擎的超媒体—客户端不需要事先了解如何与服务器交互，因为API不是固定的，而是由服务器动态提供的。
Remote procedure calls (RPCs) [RFC5531], e.g., XML-RPC and the like, have the following characteristics:
远程过程调用（RPC）[RFC5531]，例如XML-RPC等，具有以下特征：
o Individual procedures are identified using an identifier.
o 使用标识符标识各个程序。
o A client needs to know the procedure name and the associated parameters.
o 客户机需要知道过程名称和相关参数。
Applications and services that use services from the control and/or management plane form the application plane.
使用来自控制和/或管理平面的服务的应用程序和服务构成应用程序平面。
Additionally, services residing in the application plane may provide services to other services and applications that reside in the application plane via the service interface.
另外，驻留在应用平面中的服务可以通过服务接口向驻留在应用平面中的其他服务和应用提供服务。
Examples of applications include network topology discovery, network provisioning, path reservation, etc.
应用程序的示例包括网络拓扑发现、网络供应、路径保留等。
We advocate that the SDN southbound interface should encompass both CPSI and MPSI.
我们主张SDN南行接口应包括CPSI和MPSI。
SDN controllers such as [NOX] and [Beacon] are a collection of control-plane applications and services that implement a CPSI ([NOX] and [Beacon] both use OpenFlow) and provide a northbound interface for applications. The SDN northbound interface for controllers is implemented in the Network Services Abstraction Layer (NSAL) of Figure 1.
SDN控制器，如[NOX]和[Beacon]是控制平面应用程序和服务的集合，它们实现CPSI（[NOX]和[Beacon]都使用OpenFlow），并为应用程序提供北行接口。控制器的SDN北向接口在图1的网络服务抽象层（NSAL）中实现。
The above model can be used to describe all prominent SDN-enabling technologies in a concise manner, as we explain in the following subsections.
正如我们在以下小节中所解释的那样，上述模型可用于以简洁的方式描述所有突出的SDN支持技术。
The IETF Forwarding and Control Element Separation (ForCES) framework [RFC3746] consists of one model and two protocols. ForCES separates the forwarding plane from the control plane via an open interface, namely the ForCES protocol [RFC5810], which operates on entities of the forwarding plane that have been modeled using the ForCES model [RFC5812].
IETF转发和控制单元分离（ForCES）框架[RFC3746]由一个模型和两个协议组成。ForCES通过一个开放接口（即ForCES协议[RFC5810]）将转发平面与控制平面分离，该接口对使用ForCES模型[RFC5812]建模的转发平面实体进行操作。
The ForCES model [RFC5812] is based on the fact that a network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as routing or IP switching) and yet appear as a normal integrated network element to external entities.
ForCES模型[RFC5812]基于这样一个事实，即网元由多个逻辑上独立的实体组成，这些实体相互协作以提供给定的功能（如路由或IP交换），但对于外部实体来说，它仍然是一个普通的集成网元。
ForCES models the forwarding plane using Logical Functional Blocks (LFBs), which, when connected in a graph, compose the Forwarding Element (FE). LFBs are described in XML, based on an XML schema.
ForCES使用逻辑功能块（LFB）对转发平面进行建模，逻辑功能块在连接到图中时构成转发元素（FE）。LFB是基于XML模式用XML描述的。
LFB definitions include base and custom-defined datatypes; metadata definitions; input and output ports; operational parameters or components; and capabilities and event definitions.
LFB定义包括基本数据类型和自定义数据类型；元数据定义；输入和输出端口；操作参数或组件；以及功能和事件定义。
The ForCES model can be used to define LFBs from fine- to coarse-grained as needed, irrespective of whether they are physical or virtual.
力模型可用于根据需要定义从细粒度到粗粒度的LFB，无论它们是物理的还是虚拟的。
The ForCES protocol is agnostic to the model and can be used to monitor, configure, and control any ForCES-modeled element. The protocol has very simple commands: Set, Get, and Del(ete). The ForCES protocol has been designed for high throughput and fast updates.
ForCES协议与模型无关，可用于监视、配置和控制任何ForCES建模元素。该协议有非常简单的命令：Set、Get和Del（ete）。ForCES协议设计用于高吞吐量和快速更新。
With respect to Figure 1, the ForCES model [RFC5812] is suitable for the DAL, both for the operational and the forwarding plane, using LFBs. The ForCES protocol [RFC5810] has been designed and is suitable for the CPSI, although it could also be utilized for the MPSI.
关于图1，力模型[RFC5812]适用于DAL，包括使用LFB的操作平面和转发平面。ForCES协议[RFC5810]已经设计好，适用于CPSI，但也可用于MPSI。
The Network Configuration Protocol (NETCONF) [RFC6241] is an IETF network management protocol [RFC6632]. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices.
网络配置协议（NETCONF）[RFC6241]是IETF网络管理协议[RFC6632]。NETCONF提供了安装、操作和删除网络设备配置的机制。
NETCONF protocol operations are realized as remote procedure calls (RPCs). The NETCONF protocol uses XML-based data encoding for the configuration data as well as the protocol messages. Recent studies, such as [ESNet] and [PENet], have shown that NETCONF performs better than SNMP [RFC3411].
NETCONF协议操作通过远程过程调用（rpc）实现。NETCONF协议对配置数据和协议消息使用基于XML的数据编码。最近的研究，如[ESNet]和[PENet]，表明NETCONF的性能优于SNMP[RFC3411]。
Additionally, the YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations. YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications.
此外，还开发了YANG数据建模语言[RFC6020]，用于指定NETCONF数据模型和协议操作。YANG是一种数据建模语言，用于对由NETCONF协议、NETCONF远程过程调用和NETCONF通知操作的配置和状态数据进行建模。
YANG models the hierarchical organization of data as a tree, in which each node has either a value or a set of child nodes. Additionally, YANG structures data models into modules and submodules, allowing reusability and augmentation. YANG models can describe constraints to be enforced on the data. Additionally, YANG has a set of base datatypes and allows custom-defined datatypes as well.
YANG将数据的分层组织建模为一棵树，其中每个节点都有一个值或一组子节点。此外，YANG将数据模型构造为模块和子模块，允许重用和扩展。YANG模型可以描述对数据实施的约束。此外，YANG有一组基本数据类型，并允许自定义定义的数据类型。
YANG allows the definition of NETCONF RPCs, which allows the protocol to have an extensible number of commands. For RPC definitions, the operations names, input parameters, and output parameters are defined using YANG data definition statements.
YANG允许定义NETCONF RPC，这允许协议具有可扩展数量的命令。对于RPC定义，使用数据定义语句定义操作名称、输入参数和输出参数。
With respect to Figure 1, the YANG model [RFC6020] is suitable for specifying DAL for the forwarding and operational planes. NETCONF [RFC6241] is suitable for the MPSI. NETCONF is a management protocol [RFC6632], which was not (originally) designed for fast CP updates, and it might not be suitable for addressing the requirements of CPSI.
关于图1，YANG模型[RFC6020]适用于为转发和操作平面指定DAL。NETCONF[RFC6241]适用于MPSI。NETCONF是一种管理协议[RFC6632]，它（最初）不是为快速CP更新而设计的，它可能不适合满足CPSI的要求。
OpenFlow is a framework originally developed at Stanford University and currently under active standards development [OpenFlow] through the Open Networking Foundation (ONF). Initially, the goal was to provide a way for researchers to run experimental protocols in a production network [OF08]. OpenFlow has undergone many revisions, and additional revisions are likely. The following description reflects version 1.4 [OpenFlow]. In short, OpenFlow defines a protocol through which a logically centralized controller can control an OpenFlow switch. Each OpenFlow-compliant switch maintains one or more flow tables, which are used to perform packet lookups. Distinct actions are to be taken regarding packet lookup and forwarding. A group table and an OpenFlow channel to external controllers are also part of the switch specification.
OpenFLASH是一个最初在斯坦福大学开发的框架，目前正处于开放式网络基金会（ONF）的积极标准开发[OpenFLUE]中。最初，目标是为研究人员提供一种在生产网络中运行实验协议的方法[OF08]。OpenFlow已经经历了许多修订，可能还会有更多的修订。以下描述反映了1.4版[OpenFlow]。简言之，OpenFlow定义了一个协议，通过该协议，逻辑集中的控制器可以控制OpenFlow交换机。每个符合OpenFlow的交换机维护一个或多个流表，用于执行数据包查找。关于数据包查找和转发，将采取不同的措施。组表和到外部控制器的OpenFlow通道也是交换机规范的一部分。
With respect to Figure 1, the OpenFlow switch specifications [OpenFlow] define a DAL for the forwarding plane as well as for CPSI. The OF-CONFIG protocol [OF-CONFIG], based on the YANG model [RFC6020], provides a DAL for the forwarding and operational planes of an OpenFlow switch and specifies NETCONF [RFC6241] as the MPSI. OF-CONFIG overlaps with the OpenFlow DAL, but with NETCONF [RFC6241] as the transport protocol, it shares the limitations described in the previous section.
关于图1，OpenFlow交换机规范[OpenFlow]定义了转发平面和CPSI的DAL。OF-CONFIG协议[OF-CONFIG]基于YANG模型[RFC6020]，为OpenFlow交换机的转发和操作平面提供DAL，并将NETCONF[RFC6241]指定为MPSI。OF-CONFIG与OpenFlow DAL重叠，但以NETCONF[RFC6241]作为传输协议，它与上一节中描述的限制相同。
Interface to the Routing System (I2RS) provides a standard interface to the routing system for real-time or event-driven interaction through a collection of protocol-based control or management interfaces. Essentially, one of the main goals of I2RS, is to make the Routing Information Base (RIB) programmable, thus enabling new kinds of network provisioning and operation.
路由系统接口（I2RS）通过一系列基于协议的控制或管理接口，为路由系统提供了一个标准接口，用于实时或事件驱动的交互。本质上，I2RS的主要目标之一是使路由信息库（RIB）可编程，从而实现新类型的网络供应和操作。
I2RS did not initially intend to create new interfaces but rather leverage or extend existing ones and define informational models for the routing system. For example, the latest I2RS problem statement
I2RS最初并不打算创建新接口，而是利用或扩展现有接口，并为路由系统定义信息模型。例如，最新的I2RS问题声明
[I2RSProb] discusses previously defined IETF protocols such as ForCES [RFC5810], NETCONF [RFC6241], and SNMP [RFC3417]. Regarding the definition of informational and data models, the I2RS working group has opted to use the YANG [RFC6020] modeling language.
[I2RSProb]讨论了先前定义的IETF协议，如ForCES[RFC5810]、NETCONF[RFC6241]和SNMP[RFC3417]。关于信息和数据模型的定义，I2RS工作组选择使用YANG[RFC6020]建模语言。
Currently the I2RS working group is developing an Information Model [I2RSInfo] in regards to the Network Services Abstraction Layer for the I2RS agent.
目前，I2RS工作组正在针对I2RS代理的网络服务抽象层开发一个信息模型[I2RSInfo]。
With respect to Figure 1, the I2RS architecture [I2RSArch] encompasses the control and application planes and uses any CPSI and DAL that is available, whether that may be ForCES [RFC5810], OpenFlow [OpenFlow], or another interface. In addition, the I2RS agent is a control-plane service. All services or applications on top of that belong to either the Control, Management, or Application plane. In the I2RS documents, management access to the agent may be provided by management protocols like SNMP and NETCONF. The I2RS protocol may also be mapped to the service interface as it will even provide access to services and applications other than control-plane services and applications.
关于图1，I2RS体系结构[I2RSArch]包含控制和应用平面，并使用任何可用的CPSI和DAL，无论是ForCES[RFC5810]、OpenFlow[OpenFlow]还是其他接口。此外，I2RS代理是一种控制平面服务。其上属于控制、管理或应用程序平面的所有服务或应用程序。在I2RS文档中，可以通过SNMP和NETCONF等管理协议提供对代理的管理访问。I2RS协议也可以映射到服务接口，因为它甚至可以提供对控制平面服务和应用程序以外的服务和应用程序的访问。
The Simple Network Management Protocol (SNMP) is an IETF-standardized management protocol and is currently at its third revision (SNMPv3) [RFC3417] [RFC3412] [RFC3414]. It consists of a set of standards for network management, including an application-layer protocol, a database schema, and a set of data objects. SNMP exposes management data (managed objects) in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried and set by managing applications.
简单网络管理协议（SNMP）是IETF标准化管理协议，目前处于第三版（SNMPv3）[RFC3417][RFC3412][RFC3414]。它由一组网络管理标准组成，包括应用层协议、数据库模式和一组数据对象。SNMP以变量的形式在管理系统上公开管理数据（管理对象），这些变量描述系统配置。然后可以通过管理应用程序来查询和设置这些变量。
SNMP uses an extensible design for describing data, defined by Management Information Bases (MIBs). MIBs describe the structure of the management data of a device subsystem. MIBs use a hierarchical namespace containing object identifiers (OIDs). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2 [RFC2578].
SNMP使用可扩展设计来描述由管理信息库（MIB）定义的数据。MIB描述设备子系统管理数据的结构。MIB使用包含对象标识符（OID）的分层命名空间。每个OID标识一个可通过SNMP读取或设置的变量。MIB使用管理信息结构版本2[RFC2578]定义的符号。
An early example of SNMP in the context of SDN is discussed in [Peregrine].
[Peregrine]中讨论了SDN环境中SNMP的早期示例。
With respect to Figure 1, SNMP MIBs can be used to describe DAL for the forwarding and operational planes. Similar to YANG, SNMP MIBs are able to describe DAL for the forwarding plane. SNMP, similar to NETCONF, is suited for the MPSI.
关于图1，SNMP MIB可用于描述转发和操作平面的DAL。与YANG类似，SNMP MIB能够描述转发平面的DAL。SNMP类似于NETCONF，适用于MPSI。
The Path Computation Element (PCE) [RFC4655] architecture defines an entity capable of computing paths for a single service or a set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for a variety of path computation problems and switching technologies. The PCE Communication Protocol (PCEP) [RFC5440] is used between a Path Computation Client (PCC) and a PCE, or between multiple PCEs.
路径计算元素（PCE）[RFC4655]体系结构定义了能够为单个服务或一组服务计算路径的实体。PCE可以是一个资源感知的网络节点、网络管理站或专用计算平台，并具有考虑各种路径计算问题和交换技术的多个约束的能力。PCE通信协议（PCEP）[RFC5440]在路径计算客户端（PCC）和PCE之间或在多个PCE之间使用。
The PCE architecture represents a vision of networks that separates path computation for services, the signaling of end-to-end connections, and actual packet forwarding. The definition of online and offline path computation is dependent on the reachability of the PCE from network and Network Management System (NMS) nodes and the type of optimization request that may significantly impact the optimization response time from the PCE to the PCC.
PCE体系结构代表了一种网络愿景，它将服务的路径计算、端到端连接的信令和实际的数据包转发分离开来。在线和离线路径计算的定义取决于来自网络和网络管理系统（NMS）节点的PCE的可达性以及可能显著影响从PCE到PCC的优化响应时间的优化请求的类型。
The PCEP messaging mechanism facilitates the specification of computation endpoints (source and destination node addresses), objective functions (requested algorithm and optimization criteria), and the associated constraints such as traffic parameters (e.g., requested bandwidth), the switching capability, and encoding type.
PCEP消息传递机制有助于指定计算端点（源节点和目的节点地址）、目标函数（请求的算法和优化标准）以及相关约束，例如业务参数（例如，请求的带宽）、交换能力和编码类型。
With respect to Figure 1, PCE is a control-plane service that provides services for control-plane applications. PCEP may be used as an east-west interface between PCEs that may act as domain control entities (services and applications). The PCE working group is specifying extensions [PCEActive] that allow an active PCE to control, using PCEP, MPLS or GMPLS Label Switched Paths (LSPs), thus making it applicable for the CPSI for MPLS and GMPLS switches.
关于图1，PCE是一种控制平面服务，为控制平面应用程序提供服务。PCEP可用作PCE之间的东西接口，PCE可作为域控制实体（服务和应用程序）。PCE工作组正在指定允许活动PCE使用PCEP、MPLS或GMPLS标签交换路径（LSP）进行控制的扩展[PCEActive]，从而使其适用于MPLS和GMPLS交换机的CPSI。
Bidirectional Forwarding Detection (BFD) [RFC5880] is an IETF-standardized network protocol designed for detecting path failures between two forwarding elements, including physical interfaces, subinterfaces, data link(s), and, to the extent possible, the forwarding engines themselves, with potentially very low latency. BFD can provide low-overhead failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links where there exists a return path as well. It is often implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated.
双向转发检测（BFD）[RFC5880]是一种IETF标准化网络协议，设计用于检测两个转发元素（包括物理接口、子接口、数据链路）之间的路径故障，并尽可能检测转发引擎本身，潜在延迟非常低。BFD可以在系统之间的任何类型的路径上提供低开销故障检测，包括直接物理链路、虚拟电路、隧道、MPLS LSP、多跳路由路径以及存在返回路径的单向链路。在转发引擎和控制引擎分离的情况下，它通常在系统转发引擎的某些组件中实现。
With respect to Figure 1, a BFD agent can be implemented as a control-plane service or application that would use the CPSI towards the forwarding plane to send/receive BFD packets. However, a BFD agent is usually implemented as an application on the device and uses the forwarding plane to send/receive BFD packets and update the operational-plane resources accordingly. Services and applications of the control and management planes that monitor or have subscribed to changes of resources can learn about these changes through their respective interfaces and take any actions as necessary.
关于图1，BFD代理可以实现为控制平面服务或应用程序，该服务或应用程序将使用CPSI向转发平面发送/接收BFD数据包。然而，BFD代理通常实现为设备上的应用程序，并使用转发平面发送/接收BFD分组，并相应地更新操作平面资源。监控或订阅资源更改的控制和管理平面的服务和应用程序可以通过其各自的接口了解这些更改，并在必要时采取任何行动。
This document has been developed after a thorough and detailed analysis of related peer-reviewed literature, the RFC series, and documents produced by other relevant standards organizations. It has been reviewed publicly by the wider SDN community, and we hope that it can serve as a handy tool for network researchers, engineers, and practitioners in the years to come.
本文件是在对相关同行评审文献、RFC系列和其他相关标准组织编制的文件进行彻底和详细分析后编制的。它已经被更广泛的SDN社区公开审查，我们希望它能在未来几年成为网络研究人员、工程师和从业者的便捷工具。
We conclude this document with a brief summary of the terminology of the SDN layer architecture. In general, we consider a network element as a composition of resources. Each network element has a forwarding plane (FP) that is responsible for handling packets in the data path and an operational plane (OP) that is responsible for managing the operational state of the device. Resources in the network element are abstracted by the Device and resource Abstraction Layer (DAL) to be controlled and managed by services or applications that belong to the control or management plane. The control plane (CP) is responsible for making decisions on how packets should be forwarded. The management plane (MP) is responsible for monitoring, configuring, and maintaining network devices. Service interfaces are abstracted by the Network Services Abstraction Layer (NSAL), where other network applications or services may use them. The taxonomy introduced in this document defines distinct SDN planes, abstraction layers, and interfaces; it aims to clarify SDN terminology and establish commonly accepted reference definitions across the SDN community, irrespective of specific implementation choices.
我们以SDN层体系结构术语的简要总结来结束本文档。一般来说，我们认为网络元素是资源的组成部分。每个网元具有负责处理数据路径中的分组的转发平面（FP）和负责管理设备的操作状态的操作平面（OP）。网元中的资源由设备和资源抽象层（DAL）抽象，由属于控制或管理平面的服务或应用程序控制和管理。控制平面（CP）负责决定如何转发数据包。管理平面（MP）负责监控、配置和维护网络设备。服务接口由网络服务抽象层（NSAL）抽象，其他网络应用程序或服务可以使用它们。本文介绍的分类法定义了不同的SDN平面、抽象层和接口；它旨在澄清SDN术语，并在整个SDN社区中建立普遍接受的参考定义，而不考虑具体的实现选择。
This document does not propose a new network architecture or protocol and therefore does not have any impact on the security of the Internet. That said, security is paramount in networking; thus, it should be given full consideration when designing a network architecture or operational deployment. Security in SDN is discussed in the literature, for example, in [SDNSecurity], [SDNSecServ], and
本文件未提出新的网络架构或协议，因此不会对互联网的安全产生任何影响。这就是说，网络安全是最重要的；因此，在设计网络体系结构或操作部署时，应充分考虑这一点。文献中讨论了SDN中的安全性，例如在[SDN安全]、[SDN安全服务]和[SDN安全服务]中
[SDNSecOF]. Security considerations regarding specific interfaces (such as, for example, ForCES, I2RS, SNMP, or NETCONF) are addressed in their respective documents as well as in [RFC7149].
[SDNSecOF]。有关特定接口（例如，ForCES、I2RS、SNMP或NETCONF）的安全注意事项在其各自的文档以及[RFC7149]中均有说明。
[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.
[A4D05]Greenberg，A.，Hjalmtysson，G.，Maltz，D.，Myers，A.，Rexford，J.，Xie，G.，Yan，H.，Zhan，J.，和H.Zhang，“网络控制和管理的全新4D方法”，ACM SIGCOMM计算机通信评论，第35卷，第5期，第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.
[ALIEN]Parniewicz，D.，Corin，R.，Ogrodowczyk，L.，Fard，M.，Matias，J.，Gerola，M.，Fuentes，V.，Toseef，U.，Zaalouk，A.，Belter，B.，Jacob，E.，和K.Pentikousis，“OpenFlow硬件抽象层的设计和实现”，美国伊利诺伊州芝加哥ACM SIGCOMM分布式云计算（DCC）研讨会论文集，第71-76页，内政部10.1145/2627566.26275772014年8月。
[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.
[Beacon]Erickson，D.，“Beacon OpenFlow控制器”，载于第二届ACM SIGCOMM软件定义网络热点研讨会论文集，第13-18页，2013年。
[CAPBR] Brewer, E., "Towards Robust Distributed Systems", In Proceedings of the Symposium on Principles of Distributed Computing (PODC), 2000.
[CAPBR]Brewer，E.，“走向健壮的分布式系统”，发表于《分布式计算原理研讨会论文集》（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.
[CAPFN]Panda，A.，Scott，C.，Ghodsi，A.，Koponen，T.，和S.Shenker，“网络CAP”，摘自第二届ACM SIGCOMM软件定义网络热点研讨会论文集，第91-962013页。
[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.
[CAPGL]Gilbert，S.和N.Lynch，“布鲁尔猜想和一致、可用、分区容忍Web服务的可行性”，ACM SIGACT News，第33卷，第2期，第51-59页，2002年。
[CORBA] Object Management Group, "CORBA Version 3.3", November 2012, <http://www.omg.org/spec/CORBA/3.3/>.
[CORBA]对象管理组，“CORBA版本3.3”，2012年11月<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.
[DIOPR]Denazis，S.，Miki，K.，Vicente，J.，和A.Campbell，“为开放式可编程路由器设计接口”，摘自《主动网络》，柏林海德堡斯普林格出版社，第13-241999页。
[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.
[ESNet]Yu，J.和I.Al-Ajarmeh，“NETCONF协议的实证研究”，第六届网络与服务国际会议，第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>.
[FCAPS]国际电联，“CCITT应用的开放系统互连（OSI）管理框架”，国际电联建议X.700，1992年9月<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.
[I2RSArch]Atlas，A.，Halpern，J.，Hares，S.，Ward，D.，和T.Nadeau，“路由系统接口的架构”，在建工程，草案-ietf-i2rs-Architecture-07，2014年12月。
[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.
[I2RSInfo]Bahadur，N.，Folkes，R.，Kini，S.，和J.Medved，“路由信息基础信息模型”，正在进行的工作，草稿-ietf-i2rs-rib-Info-Model-042014年12月。
[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.
[I2RSProb]Atlas，A.，Nadeau，T.，和D.Ward，“路由系统问题声明的接口”，正在进行的工作，草案-ietf-i2rs-Problem-Statement-05，2015年1月。
[ITUATM] ITU, "B-ISDN ATM Layer Specification", ITU Recommendation I.361, 1990, <http://www.itu.int/rec/T-REC-I.361-199902-I/en>.
[ITUATM]ITU，“B-ISDN ATM层规范”，ITU建议I.36119990<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>.
[ITUSG11]国际电联，“ITU-T研究小组11：协议和测试规范”<http://www.itu.int/en/ITU-T/ studygroup/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>.
[ITUSG13]ITU，“ITU-T研究小组13：未来网络，包括云计算、移动和下一代网络”<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>.
[ITUSS7]国际电联，“CCITT第7号信令系统简介”，国际电联建议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>.
[ITUY3300]国际电联，“软件定义网络框架”，国际电联建议Y.3300，2014年6月<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.
[KANDOO]Yeganeh，S.和Y.Ganjali，“KANDOO：有效和可扩展的控制应用卸载框架”，载于第一届ACM SIGCOMM软件定义网络热点研讨会论文集，第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>.
[NFVArch]ETSI，“网络功能虚拟化（NFV）：架构框架”，ETSI GS NFV 002，2013年10月<http://www.etsi.org/deliver/etsi_gs/ nfv/001_099/002/01.01.01_60/gs_NFV002V00101P.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.
[NOX]Gude，N.，Koponen，T.，Pettit，J.，Pfaff，B.，Casado，M.，McKeown，N.，和S.Shenker，“NOX：迈向网络操作系统”，ACM SIGCOMM计算机通信评论，第38卷，第3期，第105-110页，2008年7月。
[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.
[NV09]Chowdhury，N.和R.Boutaba，“网络虚拟化：最新技术和研究挑战”，通信杂志，IEEE，第47卷，第7期，第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>.
[OpenFIG]开放网络基金会，“OpenFLUE管理和配置协议（CONFIG1.1.1）”，2013年3月，<https://www.opennetworking.org/images/stories/ 下载/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.
[OF08]N.McKeown、T.Anderson、H.Balakrishnan、G.Parulkar、Peterson、L.Rexford、J.Shenker、S.和J.Turner，“OpenFlow：校园网络中的创新”，ACM SIGCOMM计算机通信评论，第38卷，第2期，第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>.
开放网络基础，“SDN架构，版本1”，2014年6月，<https://www.opennetworking.org/images/stories/ 下载/sdn资源/技术报告/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>.
开放网络基础，“OpenFLASH交换机规范，版本1.4.0”，2013年10月，<https://www.opennetworking.org/images/stories/ 下载/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.
[P1520]Biswas，J.，Lazar，A.，Huard，J.，Lim，K.，Mahjoub，S.，Pau，L.，Suzuki，M.，Torstensson，S.，Wang，W.，和S.Weinstein，“IEEE P1520可编程网络接口标准倡议”，《IEEE通信杂志》，第36卷，第10期，第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.
[PCEActive]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-Stateful-PCE-102014年10月。
[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.
[PNET ] HeSTROM，B，WATWE，A.和S.SkthIDHARAN，“NETCONF与SNMP的配置管理功能的协议效率”，硕士论文，科罗拉多大学，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.
[PNSurvey99]Campbell，A.，De Meer，H.，Kounanis，M.，Miki，K.，Vicente，J.，和D.Villela，“可编程网络的调查”，ACM SIGCOMM计算机通信评论，第29卷，第2期，第7-23页，1992年9月。
[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.
[Peregrine]Chiueh，D.，Tu，C.，Wang，Y.，Wang，P.，Li，K.，和Y.Huang，“Peregrine:一个全层2容器计算机网络”，载于2012年IEEE第五届云计算国际会议记录，第686-693页，2012年。
[PiNA] Day, J., "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, ISBN 0132252422, 2008.
[PiNA]Day，J.，“网络架构中的模式：回归基本面”，普伦蒂斯大厅，ISBN 013225422，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.
[RCP]Caesar，M.，Caldwell，D.，Feamster，N.，Rexford，J.，Shaikh，A.，和J.van der Merwe，“路由控制平台的设计和实现”，载于《网络化系统设计与实现研讨会第2卷第2次会议录》，2005年第15-28页。
[REST] Fielding, Roy, "Chapter 5: Representational State Transfer (REST)", in Disseration "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[REST]Fielding，Roy，“第5章：表征状态转移（REST）”，论文“架构风格和基于网络的软件架构的设计”，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>.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月<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>.
[RFC1953]Newman，P.，Edwards，W.，Hinden，R.，Hoffman，E.，Ching Liaw，F.，Lyon，T.，和G.Minshall，“IPv4版本1.0的Ipsilon流管理协议规范”，RFC 1953，1996年5月<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>.
[RFC2297]Newman，P.，Edwards，W.，Hinden，R.，Hoffman，E.，Liaw，F.，Lyon，T.，和G.Minshall，“Ipsilon的通用交换机管理协议规范版本2.0”，RFC 2297，1998年3月<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>.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月<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>.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月<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>.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月<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>.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月<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>.
[RFC3417]Presohn，R.，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月<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>.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月<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>.
[RFC3535]Schoenwaeld，J.，“2002年IAB网络管理研讨会概述”，RFC 3535，2003年5月<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>.
[RFC3746]Yang，L.，Dantu，R.，Anderson，T.，和R.Gopal，“转发和控制单元分离（部队）框架”，RFC 37462004年4月<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>.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月<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>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月<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>.
[RFC5440]Vasseur，JP。和JL。Le Roux，“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月<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>.
[RFC5531]Thurlow，R.，“RPC:远程过程调用协议规范版本2”，RFC 55312009年5月<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>.
[RFC5743]Falk，A.“互联网研究工作队（IRTF）文件流的定义”，RFC 57432009年12月<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>.
[RFC5810]Doria，A.，Hadi Salim，J.，Haas，R.，Khosravi，H.，Wang，W.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 58102010年3月<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>.
[RFC5812]Halpern，J.和J.Hadi Salim，“转发和控制单元分离（部队）转发单元模型”，RFC 5812，2010年3月<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>.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月<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>.
[RFC6020]Bjorklund，M.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 602020，2010年10月<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>.
[RFC6241]Enns，R.，Bjorklund，M.，Schoenwaeld，J.，和A.Bierman，“网络配置协议（NETCONF）”，RFC 62412011年6月<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>.
[RFC6632]Ersue，M.和B.Claise，“IETF网络管理标准概述”，RFC 6632，2012年6月<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>.
[RFC7011]Claise，B.，Trammell，B.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，2013年9月<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>.
[RFC7047]Pfaff，B.和B.Davie，“开放式vSwitch数据库管理协议”，RFC 7047，2013年12月<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>.
[RFC7149]Boucadair，M.和C.Jacquenet，“软件定义的网络：服务提供商环境中的视角”，RFC 7149，2014年3月<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>.
[RFC7276]Mizrahi，T.，Sprecher，N.，Bellagamba，E.，和Y.Weingarten，“运营、管理和维护（OAM）工具概述”，RFC 7276，2014年6月<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.
[RINA]Day，J.，Matta，I.，和K.Mattar，“网络是IPC：更好的互联网的指导原则”，2008年ACM CoNEXT会议记录，第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.
[RouteFlow]Nascimento，M.，Rothenberg，C.，Salvador，M.，Correa，C.，de Lucena，S.，和M.Magalhaes，“虚拟路由器即服务：利用软件定义网络的路由流方法”，载于《第六届未来互联网技术国际会议录》，2011年第34-37页。
[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.
[SDNACS]Kreutz，D.，Ramos，F.，Verissimo，P.，Rothenberg，C.，Azodolmolky，S.，和S.Uhlig，“软件定义的网络：综合调查”，网络和互联网架构（cs.NI），arXiv:1406.04402014。
[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.
[SDN历史]N.Feamster、J.Rexford和E.Zegura，“SDN之路：可编程网络的知识史”，ACM队列，第11卷，2013年第12期。
[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.
[SDNNFV]Haleplidis，E.，Hadi Salim，J.，Denazis，S.，和O.Koufopavlou，“SDN的网络抽象模型”，网络和系统管理杂志：软件定义网络管理专刊，2014年1-19页。
[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.
[SDNSecOF]Kloti，R.，Kotronis，V.，和P.Smith，“OpenFlow:安全分析”，第21届IEEE网络协议国际会议（ICNP）第1-6页，2013年10月。
[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.
[SDNSecServ]Scott Hayward，S.，O'Callaghan，G.和S.Sezer，“SDN安全：一项调查”，载于IEEE未来网络和服务SDN（SDN4FNS），第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.
[SDNSecurity]Kreutz，D.，Ramos，F.，和P.Verissimo，“迈向安全可靠的软件定义网络”，摘自第二届ACM SIGCOMM软件定义网络热点研讨会论文集，第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.
[SDNSurvey]Nunes，B.，Mendonca，M.，Nguyen，X.，Obraczka，K.，和T.Turletti，“软件定义网络的调查：可编程网络的过去、现在和未来”，IEEE通信调查和教程，DOI:10.1109/SURV.2014.012214.001802014。
[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.
[SLTSDN]Jarraya，Y.，Madi，T.，和M.Debbabi，“软件定义网络的调查和分层分类”，IEEE通信调查和教程，第16卷，第4期，第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.
[软路由器]Lakshman，T.，Nandagopal，T.，Ramjee，R.，Sabnani，K.，和T.Woo，“软路由器架构”，摘自ACM SIGCOMM网络热点研讨会论文集，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.
[Tempest]Rooney，S.，van der Merwe，J.，Crosby，S.，和I.Leslie，“Tempest：安全、资源保证、可编程网络的框架”，《通信杂志》，IEEE，第36卷，第10期，第42-53页，1998年。
Acknowledgements
致谢
The authors would like to acknowledge Salvatore Loreto and Sudhir Modali for their contributions in the initial discussion on the SDNRG mailing list as well as their document-specific comments; they helped put this document in a better shape.
作者感谢Salvatore Loreto和Sudhir Modali在SDNRG邮件列表的初步讨论中所做的贡献以及他们对文件的具体评论；他们帮助改善了这份文件。
Additionally, we would like to thank (in alphabetical order) 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, Yaakov Stein, Eve Varma, Stuart Venters, Russ White, and Lee Young for their critical comments and discussions at IETF 88, IETF 89, and IETF 90 and on the SDNRG mailing list, which we took into consideration while revising this document.
此外，我们还要感谢（按字母顺序排列）希夫莉拉·阿利马蒂、罗兰·布莱斯、斯科特·布里姆、艾伦·克拉克、路易斯·米格尔·孔特雷拉斯·穆里洛、蒂姆·科普利、琳达·邓巴、肯·格雷、丹尼斯·古坎、戴夫·胡德、乔治·卡拉吉安尼斯、普密普·哈斯纳比什、斯利甘内斯·基尼、拉姆基·克里希南、德克·库彻、迭戈·洛佩斯、斯科特·曼斯菲尔德、，Pedro Martinez Julia、David E.Mcdysan、Erik Nordmark、Carlos Pignataro、Robert Raszuk、Bless Roland、Francisco Javier Ros Munoz、Dimitri Staessens、Yaakov Stein、Eve Varma、Stuart Venters、Russ White和Lee Young在IETF 88、IETF 89和IETF 90以及SDNRG邮件列表上发表了评论和讨论，我们在修改本文件时考虑到了这一点。
We would also like to thank (in alphabetical order) Spencer Dawkins and Eliot Lear for their IRSG reviews, which further refined this document.
我们还要感谢（按字母顺序）斯宾塞·道金斯和艾略特·李尔对IRSG的评论，这进一步完善了本文件。
Finally, we thank Nobo Akiya for his review of the section on BFD, Julien Meuric for his review of the section on PCE, and Adrian Farrel and Benoit Claise for their IESG reviews of this document.
最后，我们感谢Nobo Akiya对BFD部分的审查，Julien Meuria对PCE部分的审查，以及Adrian Farrel和Benoit Claise对本文件的IESG审查。
Kostas Pentikousis is supported by [ALIEN], a research project partially funded by the European Community under the Seventh Framework Program (grant agreement no. 317880). The views expressed here are those of the author only. The European Commission is not liable for any use that may be made of the information in this document.
Kostas Pentikousis由[ALIEN]支持，该研究项目由欧洲共同体根据第七个框架计划（第317880号赠款协议）部分资助。这里表达的观点仅是作者的观点。欧盟委员会对可能使用本文件中的信息不承担任何责任。
Contributors
贡献者
The authors would like to acknowledge (in alphabetical order) the following persons as contributors to this document. They all provided text, pointers, and comments that made this document more complete:
作者希望（按字母顺序）确认以下人士为本文件的撰稿人。他们都提供了文本、指针和注释，使本文档更加完整：
o Daniel King for providing text related to PCEP.
o Daniel King提供与PCEP相关的文本。
o Scott Mansfield for information regarding current ITU work on SDN.
o 斯科特·曼斯菲尔德（Scott Mansfield），了解国际电联目前在SDN方面的工作。
o Yaakov Stein for providing text related to the CAP theorem and SDO-related information.
o Yaakov Stein提供了与CAP定理和SDO相关信息相关的文本。
o Russ White for text suggestions on the definitions of control, management, and application.
o Russ White提供有关控制、管理和应用定义的文本建议。
Authors' Addresses
作者地址
Evangelos Haleplidis (editor) University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
Evangelos Haleplidis（编辑）佩特雷大学电气与计算机工程系帕特雷希腊26500
EMail: ehalep@ece.upatras.gr
EMail: ehalep@ece.upatras.gr
Kostas Pentikousis (editor) EICT GmbH Torgauer Strasse 12-15 10829 Berlin Germany
Kostas Pentikousis（编辑）EICT GmbH Torgauer Strasse 12-15 10829德国柏林
EMail: k.pentikousis@eict.de
EMail: k.pentikousis@eict.de
Spyros Denazis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
佩特雷大学电气与计算机工程系帕特雷26500希腊分校
EMail: sdena@upatras.gr
EMail: sdena@upatras.gr
Jamal Hadi Salim Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada
Jamal Hadi Salim Mojatatu Networks 400套房，303 Moodie Dr.渥太华，加拿大安大略省K2H 9R4
EMail: hadi@mojatatu.com
EMail: hadi@mojatatu.com
David Meyer Brocade
大卫·迈耶·博科
EMail: dmm@1-4-5.net
EMail: dmm@1-4-5.net
Odysseas Koufopavlou University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
OdssSoukoufopav娄佩特雷大学电气与计算机工程系帕特雷26500希腊
EMail: odysseas@ece.upatras.gr
EMail: odysseas@ece.upatras.gr