SDN是一种面向可编程商品硬件的网络构建方法，它具有在软件中实现数据包转发和控制数据包转发的智能性。实现这样的设计独立于任何特定的协议栈，但是需要一组开放的api和一组支持这些api的新的软件组件。本章介绍了SDN软件栈的基本结构。

软件堆栈

软件堆栈的概述，其中包括一个运行本地交换机操作系统的白盒交换机，该交换机由托管一组控制应用程序的全局网络操作系统控制。还在右侧显示了一组相应的示例性开源组件（Trellis、ONOS和strateum）

两个开放接口：一个在控制应用程序和网络操作系统之间，一个在网络操作系统和基本白盒交换机之间。在示例组件的上下文中，这两个接口在图12中被描述为“API垫片”，在第一种情况下对应于gNMI、gNOI和FlowObjective的组合，在第二种情况下对应于gNMI、gNOI和P4Runtime或OpenFlow的组合。将gRPC显示为这两个api的传输协议是一种实现选择，但从现在起，我们将理所当然地选择其中一种。


重要的是要记住，列出的软件组件对应于活动的开源项目，因此它们会继续发展（与它们的API相同）。每个组件及其相关api的特定版本已经集成并部署在试用和生产环境中。例如，尽管显示P4Runtime作为switchos导出的候选控制接口，但是部署的解决方案使用OpenFlow。（这包括Comcast部署。）同样，尽管gNMI/gNOI在图中显示为每个交换机的config/ops接口，但有些解决方案使用NETCONF。
交换机和主机的实现

从单个交换机的角度来看，软件堆栈的自顶向下视图所示，但同时，记住网络透视图非常重要。图13通过关注通过网络连接一对vm的端到端路径给出了这个透视图。

这一观点突出了系统的两个重要方面。第一个观点加强了我们一直强调的一点：网络操作系统（如ONOS）是全网的，而交换机操作系统（如strateum）是针对每个交换机的。

第二个是SDN软件栈的一部分运行在最终的主机上。特别是，有一个虚拟交换机（vSwitch），它通常作为服务器上运行的hypervisor的一部分在软件中实现。虚拟交换机负责在服务器上运行的虚拟机之间转发数据包。与物理交换机一样，vSwitch将数据包从输入端口转发到输出端口，但这些端口是连接到虚拟机的虚拟端口，而不是连接到物理机器的物理端口。

幸运的是，我们可以认为vSwitch的行为类似于物理交换机，包括它支持的api。vSwitch是在通用处理器上而不是在专用集成电路（ASIC）上用软件实现的。这是一个实现细节。虽然这是正确的说法，但通过软件切换可以大大减少引入其他功能的障碍，因此特征集既丰富又动态。例如，openvswitch（OvS）是一个广泛使用的开源vSwitch，它已经与各种补充工具集成在一起。例如DPDK，它是另一个开源组件，它优化了从网络设备到运行在主机操作系统用户空间中的进程的路径。虽然这是一个重要的主题，但本书并没有探讨vSwitch的所有可能性，例如OvS或其他端主机优化，而是将其视为端到端路径上的任何其他交换机。

显示的另一个实现细节是主机可以有一个SmartNIC（SmartNIC），它可以帮助（甚至替换）vSwitch。供应商将核心功能传输到NIC的历史悠久（例如，从计算TCP/IP校验和到支持虚拟机），但在SDN的上下文中，有趣的可能性被复制并在网络交换机转发管道上找到。同样，还有一系列可能的实现选项，包括FPGA和ASIC，以及NIC是固定的还是可编程的（使用P4）。出于我们的目的，我们将把这种类型的智能网卡视为端到端路径上的另一个交换元件。

白盒开关

从底部开始，一直到和所示的堆栈，网络数据平面由一组互连的白盒交换机实现。目前，我们的重点是单个交换机，整个网络拓扑结构由运行在软件栈顶部的控制应用程序决定。

该体系结构独立于交换机供应商，概述的完整软件堆栈可以在分别使用赤足网络（现为Intel Corporation）和Broadcom制造的Tofino和Tomahawk交换芯片构建的交换机上运行。Tofino芯片实现了基于PISA的可编程转发流水线，Tomahawk芯片实现了固定功能的流水线。

对于两个芯片，一对P4程序定义了transferNoneHair管道。第一个（forward.p4）指定转发行为。第二个（arch.p4）指定目标转发芯片的逻辑架构。P4编译器生成目标文件，这些文件将同时加载到网络操作系统和交换机中。这些对象文件中没有命名，但是这两个组件都是ne

因为一个组件实现转发行为（switch），而另一个组件控制转发行为，所以需要理解输出。（网络操作系统）。

开关操作系统

从基本硬件开始，每个交换机运行一个本地交换机操作系统。不要与管理交换网络的网络操作系统混淆。switch操作系统运行在交换机内部的商用处理器上。它负责处理发送到交换机的API调用，例如从网络操作系统发出的API调用。这包括对交换机的内部资源采取适当的措施，这有时会影响交换芯片。


可以使用多个开源交换操作系统（包括最初由Microsoft Azure开发的SONiC），但我们使用Stratum和开放网络Linux（ONL）的组合作为主要示例。ONL是Linux的一个支持交换的发行版（最初由BigSwitch编写），而stratinum（最初由Google开发）主要负责在面向外部的api和内部交换资源之间进行转换。因此，有时我们称之为分层薄交换操作系统。


阶层介导开关与外界的所有互动。这包括加载由P4编译器生成的对象文件，P4编译器定义了数据平面和控制平面之间的一致性。契约有效地用自动生成的规范取代了OpenFlow的流规则抽象。由分层管理的其余API定义如下：

P4Runtime：用于在运行时控制转发行为的接口。它是填写转发表和处理转发状态的关键。它是通过P4程序和硬件无关的方法实现的。（为了完整起见，图12还列出了OpenFlow作为一个替代控制接口。）

gNMI（gRPC网络管理接口）：用于设置和检索配置状态。gNMI通常与OpenConfig-YANG模型搭配使用，后者定义了状态树的配置和结构。

gNOI（gRPC网络操作接口）：用于设置和检索操作状态，例如支持证书管理、设备测试、软件升级和网络故障排除。

如果您回想一下第一章中介绍的“控制”和“配置”之间的区别，那么您将认识到P4RNoneUntime是控制API，gNMI/gNOI组合是交换机传统配置API的现代版本。后一个API在过去被称为OAM接口（用于“操作、管理和维护”），通常作为命令行接口实现。

网络操作系统

网络操作系统是配置和控制白盒交换网络的平台。它作为交换机外部的逻辑集中式SDN控制器工作，并管理整个网络中的一组交换机。此角色的核心负责监视这些交换机的状态（例如，检测端口和链路故障），维护反映网络当前状态的拓扑的全局视图，并使该视图可用于任何感兴趣的控制应用程序。这些控制应用程序反过来“指示”网络操作系统基于它们提供的任何服务来控制通过底层交换机的数据包流。这些“控制指令”的表达是网络操作系统API的一个关键方面。

在这个概念描述的范围之外需要一个特定的网络操作系统，我们以ONOS（开放网络操作系统）为例。在性能、可伸缩性和可用性方面，ONOS是同类产品中最好的。在顶端，小野寺负责三件事：

管理拓扑：跟踪网络基础设施设备及其互连的列表，以便为其余平台和应用程序提供网络环境的共享视图。

管理配置：帮助在多个网络设备上发布、跟踪、回滚和验证原子配置操作。这有效地反映了每个交换机的配置和操作接口（也使用了gNMI和gNOI），但在网络级别而不是设备级别。

控制交换机：允许对网络交换机的数据平面包处理管道进行整形，然后控制这些管道中的流规则、组、表等组件。

对于最后一个角色，ONOS导出了northboundflowobjectives抽象，它以独立于管道的方式总结了流规则。要求是这个接口必须是开放的和定义良好的；这样的接口不止一个。如果随着时间的推移，人们对网络操作系统接口达成共识，那么应用程序将更容易移植。然而，与服务器操作系统一样，软件栈越多，达成共识就越困难。

我们不能断言FlowObjectives是控制交换机的理想接口。他们的开发是不必要的，允许开发人员处理不同的管道。定义一个公共接口是当前研究的主题。

最后，尽管没有显示ONOS内部的任何细节，但是为了更好地理解它在更大的场景中的作用，我们注意到任何网络操作系统中最关键的子系统是可伸缩的密钥/值存储。因为ONOS提供了一个逻辑上集中的网络视图，所以其性能、可伸缩性和可用性的关键在于它如何存储状态。对于ONOS，这个存储由一个名为Atomix的开源项目提供，它实现RAFT共识算法。

叶脊布

由于我们使用ONOS作为网络操作系统，所以我们仅限于ONOS托管的SDN控制应用程序。为了便于说明，我们使用“网格”作为控制应用程序。网格在白盒交换网络上实现了叶脊结构。这意味着Trellis指定了一个特定的网络拓扑：数据中心clusterNoneCollective leaf ridge拓扑。该拓扑包括一组分支交换机，每个分支交换机充当机架顶部交换机（即

s、 它将所有服务器连接在一个机架中），分支交换机由一组主干交换机互连。甚至。

在更高的层次上，网格扮演三个角色。首先，它提供了一种交换结构，可以将多机架集群中的服务器与运行在这些服务器上的虚拟机互连。其次，它使用BGP将整个集群的整个上游连接到对等网络，包括互联网（也就是说，它的行为很像路由器）。第三，它将整个集群连接到下游接入网（即终止接入网技术，如PON和LTE/5G）。换言之，最好不要将网格视为锁定在某些数据中心的传统叶脊结构，但最好将网格视为运行在网络边缘的互连，这有助于使访问特定的边缘云桥连接到基于IP的数据中心云。

在实现方面，Trellis实际上对应于ONOS上运行的controlapps套件，而不是单个应用程序。该套件支持多种控制平面功能，包括：

VLAN和L2桥接

IPv4和IPv6单播和多播路由

DHCP L3中继

家庭和双上游服务器

QinQ转发/终止

基于MPLS的伪线。

对于这些功能，相应的控制应用程序通过观察网络拓扑结构的变化和发布进程目标来与ONOS交互，而不是使用传统路由器和交换机中的任何标准协议实现。传统协议所涉及的唯一时间是当Trellis需要与外部世界通信时（例如上游metro/core路由器），在这种情况下，它使用标准的BGP（由开源Quagga服务器实现）。

最后，有时网格被部署在一个站点上，并且多个移动基站通过网格叶交换机连接在一起。但是，您也可以使用多级激励将网格扩展到网络中的多个站点。