SDN核心技术剖析和实战指南---读书笔记

第一章

SDN定义如下：

SDN是一种新兴的基于软件的网络架构及技术，其最大的特点在于具有松耦合的控制平面与数据平面、支持集中化的网络状态控制、实现底层网络设施对上层应用的透明。

SDN和NFV：

ONF（开发网络基金会）从用户角度定义SDN架构，ETSI（欧洲电信标准化协会）从网络运营商角度出发提出的NFV（网络功能虚拟化）架构。

ONF提出的SDN架构图如下：

分为三层：

应用层---包括各种不同的业务和应用；

控制层---负责处理数据平面资源的编排，维护网络拓扑、状态信息等；

基础设施层---负责数据处理、转发和状态收集。

应用层与控制层通过北向接口API连接，控制层与基础设施层通过南向接口OpenFlow等连接。

ETSI提出的NFV网路架构草案图如下：

NFV相对于SDN的比较：

相同点：都实现了转发层面与控制层面的分离，并在控制层面上提出了类似SDN中应用层的虚拟化架构的管理和编排层。

不同点：NFV在南向接口上，除了ONF倡导的OpenFlow协议之外，还包含了ForCES、PCE-P等之前已经在IETF等传统网络标准化组织中获得认可的接口；NFV将控制层面进行了更细致的划分，提出了端到端的网络控制层。

OpenDaylight开源项目架构图如下：

OpenDaylight开源项目的主要内容包括SDN控制器开发、南北向接口API的扩展、用于多个控制器关联的东西向协议实现等。

SDN三大基本特征：

1.集中控制：逻辑上集中的控制能支持获得网络资源的全局信息并根据业务需求进行资源的全局调配和优化，例如流量工程、负载均衡等。同时，集中控制还使得整个网络可在逻辑上被视作是一台设备进行运行和维护，无须对物理设备进行现场配置，从而提升了网络控制的便捷性。

2.开放接口：通过开放的南向和北向接口，能够实现应用和网路的无缝集成，使得应用能告知网络如何运行才能更好地满足应用的需求，比如业务的带宽、时延需求，计费对路由的影响等。另外，支持用户基于开放接口自行开发网络业务并调用资源，加快新业务的上线周期。

3.网络虚拟化：通过南向接口的统一和开放，屏蔽了底层物理转发设备的差异，实现了底层网络对上层应用的透明化。逻辑网络和物理网络分离后，逻辑网络可以根据业务需要进行配置、迁移，不再受具体设备物理位置的限制。同时，逻辑网络还支持多租户共享，支持租户网络的定制需求。

总之：SDN支持控制平面与转发平面的分离，使得对网络设备的集中控制成为可能。以OpenFlow为代表的南向接口的提出使得底层的转发设备可以被统一控制和管理，而其具体的物理实现将被透明化，从而实现设备的虚拟化。

三种典型的SDN实现方案如下：

1.基于专用接口（硬件和软件紧耦合）：不改变传统网络的实现机制和工作方式，通过对网络设备的操作系统进行升级改造，在网络设备上开发出专用的API接口，管理人员可通过API接口实现网络设备的统一配置管理和下发，改变原先需要一台台设备登录配置的手工操作方式，同时这些接口也可供用户开发网络应用，实现网络设备的可编程。

2.基于叠加网络的方案（逻辑/叠加网络）：以现行的IP网络为基础，在其上建立叠加的逻辑网络，屏蔽掉底层物理网络差异，实现网络资源的虚拟化，使得多个逻辑上彼此隔离的网络分区，以及多种异构的虚拟网络可以在同一共享网路基础设施上共存。主要思想可归结为解耦、独立、控制三个方面如下：

　　1）解耦---将网络的控制从网络物理硬件中脱离出来，交给虚拟化的网络层处理。这个虚拟化的网络层加载在物理网络之上，屏蔽掉底层的物理差异，在虚拟的空间重建整个网络。物理网络资源被泛化成网络能力池

　　2）独立---只要IP可达，相应的虚拟化网络就可以被部署，而无需对原有物理网络架构做出任何改变

　　3）控制---叠加的逻辑网络将以软件即可编程的方式被统一控制

ps:基于叠加网络的方案并不是最近才被提出，VLAN就是典型的代表。在当前的基于叠加网络的SDN实现领域，隧道技术被广泛应用，它可以基于现行的IP网络进行叠加部署，消除传统二层网络的限制。很多新型的协议都采用了隧道的原理进行网络通信，例如VXLAN、NVGRE等，它们均利用叠加在三层网路之上的虚拟网络传递二层数据包，实现了可以跨越三层物理网路哦进行通信的二层逻辑网络，突破了传统二层网路中存在的物理位置受限、VLAN数量有限等障碍，同时还使得网络支持服务的可移动性，大幅度降低管理的成本和运营的风险。

3.基于开放协议（硬件和软件松耦合）

SDN核心技术体系：

OpenFlow解决了如何由控制层把SDN交换所需的用于和数据流做匹配的表项下发给转发层设备的问题，同时ONF还提出OF-CONFIG协议，用于对SDN交换机进行远程配置和管理。

云管理平台案例：OpenStack是可以工作在SDN应用层的云管理平台，通过在其网络资源管理组件中增加SDN管理插件，管理者和使用者可以利用SDN北向解耦便捷地调用SDN控制器对外开放的网络能力。当有云主机组网需求被发出时，相关的网络策略和配置可以在OpenStack管理平台的界面上集中制定并进而驱动SDN控制器统一地自动下发到相关的网络设备上。因此，网络资源可以和服务器资源、存储资源一样，以抽象的资源能力的面貌统一呈现给业务应用开发者，开发者无需针对底层网路设备的差异耗费大量开销从事额外的适配工作。

第二章

传统网络交换设备的典型架构示意图如下：

在传统的网络交换设备中，转发平面和控制平面是紧密耦合的，被集成实现在单独的设备箱中。

转发平面：主要用于对每一个数据报文进行处理，使得它能够通过网络交换设备。这些操作大多采用专门的硬件实现，主要包括转发决策、背板和输出链路调度等功能。

控制平面：主要用于对交换机的转发表或路由器的路由表进行管理，同时负责网络配置、系统管理等方面的操作，与转发平面相比，运行频率较低，可以采用软件实现。

SDN定义了标准的南向接口，用于对网络基础设施层的交换机、路由器等设备进行抽象建模，从而把每台单独的网路设备中的控制平面集中抽取到控制层中，实现底层转发设备的”去智能化“。在SDN网络中，底层负责转发的设备只需要按照基本地保存的转发决策机制进行高速数据转发，而转发决策中的距离策略都由控制层通过南向接口协议统一下发。

交换机的三个基本功能：

1.转发决策---当数据报文到达SDN交换机后 ，数据报头中携带的信息会在交换机转发表，即流表中被查找，如果地址找到，对应的下一跳MAC地址就会被挂接在数据报文的最前端，同时IP数据报文的TTL域递减1，并计算出一个新的校验和

2.背板---数据报文通过背板转发到SDN交换机对应的设备出端口，数据报文需要被加入到一个队列中等待，如果当前的等待队列中没有足够的空间存在，那么数据报文可能会被丢弃或替换掉其他数据报文，占据别的数据报文此前在队列中的位置

3.输出链路调度---当数据报文到达SDN交换机的设备出端口后，它需要按照一定的顺序进行等待，直到它被发出到相应的交换机输出链路上

交换机的三种交换模式：

1.直通---交换机仅对数据帧的前6个字节的信息进行接收和分析，并将数据帧的其余部分直接剪切到出端口上。直通模式具有最小的转发延迟，但是它并不检查数据的完整性，因此可能会把能够导致以太网冲突的”坏包“转发出去，从而产生网络可靠性问题

2.零碎片---交换机首先对数据帧的前64个字节进行接收和解析，再进行转发。这种模式虽然可能造成极少量的”坏包“漏检，但它对网络的整体性能影响不大，又被称为”快速转发“

3.存储转发---交换机需要对整个数据帧的内容进行接收和解析，并开展数据帧的完整性检验等操作，以有效地避免出现错误

SDN交换机的背板：

作用：是数据帧在交换机内部传输的通信通道，携带有转发决策信息及中继管理信息。

两种方式：共享总线机制和交叉开关矩阵机制。

SDN交换机的两种缓冲机制：

1.端口缓冲：每个交换机上的以太网端口有一定数量的高速内存用于缓冲数据帧的到来与转发。该方法的问题是当端口的缓冲被使用殆尽时，其后续接收到的数据帧将被丢弃

2.共享内存：为所有端口提供可以同时访问的共享内存空间用于端口缓冲。该方法将所有接收到的数据帧都保存在共享的内存池中，直到设备出端口准备将其转发到网络中。使用这种方法，交换机能动态分配共享内存，可根据端口流量的大小设定相应的缓冲规模

OpenFlow标准的名称是OpenFlow Switch Specification，因此它本身是一份设备规范，其中规定了作为SDN基础设施层转发设备的OpenFlow交换机的基本组件和功能要求，以及用于由远程控制器对交换机进行控制的OpenFlow协议。

OpenFlow交换机的整体架构图如下：

设计思想：OpenFlow交换机利用基于安全连接的OpenFlow协议与远程控制器相通信。流表是OpenFlow交换机的关键组件，负责数据包的告诉查询和转发。OpenFlow交换机还需通过一个安全通道与外部的控制器进行通信，这个安全通道上传输的是OpenFlow协议，它将负责传递控制器和交换机之间的管理和控制信息。

OpenFlow流表项结构如下：

组成如下：用于数据报匹配的包头域、用于统计匹配数据报的计数器、用于展示匹配的数据包如何处理的动作

ps：OpenFlow交换机的每个流表项可以对应有零至多个动作，如果没有定义转发动作，那么与流表项包头域匹配的数据包将被默认丢弃。如果流表项中出现有OpenFlow交换机不支持的参数值，交换机将向控制器返回相应的出错信息。

OpenFlow流表动作列表如下（分为必备动作和可选动作）：

ps：根据交换机的应用场景及其所能够支持的流表动作类型，OpenFlow交换机可被分为两类：OpenFlow专用交换机（只支持OpenFlow协议）、OpenFlow使能交换机（支持OpenFlow协议和传统的二层/三层协议栈）

OpenFlow交换机中的数据包处理流程如下：

流程：当OpenFlow交换机接收到一个数据包时，将按照优先级一次匹配基本地保存的流表中的表项，并以发生具有最高优先级的匹配表项作为匹配结果，并根据相应的动作对数据包进行操作。一旦匹配成功，对应的计数器将更新；而如果没能找到匹配的表项，则将数据包转发给控制器。

OpenFlow交换机中的数据包头解析和匹配流程如下：

匹配流程：交换机中每一个表项的匹配首先按照接收到数据包的物理端口对入端口进行匹配，然后按照二层数据包头进行比较。如果数据包是VLAN包，则继续查询VLAN ID和PCP域。如果是ARP包，继续查询IP地址和目的IP地址。如果是IP包，则继续查询IP包头的相关域；如果IP包是TCP/UDP包，则需要继续查询传输层端口；如果IP包是ICMP包，则需要继续拆线呢ICMP包中的Type和Code。对于分段数据包的后续包，则将传输层端口设为0后继续查询。

OpenFlow协议：

支持三种消息类型：controller-to-switch、asynchronous、symmetric。具体如下：

OpenFlow标准版本演进示意图：

OpenFlow v1.1交换机结构如下：

相对于v1.0变化：交换机中的流表由单一的流表演变为由流水线串联而成的多流表；增加了组表。

OpenFlow v1.1和v1.2的流表结构如下：

OpenFlow v1.3的流表结构如下：

v1.3的流表结构解释如下：

匹配域---对数据包匹配。包括入端口和数据包报头，以及由前一个表指定的可选的元数据

优先级---流表项的匹配次序

计数器---更新匹配数据包的计数

指令---修改动作集或流水线处理

超时定时器---一个流的最长有效时间或最大空闲时间

Cookie---由控制器选择的不透明数据值。控制器用来过滤流统计数据、流改变和流删除

OpenFlow多流表流水线处理流程如下：

流程：当数据包进入交换机后，将从流表0开始一次 匹配，在后续处理中流表可以按次序从小到大越级跳转，但不能从某一流表向前跳转至编号更小的流表。流表项将以优先级高低的顺序与数据包进行匹配，当数据包成功匹配到一条流表项后，会首先更新该流表项对应的计数器记录的统计数据（如发生成功匹配的数据包数量和总字节数），然后根据流表项中的指令进行相应操作。当数据包已经处于最后一个流表时，其对应的动作集合中的所有动作指令将被执行。

OpenFlow组表结构如下：

ps：利用组表，每个数据流可以被划分到相应的组中，动作指令的执行可以针对属于同一个组标识符的所有数据包，这非常适合于实现广播或多播，或者规定只执行某些特定的操作集。组类型规定了是否所有的动作桶中的指令都会被执行，其定义了如下四种类型：

1）所有：执行所有动作桶中的动作，可用于组播或广播。

2）选择：执行该组中的一个动作桶中的动作，可用于多路径。

3）间接：执行该组的一个确定的动作桶中的动作。

4）快速故障恢复：执行第一个具有有效活动端口的动作桶中的指令。

OpenFlow v1.1多流表匹配流程如下：

OpenFlow v1.1单个数据包匹配流程如下：

ps：如果数据包在流表中没有匹配到流表项，将被称为一个流表失配的行为。在v1.3之前的版本会对没有匹配的数据包做相应处理，而v1.3则专门增建了table-miss流表项，即将没有发生匹配也作为一个匹配表项，由此导致的相应的多流表匹配流程如下：

OpenFlow v1.3多流表匹配流程如下：

OpenFlow交换机之间通过端口在逻辑上相互连接，其支持三种类型的端口：

1.物理端口---与OpenFlow交换机上的硬件接口一一对应。一个OpenFlow物理端口可以对应交换机硬件接口的一个虚拟接口

2.逻辑端口---不直接对应要给交换机的硬件接口。可能支持报文封装并被映射到不同的物理端口上，但其处理动作必须是透明的，即OpenFlow在处理上并不可以区分逻辑端口和物理端口的差异

3.保留端口---用于特定的转发动作，如发送到控制器、洪泛，或使用非OpenFlow的方法转发，如使用传统交换机的处理过程

SDN控制器东西横向扩展需求：

多控制器。多控制器之间为主从关系，可以提供负载均衡能力和快速故障倒换。增加一类角色消息用于控制器之间协商主从关系。控制器的角色在缺省情况下是EQUAL，在此状态下的控制器可以响应来自OpenFlow交换机发来的请求。控制器角色也可以设为SLAVE，在此状态下控制器只负责监听，不响应交换机发送的消息。第三种控制器角色是MASTER，这种状态下的控制器行为与EQUAL类似，唯一的差异在于系统中只能有一台MASTER。因此，一旦网络中有一台控制器的角色转变为MASTER，那么原先处于MASTER角色的控制器就必须转为SLAVE角色，避免角色冲突。

计量器的作用：

计量器可以用于测试数据包的速率并对其实现速率控制。计量器可以直接连接到流表项（而不是连接到端口的队列）上。任意的流表项可以在它的指令集中定义一个计量器，进而由计量器测量和控制与它相连的所有数据流的速率。同一个表中可以使用多个计量器，但必须使用独占方式（即流表项之间没有交集）。通过将多个计量器部署在前后相连的流表上，使其能被用在统一数据集合的转发中。

OpenFlow提出了由控制器向OpenFlow交换机发送流表以控制数据流通过网络所经过的路径的方式，OF-CONFIG规定怎样管理和配置这些网络设备。

OpenFlow与OF-CONFIG的关系如下：

关系：OF-CONFIG的本质是提供一个开放接口用于远程配置和控制OpenFlow交换机，但是它并不会影响到流表的内容和数据转发行为，对实时性也没有太高的要求。诸如构建流表和确定数据流走向等事项将有OpenFlow规范进行规定，而诸如如何在OpenFlow交换机上配置控制器IP地址、如何对交换机的各个端口进行enable/disable操作则由OF-CONFIG协议完成。OpenFlow交换机上所有参与数据转发的软硬件（例如端口、队列）都可被视为网络资源，而OF-CONFIG的作用就是对这些资源进行管理。

OF-CONFIG的目标是在支持OpenFlow v1.2的网络设备上实现以下基本功能配置：

1）配置一至多个控制器的IP地址

2）配置设备的队列、端口等资源

3）支持远程修改设备的端口状态

OF-CONFIG v1.0中定义的OpenFlow v1.2功能配置需求：

OF-CONFIG数据模型：

模型：OF-CONFIG的数据模型主要由类和类属性构成，其核心由OpenFlow配置点对OpenFlow交换机的资源进行配置。在OF-CONFIG v1.0中，定义了OpenFlow端口和OpenFlow队列等两类资源，它们隶属于各个OpenFlow交换机。每个OpenFlow交换机中包含多个逻辑交换机的实例，每个逻辑交换机可以对应一组控制器，同时也可拥有相应的资源。

OVS（Open vSwitch）定义：

OVS是一款基于软件实现的开源虚拟交换机。在虚拟交换机的实现中，其连孤单分别连接这物理网卡和多块虚拟网卡，同时虚拟交换机内部会维护一张映射表，根据MAC地址寻找对应的虚拟机链路进而完成数据转发。

虚拟交换机工作原理如下：

工作原理：当数据包从虚拟机发出后，首先将通过虚拟机上配置的虚拟网卡。虚拟网卡会根据一些既定的规则决定如何处理数据包，例如放行、组个或修改。数据包在被网卡放行后将转发至虚拟交换机，与其他虚拟交换机不同的是，提供了OpenFlow支持能力的OVS将根据自身保存的流表对数据包进行匹配，如果匹配成功则按照相应的指令进行数据包操作，如果匹配未成功则将数据包发给控制器等待相关流表的指定和下发。当数据包需要通过物理网卡转发时，它将会被发送到与虚拟交换机相连的物理网卡上，进而被转发给外部网络设备。

OVS核心架构图如下：

OVS核心架构：OpenFlow协议、数据转发通路。OVS的数据转发通路主要用于执行数据交换工作，即负责从设备入端口接收数据包并依据流表信息对其进行管理，例如将其转发至出端口、丢弃或进行数据包修改。而OVS的OpenFlow协议支持则用于实现交换策略，即通过增加、删除、修改流表项的方式告诉数据转发通路针对不同的数据流采用不同的动作。另外，OVS提供了两种数据转发通路：工作在用户态的慢速通道；利用专门的Linux内核模块的快速通道。

OVS核心组件及其关联关系：

用户空间：拥有多个组件，主要负责用于实现数据交换和OpenFlow流表功能，是OVS的核心

核心组件：OVS提供一些工具用于交换机管理、数据库搭建，以及和内核组件交互。

ovs-vswitchd：实现OpenFlow交换机的核心功能，并通过netlink协议直接和OVS的内核模块进行通信。交换机运行过程中，ovs-vswitchd还会将交换机的配置、数据流信息及其变化保存到数据ovsdb中，因为这个数据库由ovsdb-server直接管理，所以ovs-vswitchd需要和ovsdb-server通过UNIX socket机制进行通信以获得或这保存配置信息。数据库ovsdb的存在，使得OVS交换机的配置能被持久化存储，即便设备被重启后相关的OVS配置仍旧能存在。

ovs-vsctl：是一个用于交换机管理的基本工具，它需要直接和ovs-vswitchd通信，能支持很多管理操作，用户可以登录到交换机部署的服务器上通过ovs-vsctl管理OVS交换机。同时，ovs-appctl组件也是一个管理工具，通过发送一些内部命令给ovs-vswitchd组件以改变其配置。另外，在一些情况下，用户可能会需要自行管理运行在内核中的数据通路，那么也可以通过调用ovs-dpctl驱使ovs-vswitchd在不依赖于数据库的情况下去管理内核空间中的数据通路。

当用户需要和ovsdb-server通信以进行一些数据库操作时，可以通过运行ovsdb-client组件访问ovsdb-server，或者直接使用ovsdb-tool而不经ovsdb-server就对ovsdb数据库进行操作。

ovs-ofctl：在OVS实现中，OpenFlow是用于管理交换机流表的协议。通过使用ovs-ofctl，用户可以使用OpenFlow去连接交换机并在远程开展监控和管理。

第三章

控制器的南向网络控制技术：

包括通过南向接口协议进行链路发现、拓扑管理、策略制定、表项下发等。其中链路发现和拓扑管理主要是控制器利用南向接口的上行通道对底层交换设备上报信息进行统一监控和统计的技术，而策略制定和表项下发则是控制器利用南向接口的下行通道对网络设备实施统一控制的技术。

链路发现技术：

SDN控制器主要使用LLDP（链路层发现协议）作为链路发现协议，该协议提供了一种标准的链路发现方式，可以将本端设备的主要能力、管理地址、设备标识、接口标识等信息组织成不同的TLV，并封装在LLDPDU（链路层发现协议数据单元）中发布给与自己直连的了邻居，邻居收到这些信息后将其以标准MIB（管理信息库）的形式保存起来，以供网络管理系统查询及判断链路的通信状况。

SDN控制器的链路发现过程如下：

发现过程：控制器在执行链路发现过程时，会首先通过一个Packet_out消息向所有与之相连接的交换机发送LLDP数据包，该消息命令交换机将LLDP数据包发送给所有端口，一旦交换机收到Packet_out消息，它就会把LLDP数据包通过其所有的端口发送给其他与之连接的设备。如果其邻居交换机是一台OpenFlow交换机，那么该交换机将执行相应的流表查找操作。因为交换机中并没有专门的流表项用于处理LLDP消息，所以它将通过一个Packet_in消息将数据包发送给控制器。而控制器在接收到Packet_in消息后，会对数据包进行分析并在其保存的链路发现表中创建两台交换机之间的额链接记录。网络中其他交换机也都将采用与上述过程相同的方式向控制器发送Packet_in消息，因此控制器将能够创建出完备的网络拓扑视图。

判断网络中是否存在非OpenFlow域：

基于LLDP消息的方法只能对与控制器直连的OpenFlow交换机进行链路发现，如果网络中还存在其他的非OpenFlow域，即两台OpenFlow交换机之间可能会通过其他的一台或多台非OpenFlow交换机相连。在这种情况下，控制器会首先发送Packet_out消息给与之相连的OpenFlow交换机，但同时控制器会要求交换机发出广播包，广播包将被发往除交换机与控制器相连的端口之外的其他所有端口。广播包从OpenFlow交换机发出后，如果网络中存在非OpenFlow域，那么广播包将从这个网络域的一端进入并穿越，进而到达与该非OpenFlow域连接的其他OpenFlow交换机。因为在接收到广播包的OpenFlow交换机中并没有相应的流表项可供广播包匹配，所以该广播包将会被上传给控制器，从而达到告知控制器在网络中存在有非OpenFlow域的目的。如果控制器并没有收到上传的广播包，那么就可以判断出整个网络都由OpenFlow交换机构成。

拓扑管理技术的作用：

1.随时监控和采集网络中SDN交换机的信息，及时反馈网络的设备工作状态和链路连接状态。为了实现这一目标，控制器需要通过定时地发送包含LLDP数据包的Packet_out消息给与其相连接的SDN交换机并根据反馈回来的Packet_in消息获知交换机信息，在监测交换机工作状态的同时完成网络拓扑视图的更新。

2.在随时更新SDN交换机及其链接状态的同时，对各种逻辑组网信息进行记录，其中最典型的场景是云计算环境下的多租户共享网络资源。在多租户情况下，网络资源被虚拟化为资源池，每个租户都可以按其实际需求获得设备、端口、带宽等网络资源，同时还可以根据自身需求对其所有的资源进行灵活组网。这些与租户网络相关的资源信息都需要在拓扑管理中给与保存和展现，以反映真实的网络利用情况，实现优化的资源调度。

策略制定和表项下发技术：

SDN交换机中的流表机制打破了传统网络中的层次化概念，无论是源MAC、目的MAC、VLAN ID等传统的二层网络信息，还是源IP、目的IP等传统的三层网络信息，抑或源TCP/UDP端口、目的TCP/UDP端口等传统的四层网络信息，都被统一封装到一个流表项中。因此，控制器需要针对不同层次上的网络传输需求，制定相应的转发策略并生成对应的流表项下发给交换机。具体思路如下：

1）二层网路数据转发：传统设备的主要工作是MAC地址学习和基于MAC地址的数据包转发。而在SDN网络中，MAC地址学习已经在控制器的链路发现过程中实现，而根据二层网路哦信息（如MAC地址）进行数据包转发也比较容易实现，只需要控制器以目的MAC地址为依据将对应的交换机转发端口号写入相应交换机的流表项中即可

2）三层网路数据转发：传统设备通常采用“一次路由多次转发”的机制，即交换设备在接收到来自源IP的数据包后，查询路由表确定到达目的IP的路由，并通过一定的识别触发机制确立和记录源MAC地址与目的MAC地址以及转发端口的对应关系，后续在源和目的之间产生的通信将由二层模块直接处理。在SDN网络中，其核心是控制器利用相关的路由算法计算出源和目的之间的路由信息，并以IP地址、MAC地址为依据将对应的交换机转发端口号写入相应交换机的流表项中。

3）四层网络数据转发：传统设备的实现通常需要维护一个连接表用于保存与业务应用服务器相对应的源IP、源TCP/UDP端口等信息。在SDN网路中，四层数据解析将在控制器中完成，并以TCP/UDP端口号、IP地址和MAC地址为依据将对应的交换机转发端口号写入相应交换机的流表项中。

SDN控制器的流表下发的两种模式：

1.主动：在数据包到达OpenFlow交换机之前就进行流表设置，当第一个数据包到达交换机后，交换机就已经直到该如何处理数据包了，这种方式有效消除了数据传输过程中的流表项设置延迟。同时，不存在控制器每秒钟能够处理的流数量的限制。在理想情况下，控制器需要尽可能地预扩散流表项。

2.被动：当OpenFlow交换机接收到一个数据包并且没有发现与之匹配的流表项时，只能将其送给控制器处理。一旦控制器去欸的那个了相应的处理方式，那么相关的信息就会返回并缓存在交换机上，同时控制器将确定这些缓存信息的保存时限。

两种下发模式的比较：主动的流表下发利用预先设定好的规则，避免每次针对各个数据流的流表项设置工作，但考虑到数据流的多样性，为了保证每个流都被转发，流表项的管理工作将变得复杂，例如需要合理设置通配符满足转发要求。被动的流表下发能够更有效地利用交换机上的流表存储资源，但在处理过程中，会增加额外的流表设置时间，同时一旦控制器和交换机之间的连接被断开，交换机将不能对后续到达的数据流进行转发处理。

北向接口技术REST API的四个特征：

1）可寻址性强：每个片段都应该有自己的URI，并且URI应具有良好的可读性。

2）接口无状态：服务器不会根据之前的访问行为来约束后续的动作，除非某些行为已经影响到了服务器资源。

3）注重关联性：应用应该能够根据用户发来的请求，自动地在反馈的信息中尽可能地包含与请求相关的全部资源链接，以允许用户在无需理解所有URI对应的资源的前提下从应用反馈的信息中选取可用资源。

4）接口要统一：web服务应当拥有统一的资源编址及表述方案。其中，统一编址需要在对资源相关的URI进行准确描述的基础上，使用标准的HTTP请求方法（GET、POST、PUT、DELETE）；统一表述需要利用标准化的编码机制（如XML），同时，访问错误处理也应当使用标准化的HTTP相应编码。

东西向控制技术扩展：

基于控制器集群的SDN架构：

ps：控制器的软件化使得服务器可以作为控制器的载体，控制器可以以服务器集群为基础进行搭建。控制器集群要能支持向正在运行的集群中增加新的控制器以改善扩展性、保存失效控制器对应的交换状态以保证可靠性。

保证控制器集群对SDN网络的控制的两个设计点：

1.主控制器的选举：主控制器主要负责生成和维护全网范围内的控制器和交换机的状态信息，一旦它出现失效，就需要从集群中的副控制器中选举一个新的主控制器以避免单点失效。

2.控制器集群对交换机的透明化：在SDN网络的运行过程中，交换机无需关心它当前接收的是哪台控制器发来的控制指令，同时在其向控制器发送数据包时，能继续保持之前单一控制器时的操作方式，从而保证控制器在逻辑上的集中。

SDN控制器的设计要素：

业界主要开源SDN控制器信息：

Floodlight软件架构：

控制器模块：用于实现SDN核心网络服务

应用模块：针对不同业务应用实现解决方案。

控制器模块提供了Java API供应用模块调用，同时两类模块还共同支持向上层开放REST API作为北向接口。

Floodlight主要控制器模块：

四类功能如下：

1）发现和揭示网络状态及相关事件（如拓扑、设备、流）

2）支持控制器和网络交换机的通信（如OpenFlow协议）

3）管理Floodlight模块及模块共享的资源（如存储、线程、测试）

4）提供Web UI和调试服务（如提供Jython接口）

ps：FloodlightProvider将作为核心模块首先在Floodlight的启动过程中被运行，它将收到的OpenFlow数据包转换为一个个事件。同时，其他的模块将向FloodlightProvider进行注册，进而称为一个服务，然后就可以处理相应事件了。

Floodlight的部分应用模块：

第四章

SDN应用分类及其与控制器的关系：

SDN中主要三类应用：

1）资源管理平台：主要是面向云计算资源统一管理和调配的平台，其目标是实现池化的计算、存储、网络等资源的灵活交付，按需满足云计算业务的资源需求。

2）软件定义的应用交付：基于SDN理念改造负载均衡、访问控制、应用加速等应用交付技术，使之能替换或扩展此前在传统网络中需要利用专用硬件实现的功能

3）创新网络业务：在传统的静态化网络中难以实现，但在SDN环境下能获得良好支持的新兴业务，这类应用具有非常大的创新空间

典型的SDN资源管理平台架构图如下：

资源管理平台的核心：基于SDN控制器北向接口编排资源管理流程，使得它能及时有效地将上层云计算业务的资源需求反馈给控制器并对网络设备和链路进行调配。考虑到云计算等典型业务通常需要计算、存储、网络等多种类型资源的协同交付，因此对SDN控制能力的调用需要被封装为独立的组件，并与相应计算资源空控件组件、存储资源控制组件，以及其他一些功能组件共同工作。当前云计算也普遍是以计算资源为核心的服务，随着网络资源管理灵活性和便利性的提升，日后势必会有越来越多以网络资源为核心的云计算服务被提出和应用。

软件定义应用交付与传统网络应用交付的比较：

ps：在传统网络中，类似防火墙、负载均衡、入侵检测等网络应用都是由专用的硬件设备实现的，在网络运行过程中，根据实际需要逐台进行配置以满足数据传输要求。而在SDN网络中，上述应用将以软件程序的方式存在，它们可以与控制器一起部署在通用服务器上，通过调用控制器的北向接口获得其提供的流量模式、应用数据等信息并对其进行辨识和判断，进而驱动控制器洗发指令调整网络配置。例如，当基于SDN的入侵监测应用在控制器监测的数据流中识别到恶意流量时，它就可以自动驱动控制器设置相应的流表项将这些数据包导向网络中部署的安全隔离设备，避免其对网络的破坏。

面向SDN的网络应用交付技术的改造从四个方面进行：

1）改写传统的硬件应用为软件实现

2）支持网络应用的虚拟化实现和部署

3）基于控制器北向接口改造应用

4）开放编程接口支持创新业务开发

OpenStack总体架构和其七大核心组件之间的关系图：