1. 在本节中，我们将深入探讨SDN控制平面-控制网络中支持SDN的设备之间的数据包转发的全网逻辑，以及这些设备及其服务的配置和管理。我们在这里的研究建立在4.4节中对通用SDN转发的早期讨论的基础上，因此在继续之前，您可能需要先回顾该节以及本章的5.1节。正如在第4.4节中一样，我们将再次采用SDN文献中使用的术语，并将网络的转发设备称为“数据包交换机”(或理解为就是用于数据包的交换机)，因为转发决策可以基于网络层源/目的地址、链路层源/目的地址以及传输层、网络和链路层分组首部字段中的许多其他值来做出。<br />可以确定SDN架构的四个关键特征[Kreutz 2015]：
  • 基于流的转发（Flow-based forwarding）。SDN控制的交换机转发的数据包可以基于传输层、网络层或链路层首部中的任意数量的首部字段值。我们在第4.4节中看到，OpenFlow1.0抽象允许基于11个不同的首部字段值进行转发。这与我们在5.2-5.4节中研究的基于路由器的传统转发方法形成了鲜明对比，在传统方法中，IP数据报的转发完全基于数据报的目的IP地址。回想一下图5.2，数据包转发规则是在交换机的流表中指定的；SDN控制平面的工作是计算、管理和安装网络的所有交换机中的流表条目。
  • 数据平面和控制平面分离（Separation of data plane and control plane）。图5.2和5.14清楚地显示了这种分离。数据平面由网络的交换机组成—相对简单(但速度较快)的设备，在它们的流表中执行“匹配加动作”规则。控制平面由确定和管理交换机流表的服务器和软件组成。
  • 网络控制功能（Network control functions: external to data-plane switches）：数据平面交换机外部。考虑到SDN中的“S”代表“软件（software）”，因此SDN控制平面在软件中实现也许就不足为奇了。然而，与传统路由器不同的是，该软件在远离网络交换机的不同服务器上运行。如图5.14所示，控制平面本身由两个组件组成-SDN控制器(或网络操作系统[Gude 2008])和一组网络控制应用程序。控制器维护准确的网络状态信息(例如，远程链路、交换机和主机的状态)；将该信息提供给在控制平面中运行的网络控制应用；并提供这些应用可以用来监视、编程和控制底层网络设备的手段。尽管图5.14中的控制器显示为单个中央服务器，但实际上该控制器仅在逻辑上集中；它通常在提供协调、可扩展性能和高可用性的多个服务器上实施。
  • 一个可编程网络（A programmable network）。网络可以通过运行在控制平面上的网络控制应用程序进行编程。这些应用程序代表SDN控制平面的“大脑”，使用SDN控制器提供的API来指定和控制网络设备中的数据平面。例如，路由网络控制应用程序可以确定源和目的地之间的端到端路径(例如，通过使用SDN控制器维护的节点状态和链路状态信息执行Dijkstra算法)。另一个网络应用程序可能会执行访问控制，即确定要在交换机上阻止哪些数据包，如第4.4.3节中的第三个示例所示。还有一个应用程序可能让交换机以执行服务器负载均衡的方式转发数据包(我们在第4.4.3节中考虑的第二个示例)。

image.png
Figure 5.14 ♦ Components of the SDN architecture: SDN-controlled switches, the SDN controller, network-control applications
图5.14♦SDN体系结构的组件：SDN控制的交换机、SDN控制器、网络控制应用
从这次讨论中，我们可以看到SDN代表了网络功能的一次重大“拆分”—数据平面交换机、SDN控制器和网络控制应用程序是独立的实体，每个实体都可以由不同的供应商和组织提供。这与SDN之前的模式不同，在SDN之前的模式中，交换机/路由器(及其嵌入式控制平面软件和协议实施)是整体式的、垂直集成的，并由单一供应商销售。SDN中网络功能的这种拆分被比作从大型机(其中硬件、系统软件和应用程序由单个供应商提供)到个人计算机(具有各自独立的硬件、操作系统和应用程序)的早期演变。计算硬件、系统软件和应用程序的分离带来了一个由所有这三个领域的创新驱动的丰富、开放的生态系统；SDN的一个希望是，它将继续推动和支持如此丰富的创新。
鉴于我们对图5.14的SDN体系结构的理解，自然会出现许多问题。流程表实际上是如何计算的，在哪里计算的？如何更新这些表以响应SDN控制的设备上的事件(例如，连接的链路接通/断开)？如何协调多个交换机上的流表条目，以产生协调一致的网络范围功能(例如，用于将分组从源转发到目的地的端到端路径，或协调的分布式防火墙)？SDN控制平面的角色是提供这些功能和许多其他功能。

5.5.1 SDN控制平面：SDN控制器和SDN网络控制应用 The SDN Control Plane: SDN Controller and SDN Network-control Applications

让我们从SDN控制平面必须提供的通用功能开始抽象地讨论SDN控制平面。正如我们将看到的，这种抽象的“首要原则（first principles）”方法将把我们引向一个反映SDN控制平面在实践中是如何实现的总体架构。
如上所述，SDN控制平面大致分为两个组件-SDN控制器和SDN网络控制应用。让我们先了解一下控制器。自从最早的SDN控制器[Gude 2008]以来，已经开发了许多SDN控制器；有关非常全面的调查，请参阅[Kreutz 2015]。图5.15提供了通用SDN控制器的更详细视图。控制器的功能可以大致组织为三层。让我们以一种不同寻常的自下而上的方式来考虑这些层：

  • 通信层（A communication layer）：SDN控制器和受控网络设备之间的通信。显然，如果SDN控制器要控制启用SDN的远程交换机、主机或其他设备的操作，则需要一个协议来在控制器和该设备之间传输信息。此外，设备必须能够向控制器传达本地观察到的事件(例如，指示连接的链路已打开或关闭的消息、设备刚刚加入网络的消息，或指示设备已启动并运行的心跳)。这些事件为SDN控制器提供网络状态的最新视图。该协议构成了控制器体系结构的最低层，如图5.15所示。控制器和受控设备之间的通信跨越了所谓的控制器的“南向（southbound）”接口。在第5.5.2节中，我们将研究OpenFlow—一个提供这种通信功能的特定协议。OpenFlow实现在大多数(如果不是全部)SDN控制器中。
  • 网络范围的状态管理层（A network-wide state-management layer）。SDN控制平面做出的最终控制决策(例如，在所有交换机中配置流表以实现所需的端到端转发、实施负载均衡或实施特定防火墙功能)将要求控制器掌握有关网络主机、链路、交换机和其他SDN控制设备状态的最新信息。交换机的流表包含计数器，其值也可能被网络控制应用程序有效地使用；因此，这些值应该对应用程序可用。由于控制平面的最终目的是确定各种受控设备的流表，因此控制器可能还会维护这些表的副本。这些信息都构成了SDN控制器维护的全网“状态”的例子。
  • 网络控制应用层的接口（The interface to the network-control application layer）。控制器通过其“北向（northbound）”接口与网络控制应用程序交互。此API允许网络控制应用程序读/写状态管理层内的网络状态和流表。应用程序可以注册以在状态更改事件发生时收到通知，以便它们可以响应从SDN控制的设备发送的网络事件通知而采取操作。可以提供不同类型的API；我们将看到两个流行的SDN控制器使用REST[Fiding 2000]请求-响应接口与其应用程序通信。

image.png
Figure 5.15 ♦ Components of an SDN controller
图5.15♦SDN控制器的组件
我们已经多次注意到，SDN控制器可以被认为是“逻辑集中的”，也就是说，该控制器可以在外部(例如，从受SDN控制的设备和外部网络控制应用程序的角度)被视为单一的、整体的服务。然而，由于容错、高可用性或性能原因，这些用于保存状态信息的服务和数据库实际上是由一组分布式服务器实现的。由于控制器功能由一组服务器实施，因此必须考虑控制器内部操作的语义(例如，维护事件的逻辑时间顺序、一致性、一致等)[Panda 2013]。这些问题在许多不同的分布式系统中都很常见；有关这些挑战的完美解决方案，请参阅[Lamport 1989，Lampson 1996]。OpenDaylight[OpenDaylight 2020]和OnosOnos 2020等现代控制器非常重视构建逻辑上集中但物理上分布式的控制器平台，为受控设备和网络控制应用提供可扩展的服务和高可用性。
图5.15中描述的架构非常类似于2008年[Gude 2008]最初提出的NOX控制器的架构，以及今天的OpenDaylight[OpenDaylight 2020]和Onos[Onos 2020]SDN控制器的架构(请参阅侧栏)。我们将在第5.5.3节中介绍一个控制器操作的示例。不过，首先让我们来看看OpenFlow协议，它是最早也是现在可以用于SDN控制器和受控设备之间通信的几个协议之一，它位于控制器的通信层。

PRINCIPLES IN PRACTICE 实践中的原则 GOOGLE’S SOFTWARE-DEFINED GLOBAL NETWORK 谷歌软件定义的全球网络 回想一下第2.6节中的案例研究，Google部署了一个专用的广域网(wide-area network，WAN)来互连其数据中心和服务器集群(在IXP和ISP中)。这个名为B4的网络有一个由谷歌设计的基于OpenFlow的SDN控制平面。从长远来看，Google的网络能够以接近70%的利用率驱动WAN链路(比典型的链路利用率高出两到三倍)，并根据应用优先级和现有流量需求在多条路径上拆分应用流量[Jain 2013]。 Google B4网络特别适合SDN：(I)Google控制从IXP和ISP的边缘服务器到其网络核心中的路由器的所有设备；(Ii)带宽最密集的应用是站点之间的大规模数据复制，在资源拥塞时可以遵循更高优先级的交互应用；(Iii)由于只连接了几十个数据中心，集中控制是可行的。 Google的B4网络使用定制的交换机，每个交换机都实现了一个略微扩展的OpenFlow版本，并带有一个本地Open Flow Agent(OFA)，它在本质上类似于我们在图5.2中遇到的控制代理。每个OFA依次连接到网络控制服务器(NCS)中的开放式流量控制器(OFC)，使用单独的“带外”网络，与在数据中心之间传输数据中心流量的网络不同。因此，OFC提供NCS用来与其受控交换机通信的服务，在本质上类似于图5.15所示的SDN体系结构中的最低层。在B4中，OFC还执行状态管理功能，将节点和链路状态保存在网络信息库(NIB)中。Google的OFC实现基于Onix SDN控制器[Koponen 2010]。实现了两个路由协议，BGP(用于数据中心之间的路由)和IS-IS(用于数据中心内路由的OSPF的近亲)。Paxos[Chandra 2007]用于执行NCS组件的热副本，以防止故障。 在逻辑上位于网络控制服务器集上方的流量工程网络控制应用（traffic engineering network-control application）与这些服务器交互，以为应用流组提供全局的、网络范围的带宽供应。借助B4，SDN向全球网络提供商的运营网络迈进了一大步。有关B4的详细说明，请参阅[Jain 2013；Hong 2018]。

5.5.2 OpenFlow协议 OpenFlow Protocol

OpenFlow协议[OpenFlow 2009，ONF 2020]在SDN控制器和SDN控制的交换机或实现我们在第4.4节前面研究的OpenFlow API的其他设备之间运行。OpenFlow协议在TCP上运行，默认端口号为6653。
从控制器流向受控交换机的重要消息如下：

  • 配置（Configuration）。此消息允许控制器查询和设置交换机的配置参数。
  • 修改-状态（Modify-State）。控制器使用此消息来添加/删除或修改交换机流表中的条目，以及设置交换机端口属性。
  • 读取状态（Read-State）。控制器使用此消息从交换机的流表和端口收集统计信息和计数器值。
  • 发送数据包（Send-Packet）。控制器使用此消息将特定数据包从受控交换机的指定端口发送出去。消息本身包含要在其有效负载中发送的数据包。

从SDN控制的交换机流向控制器的消息如下：

  • 流-移除（Flow-Removed）。该消息通知控制器流表条目已被移除，例如通过超时或作为接收到的修改状态消息的结果。
  • 端口状态（Port-status）。交换机使用此消息通知控制器端口状态发生变化。
  • 数据包输入（Packet-in）。回想一下第4.4节，到达交换机端口且与任何流表条目都不匹配的数据包将被发送到控制器进行额外处理。匹配的数据包也可以被发送到控制器，作为对匹配采取的动作。数据包输入消息用于将这样的数据包发送到控制器。

其他OpenFlow消息在[OpenFlow 2009，ONF 2020]中定义。

5.5.3 数据和控制平面交互：示例 Data and Control Plane Interaction: An Example

为了巩固我们对SDN控制的交换机和SDN控制器之间交互的理解，让我们考虑图5.16所示的示例，其中使用Dijkstra算法(我们在第5.2节学习)来确定最短路径路由。图5.16中的SDN场景与前面第5.2.1节和5.3节中的每个路由器控制场景有两个重要区别，即在每台路由器中实施Dijkstra算法，并在所有网络路由器之间泛洪链路状态更新：

  • Dijkstra的算法在数据包交换机之外作为单独的应用程序执行。
  • 数据包交换机将链路更新发送到SDN控制器，而不是彼此之间。

image.png
Figure 5.16 ♦ SDN controller scenario: Link-state change
图5.16♦SDN控制器场景：链路状态更改
在本例中，我们假设交换机s1和s2之间的链路中断；实施了最短路径路由，因此s1、s3和s4的传入和传出流量转发规则受到影响，但s2的操作没有变化。我们还假设使用OpenFlow作为通信层协议，并且控制平面除了链路状态路由之外不执行任何其他功能。

  1. 交换机s1遇到自身与s2之间的链路故障时，会使用OpenFlow端口状态消息通知SDN控制器链路状态更改。
  2. SDN控制器接收指示链路状态改变的OpenFlow消息，并通知链路状态管理器，后者更新链路状态数据库。
  3. 实现Dijkstra链路状态路由的网络控制应用程序之前已注册，以便在链路状态更改时收到通知。该应用程序接收链路状态更改的通知。
  4. 链路状态路由应用程序与链路状态管理器交互以获取更新的链路状态；它还可能咨询状态管理层中的其他组件。然后，它计算新的最低成本路径。
  5. 然后，链路状态路由应用程序与流表管理器交互，流表管理器确定要更新的流表。
  6. 然后，流表管理器使用OpenFlow协议更新受影响交换机上的流表条目-s1(现在将通过s4路由目的地为s2的数据包)、s2(现在将开始通过中间交换机s4接收来自s1的数据包)和s4(现在必须将目的地为s2的数据包从s1转发到s2)。

此示例很简单，但说明了SDN控制平面如何提供控制平面服务(在本例中为网络层路由)，这些服务以前是通过在每台网络路由器中实施每台路由器的控制来实施的。现在，人们可以很容易地理解启用SDN的ISP如何能够轻松地从成本最低的路径路由切换到更加手工定制的路由方法。事实上，由于控制器可以随心所欲地定制流表，因此它可以实现任何形式的转发—只需更改其应用控制软件即可。这种易于更改的情况应该与传统的每路由器控制平面的情况形成对比，在传统的每路由器控制平面中，所有路由器中的软件(可能由多个独立供应商提供给ISP)都必须更改。

5.5.4 SDN：过去和未来 SDN: Past and Future

虽然对SDN的浓厚兴趣是一个相对较新的现象，但SDN的技术根源，特别是数据和控制层面的分离，要追溯到相当远的地方。2004年，[Feamster 2004，Lakshman 2004，RFC3746]都主张将网络的数据平面和控制平面分离。[van der Merwe 1998]描述了具有多个控制器的ATM网络的控制框架[Black 1995]，每个控制器控制多个ATM交换机。乙烷（Ethane）项目[Casado 2007]率先提出了基于简单流的以太网交换机网络的概念，该网络具有匹配加动作流表、管理流准入和路由以及将不匹配的数据包从交换机转发到控制器的集中式控制器。2007年，一个由300多个乙烷交换机（Ethane switches）组成的网络投入使用。乙烷很快就演变成了OpenFlow项目，剩下的(俗话说)就是历史了！
许多研究工作的目标是开发未来的SDN体系结构和功能。正如我们已经看到的，SDN革命正在导致专用单片交换机和路由器(具有数据和控制平面)被简单的商用交换硬件和复杂的软件控制平面颠覆性地取代。SDN的泛化称为网络功能虚拟化(NFV)(我们在前面的4.5节中讨论过)，类似地旨在用简单的商用服务器、交换和存储来破坏性地替换复杂的中间盒(例如具有专用硬件和用于媒体缓存/服务的专有软件的中间盒)。第二个重要研究领域寻求将SDN概念从AS内扩展到AS间[Gupta 2014]。

PRINCIPLES IN PRACTICE 原则中的实践 SDN CONTROLLER CASE STUDIES: THE OPENDAYLIGHT AND ONOS CONTROLLERS SDN控制器案例研究:opendaylight和onos控制器 在SDN最早的日子里，有一个单一的SDN协议(OpenFlow [McKeown 2008;OpenFlow 2009])和一个SDN控制器(NOX [Gude 2008])。自那以后，SDN控制器的数量尤其显著增长[Kreutz 2015]。有些SDN控制器是公司特有的和专有的，特别是用于控制内部专有网络时(例如，在公司的数据中心内部或之间)。但更多的控制器是开源的，并使用多种编程语言实现[Erickson 2013]。最近，OpenDaylight控制器[OpenDaylight 2020]和ONOS控制器[ONOS 2020]获得了相当大的行业支持。它们都是开源的，正在与Linux基金会合作开发。 The OpenDaylight Controller OpenDaylight控制器 图5.17展示了OpenDaylight (ODL)控制器平台的简化视图[OpenDaylight 2020, Eckel 2017]。 image.png Figure 5.17 ♦ A simplified view of the OpenDaylight controller 图5.17♦OpenDaylight控制器的简化视图 ODL的基本网络功能位于控制器的核心，与我们在图5.15中遇到的网络范围的状态管理功能密切对应。服务抽象层(SAL)是控制器的神经中枢，允许控制器组件和应用程序调用彼此的服务、访问配置和操作数据，并订阅它们生成的事件。SAL还为ODL控制器和被控制设备之间的特定协议提供统一的抽象接口。这些协议包括OpenFlow(我们在第4.5节中介绍过)、简单网络管理协议(SNMP)和网络配置协议(NETCONF)，我们将在第5.7节中介绍这两种协议。OVSDB (Open vSwitch Database Management Protocol)用于管理数据中心交换，是SDN技术的一个重要应用领域。我们将在第6章介绍数据中心网络。 网络编制和应用程序（Network Orchestrations and Applications）决定数据平面转发和其他服务(如防火墙和负载均衡)如何在受控设备中完成。ODL提供了两种应用程序与本地控制器服务(以及设备)以及彼此之间进行互操作的方式。在如图5.17所示的API- driven (AD-SAL)方法中，应用程序使用运行在HTTP上的REST请求-响应API与控制器模块通信。OpenDaylight控制器的最初版本只提供AD-SAL。随着ODL越来越多地用于网络配置和管理，后来的ODL版本引入了模型驱动(model - driven, MD-SAL)方法。这里，YANG数据建模语言[RFC 6020]定义了设备、协议、网络配置和操作状态数据的模型。然后，通过使用NETCONF协议操作这些数据来配置和管理设备。 The ONOS Controller ONOS控制器 图5.18为ONOS控制器ONOS 2020的简化图。与图5.15中的规范控制器类似，ONOS控制器可以划分为三个层:

  • 北向抽象和协议（Northbound abstractions and protocols）。ONOS的一个独特的特性是其意图的框架,它允许应用程序请求一个高层次的服务(例如,设置一个连接主机和主机B之间,或相反不允许主机和主机B通信),而无需知道这个服务是如何执行的细节。状态信息通过北向API同步(通过查询)或异步(通过监听器回调，例如，当网络状态改变时)提供给网络控制应用程序。
  • 分布式核心（Distributed core）。网络的链路、主机和设备的状态维护在ONOS的分布式核心中。ONOS作为一个服务部署在一组相互连接的服务器上，每个服务器运行相同的ONOS软件副本;服务器数量的增加提供了更大的业务能力。ONOS内核提供了实例之间的服务复制和协调机制，为上面的应用程序和下面的网络设备提供了逻辑上集中的核心服务的抽象。
  • 南向抽象和协议（Southbound abstractions and protocols）。南向抽象掩盖了底层主机、链路、交换机和协议的异构性，允许分布式核心既与设备无关，又与协议无关。由于这种抽象，分布式核心下面的南向接口在逻辑上高于图5.14中的规范控制器或图5.17中的ODL控制器。

image.png Figure 5.18 ♦ ONOS controller architecture 图5.18 ♦ ONOS控制器架构的阐述