Software-Defined Networking: A Perspective from within a Service Provider Environment，March 2014
梗概
在过去的几年里，软件定义网络 （Software-Defined Networking，SDN） 一直是网络行业的主要流行词之一。然而，到目前为止，还没有广泛承认 SDN 实际涵盖的明确定义。本文档旨在通过从服务提供商环境中看到的有关 SDN 的要求、问题和其他考虑因素的观点，阐明 SDN 的前景。
它并不是要无休止地讨论 SDN 的真正含义，而是建议对可以在 SDN 保护伞下使用的技术进行功能分类，并详细说明这些技术的联合激活不可避免地引起的各种悬而未决的问题。因此，仅出于澄清目的而提及SDN的定义。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
本文档是互联网工程任务组 （Internet Engineering Task Force，IETF） 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 （Internet Engineering Steering Group，IESG） 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。
有关本文档当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7149。
版权声明
版权所有 （c） 2014 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 （http://trustee.ietf.org/license-info） 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 简介
Internet 已成为支持各种服务产品的联合网络。IP VPN 等网络服务的交付往往伴随各种功能的组合激活，包括（但不一定限于）转发和路由（例如，客户特定的寻址方案管理、动态路径计算以到达一组目的地前缀、动态建立隧道等）；服务质量（例如，流量分类、标记、调节和调度）；安全性（例如，保护客户场所免受网络发起的攻击的过滤器，避免格式错误的路由公告等）；和管理（例如，故障检测和处理）。
由于这些服务不仅种类繁多，而且越来越复杂，因此它们的设计、交付和操作已成为一门复杂的炼金术，通常需要各种级别的专业知识。各种各样的（网络）协议和工具以及最近由任何时间、任何地点、任何设备 （Any Time, Any Where, Any Device，ATAWAD） 推动的融合趋势进一步加剧了这种情况；ATAWAD旨在确保最终用户可以访问他/她订阅的所有服务范围，无论使用何种访问和设备技术，无论最终用户连接到网络的位置，以及该最终用户是否在移动中.
然而，这些服务中的大多数已经部署了过去十年，主要基于通常是静态的服务生产过程，这些过程越来越暴露于错误配置命令的风险中。此外，除了典型的财务条款外，这些服务中的大多数不承担客户与服务提供商之间或服务提供商之间的任何具体谈判。
充其量，五年总体规划被称为网络规划政策，由服务提供商根据可预见的业务发展前景、人工计算的流量预测和市场覆盖范围（固定/移动和住宅/企业）执行。这种所谓的网络规划策略可能会很好地影响网络中资源的分配方式，但它显然无法以“永远在线”的方式充分响应高度动态的客户需求。对改进服务交付程序的需求（包括在可能的谈判阶段完成后交付服务所需的时间）对于企业客户来说更为重要。
此外，各种工具用于不同的、有时以服务为中心的管理目的，但它们的使用不一定针对事件聚合、关联和处理进行协调。这种缺乏协调可能以额外的复杂性和可能的客户体验质量下降为代价。
因此，在不久的将来，多服务、多协议、多技术融合和动态自适应的网络环境已成为服务提供商面临的主要挑战之一。
本文档旨在通过从服务提供商环境中看到的可用于 SDN 的技术的功能分类提供一个视角来阐明 SDN 的前景。
2、 引入软件定义网络
2.1、 同义反复？
转发平面和控制平面的分离（超出实施考虑）几乎成为一种噱头，以促进灵活性作为 SDN 方法的一个关键特征。从技术上讲，大多数当前的路由器实现几十年来一直假设这种分离。路由过程（例如 IGP 和 BGP 路由计算）通常基于软件，而转发功能通常在硬件中实现。
因此，在撰写本文时，被认为是最先进的技术倾向于确认所述分离，而这更像是一种同义反复。
但是，在转发信息库 （Forwarding Information Base，FIB） 流行之前，为了优化路由计算而有点集中的、“嵌入控制器的”控制平面肯定是另一回事。
2.2、 关于灵活性
SDN 的推动者认为，它为网络的运营方式提供了额外的灵活性。这无疑是服务提供商必须实现的关键目标之一。这是因为能够动态适应广泛的客户对灵活网络服务交付的请求是一项重要的竞争优势。但是，灵活性远不止将控制平面和转发平面分离以促进转发决策过程。
例如，能够满足短期额外带宽要求，以便最终用户可以将视频文件流式传输到他们的 4G 终端设备，这就是一些移动运营商目前正在研究的灵活性的一个例子。
从这个角度来看，根据要交付的网络服务预测网络行为的能力对于服务提供商来说至关重要，因此他们可以评估引入新服务或激活附加网络功能或执行给定集的影响从财务和技术角度分析（新）政策。这有利于研究先进的网络仿真引擎，例如，可以从 [LS-DISTRIB] 中获取信息。
鉴于术语“灵活性”所暗示的范围相当广泛：
** 目前标有 SDN 的解决方案据称是灵活的，尽管这个概念几乎没有定义。尚未提供对灵活性实际意味着什么的确切特征。
因此，需要开展进一步的工作，以便可以根据各种标准精确定义灵活性，例如网络演进能力作为 SDN 技术，通过复杂函数实现无缝引入的能力集成（即逐步引入的能力，启用 SDN 设备而不会中断网络和服务运行等）。
** 可编程接口的开放本身不是目标；相反，它是一种促进配置过程以提高灵活性的手段。
2.3、 假设定义
我们将软件定义网络定义为一组技术，用于以确定性、动态和可扩展的方式促进网络服务的设计、交付和操作。所述确定性是指完全掌握服务交付链的各个组成部分的能力，从而使已交付的服务符合与客户协商和合同定义的内容。
因此，确定性意味着控制网络服务的结构、设计和交付方式以及流量应在网络中转发的位置的能力是为了优化资源使用。尽管在本文档的以下部分中没有明确重申，一旦服务参数协商完成，从配置任务到服务交付、实现和保证（请参阅下面的第 2.4 节），服务提供者可能采取的任何行动都存在确定性。
这样的定义假设在整个服务交付和操作程序中引入了高度自动化。
由于网络是由软件驱动的，因此上述定义并未强调标有 SDN 标签的解决方案所声称的“软件定义”属性。
2.4、 功能元域
SDN 技术可以分为以下功能元域：
** 动态发现网络拓扑、设备和功能的技术，以及旨在精确记录此类拓扑、设备及其功能的相关信息和数据模型。
** 公开网络服务及其特性以及动态协商服务参数集的技术，这些服务参数将用于衡量与提供给定服务或其组合相关的质量水平。在 [CPP] 中可以看到这样的一个例子。
** 服务需求衍生的动态资源分配和策略实施方案所使用的技术，以便可以相应地对网络进行编程。动态分配资源和执行策略的决定通常是各种输入相关性的结果，例如在任何给定时间网络中可用资源的状态，需要在给定时间内处理的客户服务订阅请求的数量时间段、流量预测、根据典型的多年总体规划触发额外资源供应周期的可能需要等。
** 动态反馈机制，旨在从服务实现和保证的角度评估给定策略（或一组策略）的执行效率。
3、 现实检查
网络生态系统在健壮性、性能、可扩展性、灵活性、敏捷性等方面变得非常复杂和高要求。这尤其意味着服务提供商和网络运营商必须应对这种复杂性并运营可以轻松发展的网络基础设施，保持可扩展性，保证健壮性和可用性，并且对拒绝服务攻击具有弹性。
引入新的基于 SDN 的网络功能显然应该考虑到这种情况，尤其是从成本影响评估的角度来看。
3.1、 记住过去
SDN 技术本身并不是下一件大事，而是一种已经研究了多年的提案的品牌重塑，例如主动或可编程网络 [AN] [PN]。事实上，一些声称的“新”的SDN 功能已经实现（例如，网络管理系统 （Network Management System，NMS） 和路径计算元素 （Path Computation Element，PCE） [RFC4655]）并得到厂商的支持。
其中一些功能也已经标准化（例如，基于 DNS 的路由 [RFC1383]），可以将其视为分离控制和转发平面或转发和控制元素分离（Forwarding and Control Element Separation，ForCES）[RFC5810] [RFC5812] 的说明。
此外，2000 年代初期引入的基于策略的管理框架 [RFC2753] 旨在通过典型的策略决策点 （Policy Decision Point，PDP） 来编排可用资源，该策略掌握高级离线流量工程能力。因此，该框架能够与嵌入（或不嵌入）在受控设备中的带内软件模块进行交互。
PDP 是做出政策决定的地方。PDP 使用目录服务来实现策略存储库的目的。策略存储库存储可由 PDP 检索和更新的策略信息。PDP 以包含配置信息的策略提供信息的形式向策略执行点 （Policy Enforcement Point，PEP） 下发策略规则。
PEP 是应用政策决定的地方。PEP 嵌入（网络）设备中，这些设备是根据 PEP 处理的策略格式信息动态配置的。PEP 从 PDP 请求配置，将配置信息存储在策略信息库 （Policy Information Base，PIB） 中，并将任何策略决定委托给 PDP。
SDN 技术作为一个整体是基于策略的管理框架的实例。在这种情况下，SDN 技术可用于按需激活能力，动态调用网络和存储资源，并根据事件（例如，网络拓扑的更改）、触发器（例如，动态通知链接失败）等。
3.2、 务实
SDN 方法应该是整体的，即全球和网络范围的。这不是一个接一个地配置设备以强制执行特定转发策略的问题。相反，SDN 技术是关于在网络规模上配置和操作一系列设备以实现自动化服务交付 [AUTOMATION]，从服务协商（例如 [CPNP]）和创建（例如 [SLA-EXCHANGE]）到保证和履行。
由于激活 SDN 功能的复杂性在很大程度上对最终用户隐藏，并由软件处理，因此需要对整个生态系统有清晰的了解，以弄清楚如何管理这种复杂性以及这种隐藏操作的复杂性在多大程度上不会对网络产生副作用。
例如，假设有一个中央决策实体的 SDN 设计必须避免单点故障。它们也不得影响数据包转发性能（例如，不得影响传输延迟）。
SDN 技术本身并不是开发新网络服务所必需的。基本服务仍然是请求位于网络中的资源的 （IP） 连接。因此，SDN 技术可以被视为另一种与网络服务模块交互并相应地调用连接和存储资源以满足特定服务需求的手段。
根据定义，SDN 技术的激活和操作仍然限于嵌入式软件和硬件支持的内容。不能指望 SDN 技术支持无限的可定制功能。
3.3、 针对期望衡量经验
由于多个软件模块可能由外部实体（通常为 PDP）控制，因此需要一种方法来确保已交付的内容与已协商的内容一致。这样的手段属于一套SDN技术。
这些典型的基于策略的技术应该与服务结构引擎（旨在暴露服务特征并可能协商这些特征）和网络交互，以持续评估所经历的网络行为是否符合服务结构引擎设定的目标以及可能已经与客户动态协商的那些（例如，在 CPP [CPP] [CPNP] 中捕获）。此要求适用于网络的多个区域，包括：
1.在两个相邻 IP 网络提供商之间的接口处。
2.在服务提供商和IP网络提供商之间的接入接口处。
3.在客户和 IP 网络提供商之间的接口处。
理想情况下，应以第 4.1 节中讨论的影响为代价支持从协商、订购和订单处理到交付、保证和履行的完全自动化的服务交付程序。除了接口之外，这种方法还假设广泛采用的标准数据和信息模型。
3.4、 精心设计
从可扩展性和性能的角度来看，公开开放和可编程的接口是有代价的。
鼓励维护硬编码的性能优化技术。使用允许直接控制某些引擎（例如，路由和转发）而不需要任何中间适配层（例如，厂商特定命令行接口（command line interfaces，CLI）的通用对象）的接口也是如此。然而，从性能的角度来看，使用特定于厂商的访问意味着它可能对某些引擎有益，但代价是增加了配置任务的复杂性。
无论如何，SDN 技术必须适配厂商特定的组件。事实上，这些厂商特定的功能不会因为激烈的竞争而消失。
应避免引入可能危及网络灵活性的新功能或设备，或者至少根据可能的性能和可扩展性影响仔细考虑。支持 SDN 的设备必须与传统系统共存。
因此，一个单一的 SDN 网络范围的部署是不太可能的。相反，SDN 技术的多个实例将逐步部署并适应各种网络和服务段。
3.5、 关于OpenFlow
使用带内可控模块实现联网可能依赖于 OpenFlow 协议，但也可以使用其他协议在控制平面和数据平面之间交换信息。
实际上，还有许多其他候选协议可用于相同甚至更广泛的目的（例如，资源预留目的）。例如，配置信息的转发可以依赖于诸如路径计算元素 （Path Computation Element，PCE） 通信协议 （Path Computation Communication Protocol，PCEP） [RFC5440]、网络配置协议 （Network Configuration Protocol，NETCONF） [RFC6241]、用于策略提供的 COPS 使用 （COPS Usage for Policy Provisioning，COPS- PR） [RFC3084]、路由策略规范语言 （Routing Policy Specification Language，RPSL） [RFC2622] 等。
因此，OpenFlow 和 SDN 之间没有 1:1 的关系。相反，OpenFlow 是向设备传达特定配置信息的候选协议之一。因此，OpenFlow 是全球 SDN 工具包的一个可能组件。
3.6、 无目的
在运营当前的网络生态系统和引入一些 SDN 技术之间存在不可避免的权衡，可能以引入新技术为代价。运营商不必在两者之间做出选择，因为这两种环境都必须共存。
特别是，以下考虑不能证明部署 SDN 技术是合理的：
** 完全灵活的软件实现，因为声称的灵活性仍然受到软件和硬件限制的限制。
** 完全模块化的实现很难实现（因为隐含的复杂性），并且可能会为测试、验证和故障排除带来额外的工作量。
** 完全集中的控制系统，可能会引起一些可扩展性问题。分布式协议及其及时响应某些事件（例如，链路故障）的能力仍然
是可扩展网络的基石。这意味着 SDN 设计可以依赖集中特征的逻辑表示（例如，支持 PDP 间通信的抽象层）。
4、 讨论
4.1、 全自动化的影响
通往完全自动化的道路面临着众多挑战和要求，包括：
** 确保自动化得到很好的实施，以促进测试（包括验证检查）和故障排除。
* 这表明需要模拟工具来准确评估在整个服务交付过程中引入高度自动化的影响，以避免典型的“疯狂机器人”综合症，从控制和 QoS 的角度来看，其后果可能很严重。
* 这也建议对人工专业知识进行仔细管理，以便网络运营商可以使用强大、灵活的方法来自动化执行重复或容易出错的任务，然后在自动化的基础上或将多个操作串联起来，以完成需要较少人工交互但日益复杂的任务（指导和输入）。
** 简化和促进服务交付、保证和履行，以及网络故障检测、诊断和根本原因分析以优化成本。
* 此类成本优化与改进的服务交付时间以及优化的人类专业知识（见上文）以及与技术无关的全球服务结构和交付程序有关。特别是，在现有设备中注入新功能的能力不应假设替换所述设备，而是允许智能投资资本化。
* 可以通过自动化来实现，可能基于网络基础设施（或其一部分）的逻辑集中视图，从而需要高度自动化的拓扑、设备和功能发现手段以及操作程序。
* 主要智能存在于 PDP 中，这表明 SDN 相关开发工作的一个重要部分应侧重于 PDP 功能的详细规范，包括基于完整标准化数据集的算法和行为状态机，以及信息模型。
* 这些信息模型和数据需要精心构建以提高效率和灵活性。这可能表明可以根据要交付的服务的性质组装一组简化的伪块。
** 对抽象层的需求——各业务参与者之间和各层之间的清晰接口等，暂不考虑跨层。这样的抽象层是在服务结构化和打包的上下文中调用的，旨在促进以下内容的出现：
* 向客户、对等方、应用程序、内容/服务提供商等公开 IP 连接服务（在 [CPP] 中可以看到此类示例）。
* 满足具有网络工程目标的 IP 连接服务要求的解决方案。
* 动态自适应决策过程，可以根据一组输入数据和指标正确运行，例如当前资源使用和需求、流量预测和矩阵等，所有这些都是为了高度响应的动态资源分配和策略执法计划。
** 通过以下方式更好地适应技术上的异构网络环境：
* 独立于厂商的配置程序基于厂商不可知的通用策略而不是厂商特定语言的实施。
* 有助于管理和编排资源的工具。
* 避免代理和特权与引擎的直接交互（例如，路由和转发）。
4.2、 引导 SDN
需要提供动态发现将由 PDP 智能引导的设备功能能力化的方法，以实现自动化网络服务交付。这是因为获取与网络实际能力相关的信息将有助于构建 PDP 智能，从而可以相应地导出策略供应信息。
一个典型的例子是记录流量工程策略，该策略基于网络设备支持的各种功能的动态发现，作为要交付的服务的功能，从而根据需要建立到同一目的地的不同路由。流量的性质，需要调用以转发此类流量的功能的位置等。
这种动态发现能力可以依赖于通过网络设备之间或网络设备与传统网络环境中的 PDP 之间的 IGP 或 BGP 的特定信息交换。PDP 还可以向网络设备发送未经请求的命令，以获取其功能能力的描述，并相应地导出网络和服务拓扑。
当然，SDN 技术（如 2.4 节中介绍的）可以部署在 IGP- free/BGP-free 网络环境中，但这种环境中的 SDN 引导过程仍然假设支持以下能力：
** 以弹性方式动态发现 SDN 参与节点（包括 PDP）及其各自的能力，假设 PDP 和参与设备相互认证 第 5 节。PDP 和参与设备之间交换的信息的完整性在发现阶段也必须保留；
** 将 PDP 动态连接到参与节点，避免任何转发环路；
** 根据设备功能和（可能）客户和服务提供商之间动态协商的内容动态启用网络服务；
** 动态检查 PDP 与参与节点之间以及参与节点之间的连通性，以交付给定的网络服务（或其中的一组）；
** 根据要交付的服务动态评估可达性范围；
** 动态检测和诊断故障，并采取相应的纠正措施。
同样，应该提供动态获取可能参与给定服务交付的任何网络设备的描述信息（包括基本配置）的手段，以帮助 PDP 构建可以作为服务交付的功能可用资源、它们的位置等。
在 IGP-free/BGP-free 网络环境中，除了可能需要提供发现和连接功能的特定附加网络之外，可能需要特定的引导协议来支持上述功能，以实现正确的 PDP 和 SDN 设备操作。
特别是，在 IGP-free/BGP-free 环境中的 SDN 设计和操作应该提供类似于运行 IGP 和 BGP 的传统环境的性能。例如，即使与 PDP 的连接丢失，底层网络也应保持运行。此外，与在现有 IGP/BGP 协议机制中集成上述功能的成本相比，运营商应评估引入新的特定引导协议的成本。
由于 SDN 相关功能可以嫁接到现有的网络基础设施中，因此从引导的角度来看，它们可能无法同时启用；可以采用渐进的方法。
一个典型的部署示例是使用 SDN 决策过程作为仿真平台，帮助服务提供商和运营商在实际部署到网络之前做出适当的技术选择。
最后，发现过程的完成并不一定意味着网络现在可以完全运行。网络的可操作性通常采用基于弹性和高可用性功能的稳健设计。
4.3、 运营SDN
从运营和管理 （OAM） 的角度 [RFC6291]，运行支持 SDN 的网络会引发几个问题，如下所列：
** SDN 服务和网络管理块如何交互？例如，在给定的时间段内与客户或客户集合动态协商服务参数的结果将如何影响PDP决策过程（资源分配、路径计算等）。
** 适合 SDN 网络操作的 OAM 工具应该是什么（例如，检查 PDP 或 PEP 可达性）？
** 当软件模块的激活由外部实体（通常是 PDP）控制时，如何优化性能（例如以服务交付时间表示）？
** SDN 实施在多大程度上简化了网络可管理性，包括服务和网络诊断？
**“控制平面和数据平面分离”原则是否应该应用于整个网络或其中的一部分，作为要交付的服务的性质的函数还是考虑到当前部署的技术？
** 对服务提供商的测试程序和方法（在验证和部署前阶段使用）有何影响？特别是：（1）当支持自定义模块的激活时，如何定义和执行测试用例？（2）评估 SDN 控制设备行为的方法是什么？（3）如何进行测试回归？等等。
** SDN 技术如何影响服务实现和保证？应如何根据与客户动态协商的内容评估 SDN 设备的最终行为（例如，完成配置任务）。如何根据已交付的服务来衡量动态执行策略的效率。如何衡量已交付的内容是否符合已协商的内容。SDN 技术对故障排除实践有何影响。
** 由于受控设备和 SDN 控制器之间潜在的互操作性问题，运行冻结架构是否有任何风险？
** SDN 技术的引入如何影响遗留系统的生命周期？由于现有技术的硬件或软件限制，是否存在（迅速）淘汰现有技术的风险？
上述问题的答案很可能是特定于服务提供商的，具体取决于他们的技术和商业环境。
4.4、 存在于PDP中的情报
第 2.3 节中提议的 SDN 定义假定智能可能驻留在控制或管理平面（或两者）中。这种智能通常由策略决策点 （Policy Decision Point，PDP） [RFC2753] 表示，它是基于策略的管理框架的关键功能组件之一。
因此，SDN 网络依赖于能够处理各种输入数据（流量预测、客户与服务提供商之间的协商结果、PIB 中实例化的适当信息模型中描述的资源状态等）的 PDP 功能来做出适当的决策.
以可扩展的方式设计和运行这种基于 PDP 的情报仍然是需要研究的主要领域的一部分。
为避免集中设计方案，很可能需要 PDP 间的通信，并应考虑相应的问题和解决方案。因此可以在给定域中激活多个 PDP 实例。因为这些 PDP 实例中的每一个都可能负责对特定策略的实施做出决定（例如，一个 PDP 用于 QoS 策略实施目的，另一个用于安全策略实施目的等），所以需要一个 PDP 间通信方案用于全球 PDP 协调和关联。
特定用途也可能需要域间 PDP 交换。此类交换的示例如下：（1） 在节点到访问网络的网络连接阶段，访问网络操作的 PDP 可以联系归属 PDP 以检索要对该节点执行的策略，以及（2）各种 PDP 可以协作以计算满足一组流量性能保证的域间路径。
4.5、 简单性、适应性与复杂性
2.4 节中介绍的功能元域假设引入了高度自动化，从服务协商到交付和操作。自动化是简化的关键，但它不能被视为一个神奇的按钮，每当必须处理客户请求或需要分配额外资源时，网络管理员就会按下它。
由于自动化程序，对简单性和适应性的需求通常会假设自动化背后存在一些复杂性。
4.6、 性能和可扩展性
作为要交付的服务的数量和性质及其相关动态的函数，灵活性与软件的结合不可避免地会引发性能和可扩展性问题。
例如，部署在数据中心 （Data Centers，DC） 中且依赖 OpenFlow 交换机的网络不太可能引发重要的 FIB 可扩展性问题。相反，旨在动态管理虚拟机 （Virtual Machine，VM） 迁移性（可能基于特定 QoS 策略的动态实施）的 DC 互连设计可能会引发可扩展性问题。
运营商必须仔细调查在后一种情况下 SDN 网络所声称的灵活性。
4.7、 风险评估
需要评估各种风险，例如：
** 评估依赖控制器技术而非设备技术的风险。
** 由于控制器和受控设备之间潜在的互操作性问题，评估运行冻结架构的风险。
** 评估带有 SDN 标签的解决方案是否可能因硬件限制而淘汰现有技术。从技术角度来看，根据要交付的服务动态提供资源的能力可能与传统路由系统不兼容，例如，因为它们的硬件限制。同样，从经济的角度来看，为了灵活性和自动化而使用 SDN 解决方案可能会显着影响资本支出 （Capital Expenditure，CAPEX） 和运营支出 （Operational Expenditure，OPEX） 预算。
5、 安全考虑
安全性是任何 SDN 设计的一个重要方面，因为它决定了网络和应用程序人员之间交互的稳健性和可靠性，以实现高效的访问控制程序和优化保护 SDN 资源免受任何类型的攻击。特别是，SDN 安全策略 [SDNSEC] 应确保适当保护 SDN 资源免受可能危及网络或应用程序操作的行为。
特别是，服务提供商应定义程序来评估嵌入在 SDN 节点中的软件模块的可靠性。此类程序应包括评估软件组件的行为（在压力条件下）、检测任何可利用的漏洞、可靠地进行软件升级等的方法。这些安全防护应在初始 SDN 节点部署和激活期间激活，也应在 SDN 期间激活意味着软件升级程序的操作。
尽管这些程序可能不是特定于 SDN 的（例如，运营商熟悉有或没有服务中断的固件更新），但鉴于 SDN 部署和运营，值得挑战现有实践。
同样，PEP-PDP 交互表明需要确保：（1） PDP 有权征求 PEP，以便他们可以应用所述 PDP 做出的决定，（2） PEP 有权出于任何目的（请求附加配置信息，关于一组配置任务结果的通知等）征求 PDP原因，（3） PEP 可以接受 PDP 做出的决定，以及（4）域内 PDP 之间或域之间的通信是适当保护（例如，确保一对 PDP 有权相互通信，确保可以保护两个 PDP 之间交换的信息的机密性等）。
6、 致谢
非常感谢 R. Barnes、S. Bryant、S. Dawkins、A. Farrel、S. Farrell、W. George、J. Halpern、D. King、J. Hadi Salim 和 T. Tsou 的评论。特别感谢 P. Georgatos 对 SDN 互连 （SDN Interconnection，SDNI） 的富有成果的讨论。
7、 参考资料
[AN] Tennenhouse, D. and D. Wetherall, "Towards an Active Network Architecture", Multimedia Computing and Networking （MMCN）, January 1996. [AUTOMATION] Boucadair, M. and C. Jacquenet, "Requirements for Automated （Configuration） Management", Work in Progress, January 2014. [CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning Negotiation Protocol （CPNP）", Work in Progress, October 2013. [CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS Connectivity Provisioning Profile", Work in Progress, September 2012. [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. [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. [RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992. [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. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [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. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element （PCE）-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element （PCE） Communication Protocol （PCEP）", RFC 5440, March 2009. [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. [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation （ForCES） Forwarding Element Model", RFC 5812, March 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol （NETCONF）", RFC 6241, June 2011. [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. [SDNSEC] Hartman, S. and D. Zhang, "Security Requirements in the Software Defined Networking Model", Work in Progress, April 2013. [SLA-EXCHANGE] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. Boucadair, "Inter-domain SLA Exchange", Work in Progress, November 2013.
