随着互联网和数据中心流量的爆炸式增长，SDN 已经逐步取代静态路由交换设备成为构建网络的主流方式，本系列是免费电子书《Software-Defined Networks: A Systems Approach》的中文版，完整介绍了 SDN 的概念、原理、架构和实现方式。原文: Software-Defined Networks: A Systems Approach
第 4 章 裸金属交换机
本章将介绍作为 SDN 网络底层硬件基础的裸金属交换机，我们的目标不是介绍详细的硬件原理，而是提供足够的设计概念，从而能够欣赏在其上运行的软件栈。请注意，这是个仍在发展中的技术栈，不同厂商采用了不同的实现方法。本章讨论了作为交换机数据平面编程语言的 P4 以及作为第一代解决方案的 OpenFlow。我们将从更一般的、可编程的 P4 开始，按照逆时间顺序介绍这两种方法。
4.1 交换层概要(Switch-Level Schematic)
首先，我们把裸金属交换机作为整体来考虑，可以类比为一台由一组商业化的、现成的组件组装而成的 PC。事实上，利用这些组件构建交换机的完整架构规范可以在开放计算项目(OCP, Open Compute Project) 上在线获得。这是类似于开源软件的硬件项目，类似于家用 PC，任何人都有可能依此构建高性能交换机。但就像 PC 生态系统包括戴尔和惠普这样的商品服务器供应商一样，也可以从裸金属交换机供应商(如 EdgeCore、Delta 等)那里购买预构建(OCP 兼容)交换机。
图 18 给出了裸金属交换机的高层示意图。网络处理单元(NPU, Network Processing Unit) 是一种商业硅交换芯片，被优化来解析包头并做出转发决策。NPU 能够以每秒太比特(Tbps)的速度处理和转发数据包，其速度足以与 32x100-Gbps 端口或图中所示的 48x40-Gbps 端口保持一致。在撰写本文时，这些芯片的最先进技术是在 400 Gbps 端口实现的 25.6 Tbps。
图 18. 裸金属交换机高层概要。
请注意，我们对术语 NPU 的使用可能会被认为有点不标准。过去，NPU 指的是更狭义的网络处理芯片，用于实现智能防火墙或深度包检测。它们不像我们在本章讨论的 NPU 那样通用，性能也不高。然而，长期趋势是 NPU 的性能越来越接近固定功能 ASIC，同时提供更高的灵活性。目前的商用硅交换芯片似乎有可能淘汰早期的专用网络处理器。这里使用的 NPU 命名规范与构建可编程特定处理器的行业趋势一致，包括用于图形处理的 GPU(图形处理单元, Graphic Processing Unit)和用于 AI 的 TPU(张量处理单元, Tensor Processing Unit)。
图 18 显示的 NPU 由基于 SRAM 的内存(在处理数据包时进行缓冲)和基于 ASIC 的转发流水线组合实现，这些流水线通过一系列(Match, Action)对实现，我们将在下一节中更详细介绍转发流水线。交换机还包括一个通用处理器，通常是一个 x86 芯片，用以控制 NPU。如果控制面在交换机上运行，那么 CPU 将运行 BGP 或 OSPF，但就我们的目的而言，控制面是在交换机外以 Switch OS 的方式运行的，因此需要导出控制数据平面的 API。该控制处理器与 NPU 通信，并通过标准 PCIe 总线连接到外部管理网络。
图 18 还显示了使这一切变得实用的其他商品组件。无论是 40G 以太网、10G PON 还是 SONET 或者光学设备，都可以购买可插拔收发模块，用于处理所有媒介接入细节。这些收发器都符合 SFP+等标准化要求，也可以反过来通过标准化总线连接到其他组件(如 SFI)。最关键的是，网络行业正在进入计算机行业在过去 20 年里所享受的同样的商品化世界。
最后，虽然图 18 中没有显示，但每个交换机都包括 BIOS，很像微处理器中的对应物，用来提供和引导裸金属交换机的固件。在 OCP 的指导下，出现了一种被称为开放网络安装环境(ONIE, Open Network Install Environment) 的标准 BIOS，因此我们在本章的其余部分假定基于 ONIE 讨论。
4.2 转发流水线(Forwarding Pipeline)
高速交换机使用多级流水线处理数据包。使用多级流水线而不是单级处理器的原因在于，单个包的转发可能涉及到查看多个报头字段，每个阶段都可以通过编程来处理不同的领域组合。多阶段流水线给每个包增加了一点端到端延迟(以纳秒为单位)，但意味着可以同时处理多个包。例如，在阶段 1 对包 B 进行初始查找时，阶段 2 可以对包 A 进行二次查找，以此类推。从而意味着流水线作为一个整体能够匹配所有输入端口的总带宽。重复上一节中的数字，目前最先进的是 25.6 Tbps。
一个特定 NPU 如何实现流水线的主要区别在于，每个阶段功能是固定的(即每个阶段都知道如何处理某些固定协议的报头)还是可编程的(即每个阶段都是通过动态编程知道要处理哪些报头字段)。在接下来的讨论中，我们从更一般的情况(可编程流水线)开始，并在最后回到固定功能的对应流水线。
在体系架构层面，可编程流水线通常被称为协议独立交换架构(PISA, Protocol Independent Switching Architecture)。图 19 给出了 PISA 概述，包括三个主要组成部分。第一个是解析器(Parser)，通过编程定义哪些报头字段(以及在包中的位置)将被后面的阶段识别和匹配。第二个是匹配操作单元(Match-Action Unit)，每个单元都被编程来匹配(并可能对其进行操作)一个或多个已标识的报头字段。第三个是编码器(Deparser)，将包元数据重新序列化到包中，然后在输出链路上传输。deparser 根据之前处理阶段缓存在内存中的所有报头字段重新构建在链路上传输的每个包。
图中没有显示关于穿越流水线的数据包的元数据集合，包括每个包的状态(如输入端口和到达时间戳)，以及跨连续包计算的流级别状态(如交换机计数器和队列深度)。这种元数据(对应于 ASIC 的寄存器)，可用于各个阶段的读写，也可以被 Match-Action Unit 使用(例如匹配输入端口)。
图 19 所示. PISA 多级流水线概要。
图 19 中的各个 Match-Action Unit 值得我们仔细观察。图中显示的内存通常是基于 SRAM 和 TCAM 组合构建，实现了一个存储正在处理的数据包中匹配的位模式的表。在这一特定组合中，TCAM 比 SRAM 更昂贵、更耗电，但能够支持通配符匹配。具体来说，TCAM 中的"CAM"代表"内容可寻址内存(Content Addressable Memory,)"，意味着希望在表中查找的键可被有效用作实现该表的内存地址。"T"代表"三元(Ternary)"，这是一种技术方法，表示想要查找的键可以包含通配符(例如，键 10*1 可以同时匹配 1001 和 1011)。从软件角度来看，主要结论是通配符匹配比精确匹配更昂贵，应该尽可能避免。
然后，图中显示的 ALU 与相应的模式配对实现操作。可能的操作包括修改特定报头字段(例如，减少 TTL)，增加或弹出标签(例如，VLAN, MPLS)，增加或清除交换机内部的各种计数器(例如，处理的数据包个数)，以及设置用户/内部元数据(例如，路由表中使用的 VRF ID)。
直接编写 parser、match-action unit 和 deparser 会很乏味，类似于编写微处理器汇编代码，所以我们改用像 P4 这样的高级语言来表示所需行为，并依赖编译器生成等价的低级程序。我们将在后面章节讨论 P4 的细节，现在我们用图 20 所示的更抽象的方式来代替所需的转发流水线。(为了与其他示例保持一致，我们将此程序称为forward.p4。)该示例程序首先匹配 L2 报头字段，然后匹配 IPv4 或 IPv6 报头字段，最后对数据包应用一些 ACL 规则，然后允许它们通过(例如，将后者视为防火墙过滤规则)。这是第 1.2.3 节中图 7 中所示 OpenFlow 流水线的一个示例。
除了将流水线的高级表示转换为底层 PISA 之外，P4 编译器还负责分配可用的 PISA 资源。在这种情况下，有 4 个槽位(或行)可用作 Match-Action Unit，如图 19 所示。在可用的 Match-Action Unit 中分配槽位(slot)类似于传统编程语言在通用微处理器上分配寄存器。在我们的例子中，假设 IPv4 的 Match-Action 规则比 IPv6 或 ACL 规则多得多，编译器可以相应的在可用的 Match-Action Unit 中分配条目。
图 20. 将期望的转发行为(由图示 P4 程序指定)映射到 PISA。
4.3 流水线抽象(Abstracting the Pipeline)
另一个难题是考虑不同交换芯片实现的不同物理流水线。要做到这一点，需要一个足够通用，可以公平表示可用硬件的抽象(规范)流水线，以及抽象流水线如何映射到物理流水线的定义。有了这样一个流水线的逻辑模型，就能够支持流水线无关的控制器，如图 21 所示。
理想情况下，只有一个逻辑流水线，P4 编译器负责将该逻辑流水线映射到各种对应的物理流水线。不幸的是，市场还没有统一的单一逻辑流水线，但我们暂时把这种复杂性放在一边。另一方面，目前需要考虑的目标 ASIC 大约有 10 个。市场上有数十家交换机供应商，但在实践中，我们主要需要考虑那些为高端市场服务的供应商。
图 21. 通过定义逻辑流水线作为支持流水线无关控制平面的通用方法。
如何指定逻辑流水线？同样是通过 P4 程序实现，结果如图 22 所示。注意，我们正在重新审视图 15 中引入的两个 P4 程序。第一个程序(forward.p4)定义了我们希望从可用的交换芯片获得的功能。这个程序是由想要建立数据平面行为的开发人员编写的。第二个程序(arch.p4)本质上是一个头文件，表示 P4 程序和 P4 编译器之间的契约。具体来说，arch.p4定义了可用的 P4 可编程块、每个阶段的接口以及每个阶段的功能。谁负责编写这样的架构程序？P4 联盟是这种定义的一个来源，但不同的交换机供应商已经创建了自己的架构规范，从而密切描述其交换芯片的能力。因为有单一公共架构，可以在不同供应商的不同 ASIC 上执行相同的 P4 程序，并且该架构能够最好很好的表示任何给定 ASIC 的能力差异。
图 22 所示例子被称为可移植交换机架构(PSA, Portable Switch Architecture)，旨在为 P4 开发人员提供实现转发程序(如forward.p4)的抽象的目标机，类似于 Java 虚拟机。其目标与 Java 相同，支持一次编写、随处运行的编程范式。(注意，图 22 包括了通用arch.p4作为体系架构模型规范，但实际上体系架构模型是特定于 PSA 的，类似于psa.p4。)
图 22. P4 架构被称为 PSA(Portable Switch Architecture)。包括通用arch.p4作为架构模型规范，但是对于 PSA 来说，这将被psa.p4所取代。
与图 19 和图 20 中使用的更简单的 PISA 模型相比，我们看到了两个主要差异。首先，流水线包含一个新的固定功能阶段: 流量管理器(Traffic Manager) 。这个阶段负责对数据包进行排队、复制和调度，可以用定义良好的方式配置(例如，设置队列大小和调度策略等参数)，但不能用通用方式重新编程(例如，定义一个新的调度算法)。其次，流水线被分为两部分: 入口处理(ingress processing)(流量管理器左边)和出口处理(egress processing)(流量管理器右边)。
到底arch.p4定义了什么？基本上是三件事:
- 如图 22 所示，根据输入和输出信号(想想“函数参数和返回类型”)定义了块间接口签名。P4 开发人员为每个 P4 可编程块提供对应的实现，处理输入信号(如输入端口收到数据包)，并将输出信号写到下一个受影响的可编程块(例如数据包指示的输出队列/端口)。
- 被声明为扩展(externs) 的类型，可被视为由目标硬件开放的附加固定功能的服务，可以被 P4 开发人员调用。这类外部服务的例子包括 checksum 以及哈希计算单元、数据包或字节计数器、加密/解密数据包负载，等等。P4 体系架构中不会指定这些外部服务的实现，但会指定其接口。
- 扩展核心 P4 语言类型，包括可选匹配类型(如 4.4.3 节中描述的
range和lpm)。
P4 编译器(像所有编译器一样)有一个与硬件无关的前端，为被编译程序生成抽象语法树(AST, Abstract Syntax Tree)，以及与硬件相关的后端，从而输出特定 ASIC 的可执行文件。arch.p4只是类型和接口定义的集合。
4.3.1 V1Model
图 22 中所示的 PSA 仍在开发中，其代表了一个理想的架构，位于 P4 开发人员和底层硬件之间，但是开发人员目前正在编写的架构模型稍微简单一些。该模型称为 V1Model，如图 23.1 所示<sup>[1]</sup>。它不包括流量管理器之后的重新解析步骤，相反，它隐式连接了从入口到出口处理的所有元数据。此外，V1Model 包括一个 checksum 验证/更新块，而 PSA 将 checksum 视为一个扩展，并支持在入口/出口处理流程的任何点上进行增量计算。
[1] V1Model 最初是作为 P4 早期版本(即 P4_14 "V1Model")的参考体系架构引入，随后被用于简化 P4 程序从 P4_14 到 P4_16 的移植。
本书其余部分将使用这个更简单的模型。说句题外话，V1Model 被广泛使用的最重要因素是交换机供应商没有提供从 PSA 映射到各自 ASIC 的编译器后端。因此在此之前，PSA 还是主要停留在纸面上。
图 23. V1Model 在实践中用于抽象出不同物理转发流水线的细节，开发人员为这个抽象架构模型编写 P4。
当我们说 P4 开发人员"编写这个模型"时，其实际含义比你想的更多。在实践中，每个 P4 程序都从下面的模板开始，它实际为图 23 所示的每个可编程元素的抽象描述提供了一个代码块。
#include <core.p4> #include <v1model.p4> /* Headers */ struct metadata { ... } struct headers { ethernet_t ethernet; ipv4_t ipv4; } /* Parser */ parser MyParser( packet_in packet, out headers hdr, inout metadata meta, inout standard_metadata_t smeta) { ... } /* Checksum Verification */ control MyVerifyChecksum( in headers, hdr, inout metadata meta) { ... } /* Ingress Processing */ control MyIngress( inout headers hdr, inout metadata meta, inout standard_metadata_t smeta) { ... } /* Egress Processing */ control MyEgress( inout headers hdr, inout metadata meta, inout standard_metadata_t smeta) { ... } /* Checksum Update */ control MyComputeChecksum( inout headers, hdr, inout metadata meta) { ... } /* Deparser */ parser MyDeparser( inout headers hdr, inout metadata meta) { ... } /* Switch */ V1Switch( MyParser(), MyVerifyChecksum(), MyIngress(), MyEgress(), MyComputeChecksum(), MyDeparser() ) main;
也就是说，在包含两个定义文件(core.p4, v1model.p4)以及定义流水线将要处理的包头之后，开发人员需要编写 p4 代码用于解析、验证 checksum、处理输入等等。最后一个块(V1Switch)是"main"函数，将所有部件整合到一起形成完整的交换机流水线。至于模板中每个"…"对应的细节，我们将在后面章节中详细介绍。现在，最重要的是看到forward.p4是一个高度程式化的程序，其结构来自v1model.p4中定义的抽象模型。
