SDN初探

樊勇兵，冯 明，陈 楠，何晓武

（1.中国电信股份有限公司广州研究院 广州510630；2.中国电信集团公司 北京100032）

1 SDN的产生及其概念

2006年，在斯坦福大学主导的Clean-Slate Design for the Internet项目中，Martin Casado博士及其团队成员提出了Ethane架构，被认为是软件定义网络（software-defined networking，SDN）概念和技术的发展源头。在此基础上，2007年，Martin联 合McKeown N教 授 （斯 坦 福 大 学）、Shenker教授（加州大学伯克利分校），共同创建了致力于网络虚拟化的Nicira公司，并提出了SDN的概念。但是，也有人说，SDN的概念最早是由Greene K于2009年在Technology Review网站上评选年度十大前沿技术时提出的。2008年，Nick等 人 发 表 文 章“OpenFlow：Enabling Innovation in Campus Networks”[1]，完整地提出了实现SDN的OpenFlow框 架。2011年，开 放 网 络 基 金 会（Open Networking Foundation，ONF）在Nick等人的推动下成立，专门负责OpenFlow规范的维护和发展。在此过程中，随着互联网公司的介入，尤其是Google的成功实践，OpenFlow几乎成为SDN和下一代网络的代名词。

2012年，Nicira被VMware收购。有趣的是，被收购后的Nicira很快将其研发方向从基于OpenFlow的SDN转向了基于Overlay的SDN。至于其原因，按Martin的说法，“前者更适合于流量工程，后者更适合于数据中心网络”。笔者分析，这其中隐藏的一个重要原因也许是VMware需要构建和强化一个以服务器虚拟化为核心的、端到端的生态链，摆脱对传统网络设备厂商的依赖。

为了迎接新的技术挑战，代表互联网设备厂商的最重要标准组织IETF也在2011年的第82次会议上设立了SDN BoF。不 过 此SDN不 是 彼SDN，这 里 的SDN是software-driven networking的缩写。与OpenFlow强调控制与转发物理分离不同的是，software-driven networking的目标是通过在应用与网络控制层之间引入一个通信框架，使现有控制平面变得更灵活并且允许快速可靠的配置更改。该BoF结束后IETF于2012年5月、11月分别设立了与SDN相关的网络虚拟化叠加 （network virtualization overlay，NVO3）、路由系统接口（interface to the routing system，I2RS）工作组。从NVO3和I2RS所面向的问题域来看，后者更像是上述BoF的继承产物。同年，IRTF设立了SDN研究组（这里的SDN又恢复了software-defined networking的拼写，但从该研究组发布的草案draft-sin-sdnrg-sdn-approach-03[2]和I2RS的已有工作看，它仍然在沿着software-driven networking所定义的目标前进）。其实，IETF历史上的某些工作，也有与SDN在理念上有相通之处的，如早在2001年即已成立的转发与控制元素分离 （forwarding and control element separation，ForCES）工作组。

作为基础网络的最大玩家，运营商也在ETSI的旗帜下聚集，成立了 “网络功能虚拟化”的行业规范组（“Network Functions Virtualization”Industry Specifications Group，NFV ISG），并于2012年10月发布了NFV白皮书[3]，描述了遇到的问题以及初步解决方案。NFV没有使用SDN这个字眼，但通常被认为是运营商的SDN。NFV与OpenFlow、I2RS等有明显不同的诉求。

综上所述，SDN还是一个新生儿，流派众多，流派之间差异巨大，对它进行统一定义很困难。这里选取几个有代表性的定义。

ONF对SDN的定义[4]：SDN是一种网络控制层与转发层分离、并可直接编程控制的新兴的网络架构。这种架构将控制层从网络设备转移到了计算设备，使得底层的基础设施对于应用和网络服务而言是透明抽象的，网络可被视为一个逻辑或虚拟实体。

IETF对SDN的定义[2]：SDN是一类技术的集合，这些技术以确定、动态、可扩展地方式，使得网络服务的设计、交付和运行更加便利。这样的定义假设在整体服务交付和运行过程中高层次、自动化地引入。因为网络本质上是软件驱动（software-driven）的，此定义并不强调贴上SDN标签的那些解决方案所宣称的“软件定义”（software-defined）属性。

ETSI的NFV对SDN的定义[3]：NFV的目的是以不断发展的标准IT虚拟化技术，将许多网络设备类型（它们可能位于数据中心、网络节点或最终用户的前端）整合到工业标准的高容量服务器、交换机和存储中，以转换网络运营商的网络架构方式。它涉及网络功能的软件实现，这些实现可以运行在工业标准的服务器硬件上，可以按需在不同位置间移动，或在不同位置进行实例化，而不必安装新设备。NFV与SDN的关系是互不依赖，互为补充。

2 SDN的几种主要技术实现

2.1 基于OpenFlow的SDN

正如Nick在参考文献[1]中所感叹的，互联网的极大成功，一方面使网络研究者的工作显得越发重要，另一方面又使这些研究者对网络施加影响的机会愈加遥远，这是因为生产网络环境中那些商业解决方案封闭、昂贵、不灵活，整个产业链的创新周期漫长。因此，OpenFlow提出的初始目标是单一而单纯的：作为研究者，如何在园区网中运行实验？随着OpenFlow的前期成功，4年之后，ONF在参考文献[4]中高调地将SDN称为“网络的新范式”，并将其用例扩展到园区、数据中心、云环境、运营商和SP网络，问题域也扩展到现行互联网产业链的更多方面。

OpenFlow的思路很简单：整个系统由OpenFlow交换机（OF switch）和控制器（OF controller）组成，二者通过安全通道（如SSL）以OpenFlow协议进行交互。控制器负责生成、维护和下发流表（flow table），交换机接收流表并且只按照流表进行转发。流表由匹配域（match field）、指令集和计数器3部分组成，匹配域规定匹配输入报文的字段，指令集决定匹配后的报文如何转发，计数器管理所需。最基本的转发行为包括转发给交换机的某个端口、封装改写报文后转发给控制器以及丢弃。OpenFlow概念架构如图1所示。

图1 OpenFlow概念架构

OpenFlow 1.0定义的流表，其匹配域包含了10个关键字（如图2所示），并且支持通配符；OpenFlow 1.1增加了对MPLS以及UDP等协议的支持，同时引入了多级流表，并增加分组策略功能。通配符的采用使网络运营商可以根据不同字段聚合不同粒度和属性的流；多级流表有效改善了原始流表设计开销过大的情况。随着版本的演进，流表支持的关键字和功能越来越多。

图2 OpenFlow 1.0流表结构

上述架构对于二层交换设备而言，意味着MAC地址的学习、VLAN和基本的3层路由配置都由控制器实现并以流表的形式下发给交换机；对于3层路由设备，各类IGP/EGP也是运行在控制器之上并以流表的形式将路由表下发给相应的路由器。简言之，理想情况下，所有网络设备都抽象成了逻辑上等价的、按流表转发的通用交换机。

OpenFlow架构的特性可以简单总结如下：软件与硬件分离；控制与转发分离；逻辑集中的控制器拥有全网视图和控制；物理分布的交换机根据控制器下发的流表进行转发；理想情况下交换机是系列化、标准化的，其与控制器之间的交互协议是开放、标准的。因此，流表处理器和控制器软件系统将成为该架构的两个最核心组件，交换机不可避免地低值化。

2.2 IETF的SDN

（1）I2RS[5]

I2RS是一种机制，该机制通过一个外部控制平面，以开放接口与传统路由系统的分布式控制平面中的单个设备进行交互，从而对分布式控制平面进行加强。这是一种介乎传统方式和完全取代分布式控制平面而直接配置设备之间的折中方案。

路由系统包括了控制平面协议和用于为报文计算路由和路径的进程，不管这些协议和进程在何处实现。

I2RS通过基于协议的控制或管理的接口集，促进与路由系统的实时或事件驱动的交互，这使得信息、策略和操作参数能被注入路由系统中，也可以从路由系统中读取这些信息。I2RS接口也将支持与现有的配置管理系统及其接口共存。I2RS接口的用户可以是管理应用程序、网络控制器和在网络上实现特定需求的用户应用程序。

I2RS的关键用例包括如下几项。

·与RIB（routing information base，路由信息数据库）的交互。允许对RIB的读写访问，但不允许直接访问FIB（forwarding information base，转发信息数据库）。

·BGP操作的控制和分析，包括相关策略的设置和启用。

·基于由动态控制平面所提供的更多信息的控制、优化和流量出口选择。

·针对网络攻击的分布式响应，通过快速修改控制平面行为，对流量进行重路由。

（2）VXLAN[6]

叠加（overlay）方案有多种，VXLAN是目前最新、商业支持较多、针对性较强、影响力也比较大的一种。

服务器虚拟化的出现对物理网络提出了新的要求，原有网络技术或设备出现了严重的不适应：单一管理域内将出现更多的MAC地址；ToR交换机的表容量不足；多租户场景下可能产生私有MAC地址、私有VLAN编址空间的冲突；传统网络隔离手段VLAN所支持的4 096个VLAN ID严重不足，实现无环拓扑的STP有重大缺陷；需要在3层网络上维持虚拟机间的二层通信模型等。以上就是VXLAN试图解决的问题。

VXLAN的基本原理是建立基于UDP的隧道：隧道端点称为VTEP，源VTEP将源VM发出的原始二层以太帧以VXLAN分组头格式封装在UDP报文中，发送给目的VTEP，VXLAN分组头中的24 bit VNI用于标识一个被封装的二层网络。VTEP可以位于物理服务器的VMM、物理服务器中，也可以位于物理交换机中；VTEP可以通过软件实现，也可以通过硬件实现。

控制信息（内层源VM MAC到外层源VTEP IP的映射）的建立有3种方式：通过数据平面进行学习（类似于普通以太网）；push方式（某个中心目录将这种映射推送到VTEP上）；pull方式（每个VTEP主动到一个中心目录上查找）。

如通过数据平面学习控制信息，VXLAN底层物理网络需要支持多播，因为VXLAN网段内部的广播通过多播实现。每个VNI对应一个多播组，这需要一个VNI到IP多播组的映射，该映射通过管理通道提供给每个VTEP。VTEP得到该配置后通过与上游交换机（或路由器）交互IGMP成员报告消息来动态加入或离开相关的多播组。

特点：通过24 bit的VNI，极大地扩展了传统VLAN的地址空间；不同VNI域的MAC地址空间可重叠；通过VNI内部的VLAN可进一步支持同一租户内的隔离；外层VLAN亦可与VNI协同工作，一个用例是所有VXLAN流量都运行在底层网络的同一VLAN中，以达到VXLAN流量与传统流量的隔离；基于IP的封装，使底层网络可以是二层的，也可以是3层的；基于UDP的封装，通过UDP源端口号可以实现更细粒度的负载均衡；VNI到其对应多播组的映射需要通过管理平面配置，如通过数据平面学习控制信息，需要底层网络支持多播；如通过其他方式得到控制信息，多播、广播只能通过源端复制实现。

（3）ForCES[7]

早在2001年，Intel和IBM就在IETF推动下成立了ForCES工作组。ForCES的核心理念与OpenFlow颇有相似之处，如图3所示。整个网络称为网元（network element，NE），由 控 制 元 素 （control element，CE）和 转 发 元 素（forwarding element，FE）组成，一个CE可以控制多个FE，一个FE可以从属于多个CE；CE由CE管理器（CE manager）管理，FE由FE管理器（FE manager）管理；每个组件都是逻辑概念，物理实现上可以有多种形态；各组件之间通过参考点连接，整个NE通过Fi/f接口与其他NE连接。

图3 ForCES架构

图4 NFV架构示意

参考点说明：Fp，CE-FE接口；Fi，FE-FE接口；Fr，CE-CE接口；Fc，CE管理器接口；Ff，FE管理器-FE接口；Fl，CE管理器-FE管理器接口；Fi/f，FE外部接口。ForCES起源很早，此后沉寂多年，并且商业上没有成功案例。随着SDN概念的兴起，该工作组又开始活跃起来。

2.3 运营商主导的NFV[3]

NFV所针对的问题域如下。

NFV的思想是基于海量的、归一化的工业标准服务器、交换机和存储设备，利用标准的IT虚拟化技术，通过软件实现多种多样的网络功能，如虚拟的运营级NAT、虚拟的广域网加速、虚拟的企业接入路由器，以此达到降低成本、加快业务成熟周期、资源弹性伸缩、构建创新生态链的目的。

如图4所示，网络功能以软件形式实现，并运行在符合工业标准的服务器硬件上，可以根据需要被移动到或实例化到网络中不同的位置，免除新设备安装的工作。

NFV的典型用例如下。

·交换元件：BNG，CG-NAT，路由器；

·移 动 网 络 节 点：HLR/HSS，MME，SGSN，GGSN/PDN-GW；

·隧道网管元件：IPSec/SSL VPN网关；

·流量分析：DPI，QoE测量；

·安全功能：防火墙，病毒扫描器，入侵检测系统。

NFV面临以下技术挑战：

对于绝大多数人来说，晚餐并不是可有可无，好好吃饭，身体才能健康。但也有这么三类人是可以不吃晚餐的。对于他们来说，不吃晚餐反而“更健康”。

·提供能够满足服务提供商的性能、可靠性和可用性要求的，基于标准的，高度可扩展的COTS服务器和高可用性的中间件；

·实现NFV与传统网络元素的互操作；

·NFV应用程序的管理和业务流程功能的自动化；

·确保网络的安全性不受NFV技术引入的影响。

3 不同SDN实现的关系及运营商策略

3.1 不同SDN实现的关系

综上所述，SDN技术流派众多，彼此差异巨大。

基于OpenFlow的SDN是对目前TCP/IP网络架构的一个颠覆：它强调网络层面的控制与转发分离，流表每跳下发。在OpenFlow的发展初期，由于其简单、清晰而强烈的需求，加上互联网巨头（如Google等）的成功商用，在业界掀起了一股SDN热潮。可以预见，OpenFlow必将朝大规模复杂应用场景前进。OpenFlow的主导者是学术界、互联网界和IT业者，其出现的行业大背景是传统网络设备产业链的封闭、迟钝已经严重阻碍了互联网发展。由于OpenFlow的未来发展将面临算法、架构、转发芯片等方面的极大挑战，学术界一定会在其中继续发挥重要作用。

NFV的核心是网络设备实现形态的标准化、虚拟化、软件化，并不涉及网络架构和控制。它反映了运营商对网络设备低成本、高适应、快部署的诉求。NFV面临多方面挑战。正如曾经提到的，NFV与SDN的关系是互不依赖、互为补充。SDN更像是人为强加给NFV的“一顶帽子”。

IETF是网络设备厂商的大本营，它的SDN呈现出对传统网络更多的继承性。

I2RS的基本思路是维持现有路由体系，但在单路由设备的控制平面引入一定的开放性，使用户可以做一些设备级的局部控制。这可以视为设备厂商对用户的某种妥协。

VXLAN是基于现有网络架构的叠加方案，和其他VPN、隧道技术没有本质区别，但针对虚拟化、多租户场景等提出了针对性解决方案，其控制信息建立的push和pull方式被厂商宣称为SDN。当然，这与IETF关于SDN的定义是吻合的。

ForCES是IETF中的一个异类，它在理念上与OpenFlow最接近，出现的时间早很多，并且更为理想化——试图改变转发芯片而不仅仅是转发设备。从事后的观点看，ForCES当时面临的需求动力不足非常明显，生态环境（如芯片、软件、最终用户）不完善，技术目标太理想，其主导者——Intel和IBM既非网络大玩家（这也许解释了IETF中为什么会出现ForCES这样的异类），也没有持续投入。即使到了今天，如果ForCES想有进一步发展，也必须做出某些修正。

尽管存在上述巨大差异，从网络总体的角度看，不同技术流派的关系却是有迹可循的：OpenFlow和ForCES强调的是新型网络架构（从而必然对网元产生重大影响）；NFV强调的是新型网元（并且更侧重于业务网元，如防火墙等）；I2RS强调的是现有网元在设备级控制平面的开放性（明显不同于传统网管）；叠加强调的是在现有基础设施灵活的租户网络上构建。它们分别面向网络的不同方面，互不依赖，互有竞争，互相补充。

3.2 运营商策略

运营商在不同SDN间处于相对超然的位置，基本策略应该是乐见其成，借势借力，按需取用。尤其对于大型综合网络运营商，手中掌握骨干网、城域网、接入网、无线网、IDC，不仅提供公众网络服务，也提供企业网络服务，多厂商混合环境始终是技术互操作和工程可实施的难点，基本上每个环节都可以或多或少地发现某种场景可以使用上述某种技术。从中短期的业务部署角度看，运营商应该更加关注Overlay和I2RS；从长期的竞争角度看，运营商应该更加关注OpenFlow和NFV。

OpenFlow中短期内在小规模、特定场景（如流量工程）下的可行性是已经被证明的，尽管它的商品化水平有待提高；在可见的未来，规模应用于数据中心、接入网、无线网也是可以期待的。尤其是数据中心，它已经成为IT界和CT界应用OpenFlow技术的交集场景，运营商可以联合IT共同推动OpenFlow与IP/MPLS骨干在云边缘的互通，提供虚拟私有云服务；在大规模复杂场景的应用还有漫长的路要走，但这不是不可能的。一旦真的实现了大规模网络应用，必将大大降低网络建设和运营门槛，彻底颠覆网络建设和运营模式——如果说互联网对运营商的冲击更多是在业务层面，未来的SDN对运营商的冲击将在基础设施层面。真到了那一天，能够挽救运营商命运的除了牌照，恐怕只能自我革命了。

NFV的适用场景和挑战前文已有涉及，这里不赘述。理想的NFV，结合其他技术，将极大地降低IDC运营商、云服务提供商、网络增值服务提供商的门槛，而这也将对网络运营商的同类业务提出更高要求。

4 结束语

SDN正在成为一个营销词汇，用于包装各种不同技术，如果仅看名字而不了解其内涵，将什么也得不到；SDN的每种实现方式都针对特定的问题域，互不依赖，互有竞争，互相补充，各有其潜在价值；目前几乎所有实现方式都处在发展早期，但它们在中短期内商品化的可能性有很大不同；类OpenFlow的技术可能会对现有网络架构形成颠覆性的影响；众多实现方式的涌现是产业链博弈的反映；运营商总体应对策略应该是超然、开放、为我所用的，但需要未雨绸缪，准备应对网络架构的巨变。以上是本文期望传递给读者的信息。

1 McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow：enabling innovation in campus networks.ACM SIGCOMM Computer Communication Review,2008,38(2)

2 Boucadair M.Draft-sin-sdnrg-sdn-approach-03.Software-Defined Networking:a Service Provider’s Perspective,2013

3 Chiosi M.Network Functions Virtualization—Introductory White Paper,2012

4 ONF白 皮 书.Software-Defined Networking：the New Norm for Networks,2012

5 White R.Draft-white-i2rs-use-case-00.Use Cases for an Interface to the Routing System,2013

6 Kreeger L.Draft-mahalingam-dutt-dcops-vxlan-04.VXLAN：a Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks,2013

7 Yang L.Forwarding and Control Element Separation（ForCES）Framework,RFC 3746.2004