Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7149 C. Jacquenet
Category: Informational France Telecom
ISSN: 2070-1721 March 2014
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7149 C. Jacquenet
Category: Informational France Telecom
ISSN: 2070-1721 March 2014
Software-Defined Networking: A Perspective from within a Service Provider Environment
软件定义的网络：服务提供商环境中的视角
Abstract
摘要
Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.
在过去的几年里，软件定义网络（SDN）一直是网络行业的主要流行语之一。然而，到目前为止，SDN实际涵盖的内容还没有一个明确的定义被广泛接受。本文档旨在从服务提供商环境的角度，通过提供有关SDN的需求、问题和其他注意事项的观点，阐明SDN的前景。
It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.
它不是要无休止地讨论SDN的真正含义，而是要提出SDN保护伞下可使用的技术的功能分类法，并详细说明这些技术的联合激活不可避免地会引起的各种未决问题。因此，提及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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc7149.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7149.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Introducing Software-Defined Networking .........................4
2.1. A Tautology? ...............................................4
2.2. On Flexibility .............................................4
2.3. A Tentative Definition .....................................5
2.4. Functional Metadomains .....................................6
3. Reality Check ...................................................6
3.1. Remember the Past ..........................................7
3.2. Be Pragmatic ...............................................8
3.3. Measure Experience against Expectations ....................8
3.4. Design Carefully ...........................................9
3.5. On OpenFlow ................................................9
3.6. Non-goals .................................................10
4. Discussion .....................................................11
4.1. Implications of Full Automation ...........................11
4.2. Bootstrapping an SDN ......................................12
4.3. Operating an SDN ..........................................14
4.4. The Intelligence Resides in the PDP .......................15
4.5. Simplicity and Adaptability vs. Complexity ................16
4.6. Performance and Scalability ...............................16
4.7. Risk Assessment ...........................................17
5. Security Considerations ........................................17
6. Acknowledgements ...............................................18
7. Informative References .........................................18
1. Introduction ....................................................3
2. Introducing Software-Defined Networking .........................4
2.1. A Tautology? ...............................................4
2.2. On Flexibility .............................................4
2.3. A Tentative Definition .....................................5
2.4. Functional Metadomains .....................................6
3. Reality Check ...................................................6
3.1. Remember the Past ..........................................7
3.2. Be Pragmatic ...............................................8
3.3. Measure Experience against Expectations ....................8
3.4. Design Carefully ...........................................9
3.5. On OpenFlow ................................................9
3.6. Non-goals .................................................10
4. Discussion .....................................................11
4.1. Implications of Full Automation ...........................11
4.2. Bootstrapping an SDN ......................................12
4.3. Operating an SDN ..........................................14
4.4. The Intelligence Resides in the PDP .......................15
4.5. Simplicity and Adaptability vs. Complexity ................16
4.6. Performance and Scalability ...............................16
4.7. Risk Assessment ...........................................17
5. Security Considerations ........................................17
6. Acknowledgements ...............................................18
7. Informative References .........................................18
The Internet has become the federative network that supports a wide range of service offerings. The delivery of network services such as IP VPNs assumes the combined activation of various capabilities that include (but are not necessarily limited to) forwarding and routing (e.g., customer-specific addressing scheme management, dynamic path computation to reach a set of destination prefixes, dynamic establishment of tunnels, etc.); Quality of Service (e.g., traffic classification, marking, conditioning, and scheduling); security (e.g., filters to protect customer premises from network-originated attacks, to avoid malformed route announcements, etc.); and management (e.g., fault detection and processing).
互联网已成为支持各种服务的联邦网络。IP VPN等网络服务的交付假设各种能力的组合激活，包括（但不一定限于）转发和路由（例如，特定于客户的寻址方案管理、到达一组目的地前缀的动态路径计算、隧道的动态建立等）；服务质量（例如，交通分类、标记、调节和调度）；安全性（例如，保护客户场所免受网络攻击的过滤器，避免错误的路线公告等）；和管理（例如，故障检测和处理）。
As these services not only grow in variety but also in complexity, their design, delivery, and operation have become a complex alchemy that often requires various levels of expertise. This situation is further aggravated by the wide variety of (network) protocols and tools, as well as recent convergence trends driven by Any Time, Any Where, Any Device (ATAWAD); ATAWADs are meant to make sure that an end user can access the whole range of services he/she has subscribed to whatever the access and device technologies, wherever the end user is connected to the network, and whether or not this end user is in motion.
随着这些服务不仅在种类上而且在复杂性上的增长，它们的设计、交付和操作已经成为一种复杂的炼金术，通常需要不同级别的专业知识。各种各样的（网络）协议和工具，以及由任何时间、任何地点、任何设备（ATAWAD）推动的最近的融合趋势，进一步加剧了这种情况；ATAWADs旨在确保最终用户能够访问他/她已订阅的所有服务，无论访问和设备技术如何，无论最终用户连接到网络的何处，以及该最终用户是否处于活动状态。
Yet, most of these services have been deployed for the past decade, primarily based upon often static service production procedures that are more and more exposed to the risk of erroneous configuration commands. In addition, most of these services do not assume any specific negotiation between the customer and the service provider or between service providers, besides the typical financial terms.
然而，这些服务中的大多数都是在过去十年中部署的，主要基于静态的服务生产过程，这些过程越来越容易受到错误配置命令的风险。此外，除典型的财务条款外，这些服务中的大多数并不承担客户与服务提供商之间或服务提供商之间的任何特定谈判。
At best, five-year master plans are referred to as the network planning policy that will be enforced by the service provider given the foreseen business development perspectives, manually computed traffic forecasts, and market coverage (fixed/mobile and residential/ corporate). This so-called network planning policy may very well affect the way resources are allocated in a network, but it clearly fails to be adequately responsive to highly dynamic customer requirements in an "always-on" fashion. The need for improved service delivery procedures (including the time it takes to deliver the service once the possible negotiation phase is completed) is even more critical for corporate customers.
充其量，五年总体规划被称为网络规划政策，服务提供商将根据预期的业务发展前景、手动计算的流量预测和市场覆盖率（固定/移动和住宅/公司）实施该政策。这种所谓的网络规划策略很可能会影响网络中资源的分配方式，但它显然无法以“始终在线”的方式充分响应高度动态的客户需求。对公司客户来说，改进服务交付程序（包括在可能的谈判阶段完成后交付服务所需的时间）的需求更为关键。
In addition, various tools are used for different, sometimes service-centric, management purposes, but their usage is not necessarily coordinated for event aggregation, correlation, and processing. This lack of coordination may come at the cost of extra complexity and possible customer Quality-of-Experience degradation.
此外，各种工具用于不同的（有时是以服务为中心的）管理目的，但它们的使用不一定协调用于事件聚合、关联和处理。这种缺乏协调性的代价可能是额外的复杂性和可能的客户体验质量下降。
Multi-service, multi-protocol, multi-technology-convergent, and dynamically adaptive networking environments of the near future have therefore become one of the major challenges faced by service providers.
因此，在不久的将来，多业务、多协议、多技术融合和动态自适应的网络环境已成为服务提供商面临的主要挑战之一。
This document aims to clarify the SDN landscape by providing a perspective on the functional taxonomy of the techniques that can be used in SDN, as seen from within a service provider environment.
本文档旨在通过从服务提供商环境中观察SDN中可使用的技术的功能分类来阐明SDN的前景。
The separation of the forwarding and control planes (beyond implementation considerations) has almost become a gimmick to promote flexibility as a key feature of the SDN approach. Technically, most of the current router implementations have been assuming this separation for decades. Routing processes (such as IGP and BGP route computation) have often been software based, while forwarding capabilities are usually implemented in hardware.
转发和控制平面的分离（除了实现方面的考虑之外）几乎已经成为一个噱头，以促进灵活性，将其作为SDN方法的一个关键特性。从技术上讲，目前大多数路由器的实现几十年来一直假设这种分离。路由过程（如IGP和BGP路由计算）通常基于软件，而转发功能通常在硬件中实现。
As such, at the time of writing, what is considered to be state of the art tends to confirm the said separation, which rather falls under a tautology.
因此，在写作时，被认为是最先进的技术倾向于确认上述分离，而这属于重言式。
But, a somewhat centralized, "controller-embedded", control plane for the sake of optimized route computation before the Forwarding Information Base (FIB) population is certainly another story.
但是，在转发信息库（FIB）填充之前，为了优化路由计算而使用某种集中的“嵌入式控制器”控制平面肯定是另一回事。
Promoters of SDN have argued that it provides additional flexibility in how the network is operated. This is undoubtedly one of the key objectives that must be achieved by service providers. This is because the ability to dynamically adapt to a wide range of customer requests for flexible network service delivery is an important competitive advantage. But, flexibility is much, much more than separating the control and forwarding planes to facilitate forwarding decision-making processes.
SDN的发起人认为，SDN为网络的运营提供了额外的灵活性。这无疑是服务提供者必须实现的关键目标之一。这是因为能够动态地适应客户的各种要求，以实现灵活的网络服务交付是一项重要的竞争优势。但是，灵活性远不止是分离控制平面和转发平面以促进转发决策过程。
For example, the ability to accommodate short duration extra bandwidth requirements so that end users can stream a video file to their 4G terminal device is an example of the flexibility that several mobile operators are currently investigating.
例如，能够满足短期额外带宽需求，以便最终用户能够将视频文件流式传输到他们的4G终端设备，这是几个移动运营商目前正在研究的灵活性的一个例子。
From this perspective, the ability to predict the network behavior as a function of the network services to be delivered is of paramount importance for service providers, so that they can assess the impact of introducing new services or activating additional network features or enforcing a given set of (new) policies from both financial and technical standpoints. This argues in favor of investigating advanced network emulation engines, which can be fed with information that can be derived from [LS-DISTRIB], for example.
从这个角度来看，预测网络行为作为要交付的网络服务功能的能力对于服务提供商来说是至关重要的，以便他们能够评估引入新服务或激活其他网络功能或强制实施给定的一组（新）服务的影响从财务和技术角度制定政策。这表明有利于研究高级网络仿真引擎，例如，可以从[LS-DISTRIB]获取信息。
Given the rather broad scope that the term "flexibility" suggests:
鉴于“灵活性”一词所指的范围相当广泛：
o Current SDN-labeled solutions are claimed to be flexible, although the notion is hardly defined. The exact characterization of what flexibility actually means is yet to be provided. Further work needs, therefore, to be conducted so that flexibility can be precisely defined in light of various criteria such as network evolution capabilities as a function of the complexity introduced by the integration of SDN techniques and seamless capabilities (i.e., the ability to progressively introduce SDN-enabled devices without disrupting network and service operation, etc.).
o 目前SDN标签的解决方案被认为是灵活的，尽管这个概念很难定义。至于灵活性究竟意味着什么，目前尚不清楚。因此，需要开展进一步的工作，以便能够根据各种标准精确定义灵活性，例如网络进化能力，作为SDN技术和无缝能力集成引入的复杂性的函数（即，在不中断网络和服务运行等情况下逐步引入支持SDN的设备的能力）。
o The exposure of programmable interfaces is not a goal per se; rather, it is a means to facilitate configuration procedures for improved flexibility.
o 可编程接口的公开本身不是一个目标；相反，它是一种促进配置过程以提高灵活性的方法。
We define Software-Defined Networking as the set of techniques used to facilitate the design, delivery, and operation of network services in a deterministic, dynamic, and scalable manner. The said determinism refers to the ability to completely master the various components of the service delivery chain, so that the service that has been delivered complies with what has been negotiated and contractually defined with the customer.
我们将软件定义的网络定义为一组技术，用于以确定性、动态和可扩展的方式促进网络服务的设计、交付和操作。所述决定论是指完全掌握服务交付链的各个组成部分的能力，以便已交付的服务符合与客户协商和合同定义的内容。
As such, determinism implies that the ability to control how network services are structured, designed, and delivered and where traffic should be forwarded in the network is for optimized resource usage. Although not explicitly restated in the following sections of the document, determinism lies beneath any action that may be taken by a service provider once service parameter negotiation is completed, from configuration tasks to service delivery, fulfillment, and assurance (see Section 2.4 below).
因此，决定论意味着控制网络服务的结构、设计和交付方式以及流量在网络中的转发位置的能力是为了优化资源使用。尽管本文件以下章节未明确重申，但服务供应商一旦完成服务参数协商，从配置任务到服务交付、履行和保证（见下文第2.4节），可能采取的任何行动都具有决定性。
Such a definition assumes the introduction of a high level of automation in the overall service delivery and operation procedures.
这种定义假设在整个服务提供和操作过程中引入了高水平的自动化。
Because networking is software driven by nature, the above definition does not emphasize the claimed "software-defined" properties of SDN-labeled solutions.
由于网络是由自然驱动的软件，上述定义并不强调SDN标记的解决方案声称的“软件定义”属性。
SDN techniques can be classified into the following functional metadomains:
SDN技术可分为以下功能元域：
o Techniques for the dynamic discovery of network topology, devices, and capabilities, along with relevant information and data models that are meant to precisely document such topology, devices, and their capabilities.
o 用于动态发现网络拓扑、设备和功能的技术，以及用于精确记录此类拓扑、设备及其功能的相关信息和数据模型。
o Techniques for exposing network services and their characteristics and for dynamically negotiating the set of service parameters that will be used to measure the level of quality associated with the delivery of a given service or a combination thereof. An example of this can be seen in [CPP].
o 用于公开网络服务及其特征以及动态协商将用于测量与给定服务或其组合的交付相关联的质量水平的服务参数集的技术。这方面的一个例子可以在[CPP]中看到。
o Techniques used by service-requirement-derived dynamic resource allocation and policy enforcement schemes, so that networks can be programmed accordingly. Decisions made to dynamically allocate resources and enforce policies are typically the result of the correlation of various inputs, such as the status of available resources in the network at any given time, the number of customer service subscription requests that need to be processed over a given period of time, the traffic forecasts, the possible need to trigger additional resource provisioning cycles according to a typical multi-year master plan, etc.
o 服务需求使用的技术派生出动态资源分配和策略实施方案，从而可以相应地对网络进行编程。动态分配资源和实施策略的决策通常是各种输入相互关联的结果，例如任何给定时间网络中可用资源的状态、在给定时间段内需要处理的客户服务订阅请求的数量、流量预测、，根据典型的多年总体规划等，可能需要触发额外的资源供应周期。
o Dynamic feedback mechanisms that are meant to assess how efficiently a given policy (or a set thereof) is enforced from a service fulfillment and assurance perspective.
o 动态反馈机制，用于从服务实现和保证的角度评估给定策略（或其集合）的执行效率。
The networking ecosystem has become awfully complex and highly demanding in terms of robustness, performance, scalability, flexibility, agility, etc. This means, in particular, that service providers and network operators must deal with such complexity and operate networking infrastructures that can evolve easily, remain scalable, guarantee robustness and availability, and are resilient to denial-of-service attacks.
网络生态系统在健壮性、性能、可扩展性、灵活性、敏捷性等方面变得极其复杂，要求极高。这尤其意味着，服务提供商和网络运营商必须应对这种复杂性，并运营能够轻松发展、保持可伸缩性的网络基础设施，保证健壮性和可用性，并且能够抵御拒绝服务攻击。
The introduction of new SDN-based networking features should obviously take into account this context, especially from a cost impact assessment perspective.
引入新的基于SDN的网络功能显然应该考虑到这一背景，特别是从成本影响评估的角度。
SDN techniques are not the next big thing per se but rather a kind of rebranding of proposals that have been investigated for several years, like active or programmable networks [AN] [PN]. As a matter of fact, some of the claimed "new" SDN features have been already implemented (e.g., Network Management System (NMS) and Path Computation Element (PCE) [RFC4655]) and supported by vendors for quite some time.
SDN技术本身并不是下一件大事，而是对已经研究了好几年的提案（如主动或可编程网络[AN][PN]）的一种重新命名。事实上，一些声称的“新”SDN特性已经实现（例如，网络管理系统（NMS）和路径计算元件（PCE）[RFC4655]），并且已经被供应商支持了相当长的一段时间。
Some of these features have also been standardized (e.g., DNS-based routing [RFC1383]) that can be seen as an illustration of separated control and forwarding planes or Forwarding and Control Element Separation (ForCES) [RFC5810] [RFC5812].
其中一些功能也已经标准化（例如，基于DNS的路由[RFC1383]），可以看作是分离的控制和转发平面或转发和控制元素分离（强制）[RFC5810][RFC5812]的图示。
Also, the policy-based management framework [RFC2753] introduced in the early 2000's was designed to orchestrate available resources by means of a typical Policy Decision Point (PDP), which masters advanced offline traffic engineering capabilities. As such, this framework has the ability to interact with in-band software modules embedded in controlled devices (or not).
此外，2000年代初引入的基于策略的管理框架[RFC2753]旨在通过一个典型的策略决策点（PDP）来协调可用资源，该决策点掌握了先进的离线流量工程能力。因此，该框架能够与嵌入（或不嵌入）受控设备中的带内软件模块进行交互。
PDP is where policy decisions are made. PDPs use a directory service for policy repository purposes. The policy repository stores the policy information that can be retrieved and updated by the PDP. The PDP delivers policy rules to the Policy Enforcement Point (PEP) in the form of policy-provisioning information that includes configuration information.
PDP是制定政策决策的地方。PDP将目录服务用于策略存储库目的。策略存储库存储可由PDP检索和更新的策略信息。PDP以包含配置信息的策略供应信息的形式将策略规则传递给策略实施点（PEP）。
PEP is where policy decisions are applied. PEPs are embedded in (network) devices, which are dynamically configured based upon the policy-formatted information that has been processed by the PEP. PEPs request configuration from the PDP, store the configuration information in the Policy Information Base (PIB), and delegate any policy decision to the PDP.
政治公众人物是应用政策决策的地方。PEP嵌入在（网络）设备中，这些设备根据PEP处理的策略格式信息进行动态配置。PEP从PDP请求配置，将配置信息存储在策略信息库（PIB）中，并将任何策略决策委托给PDP。
SDN techniques as a whole are an instantiation of the policy-based management framework. Within this context, SDN techniques can be used to activate capabilities on demand, to dynamically invoke network and storage resources, and to operate dynamically adaptive networks according to events (e.g., alteration of the network topology), triggers (e.g., dynamic notification of a link failure), etc.
SDN技术作为一个整体是基于策略的管理框架的一个实例。在此上下文中，SDN技术可用于按需激活功能，动态调用网络和存储资源，并根据事件（例如，网络拓扑的改变）、触发器（例如，链路故障的动态通知）等操作动态自适应网络。
SDN approaches should be holistic, i.e., global and network wide. It is not a matter of configuring devices one by one to enforce a specific forwarding policy. Instead, SDN techniques are about configuring and operating a whole range of devices at the scale of the network for automated service delivery [AUTOMATION], from service negotiation (e.g., [CPNP]) and creation (e.g., [SLA-EXCHANGE]) to assurance and fulfillment.
SDN方法应该是整体的，即全球和网络范围的。这不是逐个配置设备以实施特定转发策略的问题。相反，SDN技术是在网络规模上配置和操作一系列设备，以实现自动化服务交付[AUTOMATION]，从服务协商（例如[CPNP]）和创建（例如[SLA-EXCHANGE]）到保证和实现。
Because the complexity of activating SDN capabilities is largely hidden from the end user and is software handled, a clear understanding of the overall ecosystem is needed to figure out how to manage this complexity and to what extent this hidden complexity does not have side effects on network operation.
由于激活SDN功能的复杂性在很大程度上是对最终用户隐藏的，并且是由软件处理的，因此需要对整个生态系统有一个清晰的了解，以了解如何管理这种复杂性，以及这种隐藏的复杂性在多大程度上不会对网络运行产生副作用。
As an example, SDN designs that assume a central decision-making entity must avoid single points of failure. They must not affect packet forwarding performances either (e.g., transit delays must not be impacted).
例如，假设中央决策实体的SDN设计必须避免单点故障。它们也不得影响数据包转发性能（例如，不得影响传输延迟）。
SDN techniques are not necessary to develop new network services per se. The basic service remains as (IP) connectivity that solicits resources located in the network. SDN techniques can thus be seen as another means to interact with network service modules and invoke both connectivity and storage resources accordingly in order to meet service-specific requirements.
开发新的网络服务本身并不需要SDN技术。基本服务保持为（IP）连接，请求位于网络中的资源。因此，SDN技术可以被视为与网络服务模块交互并相应地调用连接和存储资源以满足特定于服务的需求的另一种手段。
By definition, SDN technique activation and operation remain limited to what is supported by embedded software and hardware. One cannot expect SDN techniques to support unlimited customizable features.
根据定义，SDN技术的激活和操作仍然限于嵌入式软件和硬件支持的内容。不能指望SDN技术支持无限的可定制功能。
Because several software modules may be controlled by external entities (typically, a PDP), there is a need for a means to make sure that what has been delivered complies with what has been negotiated. Such means belong to the set of SDN techniques.
由于多个软件模块可能由外部实体（通常为PDP）控制，因此需要一种方法来确保交付的内容符合协商的内容。这种方法属于SDN技术的集合。
These typical policy-based techniques should interact with both Service Structuring engines (that are meant to expose the service characteristics and possibly negotiate those characteristics) and the network to continuously assess whether the experienced network behavior is compliant with the objectives set by the Service Structuring engine and those that may have been dynamically negotiated with the customer (e.g., as captured in a CPP [CPP] [CPNP]). This requirement applies to several regions of a network, including:
这些典型的基于策略的技术应该与两个服务结构引擎交互（这意味着公开服务特征，并可能协商这些特征）以及网络，以持续评估经验丰富的网络行为是否符合服务结构化引擎设定的目标以及可能已与客户动态协商的目标（例如，如在CPP[CPP][CPNP]中捕获的目标）。该要求适用于网络的多个区域，包括：
1. At the interface between two adjacent IP network providers.
1. 在两个相邻IP网络提供商之间的接口处。
2. At the access interface between a service provider and an IP network provider.
2. 在服务提供商和IP网络提供商之间的访问接口上。
3. At the interface between a customer and the IP network provider.
3. 在客户和IP网络提供商之间的接口处。
Ideally, a fully automated service delivery procedure, from negotiation, ordering, and order processing to delivery, assurance, and fulfillment, should be supported at the cost of implications that are discussed in Section 4.1. This approach also assumes widely adopted standard data and information models in addition to interfaces.
理想情况下，应支持从谈判、订购和订单处理到交付、保证和履行的全自动服务交付流程，但应以第4.1节中讨论的影响为代价。除接口外，该方法还假设广泛采用的标准数据和信息模型。
Exposing open and programmable interfaces has a cost from both scalability and performance standpoints.
从可伸缩性和性能角度来看，公开开放和可编程接口都有成本。
Maintaining hard-coded performance optimization techniques is encouraged. So is the use of interfaces that allow the direct control of some engines (e.g., routing and forwarding) without requiring any in-between adaptation layers (generic objects to vendor-specific command line interfaces (CLIs), for instance). Nevertheless, the use of vendor-specific access means to some engines that it could be beneficial from a performance standpoint, at the cost of increasing the complexity of configuration tasks.
鼓励使用硬编码性能优化技术。使用允许直接控制某些引擎（例如，路由和转发）而不需要任何中间适配层（例如，供应商特定命令行接口（CLI）的通用对象）的接口也是如此。然而，使用特定于供应商的访问意味着从性能的角度来看，对某些引擎可能是有益的，但代价是增加配置任务的复杂性。
SDN techniques will have to accommodate vendor-specific components anyway. Indeed, these vendor-specific features will not cease to exist mainly because of the harsh competition.
SDN技术无论如何都必须适应特定于供应商的组件。事实上，这些特定于供应商的功能不会因为激烈的竞争而停止存在。
The introduction of new functions or devices that may jeopardize network flexibility should be avoided or at least carefully considered in light of possible performance and scalability impacts. SDN-enabled devices will have to coexist with legacy systems.
应避免引入可能危及网络灵活性的新功能或设备，或至少根据可能的性能和可伸缩性影响仔细考虑。支持SDN的设备必须与遗留系统共存。
One single SDN network-wide deployment is, therefore, very unlikely. Instead, multiple instantiations of SDN techniques will be progressively deployed and adapted to various network and service segments.
因此，在整个网络范围内部署一个SDN是非常不可能的。相反，SDN技术的多个实例将逐步部署并适应各种网络和服务段。
Empowering networking with in-band controllable modules may rely upon the OpenFlow protocol but also use other protocols to exchange information between a control plane and a data plane.
通过带内可控模块实现联网可能依赖于OpenFlow协议，但也可以使用其他协议在控制平面和数据平面之间交换信息。
Indeed, there are many other candidate protocols that can be used for the same or even a broader purpose (e.g., resource reservation purposes). The forwarding of the configuration information can, for example, rely upon protocols like the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440], the Network Configuration Protocol (NETCONF) [RFC6241], COPS Usage for Policy Provisioning (COPS-PR) [RFC3084], Routing Policy Specification Language (RPSL) [RFC2622], etc.
事实上，还有许多其他候选协议可用于相同甚至更广泛的目的（例如，资源保留目的）。例如，配置信息的转发可以依赖于诸如路径计算元素（PCE）通信协议（PCEP）[RFC5440]、网络配置协议（NETCONF）[rfc621]、用于策略供应的COPS使用（COPS-PR）[RFC3084]、路由策略规范语言（RPSL）[RFC2622]等协议。
There is, therefore, no 1:1 relationship between OpenFlow and SDN. Rather, OpenFlow is one of the candidate protocols to convey specific configuration information towards devices. As such, OpenFlow is one possible component of the global SDN toolkit.
因此，OpenFlow和SDN之间没有1:1的关系。相反，OpenFlow是向设备传递特定配置信息的候选协议之一。因此，OpenFlow可能是全局SDN工具包的一个组件。
There are inevitable trade-offs to be found between operating the current networking ecosystem and introducing some SDN techniques, possibly at the cost of introducing new technologies. Operators do not have to choose between the two as both environments will have to coexist.
在操作当前的网络生态系统和引入一些SDN技术之间，不可避免地要进行权衡，可能要以引入新技术为代价。运营商不必在这两种环境之间进行选择，因为这两种环境必须共存。
In particular, the following considerations cannot justify the deployment of SDN techniques:
特别是，以下考虑因素不能证明SDN技术的部署是合理的：
o Fully flexible software implementations because the claimed flexibility remains limited by the software and hardware limitations, anyway.
o 完全灵活的软件实现，因为所声称的灵活性仍然受到软件和硬件限制的限制。
o Fully modular implementations are difficult to achieve (because of the implicit complexity) and may introduce extra effort for testing, validation, and troubleshooting.
o 完全模块化的实现很难实现（因为隐含的复杂性），并且可能会为测试、验证和故障排除带来额外的工作量。
o Fully centralized control systems that are likely to raise some scalability issues. Distributed protocols and their ability to react to some events (e.g., link failure) in a timely manner remains a cornerstone of scalable networks. This means that SDN designs can rely upon a logical representation of centralized features (an abstraction layer that would support inter-PDP communications, for example).
o 完全集中的控制系统可能会引起一些可伸缩性问题。分布式协议及其对某些事件（如链路故障）做出及时反应的能力仍然是可扩展网络的基石。这意味着SDN设计可以依赖于集中式功能的逻辑表示（例如，支持PDP间通信的抽象层）。
The path towards full automation is paved with numerous challenges and requirements, including:
实现全自动化的道路面临诸多挑战和要求，包括：
o Making sure automation is well implemented so as to facilitate testing (including validation checks) and troubleshooting.
o 确保自动化良好实施，以便于测试（包括验证检查）和故障排除。
* This suggests the need for simulation tools that accurately assess the impact of introducing a high level of automation in the overall service delivery procedure to avoid a typical "mad robot" syndrome, whose consequences can be serious from control and QoS standpoints, among others.
* 这表明需要模拟工具来准确评估在整个服务提供过程中引入高水平自动化的影响，以避免典型的“疯狂机器人”综合症，从控制和QoS等角度来看，其后果可能是严重的。
* This also suggests careful management of human expertise, so that network operators can use robust, flexible means to automate repetitive or error-prone tasks and then build on automation or stringing together multiple actions to create increasingly complex tasks that require less human interaction (guidance and input) to complete.
* 这还建议仔细管理人力专业知识，以便网络运营商可以使用稳健、灵活的手段自动化重复或容易出错的任务，然后在自动化的基础上构建或将多个操作串联在一起，以创建越来越复杂的任务，这些任务需要较少的人力交互（指导和输入）来完成。
o Simplifying and fostering service delivery, assurance, and fulfillment, as well as network failure detection, diagnosis, and root cause analysis for cost optimization.
o 简化和促进服务交付、保证和实现，以及网络故障检测、诊断和根本原因分析，以实现成本优化。
* Such cost optimization relates to improved service delivery times as well as optimized human expertise (see above) and global, technology-agnostic service structuring and delivery procedures. In particular, the ability to inject new functions in existing devices should not assume a replacement of the said devices but rather allow smart investment capitalization.
* 此类成本优化涉及改进的服务交付时间、优化的人力专业知识（见上文）以及全球技术无关的服务结构和交付程序。特别是，在现有设备中注入新功能的能力不应假设替换所述设备，而是允许智能投资资本化。
* This can be achieved thanks to automation, possibly based upon a logically centralized view of the network infrastructure (or a portion thereof), yielding the need for highly automated topology, device and capabilities discovery means, and operational procedures.
* 这可以通过自动化实现，可能基于网络基础设施（或其一部分）的逻辑集中视图，从而产生对高度自动化的拓扑、设备和功能发现手段以及操作过程的需求。
* The main intelligence resides in the PDP, which suggests that an important part of the SDN-related development effort should focus on a detailed specification of the PDP function, including algorithms and behavioral state machineries that are based upon a complete set of standardized data and information models.
* 主要智能存在于PDP中，这表明SDN相关开发工作的一个重要部分应关注PDP功能的详细规范，包括基于一整套标准化数据和信息模型的算法和行为状态机制。
* These information models and data need to be carefully structured for efficiency and flexibility. This probably suggests that a set of simplified pseudo-blocks can be assembled as per the nature of the service to be delivered.
* 这些信息模型和数据需要仔细构造，以提高效率和灵活性。这可能意味着可以根据要交付的服务的性质组装一组简化的伪块。
o The need for abstraction layers -- clear interfaces between business actors and between layers, let alone cross-layer considerations, etc. Such abstraction layers are invoked within the context of service structuring and packaging and are meant to facilitate the emergence of the following:
o 对抽象层的需求——业务参与者之间和层之间的清晰接口，更不用说跨层考虑因素等。此类抽象层在服务结构化和打包的上下文中调用，旨在促进以下方面的出现：
* IP connectivity service exposure to customers, peers, applications, content/service providers, etc. (an example of this can be seen in [CPP]).
* 向客户、对等方、应用程序、内容/服务提供商等提供IP连接服务（如[CPP]所示）。
* Solutions that accommodate IP connectivity service requirements with network engineering objectives.
* 满足IP连接服务要求和网络工程目标的解决方案。
* Dynamically adaptive decision-making processes, which can properly operate according to a set of input data and metrics, such as current resource usage and demand, traffic forecasts and matrices, etc., all for the sake of highly responsive dynamic resource allocation and policy enforcement schemes.
* 动态自适应决策过程，可根据一组输入数据和指标（如当前资源使用和需求、流量预测和矩阵等）正确运行，所有这些都是为了实现高度响应的动态资源分配和策略实施方案。
o Better accommodation of technologically heterogeneous networking environments through the following:
o 通过以下方式更好地适应技术异构的网络环境：
* Vendor-independent configuration procedures based upon the enforcement of vendor-agnostic generic policies instead of vendor-specific languages.
* 独立于供应商的配置过程基于实施与供应商无关的通用策略，而不是特定于供应商的语言。
* Tools to aid manageability and orchestrate resources.
* 用于帮助管理和协调资源的工具。
* Avoiding proxies and privileging direct interaction with engines (e.g., routing and forwarding).
* 避免代理和与引擎直接交互的特权（例如路由和转发）。
Means to dynamically discover the functional capabilities of the devices that will be steered by a PDP intelligence for automated network service delivery need to be provided. This is because the acquisition of the information related to what the network is actually capable of will help structure the PDP intelligence so that policy provisioning information can be derived accordingly.
需要提供动态发现将由PDP智能控制的设备功能能力的方法，以实现自动网络服务交付。这是因为获取与网络实际能力相关的信息将有助于构建PDP智能，从而可以相应地导出策略供应信息。
A typical example would consist in documenting a traffic engineering policy based upon the dynamic discovery of the various functions supported by the network devices, as a function of the services to be
一个典型的例子是，在动态发现网络设备支持的各种功能的基础上，将流量工程策略记录为服务的功能
delivered, thus yielding the establishment of different routes towards the same destination depending on the nature of the traffic, the location of the functions that need to be invoked to forward such traffic, etc.
交付，从而根据交通的性质、需要调用以转发此类交通的功能的位置等，建立通向同一目的地的不同路线。
Such dynamic discovery capability can rely upon the exchange of specific information by means of an IGP or BGP between network devices or between network devices and the PDP in legacy networking environments. The PDP can also send unsolicited commands towards network devices to acquire the description of their functional capabilities in return and derive network and service topologies accordingly.
这种动态发现能力可以依赖于在传统网络环境中通过IGP或BGP在网络设备之间或网络设备与PDP之间交换特定信息。PDP还可以向网络设备发送未经请求的命令，以获取其功能能力的描述，并相应地导出网络和服务拓扑。
Of course, SDN techniques (as introduced in Section 2.4) could be deployed in an IGP-/BGP-free networking environment, but the SDN bootstrapping procedure in such an environment still assumes the support of the following capabilities:
当然，SDN技术（如第2.4节所述）可以部署在无IGP-/BGP的网络环境中，但这种环境中的SDN引导过程仍然假设支持以下功能：
o Dynamically discover SDN participating nodes (including the PDP) and their respective capabilities in a resilient manner, assuming the mutual authentication of the PDP and the participating devices Section 5. The integrity of the information exchanged between the PDP and the participating devices during the discovery phase must also be preserved;
o 假设PDP和参与设备部分5的相互认证，以弹性方式动态地发现SDN参与节点（包括PDP）及其各自的能力。还必须保持PDP和参与设备之间在发现阶段交换的信息的完整性；
o Dynamically connect the PDP to the participating nodes and avoid any forwarding loops;
o 动态地将PDP连接到参与节点并避免任何转发循环；
o Dynamically enable network services as a function of the device capabilities and (possibly) what has been dynamically negotiated between the customer and the service provider;
o 根据设备能力和（可能的）客户与服务提供商之间动态协商的内容，动态启用网络服务；
o Dynamically check connectivity between the PDP and the participating nodes and between participating nodes for the delivery of a given network service (or a set thereof);
o 动态检查PDP和参与节点之间以及参与节点之间的连接，以交付给定网络服务（或其集合）；
o Dynamically assess the reachability scope as a function of the service to be delivered;
o 动态评估可达性范围，将其作为要提供的服务的函数；
o Dynamically detect and diagnose failures, and proceed with corrective actions accordingly.
o 动态检测和诊断故障，并相应地执行纠正措施。
Likewise, the means to dynamically acquire the descriptive information (including the base configuration) of any network device that may participate in the delivery of a given service should be provided so as to help the PDP structure the services that can be delivered as a function of the available resources, their location, etc.
类似地，应提供动态获取可参与给定服务的交付的任何网络设备的描述信息（包括基本配置）的手段，以帮助PDP根据可用资源、其位置等来构造可交付的服务。
In IGP-/BGP-free networking environments, a specific bootstrap protocol may thus be required to support the aforementioned capabilities for proper PDP- and SDN-capable device operation, in addition to the possible need for a specific additional network that would provide discovery and connectivity features.
因此，在无IGP-/BGP的网络环境中，除了可能需要提供发现和连接功能的特定附加网络外，还可能需要特定的引导协议来支持上述功能，以实现正确的PDP和SDN设备操作。
In particular, SDN design and operation in IGP-/BGP-free environments should provide performances similar to those of legacy environments that run an IGP and BGP. For example, the underlying network should remain operational even if connection with the PDP has been lost. Furthermore, operators should assess the cost of introducing a new, specific bootstrap protocol compared to the cost of integrating the aforementioned capabilities in existing IGP/BGP protocol machineries.
特别是，无IGP-/BGP环境中的SDN设计和操作应提供与运行IGP和BGP的传统环境类似的性能。例如，即使与PDP的连接已断开，底层网络也应保持运行。此外，运营商应评估引入新的特定引导协议的成本，与在现有IGP/BGP协议机制中集成上述功能的成本进行比较。
Since SDN-related features can be grafted into an existing network infrastructure, they may not be all enabled at once from a bootstrapping perspective; a gradual approach can be adopted instead.
由于SDN相关功能可以移植到现有的网络基础设施中，因此从引导的角度来看，它们可能不会一次全部启用；可以采取循序渐进的办法。
A typical deployment example would be to use an SDN decision-making process as an emulation platform that would help service providers and operators make appropriate technical choices before their actual deployment in the network.
典型的部署示例是使用SDN决策过程作为仿真平台，帮助服务提供商和运营商在实际部署到网络之前做出适当的技术选择。
Finally, the completion of the discovery procedure does not necessarily mean that the network is now fully operational. The operationality of the network usually assumes a robust design based upon resilience and high availability features.
最后，发现过程的完成并不一定意味着网络现在可以完全运行。网络的可操作性通常假设基于弹性和高可用性特征的稳健设计。
From an Operations and Management (OAM) standpoint [RFC6291], running an SDN-capable network raises several issues such as those listed below:
从运营和管理（OAM）的角度[RFC6291]来看，运行支持SDN的网络会引发以下问题：
o How do SDN service and network management blocks interact? For example, how the results of the dynamic negotiation of service parameters with a customer or a set thereof over a given period of time will affect the PDP decision-making process (resource allocation, path computation, etc.).
o SDN服务和网络管理块如何交互？例如，在给定时间段内与客户或其集合动态协商服务参数的结果将如何影响PDP决策过程（资源分配、路径计算等）。
o What should be the appropriate OAM tools for SDN network operation (e.g., to check PDP or PEP reachability)?
o SDN网络运行的适当OAM工具应该是什么（例如，检查PDP或PEP的可达性）？
o How can performance (expressed in terms of service delivery time, for example) be optimized when the activation of software modules is controlled by an external entity (typically a PDP)?
o 当软件模块的激活由外部实体（通常是PDP）控制时，如何优化性能（例如，以服务交付时间表示）？
o To what extent does an SDN implementation ease network manageability, including service and network diagnosis?
o SDN实施在多大程度上缓解了网络可管理性，包括服务和网络诊断？
o Should the "control and data plane separation" principle be applied to the whole network or a portion thereof, as a function of the nature of the services to be delivered or by taking into account the technology that is currently deployed?
o “控制和数据平面分离”原则是否应应用于整个网络或其一部分，作为所提供服务的性质的函数，或通过考虑当前部署的技术？
o What is the impact on the service provider's testing procedures and methodologies (that are used during validation and pre-deployment phases)? Particularly, (1) how test cases will be defined and executed when the activation of customized modules is supported, (2) what the methodology is to assess the behavior of SDN-controlled devices, (3) how test regression will be conducted, (4) etc.
o 对服务提供商的测试程序和方法（在验证和部署前阶段使用）有何影响？特别是，（1）当支持激活定制模块时，如何定义和执行测试用例，（2）评估SDN控制设备行为的方法，（3）如何进行测试回归，（4）等等。
o How do SDN techniques impact service fulfillment and assurance? How the resulting behavior of SDN devices (completion of configuration tasks, for example) should be assessed against what has been dynamically negotiated with a customer. How to measure the efficiency of dynamically enforced policies as a function of the service that has been delivered. How to measure that what has been delivered is compliant with what has been negotiated. What the impact is of SDN techniques on troubleshooting practice.
o SDN技术如何影响服务实现和保证？如何根据与客户动态协商的内容评估SDN设备的最终行为（例如，完成配置任务）。如何根据已交付的服务来衡量动态实施的策略的效率。如何衡量已交付的内容是否符合已协商的内容。SDN技术对故障排除实践的影响。
o Is there any risk to operate frozen architectures because of potential interoperability issues between a controlled device and an SDN controller?
o 由于受控设备和SDN控制器之间的潜在互操作性问题，是否存在操作冻结架构的风险？
o How does the introduction of SDN techniques affect the lifetime of legacy systems? Is there any risk of (rapidly) obsoleting existing technologies because of their hardware or software limitations?
o SDN技术的引入如何影响遗留系统的生命周期？是否存在因硬件或软件限制而（迅速）淘汰现有技术的风险？
The answers to the above questions are very likely to be service provider specific, depending on their technological and business environments.
上述问题的答案很可能是针对服务提供商的，具体取决于他们的技术和业务环境。
The proposed SDN definition in Section 2.3 assumes an intelligence that may reside in the control or the management planes (or both). This intelligence is typically represented by a Policy Decision Point (PDP) [RFC2753], which is one of the key functional components of the policy-based management framework.
第2.3节中提出的SDN定义假设智能可能驻留在控制或管理平面（或两者）中。这种智能通常由策略决策点（PDP）[RFC2753]表示，它是基于策略的管理框架的关键功能组件之一。
SDN networking, therefore, relies upon PDP functions that are capable of processing various input data (traffic forecasts, outcomes of negotiation between customers and service providers, resource status as depicted in appropriate information models instantiated in the PIB, etc.) to make appropriate decisions.
因此，SDN网络依赖能够处理各种输入数据（流量预测、客户和服务提供商之间的协商结果、PIB中实例化的适当信息模型中描述的资源状态等）的PDP功能来做出适当的决策。
The design and the operation of such PDP-based intelligence in a scalable manner remains a part of the major areas that need to be investigated.
以可扩展的方式设计和运行此类基于PDP的智能仍然是需要研究的主要领域的一部分。
To avoid centralized design schemes, inter-PDP communication is likely to be required, and corresponding issues and solutions should be considered. Several PDP instances may thus be activated in a given domain. Because each of these PDP instances may be responsible for making decisions about the enforcement of a specific policy (e.g., one PDP for QoS policy enforcement purposes, another one for security policy enforcement purposes, etc.), an inter-PDP communication scheme is required for global PDP coordination and correlation.
为避免集中式设计方案，可能需要PDP之间的通信，并应考虑相应的问题和解决方案。因此，可以在给定域中激活多个PDP实例。由于这些PDP实例中的每一个都可能负责做出关于特定策略实施的决策（例如，一个PDP用于QoS策略实施，另一个PDP用于安全策略实施等），因此需要一个PDP间通信方案来进行全局PDP协调和关联。
Inter-domain PDP exchanges may also be needed for specific usages. Examples of such exchanges are as follows: (1) during the network attachment phase of a node to a visited network, the PDP operated by the visited network can contact the home PDP to retrieve the policies to be enforced for that node, and (2) various PDPs can collaborate in order to compute inter-domain paths that satisfy a set of traffic performance guarantees.
特定用途也可能需要域间PDP交换。此类交换的示例如下：（1）在节点到到访网络的网络连接阶段期间，由到访网络操作的PDP可以联系归属PDP以检索要为该节点实施的策略，以及（2）各种PDP可以协作以计算满足一组流量性能保证的域间路径。
The functional metadomains introduced in Section 2.4 assume the introduction of a high level of automation, from service negotiation to delivery and operation. Automation is the key to simplicity, but it must not be seen as a magic button that would be hit by a network administrator whenever a customer request has to be processed or additional resources need to be allocated.
第2.4节中介绍的功能元域假设引入了高级别的自动化，从服务协商到交付和操作。自动化是简单性的关键，但它不能被视为一个神奇的按钮，当必须处理客户请求或需要分配额外资源时，网络管理员就会按下这个按钮。
The need for simplicity and adaptability, thanks to automated procedures, generally assumes some complexity that lies beneath automation.
由于自动化程序的存在，对简单性和适应性的需求通常假定自动化之下存在一些复杂性。
The combination of flexibility with software inevitably raises performance and scalability issues as a function of the number and the nature of the services to be delivered and their associated dynamics.
灵活性与软件的结合不可避免地带来了性能和可伸缩性问题，这是要交付的服务的数量和性质及其相关动态的函数。
For example, networks deployed in Data Centers (DCs) and that rely upon OpenFlow switches are unlikely to raise important FIB scalability issues. Conversely, DC interconnect designs that aim to dynamically manage Virtual Machine (VM) mobility, possibly based upon the dynamic enforcement of specific QoS policies, may raise scalability issues.
例如，部署在数据中心（DC）中并依赖OpenFlow交换机的网络不太可能引发重要的FIB可伸缩性问题。相反，旨在动态管理虚拟机（VM）移动性的DC互连设计（可能基于特定QoS策略的动态实施）可能会引发可伸缩性问题。
The claimed flexibility of SDN networking in the latter context will have to be carefully investigated by operators.
运营商必须仔细调查SDN网络在后一种情况下声称的灵活性。
Various risks are to be assessed such as:
应评估各种风险，例如：
o Evaluating the risk of depending on a controller technology rather than a device technology.
o 评估依赖控制器技术而非设备技术的风险。
o Evaluating the risk of operating frozen architectures because of potential interoperability issues between a controller and a controlled device.
o 评估由于控制器和受控设备之间潜在的互操作性问题而导致操作冻结架构的风险。
o Assessing whether SDN-labeled solutions are likely to obsolete existing technologies because of hardware limitations. From a technical standpoint, the ability to dynamically provision resources as a function of the services to be delivered may be incompatible with legacy routing systems because of their hardware limitations, for example. Likewise, from an economical standpoint, the use of SDN solutions for the sake of flexibility and automation may dramatically impact Capital Expenditure (CAPEX) and Operational Expenditure (OPEX) budgets.
o 评估SDN标记的解决方案是否可能因硬件限制而淘汰现有技术。从技术角度来看，例如，由于传统路由系统的硬件限制，动态提供资源作为要交付的服务的功能的能力可能与传统路由系统不兼容。同样，从经济角度来看，为了灵活性和自动化而使用SDN解决方案可能会极大地影响资本支出（CAPEX）和运营支出（OPEX）预算。
Security is an important aspect of any SDN design because it conditions the robustness and reliability of the interactions between network and applications people for efficient access control procedures and optimized protection of SDN resources against any kind of attack. In particular, SDN security policies [SDNSEC] should make sure that SDN resources are properly safeguarded against actions that may jeopardize network or application operations.
安全性是任何SDN设计的一个重要方面，因为它决定了网络和应用程序人员之间交互的健壮性和可靠性，以实现高效的访问控制程序和针对任何类型攻击的SDN资源优化保护。特别是，SDN安全策略[SDNSEC]应确保SDN资源得到适当保护，以防止可能危及网络或应用程序操作的操作。
In particular, service providers should define procedures to assess the reliability of software modules embedded in SDN nodes. Such procedures should include the means to also assess the behavior of software components (under stress conditions), detect any exploitable vulnerability, reliably proceed with software upgrades, etc. These
特别是，服务提供商应定义程序，以评估SDN节点中嵌入的软件模块的可靠性。此类程序应包括评估软件组件行为（在压力条件下）、检测任何可利用漏洞、可靠地进行软件升级等的方法
security guards should be activated during initial SDN node deployment and activation but also during SDN operation that implies software upgrade procedures.
在初始SDN节点部署和激活期间，以及在暗示软件升级过程的SDN操作期间，应激活安全防护。
Although these procedures may not be SDN-specific (e.g., operators are familiar with firmware updates with or without service disruption), it is worth challenging existing practice in light of SDN deployment and operation.
尽管这些过程可能不是SDN特定的（例如，操作员熟悉固件更新，无论是否有服务中断），但根据SDN部署和操作，对现有实践提出挑战是值得的。
Likewise, PEP-PDP interactions suggest the need to make sure that (1) a PDP is entitled to solicit PEPs, so that they can apply the decisions made by the said PDP, (2) a PEP is entitled to solicit a PDP for whatever reason (request for additional configuration information, notification about the results of a set of configuration tasks, etc.), (3) a PEP can accept decisions made by a PDP, and (4) communication between PDPs within a domain or between domains is properly secured (e.g., make sure a pair of PDPs are entitled to communicate with each other, make sure the confidentiality of the information exchanged between two PDPs can be preserved, etc.).
同样，PEP-PDP互动表明需要确保（1）PDP有权征求PEP，以便他们可以应用所述PDP做出的决定，（2）PEP有权出于任何原因（请求额外配置信息、通知一组配置任务的结果等）征求PDP，（3）政治公众人物可以接受PDP做出的决定，并且（4）域内或域之间的PDP之间的通信得到了适当的保护（例如，确保一对PDP有权相互通信，确保两个PDP之间交换的信息的机密性得到保护，等等）。
Many thanks to R. Barnes, S. Bryant, S. Dawkins, A. Farrel, S. Farrell, W. George, J. Halpern, D. King, J. Hadi Salim, and T. Tsou for their comments. Special thanks to P. Georgatos for the fruitful discussions on SDN Interconnection (SDNI) in particular.
非常感谢R.Barnes、S.Bryant、S.Dawkins、A.Farrell、S.Farrell、W.George、J.Halpern、D.King、J.Hadi Salim和T.Tsou的评论。特别感谢P.Georgatos就SDN互连（SDNI）进行了富有成果的讨论。
[AN] Tennenhouse, D. and D. Wetherall, "Towards an Active Network Architecture", Multimedia Computing and Networking (MMCN), January 1996.
[AN]Tennenhouse，D.和D.Wetheral，“走向主动网络架构”，多媒体计算和网络（MMCN），1996年1月。
[AUTOMATION] Boucadair, M. and C. Jacquenet, "Requirements for Automated (Configuration) Management", Work in Progress, January 2014.
[自动化]Boucadair，M.和C.Jacquenet，“自动化（配置）管理的要求”，在建工程，2014年1月。
[CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, October 2013.
[CPNP]Boucadair，M.和C.Jacquenet，“连接供应协商协议（CPNP）”，正在进行的工作，2013年10月。
[CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS Connectivity Provisioning Profile", Work in Progress, September 2012.
[CPP]Boucadair，M.，Jacquenet，C.，和N.Wang，“IP/MPLS连接配置文件”，正在进行的工作，2012年9月。
[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, November 2013.
[LS-DISTRIB]Gredler，H.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和TE信息的北向分布”，正在进行的工作，2013年11月。
[PN] Campbell, A., De Meer, H., Kounavis, M., Kazuho, M., Vincente, J., and D. Villela, "A Survey of Programmable Networks", ACM SIGCOMM Computer Communication Review, April 1999.
[PN]Campbell，A.，De Meer，H.，Kounanis，M.，Kazuho，M.，Vincente，J.，和D.Villela，“可编程网络的调查”，ACM SIGCOMM计算机通信评论，1999年4月。
[RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992.
[RFC1383]Huitema，C.，“基于DNS的IP路由的实验”，RFC1383，1992年12月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.，和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 26221999年6月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[RFC3084]Chan，K.，Seligson，J.，Durham，D.，Gai，S.，McCloghrie，K.，Herzog，S.，Reichmeyer，F.，Yavatkar，R.，和A.Smith，“策略供应的COPS使用（COPS-PR）”，RFC 30842001年3月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP。和JL。Le Roux，“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[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.
[RFC5810]Doria，A.，Hadi Salim，J.，Haas，R.，Khosravi，H.，Wang，W.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 58102010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812]Halpern，J.和J.Hadi Salim，“转发和控制单元分离（部队）转发单元模型”，RFC 5812，2010年3月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Bjorklund，M.，Schoenwaeld，J.，和A.Bierman，“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月。
[SDNSEC] Hartman, S. and D. Zhang, "Security Requirements in the Software Defined Networking Model", Work in Progress, April 2013.
[SDNSEC]Hartman，S.和D.Zhang，“软件定义网络模型中的安全要求”，正在进行的工作，2013年4月。
[SLA-EXCHANGE] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. Boucadair, "Inter-domain SLA Exchange", Work in Progress, November 2013.
[SLA-EXCHANGE]Shah，S.，Patel，K.，Bajaj，S.，Tomotaki，L.，和M.Boucadair，“域间SLA交换”，正在进行的工作，2013年11月。
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Christian Jacquenet France Telecom Rennes France
克里斯蒂安·雅克网法国电信法国雷恩
EMail: christian.jacquenet@orange.com
EMail: christian.jacquenet@orange.com