SDN 系统方法 | 1. 概述

随着互联网和数据中心流量的爆炸式增长，SDN 已经逐步取代静态路由交换设备成为构建网络的主流方式，本系列是免费电子书《Software-Defined Networks: A Systems Approach》的中文版，完整介绍了 SDN 的概念、原理、架构和实现方式。原文: Software-Defined Networks: A Systems Approach

序

当我在 1993 年看到第一个 Mosaic 网页浏览器时，全身都起了鸡皮疙瘩，显然有大事即将发生，但当时并不知道有多大。后来互联网迅速大规模爆发，数以千计 ISP(Internet Service Provider, 互联网服务提供商)如雨后春笋般在各地出现，每个都将互联网扩展到新的范围。他们需要做的就是将可互操作的部件(传统网络设备供应商出售的商用交换机、路由器、基站和接入点)连接在一起，而且不需要征求中央控制机构的许可。早期路由器简单而直接，只需要支持 IP 协议。去中心化的控制机制让互联网迅速发展。

路由器制造商面临两难境地: 销售简单直接的设备很难维持繁荣、有利可图的业务。此外，如果由简单设备组成的大型网络易于远程管理，那么所有的智能(和价值)都将由网络运营商提供，而不是路由器制造商。因此，设备商决定只提供最少的外部 API("网络管理"被认为是一个笑话)，路由器被新特性塞满，将所有价值保留在内部。到 2000 年代中期，ISP 使用的路由器非常复杂，支持数百种协议，源代码超过 1 亿行，其复杂性是有史以来最大的电话交换机的十倍以上。互联网为这种复杂性付出了高昂的代价: 路由器臃肿、耗电量大、不可靠、难以保障安全，而且贵得离谱。最糟的是，很难改进(ISP 需要请求设备商增加新功能)，而且 ISP 不可能自己增加新功能。网络所有者抱怨路由器供应商的"钳制"，研究机构警告说互联网已经"僵化"。

本书将介绍接下来发生的事情，这是一个激动人心的故事。Larry, Carmelo, Brian, Thomas 和 Bruce 通过具体的例子和开源代码清楚的展现那些拥有以及运营大型网络的人是如何开始编写自己的代码并构建自己的交换机和路由器的。一些人选择用更简单、更容易维护的自研设备取代路由器，其他人则选择将软件从路由器移到远程集中控制平面。无论选择哪条路，开源成为越来越重要的部分。开源在 Linux、Apache、Mozilla 和 Kubernetes 中已经证明了自己，也就可以被信任用来运行我们的网络。

本书解释了 SDN 运动发生的原因。本质上这是对控制权的争夺，大型网络的所有者和运营商控制了网络的运行方式，从设备商那里夺取了创新的关键。SDN 始于数据中心，由于他们无法使用现成的网络设备构建足够大规模的可扩展网络，因此他们购买交换芯片，自己编写软件。是的，这为他们节省了资金(通常是成本的五倍或更多)，但更重要的是获得了控制权。他们雇佣大量软件工程师，促进了网络新思想的寒武纪大爆发，使网络更可靠，可更快修复，并且更好的控制流量。今天，也就是 2021 年，所有的大型数据中心公司都打造了自己的网络设备，通过修改开源控制软件，或者自己编写、提供软件来控制自己的网络，他们已经掌握了主动权，互联网服务提供商和 5G 运营商将是下一个。预计在十年内，企业和校园网络将运行在开源控制软件上，通过由云进行管理。这是很好的变化，只有那些拥有和运营大规模网络的人才知道如何做到最好。

这种变化被称为软件定义网络(SDN, Software Defined Networking)，是网络构建方式的一场革命，转向由网络运营商自行开发和维护软件。本书作者从一开始就参与了这场革命，非常清楚这场革命是如何以及为什么发生的。

本书也将帮助我们看到未来的网络会是什么样子。网络系统将是一个我们可以编程的平台，而不是由一堆运行标准化互操作性协议的盒子组装起来。网络所有者将通过编写任何希望的行为决定网络如何工作，网络专业的学生将学习如何为分布式系统编程，而不是研究传统协议的神秘细节。

对于那些对编程感兴趣的人来说，网络又重新变得有趣起来，这本书是一个很好的开始。

Nick McKeown

斯坦福大学, 加利福尼亚

前言

互联网正处于转型之中，从捆绑专有设备转变为将网络硬件(变成通用商业硬件)与控制软件(可在云中扩展)分离开来。这种转变通常被称为软件定义网络(SDN)，但由于其对市场的颠覆性，从技术基础和短期工程决策中理清业务定位是一个挑战。本书希望读者需要理解的最重要的事情是，基于 SDN 的网络是运行在商业硬件上的可伸缩分布式系统。

任何上过基础网络课程的人都知道协议栈是描述网络的规范框架，无论协议栈是七层还是只有三层，它塑造和限制了我们思考计算机网络的方式，教材的编排也依此组织。SDN 提出了另一种世界观，一种伴随着新的软件栈的世界观。本书围绕这个新协议栈进行组织，目的是自上而下展示 SDN，不会留下任何读者也许会怀疑只能用神奇的专有代码来填补的重大空白。你可以在本书最后做一些实际的编程练习，以证明其软件栈是真实且完整的。

实现这一目标的重要方面是开放源代码。我们很大程度上是利用了两个社区组织的优势，他们是这方面的领导者。一个是开放计算项目(OCP, Open Compute Project)，它积极指定和认证可以运行 SDN 软件栈的商品硬件(例如，裸金属交换机)。第二个是开放网络基金会(ONF, Open Networking Foundation)，它正在积极构建可以集成到端到端解决方案中的软件组件。这个领域还有许多其他参与者，从设备供应商到网络运营商、初创公司、标准机构和其他开源项目，每个人都对 SDN 是什么和不是什么给出了不同的解释。我们讨论这些不同的视角，并解释它们是如何适应更大的规划的，但我们不会让这些不同点妨碍我们介绍 SDN 本身的全部内容。只有时间才能告诉我们 SDN 旅程将带我们走向何方，但我们相信，了解机会的可能范围非常重要。

本书假定读者对互联网有大致了解，不过对交换机和路由器在转发以太网帧和 IP 包方面所起的作用有更深入的了解会更有帮助。链接到相关的背景信息，以帮助弥合任何差距。

本书是一个演进中的工作，会不断添加更新、澄清和新的材料。例如，最新版本(v2.0)包含了关于网络虚拟化(第 8 章)和接入网络(第 9 章)的新章节。我们渴望听到反馈和建议，以便继续改进本书。

感谢

本书所描述的软件要归功于 ONF 工程团队以及合作开源社区的辛勤工作，感谢他们的贡献，特别感谢 Yi Tseng, Max Pudelko 和 Charles Chan，感谢他们对相关学习教程的贡献，本书将其囊括进来作为实践练习。同时感谢 Charles Chan, Jennifer Rexford, Nick McKeown, Kentaro Ebisawa, Motonori Shindo 和 Sina Ebrahimi 的评论和反馈。

封面图片是东京的 Ueno 地铁站，由Athena Lam发表在Unsplash上。

Larry Peterson, Carmelo Cascone, Brian O’Connor, Thomas Vachuska, and Bruce Davie

2021 年 11 月

第 1 章 概述

软件定义网络(SDN)是关于如何实现网络的一种方法，对创新的速度有很大的影响，因此这一方法非常关键。SDN 并不直接解决路由、拥塞控制、流量工程、安全、移动性、可靠性或实时通信等方面的任何技术挑战，但又确实为创建和部署这些问题的创新解决方案提供了新的机会。本书将讨论 SDN 到底是在业务和技术方面如何实现这一目标。

我们的方法是系统化探索 SDN，也就是说，我们将探索指导实现 SDN 的一系列设计原则(这是一个仍在进行中的发展过程)，而不只是谈论 SDN 的单点解决方案。我们的方法强调概念(将抽象引入网络是 SDN 最初案例的关键部分)，但为了使讨论具体化，我们还借鉴了过去六年来实现开源平台集合的经验，这些平台被用于向生产网络(包括一级网络运营商)交付基于 SDN 的解决方案。

对软件栈的关注是本书的中心主题。由于 SDN 是一种构建网络的方法，因此需要一组软件和硬件工件来将该方法付诸实践。我们使用的开源例子可以在 GitHub 上找到，本书还提供了代码和实际编程练习的链接。

在深入讨论细节之前，先了解一下 SDN 的起源故事很有帮助，SDN 最初是计算机科学研究社区解决互联网僵化问题的一项努力，目标是使网络能够加快创新。这段历史在 Feamster、Rexford 和 Zegura 的一篇文章中有很好的描述。

延伸阅读:

N. Feamster, J. Rexford, and E. Zegura. The Road to SDN: An Intellectual History of Programmable Networks. SIGCOMM CCR, April 2014.

我们给这段历史加上两个脚注。第一个是 2001 年国家科学院的一份报告，该报告将互联网的僵化问题作为主要挑战，从而引起了关注。在这一过程中，这份报告促成了一项长达 20 年的研发工作。这项研究的成果现在正直接影响着云提供商、企业和互联网服务提供商部署的网络。

延伸阅读:

Looking Over the Fence at Networks: A Neighbor’s View of Networking Research. The National Academies Press, 2001.

第二个是 Scott Shenker 对 SDN 智能化场景所作的标志性演讲。理解 Shenker 演讲的中心论点: 构建和运营网络的实践迫切需要抽象来帮助管理复杂性，是理解本书中描述的系统、平台、工具和接口的关键。

延伸阅读:

S. Shenker. The Future of Networking and the Past of Protocols. Open Networking Summit, October 2011.

1.1 市场前景(Market Landscape)

要充分认识 SDN 的作用和最终影响，首先要看市场格局。SDN 在某种程度上被认为是一种改变市场的方式，其灵感来自于计算机行业在过去几十年所经历的转变。

计算机行业在历史上是一个垂直市场(vertical market)，这意味着，想要解决某些问题(例如，财务、设计、分析)的客户需要从单一供应商(通常是像 IBM 这样的大型主机公司)购买垂直集成的解决方案，包括从底层硬件(包括处理器芯片)到运行在硬件上的操作系统，再到应用程序本身的所有内容。

图 1. 将垂直主机市场转变为水平市场，在每个层级上都有开放接口和多种选择。

如图 1 所示，微处理器(如 Intel x86 和 Motorola 68000)和开源操作系统(如 BSD Unix 和 Linux)的引入，帮助将垂直市场转变为水平市场，开放接口刺激了各个层面的创新。

当 SDN 被视为变革性倡议时，是在网络产业中刺激同样变革的尝试，正如 2001 年国家科学院的报告所观察到的，网络已经僵化了。如图 2 所示，最终目标是建立一个水平生态系统，在由商用硅交换芯片构建的裸金属交换机上启用多个网络操作系统，从而实现丰富的网络应用市场。

图 2. 垂直路由器市场向水平市场转变，每个层级都有开放接口和多种选择。

这种转变的价值显而易见，打开垂直整合、封闭、专有的市场，可以为创新创造机会。或者换句话说，通过开放接口，有可能将控制权从销售网络设备的供应商转移到建设网络以满足用户需求的网络运营商。

为了更深入理解这一机会，我们需要深入了解技术细节(将在下一节介绍)，但认识到 SDN 作为改变网络行业的方式的背景故事是重要的起点。

1.2 技术前景(Technical Landscape)

要理解 SDN 是一种系统方法而不是单点解决方案，这样有助于为方法的核心定义设计原则。构建设计空间是这部分的目标，但重要的是，最终状态不止一种。每个网络运营商可以自由选择不同的设计点，并相应构建自己的网络。

也就是说，本书着重描述 SDN 原则的最完整应用，有时也被称为纯粹 SDN(pure play SDN)。考虑到 SDN 的全部意义在于颠覆现有垂直市场，因此，现有供应商将提供与他们的既定商业模式相一致并且易于采用的混合解决方案。我们有时称这些混合解决方案为 SDN-lite，它们利用了 SDN 的某些方面，但不是全部。除了指出这些部分解决方案的存在之外，我们不打算以百科全书式的方式来介绍它们。我们的目标是描绘 SDN 的全部潜力，并以当今最先进的技术所允许的尽可能多的深度来做到这一点。

1.2.1 分离控制平面和数据平面

SDN 背后的重要思想是，网络有不同的控制平面和数据平面，这两个平面的分离应该被编码在开放接口中。用最基本的术语来说，控制平面决定网络的行为，而数据平面负责在单个数据包上实现该行为。例如，控制平面的一个工作是确定数据包通过网络应该遵循的路由规则(也许通过运行 BGP、OSPF、RIP 这样的路由协议实现)，数据平面的工作是根据路由规则转发数据包，对于每个包，交换机逐跳做出转发决策。

实践中，分离控制面和数据面表现为并行但不同的数据结构: 控制面维护包含所有辅助信息的路由表，在给定时间选择最好的路由(例如考虑可选路径，各自成本，以及任何策略约束)，数据面维护转发表优化快速数据包处理(例如决定任何到达端口 i 的目的地址为 D 的数据包都应该通过端口 j 转发，新目的地址为 D')。路由表通常被称为路由信息库(RIB, Routing Information Base)，转发表通常被称为转发信息库(FIB, Forwarding Information Base)，如图 3 所示。

图 3. 控制面(及其对应的 RIB)与数据面(及其对应的 FIB)解耦。

解耦网络控制平面和数据平面的价值没有争议，这是网络中的成熟实践，在 SDN 之前，封闭/专有路由器就采用了这种级别的模块化。但是 SDN 的第一个原则是控制平面和数据平面之间的接口应该是定义良好且开放的，这种强大的模块化通常被称为解耦，它使每个平面由不同的参与方负责成为可能。

原则上，解耦意味着网络运营商应该能够从供应商 X 处购买控制平面，从供应商 Y 处购买数据平面。尽管这一切并没有立即发生，但解耦的一个自然后果是数据平面组件(即，交换机)成为通用包转发设备(通常称为裸金属交换机)，所有智能都在软件中实现，并在控制平面中运行。这正是发生在计算机行业的事情，微处理器成为了通用商业化产品。第 4 章更详细介绍了裸金属交换机。

解耦控制平面和数据平面意味着需要定义良好的转发抽象，也就是说，需要一种通用的方式让控制平面指示数据平面以特定方式转发数据包。请记住，解耦不应该限制交换机供应商如何实现数据平面(例如，其转发表的确切形式或转发数据包的过程)，这种转发抽象不应该假定(或依赖)某个数据平面的实现。

2008 年引入的OpenFlow是最早的支持解耦的接口。尽管它在 SDN 发展过程中起到了巨大作用，但被证明只是今天定义 SDN 的一小部分。将 SDN 与 OpenFlow 等同起来明显低估了 SDN 的价值，但它是一个重要的里程碑，因为它引入了流规则(Flow Rules)作为一种简单但强大的方式来指定转发行为。

流规则是一组匹配规则和对应的动作(Match-Action pair)，任何和规则匹配的数据包都应该执行相应的动作。例如，一个简单的流规则可能指定任何目的地址为 D 的数据包在输出端口 i 上转发。原始的 OpenFlow 规范允许图 4 中所示的报头字段包含在规则的 Match 部分中。例如，一个 Match 可能指定数据包的 MAC 报头Type字段等于0x800(表示帧携带 IP 数据包)，它的 IP 报头DstAddr字段包含某些子网(例如192.12.69/24)。

图 4. 原生 OpenFlow 规范匹配报文字段。

原生动作包括"将数据包转发到一个或多个端口"以及"丢弃包"，或者"将数据包发送到控制面"，从而将任何需要控制面进一步处理的数据包发送给控制器(controller)(该术语代表在控制面中负责控制交换机的进程)。随着时间的推移，支持的操作集变得更加复杂，稍后将继续介绍。

基于流规则抽象，每个交换机维护一个流表来保存控制器传给它的流规则集。实际上，流表是本节开始介绍的转发表的 OpenFlow 抽象。OpenFlow 还定义了一个安全协议，通过该协议，可以在控制器和交换机之间传递流规则，从而可以在交换机之外运行控制器，如图 5 所示。

图 5. 控制器将流规则安全的传递给启用了 OpenFlow 的交换机，交换机维护流表。

随着时间的推移，OpenFlow 规范变得越来越复杂(当然，其定义比之前介绍的精确得多)，但最初的想法很简单。在当时(2008 年)，在传统的转发路径之外，建立一个包含“OpenFlow 选项”的交换机的想法非常激进，是通过研究项目提出的。事实上，最初的 OpenFlow 出版物是作为对研究界的行动呼吁而撰写的。

延伸阅读:

N. McKeown, et. al. OpenFlow: Enabling Innovation in Campus Networks. SIGCOMM CCR, March 2008.

今天，OpenFlow 规范已经经历多次修订，并且正在用更灵活(即可编程)的替代方案来取代。我们将在第四章继续探讨 OpenFlow 和 P4(另一种编程语言)。

在本节最后，我们提醒注意两个相关但截然不同的概念: 控制(Control) 和 配置(Configuration) 。OpenFlow(以及一般的 SDN)的思想是定义控制数据平面的接口，这意味着需要对链路和交换机故障以及其他数据平面事件做出实时决策。如果数据面报告了故障，控制面通常需要在毫秒内了解这个故障并提供补救(例如，下发新的 Match/Action 流规则)，否则 SDN 所暗示的解耦将不可行。

同时，运维人员习惯于自己配置交换机和路由器，在历史上他们一直使用命令行接口(CLI)或(不太常见的)像 SNMP 这样的管理协议来完成。回头看一下图 3，它对应于到 RIB 的北向接口(与 RIB 和 FIB 之间的接口相反)。该接口能够配置新的路由，这在表面上似乎相当于配置新的流规则。如果交换机仅仅暴露了可编程配置界面，而不是传统的 CLI，会被认为是"支持 SDN(SDN-capable)"的吗?

答案可能是否定的，最终需要在通用性和性能上都达到目标。虽然定义良好的可编程配置接口肯定是对传统 CLI 的改进，但目的是修改控制平面的各种设置(如 RIB 条目)和其他设备参数(如端口速率/模式)，而不是修改数据平面的 FIB。因此，这样的配置接口即不太可能支持控制/数据平面接口隐含的全部可编程性，又不太可能支持控制/数据平面解耦所需的实时控制回路。简而言之，SDN 的发展势头的一个副作用是改善了交换机和路由器供应商公开的配置接口(我们将在第 5 章中描述这种接口的最先进技术)，但这样做并不能替代 SDN 所需要的控制粒度。

需要说明的是，交换机中的所有元素都需要配置。数据平面需要配置端口速率等内容，平台需要配置风扇、LED 和其他外围设备，交换机软件需要知道在客户端连接时应该使用什么证书，以及应该设置什么日志级别。控制平面组件也需要配置，例如路由代理需要知道它的 IP 地址、相邻节点，以及是否有静态路由。关键区别在于目的，定量来说是更新速度: 配置意味着每天可能有数千次更新，而控制意味着每秒可能有数千次更新。

1.2.2 控制平面: 中心化 vs 分布式

在解耦控制平面和数据平面之后，接下来要考虑的是如何实现控制平面。一种选择是在交换机上运行实现控制面的软件。这样做意味着每个交换机都作为自治设备运行，与整个网络中的对等交换机通信，以构建本地路由表。为了方便起见，已经存在一组可用于此目的的协议: BGP、OSPF、RIP 等。这正是过去 30 多年来互联网一直采用的分布式控制平面。

这种场景自有其价值。由于解耦带来了使用商用硅交换芯片构建低成本裸金属交换机的可能性，网络运营商可以从裸金属交换机供应商购买硬件，然后从其他供应商购买适当的控制平面软件，甚至可能使用这些软件的开源版本。这样做可能会降低成本和复杂性(因为只需要将所需的控制模块加载到设备上)，但不一定能实现 SDN 所承诺的创新速度。因为运营商仍然停留在缓慢的标准化过程中，这是今天的标准化协议所暗示的，也没能实现 SDN 先驱们所设想的新的网络抽象(例如 Shenker 在上面的演讲中提到的)。

另一种选择是控制平面完全独立于数据平面，并在逻辑上集中管理，这是 SDN 的第二个设计原则。这意味着控制平面是部署在交换机之外的，例如可以在云上运行控制器。为了完整起见，我们注意到也可以采用混合方法，在云托管的控制器中，一些控制功能运行在交换机上，一些运行在交换机之外。

我们说逻辑集中是因为收集状态的控制器需要维护全局数据结构(相对于在每个交换机上维护路由表)，这个数据结构的实现仍然可以分布在多个服务器上，通过云的最佳实践，实现服务的水平扩展，这对于可伸缩性和可用性都很重要，其中关键是这两个平面是独立配置和扩展的。如果需要增加数据平面容量，可以增加裸金属交换机。如果控制平面需要更多容量，可以添加计算服务器(或者更可能的是虚拟机)。

图 6. 网络操作系统(NOS)托管一组控制应用程序，并为底层网络数据平面提供逻辑上集中的控制点。

图 6 描述了与分布式数据平面相关联的集中式控制平面，但是更进一步，还引入了这种方法所隐含的关键组件: 网络操作系统(Network Operating System, NOS)。服务器操作系统(如 Linux, iOS、Android、Windows)提供了一组高级抽象，可以更容易实现应用程序(例如,用户可以读取和写入文件，而不是直接访问磁盘驱动器)，NOS 与此类似，可以更容易实现网络控制功能，也称为控制应用程序(Control Apps)。

NOS 背后的思想是抽象交换机细节，并向应用开发人员提供网络分布(Network Map) 抽象。NOS 检测底层网络变化(例如，交换机、端口和连接的可用状态)，而控制应用只是在这个抽象上实现想要的行为。这意味着 NOS 承担了收集网络状态的负担(分布式算法中最困难的部分，例如链路状态和距离向量路由协议等)，而应用可以免费使用相关抽象，并在图上运行简单的最短路径算法，并将构建的流规则加载到底层交换机。下面是关于链路状态(Link-State)和距离矢量路由算法(Distance-Vector routing algorithms)的在线介绍。

延伸阅读:Routing. Computer Networks: A Systems Approach, 2020.

通过集中化相关逻辑，可以实现以前在分布式网络中不可能实现的事情: 计算全局优化解决方案。正如在后面章节中讨论的那样，已经公布的来自云供应商的证据证实了这种优势。多年来大家都很清楚，互联网完全分布式的方法并不适合全局优化，但直到 SDN，还没有真正可行的替代方案。SDN 使这种可能性成为现实，这就是提供集中式网络抽象的力量。

"收集网络状态"的想法是 SDN 和 NOS 所扮演角色的核心。我们不讨论收集网络遥测数据的所有使用方式，例如解决配置错误或做长期规划，但我们会谈论可能需要控制平面立即做出反应的精确控制，一个明显的例子是每个端口上发送和接收的字节/数据包的数量。像 OpenFlow 这样的协议定义了向 NOS 报告此类统计报告的方法，此外还为 NOS 提供了基于其收集的信息配置新流规则的方法。

中心化控制平面还有一个相关好处，随着我们讨论 SDN 用例，这个好处将变得更加清晰。逻辑集中的控制平面提供了单一的网络公开 API。将可编程 API 放在单个交换机和路由器上的想法已经出现了几十年，但没有产生多大影响，相比之下，对于整个交换机或路由器集合的中心 API 可以支持各种各样新用例。其中包括网络虚拟化、网络自动化和网络验证。以自动化为例，将 BGP 配置这样的事情自动化是相当困难的，因为很难推断当一组 BGP 节点开始彼此交互时如何回应。但是，如果中央控制平面公开了 API，可以通过 API 实现"创建一个连接以下端点集的隔离网络"，那么将该请求作为自动化配置系统的一部分就相当合理了。这正是许多现代云中的情况，其中网络资源和策略的供应可以与所有其他类型的操作(如绑定虚拟机或容器)一起自动化。

回到集中式控制平面与分布式控制平面的最初问题，后者的支持者往往基于互联网首先采用分布式路由协议的历史原因: 规模化和容错。需要注意的是，任何集中式解决方案都会导致瓶颈，也就是单点故障。在服务器集群上分布式部署集中化控制平面可以缓解这两个问题，因为基于分布式系统开发的技术可以确保此类集群的高可用性和可伸缩性。

关于控制平面集中化的第二个问题是，由于控制平面是远程的(即在交换机之外)，两个平面之间的链接增加了脆弱的攻击面。相反的观点是，非 SDN 网络已经有(并依赖)带外管理网络，所以这种攻击面由来已久。控制器可以使用这些管理网络，就像其他管理软件一样。还有一种观点认为，少量的集中式控制器比大量的分布式控制器所呈现的攻击面更小。可以这么说，虽然意见不同，但肯定有很多人支持中心化方法。

控制域(Domain of Control)

本节的"集中式 vs 分布式"框架旨在描述 SDN 设计空间的一个维度，而不是表明网络运营商面临非此即彼的情况。有许多因素会影响给定运营商在这个问题上的决定，但首先要确定 SDN 应用的域的范围。我们将在第 2 章中讨论示例用例，但是网络的自然发展突出了这个思考过程。

从历史上看，每个交换机都有一个控制平面实例，它们在同一个机器上运行。当简单的路由器发展为机架式路由器时，M 个线卡通常对应有 N 个控制平面实例，在独立的硬件上运行，并通过管理网络相互通信。随着机架式路由器从普通交换机发展为多机架结构，SDN 提出了一种设计，将转发元素集中在一个可以运行在任何地方的控制平面下，并构建一个分布式系统。这样一个系统的优势在于可以使用现代技术来进行状态分发和管理，而不用受制于标准，关键是找到能够有可能使用集中式逻辑控制平面优化性能的域。本书介绍了 SDN 可以提供提供价值的几个这样的领域。

1.2.3 数据平面: 可编程与固定功能

设计空间的最后一个维度是考虑数据平面交换机是可编程的还是固定功能的，我们需要多说一点交换机的实现，从而理解这意味着什么。

前面我们用一个简单模型讨论交换机，交换机的主要处理逻辑是从输入端口接收数据包，查找目的地址的 FIB(或者使用 OpenFlow 的术语流表)，然后根据匹配的表项将数据包输出到端口或端口组，这是低端交换机的合理实现策略(通用处理器上可以通过软件实现这一主处理循环)，但高性能交换机采用基于硬件的转发流水线。

我们将在第 4 章深入介绍处理流水线，但目前重要的特征是，该流水线是否仅限于匹配数据包报头中的固定字段集(例如图 4 所示字段)，并执行固定的操作，或者是否将匹配的位模式和要执行的动作动态编程到交换机中。前者被称为固定功能流水线(fixed-function pipelines)，后者被称为可编程流水线(programmable pipelines)。但首先我们必须回答这个问题: "转发流水线到底是什么?"

一种方式是考虑转发流水线而不是单个流表，就像前一节介绍的那样，交换机实际上实现了一系列流表，每个表项关注一个头字段的子集，也许跟某一个流规则相关联(例如，一个表项匹配 MAC 头，一个匹配 IP 报头，等等)，给定数据包被多个流表按顺序处理，这就是流水线，并最终决定如何转发。图 7 基于 OpenFlow 规范给出了这种流表流水线的一般示意图。其思想是，在数据包流经流水线时收集一组操作，并在最后阶段作执行。

图 7. OpenFlow 转发流水线简单示意图。

乍一看似乎并不重要，因为如图 4 所示的头字段都是众所周知的，交换机很容易对每个包计算偏移量(例如，表 0 匹配 MAC 头字段，表 1 尝试匹配 IP 字段，等等)。在这一点上，SDN 的最初想法是有意不涉及数据平面，并完全专注于可编程开放控制平面，但早期实施 SDN 控制器的经验暴露出两个问题。

第一个问题是，随着 SDN 从研究实验阶段逐渐成熟，成为传统专有交换机的可行替代品，性能变得越来越重要。虽然流规则足以说明控制器想要编程到交换机中的转发行为，但交换机不一定有能力以有效方式实现该功能。为了确保高转发性能，流表使用高度优化的数据结构来实现，这些数据结构需要专门的内存，比如三元内容寻址内存(TCAM, Ternary Content Addressable Memory)。结果是只支持有限数量的条目，这意味着控制器必须谨慎使用。

简而言之，控制器必须知道流水线的详细信息，以便配置一组交换机可以映射到硬件的流规则。因此，许多控制应用程序隐式的绑定到特定的转发流水线。这类似于编写只能在 x86 处理器上运行的 Java 或 Python 程序，并且不容易移植到 ARM 处理器上。事实证明，对转发流水线有更多的控制是必要的，因为我们不想将自己限制在单个供应商的流水线上，还需要抽象方法来指定流水线的行为，从而可以映射到任何给定交换机的物理流水线上。

第二个问题是协议栈以意想不到的方式发生了变化，这意味着可能需要匹配的所有报头字段都是公开的这一假设是有缺陷的。例如，虽然 OpenFlow(以及早期的转发流水线)正确的包含了对 VLAN 标记的支持，这是在企业网络中创建虚拟网络的基础，但 4096 个可能的 VLAN 不足以支撑云可能承载的所有租户。

为了解决这个问题，IETF 引入了一种新的封装，称为虚拟可扩展 LAN(VXLAN, Virtual Extensible LAN)。与之前的方法(将虚拟以太网帧封装在另一个以太网帧中)不同，VXLAN 将虚拟以太网帧封装在 UDP 包中。图 8 显示了 VXLAN 报头，以及交换机为了做出转发决定可能必须处理的所有包报头。

图 8. VXLAN 报头封装在 UDP/IP 报文中。

向 OpenFlow 添加对 VXLAN 的支持已经足够困难了，因为标准的批准需要时间，但是向固定功能的转发流水线添加对 VXLAN 的支持则是更为耗时: 需要改变硬件！ 有人可能会说，有了 VXLAN，我们现在就完成了协议栈的变更，但这是不可能的。例如，当与 HTTP 一起使用时，QUIC 正逐渐成为 TCP 的替代方案。另一个即将出现的例子是 MPLS vs SRv6。甚至 VXLAN 在某些情况下也被一种称为 GENEVE 的更灵活的新封装所取代。

可编程转发流水线，加上可用于对流水线进行编程的高级语言，是对这两个问题的一个可行应对。这两者都是在最近几年出现的，以协议独立交换体系架构(PISA, Protocol Independent Switching Architecture) 和 P4 编程语言的形式出现。我们将在第 4 章中更详细讨论这两个问题，但目前最大的收获是，SDN 已经超越了其作为控制平面编程手段的最初目标。今天，SDN 还囊括了可编程数据平面的可能性。

1.3 SDN: 定义

综上所述，SDN 的初始定义很简单:

控制平面和转发平面在物理上相互隔离，一个控制平面可以控制多台转发设备的网络。

-- 来自 Nick McKeown 2013 年题为"软件定义网络"的演讲。

这是第 1.2.1 节和第 1.2.2 节大段内容的简洁表述。从最初的定义开始，SDN 就被不同的利益相关方解释为更少(例如，对网络设备的可编程配置接口被称为 SDN)和更多(例如，SDN 还包括具有可编程转发流水线的交换机)，本书以更广阔的视角涵盖了整个领域。

另一种定义 SDN 的方法是把它看作两个阶段。阶段 1 中，网络运营商获得了控制平面的所有权，现在在阶段 2 中，他们正在控制如何在数据平面中处理数据包。第二阶段仍处于开发阶段，但正如 Nick McKeown 所假设的那样，理想的最终状态是:

"网络(理想情况下)将更多的被编程，更少的被运维操作。"

也就是说，SDN 不仅仅是将控制权从设备商转移到运营商，最终，它是将控制权从设备商转移到运营商，再转移到用户。这是一个长期目标，其灵感来自于商用服务器和开源软件对计算机行业的贡献。但是我们仍然有很长的路要走，所以我们在第 10 章中对 SDN 旅程的下一阶段进行了适度的预测。

延伸阅读:

N. McKeown. FutureNet 2019. October 2019.

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。

微信公众号：DeepNoMind