张俊帅,杨 昊

(中国计量学院 信息工程学院,浙江 杭州 310018)

OpenFlow交换机流表转发设计与实现

张俊帅,杨 昊

(中国计量学院 信息工程学院,浙江 杭州 310018)

在传统网络中,交换机和路由器的信息以不同的形式(MAC表、路由表等)进行存储,需要在整个网络中通过非常复杂的交换和路由协议进行计算才能得到.根据这些不同的表,可以对数据平面进行指令操作.OpenFlow协议将协议规范化和集中化,通过控制器管理流表代替其他所有转发的转发表项,相对传统网络而言,它具有表项单一、过程简单且有着相当大的优势,是未来网络发展的必然趋势.流表贯穿整个网络并且是网络能够正常工作的核心，流量的转发过程将影响到整个网络,并详细介绍了流表的转发过程,包括vxlan转发、同OVS流量转发以及跨OVS流量转发.

OpenFlow协议;流表;vxlan转发;同OVS流量转发;跨OVS流量转发

软件定义网络(SDN)作为新型网络创新架构,其核心思想是将控制平面和数据平面分离,由一个控制平面统一指挥数据平面,共同完成网络中的数据传输;网络设备只需要负责数据包的转发,复杂的网络控制功能交由控制器集中处理.在越来越复杂的网络环境下,一台普通的网络设备将有300多个功能模块、近万个协议,软硬件集成度高、设计复杂,“控制转发分离”“转发设备傻瓜化”将极大地简化网络的规划设计和设备制造,而用户也只需要对一个或少数几个控制节点进行管理即可完成对全网的运行和维护,运维成本得以大大降低.而OpenFlow是这套体系正常运做的基石.OpenFlow协议是一个基于一定标准的开放协议,建立了控制平面与数据平面交互的标准[1].控制平面和数据平面建立连接之后,数据平面上报端口状态,控制平面向数据平面添加或删除流表项都需要通过OpenFlow来完成.可以说OpenFlow协议是SDN体系中流量转发的核心部分[2].

图1 OpenFlow组件Figure 1 OpenFlow module

OpenFlow交换机和控制器共同完成原本完全需要由交换机和路由器控制的报文转发过程,从而达到数据转发与路由控制分离的目的[3].数据转发由控制器通过规定的接口操作来控制OpenFlow交换机中的流表.如图1,OpenFlow最重要的组件是:OpenFlow控制器(Controller),OpenFlow交换机(OVS),OpenFlow协议[4].Controller是所有基于OpenFlow软件定义网络(SDN)的核心.Controller运行于控制平面,并通过控制平面逻辑对网络交换机中的流进行指令操作.Controller运行在服务器上,以此来保证所有OVS都可以访问,管理员或者用户可以通过用户界面以及控制功能对整个网络进行实时控制,从而大大的方便了操作[5].如果流表中没有列出新的事件发生,OVS将向Controller发出请求.OVS与Controller进行连接,对流表进行分析和安装,所有的OVS均由Controller统一管理和配置,贯穿整个网络的只有单一的一种表项即流表.

1 流 表

流表是OpenFlow最重要的组成部分,相当于常规的MAC表和路由表,每个流表由许多流表项组成,流表项则代表转发规则,进入交换机的数据包通过查询流表项来取得对应的操作[6].所谓流表,其实可以看作是OpenFlow对网络设备的数据转发功能进行的一种抽象.在传统的网络设备中,交换机和路由器的数据转发需要依赖设备中保存的二层MAC地址转发表或者三层IP地址路由表,而OpenFlow交换机中使用的流表也是如此,不过在它的表项中统一整合了网络中所有层次的配置信息,从而在进行数据转发时能够使用更加丰富的规则.

流表项主要由匹配字段、表项优先级、计数器、表项指令、超时时间和Cookie组成[7].其中,匹配字段和表项优先级在流表中共同定义了一个唯一的流表项.匹配字段的结构包含很多匹配项,涵盖了链路层、网络层和传输层的大部分标识.优先级表示流表存在冲突时,流表项的执行顺序;指令表明了与该流表项匹配的数据包应该执行的下一步操作;计数器用来统计数据流的基本数据[8].而在OpenFlow网络中将不再区分路由器和交换机,都统称为OpenFlow交换机,这也是由于OpenFlow交换机采取流的匹配和转发模式所致[9].

为了提高数据流的查询效率,目前的流表查询通过多级流表和流水线模式来获得对应操作.每台OpenFlow交换机的OpenFlow流水线包含多级流表,每个流表包含多个流表项.OpenFlow流水线处理定义了数据包如何与流表互动,一个OpenFlow交换机至少要有一条流表[10].流表工作流程如图2.

图2 OpenFlow交换机流水线示意图Figure 2 Openflow switch assembly line chart

当数据包进入到OVS之后,数据包首先会查找一个与之相匹配的流表项.当找到匹配的流表项后,执行流表项中指定的转发动作.这些指令会明确地将数据包指向另一个流表,然后执行相同的动作.流表项只能将数据包指向流表号大于自己所在的流表号的流表,也就是说流水线的处理只能向前进行而不能倒退.若匹配流表项不将数据包指向其它流表,则流水线处理就此停止.当流水线处理停止后,数据包根据它所联合的动作集进行处理和照常转发.当有数据包不匹配流表中的流表项时,这就是table-miss.table-miss的动作依据流表的配置,table-miss表项会指出如何处理不匹配的数据包:如丢弃、传递到其它的流表和packet-in上送控制器.

2 流量转发过程设计

2.1 Controller与OVS建立连接

流表的转发是建立在Controller与OVS连接的基础上,由图3知Controller与OVS的连接需要以下步骤:

图3 Controller与OVS连接图Figure 3 Controller and ovs connection

1)Controller与OVS之间通过TCP三次握手过程建立连接.

2)TCP建立连接之后,Controller和OVS互发hello报文,当hello报文在Controller和OVS相互交换之后,Controller与OVS之间就建立了连接.

3)两者建立连接之后,Controller会向OVS发送功能请求(Feature Request)报文来获得OVS的性能、功能等一系列参数,当OVS收到请求之后,会向Controller发送功能响应(Feature Apply)报文来描述OVS的详细参数.

4)Controller获得OVS的性能信息之后,OpenFlow协议特定操作就可以开始进行了.

5)Echo请求(Echo Request)和Echo响应(Echo Apply)属于OpenFlow中的对称报文,作为Controller和OVS之间保持连接的消息(Keep-alive)来使用.

2.2 转发过程设计

流量转发包括两种情况:同OVS下流量的转发和跨OVS流量的转发.如图4,19.1.1.1到18.1.1.1和19.1.1.3到18.1.1.2的流量转发称为同OVS下的流量转发;19.1.1.1到19.1.1.3的流量转发称为跨OVS下的流量转发.

图4 流表转发图Figure 4 Flow table forwarding chart

对于上述两种不同流量的转发过程,分别有不同的方案.对于同OVS下流量的转发相对简单,下面以18.1.1.1到19.1.1.1进行说明.

1)虚拟机(VM)发送ICMP报文,ICMP报文从VM(18.1.1.1)发送到达OVS之后,首先会查询指导转发的流表项,对于首包,无法找到可以指导报文转发的表项,所以ICMP报文根据初始流表项匹配table-miss表项后packet-in上送Controller.OVS(172.16.0.18)将ICMP报文进行OpenFlow封装,主要包含目的IP(172.16.27.2)、源IP(172.16.0.18)和入端口(tap128=4).

2)Controller收到加OpenFlow封装之后的报文后,会进行解封装动作,得到原始ICMP报文,通过计算网络拓扑,根据ICMP报文中的目的IP查找出端口(tap137=6),然后将原始ICMP报文packet-out到OVS(172.16.0.18),同时下flow_mod表项,其中packet-out报文中包含了ICMP报文的目的IP(19.1.1.1),flow_mod表项包含了ICMP报文的目的IP(19.1.1.1)和出端口(tap137=6).

3)VM(19.1.1.1)收到ICMP报文之后,VM会对此报文进行响应,即ICMP报文会按照相同的过程由19.1.1.1发送到18.1.1.1,一次请求一次响应之后,所有类似报文会在两个flow_mod表项的指导下进行不间断转发,除非具有新特征的报文出现,否则不会再次上送Controller,这样就达到了上文提到的数据平面和控制平面相分离的目的.

对于跨OVS下流量的转发相对复杂,本方案引入了Vxlan隧道的概念,如图5所示,使报文经过Vxlan隧道发送到其他OVS下的虚拟机,来达到流量相通的目的.下面以18.1.1.1到19.1.1.3进行说明.

1)VM发送ICMP报文,ICMP报文从VM(18.1.1.1)发送到达OVS之后,首先会查询指导转发的流表项,对于首包,无法找到可以指导报文转发的表项,所以ICMP报文根据初始流表项匹配table-miss表项后packet-in上送Controller.OVS(172.16.0.18)将ICMP报文进行OpenFlow封装,主要包含目的IP(172.16.27.2)、源IP(172.16.0.18)和入端口(tap128=4).

2)Controller收到加OpenFlow封装之后的报文后,会进行解封装动作,得到原始ICMP报文,通过计算网络拓扑,根据ICMP报文中的目的

图5 Vxlan隧道图Figure 5 Vxlan tunnel chart

IP查找出端口,并且计算出ICMP报文所需封装(vxlan封装).

3)Controller将原始的ICMP报文packet-out到OVS(172.16.0.18),并且通过flow_mod下发指导该ICMP流量转发的流表.流表中需要通过action来指导流量的转发动作,主要进行vxlan的封装,包括外层MAC头、IP头和UDP头.IP头包括源IP(VTEP IP:18.18.18.18)和目的IP(VTEP IP:19.19.19.19),MAC头包含源MAC(源IP对应的MAC地址)和目的MAC(目的IP对应的MAC地址),UDP头主要是用来指导报文从哪条vxlan隧道进行转发.

4)OVS(172.16.0.18)对完成vxlan封装之后,该ICMP报文将由vxlan隧道口进入隧道,在隧道中目的OVS(172.16.0.19)对该报文进行解封转,进而获得ICMP报文的目的IP(19.19.19.19)和目的MAC,获得这些信息之后,ICMP报文从另一端的vxlan隧道口发出到达目的OVS(172.16.0.19),此时的报文在隧道中经过解封装后为原始ICMP报文.

5)目的OVS(172.16.0.19)收到原始ICMP报文后并不知道该发送到哪个虚拟机下,所以仍然需要将该报文再次packet-in上送Controller,同样的需要进行OpenFlow封装,包含目的IP(172.16.27.2)、源IP(172.16.0.19)和入端口(vxlan隧道口),上送到Controller后,Controller再次对该报文进行解封装计算网络拓扑,并将该报文packet-out到目的OVS(172.16.0.19),包含报文的出端口(tap147=6),并且通过flow_mod下发指导该ICMP流量转发的流表.这样VM(18.1.1.1)到VM(19.1.1.3)的请求完成了,然后VM(19.1.1.3)会对该请求做出响应,按照同样的转发过程将ICMP报文由VM(19.1.1.3)发送到VM(18.1.1.1).在完成首包发送之后,所有的类似报文不需要上送Controller,将在四个flow_mod的指导下进行不间断的转发,进而达到数据平面和控制平面分离的目的.

3 流量转发过程实现

按照上述过程的设计方案,采用java编写代码来实现,同时采用javascript、css3和html5编写web页面,借助web页面可以清晰的展示不同流量的转发情况.

OVS和Controller建立连接之后,Controller需要给OVS下发初始流表,否则进入OVS的报文查找不到流表项,将做丢弃处理.图6和图7是下发的初始流表项,从图中可以看到table-miss表项在下发初始流表的作用,即将报文上送到Controller.table-miss表项的意思是在找不到任何匹配项的时候,报文会命中这个表项,进而指导这些报文的转发行为,因此table-miss表项设计成优先级最低且无匹配项.若没有这个表项,不匹配的报文默认是被丢弃.

图8是18.1.1.1 ping 19.1.1.1,可以看到有流量的转发,在图9中,将转发的流表获取到web页面上,可以清晰的看到18.1.1.1和19.1.1.1之间的流量在端口4和端口6之间互通.

从18.1.1.1发出的原始ICMP报文的目的MAC、源MAC、目的IP以及源IP，分别为00:16:3f:aa:aa:aa、00:50:56:95:32:1d、19.1.1.1和18.1.1.1.经过OpenFlow封装的ICMP报文的目的MAC,源MAC,目的IP,源IP，分别为00:50:56:af:6f:1a、00:16:3f:aa:aa:aa、19.1.1.1和18.1.1.1.

图6 172.16.0.18初始化流表Figure 6 172.16.0.18 initialization flow table

图7 172.16.0.18初始化流表Figure 7 172.16.0.18 initialization flow table

图8 18.1.1.1 ping 19.1.1.1Figure 8 18.1.1.1 ping 19.1.1.1

图9 同OVS流表转发Figure 9 Sameovs flow tableforwarding

图10是18.1.1.1 ping 19.1.1.3,可以看到有流量的转发,在图11中,将转发的流表获取到web页面上,可以清晰的看到18.1.1.1和19.1.1.3之间的流量互通.从18.1.1.1发出的报文从入端口(in_port:4)发出,经过vxlan隧道后,从出端口(output:6)到达19.1.1.3;从19.1.1.3响应的报文从入端口(in_port:6)发出,经过隧道后,从出端口(output:4)到达18.1.1.1.

图10 18.1.1.1 ping 19.1.1.3Figure 10 18.1.1.1 ping 19.1.1.3

图11 跨OVS流表转发Figure 11 Differentovs flow table forwarding

从18.1.1.1发出的原始ICMP报文目的MAC、源MAC、目的IP以及源IP，分别为00:16:3f:aa:aa:aa、00:50:56:95:32:1d、19.1.1.1和18.1.1.1.增加vxlan封装的ICMP报文的目的MAC、源MAC、目的IP以及源IP，分别为00:0f:e2:00:00:18、00:50:56:6d:1b:a4、19.19.19.19和18.18.18.18.

4 结 语

流表作为软件定义网络(SDN)的核心,对于整个网络极其重要.流量不通,网络则不通,对于企业来说整个网络就处于瘫痪状态,对于网络的业务如服务链、防火墙等的存在已毫无意义,这将对企业造成不可估量的后果.一个合理的流表转发方案将起着决定的作用,是整个网络存在的基石,上文提出的设计方案涵盖了各种形式的流量转发过程,切实可行地保证了流量在不同情况下的成功转发,进一步根据实现结果验证了本套方案是合理可行的,是可靠稳定的.在此基础上,整个网络的存在才有意义.

[1] MCKEOWN N, ANDERSON T, BALAKRISHNAN H, et al. OpenFlow: enabling innovation in campus networks[J].ACM SIGCOMM Computer Communication Review,2008,38(2):69-75.

[2] LIN Haizhuo, SUN Lujing, FAN Yuntao, et al. Apply embedded OpenFlow MPLS technology on wireless OpenFlow-OpenRoads[C]//Proc of the 2nd IEEE International Conference on Consumer Electronics, Communications and Networks. Piscataway: IEEE,2012:916-919.

[3] DELY P, KASSLER A, BAYER N. OpenFlow for wireless mesh networks[C]//Proc of the 20th International Conference on Computer, Communications and Networks. Maui: IEEE,2011:1-6.

[4] SALVADORI E, CORINR D, BROGLIO A, et al. Generalizing virtual network topologies in OpenFlow based networks[C]//Proc of GlobalTelecommunications Conference. Kathmandu: IEEE, 2011:1-6.

[5] MIN S, KIM S, LEE J, et al. Implementation of an OpenFlow network virtualization for multi-controller environment[C]//Proc of the 14th International Conference on Advanced Communication Technology. PyeongChang: IEEE,2012:589-592.

[6] 张顺淼,邹复民.软件定义网络研究综述[J].计算机应用研究,2013,30(8):2246-2251. ZHANG Shunmiao, ZOU Fumin. Survey on software defined network research[J].Application Research of Computers,2013,30(8):2246-2251.

[7] 周烨,杨旭,李勇,等.基于分类的软件定义网络流表更新一致性方案[J].电子与信息学报,2013(7):1746-1752. ZHOU Ye, YANG Xu, LI Yong, et al. Classification based consistent flow update scheme in software defined network[J].Journal of Electronics & Information Technology,2013(7):1746-1752.

[8] 左青云,陈鸣,赵广松,等.基于OpenFlow的SDN技术研究[J].软件学报,2013,24(5):1078-1097. ZUO Qingyun, CHEN Ming, ZHAO Guangsong, et al. Research on OpenFlow-based SDN technologies[J].Journal of Software,2013,24(5):1078-1097.

[9] 周烨,李勇,苏厉,等.基于虚拟化的网络创新实验环境研究[J].电子学报,2012,40(11):2152-2157. ZHOU Ye, LI Yong, SU Li, et al. Research of network innovation experimental environment based on networkvirtualization[J].Acta Electronica Sinica,2012,40(11):2152-2157.

[10] 王丽君,刘永强,张健.基于OpenFlow的未来互联网实验技术研究[J].电信网技术,2011,6(6):11-14. WANG Lijun, LIU Yongqiang, ZHANG Jian. Research on future internet experimental technology Based on OpenFlow[J].The Manuscript Editing Center,2011,6(6):11-14.

Design and implementation of openflow switch flow table forwarding

ZHANG Junshuai, YANG Hao

(College of Information Engineering, China Jiliang University, Hangzhou 310018, China)

In the traditional network, since the information of switch and router is stored in different forms such as MAC tables and routing tables, the complex calculation of switching and routing protocols is needed in the network to get the tables. According to these different tables, we can operate the data plane with instructions. OpenFlow protocol standardizes and centralizes the protocol, and by using controllers controls the flow table, which takes the place of all other tables to finish forwarding. Compared with the traditional network, the virtual network has the advantages of being simple in structure and direct in process and is the future of network development. Flow table is the core of the network, and the process of flow table forwarding will affect the entire network. The process of forwarding that included vxlan, the same OVS forwarding and the different OVS forwarding was introduced.

OpenFlow protocol; flow table; vxlan forwarding; same OVS forwarding; different OVS forwarding

1004-1540(2015)03-0316-08

10.3969/j.issn.1004-1540.2015.03.013

2015-04-01 《中国计量学院学报》网址：zgjl.cbpt.cnki.net

张俊帅(1988- ),男,河北省张家口人,硕士研究生,主要研究方向为SDN虚拟网络.E-mail:zhangjunshuai211@sina.com 通讯联系人：杨 昊,男,副教授.E-mail:yanghao@cjlu.edu.cn

TP393.03

A