软件定义的网络（SDN）之忧（141027）

闵应骅

   SDN由基础研究提出来以后，得到众多公司的响应，反应极其强烈。从体系结构角度讲，它有许多优越性。但是，要逐步取代传统网络，谈何容易。传统网络有几十年的运行经验，作过不知道多少次修改和补充。要在SDN上实现所有这些功能，首先就要抽象化所有功能，才能找到实现的办法。下面，不妨列出一二。

模块组合

   在操作系统中，进程允许多用户在一个机器上共享可用资源，每一个进程联系着一个执行线程，与系统资源打交道，譬如存储器、锁存器、文件描述符、套接口等。操作系统要求进程之间的所有交互在指定的接口上发生。譬如，存储定位到一个进程不能被其他进程干扰，除非它是被明确规定由其共享的。虽然SDN控制器可以称为网络操作系统，但目前控制器缺少类似于进程的抽象，大部分仍给应用无拘束的访问交换机上的转发表。这就使网络很难模块化地写程序。这是一个很大的问题。因为SDN的许多应用是由标准模块，譬如路由、广播、管理、存取控制，建造起来的。不能模块化就要求程序员对每一个新应用的基本服务重新编程序，而不能从库中简单调用。例子如下：

转发和管理：交换表实现转发和管理两个功能，按规则严格选择某些包执行转发和管理这两个功能，其他的只执行一个。如果并行执行，规则就可能重叠，从而使系统行为无法预计。

带隔离的转发：网络分为两个相互隔离的主机群，流量是在同一个主机群里转发。程序把隔离和转发这两个功能分开，很容易把包转发到另一个主机群里去了，这是违反政策的。

短延迟视频和大容量数据传送：对于视频会议，网络必须提供低延迟服务，而且要允许一个后备应用，只要带宽允许可以沿不同路径转发流量。程序员必须同时考虑这两个功能。这些例子说明，如果必须允许程序员直接处理低层的网络状态开发SDN应用，用模块化的方式有效完成此事几乎不可能。

编程语言抽象：SDN应用模块化的一个办法是改变编程接口，而不是管理低层的交换转发规则。他们可以用编译OpenFlow的高级语言。这种语言允许程序员独立开发和测试模块，不必担心不想要的交互。程序员甚至可以用自己相同功能的模块去取代已有模块。

孤立切片：在某些情况下，程序员需要把几个程序互不干扰地组合起来。譬如，流量隔离时，两个转发模块必须互不干扰。直接合并肯定是不正确的，模块互动会引起包互相传送。要用一个抽象，允许多个程序并行执行，但限制每个程序到它自己的隔离切片。

分享的网络化：多模块的组合行为可能引起冲突。譬如，一个模块保留一条链路的全部带宽。其他模块就不能使用。

我们看到，分解复杂应用为简单模块的抽象对SDN极关重要。没有它们，程序员必须用统一的方式写程序，在每一段小程序之间同时进行开发、测试、潜在交互的推理。我们需要考虑一个模块是否可以取代另一个而不影响整个程序，需要表达和解决冲突，特别是牵涉安全和资源约束的性质。

虚拟化

   SDN把网络控制的软件从低端的转发元件分离出来。但它并不把转发逻辑和物理网络拓扑分离开来。这就意味着实现最短路由的程序必须保存拓扑的完全表示，而且当拓扑变化时必须重新计算。为此，某些SDN控制器提供基本单元，用虚拟网络元件写应用，更加可扩展，更加容错。下面是一些例子

存取控制：存取控制一般用MAC或 IP地址编码到网络配置中加以实现。这将使拓扑改变时，譬如主机移动位置，破坏安全性。假如存取控制表是用连接主机的虚拟交换来配置，即使拓扑改变，政策仍将保持稳定。

多用户数据中心：在数据中心，同一个共享的物理网络，人们希望允许多个用户对设备施加不同的政策。在传统网络中，重叠的地址和服务使得转发表复杂化，而且很难保证一个用户产生的流量与其他用户隔离。用虚拟交换，可以给每一个用户提供一个虚拟网络，具有任意的配置而不影响其他用户。

扩张路由器：在大型网络中，有时需要将多个物理交换机行为看作一个逻辑交换机。譬如，一大堆低廉的商品交换机可以装配成一台运营商级的路由器。这个办法不仅可以简化单个应用的转发逻辑，而且可以用于提高可扩张性。因为这种路由器只存在于逻辑级，它可以在必要时增加物理交换机而得到动态扩展。

这些例子说明虚拟化把转发逻辑与物理拓扑分开，可以使应用更加可便携、可扩展。

虚拟化抽象：为了定义一个虚拟网络，程序员要指定逻辑网络元件与物理网络元件之间的对应。譬如他可以把物理网络里的所有交换机影射到一个虚拟交换机，而且隐藏所有的内部连接，而创建一个特大的交换机。

虚拟化机制：为了实现虚拟化，许多平台用一个标签标记到来的包，将它与一个或多个虚拟网络联系起来。包处理的步骤是：首先，系统识别包的逻辑环境，即在虚拟网络中的位置，包括交换机和端口；其次，根据其逻辑环境处理这个包，即重新设置包的逻辑环境，有可能还会产生附加的包；最后，把该包影射到物理层。管理程序产生物理层的转发规则，同时实现这三步。一个问题是物理交换机能存多少规则。基于虚拟网络数和它们政策的大小，管理程序可能无法在交换机上容纳所有规则。像通常操作系统的存储管理一样，管理程序只能分页，把某些规则动态地移入和移出物理交换机。

我们看到，虚拟抽象是现代SDN控制器的重要部件。把程序和物理拓扑分离简化了应用，而且可以分享网络中多个不同的程序，而不互相打扰。虽然已经有多个产品控制器支持虚拟化，但还是有问题。低层的详情要在逻辑层表现出来。目前的SDN虚拟化在逻辑层和物理层提供相同的程序接口，删去了诸如链路能力、队列、逻辑交换能力等资源。另一个问题是怎么把虚拟化和其他的抽象，譬如相容性更新组合起来。但是，二者并不是总可以用标签方案组合得起来的。还有，目前的平台不支持嵌套的虚拟化。

形式验证

   现在的网络操作员用手动做底层物理配置，难免出错，引起网络的不可靠、不安全。SDN标准化网络硬件接口，极大地提供开发新方法、新工具的机会，很容易建造和运作可靠的网络。今列举某些特性如下，而这些特性可以动态或静态地形式检查网络和控制器的状态。这些特性可以分为两类：一类是基于网络拓扑的。只有给定网络结构模型才能叙述和验证。譬如：

连通性：主机发出的任何包总要最后达到预定的目的地，除非拥塞或故障。

无循环：没有包会经过循环路由回到原点，而包头和内容未变。

指路：从不可信主机发出的包在到达目的地之前会通过一个扫描恶意流量的中间盒。

带宽：网络对用户承诺服务层的最小带宽。

另一类是从拓扑无法得知，或者只关于一大类拓扑。这些性质是为获得应用对许多不同网络的一般正确性准则。包括：

存取控制：根据存取控制表，网络堵截从非授权主机发出的所有流量。

主机学习：控制器最后知道所有主机的位置，网络直接把包送到目的地。

生成树：网络沿着一颗包含所有交换机的树传送广播流量。

这两类性质在传统网络中都很难验证，因为它们需要分布在许多异构装置上的复杂状态进行推理。SDN建基于统一接口，现在已有工具自动验证许多网络性质。

验证配置：验证无循环、连通性需要模型化拓扑和交换配置。这已经有许多工作，问题是SDN的转发行为变化很快，特别是在网络条件变化时，所以，这些验证必须是实时的。

验证控制器：我们还要验证控制程序，特别是基于与拓扑无关的性质。NICE用符号执行和模型检验相结合验证许多重要性质，譬如竞态条件和类似于交换机存储器泄露的bug等。还要测试SDN控制器在交换机层次上是否真正实现了它应有的功能。这时候的网络测试就远远不是光测与协议的相容性了。譬如防火墙、路由算法、控制器的正确性等，需要工具和语言。这里，急需工具，对网络系统行为、性能、可靠性和安全性提供严格的保证。SDN的标准化接口提供了这种可能性，但需要开发SDN控制平台上的顾客逻辑和决策过程，以表达和检验性质、浓缩带有潜伏期和带宽的模型和较好地集成性质检验和测试工具。

   过去10年，全世界都在关注下一代互联网。美国提出了好几个方案，现在看来，SDN最火。中国的CNGI项目已经完结，SCI论文发表得很多，但看不出什么引起广泛关注的方案。泛泛的议论比较多，批评传统网络的也比较多，建设性的方案基本没有。那么，现在我们怎么办？是继续空洞地探索，还是在SDN方案下做比较具体的工作？SDN不是我国原创，当然还有许多原创性的工作可做。但是，现在再另起炉灶，另提方案，似乎不太可能。如果我们现在不参加进来，等SDN的全套硬件和软件都商业化以后再大批进口，建中国的SDN，可能就太晚了，更没有发言权了。