随着互联网和数据中心流量的爆炸式增长，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 所示，最终目标是建立一个水平生态系统，在由商用硅交换芯片构建的裸金属交换机上启用多个网络操作系统，从而实现丰富的网络应用市场[1]。
[1] 术语"bare-metal"起源于服务器，指没有安装操作系统或管理程序的机器。通过类比，该术语适用于没有绑定操作系统或网络应用程序的交换机，交换机的软硬件分离是 SDN 的核心。
图 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 处购买数据平面。尽管这一切并没有立即发生，但解耦的一个自然后果是数据平面组件(即，交换机)成为通用包转发设备(通常称为裸金属交换机)，所有智能都在软件中实现，并在控制平面中运行[2]。这正是发生在计算机行业的事情，微处理器成为了通用商业化产品。第 4 章更详细介绍了裸金属交换机。
[2] 根据我们的统计，今天有超过 15 个开源和专有的解耦控制平面可用。
解耦控制平面和数据平面意味着需要定义良好的转发抽象，也就是说，需要一种通用的方式让控制平面指示数据平面以特定方式转发数据包。请记住，解耦不应该限制交换机供应商如何实现数据平面(例如，其转发表的确切形式或转发数据包的过程)，这种转发抽象不应该假定(或依赖)某个数据平面的实现。
2008 年引入的 OpenFlow 是最早的支持解耦的接口[3]。尽管它在 SDN 发展过程中起到了巨大作用，但被证明只是今天定义 SDN 的一小部分。将 SDN 与 OpenFlow 等同起来明显低估了 SDN 的价值，但它是一个重要的里程碑，因为它引入了流规则(Flow Rules)作为一种简单但强大的方式来指定转发行为。
[3] OpenFlow 实际上并不是第一个这样做的，但它是最吸引人的。早期工作包括 Ipsilon 的 GSMP 和 IETF 的 ForCES。
流规则是一组匹配规则和对应的动作(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 所暗示的解耦将不可行[4]。
[4] 还有一些事件需要在亚毫秒响应时间内关注。在这种情况下，有必要在数据平面中实施补救措施，然后通知控制平面，让它有机会重新编程数据平面。OpenFlow 中的快速故障转移组就是一个例子。
同时，运维人员习惯于自己配置交换机和路由器，在历史上他们一直使用命令行接口(CLI)或(不太常见的)像 SNMP 这样的管理协议来完成。回头看一下图 3，它对应于到 RIB 的北向接口(与 RIB 和 FIB 之间的接口相反)。该接口能够配置新的路由，这在表面上似乎相当于配置新的流规则。如果交换机仅仅暴露了可编程配置界面，而不是传统的 CLI，会被认为是"支持 SDN(SDN-capable)"的吗?
答案可能是否定的，最终需要在通用性和性能上都达到目标。虽然定义良好的可编程配置接口肯定是对传统 CLI 的改进，但目的是修改控制平面的各种设置(如 RIB 条目)和其他设备参数(如端口速率/模式)，而不是修改数据平面的 FIB。因此，这样的配置接口即不太可能支持控制/数据平面接口隐含的全部可编程性，又不太可能支持控制/数据平面解耦所需的实时控制回路。简而言之，SDN 的发展势头的一个副作用是改善了交换机和路由器供应商公开的配置接口(我们将在第 5 章中描述这种接口的最先进技术)，但这样做并不能替代 SDN 所需要的控制粒度。
需要说明的是，交换机中的所有元素都需要配置。数据平面需要配置端口速率等内容，平台需要配置风扇、LED 和其他外围设备，交换机软件需要知道在客户端连接时应该使用什么证书，以及应该设置什么日志级别。控制平面组件也需要配置，例如路由代理需要知道它的 IP 地址、相邻节点，以及是否有静态路由。关键区别在于目的，定量来说是更新速度: 配置意味着每天可能有数千次更新，而控制意味着每秒可能有数千次更新。
