2.2 控制平面和数据平面做什么

我们首先探讨控制平面和数据平面的基础组件和行为，它们为什么不同，以及它们应该如何实现。

2.2.1 控制平面

从高度抽象的角度来看，控制平面在本地建立了用于创建转发表项的数据集，数据平面利用转发表项在设备的出入端口之间转发流量。其中保存了网络拓扑的数据集被称为路由信息库（RIB）。在与网络中其他控制平面通信的过程中，RIB总是保持其一致性（如不会产生环路）。转发表项通常被称为转发信息库（FIB），并且一般在设备的控制和数据平面上保持镜像关系。一旦RIB被视为一致且稳定，FIB马上就会被创建出来。要执行此任务，控制实体/程序必须建立一个网络拓扑的视图（view），此视图必须满足一定的约束条件。网络的这种视图可以通过人工编程来得到，通过观察来学习，也可以从与其他控制平面实例的通信中所收集的零散信息中构建出来。这种控制平面之间的通信可以通过一种或多种路由协议、人工编程或这两者的结合来实现。

图2-2通过一个交换机互连的网络来展示控制平面和数据平面的机制。该图的顶部是一个交换机互连的网络，图下部还展示了其中两台交换机（图中标记为A和B）的控制和数据平面的细节。数据分组被图下部最左边的交换机A所接收，最终转发给图下部右边的交换机B。请注意，在交换机内部结构展示图中，控制平面和数据平面是分开的，控制平面和数据平面各自运行在自己的处理器/线卡上。控制平面和数据平面都包含在一个机箱内。在本章的后续部分，会探讨此种或其他种类的控制平面和数据平面的物理放置位置方式。在图中，数据分组在数据平面所在的线卡的输入端口被接收。举例来说，如果收到一个含有未知源MAC地址的数据分组，数据分组会被转发或重定向（图中标为4）到设备的控制平面上。控制平面学习、处理，然后继续转发此数据分组。控制分组流量如路由协议消息（例如OSPF链路状态通告）也会这样处理。一旦路由协议的数据分组被传送给控制平面，其中所包含的信息就会被处理，并且可能会导致RIB的变更、或者向其他对端设备发送额外的消息以通知这项更新（即学习到了新路由）。一旦RIB变得稳定，控制平面和数据平面上的FIB就会被更新，转发也就随之被更新以体现此路由的变更。如果收到的数据分组的源MAC地址是未知的，控制平面处理后还会将数据分组（图中标为C）返还给数据平面（图中标为2），以便转发数据分组（图中标为3）。如需对FIB进行额外的编程，如FIB学习到该MAC源地址，同样也在这一步骤（图中标为C）里完成。右边的下一台交换机中也采用了同样的处理数据分组的算法。

互联网发展历史可以大致反映为面对各种挑战而引发的控制模式的变革，这些控制模式包括对网络信息可达性管理、可达性信息分发协议和生成优化路径的算法。这些挑战包括不断增长的信息库（即路由表的增长），以及如何管理这个信息库。不这样做很可能会导致物理网络非常不稳定；而这么做又可能导致网络的变化速度过快，甚至让网络无法运转。随着路由信息库规模的增长，另外一个需要克服的挑战是对部分目的/目标数据的可达性进行宣告的责任分散问题（Diffusion of responsibility），这种通告不仅是在本地数据平面实例之间，而且是可以跨越管理界限的。

在现实中，刚才讨论的互联网的控制平面是二层和三层控制平面的某种组合。因此，二层/三层网络和组成其控制平面的协议都出现发展和演进也不奇怪。实际上，互联网的发展就是由于两个方面的演进，即这些协议在功能上的演进，以及硬件厂商掌握了高扩展性和高可用性的技术以实现协议的演进。

二层控制平面专注于硬件或者物理层地址如IEEE MAC地址。构建一个三层控制平面是为了使用网络层地址，如IP地址。在二层网络中，围绕MAC地址的学习、保证无环路拓扑的机制（如大多数读者所熟悉的生成树协议）和大量的BUM（广播、单播和组播）洪泛流量，都会造成其可扩展性方面的挑战，并揭示出可扩展性上的局限。为了解决这些问题及其他问题，人们已对标准的二层控制协议进行了多次更新换代。最值得注意的是，这些协议里包括了IEEE的SPB/802.1aq以及IETF的TRILL。

不过，一般来说，由于大量终端主机的存在，二层网络终究是不能很好扩展的，这导致二层和三层把它们的控制平面设计最终合并或混合在一起。这些问题的核心在于如何处理终端主机在网络之间迁移的问题，这会导致转发表的大量振荡，并且必须快速地更新转发表，以防止数据流量的转发被中断。二层网络中的转发专注于MAC地址的网络可达性。因此，二层网络为了进行转发，主要处理MAC地址的存储。因为在大型企业网络中，MAC地址的数目庞大，管理这些地址十分困难。更糟的是，想象一下，管理多个甚至整个互联网的MAC地址会是多么困难的事。

在三层网络中，分组转发着眼于网络地址的可达性。三层网络的可达性信息主要和目的地址的IP地址前缀的可达性有关。这包括了各种不同地址类型的网络前缀，包括单播和组播。如今三层网络被用于二层域之间的分隔与合并，以克服二层网络所存在的扩展性问题。具体而言，部分IP子网的二层网桥一般都和三层路由器相连。三层路由器也被连在一起，组成一个更大的网络，或者几个拥有不同地址范围的子网。更大的网络通过专门为大型网络间互连而设计的网关路由器与其他网络相连。然而，在上述这些情况下，路由器在为三层网络之间的数据流提供路由时，只有在已知数据分组已经到达最终目的地所在的三层网络，并且需要将它传送到特定的主机上时，才会在二层进行转发。

随着多协议标签交换（MPLS）协议、以太虚拟专用网（EVPN）协议、位置/身份标识分离协议（Locator/ID Separation Protocol, LISP）的出现，二层和三层网络之间的界限才开始变得模糊。MPLS协议实际上是一系列的协议，集二层转发（或交换）和三层路由之所长，同时拥有了ATM那种极其快速的数据分组转发，以及从IP借鉴而来的高度灵活和复杂的路径信令技术。EVPN协议试图通过将两个相距较远的二层网桥用MPLS（或GRE）隧道连接来解决本章刚刚讨论过的二层网络的扩展性问题。这样二层寻址和网络可达性信息可以通过这些隧道来传递，从而避免对其之上的三层网络造成干扰（或影响）。相距较远的网桥之间的网络可达性信息在一个新的BGP地址段里作为数据来传输，同样不会干扰其之上的网络。其他一些优化限制了网桥间交换的二层地址的数量，并对网桥之间的交互做了进一步的优化。这种设计将广播和组播的需要最小化了。另外一种值得一提的二层和三层网络的混合是LISP（参见RFC 4984）。在其核心，LISP试图解决普通分布式控制平面模型在多宿主、增加新的寻址域，以及通过在新的映射/封装控制和转发协议将站点的地址空间与厂商的地址空间分开等方面的不足。

在稍微低一些的层次上，某些类型的网络有一些辅助控制进程，被用来提供构建更强大的控制平面所需的信息。这些进程提供的服务包括链路可用性或质量信息的验证/通知、邻居发现和地址解析。

因为这些服务中有些有着非常严格的性能回路要求（为了缩短事件检测的时间），所以不管控制平面采用的是什么策略，它们几乎不约而同地在本地的数据平面设备里实现（如运行、管理与维护OAM）。图2-3通过展示由多种路由协议及RIB到FIB控制所组成的控制平面核心来描绘这一点。请注意，这里并不是非要规定控制和数据平面所处的位置，只是说数据平面放置在线卡上（图2-3的LC框里），控制平面位于路由处理器上（图中由RP框表示）。

2.2.2 数据平面

数据平面通过一系列链路层操作来处理（通过线缆、光纤或无线媒介）到来的数据分组。这些操作通常包括数据分组的收集和基本的完整性检查。数据平面通过查询由控制平面所编程的FIB表（在某些实现中，可能是多个FIB表）来处理一个格式正常的数据分组。这有时被称为数据处理的快速路径（fast path），因为它除了利用编程好的FIB识别数据分组的目的地址之外不需要额外的操作。这个流程的一个例外是，当数据分组不能匹配这些规则时，例如检测到一个未知的目的地址时，这些数据分组就会被发送到路由处理器上，这样控制平面就可以进一步利用RIB来处理它们。重要的是需要知道，FIB表可能存在于一系列的转发引擎中，包括基于软件的转发、基于硬件加速的软件转发（GPU/CPU，例如Intel公司或ARM公司的产品）、基于通用商品级芯片的转发（NPU，例如博通公司(Broadcom）、Intel公司或Marvell公司在以太网交换机市场推出的产品）、基于FPGA的转发以及基于专用集成电路的转发（ASIC，例如瞻博公司的Juniper Trio），或者它们的任何组合，具体取决于网元设备的设计。

这里所阐述的软件路径（software path）以现代专用的网元设备（例如路由器或交换机）的基于CPU的转发为例，它以处理器密集查询（在内核系统空间还是用户空间是由特定厂商的设计所决定的，受限于主机操作系统的架构和特征）换取处理器内存的看似无限的转发表项存储。现代计算环境中所对应基于虚拟机管理程序（hypervior-based）的软件交换机或网桥有许多硬件转发模型上的优化（以及一些局限）。

从历史上看，硬件表查询技术已经被证实可以达到相当高的数据分组转发性能，因此其在网元设备设计中占有首要地位，尤其是在高带宽的网元设备中。然而，受到云计算增长和创新的推动，最近在通用处理器输入输出处理方面的进展，使基于专用集成电路转发芯片设计的中低端性能的设备的竞争变得相当激烈。

硬件转发设计方面的差异涉及多种因素，包括（板卡和机架）空间、预算、能效以及吞吐量的目标需求。这些会导致维持针对特定的目标数据分组长度（或者混合的数据分组长度）的线速转发（一个接口上接近信号上或理论上最大的吞吐率）所需的存储器类型（速度、带宽、大小和位置）的差异，以及运行预算（对数据分组操作的数量、序列或类型）的差异。最终，这导致转发特性支持和转发规模（例如转发表项的数量、路由表的数量）等设计上的差异。

数据平面转发查找结果带来的典型操作就是转发（在特殊情况如组播下，此典型操作是复制）、丢弃、重标记、计数和排队。某些动作可以组合或者串连起来。在某些情况下，转发选路操作会返回一个设备内的本地端口，这表明流量被定向到一个在该设备内部运行的进程，比如OSPF或者BGP。这些数据分组会采用被称为上传路径(punt path)的路径，即借以离开硬件转发路径，使用内部通信通道转发到本设备的路由处理器。这个路径通常是一条相对较低吞吐率的路径，这是因为它不是设计用来做正常流量的高吞吐率包转发用的；然而，为了高吞吐率，有的设计可以简单地在内部交换矩阵里增加一个额外通道，这样就能达到在设备内部接近线速转发的目的。

除了转发选路操作之外，数据平面可能实现一些轻载的服务/特性，通常称为转发特性（例如访问控制列表和服务质量/策略）。在有的系统中，这些特性使用它们自己独立的表项；而有的系统则作为转发表的扩展（通过增加表项的宽度）来执行。此外，不同的设计可以实现不同的特性和转发操作顺序（如图2-4所示）。一些排序可能使某些特征操作排斥于其他操作。

使用这些特性，用户可以在一定程度上本地调整或者占有转发表查询的结果。举例如下。

• 一个访问控制列表可以对某个特定的匹配流指定一个丢弃操作（注意，在ACL中，一个较宽泛的参数集合可以被用到转发选路中）。由于ACL也可以有合法的转发表项，所以数据分组不被丢弃。

•一个服务质量（QoS）策略最终把一个流映射到出口的一个队列，或者重标记它的TOS/COS字段来对网络策略的服务进行规格化。就像ACL，不管是否已经存在到这个目的/流的转发表项，它都可以将分组标记为丢弃（整形）。

这些转发特性会与第7章中对服务的定义相重叠。可以说，这些特性是作为服务的数据平面和控制平面的组件而存在的。当本书讨论会话管理、代理以及数据分组包头的大规模转换等服务时，这些定义就有明显差异了。作为转发操作的组成部分，数据平面需要做某种程度的数据分组包头重写。

2.2.3 在控制平面和数据平面之间传递信息

当前大型多槽/多线卡的（即机架式的）分布式转发系统的内部功能，与SDN的逻辑上集中但物理上分布式的控制机制相仿。特别是路由表的分发和它们在硬件的实例化这些方面会令人感兴趣。研究典型的分布式交换的内部工作情况就可以揭示与外部化的控制平面相仿的一些功能和行为。例如在系统中，控制平面位于独立的处理器/线卡上，而数据平面在其他独立的线卡上，为了系统的故障恢复和容错，围绕这些组件之间通信需要有某些操作。如果控制平面从机箱中移走或者放置于更远的位置（例如逻辑上或者严格的集中式控制平面），那么所有的这些通信机制是否还都需要，就会是很值得探讨的问题了。

首先从基本的数据分组转发的概念开始讨论。当控制平面要求数据平面转发数据分组时，数据平面听得到指令吗？当数据平面正在忙于处理每一个它所接收到的数据分组时，数据平面能听得到指令吗？更具体地说，是否存在流量被引到黑洞（即，在不同厂商实现的硬件转发系统中，分组被丢弃而无从知晓）？这个问题和控制实体/程序是集中式的还是半集中式，或者是分布式的（即与其他网元设备的控制平面之间是同步式的），都是无关的。在这些系统中，对转发表的分发错误的检测功能可以嵌入到数据中（例如转发表的版本控制），或者嵌入到转移机制中（例如使用某种形式的哈希或者从表的内容产生的cookie来给转发表签名）。这样的机制可以确保分布式转发表的软件版本及时同步，而且万一出错可以被纠正。同样，在路由表的软件版本和硬件版本之间的校验例行程序，可在存储器的驱动软件中实现（针对特定的转发硬件）。

一些厂商实现了采用例行程序来对硬件表项进行事后校验，即在控制平面对数据平面编程之后，才检查转发芯片及其附属存储器的软故障。在这种情况下，将会有相关的例行程序去标记坏的存储块、移动表项、建立引用表项。通常，这些硬件校验例行程序的运行开销很高，所以它们经常被作为后台进程（又称“清道夫”）执行。为此，搬迁和内存读写例行程序也通常通过批处理或块处理技术来优化以降低运行开销。

一些多槽/多线卡的系统设计为两级查询，在入口第一级仅简单标记出口的槽位/线卡，然后在出口那里执行第二级的查找。根据如何被实现，两级查找可以做到如下这样的一种优化，即允许一种被称为本地化的技术来减少出口FIB表的大小。在此情况下需要注意的是，两级查找的“异步损失”的场景有可能会发生，并且除非它们失效了，否则很难检测到，这些与SDN转发控制是相关的。

在图2-5的左半侧显示了一台在做两级查找的多槽路由器/交换机。当链路A-B出现时，在线卡1内的FIB入口查找的结果就从线卡3变到了线卡2。如果对线卡2的更新发生在线卡1和3之后，则在出口上的第二级查找就会失败。类似地，在SDN环境中（显示在右半侧的云中），如果在这些系统上，连接A和B的隧道（分别地）从接口3变到接口2（由于管理或者网络事件），那么随后在这些网元设备上，流量从1-3转到1-2的映射就需要通过SDN控制器（即图中的CP）上的应用来同步。

当本书后续讨论集中化控制平面的一致性问题时，将会进一步探讨所提到的这些迁移技术/优化。

2.2.4 为什么控制平面与数据平面分离变得重要

控制平面和数据平面分离不是一个新的概念。实际上，在过去十年中研发的任何多槽路由器/交换机都具有运行于专门处理器/板卡上（为了实现冗余，通常是两张卡）的控制平面（即其大脑），并具有独立地运行于一张或多张线卡上的数据平面的交换功能，每一张线卡都有专用的处理器和/或分组处理器。图2-6通过路由处理器引擎说明了这一点（在图2-6中表示为路由处理器方框）。

在图2-6中，数据平面的实现在下面的方框中，都是分离的线卡，带有端口处理专用的集成电路ASIC芯片来连接此线卡的入端口和出端口（即以太网接口）。在正常的操作下，图2-6中的端口带有转发表，它指示了如何处理带内到带外的接口交换。这些表项被路由处理器的CPU/控制平面程序所设置和管理。当控制平面消息或者未知的数据分组到达这些接口时，它们通常会被推送到路由处理器做进一步处理。可以认为路由处理器和线卡通过一个很小的但是高速的内部网络连接起来，实际上现代交换机就是这么设计的。

除此之外，协议按照此结构来设计就可以优化和提高其性能。例如，多协议标签交换（MPLS）协议使用IP协议簇来承载控制流量，这样可以理想化地在通用CPU上运行专用路由处理引擎；而MPLS的固定的基于标签的交换功能最适于采用各个线卡上的简捷的但是相当高效的分组处理器来实现。

在SDN被人们讨论之前，控制和数据平面分离的距离范围是在大约一米的距离（在同一个机箱之内，或者直接相连的多机箱系统内）。在前面各节中描述的控制平面和数据平面，虽然是分布式的，却是作为紧密集成的（并且相对紧密地放置在一起的）硬件和软件的组合进行搭建和管理的。除了这些组件和非常多的对系统外部观察者所隐藏的内部结构外，对这些组件的包装结果导致了利益驱动的网元设备利润。这些网元设备经常在相同的硬件产品线之上进行开发，以基于服务、管理、控制和数据平面之间的平衡为设计的着眼点，并在吞吐率（以及复杂性）上有所变化。这种多平面间的紧耦合导致的互相依赖产生了一些围绕革新、稳定性以及规模问题，而规模问题最终可导致上述所有领域的性能问题。然而，解决这些问题由于非常复杂因而开销高昂，这是SDN出现的一个方面的原因。本书会从读者的着眼点讨论每个组件，这种讨论可以看清其所带来的每个问题，亦或是其所带来的各种益处。

1．规模是重要的

路由和交换系统的可扩展性问题可能会以各种各样的形式存在，并会涉及各方面的问题，举例来说，可能从原始数据分组转发性能到电能消耗。最终，这些扩展性问题将在开销和性能之间做出平衡，具体说明如下。

服务板卡受限于板卡的更新换代来支持特定数量的预订者/流/服务。这是由于服务板卡（特别是那些使用特殊的嵌入式CPU）不得不使用特定厂商的系统互连和交换矩阵。在新型号系列处理器（或者是板卡当前使用的型号系列里的新处理器）的推出，与服务板卡能真正获益于该处理器的升级之间，就存在着很大的时间差距。最重要的是要花费相当多的时间来做额外的定制化设计。令人遗憾的是这将导致系统成本的增加。

对于特定一代的转发芯片，其转发板卡支持特定规模的转发表项，但是其中某些板卡相对于主控板上的控制处理器，具有自己独立的本地从属处理器或者协处理器。但这些处理器也有本地处理的一些限制，例如，在某些设计中，在转发板卡CPU上运行数据流采样，可能导致本地CPU使用率上升，因而消耗系统的CPU处理资源。

控制板卡内存能处理一定规模的路由表或者其他状态，并受限于板卡上CPU处理能力的更新换代。但是内存也用来存储控制协议状态和管理信息，例如BFD或者SNMP。所以对于此类设计存在一个基本限制，也就是说，可以买到最快的内存，但这也是最昂贵的。

2．演进

因此，过去网络运维人员不得不依靠硬件升级的方法，来解决控制平面扩展或者处理性能相关的问题。而与此同时，运维人员需要关注转发板卡扩展性以及性价比，并在合适的时间进行升级。虽然在高度专用的平台解决方案中，它与控制平面分离的讨论更相关，但它必须在服务板卡和转发板卡之间的比率中做出平衡，这可能严重缩减设备的整体转发性能（将转发插槽用于服务插槽）。设备厂商试图改善这种情况的一个方法是通过分离控制和数据平面，以便它们能独立演进和扩展，或者至少比它们组合起来要好。

SDN推动的对于传统设备演进上的改变在于，虽然在控制以及服务平面仍然存在一个“增长/扩展-升级”的周期以适应扩展性，但在商用现货（COTS）计算环境下却很容易实现。在云计算推动的环境下的创新尤其是这样。把控制平面从管理过程中分离出来，进一步造成了一定程度的扩展性影响，这个问题可以通过在路由器/交换机内的COTS硬件或者远程运行这些用户级的进程来解决。

硬件转发组件将会仍然沿着其自身的升级周期规律来应对转发规模的扩大，而不用考虑控制平面（即路由处理器）的配置。来自转发平台带宽/吞吐量需求的升级，是正常的汇聚模型的一部分，即大部分较低速转发组件放置在靠近网络边缘的位置（当它们的功能变得更加通用时，这会是潜在的更为可能发生的场景）。图2-7对此进行了说明。

3．成本开销

虽然这是个吸引眼球的字眼，但和其他推动控制平面与数据平面分离的因素相比，关于成本开销可说的内容相对较少。成本开销由资产部分（投资成本CAPEX）和运营部分（运营成本OPEX）组成。成本开销由这些因素推动：规模（投资成本的推动力）、复杂性和稳定性（运营成本的推动力）。首先从关于投资成本的显而易见的陈述出发，对于众多客户（特别是运营商或者运营数据中心的大型企业），和他们的网元设备处理开销相比，通用计算（采用了COTS）的处理开销是非常小的。而采用SDN的集成服务，与控制板卡相关联的集成开销会导致某些成本差额。坦白地说，成本差额在某些情况下也由厂商的利润期望所推动，这些厂商采用的是非单独授权的操作系统（控制、管理和服务处理）。这是一种追回他们知识产权的投资，并为正在进行的维护和开发提供资金的方式。

这正是后续话题的微妙之处。虽然SDN无疑能缩减成本中的硬件集成部分，但厂商的知识产权（控制或者服务）正是可以被重新定价，成为厂商视为真正有价值的部分（这还有待被市场检验）。而且，集成成本将被算入软件组件中。

4．创新

带来创新性的收益是控制和转发平面分离优点的一个论据（当考虑到服务平面也会分离时，这一优点的说服力就更强）。理论上来说，分离能够给用户带来收益，通过改变软件分发模式，使得任一平面都能互相独立地进行升级更新（相对于当前模式，即每个平面的升级更新，都受限于多平面集成的整体更新升级周期）。

与控制/数据分离更有关的能力是支持在转发平面中引入新的硬件而不必去更新控制平面（例如，通过在控制平面安装新的驱动程序，来适应数据平面设备的物理处理的更新）。

5．稳定性

当本书在讨论SDN环境下这些平面的分离时，可能会存在一些问题，即一些控制平面的子部件不能被集中化，而是采用本地代理（可能多于一个）来接受对转发的修改，并向中心控制点反馈聚合后的管理信息。如果不考虑这些现实问题，通过分离控制和数据平面，由于得益于更小更稳定的代码库，转发网元设备可以变得更加稳定。这一假设前提：较小的代码库更稳定，在目前是被普遍接受的。例如一个相关并且流行的关于SDN优点的说法，来自于推倒重来的全新的主张。该主张假设在一些领域，比如多协议标签交换（MPLS），循序渐进的软件功能开发工作，通常会沿着一条通过增加已有代码来升级功能的道路缓慢进行。这种开发方式会导致复杂性的增加以及底层上的脆弱。研究结果表明，实现使用集中式的标签分发，来仿效分布式的LDP或者RSVP协议，以及集中式的网络拓扑信息获知，其代码量可以比当前可用的商业代码库至少减少一个数量级。通常认为在一个高度规范和集中式的控制系统中，网络行为是完全可以类似于静态转发，按理说这会是很稳定的。

6．复杂性及其导致的脆弱性

使用多少控制平面，以及这些控制平面放置于何处，这个问题直接反映了网络的规模、性能和可恢复性。对于缺乏可恢复性，本书中称之为脆弱性。特别是网络运维人员会在一个网络内，规划和部署足够的设备，来处理一定比例的峰值需求。当使用率达到峰值时，必须部署新的设备来满足需求。在传统的路由和交换系统中，有一点非常重要，就是要知道，在网络内不增加被管理的设备，及其相应的控制协议实体的数量的情况下，网络究竟能满足多少本地的转发吞吐量。从上述论述中可以看到，在交换机和路由器设计的通用模型中，将使用完全分布式控制平面模型，这就意味着对于每一个部署的设备，都需要在机箱内启动一个控制平面的实例，来控制机箱内的数据平面。接下来的问题是：对于网络收敛问题（即整个运行的控制平面，达到无环路的一致的网络状态所需花费的时间），这个额外的控制平面是如何影响整个网络的控制平面的规模的？回答是：它确实影响了整个系统的可恢复性和性能，并且控制平面的数量越多，系统就越会存在脆弱的隐患。如果调整系统，它也能增加抗脆弱性，但这样就最终会变成不能与外界条件变化保持一致的系统。简单地说，在分布式或者最终一致性控制模型中，交互协议的数量过多，会引起管理和运营的复杂性。

起初，通过建立单机设备的小型系统集群，来减缓控制平面的增长。集群的每个单元，通过通用的机箱之间的数据和控制的交换矩阵黏合起来。通常交换矩阵的实现是小型的、专用的交换式以太网。多机箱系统又前进了一步，通过在机架间提供互连交换矩阵，因而使多机箱系统作为单一的逻辑系统来运作，被单一的控制平面所控制。机箱之间的连接，也可以通过外部（网络）端口互联来实现，集中式控制平面是使用多个虚拟控制平面实例，即每个机箱内一个虚拟控制平面来实现的。由于它对网络运维人员只显示了单一的IP地址，所以它可以作为一个逻辑实体被管理。图2-8对两种方法进行了展示。

在图2-8的集群和多机箱系统设计中，由一个互连的控制用的以太网（通过冗余以太网交换机实现）连接的外部控制平面，允许外部控制协议分组流在线卡（端口）机架的处理器和控制处理器（例如路由引擎）之间进行转发表更新和设备管理。

目前业内开发了两种策略来实现这些系统的控制。第一个策略是在机箱中（处理部署位置）多个控制点之间，将处理功能进行分布式设计，从而更加充分地利用处理能力（以及扩展规模），或者在一个外部控制系统（被连线到系统的控制交换矩阵里）集中化处理。第二个策略是潜在地把扩展点转移到一个更加模块化和技术上更快移动的设备上（这些通常是一个集成的交换和计算设备，不需要特定的形式、母卡架构、或私有交换矩阵接口）。

应该注意到多机箱或者集群系统中，尽管还没有解决控制平面的可编程性/灵活性问题，但后者仍旧具有某些SDN的特点（控制平面集中化和更独立的扩展）。

对于在减少设备中建立转发状态的协议和协议交互的数量方面，还是有潜力可以挖掘的。图2-9显示出在一个IGP/BGP/MPLS网络中的进程交互，通过学习/宣告地址前缀和标签绑定，来在数据平面上安装转发表项。