基于OpenFlow的SDN架构研究与实践

于天放，芮兰兰

(北京邮电大学 网络与交换技术国家重点实验室，北京 100876)

0 引 言

随着IT技术的高速发展，云计算、虚拟化等新兴业务的不断涌现，对网络的承载能力提出了更高的要求。在传统网络中，控制平面功能是分散地运行在各个节点中，控制逻辑和数据转发被紧耦合在网络设备上，这种分布式的控制方式增加了网络管理的难度，不仅带来了网络互操作性的问题，而且难以开展基于真实网络流量的新技术研究和实验。SDN[1]和OpenFlow[2]的理念就是在上述背景下得以快速发展的。SDN的基本思想是采用相互分离的控制平面和转发平面，通过将控制功能抽象到控制平面中实现集中化的网络状态控制，同时为用户提供开放式可编程接口，使得用户能够根据上层业务需求对网络资源进行灵活调度。OpenFlow是SDN控制器与交换机之间的主要通信协议[3]，其规定了OpenFlow交换机的基本组件与性能要求，为实现网络设备的数据转发与路由控制的解耦合提供了一种全新的方法。

文中首先介绍了SDN的发展现状以及基于OpenFlow的SDN架构实现方案。在此基础上，详细探讨了OpenFlow协议下的底层网络拓扑发现机制和网络性能监测机制，并搭建了实验平台进行仿真实践。

1 SDN发展现状及实现方案

1.1 SDN与OpenFlow的发展历程

SDN的前身来自于斯坦福大学提出的用于企业集中安全控制的Ethane[4]架构。该架构在链路层和网络层之间定义了一个保护层，由一台逻辑中央控制器对网络主机进行安全绑定和认证。研究人员可以定义基于网络流的安全策略，并将这些策略运用在各种网络设备上，由控制器对每个流检测是否违反了相关的策略，并为每个流确定路由。

在上述相关工作基础上，Nick Mckeown教授等提出了OpenFlow概念。OpenFlow定义了控制器与OpenFlow交换机之间的通信协议，允许控制器来决定网络数据流的路径，并且能够实现细粒度的数据包优先级划分和创建端口级别的流量控制规则。OpenFlow技术后经由Clean State项目的不断推广，以及在GENI计划中的应用，逐渐发展为SDN。2011年，Google、Microsoft等企业联合成立了开放网络基金会联盟，共同致力于推动SDN技术的发展，并进行相关标准制定和市场推广，使其成为全球开放网络架构与网络虚拟化领域的研究热点。

1.2 基于OpenFlow的实现方案

基于OpenFlow的SDN架构由控制器和OpenFlow交换机(文中简称为OF交换机)构成。OF交换机的功能包括安全通道、组表、多级流表和OpenFlow协议等几个部分。

安全通道是连接控制器和OF交换机的接口，控制器通过该接口对OF交换机进行管理和控制。安全通道采用TLS(transport layer security)技术对控制器和OF交换机之间的控制和管理信息进行加密传输。

OF交换机进行数据转发的依据是流表，多个流表串联起来形成流水线，流水线对数据包的处理过程如图1所示。

图1 多级流表的数据包匹配过程

当数据包进入交换机后，将从流表1开始匹配。流表中的表项按照优先级的高低依次与数据包进行匹配，当匹配到一条表项时，会触发该表项指令集的执行，这些指令会进行计数器的更新、修改数据包的动作集合等操作。当数据包跳转到最后一个流表时，如果不存在匹配项，则该数据包将转发给控制器，否则，执行数据包对应的动作集合中所有的动作指令。

OF交换机中的组表可以将每个数据流划分到相应的组中，对属于同一组标识的所有数据包执行相同的动作集，从而实现广播和多播功能。

2 基于OpenFlow的拓扑发现机制

2.1 链路层发现协议

链路层发现协议[5](link layer discovery protocol，LLDP)是802.1ab中定义的链路层协议，它的帧格式包括目的MAC地址、源MAC地址、帧类型、链路层发现协议数据单元(link layer discovery protocol data unit，LLDPDU)以及校验位等字段。其中，LLDPDU字段用于承载要发送的消息，基本的信息单元采用TLV(Type-length-value)形式表示，TLV类型如表1所示。

表1 基本的TLV类型

LLDP将本地设备的主要功能、设备编码、管理地址和接口标识等信息构造成TLV封装在LLDPDU中，周期性地发送给邻居设备，同时将从邻居设备接收的LLDPDU以标准的管理信息库(management information base，MIB)形式进行存储。网络管理程序可以通过SNMP[6](simple network management protocol)协议访问获取这些信息，从而发现和模拟网络拓扑结构。

2.2 OF交换机发现机制

OpenFlow协议允许一台交换机同时连接多个控制器，因此，当交换机启动时会进行主控制器和从属控制器的IP地址和TCP端口的初始化设置。文中仅讨论单控制器的情形。控制器和OF交换机通过建立TLS会话实现OpenFlow消息的传递，具体的流程描述如下:

步骤1：安全通道的建立。

OF交换机首先尝试连接控制器默认开启的TCP 6633端口，并和控制器交换证书进行认证。当认证通过后，双方通过发送OFPT_HELLO消息确认能够支持的OpenFlow协议版本进而建立安全通道。

步骤2：OF交换机的发现。

安全通道成功建立后，控制器将向OF交换机发送OFPT_FEATURES_REQUEST消息要求交换机上报自己的功能特性。OF交换机则用OFPT_FEATURES_REPLY消息回复控制器，消息中包含了交换机的DPID(DATA path identity)、所支持的流表数、可用的端口和端口的MAC地址等信息。至此，控制器就可以精确掌握成功连接到网络的交换机信息。

2.3 OpenFlow链路发现机制

依据初始化阶段获得的OF交换机信息，控制器为每个OF交换机的所有可用端口发送一个OFPT_PACKET_OUT消息。该消息携带了一个LLDP数据包，数据包由Chassis ID和Port ID构成。交换机收到消息后按照Port ID将消息转发给相邻的交换机，邻居交换机将消息中的LLDP数据包连同本身的元数据一起封装到OFPT_PACKET_IN消息中发送给控制器，控制器对收到的消息进行解析，得出交换机之间的链接关系，同时进行网络拓扑状态的更新操作。

假设网络由M个OF交换机构成，每个交换机的可用端口数为N，交换机之间的连接数为H，则控制器需要发送的OFPT_PACKET_OUT消息数为：

(1)

控制器完成网络中所有OF交换机之间链路发现过程需要接收的OFPT_PACKET_IN消息数为：

SUMpacket-in=2H

(2)

图2 基于LLDP的链路发现过程

图2为控制器进行链路发现的具体过程。控制器通过OFPT_PACKET_OUT消息向交换机S1的Port1、Port2和Port3端口各发送一个LLDP数据包，交换机S1按照Port ID分别将数据包在相应的端口转发给邻居交换机。以Port2端口为例，交换机S1将LLDP数据包通过Port2端口转发给交换机S2的Port3端口，按照初始的流规则定义，除去交换机的Controller端口外的所有端口只要收到LLDP数据包都转发给控制器，因此交换机S2将收到的LLDP数据包连同自己的元数据一起封装到OFPT_PACKET_IN消息并发送给控制器。控制器对该消息进行解析，得到如下转发信息：①LLDPDU：{Chassis ID=S1，Port ID=Port2}；②Meta-Data：{Chassis ID=S2，Port ID=Port3}。根据这些信息，控制器能够确定交换机S1和S2之间存在链路关系。

3 基于OpenFlow的网络性能监测机制

3.1 网络QoS的主要性能指标

网络QoS用于为指定的网络通信提供更好的服务能力，它可以用一系列可度量的指标来描述。

(1)吞吐量:对于网络、端口或其他设施，单位时间内成功传送的数据量。

(2)时延：数据包从链路的一端传送到另一端所需要的时间。

(3)丢包率：在数据传输过程中，丢失的数据包数与所有传送数据包数的比率。

3.2 OpenFlow网络的性能监测

在OpenFlow网络中，控制器定期向OF交换机发送OFPT_STATS_REQUEST消息，该消息中的Type字段定义了多种类型的请求信息，包括单流、多流、流表、端口和队列等。控制器通过交换机回复的OFPT_STATS_REPLY消息获取不同类型请求的计数信息，根据这些信息，控制器能够计算出吞吐量、时延和丢包率等性能指标。

3.2.1 吞吐量测量分析

OF交换机向控制器回复的单流类型OFPT_STATS_REPLY消息是数据流吞吐量测量的依据。该消息的结构如下：

struct ofp_flow_stats{

…

uint32_t duration_sec; //数据流持续时间

uint32_t duration_nsec; //数据流额外生存时间

…

uint64_t packet_count; //已发送的数据包数

uint64_t byte_count; //已发送的字节数

…

}

控制器在T1时刻和T2时刻分别统计数据流发送的字节数和持续活动时间，通过求得T2-T1时间间隔内的数据增量，进而计算出数据流的吞吐量值，用公式表达为：

(3)

3.2.2 链路时延测量分析

链路时延测量的过程用图2加以说明。

(1)控制器到交换机的时延。

控制器分别向交换机S1和S2发送带有时间戳的OFPT_ECHO_REQUEST消息，交换机S1和S2收到消息后即刻向控制器回复带有时间戳的OFPT_ECHO_REPLY消息，控制器利用前后两个时间戳的差值计算得到控制器到交换机S1和S2的往返时延[7](round-trip time，RTT)，记为RTT1和RTT2。

(2)交换机间的链路时延。

首先，控制器产生一个可以识别的时延探测包下发到交换机S1，探测包的数据段携带着控制器下发探测包的时间戳。交换机S1将探测包通过Port2端口转发给交换机S2，交换机S2将探测包封装到OFPT_PACKET_IN消息通过Port3端口发送给控制器。控制器收到消息后，对当前时间与探测包中的时间戳求差值，记为Ta。同理，控制器向交换机S2发送探测包，重复上述过程，所求得的时间差值记为Tb。由控制器链路发现过程可知，Ta与Tb之和等于RTT1、RTT2、RTTS1-S2三者之和，因此，交换机S1与S2之间的链路单向时延可表示为：

(4)

3.2.3 丢包率测量分析

当控制器向OF交换机发起端口状态请求信息时，OF交换机回复的OFPT_STATS_REPLY消息中包含了端口发送和接收的数据包数、出错的数据包数等信息。端口类型的OFPT_STATS_REPLY消息结构如下：

struct ofp_port_stats{

…

uint64_t rx_packets; //已接收的数据包数

uint64_t tx_packets; //已发送的数据包数

…

uint64_t rx_dropped; //接收时丢弃的数据包数

uint64_t tx_dropped; //发送时丢弃的数据包数

…

}

根据这些信息，控制器就能够计算出具体的丢包率值，用公式表达为：

(5)

4 实验环境搭建与仿真分析

采用Floodlight[8]和Mininet[9]搭建一个小型SDN网络，便于进一步理解控制器和OF交换机之间的工作机制。

4.1 仿真拓扑

Mininet与Linux系统完全兼容，可以快速部署到硬件环境中，其内置的OVS(Open vSwitch)虚拟交换机能够模拟出包含多终端和网络设备的复杂大规模计算机网络。在本例中，采用Mininet虚拟一个包含三个主机节点、一个OF交换机和一个远程控制器的拓扑结构，如图3所示。启动网络包分析工具Wireshark[10]，能够看到控制器和交换机之间定时发送的OF_ECHO_REQUEST和OF_ECHO_REPLY消息。在Mininet命令行界面运行“pingall”命令，执行结果如下：

h1→h2h3

h2→h1h3

h3→h1h2

由上述结果可知，在初始阶段，主机间处于相互连通状态。

图3 Mininet创建的拓扑结构

Floodlight控制器中的LinkDiscoverManager模块实现链路发现功能，该模块通过向OVS交换机下发LLDP数据包和BDDP(broadcast domain discovery protocol)数据包来获取网络中每条链路的信息。TopologyManager模块监听LinkDiscoverManager模块的更新信息，如果有链路状态更新，则采用Dijkstra算法[11]进行节点间的路径计算并生成对应的拓扑实例。

由于Floodlight控制器中负责流表下发的Forwarding模块采用了反应式流表安装方法，当数据包到达OVS交换机后，初始状态下交换机内没有任何匹配的流，则Forwarding模块产生一些临时流表指导数据包继续转发。因此，当执行“pingall”命令后，主机之间依然能够通信。除了上述反应式流表模式，Floodlight控制器还支持静态流表写入方法(static flow pusher)。定义一条测试流规则实现H1到H2之间的链路不可达，流规则描述如下：

FlowTable(H1- H2)={

"switch":"00:00:00:00:00:00:00:01",

"cookie":"0",

"priority":"2",

"ingress-port":"1",

"active":"true",

"actions":" output=3"

}

通过curl命令将该流规则安装到控制器中，并再次运行“pingall”命令，测试结果如下：

h1→xh3

h2→xh3

h3→h1h2

在Floodlight的UI页面能够看到命令执行过程中OVS交换机各端口的流量统计数据，如表2所示。流规则通过控制器的8080端口所支持的REST[12](representational state transfer)接口下发到OVS交换机中，H1到H2之间的链路执行“数据包直接丢弃”策略，因此无法ping通。H1到H3以及H2到H3之间的链路执行“数据包正常转发”策略，因此链路是可达的。

表2 OVS交换机不同端口的数据统计

4.2 网络性能监测实验与分析

(1)吞吐量测量。

采用网络性能测试工具iperf[13]以不同的速率发送UDP[14](user datagram protocol)数据包进行测量。选择H1到H3之间的链路作为测试路径，链路带宽设置为100 M，时延为10 ms。iperf发包速率变化范围设置为10～80 Mbps，共进行8次测试，每次测试时间为60 s。测试OVS交换机在不同的负载流量速率下的吞吐量，测试结果如图4(a)所示。由图可见，随着负载流量的不断增大，链路吞吐量也随之增大，当负载流量超过40 Mbps时，吞吐量维持在23 Mbps左右，是因为OVS交换机在进行查找流表并转发UDP数据包时，在交换机的缓冲队列中存在大量的数据包导致队列溢出而被丢弃。

(2)链路时延测量。

利用Ping命令测试不同大小的数据包对链路时延的影响。选择H2到H3之间的链路作为测试路径，链路带宽设置为10 M，数据包大小变化范围设置为200～1 400 Byte，共进行5次测试，每次测试发送数据包数为5个，取平均时延值，测试结果如图4(b)所示。

图4(b)中的时延离差反映了数据包的往返时延距离平均时延的偏离程度，该值越大，表明响应时间的变化范围越大。当发送200 Byte的数据包时，H2首先通过OFPT_PACKET_IN消息向控制器发送ICMP[15](Internet control message protocol)报文，控制器收到该报文后，添加流规则定义将该报文转发到H3。H3收到报文后，同样经过OFPT_PACKET_IN消息向控制器发送ECHO回显应答消息，该消息最终被转发给H2。至此，一个Ping命令的通信过程结束。上述过程的执行影响了数据包的往返时延，由于交换机中已存在相应的流规则，因此，后续发包的平均时延显著减少，趋于平稳状态。

(3)丢包率测量。

利用iperf工具传输不同长度的字节数进行链路丢包率的测量。选择H1到H2之间的链路作为测试路径，链路带宽设置为100 M，时延为10 ms，发包速率设置为20 Mbps。待传输的字节数长度范围设置为20～100 MB，共进行5次测试，测试结果如图4(c)所示。由图4(c)可见，所测得的丢包率值均在2%以下，说明网络处于正常状态。当传输数据量为60 MB时，丢包率陡然上升，表明网络拥塞程度增大。当传输数据量为100 MB时，丢包率达到峰值，此时OVS交换机端口缓冲区队列溢出大量数据包被丢弃，在这种过载的状态下，网络性能出现大幅下降。

(a)不同负载流量下的UDP吞吐量

(b)不同大小数据包的平均时延

(c)传输不同长度数据的丢包率

5 结束语

SDN是一种数据控制分离、具有灵活软件编程能力的新型网络架构，它通过提供开放式接口，实现对网络状态的集中控制并根据业务需求进行资源的全局调配和优化。文中介绍了SDN的主要实现方式OpenFlow技术，详细探讨了基于OpenFlow协议的链路发现机制和网络性能监测机制并搭建了基于Floodlight和Mininet的实验平台进行仿真测试。SDN网络的目标是服务于多样化的业务应用创新，因此，在下一步的工作中，主要开展SDN应用编排与资源管理技术的研究。