软件定义网络关键技术及其实现

中图分类号：TN915.03； TP393.03 文献标志码：A 文章编号：1009-6868 （2013） 05-0038-003

提出了一种SDN控制器——ZENIC，并给出了其架构。在控制、转发两个层面上，ZENIC 架构主要包括转发抽象层及驱动层、网络操作系统内核层、北向应用编程接口。ZENIC采用了统一的转发抽象层加特定转发驱动、接入和内联网络分层控制的特色架构设计，解决了多种设备接入和复杂网络控制的问题。

软件定义网络；OpenFlow协议；数据中心；未来网络

In this paper， we propose an SDN controller called ZENIC and describe its architecture. In the control and forwarding layers， ZENIC includes forwarding abstract layer， driver layer， network operating system kernel level， and northern application programming interface. A unified abstraction layer and specific forwarding drive combined with hierarchical control of access and Intranet can solve problems related to access of various devices and complex network control.

software-defined networks； OpenFlow； data center； future network

自斯坦福CleanState项目孵化OpenFlow协议，在2009年业界正式提出软件定义网络（SDN）以来，业界已经有上百家企业正式加入到开放网络基金会（ONF）。SDN的产品及样机覆盖了SDN控制器、交换机、路由、虚拟网络功能部件等产品，应用场景覆盖了数据中心网络、企业网、校园网、光网络及业务边缘网络等。迄今为止，SDN的功能架构在不同的领域，出于技术和利益博弈两个方面的原因，业界尚无统一的认识。一般来说，ONF定义的转发、控制、应用3层架构得到相对广泛的认同。

1 SDN架构

按照ONF的定义，SDN分为基础设施层、控制层和应用层[1]，见图1所示。虚拟化在基础设施以及控制层两个层面上实现，前者实现设备级的虚拟化，比如一个物理交换机支持多个逻辑交换机；后者实现网络级的虚拟化，首先是SDN控制器将整个网络当成一个逻辑的超级交换机进行管理控制，其次将物理资源进一步根据端口、媒体访问控制（MAC）地址、IP地址段等信息划分为多个虚拟网络

遵照传统通信领域的惯例，在架构图中下方为南，上方为北，因此基础设施层和转发层之间的接口称为南向接口。ONF标准化的是OpenFlow协议，互联网工程任务组（IETF）正在制订路由系统接口（I2RS）协议。控制层和应用层之间的接口称为北向接口，业界主流实现的是基于超文本传输协议（HTTP）的RESTful接口，具体编程接口随应用场景不同而有所区别。

在更广义的SDN架构中，控制层之上还有业务编排层，主要实现SDN域间资源的统一管理、SDN网络和其他资源的统一调度，比如OpenStack+SDN的数据中心解决方案。OpenStack统一调度计算、网络和存储资源，相当于SDN的业务编排层。站在SDN的角度来看，控制层之上如何划分则是厂商解决方案、应用实现的具体行为，就如同传输控制协议/网间协议（TCP/IP）并不关心应用层进一步如何分层设计，统称为应用层。

站在整个网路架构的层面来看SDN，则业界存在不同的看法：

（1）SDN只进行区域性网络改造，可将SDN控制域看成一个超级设备。SDN并不改变原有的网络横向接口，边界网关协议（BGP）/多协议标签交换（MPLS）等仍然有效。

（2）SDN控制域间定义专门/增强的SDN东西向接口，将SDN作为整个网络的控制平面。

本文认为，第一种方案更加具有现实意义，利于网络的平滑演进。第二种方案中的东西向接口要么可以通过扩充现有的BGP/MPLS协议实现，要么可以通过北向接口在业务编排层面进行实现，如果要定义更加专用的SDN东西向接口，虽然有可能可以增强整网的能力，但是无疑也为部署增加了难度，业界正在探索之中。

2 ZENIC架构及控制面

关键技术实现

现有来自于学术界的开源SDN控制器实现基于OpenFlow协议，整个转发模型也绑定于某个具体的OpenFlow协议版本[2-3]。对于商用系统而言，必须要考虑整个产品生命周期内协议接口的兼容，还要考虑不同应用场景的区别以及和多厂家、多协议接口的差别，因此SDN控制面必须设置一个兼容多版本OpenFlow、多种控制协议以及不同转发面能力的抽象层，我们称之为转发抽象层（FAL），在此之上为网络操作系统（NOS）核心以及应用层提供的接口是独立于具体的协议和硬件能力的。在OpenDaylight中，此层次称为业务抽象层（SAL）[4]。

本文实现一种SDN控制器——ZENIC，其架构如图2所示。图2自上而下主要包括协议栈、驱动和转发抽象层、NOS内核和应用层。

2.1 转发抽象层及驱动层

转发抽象层定义统一的转发控制接口，包括对抽象转发面的状态、能力、硬件资源、转发表、统计信息等进行读取/操作，相当于驱动的基类。同时转发抽象层还管理转发面驱动的实例，根据转发面接入时的基本能力协商加载不同的驱动实例，将转发面的控制连接绑定到相应的驱动实例。

每个具体设备的驱动实现转发抽象层的接口，完成不同接口协议、不同硬件能力到转发抽象层的统一适配。从控制面及其上层应用的角度来看，FAL提供了一个统一的转发操纵接口，但是由于各转发面的能力差别较大，应用对于转发面的操作存在失败的可能，因此FAL需要向应用提供转发面能力获取/协商的接口。

ZENIC已经实现对于OpenFlow 1.0/1.2/1.3的自适应协商。

2.2 网络操作系统内核层

NOS内核层是对网络、系统资源的管理，包括拓扑管理、主机管理、接口资源管理、转发表管理等，并管理物理拓扑、虚拟拓扑、转发表等构成的网络信息库。总体而言，内核层并无预设的网络转发逻辑处理，而是维护准确的网络拓扑、资源状态以及转发表的存储、合成，接受应用对于网络、资源状态的订阅以及应用对于网络资源、转发逻辑的操作。

拓扑管理的实现目前能够基于OpenFlow标准化的实现是基于控制器在链路上周期下发探测报文实现的，以太网一般是基于链路层发现协议（LLDP）实现。这样实现的好处是转发面完全无需感知，缺点是链路较多、检测定时器较短时，控制器的开销较高。另外一种方式是有转发面维护链路检测定时器，自行检测，将状态上报，这一实现方式的优点是控制面开销小，缺点是需要转发面具有一定的预设逻辑。

内核层不仅要维护网络节点、拓扑状态，而且也需要收集基本的主机位置、状态，从而可以给应用提供一个完整的网络视图，进一步做转发、业务的决策。

对于SDN控制器而言，网络虚拟化应该内置支持。虚拟化首先是转发面资源的分区和隔离，比如按照端口、逻辑端口、主机MAC地址、IP地址段等进行虚拟网络的划分，其次是虚拟拓扑对于其上客户/应用的权限管理适配。

OpenFlow的流表模型以及对于交换机统一、扁平化的管理视图带来了很多问题，包括交换机硬件复杂化、不灵活、主机和网络需紧耦合[5]。在ZENIC系统中，将内联网络管理作为内核服务之一，解耦接入网络和互联网络。内核管理互联网络的封装格式，上层应用只需要决策SDN控制域内两个接入端口的位置和策略。内核计算出完整端到端路径，并在接入侧将转发决策映射到互联网络路径的封装标签。ZENIC支持多种互联网络封装格式，包括MPLS、虚拟局域网（VLAN）等，下一步将支持虚拟扩展的局域网（VXLAN）/通用路由封装协议（GRE）。这种接入-互联网络的模式，应用完全无需感知，专注于主机接入侧的策略。同时内连网络管理本身也可以开放接口，支持应用自定义的路由算法和策略。

2.3 北向应用编程接口

北向应用编程接口（API）在不同的应用场景中需求不同，对于封装的要求也有区分。如果将网络的原子能力暴露给应用，是有可能形成统一的API，但是由于缺乏封装和易用性，应用编程、实现的复杂度较高。比如有厂商实现的设备级开放API多达700多个，涵盖几乎所有协议和设备功能，但是对于SDN而言，将会面临至少两类应用，需求迥异：

（1）专业网络应用

订制化需求高，需要更加细节的API，对底层网络的操作操纵能力强，比如订制开发路由协议、订制进行精细化的流量调度。

（2）普通应用

将网络作为一种服务，只是请求网络为应用提供服务，并不关心网络细节。

对于后者，北向接口最好能封装几个模型和交互简单、易懂的服务接口，如向网络请求创建从交换机A端口1到交换机B端口2的一条1 Gb/s有带宽保证的通路，而不是由应用向路径上的交换机逐个下发转发表以及相应的队列配置参数。

还有一种北向接口的思路就是由应用定义自身对网络的需求和操作接口，网络厂商提供插件实现应用的网络接口。比较典型的是OpenStack的Quantum组件，其定义了网络的API，由各个厂商提供Quantum Plug-In来控制自己的SDN控制器或网络设备。此架构相当于把SDN的北向接口标准化工作往上推到应用，网络去适配应用需求。

两种思路各有利弊，由SDN定义北向接口比较理想化，试图统一解决所有问题，但是网络很难一一理解应用的需求，标准化的推进工作相对困难，而且易用性也很难保证；应用驱动的模式使得SDN落地更加容易，但是应用和多厂商网络之间的互通要较耗费更大代价。ZENIC提供基本的细颗粒度的底层API，同时提供封装后的虚拟网络API，目前已经提供OpenStack的Quantum Plug-In接入到OpenStack之中。

2.4 分布式处理算法

控制面本身的分布式架构以及SDN转发控制分离的架构带来了状态同步的额外开销，准确的SDN全局视图能够保证决策的精确性和实时性，对于负载均衡等应用而言可以提升资源利用率，但需更加频繁的信息同步，这大大降低了系统性能[6]。本文从设计上采用两种手段：控制器的分布式方案尽可能减少消息的复制；控制转发之间的状态同步由用户根据需求进行配置，只进行必要、够用的状态复制。

传统的集群网络系统控制面基本上是基于进程的分布式处理，比如各个不同的业务进程分布在不同的CPU上，但是一种进程仍然是单实例或少数实例，并行度受限。在单一业务进程突发负载的情况下，比如自治域间路由调整时的边界网关协议（BGP）进程就是“瓶颈”。对于SDN而言，由于控制的网络规模可能远远高于集群路由器，对控制面节点数量的要求更高，因此这种方法存在“瓶颈”不太可行。

分布式哈希表（DHT）算法提供了一个可伸缩的分布式数据存储/路由算法。对于传统应用不稳定网络的Log2（N）查找复杂度的算法，在数据中心、电信网络应用时，业界提出了多种增强的单跳算法，部分基于单跳DHT的增强型结构化查询语言系统（No-SQL）开源系统也已经过商用考验，包括Dynamo、Cassandra等，最早公开采用DHT分布式算法的SDN控制器是onix[7]，OpenDaylight项目近期也提出来采用Cassandra作为底层的分布式数据库系统。作者所在团队也实现了改良的单跳DHT算法[8]。

DHT算法基于一致性哈希，适用于键-值（Key-Value）存储模型，类结构化查询语言（SQL）的支持需要进一步封装。对于SDN控制器而言，拓扑信息是全局性的，不适合于DHT存储，而是需要进行额外的全局复制。与转发设备相关的信息组织以交换节点为单位进行分布式储存，可以满足基本要求，但是颗粒度较粗，不利于控制节点之间的负载均衡。主机信息可以按IP地址、MAC表两个维度进行分布化，更加均匀。

3 转发层面的转发抽象

技术实现

OpenFlow 1.0提供的是一个单流表的抽象模型[9]，OpenFlow 1.1之后定义了一个多级流表的模型。I2RS以及部分厂商的开放接口给应用暴露的是一个路由信息库（RIB）之上的多种业务表，表之间隐含了协议规定的各种逻辑。OpenFlow给了应用/控制面对转发面最大程度的操纵能力，理论上可以完全不受现有网络协议的限制，转发面可以是完全傻瓜化指令执行引擎，而其他开放API则是现有协议框架下的开放API，有严格的限定条件。

OpenFlow1.0非常简单，但是需要三态内容寻址存储器（TCAM）的支持，而TCAM价格相对较昂贵，同时其单表结构使得复杂转发逻辑的分解很困难。在现有基于专用集成电路芯片（ASIC）的交换机上，OpenFlow 1.0可以很容易地映射到ACL流水线之上，因此目前市场上支持OpenFlow的以太网交换机绝大多数都是只支持OpenFlow 1.0。

OpenFlow 1.x提供了多级流表模型[10-11]，增加了更多的表匹配字段和指令类型，能力越来越强，但是离现有交换机ASIC的能力越来越远。软件交换机可以容易地实现OpenFlow 1.x的多表模型。硬件交换机可以通过将自身的传统ASIC流水线进行一些必要的封装，形成多级流表上报给控制面，由控制面进行适配，只下发转发面支持的指令和表结构。这对转发面和控制器均提出了更高的要求。业界也有少数厂商推出了可配置TCAM流水环节的ASIC，这些将固定宽度的TCAM查表处理单元分解成更小的分片，比如每32比特TCAM是一个基本分片。应用可以灵活定义多个分片构成一级OpenFlow流表，从而支持了OpenFlow的多级流表模型。应用可以将L2交换、L3交换/路由、ACL等分解到不同的流表上实现，从而避免了超长单一流表关键字带来的不必要的TCAM开销。

4 结束语

SDN通过采用转发控制分离、集中控制的理念改造网络，试图将转发设备改造为简单的受控转发设备，将智能留在纯软件化的SDN控制器之中，使得网络的创新更加快速、简单，这带来了开放的产业链和新的技术变革的机会。本文描述了作者及其团队对于SDN相关关键技术的研究成果及SDN控制器产品实现架构，并阐述了各种对比方案的优劣势。

参考文献

[1] Open Networking Foundation. Software-defined networking： The new norm for networks [R]. White Paper. ONF， 2012.

[2] GUDE N， KOPONEN T， PETTIT J， et al. NOX： Towards an operating system for networks [J]. ACM SIGCOMM Computer Communication Review， 2008，38（3）：105-110.

[3] NOX [EB/OL]. [2013-02-18]. http：//www.noxrepo.org/

[4] Open daylight project [EB/OL]. [2013-02-18]. www.opendaylight.org

[5] CASADO M， KOPONEN T， SHENKER S， et al. Fabric： A retrospective on evolving SDN [C]//Proceedings of the 1th ACM Workshop on Hot Topics in Software Defined Networks （HotSDN12）， Aug 13， 2012， Helsinki， Finland. New York， NY， USA：ACM， 2012： 85-90.

[6] LEVIN D， WUNDSAM A， HELLER B， et al， Logically centralized？ State distribution trade-offs in software defined networks [C]//Proceedings of the 1th ACM Workshop on Hot Topics in Software Defined Networks （HotSDN12）， Aug 13， 2012， Helsinki， Finland. New York， NY， USA：ACM， 2012：1-6.

[7] KOPONEN T， CASADO M， GUDE N， et al. Onix： A distributed control platform for large-scale production networks [C]//Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation（OSDI10）， Oct 4-6， 2010， Vancouver， Canada. Berkeley， CA， USA： USENIX Association， 2010：1-6.

[8] HU Yongsheng， WANG Jun， HAO Zhenwu， et al. A reliable searching and broadcasting scheme in large-scale structured peer-to-peer system [C]//Proceedings of the 4th IEEE International Conference on Broadband Network and Multimedia Technology （IC-BNMT11）， Oct 28-30，2011， Shenzhen， China. Piscataway， NJ， USA： IEEE， 2011：324-328.

[9] OpenFlow switch specification 1.0.0 [S]. Open Networking Foundation， 2011.

[10] OpenFlow switch specification 1.2 [S]. Open Networking Foundation， 2011.

[11] OpenFlow switch specification 1.3.1 [S]. Open Networking Foundation， 2012.