基于OpenFlow的AFDX网络虚拟链路动态优先级接纳控制--《航空学报》2014年11期
基于OpenFlow的AFDX网络虚拟链路动态优先级接纳控制
【摘要】：为了在航空电子全双工交换式以太网(AFDX)中更加灵活地对虚拟链路(VL)实行接纳控制,将OpenFlow引入AFDX网络中,建立了相应的网络模型、消息模型和流量模型。利用网络演算方法分析了优先级VL在基于OpenFlow的AFDX网络中的端到端延迟上界,结合粒子群优化算法,提出了动态优先级接纳控制算法。理论分析结果表明:与动态非优先级接纳控制方法和传统静态优先级分配方法相比,本算法的消息延迟分别降低了49.2%和26.4%,并且本算法能够更加灵活地对VL实行接纳控制,提高网络资源的利用率。最后通过仿真对理论分析的结果进行了验证。本算法为提高接纳控制方法的性能提供了参考,增强了AFDX网络的通信效率与实时性能。
【作者单位】：
【关键词】：
【基金】：
【分类号】：V243【正文快照】：
网络出版地址:ki.net/kcms/detail/10.-78.html引用格式:Li Z,Li Q,Xiong Y,et al.Dynamic priority admission control of virtual link in AFDX based on OpenFlow[J].Acta Aeronautica etAstronautica Sinica,):.李铮,李峭
欢迎：、、)
支持CAJ、PDF文件格式，仅支持PDF格式
【参考文献】
中国期刊全文数据库
陈昕;周拥军;蒋文保;万剑雄;;[J];电子学报;2009年05期
沈伋;韩丽川;沈益斌;;[J];航空学报;2008年06期
;[J];Chinese Journal of A2011年02期
【共引文献】
中国期刊全文数据库
黄臻;张勇涛;熊华钢;;[J];北京航空航天大学学报;2011年10期
周天然;张勇涛;何锋;熊华钢;;[J];北京航空航天大学学报;2012年01期
樊葆华;张鹤颖;窦文华;;[J];电子学报;2010年11期
武虎子;唐长红;耿建中;姚海林;;[J];飞行力学;2012年02期
谭远明;沈伋;;[J];飞机设计;2010年03期
刘世豪;叶文华;唐敦兵;陈蔚芳;;[J];高技术通讯;2010年09期
谷晓燕;何锋;李忱;;[J];北京信息科技大学学报(自然科学版);2012年04期
赵永库;王红春;唐来胜;;[J];电光与控制;2013年04期
易娟;何锋;王彤;;[J];电光与控制;2013年07期
谌文涛;何锋;周一伟;熊华钢;;[J];电光与控制;2013年11期
中国重要会议论文全文数据库
刘成林;李灵军;罗洁;;[A];2012航空试验测试技术学术交流会论文集[C];2012年
刘乐平;;[A];探索 创新 交流——第六届中国航空学会青年科技论坛文集（下册）[C];2014年
王勇;;[A];探索 创新 交流——第六届中国航空学会青年科技论坛文集（下册）[C];2014年
葛晨;余爱国;;[A];探索 创新 交流——第六届中国航空学会青年科技论坛文集（下册）[C];2014年
中国博士学位论文全文数据库
刘世豪;[D];南京航空航天大学;2013年
【二级参考文献】
中国期刊全文数据库
周强;熊华钢;张晓林;张彦仲;;[J];北京航空航天大学学报;2009年04期
周强;熊华钢;;[J];电光与控制;2009年04期
陈昕;周拥军;蒋文保;万剑雄;;[J];电子学报;2009年05期
李爱国,覃征,鲍复民,贺升平;[J];计算机工程与应用;2002年21期
任斌,丰镇平;[J];南京师范大学学报(工程技术版);2002年02期
方卫国,师瑞峰;[J];系统工程理论与实践;2003年11期
【相似文献】
中国期刊全文数据库
牛睿平,李晨希;[J];水利水文自动化;2005年01期
庄锦军;林闯;任丰原;;[J];清华大学学报(自然科学版);2007年04期
智英建;魏燕;汪斌强;;[J];华中科技大学学报(自然科学版);2007年S1期
吕蓉,曹志刚;[J];清华大学学报(自然科学版);2005年07期
谢建国,陈松乔;[J];湖南大学学报(自然科学版);2002年03期
中国重要会议论文全文数据库
俞承志;;[A];中国通信学会信息通信网络技术委员会2005年年会论文集[C];2005年
秦嗣仲;张春明;;[A];2012全国无线及移动通信学术大会论文集（下）[C];2012年
中国博士学位论文全文数据库
潘军;[D];中国科学技术大学;2013年
张光胜;[D];国防科学技术大学;2008年
庞斌;[D];中国科学院研究生院（计算技术研究所）;2003年
中国硕士学位论文全文数据库
佘彦曦;[D];吉林大学;2010年
薄慧;[D];西华大学;2013年
庄浩;[D];北京邮电大学;2010年
陈起贤;[D];北京邮电大学;2013年
黄鑫;[D];西安电子科技大学;2008年
陈旭;[D];西华大学;2012年
王曙光;[D];西南交通大学;2011年
温小军;[D];北京邮电大学;2010年
李炳恒;[D];电子科技大学;2006年
王正仲;[D];北京邮电大学;2008年
&快捷付款方式
&订购知网充值卡
400-819-9993
《中国学术期刊（光盘版）》电子杂志社有限公司
同方知网数字出版技术股份有限公司
地址：北京清华大学 84-48信箱 大众知识服务
出版物经营许可证 新出发京批字第直0595号
订购热线：400-819-82499
服务热线：010--
在线咨询：
传真：010-
京公网安备75号<meta name="dc.description" xml:lang="en" content="OpenFlow is a de-facto standard programming interface between controllers and switches. How to enable the existing switches to support OpenFlow without losing their original forwarding capability is a challenge in the migration from traditional network to software defined network (SDN). Take Broadcom Trident series application specific integrated circuit (ASIC) switch as an example, an algorithm to map OpenFlow forwarding table entries into ASIC's ternary content addressable memory (TCAM) as well as traditional L2/L3 tables to augment the OpenFlow table's capability, was proposed. The feasibility and scalability of our solution was demonstrated with design, implementation and evaluation in physical switch." />
ASIC芯片OpenFlow交换机设计与实现[J]. 北京邮电大学学报, ): 93-98.&&
CHEN Chun-ling,
MAO Yan-qin.
Design, Implementation and Evaluation of ASIC-Based OpenFlow Switch[J]. JOURNAL OF BEIJING UNIVERSITY OF POSTS AND TELECOMMUNICATIONS, ): 93-98.&&
Permissions
ASIC芯片OpenFlow交换机设计与实现
南京邮电大学 计算机学院, 南京 210003
费宁(1977-), 女, 副教授, E-mail:
基金项目: 南京邮电大学科研项目（NY215168）；江苏省未来网络前瞻性研究项目（BY）
以博通公司专用集成电路（ASIC）芯片交换机为例，深入研究了OpenFlow表项映射至芯片三态内容寻址存储器和传统转发寄存器的机制，以达到充分利用现有ASIC资源的目的.在工业界主流交换机上进行测试的结果表明，该方案实现的OpenFlow交换机完全可行，并具备较好的实用性和扩展性.
软件定义网络&&&&
OpenFlow&&&&
专用集成电路&&&&
三态内容寻址存储器&&&&
中图分类号:TN915.05 文献标志码:A
文章编号:16)06-0093-06 DOI:10.13190/j.jbupt.
Design, Implementation and Evaluation of ASIC-Based OpenFlow Switch
CHEN Chun-ling,
MAO Yan-qin
School of Computer Science and Technology, Nanjing University of Posts and Telecommunications, Nanjing 210003, China
OpenFlow is a de-facto standard programming interface between controllers and switches. How to enable the existing switches to support OpenFlow without losing their original forwarding capability is a challenge in the migration from traditional network to software defined network (SDN). Take Broadcom Trident series application specific integrated circuit (ASIC) switch as an example, an algorithm to map OpenFlow forwarding table entries into ASIC's ternary content addressable memory (TCAM) as well as traditional L2/L3 tables to augment the OpenFlow table's capability, was proposed. The feasibility and scalability of our solution was demonstrated with design, implementation and evaluation in physical switch.
Key words:
software defined network&&&&
OpenFlow&&&&
application specific integrated circuit&&&&
ternary content addressable memory&&&&
软件定义网络(SDN，software defined network) 的核心思想是将控制平面的功能从交换机中分离出来，由强大的控制器统一实现[]. OpenFlow起源于斯坦福大学的Clean Slate计划[]，其已成为SDN中控制器和交换机通信的标准语言，以下讨论皆以OpenFlow 1.3.1版本为基础[].由于目前主流交换机大多通过专用集成电路(ASIC，application specific integrated circuit) 来转发数据报文，所以如何使得基于ASIC芯片的交换机支持OpenFlow协议成了SDN部署中的关键一环.
笔者在研究现有交换机硬件架构的基础上，给出了能充分复用ASIC转发资源的OpenFlow流表映射算法.由于Broadcom ASIC芯片在数据中心交换机市场占据了绝对份额，笔者以Broadcom生产的Trident芯片为例来探讨OpenFlow交换机设计和实现.
1 OpenFlow交换机的演进策略
目前数据中心几乎所有的交换机都依赖ASIC芯片作转发. 描述了ASIC的转发过程，数据报文进入交换机后，先后经历报文解析、隧道终结、VLAN过滤处理、二层和三层逻辑处理、入端过滤(IFP，ingress filter processor)、二层和三层逻辑再处理、报文修改和压入出端VLAN、出端过滤(EFP，egress filter processor) 等处理单元，最后到达出口.
图 1 Broadcom Trident芯片报文处理流程
在ASIC中，转发流水线由多个处理单元组成，在每个单元中又包含若干寄存器用来储存和触发条件相关联的匹配表项，如中的IFP和EFP，其硬件由三态内容寻址存储器(TCAM，ternary content addressable memory) 组成，主要用于快速查找ACL、路由等表项[]. TCAM很容易实现表项的快速查找，其关联的同步动态随机存储器(SDRAM，synchronous dynamic random access memory) 用来执行相应的动作.因为TCAM可支持OSI模型中2~7层任意报文特征的匹配，交换机实现OpenFlow的最直接的方法就是将OpenFlow表项下发至ASIC芯片中IFP/EFP所对应的TCAM模块.然而，一个ASIC芯片所集成的TCAM容量非常有限，在Trident系列芯片中TCAM容量只有4 K，相比较传统的二层FDB (128 K) 和三层路由表(16 K)，处理能力非常有限.
为了解决现有ASIC芯片中TCAM容量有限的问题，目前工业界有2种方案[]：第一，扩大TCAM容量，但TCAM面积大、发热量高、耗电量高等固有的缺点在短时间内很难解决[]；第二，复用交换机流水线中的其他处理模块，该方案除了充分利用现有的TCAM模块之外，也利用所示转发流水线中的二层、三层处理模块. OpenFlow交换机在接收到控制器创建流表的命令后，可根据表项的特征决定将流表写入ASIC对应的模块.该方案的最大优点就是ASIC制造商和交换机厂商不需要任何硬件的投入和改造，只需要在交换机侧实现OpenFlow接口并将OpenFlow流表映射至ASIC芯片不同模块.
笔者基于方案2的分析，提出最大化复用ASIC芯片处理单元的OpenFlow交换机流表映射算法.其核心思想为：对所有要求写入的流表进行类型甄别，如果流表属于ASIC芯片转发流水线支持的传统表项，则将其写入相应的寄存器；如果不属于任何一个传统表项，则写入原来用于支持ACL的TCAM当中.这样实现了传统表项的最大化利用，使得ASIC所支持的流表数目大大超过了TCAM的限制.
2 算法设计与实现
2.1 架构设计
在复用现有交换机ASIC芯片传统转发单元和TCAM模块的基础上，给出面向ASIC芯片的OpenFlow交换机的设计架构，如所示.
图 2 基于ASIC芯片的OpenFlow交换机架构
现有的交换机往往采用ASIC+CPU双芯片模式，其中ASIC负责报文转发，CPU负责交换路由协议的计算和对交换机资源的管理，所以操作系统所管理的硬件资源主要包括CPU和ASIC两个部分.算法最大的改动在于应用层，主要增加了4个模块：流表管理模块、控制器连接管理模块、数据传输模块和硬件适配层.流表管理模块是整个OpenFlow交换机设计架构的核心，主要负责管理OpenFlow流表项的相关部署和操作，例如添加、删除、更新等；控制器连接管理模块将交换机资源进行分割，并创建不同的实例去管理这些资源，每个实例维护一个与控制器之间的接口和链路；数据传输模块主要负责对消息进行封装，封装成OpenFlow协议并通过标准的TCP链接和控制器进行通信；硬件适配层的主要功能是将流表管理模块的指令翻译成与ASIC芯片相关的操作，并将其写入ASIC寄存器或TCAM.
在该设计中，同一个交换机可支持多个OpenFlow实例，每个实例管理不同的端口，端口之间实现流量的隔离，每个实例可连接不同的控制器.从控制器角度来说，它看到的拓扑即为多个交换机，并不能区分出这些交换机是否由一个交换机虚拟而成.这样的优势是让数据中心在部署时具备更小颗粒度和更大的灵活度，也可以节约成本.
当流表管理模块收到和流表相关的处理消息时，先根据确定该表项的类型，然后转发给特定表项的处理函数，将此表项写到ASIC对应的寄存器；如果不属于任何一个表项，则当做通用表项来处理，这样的表项不能复用传统协议的硬件寄存器，只能写入ASIC中的TCAM模块.
表 1 OpenFlow表项类型及其特征
OpenFlow表项
单播和多播FDB
Match: VLAN, DMACAction: Output
单标签的MPLS Push
Match: VLAN, DMAC and DIP PrefixAction: Push MPLS label, Pop VLAN, Change SMAC, Change DMACTL Operation: Decrement IP TTL and set user configured MPLS TTL
Match: MPLS Label, DMACAction: Pop MPLS, Push VLAN, Change SMAC, Change DMACTTL Operation: Decrement TTL，copy to IP header
Match:DMAC (Switch MAC), VLAN, DIP PrefixAction:Set SMAC (Switch MAC), Set DMAC (End host MAC), Push VLAN, IP TTL Decrement
L3多播(交换)
Match：DMAC[01:00:5E:xx:xx:xx], VLAN, DIP [224. x. x. x], SIP (Optional)Action：Output to Multiple Ports
L3多播(路由)
Match:DMAC[01:00:5E:xx:xx:xx], VLAN, DIP [224. x. x. x], SIP (Optional)Action:Group with buckets SMAC=Switch MAC, IP TTL Decrement, output
其他任意匹配
Match: ANYAction: ANY
表 1 OpenFlow表项类型及其特征
2.2 模块设计
以下以多协议标签(MPLS，multi-protocol label switching) 流表为例，详细分析如何利用ASIC流水线中的寄存器实现OpenFlow MPLS流表的映射与处理.
Broadcom芯片中MPLS入标签的操作流程如所示.当IP报文进入流水线时，查询通用的路由表，在出接口根据寄存器中的预先设置在报文相应位置压入MPLS标签，并进行MAC地址的替换.
图 3 Broadcom Trident MPLS Push处理流程
将所示的流水线转换为对应的编程接口，设计了下发OpenFlow MPLS Push流表至ASIC的操作流程，如所示.首先将入端VLAN和虚拟路由转发表(VRF，virtual route forwarding) 绑定，再创建出端VLAN，并分别和入端口及出端口绑定；然后将入端VLAN映射至VRF，确保带有不同VLAN的报文进入不同的VRF路由表处理；最后在VRF中写入具体的路由条目，并关联至存储相关动作寄存器的三层出端口即可.在此，所有流表动作皆由三层接口所指向的寄存器来完成. MPLS Push的流表被写入到传统的三层处理流水线中，而非ACL所对应的IFP模块.由此可以看出，OpenFlow交换机和传统交换机在与ASIC交互的操作基本相同，两者的关键区别在于路由表是由控制器生成还是由路由协议计算生成.
图 4 OpenFlow MPLS Push流表操作流程
由可以看出，交换机ASIC流水线是顺序处理，所有的报文在经过三层处理流水线之后都会进入IFP，即TCAM模块.当前的问题是经过三层处理后的MPLS报文可能会被TCAM模块中的OpenFlow流表项误匹配，报文被覆盖或是改写，解决方法是在TCAM模块创建2条表项，第1条为匹配MPLS标签终止为条件，即匹配对应于已经执行MPLS Pop的报文；第2条为L3目标路由命中为条件，即匹配对应于MPLS Push命中三层路由表的报文.这2个表项都动作为空且优先级最高，确保了MPLS Pop和MPLS Push报文能命中IFP但不执行任何动作，使得MPLS报文绕过了IFP模块.
以上设计展示了OpenFlow MPLS相关的表项与ASIC的映射的全过程，其使用了非TCAM模块来存储OpenFlow MPLS流表；同样的策略也可应用于满足FDB及L3单播规则的OpenFlow流表，达到最大化复用传统路由转发流水线来支持OpenFlow的目的，极大地扩展了基于ASIC的交换机对OpenFlow协议支持的能力.
3 扩展性和性能分析
OpenFlow交换机最重要的指标就是扩展性和性能.扩展性是指交换机所支持的流表类型和数目，性能是指交换机响应控制器的速度和报文转发速度，下面分别从这2个层面进行分析.
3.1 扩展性
OpenFlow不同类型的表项容量受限制于所涉及的ASIC寄存器，如果某类表项涉及多个寄存器模块，则最终的表项条目数由关键模块决定. 给出了OpenFlow不同表项扩展性的汇总.
表 2 OpenFlow不同表项扩展性汇总
OpenFlow表项
所涉及ASIC模块
L2_ENTRY (128 K)
MY_STATION_TCAM (512)L3_DEFIP (16 K)MAC_DA_PROFILE (512)EGR_L3_INTF (4 K)IP_TUNNEL_MPLS (512×4)
2 K(受限于IP_TUNNEL_MPLS)
MPLS_ENTRY (4 K)L3_DEFIP (16 K)EGR_L3_INTF (4 K)VRF (1 K)
1 K (受限于VRF)
MY_STATION_TCAM (512)L3_DEFIP (16 K)L3_ECMP (4 K)
16 K4 K (ECMP)
MY_STATION_TCAM (512)L3_IPV4_MULTICAST (4 K)L3_IPMC (4 K)
表 2 OpenFlow不同表项扩展性汇总
以MPLS Push为例，该流表对IP报文压入新的MPLS标签，所以存储标签的关键寄存器IP_TUNNEL_MPLS决定了该表项的实际大小，也就是2 K.此外，IP报文必须命中MY_STATION_TCAM才能进入三层处理，所以同时要求IP报文的(VLAN+DMAC) 组合不能超过512个.同理，所有MPLS Push需要替换的DMAC数目由MAC_DA_PROFILE决定，也不能超过512个.这些条件实际上限制了数据中心网络VLAN大小、IP域主机容量和MPLS域主机的容量.对于MPLS Pop，需将每个MPLS_ENTRY条目对应至不同VRF，所以实际容量为1 K.其他任意匹配使用ASIC中的IFP TCAM模块，其容量为2 K，远远小于传统的二层交换表(128 K) 和三层路由表(16 K)，从而可以看出，充分利用ASIC中固有流水线相关寄存器能极大地扩充OpenFlow交换机所支持流表的数目.
从同样可以看出，不仅同一类表项的扩展性受到所涉及的ASIC模块的限制，不同类型的表项之间也有影响.例如，MPLS Push和Pop、L3单播都使用L3_DEFIP寄存器来实现路由匹配，所以各种流表项实际可使用大小互相制约.一个极端的例子就是L3单播耗尽了全部L3_DEFIP存储空间，那么所有三层和MPLS相关的操作均无法继续进行.当然在这种情况下，控制器需要考虑各种流表项的最大空间，并且尽量对这些表项进行合理分配.
3.2 性能分析
在交换机层面，性能分析可以分为2个层次，即报文转发性能和交换机对控制器指令的响应时间.报文转发由ASIC负责完成，这部分处理与上层协议类型无关，各厂家ASIC芯片对报文处理都能达到线速，这也与实际测试结果完全一致.在满配MPLS Push流表的交换机上，10 G SPF+端口满速率发送和接收没有出现丢包的情况.
示出了测试所用的交换机配置.交换机采用典型的CPU+ASIC设计，由于条件限制，实验中只测试了10 G端口.
表 3 OpenFlow交换机测试规格汇总
Freescale MPC8536
4 G, 2 G turned on
Linux based, OpenFlow running on single thread
Broadcom Trident Plus BCM56840
1 core used, average 45% CPU load
48个SPF+10 G，4个QSPF+40 G
表 3 OpenFlow交换机测试规格汇总
从所示OpenFlow交换机架构中可以看出，在交换机中，数据传输依赖于ASIC芯片，而OpenFlow协议和其他传统的交换路由协议一样运行于CPU之上，交换机对控制器指令的响应时间取决于ⅰ) CPU性能、ⅱ) 操作系统对OpenFlow进程的调度、ⅲ) 交换机接收、处理控制器消息的能力和ⅳ) 流表下发至ASIC的速度.前两者是系统设计的共性问题，后两者是OpenFlow协议所引入的新问题，以下主要对后两者进行分析.
交换机接收和处理控制器消息的能力取决于交换机CPU队列的大小.对于Trident系列来说，CPU队列长度为300.交换机接收控制器报文的速度不超过每秒300个，该报文包括控制器用于下发指令和未知报文所产生的Packet-out消息.在网络收敛之后，这样的处理能力完全满足一般网络运行的需求，因为此时无论是控制器对流表的修改还是因未知报文而产生的Packet-out消息都比较少.但在交换机重新启动并处于Proactive模式时，由于控制器在短时间内可能有大量流表项需要下发至交换机，此时CPU队列的大小就可能成为瓶颈，延迟网络收敛时间.
交换机对ASIC流表的下发速度实际上是硬件寄存器的读写速度.实际测试结果如所示，1 000条MPLS Push报文在0.79 s内可写入至ASIC，1 000条MPLS Pop报文也在1 s内操作完成；至于写入TCAM的ACL类型的表项，其条目的优先级由在TCAM中的相对位置决定，所以写入时间和写入条目的优先级相关. TCAM表项中靠前的条目优先匹配，对应的优先级最高.如果所有条目以优先级递增方式写入，则在写入新条目之前，必须将之前写入的所有条目往TCAM高地址移动，这样所耗费的时间将会大大增加.实际测试中，如果以优先级递减方式写入ACL类型的流表，则每1 000条ACL类型流表项操作时间在1 s之内；如果所有流表按优先级递增方式写入，则每1 000条ACL类型的操作时间则锐增至50 s.由此可以看出，如果设计TCAM为主的面向OpenFlow的交换机，下发流表至ASIC的速度必须针对优先级做出优化，能做到操作时间随着表项数目的递增线性地增加.而传统的FDB和其他三层表项，由于采用HASH寻址写入且无法在同一种类型的流表之间再区分优先级，所以并不存在这种因为优先级的变化而写入时间大幅抖动的情况.
图 5 每千条不同类型OpenFlow流表写入速度
由此可见，这种充分复用交换机转发流水线的策略可使现有交换机在不损失转发能力的情况下支持OpenFlow协议，从而加快了软件定义网络在数据中心的部署.
以目前主流的Broadcom Trident系列ASIC芯片为基础，分析和研究了OpenFlow交换机的若干实现细节.除了利用TCAM模块来实现任意匹配的OpenFlow报文之外，也分析了如何充分利用传统二层和三层相关的寄存器来拓展OpenFlow的条目；相应的实验表明，通过复用现有ASIC资源的OpenFlow交换机能在功能和性能上满足近阶段数据中心软件定义网络的部署需求.
徐雷, 张云勇, 吴俊, 等. 云计算环境下的网络技术研究[J].
通信学报, ): 16–221.
Xu Lei, Zhang Yunyong, Wu Jun, et al. Network technology research under cloud computing environment[J].
Mckeown N, Anderson T, Balakrishnan H, et al. OpenFlow:enabling innovation in campus networks[J].
ACM SIGCOMM Computer Communication Review, ): 69–74.
Open Networking Foundation. OpenFlow switch specification 1. 3. 1[EB/OL].[]. .
刘中金, 李勇, 苏厉, 等. TCAM存储高效的OpenFlow多级流表映射机制[J].
清华大学学报:自然科学版, ): 437–442.
Liu Zhongjin, Li Yong, Su Li, et al. TCAM-efficient flow table mapping scheme for OpenFlow multiple-table pipelines[J].
周烨, 李勇, 王芳, 等. 基于OpenFlow的网络实验平台技术[J].
清华大学学报:自然科学版, ): .
Zhou Ye, Li Yong, Wang Fang, et al. OpenFlow network experiment platform[J].
Sezer S, Scott-Hayward S, Chouhan P K, et al. Are we ready for SDN? Implementation challenges for software-defined networks[J].
IEEE Communications Magazine, ): 36–43.OpenFlow：受困五大问题 标准暂难商用_动态新闻_新闻中心_赛迪网
OpenFlow：受困五大问题 标准暂难商用
近几年兴起的SDN打破了网络原有的将软硬件捆绑在一个盒子中的状态，试图将软硬件分离，进而实现转发层面和控制层面的分离，最终实现更开放、更灵活、易管理、可扩展的网络
发布时间： 17:13&&&&&&&&来源：&&&&&&&&作者：卜娜 李万予
【赛迪网讯】近几年兴起的SDN打破了网络原有的将软硬件捆绑在一个盒子中的状态，试图将软硬件分离，进而实现转发层面和控制层面的分离，最终实现更开放、更灵活、易管理、可扩展的网络。
SDN为人们展现的是未来的一种比较理想的网络形态，实现它的方式有很多种，比如OpenFlow、Netconf、虚拟化软件API等。但一提起SDN，人们第一个想到的就是OpenFlow，它在业界的普及程度也远远高过其他技术。“OpenFlow最大的特征就是协议本身就能控制转发层面，可以高效且严格地实现转发层面和控制层面的分离。”博科公司高级技术工程师谷增云为记者指出OpenFlow如此受欢迎的原因。但是，在SDN网络形态尚不稳定的今天，颇受欢迎的OpenFlow就一定会成为未来网络形态的灵魂技术吗?
用户派和厂商派殊途同归
早在2009年，SDN就被《MIT Technology Review》评为具有影响力的十大新兴技术之一并且引起业界的广泛关注。 而这个理念的提出又与OpenFlow的诞生不无关系。OpenFlow属于下一代网络研究范畴的产物，由斯坦福大学Nick McKeown教授、加州大学伯克利分校的Scott Shenker教授及相关研究团队于2008年的Ethane项目研究成果OpenFlow技术的基础上进一步提升出来。而Ethane项目本意是通过一个集中的控制器来定义基于网络流的安全控制策略，并应用到各个网络设备中，以实现对整个网络通信的安全控制。集中控制、流控制……这都与SDN 的理念不谋而合。
OpenFlow源于学术，不是专为网络虚拟化而生，但是能够为未来的网络虚拟化带来无限可能。全球专家都在关注OpenFlow和SDN的发展态势，据悉，即将于8月底举办的“2013全球SDN与开放网络高峰会议”邀请了业内知名专家共同探讨SDN的发展前景。2011年，开放网络基金会(Open Networking Foundation)成立，专门负责OpenFlow标准和规范的维护和发展，以及推进SDN的商业化。目前，ONF由董事会成员及会员两部分组成，已经出台了OpenFlow1.0、OpenFlow1.1、OpenFlow1.2、OpenFlow1.3、OpenFlow1.3.1等版本，其中OpenFlow1.0、OpenFlow1.3已可商用。董事会成员主要包括部分运营商、互联网及软件公司，包括德国电信、日本NTT、Facebook、谷歌、微软、Verizon、雅虎和高盛等8家成员，会员则包括网络设备商、网络运营商、服务器虚拟化厂商、网络虚拟化厂商、测试仪表厂商等在内的80多家成员。盛科网络CEO孙剑勇曾经在接受《中国计算机报》记者采访时表示，在ONF成员中，用户的声音尤为重要。由于OpenFlow标准的制定者都是网络用户，这决定了他们的标准制定有一些理想色彩。
这样看来，ONF代表的是广大网络用户的声音，将其归到“用户派”可谓实至名归。与“用户派”遥相呼应的是“厂商派”OpenDaylight，该组织成立于4月9日，受到了大多数重量级网络基础设施厂商支持，思科、博科、爱立信、思杰和SDN专业厂商Big Switch Networks等均位列其中。成立之初，该项目主持人Linux基金执行会董事表示，OpenDaylight是一个研发实体，未来将与作为标准化实体的ONF形成互补。他将该团队称为“厂商中立团队”，没有一个成员能够控制整个团队。据了解，OpenDaylight将会基于ONF于2011年推出的OpenFlow协议搭建软件定义网络的部分框架。对此，ONF负责人称，OpenDaylight是站在别人的肩膀上。此外，ONF还发表声明：“作为用户社区的‘代言人’，ONF只支持那些遵守我们指导原则的项目。”
作为在国际上最具影响力的SDN相关的两大国际组织，“用户派”ONF和“厂商派”OpenDaylight的发展轨迹大相径庭。ONF于近日宣布了其OpenFlow测试认证项目的成立，为广大网络设备商提供了证明其产品符合OpenFlow规范的机会，也有利于最终用户加快相关产品的部署。OpenDaylight的进展显然没有这么顺利，其创始人成员Big Switch对于组织“采用思科控制器作为基本代码库启动这个计划”不满而发出抗议，并声称要退出该组织。Big Switch Networks创始人Appenzeller称，OpenDaylight采取的包含思科控制器的方法不是向前发展的正确方法。
ONF和OpenDaylight，一个代表用户，一个代表厂商;一个专注于协议标准的制定，一个专注于探索SDN的商业化发展之路。虽然角度不同甚至对立，但最终都是为了定义API开放接口的标准，使网络更开放、更灵活、更易部署。
谷歌应用已经成熟
谈及基于OpenFlow的SDN网络应用案例，谷增云、孙剑勇、Ixia技术产品经理杨益锋等业内资深人士不约而同地提到了谷歌。“传统的网络设备供应商、运营商、政府、互联网企业和大学及科研机构都在积极参与研究SDN相关技术，研发相应产品。”杨益锋认为，“但是，很多最终用户还在考虑如何部署应用SDN网络。国内运营商尚处于研究和观望阶段，而国际上有些企业已经部署了基于OpenFlow的SDN网络，其中最为成熟的非谷歌莫属。”
为了高效利用耗资巨大的全球范围内的广域网，谷歌率先在其广域网中部署了基于OpenFlow的SDN网络，包括面向互联网和全球12个数据中心之间的网络，所使用的OpenFlow交换机是定制的交换机，芯片全部是商业ASIC，并且部署了集中的OpenFlow控制器，控制器之上运行着诸多应用。这是标准的基于OpenFlow的SDN网络架构。据谷歌首席工程师Amin Vahdat介绍，2010年谷歌开始这个项目的时候，市面上还没有支持OpenFlow的设备，所以使用的相关设备全是自主开发制造的。当然，他对专业厂商的OpenFlow设备持欢迎态度：“如果市面上出现的交换机产品能够提供我们需要的功能，我们会很乐意考虑选择这些产品。”
通过部署OpenFlow、周密的流量工程和优先级安排，谷歌广域网线路的利用率已经接近100%。标准网络协议试图根据本地通信来理解全球网络情况，这意味着如果想要使用标准协议来影响全球策略是根本不可能的，因为没有什么中央控制计划可供使用。OpenFlow则为谷歌提供了一个逻辑上的中央控制计划，使其能够对整个网络架构拥有全球视野，并且可以根据全球网络状态来进行计算和决策。通过这种“全球视野”和精密的流控制，即使网络发生故障时，也可以确保重要的流量传输不受影响。
在谷歌技术基础设施高级副总裁兼研究员Urs Holzle看来，OpenFlow的部署工作比预期顺利。但是，OpenFlow1.0版本也为部署工作带来了困难――不能让用户以简单的方式实现现有交换机的全部功能。当然，这个问题随着OpenFlow版本的演进也在一步步解决。“既要与现有硬件设备的功能兼容，又要突出自己的特色，这是驱动OpenFlow版本演进的主要动力。”谷增云表示。
OpenFlow已经在谷歌的数据中心得到成功应用，这更大一部分原因需要归结于谷歌强大的创新能力，它可以自己构建网络模型，制造硬件设备，这是其他大部分用户不具备的，OpenFlow和SDN在用户中如何推广还是个难题。国内某SDN资深专家告诉记者，现在国内运营商主要专注于NFV(网络功能虚拟化)的研发推广，对于OpenFlow，更关注它在云数据中心的表现。Amin Vahdat在之前受访时也透露了他在运营商那儿得来的消息：运营商认为OpenFlow很难扩展，获益更是难上加难。OpenFlow在数据中心的部署已初现端倪，将来是否能有更广泛的应用，有待考证。
杀手级应用成关键
SDN尽管已经在谷歌得到部署并且效果令人满意，但是想要在全球范围内的用户中推广并不算容易，毕竟像谷歌这样的创新力、财力、物力等兼具的最终用户少之又少。所以，人们的共识是SDN目前尚处于学术研究阶段。“SDN的孕育更多地是从学术界开始，目前正在经历产业界的发酵但尚未深入到用户层面，主要是因为目前SDN技术本身还在发展中，更重要的是缺乏杀手级的应用推动。”锐捷网络研究院SDN研发主管吴航告诉记者。
为了能够更加明确地表示杀手级应用对于SDN的重要性，谷增云举了一个很形象的案例――广告和互联网。“2000年互联网泡沫破灭，后来，用户习惯逐渐培养起来，广告的盈利模式也逐渐确定，互联网开始兴起。”他认为，OpenFlow属于下一代网络架构，但是目前厂商能够为用户提供的产品还不是很完善，不能为用户提供从底层到上层应用的完整的解决方案，杀手级应用更是没有。这些问题加起来使得SDN对用户没有什么吸引力。
要想真正实现OpenFlow的产业化，必须做到以下三点：一、为用户提供完整的基于OpenFlow的SDN解决方案;二、方案和应用要做到极致，保证良好的用户体验;三、向用户灌输OpenFlow的理念，使其对新技术有了解，并在此基础上引导用户在网络分片化的基础上提供增值服务，得到效益。
依靠分离软件，SDN能够颠覆传统网络架构，引发网络产业变革，意义重大但却任重而道远。谈到如何从现有网络过渡到SDN网络，吴航认为：“改造传统网络架构，SDN很难做到一步到位，必然是从局部开始慢慢蚕食传统的网络。例如对于园区网，可以将所有的接入交换机进行OpenFlow改造，受控于SDN控制器，控制器仅需接入设备的功能即可。而在核心、汇聚层还是沿用传统的网络设备。再如，可以将传统交换机上的某些功能采用SDN方式控制，其他功能继续沿用传统方式控制。这样可以更好、更温和地进行网络改造，用户也会在这个改造过程中增强对SDN的信心，进而形成良性循环。”
商业前景为何不明朗?
尽管诞生于学术环境，但在OpenFlow的发展过程中，斯坦福大学的Nick McKeown教授一直以让其实现商用化为目标，所以OpenFlow并不是一个只能存活于“象牙塔”中的标准。ONF目前已经推出了两个可商用化的版本：OpenFlow1.0和OpenFlow1.3。
然而，如果想在实际的商用环境中生存，OpenFlow的现状还不足以让用户感到安心。
首先，尽管ONF推出了被其视为可以长期保持稳定的版本，但从1.0版到1.3版的变化很大。由于基于不同版本设计的交换机难以互相兼容，所以OpenFlow还不具备形成商业标准的先决条件――稳定。ONF这样的标准组织之所以目前难以对产业界产生实质性影响，主要是因为ONF的成员以学术界和用户为主，在标准设计过程中缺乏对传统网络大量研究成果的继承，所以其版本的演进多是在弥补对现有网络和未来网络认知的不足，不管是业内厂商还是用户都难以承担这样的风险。
其次，OpenFlow的功能缺陷依旧很明显，即使在其最新版的标准中，一些传统网络可以实现的功能它还无法实现，对未来网络功能的设计也有很多没有考虑周全的问题，比如OpenFlow控制器的选举机制以及控制器间的东西向协议等。同时，由于OpenFlow 1.3版本之后定义的多级流表机制，使得控制器需要感知交换支持的流表形式，若要兼容多厂商设备，其实现复杂度会大幅增加。
此外，OpenFlow仅是SDN理念实现的方法之一，并非必由之路。OpenFlow当前的优势是，在当前业界的各种标准化协议中，能支持流控制的协议且认知最广的只有OpenFlow。而ONF组织更强调网络开放的标准化，对SDN在产业层面形成规模效应也有积极作用。
所以，当前业界普遍的观点是：将OpenFlow视为唯一有希望的商用标准还为时尚早。如果ONF想成为有影响力的标准组织，它必须和产业联盟有更紧密的结合模式，并且积极推动SDN的产业化。
对SDN产业化的推动力有多大?
如果SDN不能形成产业规模效应，下一代网络一定很难基于SDN理念快速演进。没有统一标准，做大产业无从谈起。ONF组织定义OpenFlow的核心前提是驱动业界提供标准的开放API，这对于生态圈的快速形成，让SDN的思想真正扩大化具有积极意义。但在现实中，ONF却陷入了“理想丰满、现实骨感”的局面。
SDN是一门生意，而OpenFlow只是一种技术。作为标准组织，刚刚起步的它就陷入了与OpenDaylight这类产业联盟的“对决”。尽管OpenDaylight组织成立不久就传出了有成员退出的消息，但这只能证明思科的凝聚力在该组织中出现了问题，却并不意味着这类组织所形成的标准没有取代OpenFlow的可能。毕竟，在对SDN理念的理解和技术实现方面，产业联盟目前的实力更胜一筹，也更适合助推SDN在用户的现有网络中“隐形”演进。
标准化和用户需求相辅相成。谷增云指出，厂商开发产品首先要看客户的想法和需求，如果OpenFlow能解决用户面临的问题，满足应用的需求，各厂商才会跟随OpenFlow做相应的产品。而且，标准要趋于稳定后，才有可能实现产品的规模化。
产业的形成需要依靠整个生态圈的推动。OpenFlow只提出了一种标准，有更多的企业跟随才具有实质性影响。但如果用户仍然不买单，设备厂商和芯片厂商对OpenFlow标准跟随的兴趣就会逐渐变淡。况且，OpenFlow还必须面对另一个残酷的现实：依靠商用芯片的设备厂商，目前在整个网络设备市场的份额仅有10%，90%的市场被思科、华为、Juniper这些有自主研发、生产芯片的能力的设备厂商所占。在产业前景不明朗的情况下，商用芯片厂商也很难有动力去开发支持OpenFlow的芯片。目前，除华为积极参与到ONF组织中外，思科和Juniper已加入另一阵营，Juniper表示，他们将成为去OpenFlow的支持者。
杀手级应用在哪里?
“如果有杀手级应用，OpenFlow的产业化会很快。”谷增云认为，OpenFlow的产业化并非没有可能，它需要业界在实验网络及用户需求的演进中找到“非常重要”的应用。除谷歌基于OpenFlow实现了业务运营网络的改造且获得成功外，业界目前可以参考的OpenFlow案例非常有限。而事实上，像谷歌这类具备强大技术研发、整合能力的“用户”也绝无仅有。
OpenFlow所遇到的问题和发展了多年却依然难以崛起的IPv6一样，缺乏杀手级应用刺激SDN的规模化应用。“只要能用传统方案解决问题，用户就会认为没有必要冒风险。只有用户确实感受到SDN对其企业、对其业务可以带来巨大变化，让其尝到了传统技术无法带来的好处，SDN才能得到规模化的应用。”H3C专家遇惠军如是表示。
谷歌在其广域网的流量工程中，引入了对OpenFlow的尝试，是因为流量控制与其业务具有强相关性。高效流控是OpenFlow的一大优势，传统的路由协议是选择最短路径传输报文，高峰期时同一路径流量超过带宽，就会导致拥塞、丢包，影响业务。广域网的流量是一定的，想获得同等条件下更高的带宽利用率，必然需要具备实现路径重新定位的能力。谷歌对OpenFlow的实践，让其获得了流量识别能力，判断这些流量有什么用，是否来源于需要即时反应的应用，借此为流量设置传输的优先级，为不紧急的流量重新分配路径。由此可见，对谷歌这类互联网公司而言，流量控制可以被看作是OpenFlow的杀手级应用。
但国内的运营商目前还没有出现类似谷歌这样的需求，因为其业务还没有与用户的应用强相关。但未来，随着业务的发展，运营商可能会提供不同质量的带宽保障服务，这就会对OpenFlow产生业务级的强烈需要。
另外，云服务对传统数据中心的冲击主要来自于资源大集中后，虚拟化技术的规模化应用解放了物理资源，虚拟机的迁移使资源调配的灵活性更强，但传统网络却无法支撑这样的灵活性，令网络成为云计算数据中心的桎梏。网络策略不能动态跟随，就会影响业务的连续性。而随着数据中心规模的增大，管理和运营也会遇到很多挑战，SDN全局集中控制的理念可以更好地实现网络配置的自动化。这也是OpenFlow杀手级应用的落脚点之一。
在谷增云看来，杀手级应用的出现是有前提的。一定要先通过OpenFlow做到灵活控制网络，努力做好网络的分片化，然后再引导用户在网络分片化的基础上提供增值服务。
对未来网络的影响有多大?
用户对网络的实际需求完全靠OpenFlow还很难满足。但是，OpenFlow确实让业界对SDN的构想快速形成了共识。即使是与其存在“竞争关系”的OpenDaylight，也是以ONF组织提出的模型为基础对SDN展开研究的。
对整个产业界而言，最具价值的或许并不是OpenFlow，而是SDN的思想。它像是打开了潘多拉魔盒，给产业界、IT服务商和初创公司带来了可以展开无限遐想的机会。甚至过去相对封闭的传统网络厂商，在这两年也经历了从“被动抗拒”到“主动拥抱”的态度转变。完全根据OpenFlow定义的多级交换机对现有的网络芯片会产生较大影响，毕竟原有的网络芯片固化了太多的网络协议实现细节，其处理流程也更适合于传统分布式协议的网络控制方式。
吴航指出，首先，基于OpenFlow构建网络必须要考虑接入客户端以及现有网络的兼容性。因此，未来的OpenFlow交换机并不会完全摒弃现有的架构，而是会对现有芯片架构进行改良，借此赋予网络协议开发更多的灵活性和通用性。其次，基于OpenFlow构建的网络还会遇到单点性能瓶颈的问题，同时设备间的数据一致性和报文处理响应延迟也会存在较大问题。再从网络安全设备的性能上来看，若都采用OpenFlow实现方式，大部分数据报文都要被触发到控制器进行处理，这不仅增加了响应延迟，同时也会带来管理网络的瓶颈问题。此外，基于OpenFlow构建的网络存在管理和数据转发两张网的问题。管理网是基于TCP协议进行OpenFlow协议传输的，为此用户在构建OpenFlow网络时通常需要铺设两张网络，并且还可能增加了网络故障点和管理复杂度，推广起来很有难度。这些都是今后在OpenFlow网络实践过程中需要克服和面对解决的。
OpenFlow的网络功能更多依赖于控制器Controller上的网络APP，但哪些APP是必要的，哪些又是改变现有网络控制协议的，有赖于实际的应用场景。但目前，SDN网络典型的商用场景尚不明确，即使明确的也可以通过其它技术替代，而且控制器上的网络APP及基于北向接口开发的APP不够丰富。同时，控制器之间的东西向协议目前也尚未定义，如何保证网络控制面的流表及状态等数据一致性，还需要进行技术攻关。
离用户需求有多远?
SDN早期的研究者Casado等人萌生的交换应该基于通用流表来转发的思想，就是来源于实际应用需求。Casado等人在支持Federal DOD网络时发现，在保护有关国家安全和人类生活的重要信息时，难以实施安全策略和灵活的路由，部署新的应用时也要花费很大力气。为了提高网络配置管理效率和安全策略部署的灵活性，他们想到了交换设备的流转发和安全行为应该可以通过标准开放的接口来定义。从最终用户的需要出发，既是SDN的灵魂，也是OpenFlow的灵魂。
和OpenDaylight不同，ONF组织是绝对的“用户派”，它和今天的很多开源组织一样，以“不再被厂商绑定”为信念，希望按照用户的需要制定行业标准。从OpenFlow当前的发展来看，OpenFlow协议已能经支持局域网、广域网L2、L3等报文转发。其中，OpenFlow 1.0版本面向的是校园局域网，定义了单级流表、L2 IP报文匹配;OpenFlow 1.1版本进入到城域网和广域网市场，支持多表、MPLS标签/隧道、VLAN、组播表和ECMP等;OpenFlow 1.2版本，针对性能问题和与现有网络兼容问题，定义了扩展匹配机制、通用匹配和动作Instruction集，并支持IPv6基本协议;1.3版本支持流水处理的多级流表和与多控制器间的并行通道，流表的匹配通过TLV可扩展自定义，增加每流度量和每连接事件过滤等。对用户而言，SDN的价值主要有三点：开放接口、网络虚拟化和集中控制。OpenFlow目前的指导性作用主要聚焦于集中控制，还不能兼容用户的现有网络，实现平滑过渡。如果全部理想化地采用SDN的控制分离架构，中间用OpenFlow进行控制，目前连继承现有网络的功能都很难实现。
基于这些问题，ONF作为标准组织的价值多少会有些降低，一些用户甚至认为OpenFlow当前的价值仅剩下了“最终能让开放接口统一标准，不受设备厂商制约”，而非解决他们最关心的问题。而且，即使没有OpenFlow，网络也可以实现可编程和集中控制的目标。基于传统的网络架构，主流网络设备厂商所提供的开放API方案就可以做到这一点。遇惠军告诉记者，目前开放API方案对用户而言反而是解决其问题的更成熟的技术，因为在其上运行的网络协议都是经过长久实践的检验和证明的，用户的接受度更高。目前来看，这种方法唯一的局限性就是各厂商操作系统不统一带来的开放接口难以标准化的问题。除了对标准化更看重的运营商外，当前互联网企业还没有对此表现出强烈要求，他们更在乎如何解决网络运营的问题，只要厂商能提供额外的开放接口，赋予他们更强大的管理网络的能力，大多数用户会认为没必要因为跟随OpenFlow而采购新的设备。
(责任编辑：GH)
关键词阅读:
1(共条评论)
2(共条评论)
3(共条评论)
4(共条评论)
5(共条评论)
数字化已成为未来企业发展的核心战略，企业...
联系我们：
广告发布：
方案、案例展示：
京ICP000080号 网站-3
&&&&&&&&京公网安备45号