软件定义网络
为什么需要软件定义网络？
之前，我们了解了路由协议如何适应数据中心环境（例如等成本多路径）。但如果我们想根据特定网络的约束和用例进一步优化路由协议呢？标准路由协议可能就不再适用了。
在本节中，我们将探讨软件定义网络，这是一种全新的路由和网络管理范式。在路由领域，SDN 架构包括一个集中式控制中心来计算路由，并将其分发给各个路由器。我们将了解 SDN 在数据中心和广域网中的工作方式，并讨论这种新方法的优缺点。
软件定义网络的简史
尽管我们将 SDN 视为专门路由协议的新方法，但 SDN 范式最初是为了解决管理平面的难题而设计的。
回想一下，管理平面对网络运行至关重要。路由器必须经过配置（例如为链路分配成本）并被告知要做什么（例如运行哪种路由协议）才能正常工作。此外，我们需要路由器报告错误以保持网络正常运行。历史上，许多管理工作都是手动完成的。
尽管管理平面如此重要，但对其进行创新的关注相对较少。在控制平面，我们已经看到了许多不同的路由协议，但配置和控制路由器的方式发展较为缓慢。
在互联网的发展历程中，人们逐渐开始使用脚本来以编程方式与网络交互。这些脚本将操作员手动执行的工作通过代码实现（缺乏太多智能）。例如，脚本可以自动执行向网络添加路由器和链路的过程。一个修复网络的脚本可能会这样规定：如果路由器发生故障，检查它是否真的故障，重启它，如果仍然无法修复，则向操作员报告。
尽管取得了这些进展，但长期以来，这些管理系统一直是网络运营的瓶颈。每次添加新路由器时，我们可能仍然需要等待人工干预。
2005 年，Albert Greenberg 等人的一篇论文描述了这个问题：“如今的数据网络出奇地脆弱且难以管理。我们认为，这些问题的根源在于控制平面和管理平面的复杂性。”
为了解决这些问题，研究人员开始思考运行网络系统的不同方法。这引发了更激进的提议，重新构想了路由器的基本设计。
我们将要看到的概念最早在 2003 年被提出，但当时并未获得太多关注。对网络管理的不满加速了新管理范式的发展。到 2008 年，这一领域获得了更多动力，进而催生了 OpenFlow 交换机接口（我们很快就会了解）。
到 2011 年，很明显行业正朝着这个新方向发展，开放网络基金会（ONF）由主要网络运营商（谷歌、雅虎、威瑞森、微软、Facebook）和供应商（思科、瞻博网络、惠普、戴尔）成立。Nicira 是一家专注于 SDN 的初创公司，开发了 OpenFlow 接口，在 2012 年时估值为 4000 万美元。
路由器是垂直集成且标准化的
如果我们想重新构想路由器的设计，在实践中该如何实现呢？路由器上的技术是如何随时间变化的？
如果你的网络需要路由器，你可能会从思科或瞻博网络等主要设备供应商处购买。为了确保不同路由器之间的兼容性，所有主要设备供应商都按照一些预定义的标准来制造路由器。
这种商业模式会使创新和尝试新方法变得困难。假设你有一个关于路由协议的新想法。你需要让这个协议获得标准组织的批准，这可能需要数年时间。然后，你还得等待供应商升级生产以符合新标准。
标准化也降低了用户实施自定义解决方案时路由器的灵活性。如果你的网络存在一个特定问题，而其他网络没有，那么你的解决方案可能不会被标准组织采用。供应商希望制造能满足所有人需求的路由器，如果其他人不需要某个解决方案，他们不一定会为你实现一个完美的解决方案。
另一方面，标准化也意味着，如果其他人存在你没有的问题，路由器可能会自带解决他们问题的方案，即使你并不需要。这可能会使路由器对于你特定的网络用途来说变得不必要地复杂。
标准化还使实验和研究变得困难。如果你想尝试一个新想法看看是否可行，你可能无法买到能够实现这个新想法的路由器。供应商不想制造针对特定客户的实验性产品，这些产品甚至可能无法正常工作。
创新和实验的另一个主要障碍是路由器的垂直集成。你购买的路由器已经将三个平面的功能集成在芯片上。没有模块化设计可以让你单独更换控制平面。
路由器的创新方向
如果我们确实想对路由器进行创新，在每个平面可以创新什么，以及我们会涉及哪些已有的标准呢？
数据平面由 IEEE（电气工程组织）标准化，要求所有人严格遵循标准。如果不同供应商的两个路由器相连，我们必须确保双方以相同一致的格式在物理线路上发送比特。
数据平面的创新通常是由对更高带宽路由器的需求驱动的，新功能并不常被引入。这种发展相当缓慢，以 2-3 年为一个周期，因为我们必须解决物理硬件问题并设计用于提高带宽的芯片。由于核心数据平面功能相对稳定，路由器创新并不真正聚焦于数据平面，所以其发展周期慢一些也没关系。
控制平面由 IETF（RFC 背后的网络组织）标准化。供应商有时会添加自己的扩展，但核心功能大多是标准化的。例如，我们假设每个路由器（即使来自不同厂商）都遵循相同的路由协议。
控制平面的创新（例如新的路由协议）可能需要数年时间才能被采用。你可能需要提交一份 RFC 草案提案，社区可能会花一些时间讨论该提案后才会达成一致。
管理平面也由 IETF 标准化，但标准化程度低得多。不同的运营商可以使用不同的软件来配置他们的路由器，我们并不需要不同的供应商就某些标准化软件达成一致。由于这个平面只是松散标准化的，因此存在许多具有不同功能的不同方法。
总结一下：数据平面是标准化的（但我们并没有太多新功能的想法），控制平面是标准化的（但我们想尝试新的解决方案），而管理平面则没有真正标准化。
激进想法：拆分路由器
标准化和垂直集成使得创新和实验变得困难。这引发了一个激进的想法：通过将平面拆分为不同的抽象层来拆分路由器。不再购买包含所有三个平面的单个路由器，我们现在可以分别购买数据平面和控制平面功能。这使我们能够独立地更改各个层。
为了连接这三个层，我们需要抽象层之间的 API。在垂直耦合的路由器中，我们并不关心数据平面和控制平面如何通信。但是，如果我们单独购买数据平面，并且想在其上设计自己的自定义控制平面，我们就需要一个与数据平面交互的接口。
一个更激进的想法是，不再仅从路由器的角度考虑这三个平面，而是设计一种新的系统架构，自然地分离数据平面和控制平面。
在底层，我们有通用网络设备。你可以将其视为仅购买数据平面。这些路由器通过网络操作系统接收控制程序的指令，并简单地根据这些指令转发数据包。这些路由器根本不需要考虑路由协议，因此可以更便宜。
在中间层，我们有网络操作系统。你可以将其视为连接数据平面路由器和控制平面程序的 API。网络操作系统提供路由器的抽象（例如作为图形），可以传递给控制程序。然后，控制程序可以向网络操作系统发送路由指令，而无需担心如何对特定路由器进行编程。网络操作系统可以接收这些指令并将其编程到各个路由器上。
在顶层，我们有控制程序。你可以将其视为单独购买或实现控制平面。在这里，操作员从网络操作系统接收网络的抽象（例如图形），并可以使用它来编写自己的自定义路由协议。然后，生成的路由可以传递给网络操作系统，网络操作系统将把它们编程到路由器上。
OpenFlow API 格式
OpenFlow是用于与路由器数据平面交互的 API。操作员编写自己的复杂代码（与路由器分离）来计算网络中的路由。然后，这些路由可以被编程到转发芯片上。
OpenFlow 范式与传统路由器不同，在传统路由器中，控制平面在路由器中实现，并且没有明确的 API 用于将自定义路由编程到转发芯片上。
OpenFlow API 定义了一个流表抽象来描述路由和转发规则。操作员代码可以输出任何想要的规则和路由，并将它们安装在路由器上，只要它们符合流表格式。
该 API 的基本构建块是流表，你可以将其视为转发表的通用版本。每个流表由键值对组成，就像转发表一样。键指定要与数据包匹配的内容。这可以是目的前缀、确切目的地、五元组或其他相对简单的匹配项。相应的值指定当数据包匹配时要设置的动作。该动作可以是将数据包发送到下一跳（如转发表），但也可以指定更复杂的动作，如添加额外的头部。
输出格式是一个或多个编号流表的序列，每个表都有自己不同的匹配 - 动作条目。这些流表随后可以被编程到转发芯片上。
当数据包到达路由器时，会按顺序检查每个表（例如表 0、表 1、表 2 等），当有匹配时，我们会记下相应的动作（但尚未执行）。最终，当数据包检查完最后一个表后，我们记下的任何动作都将应用于该数据包。
还有用于跳转到后面表的特殊动作，我们可以在规则中使用，例如：如果源端口与这个数字匹配，则跳转到表 5 以设置额外动作。
操作员可以运行任何代码来生成流表，而且流表可以比目的地 / 下一跳转发表更通用。然而，我们生成的规则（匹配 / 动作对）仍然受到专用转发芯片硬件的限制。转发芯片针对速度进行了优化，可能无法处理复杂的匹配规则，例如 “如果 TCP 有效载荷是英文的，则设置此动作”。
因此，实际上我们看到的流表最终看起来与我们已经见过的表非常相似。常见的匹配规则包括对 IP 目的地的最长前缀匹配、用于识别流的五元组以及对封装头部（例如 MPLS）的精确匹配。
如果转发规则没有太大不同，那么为什么还要使用 OpenFlow 呢？请记住，主要优势是它给了操作员在控制平面的完全自由。我们不再局限于距离矢量或链路状态协议。
灵活控制平面的优势
我们的新架构使操作员能够灵活地在控制平面实现新的路由协议。这种方法有哪些优势呢？
操作员可以实现最适合其特定需求的自定义路由协议。操作员不再受标准组织和供应商的限制。
灵活性也给了我们简化的机会。例如，如果标准化协议包含我们不需要的功能，我们不必在自定义解决方案中实现它们。更简单的协议可以有更少的代码和更简单的代码，这可能使该协议的开发和维护更容易。
最后，灵活的控制平面支持在控制程序中集中计算路由，而不是在多个路由器之间分布式计算。集中化也带来了几个好处。
集中化可以做出更智能的路由决策，从而带来出色的性能。在谷歌 2013 年的一份报告中，部署了 SDN 架构的工程师指出，“集中式流量工程服务使链路利用率接近 100%，同时在多条路径之间拆分应用流，以根据应用优先级 / 需求平衡容量。” 微软 2013 年的一篇论文描述了使用 OpenFlow 控制器 “通过软件驱动的广域网实现高利用率”。
更智能的路由决策有助于优化标准路由协议难以优化的其他标准，而不仅仅是性能。例如，美国政府网络可能会实施地理围栏规则，规定不通过加拿大的链路发送流量。或者，广播电视网络可能希望优化路径多样性以提高可靠性。我们可以确保两个流通过不共享任何链路的路径传输，这样如果一条链路出现故障，只有一个流会受到影响。这两条路径可以相互作为备份。
集中化还可以使路由协议更容易收敛。在分布式协议中，如果网络发生变化，路由器必须进行协调以收敛到新的路由状态。在这种集中式模型中，如果一条链路发生故障，该路由器可以告知控制中心，控制中心可以重新计算路由并在路由器上安装新路由。
流量工程
灵活的控制平面使我们能够执行流量工程，这意味着我们可以以比标准分布式路由协议更智能、更高效的方式路由流量。
假设有两个连接，S1-D 为 10 Gbps，S2-D 为 10 Gbps。如果我们只运行标准的最小成本路由，两个流都会沿着底部路径发送流量。底部路径会出现拥塞（10 Gbps 链路上有 20 Gbps 流量），而顶部路径的带宽则处于闲置状态。
通过更智能的路由方案，我们可以将 S1-D 流量沿顶部路径发送，将 S2-D 流量沿底部路径发送。通过流量工程，我们迫使一些数据包走更长的路由，以更好地利用网络中的带宽。
为了计算这些路由，我们可以修改最小成本路由，转而强制流量走具有足够容量的最短路径。我们还可以强制执行除容量之外的其他约束，例如延迟。由此产生的算法称为约束最短路径优先（cSPF）。
现在，假设 S1-D 需要 12 Gbps，S2-D 需要 8 Gbps。cSPF 会将流沿不同路径发送以最大化带宽，但 S1-D 会通过 10 Gbps 链路发送 12 Gbps 的流量。
为了解决这个问题，我们的流量工程可以更智能，将一个流的流量分配到不同的路径上。S1-D 可以沿顶部路径发送 10 Gbps 的流量，其余 2 Gbps 沿底部路径发送。
同样，我们的流量工程允许我们实施自定义逻辑，从而更好地利用网络容量。
使用前面的 OpenFlow API，我们实际上如何实现网络中的路径拆分呢？请记住，我们的路由决策仍然应该遵循转发表可以理解的简单规则。
一种方法是使用封装。在发送方，我们可以添加规则来添加一个额外的头部，其中一些数据包获得标签 0，其余的获得标签 1。这个标签告诉我们沿哪条路径发送流量。
现在，在 R1，我们可以添加简单规则，将标签 0 的数据包向上路由到 R2，将标签 1 的数据包向下路由到 R3。这个想法可以附加到我们为约束最小成本路由制定的其他规则上（例如，流表可能有其他条目用于其他目的地或其他流）。
集中式流量工程和全局最优决策
SDN 模型中自定义路由协议的一个主要区别是集中化。在原始模型中，每个路由器都运行自己的路由协议。现在，我们可以有一台位于路由器外部的计算机计算所有路由，然后使用流表 API 将这些路由安装在路由器上。
集中化使我们能够做出全局最优决策。在分布式协议中，每个路由器都在为自己做出最佳决策，但这可能不是对其他路由器的最佳决策。在集中式模型中，控制中心可以利用其对网络的全局视图来决定对所有人都最佳的方案，并告诉路由器遵循该决策。
考虑这个有两个流的网络，S1-D 为 20 Gbps，S2-D 为 100 Gbps。假设我们还没有实现将一个流拆分到多条路径的支持。
假设 20 Gbps 的 S1-D 流首先启动。使用约束最短路径优先，S1 可以选择使用底部路径。从 S1 的角度来看，这是一个局部最优决策（顶部和底部路径同样好）。
后来，100 Gbps 的 S2-D 流启动。现在，使用约束最短路径优先，S2-D 没有任何单条路径能满足其需求。顶部路径（20 Gbps）和底部路径（80 Gbps）的容量都不足。
关键问题是，每个路由器都是独立做出决策，没有进行协调。
通过引入集中式控制器，控制器可以查看整个网络结构和每个流的需求，并更智能地为每个流分配路径。由此产生的决策是全局最优的，并提高了网络效率。
集中式流量工程可以做出更智能的路由决策，这取决于操作员想要优化的目标。例如，我们可以将流分类为高优先级或低优先级，并做出同时优化网络利用率和不同应用需求的决策。
数据中心 overlay 中的 SDN
在上一节中，我们看到虚拟交换机可以应用封装来连接 overlay 和 underlay 网络。给定一个虚拟地址，我们可以添加一个带有相应物理地址的头部，这使得数据包可以沿 underlay 网络发送。但是，我们如何知道虚拟地址和物理地址之间的映射呢？
我们还看到，封装可用于在单个数据中心中支持多个租户，每个租户运行自己的私有网络。交换机可以添加带有虚拟网络 ID 的头部。但是，我们如何知道要使用哪个虚拟网络 ID 呢？
数据中心中的集中式 SDN 控制器可用于解决这些问题。每个租户可以操作自己的控制器。当创建新的 VM 时，SDN 会了解其虚拟和物理地址。然后，SDN 可以更新其他虚拟交换机中的转发表，添加带有新虚拟 / 物理地址映射的封装规则。
例如，假设创建了 Coke VM 2，其虚拟 IP 为 192.0.2.1，物理 IP 为 2.2.2.2。SDN 知道 Coke VM 1 位于物理服务器 1.1.1.1 上，因此它可以到 1.1.1.1 上的虚拟交换机，为新的 Coke VM 2 添加封装规则。
1.1.1.1 上的流表可能会说：如果你收到目的地为 192.0.2.1 的数据包，添加一个带有 Coke 虚拟网络 ID 42 的头部。此外，添加一个带有相应物理地址 2.2.2.2 的头部。然后，沿 underlay 网络发送数据包。
数据中心 overlay 中 SDN 的优势
为什么我们要使用集中式 SDN 架构来支持数据中心中的虚拟化和多租户，而不是使用更标准的路由协议呢？
集中式 SDN 架构允许我们将 overlay 和 underlay 网络清晰地拆分为两个可扩展的层。在传统架构中，underlay 网络中的路由器必须处理自定义封装头部（例如虚拟网络 ID）。SDN 允许 underlay 网络保持简单，无需考虑虚拟化或多租户。
集中化为我们提供了一种在终端主机上实现控制平面的简单方法，无需任何复杂的路由协议。控制器了解新主机并相应地更新其他主机。如果没有集中式控制器，我们可能需要一些复杂的分布式方案来确定要添加哪些封装头部。
这种 SDN 架构还向我们展示了 overlay 网络为何能够很好地扩展。租户的 SDN 控制器只需要了解属于该特定租户的 VM。相比之下，如果我们使用传统架构，一个新的 Coke VM 可能必须向所有其他 VM（甚至 Pepsi VM）宣告自己。
数据中心 underlay 中的 SDN
数据中心 underlay 是一个物理网络，就像任何其他网络一样，尽管具有特殊的拓扑结构。许多通用网络挑战，如实现链路的高利用率，也适用于数据中心 underlay 网络。这意味着我们也可以将 SDN 应用于 underlay 网络。
underlay 网络中的 SDN 可以帮助我们高效地通过数据中心路由数据包。例如，操作员可能希望将小流沿延迟小的链路发送，将大象流沿高带宽的链路发送。
在我们的 underlay Clos 网络中，按流负载均衡（对五元组进行哈希以选择路径）仍然可能导致多个大象流沿同一条路径发送。即使两个大象流使用不同的路径，这些路径也可能共享链路，这些链路可能会变得拥塞。SDN 控制器可以通过协调流并将它们放置在不重叠的路径上来解决这个问题。
这篇 2022 年谷歌的论文描述了通过使用 SDN 更智能地路由流量，消除 Clos 网络中的层级（减少链路，降低数据中心成本）。
超大规模数据中心通常在 overlay 和 underlay 网络中都使用 SDN。这些通常作为解耦的系统实现。有一个 SDN 负责 underlay，另一个独立的 SDN 负责 overlay。
广域网中的 SDN
除了数据中心，SDN 在通用广域网中也很有用，特别是当带宽的高效利用至关重要时。例如，在前面的流量工程示例中，想象一下如果我们的 10 Gbps 链路是海底电缆。增加额外带宽的成本很高，因此优化必须专注于高效利用我们已有的带宽。
集中式控制的缺点
集中化并非没有代价，它有一些缺点。
一个缺点是可靠性。在传统网络中，如果一个路由器发生故障，路由协议会围绕故障进行收敛。其他路由器可以沿其他路径重新路由流量。相比之下，如果中央控制器发生故障，我们就无法再更新网络，路由器也不知道如何适应变化。
注意：我们将集中式控制器描绘为单个实体，但它不必在单个服务器上运行。控制平面计算可以在多个服务器上进行，这些服务器通过协调以逻辑集中的方式运行。这与原始模型不同，在原始模型中，路由器进行协调但仍然做出自己的分布式决策。这有助于避免硬件中的单点故障，尽管控制器作为一个逻辑单元仍然可能发生故障（例如代码中的错误）。
集中化还带来了可扩展性问题。控制器必须为所有设备做出决策，这对于大型网络来说可能成本很高。相比之下，在传统网络中，每个路由器只需要为自己执行计算。
集中化还可能引入不同类型的复杂性。在传统网络中，我们可以购买一个路由器并连接它，它大致可以立即开始工作。使用中央控制器，我们面临额外的基础设施挑战。我们将控制器放在哪里？我们如何以可靠的方式将其连接到各个路由器？
这是一个活跃的研究领域，包括 Sylvia Ratnasamy 和 Rob Shakir（伯克利 CS 168 课程讲师）的一个项目。
管理平面和数据平面中的 SDN
我们已经将 SDN 视为实现控制平面的新方法。但是，导致 SDN 发展的最初挫折出现在管理平面。
事实证明，SDN 在控制平面使用的许多设计范式也可以应用于管理平面。例如，我们看到 SDN 依赖于定义良好的、可编程的 API（例如 OpenFlow）。
TODO：2024 年春季学期时间不足。
（注：文档部分内容可能由 AI 生成）