软件定义网络框架：OpenDaylight
OpenDaylight是一套以社区为主导的开源框架，旨在推动创新实施以及软件定义网络（简称SDN）透明化。面对SDN型 网络，大家需要合适的工具帮助自己管理基础设施，这正是OpenDaylight的专长。作为项目核心，OpenDaylight拥有一套模块化、可插拔 且极为灵活的控制器，这使其能够被部署在任何支持Java的平台之上。这款控制器中还包含一套模块合集，能够执行需要快速完成的网络任务。
SDN无疑是当前网络业界最热门的研究课题之一，SDN体现了控制和转发相分离的原则，为网络和业务的创新带来了蓬勃的生机和活力。本文通过构建 OpenDayLight控制器与Mininet交换模拟器相结合的测试环境，研究了SDN环境下二/三层网络交换的转发机制和特性，并对SDN在网络中 的应用提出了设想。
一.SDN实验环境的选择和建立
软件定义网络(Software Defined Network, SDN)最早由斯坦福大学clean slate研究组提出。SDN的核心是控制与承载相分离，实现网络开放，使流量可以被灵活控制，从而为上层的业务和应用提供更优化的服务。SDN的概念提 出后，迅速得到了各方面的响应，在IT界、网络届掀起了一股热潮。2010年，开放网络基金会ONF成立，ONF致力于开发OpenFlow协议，以规范 控制器与交换机之间南向接口标准化，目前最新发布的版本为1.4。
在控制器方面，借鉴在IT和互联网上的成功经验，开源成为一股不可抵挡的趋势。NOX，POX，Floodlight等均采用公开源代码的形式，任 何人都可以学习SDN，只要有相应的IT编程能力，都可以为SDN的控制器的完善做出贡献。各大设备厂商也正视SDN的挑战，2013年4月IBM、 Cisco、微软、NEC、Juniper、BigSwitch(后退出)等多家IT巨头合作启动了OpenDayLight项目。 OpenDayLight采用JAVA开发，是一套开源的SDN框架。其初期版本已经发布，本次实验使用的就是这个版本。该版本支持简单转发应用 (Simple Forwarding)，可以支持二/三层转发。
光有控制器还不能构成完整SDN网，但当前硬件SDN交换机还很少，也很难找到。幸好有Mininet推出了基于软件模拟的交换机。Mininet 项目也是开源的软件，通过Mininet，在一台Linux主机内可以构造并模拟多台SDN交换机和终端。使用Python脚本，使用者还可以配置较为复 杂的SDN网络拓扑结构。同时Mininet还配备了WireShark抓包软件，方便SDN开发者和学习者进行开发和研究。
二.OpenDayLight SDN二/三层转发机制分析
1)创建和启动SDN网络拓扑结构
在测试中我们创建了如下的网络拓扑结构，1台OpenDayLight控制器(简称Controller，版本为0.1版)，2台交换机(SW)， 每台SW分别连接2台主机(Host)，一共4台主机，这些主机分属于2个不同的网段，交换机与控制器之间采用OpenFlow协议(简称OF)。拓扑结 构如图所示：
图1：测试拓扑结构
首先在测试机(Windows XP系统)上安装和运行OpenDayliht(具体可参考https://wiki.opendaylight.org/view /OpenDaylight_Controller:Installation)，然后在VirtualBox[4]中载入Mininet虚拟机映像并运 行(具体可参考http://mininet.org/download/)。测试网络的拓扑结构由Python脚本生成，可将配置文件保存于虚拟机 /mnt/shared目录下的topo2_2.py文件内：
启动测试环境，使用以下命令生成测试拓扑结构： sudo mn –custom /mnt/shared/topo2_2.py –topo mytopo,–controller=remote ip=192.168.56.1。
通过启动抓包软件WireShark可以看到SW向Controller的注册过程。在注册过程中，Controller会要求SW提供 OpenFlow版本号，设备连接的端口等状态等信息。如图所示：SW1将自己所连接的4个端口情况上报给Controller(其中包括与 Controller相连的端口)，同样SW2也会上报自己的状态。
图2：SW通过OF:Stats Relay向Controller上报自身的状态和接口
当SW 设备完成设备注册后，Controller将进行网络拓扑结构的发现或更新。当网络中有一台新的SW接入后，Controller通过OF Packet Out 指令要求SW1在其所有端口上发出LLDP(Link Layer Discovery Protocol，EEE802.1ab)链路探测包。LLDP的源MAC为Controller分配，这里为00:00:00:00:00:01(对每 一个交换机，Controller都会分配一个这样的MAC作为SW标识)，LLDP目的MAC地址为组播地址。相邻的SW2将接收到LLDP，SW2由 于无法识别这条流，会将OF协议再发到Controller上。通过LLDP的发送和接收，Controller可计算出交换机之间的拓扑关系，网络的拓 扑关系可作为转发流表生成和实现网络可视化的基础。(注：与交换机SW相邻的主机也会收到LLDP，但并不会处理)
图3：基于LLDP探测的网络拓扑发现与计算
2)SDN网络二转发机制
生成网络拓扑后，还要在Controller上为每一个三层网段设置一个网关地址(即使是二层转发也必须设置)，然后将交换机的接口与三层网关相关 联。这里将SW1的2号(连接h1)和SW3的2号口(连接h2)分别与网关10.0.0.254关联，将SW1的3号(连接h3)和SW3的3号口(连 接h4)分别与网关20.0.0.254关联。这一过程好比在SDN内划分了不的三层网段，并将设备物理接口与三层对应，类似为以太网划分VLAN和增加 三层虚接口的过程。
图4：在OpenDayLight Web界面将交换机的端口与三层网关相关联
然后对各个Host的主机IP地址、子网掩码和默认网关进行逐一设置，在Mininet提示符mininet>下如下设置：
接着让Host1 PING Host2，输入h1 ping h2，同时使用抓包软件可得到如下的过程：
图5：OpenDayLight SDN二层转发机制图解
在SDN网络中，处于末端的主机Host并不会知道其连接的网络是SDN，某台主机要发送数据包到另一台主机，仍然需要进行IP到MAC地址的ARP解析。但SDN的处理机制与普通二层以太交换机洪泛+MAC地址学习机制存在却存在很大的差异，其过程如下：
当源主机h1(10.0.0.1)发出ARP解析h2(10.0.0.2)后，交换机SW1并不知道如何转发该包，因此将其通过OF消息发送到Controller处理。
Controller发现这个ARP消息是h1(10,0,0.1)发出，它也同时得到了h1的位置信息(OF包中会指出是哪个交换机的哪个端口发 出了数据包)。此时Controller可以计算网络拓扑，得到全网各节点到10.0.0.1的转发路径，并将转发流表通过OF Flow Modify消息推送到每一台交换机上。
由于收到了ARP，Controller会要求每一台SW所对应10.0.0.0/8网段的非SW互联端口(只有这些端口是连接主机或传统网络的) 发出ARP来请求10.0.0.2的MAC地址。这里Controller并不是简单的将收到ARP原封不动的发出，而是将源IP改为 10.0.0.254，也就是前面我们在Controller上配置的网关IP地址，然后发出。
只有h3(10.0.0.2)才会响应ARP，它将ARP Response发送到SW2。SW2也不知道如何处理，因此将ARP封装在OF协议中发送到Controller。Controller发现这是ARP 响应，而之前正是10.0.0.1发送的ARP请求，因此它会将该ARP通过OF协议发到SW1，同时指示SW1将其送出的端口(也就是h1对应的端 口)。SW1执行这一操作。
Controller在收到h3的ARP后也得知了10.0.0.2的位置，它根据网络拓扑计算，可以得到全网到达10.0.0.2的转发路径，并将流表通过OF Flow Modify消息推送到每一台交换机上。
h1 收到ARP Response后完成ARP解析过程，然后它构造ICMG PING Request数据包，其中源和目MAC分别为h1和h2的MAC，源和目IP分别为h1和h2的IP。由于SW1和SW2都已经成功的装载了到 h2(10.0.0.2)的流表，因此该数据包将被顺利发送到h2。
h2发现是ICMP PING Request，源是h1，但是此时它尚未有h1的MAC，于是还要进行一次ARP解析，SW2再次将ARP发送 Controller，Controller已经得知h1的MAC，可直接响应，并通过OF向SW2返回ARP结果和所需要送出的端口(h2接入的端 口)。
h2学到ARP后，即可构造ICMP Response包，发送到SW2，SW2根据h1目的地址匹配转发表将其转发到SW1，SW1根据h1目的地址匹配转发表将其发送到h1对应的端口。h1到h2的双向通道至此完全打通。
3)SDN网络三层转发机制
在分析完二层转发机制后，我们重新启动拓扑结构，回到初始状态(交换机上无任何流表)，测试一下SDN如何实现两个不同网段主机之间的转发。输入h1 ping h4，同时使用WireShark抓包，可发现如下结果：
对于三层转发，主机首先判断目的IP与自己不在同一网段内，因此要将数据包发向默认网关，在此之前它必须解析网关的MAC。h1发出 ARP，请求网关10.0.0.254的MAC。SW1不知道如何处理，将其通过OF协议发送到Controller。
Controller上配置了网关地址10.0.0.254，它即以自己的MAC地址回应ARP，并指示SW1将ARP响应发送到与h1相连的接 口。同时Controller也知道了h1的存在，通过路径计算，得到每一台交换机去往10.0.0.1的路径，并通过OF Flow Modify将流表推送到每一台交换机上。
主机h1收到网关的ARP，它构造ICMP PING Request数据包，其中源和目MAC分别为h1和网关10.0.0.254的MAC，源和目IP分别为h1和h4的IP，此包发向SW1。
SW1上并没有到达20.0.0.2的流表，因此将缓存这个数据包。同时SW1则也会将该包通过OF协议发送到 Controller，Controlller发现该包是要去向20.0.0.2，而此目的主机位置未知。因此Controller会要求每一台SW的对 应20.0.0.0/8网段的非SW互联端口发出ARP来请求20.0.0.2的MAC地址，其中ARP的源IP为20.0.0.0/8的网关地址 20.0.0.254。
只有h4(20.0.0.2)才会响应ARP，它将ARP Response发送到SW2。SW2不知道如何处理，因此将ARP封装在OF协议中发送到Controller。Controller接到这个ARP响 应，也同时得到了h4的位置是处于SW2的某一端口之下。Controller通过路径计算，得到每一台交换机去往20.0.0.2的流表，并通过OF Flow Modify消息推流表到每一台交换机上。
SW1在装载流表后可向正确的接口上转发之前缓存的ICMP数据包，当然SW2也可顺利转发。SW2还会该ICMP包的目的MAC地址修改为h4的MAC，以确保主机正确接收(之前Controller下发的目的地址10.0.0.1流表中已指出这个操作)。
图6：对20.0.0.2目的地址的流表下发
注：对与主机相邻的交换机SW不仅要指该主机所对应流的出端口，还需要对目的MAC地址进行改写以匹配主机MAC，因此下发的流表内有2个动作(Action)，对于二层转发亦然
此时h4会收到ICMP Request，它发现是不同网段主机发出的ICMP请求，因此仍要通过ARP解析出自己的默认网关。此请求发送到SW2后仍要通过OF协议转发到 Controller，Controller用自己的MAC进行响应，然后通过OF协议发往SW2，并最终发送到h4。
主机h4收到ARP后可构造ICMP PING Response，其中源和目MAC分别为h4和网关20.0.0.254的MAC，源和目IP分别为h4和h1的IP。此包发向SW2，然后经过 SW1，同样SW1在将其转发到目的端口前会将目的MAC地址修改为h1的MAC。之后h1和h4之间的通道被完全打通。
图7：OpenDayLight SDN三层转发机制图解
当网络的所有主机都完成一次的通信后，SDN控制器就感知了所有网络节点的状态。通过控制器提供的界面，可以看到网络的可视化视图(http://192.168.56.1:8080)，与我们之前给出的网络拓扑完全一致!
图8：SDN的网络拓扑，由OpenDayLight SDN控制界面绘出
让我们观察一下各交换机上的流表，可见每个交换机装载了正确的流表。随后SW将定期向Controller汇报流的状态，如匹配流的数量，转发的字节数量、生存时间等。这些流和它们的状态在OpenDayLight的控制台上都可以看到：
SDN内网络交换机的转发流表
4)特殊网络结构下SDN的转发能力分析
在传统的以太网中，是不能存在环路的，即使有环路，网络设备也将通过生成树协议Spanning Tree进行屏蔽。OpenDayLight控制器具有网络拓扑的发现功能，在其算法中也能避免环路的产生(使用的是最短路径优先算法，但在测试中仍无法 支持等价路径负载均衡)。
如图在测试中构建了5台交换机(SW1-SW5)和5台主机(h1-h5)，连成环形拓扑。通过测试表明，主机之间流量转发正常，并没有广播风暴和环路出现，查看各交换机的流表，均显示到目的地址采用的是最短路径。
图9：OpenDayLight SDN支持有环路的二层网络拓扑结构
此外，OpenDayLight控制下的SDN网络还可支持以静态路由方式与外部网络互通，但由于本次测试是基于软件交换机的模拟，因此无法测试该功能。
三、总结
基于对OpenDayLight控制下SDN网络转发行为分析可以看到：
OpenDayLight的简单转发功能以整网的拓扑结构为基础，Controller通过处理主机之间、主机与网关之间的ARP报文来获得每一台主机的位置，并采用最短路径优先算法计算到达目的主机的流表，并下发到网络内的各个交换机上。
在OpenDayLight的简单转发功能中，流仅仅基于目的IP地址进行配，而不是所有的5元组字段以及优先级字段(当然也可以选择5元组)，这点更贴近传统三层设备，可以大大减小了流表的规模，更为贴近实际生产环境。
OpenDayLight不仅可以支持二层转发还可支持三层转发，避免了环路和广播风暴，优于目前其它类型开源SDN控制器所能提供的转发功能。
OpenDayLight实现了控制和承载相分离，网络上已经没有二/三层设备之分，网络充分扁平化。因此在同一SDN内，理论上可以在允许的地址 范围内为主机分配任意可用的IP地址。这种做法解除了主机位置与IP网段物理位置的紧耦合(有点类似LISP，Location-ID Separation Protocol)，避免了IP地址段的碎片不能得到利用的尴尬。同时交换机与交换机之间也无需配置大量互联IP地址，又节约了地址空间。
OpenDayLight支持与外部非SDN网络的二/三层互通。
综上所述，OpenDayLight的基本版已经实现了传统二/三层交换机的基本转发功能，并支持任意网络拓扑和最优路径转发，达到了实用阶段。 2013年年底，OpenDayLight的完整版本将发布，届时将提供更好的多租户支持(Tenant)，更好的网络可视化(Network Virtualization)能力，实现LISP、BGP、Firewall等网络应用，成为一款控制能力足以与传统网络设备匹敌的SDN控制器。
未来网络软件化的趋势将不可阻挡，SDN将在支持数据中心虚拟化、城域网二/三层转发和V*N、网络安全和流量清洗方面大放异彩。