编者按：本文系SDNLAB社区译者计划文章系列，SDNLAB将与国外技术社区、优质媒体和个人进行长期的内容合作，带来更多的优质技术文章。本文来自译者优秀试译文章，文章节选自论文《OpenNF: Enabling Innovation in Network Function Control》，是目前为止见到的最好的解释NFV以及NFV和SDN关系的文章。
译者简介：Marshal，未来网络技术爱好与践行者，PhD在读@中科院计算所。
1 介绍
网络功能（NFs），或中间件是以复杂方式检测和更改数据包和流的系统。比如：入侵检测系统（IDSs），负载均衡器，缓存代理等。NFs在确保安全性，提高性能和提供其他新网络功能方面起着关键性的作用。
最近，我们发现利用运行在通用计算资源上的基于软件的NFs来替代专用网络功能硬件越来越引起人们的兴趣，即被称为网络功能虚拟化（NFV）的趋势。同时，SDN被用来通过适当的NFs引流，从而执行决策和共同管理网络和网络负载。
结合NFV和SDN可以实现一类重要的管理应用，这类应用需要在多个网络功能实例（如网络负载均衡，弹性网络伸缩）之间进行动态分组包处理。在此类应用场景下，“NFV+SDN”可以帮助实现以下三个重要目标：（1）、在NF性能和可用性方面满足严格的服务等级协议（SLAs）；（2）、精确地监控和处理网络流，比如，对所有包含恶意软件的网络流，IDS都应该报警；（3）、最小化NF运营成本。然而，目前同时实现三个目标是不可能的，从根本上说需要比“NFV+SDN”能提供的更多的控制功能。
要知道为何？我们考虑这样一个场景，一个IDS过载，为了在吞吐量上满足SLAs，必须进行网络扩展（图1）。通过NFV，我们可以轻易地创建一个新的IDS实例，通过SDN，我们可以将一些正在进行的流网络路由到新创建的实例。然而，由于内部NF状态是不可见的，可能发现不了攻击。为了解决这个问题，SDN控制应用可以等待现有流的终止，且只重新路由新的流，但这样就延迟了过载的缓解，并且增加了破坏SLA的可能性。由于一些NF内部状态的不可复制或共享性，NF精确度也可能被破坏。
图1 需要扩展和负载均衡来满足吞吐量的SLAs和最小化运营成本的场景
在这个例子中，为了避免NF精确度和性能之间的权衡，唯一的办法就是允许一个控制应用能快速并且安全地对一些流的内部IDS状态从原始实例转移到新的实例，同时更新网络转发状态。类似的需求也出现在其他依赖动态重分配和分组处理的应用场景中，比如，快速升级NF和远程处理的动态调用。
在本文中，我们提出一种控制平面架构OpenNF，它提供内部NF状态和网络转发状态的高效、协作控制，使得NF实例之间的流能够快速、安全和细粒度的重分配。采用OpenNF，运营商能够创建丰富的重分配处理控制应用，这些应用能最佳地满足性能、可用性、安全性和成本目标，这样就避免了麻烦的权衡决策。
设计OpenNF的三个主要挑战如下：
C1: 解决竞争条件。这是重分配在线流时产生的最基本问题：当一些内部NF状态被转移时，数据包可能在转移开始后到达源实例，或者在状态转移完成之前到达目的源。除非特别小心，不然，基于这些可能丢失的或者乱序的数据包来更新NF状态，破坏了转移安全性。同样地，当从NF实例间复制状态时，同时发生的更新可能导致状态不一致，这些问题都可能降低NF的精确度。
为了说明竞争条件，我们引入两个新的结构：（1）、一个从外部观察的抽象事件，防止内部NFs的本地状态改变。（2）、一个用于更新网络转发状态的两阶段方案。我们展示了如何将两者结合起来以确保状态更新不会丢失，或者在状态转移时重新排序和共享状态保持一致。
C2：限制开销。第二个问题是保证重分配是高效的。NF实例之间的状态转移和共享会消耗NF CPU和网络资源。此外，为了避免丢失，重排和状态不一致，需要数据包缓冲，这会引入延迟和内存消耗。如果这些性能和资源消耗是无限制的，就无法满足严格的SLAs和有限的运营成本。
为了限制开销，我们提出了一个灵活的北向接口，用于控制应用明确地指定哪些状态进行转移，复制和共享，以及哪些保证执行（例如，无损耗）。
C3：以最小变化适应各种NFs。最后一个问题是确保我们的架构能适应以大量非入侵方式的各种各样的NFs。给NFs提供接口来创建/更新状态是一种方法，但是这种方法限定了内部NFs转态的结构，可能也不适合需要一些数据包处理逻辑的状态分配/访问。相反，我们为NFs设计了一种新的南向接口，允许控制器请求NF状态的进出口，而不改变NFs内部是如何管理状态的。
我们使用Floodlight实现了我们的北向接口API，利用这个API，我们开发了几个控制应用。我们也增加了四个NFs—Bro, Squid, iptables, 和PRADS，用于支持南向接口API。
我们对OpenNF评估表明：（1）、OpenNF可以消除虚假警报，并且和使用电流控制框架需要的数十分钟相比，我们能及时缩减NF规模；（2）、状态可以高效地转移，复制和共享，即使是需要一些特定的要求，比如：对于500规模的流进行无丢失状态转移，在这个操作过程中，只需要215ms加上50ms的包接收延迟；（3）、添加对OpenNF南向接口API的支持，最多只增加9.8%的代码量，在NFs状态进出的过程中，包处理时间增加将少于6%。
2 为何使用 OpenNF?
当分组处理是被一个NF的多个实例统一进行处理时，NF的部署通常需要满足以下三个重要目标：（1）、在性能和可用性上满足严格的SLAs——比如，大部分时间的总吞吐量应该超过1Gbps，用于处理流的宕机时间应该少于10分钟/每年；（2）、精确地监控和处理网络流量，比如，对所有包含恶意软件包流的HTTP流，IDS应该发起警报，RE解码器应该能够正确地恢复由RE编码器消除的冗余；（3）、最小化运营成本。例如，当不需要额外的容量时，资源应该关闭。
目前，同时实现这三个目标是不可能的，除了结合NFV和SDN能提供的功能之外，我们需要更多的控制机制。下面，我们描述若干个具体实例，并突出以上三大目标是如何转化成控制平面需求的。我们也会讨论当前的一些NFV和SDN控制框架，以及如何简化和增加它们以满足需求。
2.1 动机实例
总是选择最新的NFs。为了最大程度的保证安全，移动手机用户可能希望本次的数据能够被最新的NF软件处理。举个例子说，SLA要求流量每年被过时的NF实例处理的时间不超过10分钟。幸运的是，NFV允许在我们几毫秒内使用更新的NF实例，同时SDN允许我们在相同的时间内重新路由到那个更新的NF实例。然而由于缺少新实例的内部NF状态，这种简单重路由流量可能会降低NF准确性：举例来说，将一个活跃的HTTP流重新路由到一个新的IDS，由于缺少流中先前报文的原数据，会造成入侵检测系统错过对一些恶意软件的检测。为了克服这个问题，我们可以等到正在处理的流终止，只对新的流重新路由。然而，由于流的持续时间是不受控制的，这个方法不能保证满足SLA，举个例子，蜂窝网络中超过40%的流的超过10分钟。同时满足SLA协议以及维持网路功能正确性的唯一方法就是控制面提供将NF状态和它的更新转化为网络传递状态的功能。此外，操作必须在限定的时间内完成。
为了保证NF在状态传输期间以及状态传输之后的正确(目标2)，没有数据包或者更新在传输过程中丢失以及没有重新排序的更新发生是很重要的两点。举个例子，IDS对一个复制的报文处理，此时如果一个复制的流量在状态传递时丢失，IDS实例将没有机会请求重传该报文。这个可能会导致没有进行安全报警，因为IDS在一个连接上仅仅收到部分用于恶意软件检测的数据。同样的，IDS可能会错误报警如果它没有按顺序收到请求建立报文(SYN)和数据处理报文。因此，控制面必须提供对于诸如无损传输和顺序保持传输的重要保证。（我们将在5.1节正式定义无损传输和保持顺序）。
高效的网络控制。移动电话用户也很关心网络的性能。举个例子，SLA可能要求NF部署吞吐量在大多数时刻超过1Gbps。由于数据包处理的复杂性，仅仅依靠单一的NF实例去满足SLA的要求困难太大。幸运的是， NFV允许NF在网络负载增加的时候动态扩展，同时SDN允许流被重新路由到新的NF。然而，正如在第一个方案中说的那样，流必须被快速重新路由—一直等到流的终止会导致网络功能持续负载过重并且破坏SLA(目标1)，而关于安全性，不移动内部NF状态的重新路由方式会降低NF的正确性(目标2).(以一种不丢失和不乱序的方式)。相似的，在事先考虑快速重路由和安全性的情况下，当网络的负载降低时，网络功能应该收缩来减少操作消耗(目的3)。为了达到这个目的，我们还是需要将NF状态以及它的状态更新转化为网络传递状态，并且这种转化必须在限定时间内完成并且有重要保证。
当重新平衡负载时，我们可能要考虑到NFs用于多个流的情况。举个例子， IDS为每个终端主机保持连接计数器。如果以主机或者子网为粒度，网络是平衡的，一个主机所有的流经过相同的IDS实例，计数器可以交给这个实例。然而，当主机上的流被平衡到不同的实例，所有的实例必须有该计数器。更进一步的说，如果一个处理流的实例终止了，主机的在该实例上的流被移动其它剩余的实例上，那么这两个实例的计数器需要合并。因此，控制面必须提供转移、复制或者共享、以及合并到多个流相关的NF状态。
网络功能故障只占用少量资源快速恢复。当一个NF实例发生故障时，我们可以通过重路由正在处理的流到一个正常的实例来减少故障时间。为了让这些流能够正确的被处理，被选中的实例必须能够获得关键的NF状态。达到这个目的的方法之一就是为所有的NF实例周期性的备份；这对于在该NF实例的CPU和存储带宽的消耗不可忽略(目标3)，由于各个备份之间的延时会导致备份中有大量的过时状态。第二种方法只备份NF状态更新的部分。这种方法会消除过时状态的问题，并且资源的占用和状态更新的频率以及被备份状态的数量成比例增长。为了支持这种方式，我们需要能够复制NF状态，同时需要能够跟踪状态何时以及如何更新。
基于对本地NF的前期观察，一个企业可能想对当前正在处理的流的某个子集进行更深层次更高级的处理（目标2的变体）。举个例子，当IDS检测到内部的主机正在向一个被列入黑名单的域名发送HTTP请求，企业要启用对恶意软件的分析会进行回复的数据包处理功能。由于本地IDS的资源限制，企业可能会利用云端更加强大的远程IDS.更进一步说，为了避免将所有流量重定向到云端的带来的消耗（目标3），其它主机的流量必须在本地处理。这个需要在先前的例子强调的特性的支持（例如将特定流的状态无损耗传输）。除此之外，更高级的处理实际上需要获得更多的状态细节：举例来说，云端的IDS可能要为与一些已经众所周知的攻击库比较签名，为新的流创建额外的状态。因此，网络控制面不能限制NF创建额外状态的能力。更进一步说，如果这个被处理的流之后会传回到原来的NF实例，那么这个额外的状态必须要能够被自动捕获。
2.2 相关工作
现有的控制平面，如PLayer, SIMPLE, Stratos, FlowTags, 和一些连接技巧，仅仅提供控制，协调和流量转发。如已经讨论过的，在不降低NF精度的条件下，单独的转发变化是不能满足各种各样需求目标的。
VM或者进程的复制只允许一整个地克隆NF实例。额外的，包含于克隆中的不需要的状态不仅浪费内存，而且更为严重的是能导致不良的NF行为。比如，IDS可能产生错误的警报。此外，这种方法阻止了多种NF实例的状态的转移和合并，妨碍了快速弹性收缩。由于他们固有的限制，结合现有的控制平面和VM迁移/过程复制技术不能满足上述的需求。
供应商提供的控制器在多个NF实例之间进行状态转移，复制和共享时，可能影响NFs的内部工作信息。但是，他们不能以一种方式控制网络状态来满足所有的目标。例如，很难通过网络链路提供优化的负载均衡。
拆分/合并和轻量复制是唯一提供一些对内部NF状态和网络状态控制的系统。他们提供一个共享库，NFs使用这个共享库，可通过预先定义的API来创建，访问，和更改内部状态。编排器通过调用一个简单的迁移操作（重新路由流f并转移相应的NF状态）来协调负载均衡。在轻量复制中，NF加进一些模块来管理进出各个实例的分组流，并且根据预先定义的频率进行状态的克隆。
不幸的是，迁移操作可能会导致NF状态更新的丢失和乱序，因为迁移之后到达NF实例的分组将被丢弃，应用网络转发状态更新和重新恢复网络流之间仍然存在竞争。此外，编排器和NF模块式针对特定问题的，使得他们不能很好地支持复杂的控制应用。最后，NFs必须使用API来创建和访问状态，通过使用不是基于流状态的秘钥，使得当流被重新路由时，很难知道存在状态的转移和复制。API值允许每种流一种状态分配，需要重建一些内部NF状态和分组处理逻辑。我们在本文的后面章节更详细地讨论这些问题。
3 OpenNF概述
OpenNF是一种新的控制平面架构（图2），这种架构满足上述需求和挑战。本节中，我们将列出关键思想，§4 和 §5中详述细节。
图2 OpenNF架构
OpenNF允许控制应用直接管理NFs的行为和性能，以满足高标准的要求。基于NF输出和外部输入，控制应用：（1）、确定特定NF实例应该处理的流集，（2）、指示控制器提供每个实例所必须的状态，包括流特定状态和流之间的共享状态，（3）、让控制器提供状态和状态操作的特定保障。
相应地，OpenNF控制器封装了分布式状态控制的复杂性，当被请求的时候，为状态和状态操作保证不丢失、不乱序和一致性。我们设计了两个新的方案来克服潜在的竞争条件：（1）、一个抽象的事件，控制器用来直接监视状态的更新，或者阻止更新但是知道哪些更新是预期的，（2）、一个两阶段的转发状态更新方案。使用前者，控制器可以确保转移操作部丢失，和状态副本最终的一致性。通过利用方案2中的步骤，仔细测序状态更新或更新一致性（方案1），控制器可以确保转移操作的不丢失和不乱序；我们在技术报告中提供了正式的证明。最后，通过缓冲与预期更新相应的事件，并一次一个地处理状态的副本，控制器可以确保状态副本的严格一致性。
OpenNF的南向接口API为控制器定义了一个标准的NF接口，用于请求事件和内部NF状态的进出。通过一个出口调用，NFs用它来完成所有状态的过滤器匹配，和确定如何将现有状态和进口调用提供的状态合并。这需要对NFs进行适当的功能添加，关键的是不能限制，或者需要对NFs维持的状态数据结构进行更改。此外，我们使用已定义好的流的概念（比如，TCP连接）作为基础，来指定哪个状态进和出。这就自然和NFs已经创建，读取和更新的状态保持一致了。
SDNLAB社区译者 正在火热招募中
成为译者的好处：
- 优质的英文原材料，最直接的提升英语能力
- 提高社区影响力，国内极具影响力的SDN交流平台
- 最优的内容传播途径，认可才是硬道理
- 社区福利免费拿，一手的学习资料
- 分享推动SDN发展，提供国内新鲜的技术资料
什么样的人才能成为译者？
- 热爱分享、热爱社区；喜爱SDN等网络创新技术；
怎样成为译者？
1、添加微信：353176266 或点击识别二维码
2、进行自我介绍
3、阅读社区提供的翻译资料
4、翻译测试
编译类仅出于传递更多信息之目的，系SDNLAB对海外相关站点最新信息的翻译稿，仅供参考，不代表证实其描述或赞同其观点，投资者据此操作，风险自担；翻译质量问题请指正。
