《SDN：为什么要分离控制平面和数据平面.doc》由会员分享，可在线阅读，更多相关《SDN：为什么要分离控制平面和数据平面.doc（6页珍藏版）》请在三一文库上搜索。
1、SDN为什么要分离控制平面和数据平面控制面和数据面的分离并不是一个新概念。例如，在过去 10余年中制造的 任何多插槽路由器/交换机内都有运行于专用处理器或板卡 （为了确保冗余保护， 通常是两个）的控制平面，以及独立运行在一个或多个线路卡 一一每个线路卡都 有一个专用处理器和/或分组处理器一一的数据平面交换功能。图1通过显示路 由处理器引擎架构（图1中的路由处理器框图）说明了这一点。在图1中，下面的方框 这是一个单独的线路卡，有专用的端口处理ASICs 连接线路卡上的输入端口和输出端口（例如以太网接口）是数据平面。在正常的运行中，图1中的端口都由转发表来决定它们如何处理数据从进入到流出的 接口转
2、换。这些表是由路由处理器的 CPU或控制面程序进行填写和管理。当这 些接口收到控制面消息或未知的数据包时， 它们一般会将这些数据上推至路由处 理器作进一步处理。请将路由处理器和线路卡之间连接想成是通过小而高速的内 部网络来完成，因为这实际上便是一台现代交换机的工作原理。Route ProcessorManagementCentralServicesDataEgressInterfaceIngressInterface图1控制平面和数据平面的实现实例除了这些，一些协议采用这一架构实际上是为了优化和提高其行为。例如， 多协议标签交换（MPLS协议使用IP协议族承载控制流量，其理想情况是部署 在一个
3、运行于通用 CPU 的专用路由处理器引擎上；同时在另一个线路接口卡上 实现一个（最适合于更简单但性能更强的分组数据包处理器引擎） 固有的基于标 签的交换范例。到目前为止，有关 SDN 以及其控制平面和数据平面之间的距离都是在米的 数量级上（例如，在单个机架内，或一个直连的多机架系统内） ，上一节中描述 的控制平面和数据平面是分布式的， 但被作为紧密集成 （位置也相对接近） 的软 件和硬件包被建造和管理。 除了这些外部系统观察者看不到的组件和众多内部架 构，对这些组件的封装导致了目的导向的网络组件的大量出现。 这些网元经常都 建立在相同的硬件家族的基础上， 但由于在服务、 管理、 控制平面和数据
4、平面之 间的不同权衡，它们会有不同的吞吐效率（和复杂度） 。平面之间的紧密耦合产 生的相互依赖产生很多有关创新、稳定和规模的问题（激励） 最终导致这些 领域的性能提高。 然而，这些设计由于极其复杂而导致其成本很高， 这也是激励 SDN改进的一个因素。接下来将会探讨每一个组件，因为这个讨论会突出每一个 问题，或优势，而这些看法是因人而异的。1， 规模因素一个路由和交换系统可以用很多方式进行扩展， 再加上一些问题 从单纯 的原始数据包转发性能， 到需要考虑功耗。 最终， 这些可扩展性问题成为成本和 性能之间的不断地平衡角力：服务线路卡（Service Card）被限定为一定数量的用户/流/服务状态
5、一一 这些状态只能支持特定一代的线路卡。此外，由于服务线路卡（尤其是 那些使用特殊的嵌入式CPU必须使用制造商特有的互联方式和交换阵 列，因此在（新处理器可以使用）和（一个新的服务线路卡能使用这个 创新）之间存在明显的滞后。这里的底线是，它需要相当长的时间做额 外的用户定制设计。很不幸这导致系统成本的增加。对于特定一代的转发芯片设计，转发卡（Forwarding cards能够支持特 定规模的转发表项，但是其中有些板卡相对于控制板卡（ control bo a rd ）上的控制处理器而言 有着自己独立的本地从属处理器或者 协处理器，而这些处理器反过来有着自己的处理限制比如，在某些 设计类型的转
6、发卡CPU上运行数据流采样，可能导致本地 CPU使用率 上升，并且消耗系统的 CPU处理资源。控制板卡内存能够处理一定的路由规模或其它状态， 并且受限于于板卡 上的CPU能力的更新换代而产生的处理能力限制， 但内存也同时用于储 存控制协议状态和管理信息（比如BFD或SNMP）。这些设计的另一个限 制是这些内存是花钱可以买到的最快的内存，因此成本是非常高的。2， 演进 因此在过去，网络运营商不得不遵循硬件升级路径来解决控制平面上与扩展 性或处理性能相关的问题。 在做这些事情的时候， 运营商不得不时刻关注转发板 卡的扩展性和性价比， 以便在合适的时间进行升级。 虽然在高度专用的平台解决 方案中更适
7、合讨论控制平面的分离， 但是运营商们或许不得不平衡业务板卡和转 发板卡的数量比例 这可能严重缩减设备的整体转发性能 （当将转发插槽用作 业务插槽）。设备厂商试图改善这种情况的一个方法是将数据平面与控制平面分 开，以便它们可以分开独立演进和扩展 或者至少比它们合在一起时更好处理。SDN驱动对典型设备演进的改变在于， 虽然在控制（和业务）平面或许仍然 存在增长/扩展和升级”循环以适应扩展性，但这些在商用现货（COTS计算市场实现却容易得多。有了云计算驱动环境中的众多创新之后，就更是如此。 而且，将控制平面从管理过程中切开，更进一步地（通过在路由器/交换机内的COTS硬件上运行一一甚至是远程运行一一
8、那些用户级的过程）提供一些层面的 扩展影响隔离。硬件转发组件仍然将遵循自身的升级周期规律来应对数据转发的扩展需求， 而不用考虑控制平面（即路由处理器）的配置。处于带宽 /吞吐量需求的转发平 台的升级是一个正常汇聚方案的一部分，那里大部分低速转发组件被有代表性地 重置到靠近网络边缘的层级（当它们的功能变得更加通用时，这会是潜在的更有 可能发生的场景）。图2描述了这些。图2将集成在一起的管理、控制、服务和转发平面分离，使它们能独立扩展3， 成本成本分成投资成本CAPE冷口运营成本OPEX成本开销由这些因素驱动：规 模（投资成本的驱动力）、复杂性和稳定性（运营成本的驱动力）。在投资成本这 块，对于很
9、多使用者（特别是业务运营商或运行数据中心的大型企业）来说，基 于通用计算设备（COTS的处理开销的成本是很便宜的， 而与之相比，基于网元 的处理开销的成本则高得多。 而业务板卡和控制板卡的集成产生的集成成本则会 导致成本的变数。 必须承认， 有些成本变数收到生产这些系统控制、 管理和 业务部分的许可权常常不会分开授予的设备商的利润预期所驱动。 这是一种 回收它们对知识产权的投资和资助后续维护及开发的方法。虽然 SDN 无疑将减少成本中的硬件集成部分，与设备商的知识产权（控制 或业务）相关的那部分成本有可能被重新定价， 达到设备商感觉应该达到的价值 （当然需要被市场来检验） 。另外，软件中的集成
10、成本依然存在。4， 创新可能有这样一个观点， 认为将控制平面和数据平面分离会带来创新收益 （当 考虑到分离业务平面时，这种呼声就更高了） 。理论上，分离通过改变软件发布 模式允许任何一个平面都能够相对独立地创新发展 （与之相比的现有模式是 任何一个平面上的创新都受限于目的复杂的集成的庞然大物的建设周期） 能 给用户带来好处。与控制/数据的分离更相关的是获得（支持在转发平面引入新硬件而不需要 重复改动控制平面的） 能力，比如设备的物理层处理可以通过新的驱动程序获得 数据平面的创新。5， 稳定性在讨论 SDN 环境下这些平面的分离时，有可能控制平面的有些子部件不能 被集中化，并且采用一个（也许不止
11、一个） 本地代理来接受对转发的修改和 （或） 将管理信息汇聚反馈给中央控制节点。 尽管有这些现实问题， 通过将控制平面和 数据平面分离，转发网元设备由于基础代码变得更小变化更少而有可能变得更加 稳定。6， 复杂性和其导致的脆弱性 关于存在多少控制平面和这些控制平面的位置的问题直接影响到网络的规 模、性能和弹性（或者因缺少弹性而导致的脆弱性） 。具体来说，网络运营商计 划在网络上部署足够多的设备， 以便能以一定比例处理峰值需求。 当使用量接近 容量时，必须部署新的设备以满足需求。 在传统的路由和交换系统中， 有一点非 常重要，就是要知道在不增加网络中被管理的设备和它们的控制协议实体的情况 下，能
12、够满足多少的本地转发吞吐量需求。 通常的路由器和交换机的设计范例是 坚定地使用分布式控制平面模式， 这意味着对每个被部署的设备， 都需要在机架 上配置一个控制平面实例。 问题在于： 这个新加入的控制平面会怎样影响整个网 络的控制平面的整体表现， 例如在网络融合方面的表现 （即运行中的控制平面整 体达到无回路状态需要的时间） ？答案是，这的确会影响整个系统的弹性和性能， 并且控制平面实例的数量越多， 系统增加的潜在脆弱性越大。 如果能恰当地调整 网络，的确能增加系统的弹性， 但是这也将产生一个不能与外界状况变化保持一 致的系统。 简单地说，在分布式或最终一致性控制模式中， 交互协议的数量的增 加
13、会制造管理和运行的复杂性。起初，通过使用单独网元的小型集群系统来减少控制平面数量的增加。 集群 中的每一个网元通过一个公共的跨机架的数据和控制阵列通常部署为一个 小型的专用的交换式以太网捆绑起来。 多机架系统又将这个概念向前推进了 一步，在分架之间提供了交互阵列， 从而表现得就像一个单独的本地系统， 由一 个单独的控制平面控制。 分架之间的连接性通过外部网络端口实现， 而集中控制 平面使用多个虚拟的控制平面实例一个实例对应一个分架。 由于它对网络运 维人员显示一个单一的 IP 地址，它可以被作为一个单一的逻辑实体来管理。 图 3显示了这种方法。1IIIGrd IfNLine Cardline tad Shelf 1 If2H RERE卯Active1) Met wknetwork Fabric Control Ethernet图3集群和多机架系统设计目前业界开发了两种策略来控制这些系统： 将处理能力分布在机架的多个控 制点之间，以更充分地使用处理能力（和扩展规模）；或者将处理能力集中到一 个外部控制系统。后一种策略潜在地将扩展点移到一个更模块化和技术演进更快 的设备上。应该注意到后一种多机架或集群策略已经有了 SDN的一些特征（控制平面 的集中化合更加独立的扩展性），尽管还没有解决控制平面的可编程性/灵活性问 题。