何晓明，冀 晖，毛东峰，唐 宏

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

1 当前电信IP网面临的问题

电信IP网络从最初仅能满足互联网应用的“尽力而为”网络发展到今天能够提供具有服务质量保证的语音、视频、文本等多媒体业务的融合承载网，IP网络的功能和性能发生了巨大的变化。支撑IP网络飞速发展的TCP/IP技术体系也在不断地 “做加法”，变得日趋庞大和复杂，IETF组织正式发布的RFC文档目前已超过7 000个。然而，这种基于分布式路由计算的网络架构并未发生本质的变化。今天的IP网络就像得了肥胖症，并伴生出多种难以治愈的并发症，如网络设备更具多样性和复杂性，由此导致的网络运维将不堪重负；网络不能适应快速变化的业务和应用需求等。下面从这些方面分别进行阐述。

1.1 网络设备的多样性和复杂性

最初的IP组网设备仅有交换机和路由器两种设备形态，设备厂商也较为单一，基本上维持Cisco设备一统天下的局面。随着IP技术发展以及市场竞争的加剧，越来越多的公司加入网络设备研发队列；与此同时，电信运营商也需要更多地考虑建设网络基础设施的经济性和网络运营的安全性，多厂商设备组网已成为各大运营商共识。另一方面，丰富多彩的网络应用也催生出更多的设备形态和种类，像以太网交换机、路由器、网关设备、宽带接入服务器、防火墙、网络地址转换（NAT）设备、负载均衡设备这些标准化程度较高的设备都已广泛部署在各大运营商网络。这些为满足不同功能、运行多种不同协议的设备组成的异构网络需要通过TCP/IP互联起来，共同构筑今天通达全球的信息高速公路。

过去30多年来，IP技术在不断满足人类信息需求的过程中取得了巨大的成功，这种成功建立在对TCP/IP技术体系不断丰富完善的基础之上。层出不穷的网络应用对IP网络的传输容量、可靠性和扩展性、安全性提出了新的要求。每当一个新的功能和性能需求提出时，需要有一种新的网络协议与之相适应。比如说，设备需要支持区分服务（DiffServ）或综合服务（IntServ）协议以支撑网络的差异化的QoS服务；设备需要支持PIM（protocol independent multicast，协议无关多播）协议以提供网络多播服务；设备需要支持标签分发协议（LDP）和多协议边界网关协议（M-iBGP），才能提供二、三层MPLS/VPN服务。每一次设备功能和性能的增强都是以设备复杂度的增加作为代价，网络设备就在人们对网络应用需求永无止境的追求中积累着难以承受的复杂度。这种IP网络和设备的复杂性根源于传统分布式路由计算的网络架构，只要传统IP网络架构不发生革命性的变化，IP网络和设备的复杂性就将会与日俱增。

1.2 网络运维的艰巨性

电信IP网络的多厂商、多设备形态、多版本的设备组网特点带给网络运维的复杂性不言而喻。不同设备形态、不同厂商、不同软硬件版本的设备存在功能和性能差异，配置命令也互不相同，网络运维人员需要耗费大量时间和精力熟悉多种设备的技术特点和配置命令。在实际网络运维中，运维部门通常按照设备厂商、设备形态或版本型号配置相应的技术人员，通过对管理界面适度分工的方式来缓解运维压力。这种分工协作的运维管理模式也滋生出一种副作用，那就是负责不同厂商设备的专业技术人员难以就设备互联互通问题进行有效的沟通，导致业务开通及网络排障的时效性差，饱受用户和客户诟病。

与此同时，IP技术发展日新月异，设备需要同时运行多种信令协议来支持不同的网络应用，网络技术人员需要不断熟悉和掌握IP新技术，这也对网络运维人员的专业技能提出了更高要求。今天网络的配置工作正变得日益繁重，通常需要在大型运营商网络设备上手工完成上千行配置命令，这对技术人员来说，是一件望而生畏的工作。随着移动互联网、云计算的广泛应用，网络更趋向于动态化，相比于过去的静态网络，今天网络中的参数和配置命令更需要进行动态配置和修改，比如说，网络中增加、删除或移动某台设备时，运维人员需要使用设备级的管理工具调整相关联设备如交换机、路由器、防火墙、AAA认证系统的网络参数，更新相关设备的访问控制列表（ACL）、VLAN、QoS等配置命令。服务器虚拟化极大地增加了网络互联的主机数目，虚拟机（VM）迁移对传统网络的诸多方面提出了挑战，从寻址方案、命名空间到网络分段和路由设计等，都对网络的动态配置提出了很高的要求。由于应用需求的动态变化、主机位置的移动、设备的添加和删除随时都可能发生，网络配置也需要适应这种动态变化的环境。传统网络基于设备级的手工配置方法不能适应当前动态变化的网络环境，网络配置的自动化更能适应快速变化的业务和应用需求，并能从根本上把网络技术人员从繁重的运维工作中解脱出来。

1.3 网络不能适应快速变化的业务和应用需求

移动设备、存储和服务器虚拟化的爆发以及云服务的兴起迫使网络工业重新审视传统IP网络架构。传统静态的IP网络架构能较好地适应以客户机/服务器模式为主的网络应用，然而，这种静态架构不能很好地适配今天云数据中心对动态计算和存储的需要。下面几个关键因素正驱动着传统网络架构的变革。

（1）流量模型的变化

今天的云数据中心，其流量模型正在发生重大变化。对比过去占统治地位的客户机/服务器应用，数据中心流量流向主要以南北向为主。在云计算环境下，用户对前端服务器访问请求，会引起大量后端服务器的分布式计算，这种后端服务器群组的协同计算产生巨大突发的东西向流量。同时，以社交网络和即时通信为代表的移动互联网应用的爆发正在改变着互联网的流量模型，永远在线的移动终端无时无刻不在制造并向网络注入海量内容，改变了过去互联网上下行流量严重不对称现象。再者，许多企业数据中心的管理者正在考虑把传统的企业数据中心转变成私有云、公有云或混合云，这将产生更多的跨越广域网的流量。

（2）云服务的兴起

企业开始关注并对公有云和私有云服务产生兴趣，导致云服务的迅速增长。企业希望以更加灵活的方式按需获取互联网应用、基础设施和IT资源。这对网络的安全隔离性、策略一致性、审计等方面提出了更高要求。网络在为计算、存储和网络资源提供更多弹性和可扩展性的同时，还需部署自服务平台，方便用户随时获取所需资源。

（3）大数据对网络带宽的弹性要求

大数据正成为互联网企业追逐的下一座金矿。大数据处理需要成百上千台相互连接的服务器并行计算，如百度和Google搜索引擎就是一种典型的大数据应用。根据权威机构预测，随着大数据应用范围的扩展，计算节点之间交换的数据流量将达到PB量级。大数据时代要求网络带宽具有极大弹性和伸缩性，能够动态提供从数十吉比特每秒到太比特每秒级的网络带宽，以满足成千上万台服务器之间的高容量、低时延的网络连接。

（4）网络虚拟化要求

当前电信运营商网络部署了大量种类各异的专用硬件设备，这些专用硬件设施是在不同时期为满足特定业务而购置的。这些设备生命周期短，运营维护成本高，为特定业务专门定制和独享，利用效率低。随着新业务层出不穷的涌现，需要部署更多新的专用硬件，不仅开发周期长，影响业务的快速部署，不利于网络和应用创新，而且大大增加了电信运营商的资本支出。电信运营商迫切需要寻求一种通用的网络基础实施，支撑未来不断变化的业务和应用需求。计算和存储的虚拟化技术的大量商用部署为网络功能虚拟化打开了一扇门。网络虚拟化的目标是通过借助IT虚拟化技术把网络基础设施转变成工业标准的大容量服务器、存储设备和交换机，而使业务的部署不再受具体物理设备及位置的限制。

2 SDN对传统网络的变革

传统网络架构不能很好地适应今天的企业、电信运营商及用户的需求。由开放网络基金组织（ONF）发起的软件定义网络（SDN）正在变革传统网络架构。根据ONF对SDN的定义，在SDN架构中，控制平面和数据平面解耦，网络智能和状态逻辑集中，底层网络基础设施抽象于应用。企业和电信运营商能够实现对网络的自动化、编程和控制，网络变得更加具有扩展性、灵活性，更能适应不断变化的业务和应用的需求。

ONF提出的SDN架构如图1所示。SDN架构分为3层，最上层为应用层，包括了各种不同的业务和网络应用。应用层根据网络不同的应用需求，调用与控制层相接的应用编程接口（API），实现不同功能的应用程序。利用API，业务应用可以充分利用网络的服务和能力，并在一个抽象的网络上进行操作，实现通常的网络服务，包括路由、多播、安全、访问控制、带宽管理、流量工程、服务质量、计算和存储优化、能源管理、各种形式的策略管理以及客户定制化服务等。

SDN的控制层由控制软件实现，主要负责集中收集和维护网络拓扑及网络状态信息，实现不同业务特性的适配。利用控制/数据平面接口，控制层获取底层网络设备互联及状态信息，生成全局的网络拓扑视图，对底层网络设备的资源进行抽象，并通过API提供给上层应用。因此，对于上层应用程序来说，网络呈现为一个单一的逻辑开关。通过这种软件模式，网络管理人员可以灵活配置、管理和优化网络资源，实现了网络的可编程及灵活控制。

SDN基础设施层由网络的底层转发设备构成，通过对底层设备及网络资源进行抽象，并通过开放标准的接口为控制层提供服务。底层设备只需关注数据的转发性能，无需运行网络相关及应用相关的各种复杂信令协议，通过接受控制器的指令，实现数据分组的转发、丢弃或修改等操作。SDN极大简化了网络设备复杂性。

从SDN架构可以总结出SDN应具有的四大基本特征。

·控制平面与数据平面完全分离。打破了传统网络设备垂直一体化设计架构，大大简化了底层转发设备复杂度。

·集中控制。由集中控制器实现全网拓扑的自动发现和路由计算，优化网络资源利用，实现全网流量工程。

·开放接口。通过开放南、北向接口，实现应用和网络的无缝集成，加快业务部署周期，提升用户体验。

·网络可编程。通过开放API，上层应用与底层网络良性互动，实现网络服务的可定制化和可编程能力。

在SDN架构下，通过集中式的网络配置和管理，大大简化了传统网络设备配置的工作量。由于底层硬件采用工业标准化的通用转发设备，有利于实现网络功能虚拟化；新业务部署减少了对不同厂商设备的依赖程度，加速了网络和应用创新。同时，SDN实现了网络智能和状态逻辑集中，网络管理人员可以通过一套动态、自动化的应用程序实现对网络的灵活配置、管理、安全加固、资源优化等。

3 电信IP网向SDN的演进

SDN改变了传统网络架构，也改变了传统网络的运维管理模式和业务部署方式，为企业和用户提供更好业务体验的同时，期望能减少电信运营商的资本支出和运营支出。然而，SDN当前仍面临许多挑战。本文对SDN满足电信级要求的网络性能、网络扩展性、网络生存性3个方面进行了探讨和分析，并结合电信运营商网络现实需求，探索SDN在电信网的应用与实践。

3.1 SDN网络性能

在移动互联、云计算、大数据爆发的今天，网络流量呈爆炸式增长。全球电信运营商都倍感网络扩容压力，目前中国电信集团ChinaNet骨干网流量已超过40 Tbit/s，若流量按照40%的年增长速度计算，网络容量每隔两年增长一倍。单槽位100 Gbit/s平台路由器刚进入大规模商用期，许多大电信运营商已开始考虑在骨干网部署400 Gbit/s平台的核心路由器。SDN的底层数据转发平面可能使用完全不同于传统网络设备的硬件架构，因此，SDN首先面临的一个基本挑战是怎样应对汹涌而来的数字洪流。这里有两个方面的因素需要考虑：网络性能与可编程/灵活性。

本文中SDN网络性能主要考察网络设备的吞吐量和时延两个指标。网络的可编程意味着网络设备接受控制器下发的一系列指令，进而改变数据流的转发行为。灵活性是指网络对新业务和应用的适应能力。通常来讲，网络性能与可编程/灵活性是一对矛盾，网络的高性能需要牺牲网络的灵活性作为代价。怎样在网络性能与可编程/灵活性之间取得平衡是SDN需要解决的问题。

图2给出了网络处理的主要技术中性能与可编程性之间的关系。通用处理器（CPU/GPU）能够提供极高的灵活性，高级编程语言和设计工具可对底层硬件进行高度抽象，快速开发复杂的数据分组处理功能。受通用架构约束，CPU的处理性能低，电能消耗大。类似Intel的Xeon系列多核处理器能够达到几十吉比特每秒的报文处理吞吐量。网络处理器（NPU/NFP）的架构专为处理数据流而优化，专用硬件加速器及各种接口技术的使用可减少处理器能耗。由于需要定义数据分组/流的处理功能，其灵活性不如通用处理器。网络处理器可达到100 Gbit/s的线速处理能力。可编程逻辑设备（PLD）或现场可编程门阵列（FPGA）专为特定的网络功能而设计，具有高度并行处理数据分组/流的能力，当前的PLD技术可以达到200 Gbit/s的线速处理能力。专用标准产品（ASSP）是高性能网络的里程碑，缺点是其灵活性不够。ASSP主要应用于物理层和链路层设备、交换机及无线产品。最近，Intel、Broadcom以及Marvell公司开始使用基于SDN的ASSP来设计高性能以太网交换机，它们设计的OpenFlow交换机声称可支持500 Gbit/s的交换能力。专用集成电路（ASIC）专为厂商定制生产，作为一种专有的解决方案，ASIC具有极高的性能、成本及能耗优势，但其灵活性也极为有限。

SDN需要同时兼顾网络性能和可编程/灵活性，容易想到一种软件和硬件相结合的混合架构更能适合SDN基础设施层。例如，基于PLD/ASSP与NPU/NFP和CPU/GPU相结合的混合架构构建的底层转发平面既能提供网络可编程的灵活性，又能支持数据流的高性能转发。这种软、硬件一体化的混合架构有助于实现网络虚拟化目标——开发出工业标准化的通用转发设备。

3.2 SDN的网络扩展性

如果SDN数据转发平面的性能问题可以通过混合式可编程架构得到解决，另一个引起广泛关注的问题是SDN的扩展性。目前，对SDN的扩展性研究主要集中在SDN控制平面可扩展性。

制约SDN控制平面可扩展性的主要原因有以下几点。

·流的细粒度处理需求使得控制器需要响应更多的流请求事件。虽然控制器可以通过主动决策机制提前将控制逻辑下发到数据转发单元，减少数据平面和控制器之间的处理开销，但控制逻辑的变化通常是动态的，尤其是当网络拓扑改变或者存在移动节点时。在基于OpenFlow的SDN中，提前安装流表项也将使大量流表空间无法释放，浪费缓存资源，而实际上大部分流的持续时间是很短的。

·接入控制、负载均衡、资源迁移等新型应用需求逐渐增加到控制平面中，控制器需要对日趋复杂的管控功能进行有效整合，这进一步增加了控制平面的处理开销。

·传统分布式网络中每台设备都是独立自治的，每台设备通过运行路由协议获取全局的网络状态信息并计算路由。而SDN控制平面需要维护全局的网络状态信息，为全网中的所有网络设备计算数据转发路径，这使得控制平面的可扩展性不仅需要考虑处理性能的需求，而且要考虑网络状态的一致性。

·在网络规模增大、数据平面转发设备数量增多的环境下，单控制器设备可能难以满足性能需求。

在基于OpenFlow的SDN中，每当交换机收到一个新的数据流时，由于交换机还未安装流表项，首个分组需要上送控制器。在电信运营商的大规模网络中，会导致数据面和控制面之间的控制通道带宽需求大、依赖首个分组反应式的流表项建立时延大以及控制器需要频繁响应交换机请求等扩展性问题。DIFANE方案结合了主动和被动两种安装流表的方式将数据流量保持在数据平面，从而减小控制器负载。通过在OpenFlow交换机中选出权威交换机，由每个权威交换机管理一定区域内的OpenFlow交换机。当普通交换机产生新的数据流时，它根据自身的分区规则直接和自己分区内的权威交换机进行通信，由于权威交换机已提前部署了权威规则，因而可以向普通交换机安装缓存规则，同时，直接将请求数据转发给目的地而无须再返回给源交换机，从而省去了流请求建立过程中首个分组经过控制器的往返时延，也减少了控制器需要实时处理的控制流。DevoFlow方案借助于ASIC的支持，在OpenFlow交换机上提前安装带有通配符的流表项，对于需要特殊处理的细粒度流才转发到控制器，这样能有效减少控制器的负载。针对单控制器无法从根本上解决处理性能瓶颈问题，Onix提出了一整套面向大规模网络的分布式SDN部署方案，即通过多控制器对OpenFlow交换机进行分域管理，这应该是未来SDN面向大规模网络部署可扩展性研究的主要发展方向。

3.3 SDN的网络生存性

电信运营商网络由于承载着大量实时交互性业务，对网络的生存性提出了很高的要求，如5个9的网络可用性、多种方式的业务保护及网络快速自愈能力。为了满足电信级IP网络的要求，IP网络已形成一整套成熟完善的高可靠性和高可用性技术，包括路由快速收敛技术、MPLS TE/LSP FRR业务保护技术、MPLS OAM/Ethernet OAM/PWE3 OAM故障快速检测技术，不间断转发（NSF）、不间断路由（NSR）及平稳重启（GR）等技术在设备控制引擎失效时仍能保持业务的连续性。

SDN对网络的生存性要求也不能低于传统的IP网络。为了应对控制器的单点失效，OpenFlow2.0增加了多角色控制器功能，主控制器与多个从控制器保持状态信息的同步，当主控制器失效时，从控制器能平滑接管主控制器的工作，不至于引起业务中断。当存在多条等价或非等价路径时，转发设备的流表项也应提供多个输出端口，并根据负载均衡算法把数据流转发到不同的路径上。SDN同样需要支持IP网络中类似于MPLS TE/LSP FRR的业务保护机制，为需要业务保护的数据流提供1条到多条备用路径，从而在链路失效时立即转用备用路径，而不是把数据转发给控制器。

下面分析SDN的故障恢复能力。如图3所示，正常情况下，由于R1与R3之间的链路代价小于R1与R4之间的链路代价，数据转发设备R1的数据流都会转发到R3。当R1快速检测到R1与R3之间的链路故障时（如通过BFD或以太网OAM），R1应立即上报控制器，控制器收到故障通告后，根据更新的全局网络拓扑重新计算路由，并向受影响的数据转发设备更新流转发表。等到最新的流转发表都安装好后，来自R1的数据流才切换到R4。再看看IP网络是怎样实现路由收敛的。在传统IP网络中，链路故障通知最先向它的邻居宣告，邻居再向邻居的邻居宣告，网络规模越大，最后一跳获知链路故障的路由器所需时间越长，当全网所有路由器都获知这一链路故障事件时，才会重新形成一致的网络拓扑，然后每台路由器各自独立计算路由，向转发平面下发FIB。显然，SDN的故障信息传播时延要小于传统IP网络，SDN的网络收敛性能基本不受网络规模的影响，而传统网络的收敛时间随着网络规模的增大而增大，这就是传统基于分布式路由计算的IP网络收敛时间难以实现传输网所要求的50 ms保护倒换的原因。而且，基于云计算架构的控制器计算能力理论上可以无限扩展，而传统路由器的CPU计算能力是有限的。

SDN优良的网络自愈能力还取决于连接控制平面和数据平面的控制信道的高可靠性。如果控制信道与数据平面共享网络带宽（带内控制信道），由于数据平面不再运行路由协议，难以保证控制平面和数据平面的连通性，数据平面的故障可能无法上报到控制器，导致网络无法自愈，业务中断。因此，控制信道的高可靠性需要独立的控制网络来保证，这个带外控制网络本身应该具有快速自愈能力。

3.4 SDN应用与实践

SDN目前主要应用于校园网和企业数据中心。在校园网中部署OpenFlow网络，是OpenFlow设计之初应用较多的场所，它为学校的科研人员构建了一个可以部署网络新协议和新算法的创新平台，并实现了基本的网络管理和安全控制功能。目前，已经有包括斯坦福大学在内的多所高校部署了OpenFlow网络，并搭建了应用环境。随着云计算在数据中心的广泛应用，将SDN应用于数据中心网络已经成为研究热点。Google在其数据中心全面采用基于OpenFlow的SDN技术，大幅度地提高其数据中心之间的链路利用率，起到了很好的示范作用。由于电信运营商网络是一个多业务融合承载网，真实网络面临的异构组网、跨域互联、超大容量、高可靠性和高可用性等都可能成为制约SDN应用的因素。SDN在校园网和企业数据中心取得的研究成果和应用经验不能一成不变地移植到电信网，需要进一步在电信网加以实践和验证。为加速SDN在电信网的全面部署，还需要充分考虑电信网的特殊需求，进一步研究SDN满足电信网所应具备的功能和性能要求。下面从电信运营商的数据中心、IP RAN、IP骨干网需求3个方面探索SDN应用和部署。

（1）SDN在数据中心的应用

随着数据中心服务器和存储虚拟化技术的广泛应用，传统数据中心网络必须实现网络虚拟化的改造，以满足虚拟机频繁迁移对网络大量动态配置的需要。在服务器上实现虚拟网卡和虚拟交换机已成为VMware、Xen、Oracle等主流服务器供应商的标准配置。为适应网络虚拟化要求，提出了相关标准和草案如虚拟以太网桥（VEB）、虚拟以太网端口聚集器（VEPA）、虚拟扩展局域网（VXLAN）、通用路由封装实现网络虚拟化（NVGRE）等，并在部分厂商设备上得到相应支持。同时，虚拟化网络环境下的动态路由、负载均衡和能量管理等方面也对数据中心网络提出了新的要求。SDN基于软件控制的可编程特点可以简化网络配置和管理的复杂性，是实现数据中心网络虚拟化最适合的基础平台。

（2）SDN在IP RAN的应用

IP RAN广泛应用于移动回传网，用于承载2G/3G/LTE等移动业务，是一种新型传输网络。IP RAN分为接入层、汇聚层和核心层。IP RAN全网采用IP/MPLS解决方案，接入 层涉及IGP、BGP、LDP、RSVP-TE、PW、L2/L3VPN、QoS等配置。一个IP RAN本地网的接入层往往有数千台接入设备，网络配置复杂、业务开通周期长。随着网络规模的扩大，现有IP RAN在网络高可用性、网络运维等方面面临困境。随着技术的发展，新的增值业务和应用不断推出，IP RAN如何更好地适应业务网络的发展和要求，快速响应业务的部署及对业务进行动态维护也是需要考虑的问题。通过把SDN技术应用于IP RAN，可探索和研究SDN快速响应业务和网络运维这两方面的能力需求。

（3）SDN在IP骨干网的应用

随着互联网流量的爆炸式增长，电信运营商IP骨干网面临持续扩容的压力。另一方面，IGP选路的唯一性原则导致网络流量分布极度不均衡，一部分链路严重拥塞，而另一部分链路长期处于轻载状态。无法通过IGP metric（度量）调整来达到全网负载均衡的目的。在存在路由反射器（RR）的环境下，RR遵循标准BGP选路原则，无法实现跨域多归属网络的负载均衡。BGP虚拟下一跳技术虽然能够弥补RR选路的不足，但是却增加了网络配置和运维的复杂度。SDN可基于全局流量观，根据自定义策略（如最短路径、链路负载、指定经由节点等）进行路径选择，实现全网流量工程。同时，城域网、数据中心、不同电信运营商网络同骨干网跨域互联对SDN的可扩展性提出了挑战，多控制器方案在骨干网的应用和实践能够验证SDN分布式部署方案的可行性，为进一步完善SDN架构、功能、相关接口和规范提供研究基础。

4 结束语

移动互联、存储和服务器虚拟化的爆发以及大数据和云服务的兴起对传统IP网络架构提出了新的要求，并加速了传统网络的变革。SDN提供了一种新的、动态的、业务驱动的网络架构，适应不断变化的业务和应用需求，契合当今时代创新求变的主旋律。SDN倡导的“集中控制、网络可编程、开放接口”等理念引起了产、学、研各界的广泛关注。目前，OpenFlow是实现SDN的主要技术和标准，其相关规范已经得到普遍承认。基于OpenFlow的SDN技术在解决当前存在的实际问题和开拓网络新应用等方面取得了不少成果，在校园网、企业网及数据中心都有相应部署，部分主流厂商的设备也逐渐支持OpenFlow接口规范，但目前在电信运营商大规模网络仍缺少商用案例。总之，SDN在控制软件架构、接口标准、数据转发性能、网络扩展性和顽健性、网络安全性、与传统网络设备的互操作性等诸多方面仍面临巨大挑战。尽管如此，SDN已为传统网络演进和变革指明了方向，相信在众多设备厂商、标准化组织、研究机构的共同努力下，SDN将发展成为面向下一代IP网络的标准架构。

1 ONF White Paper.Software-Defined Networking:the New Norm for Networks,April 13,2102

2 Raj Jain,Subharthi P.Network virtualization and software defined networking for cloud computing:a survey.IEEE Communications Magazine,2013,51(11)

3 Sezer S,Hayward S S,Chouhan P K,et al.Are we ready for SDN?Implementation challenges for software-defined networks.IEEE Communications Magazine,2013,51(7)

4 Yeganeh S H,Tootoonchian A,Ganjali Y,et al.On scalability of software-defined networking.IEEE Communications Magazine,2013,51(2)

5 Boucadair M,Jacquenet C.Software-Defined Networking:A Perspective from within a Service Provider.RFC 7149,March 2014

6 Haleplidis E,Denazis S,Salim J H,et al.SDN Layers and Architecture Terminology.IETF Draft(Work in Progress)

7 ONF.OpenFlow Switch Specification Version 1.3.4,March 27,2004

8 Yu M,Rexford J,Freedman M J,et al.Scalable flow-based networking with DIFANE.Proceedings of the ACM SIGCOMM 2010 Conference on Applications,Technologies,Architectures,and Protocols for Computer Communications,New Delhi,India,2010

9 Curtis A R,Mogul J C,Tourrilhes J,et al.DevoFlow:scaling flow management for high-performance networks.Proceedings of the ACM SIGCOMM 2011 Conference on Applications,Technologies,Architectures,and Protocols for Computer Communications,Toronto,ON,Canada,2011

10 Koponen T,Casado M,Gude N,et al.Onix:a distributed control platform for large-scale production networks.Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation,San Jose,CA,USA,2010