软件定义网络发展历程及面临的挑战

顾 强，张庆顺，臧 军（山东省邮电规划设计院有限公司，山东济南250101）

1 概述

现正在运行的互联网体系构架已经有40 多年的历史，在技术发展日新月异的现代社会已经可称得上是一个奇迹。随着网络规模的急速膨胀和业务类型的不断丰富，数据平面和控制平面紧密耦合这一特点成了网络发展的瓶颈，导致网络管控难度日益增加，新功能难以快速部署。云计算、云存储的快速发展对网络可编程控制能力提出了异常迫切的需求，由于现有网络设备多由厂家封闭的系统实现，对网络可编程控制能力的支持也极为有限。这促使人们开始思考网络体系构架的变革，可编程网络成为网络体系构架变革的主要方向，特别是软件定义网络（SDN），作为一种全新的网络构架，将控制平面和数据平面分离，大大提高了网络管控的灵活性，便于新业务的快速部署。

IETF和IRTF等标准化组织在SDN方面已经开展了一些卓有成效的工作。近几年ONF 提出的Open⁃Flow协议［1］和以OpenFlow协议为基础的SDN［2］引起了学术界与产业界的极大关注。

本文以SDN 发展历程为主线，介绍了SDN 的构架、最新进展和面临的挑战。

2 S D N发展历程

2.1 可编程网络技术的萌芽

20 世纪60 年代出现的互联网迅速获得了广泛应用，其尽力而为的理念和受限的带宽一直影响着用户体验。90 年代异步传输模式（ATM）的广泛应用为互联网提供了有保障的连接和相对充裕的带宽，互联网也因此获得了快速发展，同时也凸显了传统互联网封闭网络构架的局限性，促使学者对互联网构架重新审视和思考，提出了控制平面和数据平面解耦、可编程网络的概念，集中出现了一些可编程网络实践的案例。

2.1.1 Open Signaling

Open Signaling 工作组（OPENSIG）成立于1995年，致力于通信硬件设备和相应的控制软件分离来促进ATM 网、互联网、移动网更加开放，更具扩展性，可编程［3］。这一想法得到了IETF的支持，在IETF内部成立了专门的工作组负责通用交换机管理协议（GSMP）建议文档的起草。随着ATM技术的落伍，这个工作组被关闭，最新协议为2002年6月制定的GSMP V3。

2.1.2 Active Networking

同样在20 世纪90 年代中期，Active Networking 这一概念被提出，其首创性地提出网络基础设施通过可编程来适应定制化的业务需求［4］。这种网络有2个概念引起了大家的注意。

a）用户可编程的网络设备，设备配置有带内或者带外的控制信道。

b）带有控制信息的数据包，数据包内带有路由器或交换机可以执行的指令。

这样用户就可以通过带内或带外专门的控制信道来对业务经过的网络设备编程，以便网络更好地适配业务。由于安全和性能表现等方面的原因这种网络没能获得广泛的应用。

2.1.3 DCAN

为加强对ATM 网络的管理和增强其扩展性，DCAN（Devolved Control of ATM Networks）也在20世纪90 年代中期应运而生［5］。其主张ATM 网络的管理功能从ATM 设备中解耦出来，成为独立的功能实体，DCAN 定义了这2 个功能实体之间的通信协议。SDN转发、控制平面分离的理念也来源于此，目前的SDN实现方案仍然通过这种方式实现对ATM 和其他异构网络的管理和控制。

2.2 可编程网络技术的发展

进入21 世纪，随着千兆以太网技术的广泛应用，ATM技术也逐渐没落，传统互联网的局限性因为新技术的支撑而被暂时弱化，但是人们对可编程网络的研究仍在继续。

IETF 在完善现有网络体系构架理念指导下继续进行可编程网络研究，2003年开始的转发与控制分离（ForCES）的路由器体系结构［6］研究已经完全具备了SDN 的理念；2006 年，IETF 网络配置协议工作组提出了NETCONF［7］协议，其主要实现对网络设备配置的修改，利用这组协议，网络设备通过标准的API来接收和发送设备配置。NETCONF 协议也是目前SDN 南向接口协议之一，最新协议于2011年6月出版。

宽带接入和移动通信业务需求持续增长，网络创新研究也日趋活跃，人们认识到传统互联网的固有问题很难在原有体系下解决，美国国家自然基金会（NSF）在网络体系创新理念指导下资助了一些研究，提出了重塑互联网的思路，这些研究直接促使基于OpenFlow协议为基础的SDN产生。

2.2.1 4D Project

2004 年4D Project 开始实施，倡导重新设计的理念，强调把路由决策逻辑与调节网元之间交互的协议分开［8］。其强调4 个平面：决策平面用于处理网络控制；扩散平面提供1个连接路由器或交换机的健壮、高效的通信基础结构；发现平面用于在网络中发现物理网元并创建逻辑标识识别它们；数据平面基于决策平面产生的状态来处理报文。这一理念直接影响着后续的一些研究工作，如NOX 所提出的用于OpenFlow网络中的网络操作系统。

2.2.2 SANE/Ethane

NSF 资助启动了重塑互联网的项目——Clean-Slate Design for Internet，该项目摈弃传统的渐进叠加和向前兼容的原则，重新设计互联网体系构架。这一计划由斯坦福大学主导，研究目的定位于实现控制和转发分离并加快网络创新，一个名为SANE/Ethane 的项目［9-11］成果意义非凡。2006年这个项目定义了一种用于企业网的新型网络构架，采用集中式的控制器来管理网络中的策略和安全，并对接入的设备进行身份认证。就像现在的SDN构架，有集中式的控制器来决定如何进行数据包的转发，有内置流表只进行数据包转发的交换机，交换机和控制器之间通过安全通道连接。这一项目被认为是目前基于OpenFlow 协议SDN的直接原型。

3 S D N构架

经过多年持续不断的研究，SDN 取得了巨大进展，作为一种全新的网络构架，其具备2 个特点：把执行转发的硬件部分从控制决策部分中分离出来，成为只完成数据包转发的数据平面，控制决策部分成为独立的控制平面；控制平面和数据平面之间通过开放的接口进行编程控制［12］。控制平面和数据平面分离大大提高了网络管控的灵活性，便于新业务的快速部署。传统互联网和SDN构架的区别如图1所示。

图1 传统互联网和SDN构架对比

目前体系构架比较完整的是IETF 提出的ForCES路由器体系结构和ONF 提出的以OpenFlow 协议为基础的体系结构，下面对2 种比较有代表性的SDN 进行简略介绍和比较。

3.1 ForC ES 的路由器体系结构

ForCES 的路由器体系结构由IETF 提出及标准化，网络设备内部分为控制单元（CE）和数据转发单元（FE），CE 和FE 通过ForCES 协议进行通信。在FE 中定义了逻辑功能模块（LFB），LFB 及其属性都是由CE通过ForCES协议进行控制，各LFB之间通过数据通道相互连接，该连接关系也由CE通过ForCES协议定义，以形成不同的LFB 拓扑结构，进而实现资源动态配置，完成各种不同类型的网络服务［13］。这个体系便于现有的控制平面能对新加入的第三方数据转发设备进行控制，实现现有网络对没有控制平面的数据转发设备的兼容。虽然控制功能和数据转发功能是分开的，但是仍然紧密耦合在同一个设备实体中。

从2003 年开始有关ForCES 体系结构标准化的文档陆续发布，主要包括：ForCES需求（RFC3654）、ForC⁃ES 框架（RFC3746）、ForCES 协议及扩展（RFC5810、RFC791）、ForCES 模型及扩展（RFC5812、RFC7408）、ForCES适用性声明（RFC6041）、ForCES逻辑功能模块库（RFC6956）［13］。目前ForCES 工作组仍然在对ForC⁃ES体系结构相关标准进行研究。

3.2 以O penFlow协议为基础的体系结构

ONF提出的SDN构架如图2所示。所有业务逻辑均部署在应用平面，并通过开放的API 与控制平面相连；控制平面由集中设置的软件控制器组成；数据平面由数据转发设备组成；为保证网络的扩展性，南向接口除OpenFlow协议外也提供了对其他协议的支持。

图2 ONF提出的SDN构架

OpenFlow 协议作为目前成熟度最高的南向接口协议得到了产业界广泛支持。OpenFlow 交换机规范明确定义了交换机组成和OpenFlow 协议在交换机中的实现方式。OpenFlow 规范中定义的交换机结构如图3 所示。OpenFlow 交换机内包含1 个或多个流表（Flow Table）和1 个组表（Group Table），以及与Open⁃Flow 控制器进行通信的安全通道接口。为避免单流表过度膨胀，在OpenFlow 协议1.1 以后的版本引入了多级流表机制。

图3 OpenFlow交换机结构图

OpenFlow 协议1.0［14］、1.1［15］、1.2［16］版本中每个流表项包含匹配域、计数器及1组指令，每个数据包包头的信息与匹配字段匹配，如果匹配则执行这个流表后面定义的指令。如果这个交换机里所有流表均不能匹配，则把这个数据包的包头或整个数据包通过安全通道上交给OpenFlow 控制器，由OpenFlow 控制器决定这个数据包如何转发，并生成流表通过安全通道下发到相应OpenFlow交换机，OpenFlow交换机就可以正确转发这个数据包了。计数器对经过交换机的数据包进行分类计数，以满足各种统计管理。在OpenFlow协议1.3［17］、1.4［18］版本中流表又增设了优先级、超时设定、保留字段等参数。OpenFlow 协议流表结构如表1所示。

在OpenFlow协议1.0版本中流表匹配域共包含12个字段：输入端口、MAC 源地址、MAC 目的地址、以太网类型、VLANID、VLAN 优先级、IP 源地址、IP 目的地址、IP、IP ToS 位，TCP/UDP 源端口和TCP/UDP 目标端口。OpenFlow协议1.1版本中增加了对VLAN和MPLS标签的处理。OpenFlow协议1.2版本中规定下发流表的匹配字段不再通过固定长度的结构来定义，而是采用TLV（Type、Length、Value）结构定义，称为OpenFlow扩展匹配（OXM），这样在增加更多关键字匹配字段的同时也节省了流表空间。OpenFlow协议1.3版本中流表支持的匹配字段已经增加到40 个。这样就可以跨越物理层、介质层、网络层、应用层4 个层级对字段进行匹配，每个字段都可以通配，字段之间可以任意组合，数据报文以流为基础进行匹配转发，而不是像传统互联网以数据包为基础进行匹配转发，大大提高了转发效率，而且更加灵活。

表1 OpenFlow协议流表结构

OpenFlow 控制器利用OpenFlow 标准通过安全通道对OpenFlow交换机内的流表进行添加、修改、删除、查询等操作，最终完成各种网络行为。

3.3 2种体系结构的总结对比

以上2 种体系结构都遵循了SDN 基本的原则：控制平面和数据平面相分离；控制平面与数据平面之间通过开放的接口和标准的协议进行交互。虽然2种网络的目标是一致的，而且实现的功能也比较相似，但是两者之间在应用场景、控制平面和数据平面内部结构、接口协议、转发模型等方面存在很大差异。

以ForCES 为基础的体系结构得益于传统网络设备制造商的支持，标准化工作起步较早，目前已经具备了较为完善的标准体系，其目的是兼容新的网络构架，对现有网络的影响短期难以显现。以OpenFlow协议为基础的体系结构是一种崭新的构架，激发了研究机构、新兴网络设备制造商的浓厚兴趣，2009 年发布的可用于商业化产品的OpenFlow协议1.0版本至今已经取得了令人瞩目的成果，在网络实验测试平台、校园网、数据中心、流量工程、无线接入网络、光网络等场景均有优异表现，以至于很多人把以OpenFlow协议为基础的体系结构认为是SDN的事实标准。

4 S D N面临的挑战

OpenFlow 协议的出现和发展带动SDN 研究进入新的阶段，但在诸多方面仍面临巨大挑战。

近几年业界对SDN表现出极大热情，综合来看其发展仍然在完善标准制定、典型应用开发测试阶段，以OpenFlow 协议为基础的SDN 如何在完善自有协议体系的基础上兼容传统互联网仍是一个难题［19］。

尽管支持OpenFlow 协议的ASIC 芯片设计广受关注，但是目前仍然没有一款专用芯片出现。一方面是SDN 的技术标准尚未成熟，另一方面是芯片生产厂商并不完全认可学术界对支持OpenFlow 协议ASIC芯片的设计。这些原因都决定了芯片生产厂家暂时不会对SDN 专用芯片的开发投入太多，而是采取折中方案，在传统芯片的基础上增加支持SDN 的功能［20-21]。这就造成目前OpenFlow交换机流表容量、流表学习速度、流表转发速率、转发时延等关键指标总体表现不佳，不同厂商的设备差异极大，难以达到商用标准。

人们把SDN中的数据平面、控制平面和应用平面分别类比成计算机中的硬件平台、操作系统和应用软件。操作系统的重要性不言而喻，SDN 控制平面作为网络操作系统面临着可扩展性、处理能力和安全性等方面的挑战［20，22］。作为控制器之间交互的东西向接口标准仍在研究制定过程中，只有东西向的接口标准成熟后才能使SDN从数据中心、企业校园网等有限场景应用走向全网普遍应用；连接应用平面的北向接口仍然没有形成广泛认可的标准，业界虽然希望以REST⁃ful作为北向接口，采用模型、模板的方式，通过每个厂商公布自己的模型，实现互通和控制［19］，但是这种思路必须在规模应用测试后才能明朗。

5 结束语

SDN 研究进展得如火如荼，得到网络设备生产商、网络运营商以及互联网服务商的广泛关注，这将改变网络设备厂商的竞争格局，导致整个网络设备产业的变革。目前SDN相关技术还不够成熟，不同利益集团仍在博弈，但可以预见的是，以往那种封闭的技术路线肯定会改变，网络系统构架肯定会变得更加灵活，以便能够支持日益丰富的网络应用。

［1］ OpenFlow［EB/OL］.［2015-06-12］. https：//www.opennetworking.org/sdn-resources/openflow.

［2］ ONF White Paper Software-Defined Networking：The New Norm for Networks［EB/OL］.［2015-06-12］. https://www.opennetworking.org/component/content/article/46- sdn- resources/sdn- library/whitepa⁃pers/816-software-defined-networking-the-new-norm-for-net⁃works.

［3］ A.T.Campbell，I.Katzela，K.Miki，et al. Open signaling for atm，inter⁃net and mobile networks（opensig’98）［J］.ACM SIGCOMM Comput⁃er Commun.Review，1999,29（1）：97-108.

［4］ D.L.Tennenhouse，J.M.Smith，W.D.Sincoskie，et al. A survey of ac⁃tive network research［J］.IEEE Commun.Mag.，1997，35（1）：80-86.

［5］ Devolved Control of ATM Networks［EB/OL］.［2015-06-12］.http：//www.cl.cam.ac.uk/research/srg/netos/old-projects/dcan/#pub.

［6］ RFC 5810 Forwarding and Control Element Separation（ForCES）Pro⁃tocol Specification［S/OL］.［2015-06-12］. http://tools.ietf.org/htm l/rfc5810.

［7］ A.Greenberg，G.Hjalmtysson，D.A.Maltz，et al. A clean slate 4d ap⁃proach to network control and management［J］. ACM SIGCOMM Computer Commun.Review，2005，35（5）：41-54.

［8］ RFC 4741 NETCONF Configuration Protocol［S/OL］.［2015-06-12］.http://tools.ietf.org/html/rfc4741.

［9］ M.Casado，M. J.Freedman，J. Pettit，et al. Ethane：Taking control of the enterprise［J］. ACM SIGCOMM Computer Commun.Review，2007，37（4）：1-12.

［10］黄韬，刘江，魏亮，等. 软件定义网络核心原理与应用实践［M］.北京：人民邮电出版社，2014.

［11］Azodolmolky，Siamak.软件定义网络——基于Openflow 的技术揭秘［M］. 徐磊，译.北京：机械工业出版社，2014.

［12］Nunes，Bruno，Manoel Mendonca，et al.A survey of software-defined networking：Past，present，and future of programmable networks［J］.Communications Surveys & Tutorials，IEEE 16，2014（3）：1617-1634.

［13］RFC 6956 Forwarding and Control Element Separation（ForCES）Log⁃ical Function Block（LFB）Library. June 2013［S/OL］.［2015-06-12］.http：//www.ietf.org/rfc.htm l.

［14］OpenFlow Switch Speci_cationVersion 1.0.0（Wire Protocol 0x01）De⁃cember 31，2009［S/OL］.［2015-06-12］.http://archive.openflow.org/documents/openflow-spec-v1.0.0.pdf.

［15］OpenFlow Switch Speci_cationVersion 1.1.0 Implemented（Wire Pro⁃tocol 0x02）February 28，2011［S/OL］.［2015-06-12］.http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf.

［16］OpenFlow Switch SpecificationVersion 1.2（Wire Protocol 0x03）De⁃cember 5，2011［S/OL］.［2015-06-12］. http://archive.openflow.org/documents/openflow-spec-v1.2.pdf.

［17］OpenFlow Switch SpecificationVersion 1.3.4（Protocol version 0x04）March 27，2014［S/OL］.［2015-06-12］.http://archive.openflow.org/documents/openflow-spec-v1.3.4.pdf.

［18］OpenFlow Switch SpecificationVersion 1.4.0（Wire Protocol 0x05）Oc⁃tober 14，2013［S/OL］.［2015-06-12］. http://archive.openflow.org/documents/openflow-spec-v1.4.0.pdf.

［19］赵慧玲，史凡. SDN/NFV 的发展与挑战［J］. 电信科学，2014，30（8）：13-18.

［20］Kreutz，Diego，Fernando MV Ramos，et al.Software-defined network⁃ing：A comprehensive survey［J］. proceedings of the IEEE 103，2015（1）：14-76.

［21］宋菲，侯乐青. SDN 技术挑战及发展趋势［J］. 信息通信技术，2015（2）.

［22］Sezer，Sakir，Sandra Scott-Hayward，et al.Are we ready for SDN?Im⁃plementation challenges for software-defined networks［J］.Communi⁃cations Magazine，IEEE 51，2013（7）：36-43.