随着互联网和数据中心流量的爆炸式增长，SDN已经逐步取代静态路由交换设备成为构建网络的主流方式，本系列是免费电子书《Software-Defined Networks: A Systems Approach》的中文版，完整介绍了SDN的概念、原理、架构和实现方式。原文: Software-Defined Networks: A Systems Approach
第3章 基本架构
SDN是一种利用可编程的商用硬件构建网络的方法，从而通过软件实现智能的包转发控制以及其他网络操作。实现这样的设计不依赖任何特定协议栈，而是需要一组开放API以及支持这些API的新软件组件。本章将介绍SDN软件栈的基本架构。
本章定义了这种软件栈的一般架构，介绍了符合该架构的一个示例集合，不过能够集成到该架构中的特定组件和工具其实有多种选择。我们这样做只是为了使讨论更加具体，我们介绍的组件有两个重要属性。第一，它们是开源的，可以在GitHub上免费获得。第二，它们旨在共同努力，提供全面的解决方案，覆盖我们需要的所有场景。这两个属性使得任何人都可以构建出在生产网络中运行的相同的端到端系统。
3.1 软件栈(Software Stack)
图15给出了软件栈的概览，包括一个运行本地交换机操作系统(Switch OS) 的裸金属交换机(Bare-Metal Switch)，由一组控制应用程序(Control Applications) 控制，这些控制程序托管在全局网络操作系统(Network OS) 上。图15右边显示了一组对应的范例开源组件(SD-Fabric, ONOS和Stratum)，左边显示了相关的P4工具链。本章将介绍这些组件，后面章节将给出更多细节。
请注意此图与第1章中的图2之间的相似性。两幅图都包含两个开放接口: 一个在控制程序和网络操作系统之间，另一个在网络操作系统和底层可编程交换机之间。在图15中，这两个接口被描述为“API shims”，在示例组件的上下文中，第一种接口对应于gNMI、gNOI和FlowObjective的组合，第二种接口对应于gNMI、gNOI和P4Runtime或OpenFlow的组合。gRPC是这些API的传输协议，这是一种常规的实现选择。(注意，与其他协议不同，OpenFlow不会在gRPC上运行。)
重要的是要记住，图15中列出的软件组件都对应于活跃开源项目，因此会继续发展(就像它们的API一样)。每个组件的特定版本(及其相关API)已经集成并部署到试验和生产环境中。例如，虽然图中显示P4Runtime是Switch OS导出的候选控制接口，但也有一些部署的解决方案使用OpenFlow。(包括Comcast的部署。)类似的，虽然图中显示gNMI/gNOI作为交换机的配置/操作接口，但也有使用NETCONF的解决方案。
本书的目的不是要试图跟踪所有可能的组合的组件版本和API，而是在图15中选择专注于单一一致的堆栈，因为这代表了迄今为止我们基于早期软件栈所能做出的关于"正确"方法的最佳判断。
3.1.1 交换机实现 vs 主机实现(Switch vs Host Implementation)
图15显示了从单一交换机视角出发的软件栈视图，但是从网络视角分析也很重要。图16通过关注连接虚拟机(VM)的网络端到端路径给出了这样一个视角。
这一视图突出了系统的两个重要方面。首先强调了网络操作系统(如ONOS)是网络范围内的，而交换机操作系统(如Stratum)在每个交换机内。
其次，SDN软件栈的一部分运行在终端主机上。尤其是需要在服务器管理程序中运行虚拟交换机(vSwitch, Virtual Switch) 软件，负责将数据包转发到VM以及转发从VM返回的包。(当然，并不是每个终端主机都运行VM，但类似架构同样适用于容器主机或裸金属服务器。)就像物理交换机一样，vSwitch将数据包从输入端口转发到输出端口，但这些是连接到VM(或容器)的虚拟端口，而不是连接到物理机器的物理端口。
幸运的是，可以把vSwitch看作物理交换机，包括其支持的API。注意一个实现细节，即vSwitch是在通用处理器上而不是在专用集成电路(ASIC)上通过软件实现的。因此作为软件交换机，大大降低了引入额外功能的障碍，从而能够提供丰富、动态的功能集。例如，OVS(Open vSwitch) 是一款应用广泛的开源vSwitch，支持OpenFlow作为北向API，构成了原有Nicira网络虚拟化平台的数据平面。OVS可以与一系列补充工具集成，比如另一个开源组件DPDK(数据平面开发工具包, Data Plane Development Kit)，从而优化x86处理器上的数据包转发操作。虽然这是一个重要的主题，但本书不会探讨vSwitch(如OVS或其他终端主机优化)的所有可能性，而是像对待端到端路径上的任何其他交换机一样对待vSwitch。
图16显示的另一个实现细节是，主机可能用智能网卡(SmartNIC, Smart Network Interface Card) 来辅助(甚至取代)vSwitch。厂商将内核功能卸载到网卡上已经有很长的历史了(例如，从计算TCP/IP checksum到支持VM)，但在SDN环境中，一种可能的有趣应用是复制网络交换机上的转发流水线。这同样有一系列可能的实现选择，包括FPGA和ASIC，以及网卡是固定功能还是可编程(使用P4)。就我们的目的而言，将把这种智能网卡当作端到端路径上的另一个交换组件。
主机中心视角
本书采用面向网络的SDN视角，将终端主机(运行在主机操作系统中的虚拟交换机和连接主机到网络的网卡)视为网络的扩展，在网络操作系统的控制下运行。不过以主机为中心的观点同样有效，更重要的是，其附带了一个健壮的开源软件生态系统，作为主机操作系统的一部分运行。
DPDK是其中一个例子，但另一个受到关注的是eBPF(扩展伯克利包过滤器, extended Berkeley Packet Filter)和XDP(快速数据路径, eXpress Data Path)的组合，它们提供了一种方法来在OS内核(甚至可能在SmartNIC上)中编程通用的Match-Action规则。这在精神上与OpenFlow和P4相似，只是它们允许Action部分是任意程序。相比之下，OpenFlow定义了一组固定的动作，而P4是表达动作的特定语言(例如，不包括循环)。当Action必须在固定周期内执行时，这是必要的，例如基于交换机的转发流水线。它还使数据平面的形式化验证(formal verification)成为可能，这是第10章讨论的一个很有前途的机会。
3.2 裸金属交换机(Bare-Metal Switch)
我们从图15和图16所示软件栈从下往上介绍，底层的网络数据平面是由一组互连的裸金属交换机实现。我们现在重点关注单个交换机，整个网络拓扑是由运行在软件栈顶层的控制程序决定，后面我们会介绍一个管理叶脊拓扑的控制应用程序。
该架构与交换机供应商无关，本章介绍的完整软件栈运行在基于Tofino和Tomahawk交换芯片构建的交换机上，分别由Barefoot Networks(现在是英特尔)和博通制造。Tofino芯片实现了基于PISA的可编程转发流水线，而Tomahawk芯片实现了固定功能流水线。
两种芯片都通过两个P4程序定义转发流水线，第一个(forward.p4)指定转发行为，第二个(arch.p4)指定目标转发芯片的逻辑架构。P4编译器生成加载到网络操作系统和交换机中的目标文件，图15中我们没有指出这些目标文件(后面将在第4章和第5章中介绍详细信息)，但是两个组件都需要感知输出逻辑，因为一个实现转发行为(交换机)，而另一个控制转发行为(网络操作系统)。
我们将在第4章介绍编译器工具链的细节。现在，我们将只回答为什么在有固定功能交换芯片的情况下，还需要一个P4程序(我们没有使用P4来修改其固定行为)。简单总结一下，因为我们需要正式的转发流水线规范来生成数据平面API。P4程序提供了转发流水线的抽象模型，无论芯片的实际硬件流水线是固定的还是可编程的，我们仍然需要知道如何将抽象流水线映射到物理流水线上，这就是arch.p4起作用的地方。对于可编程芯片，forward.p4实际上定义了流水线，而对于固定功能芯片，仅仅只是通过forward.p4描述流水线。我们仍然需要forward.p4，因为在两种情况下工具链都需要使用它以及arch.p4生成位于控制平面和数据平面之间的API。
3.3 交换机操作系统(Switch OS)
从基本硬件往上看，每个交换机运行一个本地交换机操作系统。不要与管理交换机网络的网络操作系统混淆，这个交换机操作系统运行在交换机内部的商品处理器上(图15中没有显示)。它负责处理发送给交换机的API调用，例如来自网络操作系统的调用，以及对交换机内部资源采取适当的操作，有时会影响交换机芯片。
有多种开源交换机操作系统(包括最初由Microsoft Azure开发的SONiC)，但我们使用Stratum和Open Network Linux(ONL) 的组合作为主要示例。ONL是Linux的交换机发行版(最初由Big Switch Networks提供)，而Stratum(最初由谷歌开发)主要负责外部API和内部交换机资源之间的转换。因此，我们有时把Stratum称为瘦交换机操作系统(Thin Switch OS) 。
Stratum在交换机与外部世界的所有交互中起到中介作用，包括加载P4编译器生成的目标文件，该文件定义了数据平面和控制平面之间的契约。契约有效的用自动生成的规范替换了OpenFlow的流规则抽象。其他Stratum管理API定义如下:
- P4Runtime: 控制转发行为的运行时接口，是填充转发表和操作转发表状态的关键。P4Runtime独立于任何特定P4程序，并且与底层硬件无关。这与OpenFlow形成了鲜明对比，OpenFlow对转发模型以及如何与控制平面交互有着相当明确的规定。(为了完整起见，图15还列出了OpenFlow作为另一个控制接口。)
- gNMI(gRPC Network Management Interface): 用于设置和检索配置状态。gNMI通常与OpenConfig YANG模型配对，后者定义配置和状态树的结构。
- gNOI(gRPC Network OperationsInterfaces): 用于设置和检索运行状态，如证书管理、设备测试、软件升级、组网故障处理等。
如果你还记得在第一章中介绍的控制和配置之间的区别，那么你会认出P4Runtime就是控制API，而gNMI/gNOI组合在一起就是交换机传统配置API的现代版本。后一种API在历史上被称为OAM接口(即"Operations, Administration, and Maintenance")，通常被实现为命令行接口(当然，这不是真正的API)。
3.4 网络操作系统(Network OS)
网络操作系统是配置和控制交换机网络的平台，作为逻辑上集中的SDN控制器在交换机之外运行，并在全网范围内管理一组交换机。这个角色的核心是负责监控交换机状态(例如，检测端口和链路故障)，维护反映网络当前状态和拓扑的全局视图，并为任何感兴趣的控制程序提供该视图。这些控制程序反过来"指示"网络操作系统根据它们提供的服务来控制底层交换机的数据包流，这些"控制指令"的表达方式是网络操作系统API的关键方面。
我们基于ONOS(开放网络操作系统, Open Network Operating System) 这一特定网络操作系统作为范例来完整描述这一概念，ONOS在性能、可伸缩性和可用性方面是最好的。简单来说，ONOS负责三件事情:
- 管理拓扑(Managing Topology): 跟踪网络基础设施及其互联设备，为平台和其他应用程序提供网络环境的共享视图。
- 管理配置(Managing Configuration): 帮助在多个网络设备上执行、跟踪、回滚和验证原子配置操作。这可以有效反映每个交换机的配置和操作接口(也使用gNMI和gNOI)，但是在网络级别而不是设备级别上实现的。
- 控制交换(Controlling Switches): 控制网络交换机的数据平面数据包处理流水线，并对流水线内的流规则、组、监控等构建块进行后续控制。
关于最后一个角色，ONOS导出了一个北向FlowObjectives抽象，以一种独立于流水线的方式泛化流规则接口(在第6章中有更详细的描述)，但不像独立交换机导出的控制接口那样标准化[1]。与传统服务器操作系统一样，基于ONOS API上的应用程序不容易移植到另一个网络操作系统上。对这个接口的需求是开放的以及定义良好的，当前并不是只有一个这样的接口。如果随着时间的推移，如果业界对网络操作系统接口达成了共识，那么应用程序将更容易被移植。但就像服务器操作系统一样，在软件栈中层级越高的操作系统，就越难以达成这样的共识。
[1] 我们没有说FlowObjectives是控制交换机的理想接口。API会出于实际需要而发展，允许开发人员处理不同的流水线。定义通用接口是正在进行的研究的主题。
最后，尽管图15没有显示关于ONOS内部的任何细节，但为了更好的理解其在更高层面上所扮演的角色，我们注意到在任何网络操作系统中最关键的子系统是可伸缩键/值存储(Scalable Key/Value Store)。由于ONOS提供了一个逻辑上集中的网络视图，其性能、可伸缩性和可用性的关键在于如何存储这些状态。在ONOS中，这个存储是由一个名为Atomix的开源项目提供的，该项目实现了RAFT共识算法。像Atomix这样的存储服务是当今几乎所有水平可伸缩云服务的基石，我们将在第6章中详细介绍。
3.5 叶棘网络(Leaf-Spine Fabric)
由于我们使用ONOS作为网络操作系统，所以仅限于使用ONOS托管的SDN控制应用程序。为了说明问题，我们使用SD-Fabric作为控制应用程序，它在可编程交换机网络上实现了叶棘网络。意思是，SD-Fabric定义了特定的网络拓扑结构，特别是数据中心集群常见的叶脊拓扑结构。如2.3节所述，该拓扑包括一组叶交换机，每一个都作为ToR交换机(即连接单个机架中的所有服务器)，然后叶交换机再由一组脊交换机互连。
从架构上来说，SD-Fabric扮演了三个角色。首先，提供了一个交换结构，在多机架集群中将服务器和运行在这些服务器上的虚拟机相互连接。其次，使用BGP将集群作为整体连接到对等网络，包括Internet(也就是说，其行为很像路由器)。最后，将集群作为整体连接到下游接入网(即PON、RAN等接入网)。换句话说，与其将SD-Fabric看作传统的在数据中心内部构建的叶脊网络，不如将其看作是运行在网络边缘的互连系统，帮助连接访问特定边缘云和基于IP的数据中心云。
在实现方面，SD-Fabric实际上对应一套运行在ONOS上的控制程序，而不是单一应用程序。该套件支持多种控制平面特性，包括:
- VLAN和L2桥接
- IPv4和IPv6单播/组播路由
- DHCP L3中继
- 服务器和上行路由器的双归属冗余
- QinQ转发/终止
- 基于MPLS的伪连接
对于每个特性，都有相应的控制程序与ONOS交互，通过观察网络拓扑的变化并发出Flow Objective而实现，而不是基于任何传统路由器/交换机的标准协议实现。只有当SD-Fabric需要与外部通信(例如，上游城市/核心路由器)时，才会涉及到传统协议，这时需要使用标准BGP(由开源Quagga服务器实现)。这实际上是SDN环境的共同特征: 内部或在新领域避免传统路由协议，但与外部世界的交互仍然需要。
最后，SD-Fabric有时部署在一个站点，多个RAN基站通过SD-Fabric叶交换机连接。但是，SD-Fabric还可以使用多层棘网络扩展到多个站点，如图17所示。第7章会更详细介绍这部分内容。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind