1. 引言
据中国互联网络信息中心(CNNIC)发布的第36次全国互联网发展统计报告，截至2015年6月，我国网民总数已达6.68亿人，互联网普及率为48.8% [1] ，说明以互联网为代表的网络技术已经成为人们日常生活中不可却缺少的一部分。互联网技术在短短二十年的商业化浪潮中，以前所未有的速度在全球范围掀起一场影响人类所有层面的深刻变革，引发各产业生产方式、生产关系、生产要素的重新组合、建构，在很多方面影响和改变了人们的生活方式。但随着网络技术的发展，越来越多的分布式应用和不同类型的网络技术被部署到网络上，基于传统IP的网络体系结构正面临越来越多的问题，传统的优势正逐渐成为制约网络技术发展的瓶颈。由于互联网的多提供商特性(即Internet的骨干网结构是由多个ISP互连组成)，部署一种新的体系结构或者对现有的体系结构进行修改都需要得到所有ISP的同意。因此，对Internet体系结构的更新和部署一些新的网络技术正变得越来越艰难。同时，随着网络技术的发展，网络应用范围的进一步扩大，网络已经由单一的数据传输网络发展为需要支持数据、视频、语音以及实时多媒体的多样化网络，使得当前单一的网络基础设施很难同时满足上述多样化的网络应用需求。同时，电信、广播、电视运营商开始考虑将互联网作为其业务的主要承载平台，三网融合的趋势已经越来越明显，以秒拍、IPTV、在线视频播放、网盘及网络直播等为代表的新型流媒体应用不断涌现，这将会进一步加剧网络应用需求的多样化和复杂性 [2] 。由于话音、电视和数据三大类的业务对服务质量的需求差别很大，需要设计一种有效的网络架构和管控方式，保证其不同业务类型的服务质量，并从更小的粒度保证每种大业务类别中不同子类的服务质量。研究表明，很难设计出一套可以满足上述所有需求的网络体系结构。
2. QoS技术
在现有的互联网体系架构中，尽管在报文头部中包含了服务类型(Type of Service)字段，但在路由器处理中通常被忽略，网络不提供相应的服务，而采取尽力而为(Best Effort)的传输转发方式，只要把报文转发至目的节点即可，提供端到端的通信，几乎不提供服务质量，其端到端的可靠性传输通过端到端的TCP协议中出错重传机制来保证。
没有QoS的网络被称为尽力服务网络。在尽力服务网络设计中，所有的分组都被看成是同等重要。但通常网络中存在着对网络资源的大量竞争，以及网络需要提供给不同用户不同等级的服务。要从常常有争夺发生的稀缺资源的网络中获得适当服务级别，必须应用QoS的基本概念，即全部的报文将不平等。为了解决竞争，必须有可管理的不平等来对待报文转发，在网络的基础设施中定义和部署管理策略，以确保每个节点对单个分组(或者流)的相对重要性做出一致的判断。
QoS (Quality of Service，服务品质保证)是指一个网络能够利用各种技术解决网络延迟和阻塞等问题，向选定的网络通信提供更好服务的一种安全机制。有关于如何发展互联网，以便为多媒体业务提供QoS是一个持续不断的争论。目前，全球范围内没有任何的QoS体系结构是得到广泛应用的。一些研究人员认为，根本性的变革应该是怎样做才能充分保证QoS，而另一些人认为只要轻微的变化，就会有足够的保证，在很大程度上提供所请求的QoS。
目前，互联网工程任务组(IETF)已经探索了一些服务质量(Quality of Service, QoS)的体系结构 [3] ，包括以下几种：综合/集成服务模型(IntServ) [4] 、区分服务模型(DiffServ) [5] 、MPLS (Multiple Protocol Label Switching) [6] 、流量工程模型(Traffic Engineering, TE)等。其中IntServ、DiifServ、MPLS是目前主流的QoS模型。
IntServ的主要框架是在传送数据之前，为IP保留了端到端的QoS语义。关键端点是指这些发送和接收应用，他们强烈需求网络服务提供一组流，其中流由源地址、目标地址、传输协议、源端口以及目的地端口等定义。其协议为RSVP (Resource Reservation Protocol，资源预约协议) [7] ，RSVP面向流在传输路径上为流预留并维护相应的资源，主机利用RSVP向网络为应用提出的QoS请求，网络设备(如路由器)建立和维持本地资源预留，并利用RSVP将QoS请求信息往目的路径的设备传送，从而形成整个流路径的资源预留。
DiffServ的主要框架采用层次化结构，简化DS域内部路由器的功能，将复杂的QoS服务功能放在边界路由器上，在网络入口或在网络边界上，在IP头中设置一个字段(IPP或DSCP)，使用这个字段来决定网络内转发分组的节点，根据每个“类别”或服务的要求在网络边界上对被标记的分组进行调解，在网络核心只保留简单的DSCP与每跳行为(PHB)的对应机制，根据DSCP值对数据包进行相应优先级转发控制 [8] 。目前标示报文优先级的方法有三种：IEEE802.1p使用的二层报文的CoS字段、IP报文的ToS字段和基于IP层的DSCP字段。
基于MPLS的QoS映射模型的基本内涵是在MPLS增加的2.5层头部内部，将流标记域与MPLS的标签中的EXP域进行映射，并且利用MPLS提供的标记交换技术来实现报文的高速转发。基于MPLS的QoS映射模型主要优点描述如下：利用MPLS实现流量工程的特性，可充分利用全网的拓扑资源，从而实现全网流量的负载均衡，也就能更好地为每条流提供QoS服务。其缺点描述如下：尽管MPLS提出了通过其高速交换能力的部分解决方案，但属于静态性的、预先分配性的实现，缺少实时地配置QoS的能力和动态的适应能力。
以上这三种架构都没有得到真正的成功和在全球范围内广泛部署。这主要是因为这些QoS体系结构，如IntServ和Diffserv是建立在目前互联网完全分布式的、逐跳路由式的体系结构之上，缺乏整体网络资源分布这种统一的全局视图。
为了解决上述问题，并且还要为了满足网络应用的多样化QoS的需求，迫切需要从网络控制架构的本身改变来解决从全局角度，统一解决当前网络部署QoS服务存在的各种问题。
3. 软件定义网络
软件定义网络(Software Defined Networking)最初是由斯坦福大学Nick McKeown教授等人在2009年左右提出的新型网络架构理念。通过实现网络设备中控制与转发的功能分离，将控制逻辑集中到一个统一的智能计算设备上，并实现控制逻辑的可编程。这种控制的迁移提供底层网络驻留在上层的应用程序的抽象，使他们能够把网络作为一个逻辑或虚拟实体，网络管理应用与网络服务从基础设施中抽象出来，将原来封闭的网络设备“黑盒子”系统转变为灵活开放的网络架构，由原来针对不同的、独立的、运行各种分布式协议的网络设备的控制变为更加简单的工作过程，即快速简单的转发硬件和智能的控制器决策。这种将控制逻辑从转发硬件分离的分层架构使得网络使用者能够快速地部署网络新协议和网络应用，将所有的网络资源描绘成统一的资源池，为不同的网络管理应用提供全局视图，以更好地实现网络管理和服务。
图1描述了SDN体系结构的逻辑架构图，底层的网络基础设施由SDN交换机等网络设备组成，这些网络设备只需要接收执行上层控制器发来的指令，而不再需要理解和处理成千上万的协议标准。这些指令封装在所谓的南向接口中(如OpenFlow、NETCONF、BGP等)，实现了上层控制器与底层网络基础设施层之间的信息交互。根据不同的硬件形态和性能需求，基础设施层可由多种网络设备组成，采用不同的硬件。例如图1中所示的网络处理器(Network Processor, NP)、硬件可编程FPGA (Field Programmable Gate Array)、通用处理器(CPU)、网络处理芯片ASIC (Application Specific Integrated Circuits)等。网络的智能行为由基于软件的控制层负责，控制层通过标准的南向接口与底层的网络设备交互，并维护了一个网络的全局视图。这个控制层也通常被称为网络操作系统。目前研究比较火热、研究人员开发使用比较多的是Trema、Floodlight、OpenDayLight、ONOS等网络操作系统。在全局网络视图的基础上，控制层为上层应用提供了充分的编程接口。这些应用包括负载均衡、防火墙、移动终端管理、传统的L2/L3转发、代理等各种应用，它们实现了相应的网络管理操作和服务。
SDN最本质的特点就是网络控制与转发相分离，并为网络管理人员提供了充分的可编程管理接口。这种控制与转发分离的一个重要功能在于，它使得网络控制逻辑能够以一个全局网络的视野去设计、理解和管理网络，降低了网络系统的复杂度，提升了网络管理应用的控制能力；另一方面，控制转发的分离使得统一各式各样的网络设备成为可能，打破了网络设备的封闭性，改善了网络产业的生态链。而可编程的控制平面则能够让网络管理人员灵活地配置网络功能，并实时地改变网络行为，在增加网络灵活性的同时，降低了网络技术革新的难度。
OpenFlow是SDN中第一个也是目前唯一一个定义在控制层和基础设施层之间的标准通信接口，主要由开放网络基金会ONF (Open Network Foundation)组织负责维护 [9] 。上文提到的其他南向接口均为各个厂商私有的接口，并未被标准化和受到所有厂家的认可。通过SDN控制器在数据平台面中配置的规则，OpenFlow使用流(Flow)的概念对网络进行识别，这些规则被称为流表(Flow Table)。除了匹配规则，OpenFlow还规定了流表中的动作，包括转发报文和修改报文头内容等。通过流表，OpenFlow可以在每个流的基础上对网络进行编程，在实现对报文流精细控制的同时简化了报文处理复杂度。OpenFlow协议发展过程如图2所示。
ONF于2009年12月发布第一个版本OpenFlow协议的规范，即OpenFlow v1.0。其流表由匹配域、计数器、动作域三部分组成。匹配域中包含了报文头中L2-L4内12个字段的信息。随后，ONF根据网络处理的需求，引入了IPv6、多级流表、组表、多控制器等概念，不断地对协议本身进行修订。目前版本已更新到OpenFlow v1.5，流表包含匹配域、优先级、计数器、指令集、生存时间和cookie六部分，匹配域采用更加灵活的基于TLV (Type Length Value)的方式。其中匹配域包含了40多个不同协议类型的报文头域，指令集中包含了10多个特定的协议相关报文处理动作。OpenFlow协议规范从最初对单流表以及基本的二层、三层协议匹配域的支持，演进到对多级流表架构和多协议匹配域及操作的支持，已适用于大部分的网络应用场景。但随着网络设备的进一步开放，新型网络协议的不断引入，网络管理用户对设备可编程性要求不断增加，OpenFlow协议规范仍将持续发展和演进更新，如有研究人员提出支持协议无感知转发的高级编程语言P4等。
SDN的设计者认为SDN简化了网络架构，因而减少操作和控制的开销。所以其具有以下几个方面的优势：
1) 底层设备标准化。OpenFlow逐渐成为控制器与网络设备之间通信接口的标准，底层转发设备只
Figure 2. OpenFlow protocol development flow chart
图2. OpenFlow协议发展流程图
需要通过OpenFlow一致性测试，即可进行部署。网络管理员不需要考虑底层转发设备造成的内部实现差异。
2) 灵活的QoS服务策略选择。在SDN的工作模式下，由于采用全局的带宽分配方式，两种服务均可得到保障。网络管理员根据用户对传输流的需求，灵活地选择相应的QoS策略。策略可以是类似于区分服务这种在局部区域按照权重竞争带宽资源，可以是类似于集成服务这种保证某条流的绝对带宽。SVQoS下灵活的QoS服务策略可以更高效地实现带宽分配，充分利用全网的带宽资源。
3) 自动化的流量带宽配置。基于OpenFlow的SDN本身具有自动化网络配置的特性，因此对于QoS来说，可利用控制器中的接口，实现自动化的流量带宽配置，仅仅需要改变对集中控制中QoS参数输入的设置，即可改变全局的QoS策略，这将大大简化网络QoS管理过程中的操作复杂度，复杂度从O(n)降为O(1)。
4) QoS策略的一致性。无论是集成服务还是区分服务模型，网络管理员的QoS策略都是基于分布式的协议实现，配置过程采用逐跳配置的形式，这就必然导致策略更改带来的不一致情况。QoS策略不一致的另一种情况是，用户定义QoS策略带来的策略冲突以及可能的错误的资源分配。而本文提出的利用SDN集中控制的特性，所有的QoS策略(无论是用户还是网络管理员)都通过集中控制器下发，实现对所有网络设备以及全网流量的集中管控，消除了以上两种情况下策略不一致带来的问题。
4. OpenFlow对QoS的支持
OpenFlow [10] 是SDN中第一个也是目前唯一一个定义在控制层和基础设施层之间的标准通信接口，主要由开放网络基金会组织负责维护，目前已更新到版本1.5.1，而且有向OpenFlow2.0演进发展的趋势。一个OpenFlow交换机有以下几部分组成：流表和OpenFlow通道。OpenFlow通道用于交换机与控制器之间交互控制信息，例如下发流表规则等等。流表是流规则的集合，每条规则包含以下几个域：匹配域，以多级流表的形式实现，每个匹配域定义了一种处理报文流的行为，目前已包括达到41种报文头部；动作执行的集合，包括丢弃、转发、修改报文头域、转发至控制器等等；计数器的集合，记录了报文匹配的数目和字节数等等；优先级，用于确定规则在冲突情况下的执行顺序。基于OpenFlow的报文处理过程描述如下。交换机收到报文后，通过查询流表得到最高优先级的匹配规则，执行规则中相应的操作，并且增加相关的计数器。通常来说，如果是转发操作就转发至对应的端口。如果未命中，则通过OpenFlow通道发送至控制器。
在OpenFlow的规范中，主要定义了两种机制共同实现QoS流量调度：计量表(meter)和队列设置操作(set queue) [11] 。
计量表包含了计量表项，定义了每条流的计量参数。每条流的计量使得OpenFlow实现了限速功能，即将一条流的速率限定在一个固定大小的带宽内。每条流的计量也可以实现更复杂的QoS功能，例如基于DSCP的计量可以把报文集合进行分类，并且映射到不同的计量表上，实现速率限制。计量表操作与队列设置相互独立，互不干扰，两者可以相互配合共同协作，完成QoS的功能。本文为简化OpenFlow流表的规则的配置复杂性，仅采用下面论述的队列设置操作实现QoS流调度。
在最新的OpenFlow规范中指出，OpenFlow交换机通过实现简单的队列机制，提供了QoS服务的支持。具体实现描述如下。一个端口中有一个或者多个队列。队列的配置由OF-CONFIG协议 [12] 实现，是与OpenFlow协议无关的。OF-CONFIG也是由ONF提出的，用于对OpenFlow交换机进行远程的管理配置。与OpenFlow协议职责不同，OF-CONFIG并非对流表的内容和数据转发行为进行配置，而是对例如OpenFlow交换机的控制器IP地址、交换机端口的队列等进行配置。因此该协议对实时性没有太高的要求。OF-CONFIG对OpenFlow交换机的队列属性配置包括队列的最小速率(Minrate)、最大速率(Maxrate)、自定义速率(Experiment) 3个参数。
控制器通过OpenFlow消息中的OFPMP_QUEUE_DESC对OpenFlow交换机中配置的队列进行读取访问。OFPMP_QUEUE_DESC消息中针对每个端口和每个队列提供了队列的描述。这个请求消息的结构体描述如下：
/*ofp_multipart_request中OFPMP_QUEUE_DESC消息的结构体*/
structofp_queue_desc_request {
uint32_t port_no; /* All ports if OFPP_ANY. */
uint32_t queue_id; /* All queues if OFPQ_ALL. */
};
OFPMP_QUEUE_DESC请求消息中包含了要查询的端口号(port_no)和队列号(queue_id)。宏定义OFPP_ANY和OFPQ_ALL分别表示查询所有端口和队列号。OpenFlow交换机根据收到的OFPMP_QUEUE_DESC请求消息，返回相应的应答消息。应答消息的数据结构如下所示：
/* OFPMP_QUEUE_DESC请求对应回复消息的结构体*/
structofp_queue_desc {
uint32_t port_no; /* Port this queue is attached to. */
uint32_t queue_id; /* id for the specific queue. */
uint16_tlen; /* Length in bytes of this queue desc. */
uint8_t pad[6]; /* 64-bit alignment. */
structofp_queue_desc_prop_header properties[0]; /* List of properties. */
};
OFPMP_QUEUE_DESC应答消息中包含了队列相关的信息，包括要查询的队列所在的端口号(port_no)、队列号(queue_id)、队列的长度(len)和队列的属性描述(ofp_queue_desc_prop_header properties)。OpenFlow中队列的配置根据不同的类型定义不同的属性，共有以下三种属性：
/* 队列类型定义*/
enumofp_queue_desc_prop_type {
OFPQDPT_MIN_RATE = 1, /* Minimum datarate guaranteed. */
OFPQDPT_MAX_RATE = 2, /* Maximum datarate. */
OFPQDPT_EXPERIMENTER = 0xffff /* Experimenter defined property. */
};
基于OpenFlow的SDN提供逻辑集中的控制平面，为支持灵活的流量调度策略，以满足不同网络应用的需求，缓解网络中某些关键路径或者是热点交换机/路由器等网络设备的拥塞。现有的关于利用SDN/OpenFlow支持QoS的相关研究描述如下：
Kim等人 [13] 提出了QoS网络控制框架，允许对QoS参数的编程，用高级切片描述的方式实现对网络中设备的QoS配置。然而，文章中并没有提出基于OpenFlow相关的自动QoS控制框架。
Egilmez等人 [14] 提出开放的流媒体控制体系架构OpenQoS，为多媒体视频流的传输提供QoS保证。利用基于多媒体视频流的报文头字段与其它类型的数据流中报文头字段存在的差异，OpenQoS把针对于OpenFlow的匹配规则将传输的流量分为多媒体视频流和其他数据流两种类型。针对多媒体视频流，OpenQoS结合传输路径在延迟、丢包测量得到的特性，在OpenFlow控制器上增加了服务层，为其选择一条满足QoS参数的传输路径，其它数据流仍然维持在原有的最短路径上。该方案的不足是，仅对多媒体视频流进行调度优化，并没有考虑多个有QoS需求视频流同时进行调度的场景。
基于上述研究，Egilmez等人在OpenQoS的基础上，针对大规模的SDN网络部署，提出了分布式的控制平面框架，支持多运营商在多媒体业务流方面的QoS服务需求。由于分布式的控制平面包含多个控制器，每个控制器在其管理的区域执行最优的QoS路由，那么他们之间为了实现端到端的QoS服务就必须与其他区域共享聚合的QoS路由信息。所以该研究主要提出了跨多个域实现端到端QoS服务的优化框架，设计了不同域间控制器交互QoS路由信息的消息机制。最后通过实验证明了这种分布式的QoS框架能达到接近最优的QoS保证。
Ishimori等人 [15] 从SDN数据平面的角度，即关注于QoS在底层OpenFlow设备中的实现，提出了对每个报文进行QoS调度的控制机制，也为每个服务提供不同的调度算法和流量整形。本文在数据平面实现时也借鉴该文章的一些方法。
Sonkoly等人 [16] 对Ofelia Control Framework (OCF)提出QoS形式化，并在其实验床上实现细粒度的QoS控制。实现的扩展模块包括OCF Expedient，Opt-In Manager，FlowVisor，和OF datapath等，主要是为了保证实验床的各方资源保证。该文章的不足是没有对其方法进行评估。
Ongar等人 [17] 提出一个在SDN网络中的集中式管理与编排框架，为实时多媒体应用实现区分的网络服务，以达到服务等级约束(Service Level Agreements, SLA)。他们的主要贡献包括以下几个方面。首先，该文定义了一个扩展的QoS架构完成了标准SDN形式与其解决方案的无缝整合。其次，他们利用SDN能力在有线与无线的整合环境下为多媒体应用提供有质量的网络服务支撑。
以上的相关研究表明，目前关于QoS的研究仅仅针对于某条路径或者某条流量，没有从全局的角度实现流量QoS调度。
5. 关键技术分析
5.1. 链路状态收集技术
为了实现QoS策略和流量感知的路由，一个重要的前提是需要实时地收集全局网络的流量状态信息，例如传输延迟、流的带宽、每条链路的报文丢包率。任何一个QoS路由算法的性能是与网络状态信息获取的精确程度相关，即流量状况信息越精确，QoS路由算法实现网络流量调度越精确。这种方法在传统的互联网中是不可行的，因为互联网采用的是完全分布式的体系架构。在分布式的流量感知路由计算过程中，附加的报文被用于告知相邻的网络设备其交换机和链路的状态，这对交换机来说是会增加较大的开销，而且这些附加的分布式链路状态通告协议也会占用部分链路带宽。此外，状态的收敛过程也相对比较缓慢。因此当前的路由协议对链路的流量感知能力较差。
在SDN架构下，集中的控制器可实现对全局网络的流量状态信息的获取。由原来的所有交换机共享所有的链路状态信息，转变为每个交换机向控制器发送流量状态信息。因此链路状态消息传递的复杂度从O(n2)变为O(n)。但是随着网络规模的扩大，流量信息收集越发困难。根据下面的分析可知，在一个中等规模的网络中，获取全局流量信息是不可能的，会消耗大量宝贵的交换机——控制器的通信带宽，必须在提高流量收集精度与减少流量收集开销之间找到折中。
另外，由于集中的控制器需要实时地访问交换机的统计信息，因此网络状态的精确程度与信息收集的频率相关。如果部分长流占据了大部分传输的流量，那么集中控制器只需要每隔几秒钟读取一次交换机的状态信息。如果不是在高性能计算的网络环境下，流量特征显示长流持续时间很短，只有几秒钟，因此要想获得比较精确的网络状态，必须更加频繁地读取交换机的状态信息。
OpenFlow支持三类每条流的计数器，分别是报文数、字节数、持续时间。OpenFlow为控制器提供了两类获取交换机状态信息的方式，基于推的“Push-based”和基于拉的“Pull-based”，描述如下。
1) 基于推的收集方法：控制器通过在流建立的过程中进行决策，学习了流的状态信息。OpenFlow协议中规定了控制器可以请求一个异步通知消息OFPT_FLOW_REMOVED，当交换机删除一条流表项时，控制器可得知该消息。因此控制器可指定某条特定的流对应流规则超时。OpenFlow既支持流表项的空闲超时机制，也支持流表项的硬超时机制。但是这种基于推的OpenFlow流规则删除机制不支持在表项超时之前通告控制器流的行为(例如状态等)，因此基于推的状态信息统计不适合于集中的流量调度。
2) 基于拉的收集方法：控制器发送Read-State消息获取某条匹配流的状态统计信息。但是DevoFlow中Curtis等人指出，在理想设置下，依据HP的5406zl OpenFlow交换机，读取16K条精确匹配规则和1500条通配规则总计返回1.3 MB的数据，如果是每秒钟收集两次，那么会超出17 Mbit/sec的交换机CPU与控制器通信带宽的上限。所以，通常情况下，Read-State消息只用来读取特定流或者多条通配流的统计信息，减少控制器与交换机交互的带宽。但这也阻碍了控制器获取全局网络流量的能力。
5.2. QoS路由优化技术
与传统分布式的模型不同，SDN利用全局网络视图为每条流的QoS控制提供了OpenFlow配置引擎，这种模型更加简化和高效。QoS路由过程描述如下。
Figure 3. SDN data plane support for QoS optimization
图3. SDN数据平面对QoS优化的支持
首先根据管理员的QoS参数设置作为输入，定义对应的流量信息。输入可以通过REST API加入到控制器中，或者通过扩展的OpenFlow请求，由主机发起。例如，某个用户建立一个高优先级的视频流请求，对应的分类标识是UDP端口号为4428，其余用户采用普通优先级。控制器接收到请求消息后转化为对应的队列调度编码。当建立的视频流以Packet_in消息发送至控制器时，控制器分析报文头，确定对应报文的服务等级，同时根据网络实时的拓扑，计算最有效的转发路径。
OpenFlow协议提供的排队机制，为每个特定类型的应用程序提供带宽保证。一个OpenFlow交换机通过一个简单的排队机制提供有限的QoS支持。一个或多个队列可以被连接到一个端口，然后通过它来转发数据包。数据包转发到特定的队列将根据该队列的配置(如最小速率或最大速率)进行处理。
图3中描述了在SDN环境下，OpenFlow交换机如何支持控制平面的QoS策略，以及实现基于QoS的报文转发。流量整形和报文调度模块接收控制发来的QoS策略，并将其转发为不同队列的划分，并配置其队列的属性。Enqueue操作将报文根据其队列id调度至对应类别的队列中。
6. 总结与展望
流媒体应用，例如网络电视、视频会议和视频点播要求可预测的、稳定的网络资源，几乎没有延迟的变化，没有报文丢失，但这对于标准的尽力而为的互联网来说是不可能的。因此，过去十年，IETF提出了很多的QoS框架(例如集成服务、区分服务等)，但是没有可以真正被部署和全局使用。这是因为，这些已经提出的体系架构是建立在当前互联网分布式逐条路由的体系架构，缺少对全网资源更广阔的视图。尽管MPLS这种隧道方式提供了部分的解决方案，但是它缺少实时地可配置性以及动态适应网络流量的能力。
OpenFlow作为一个新的可编程网络接口，允许所有的网络服务提供商提供创新的网络服务和网络虚拟化。SDN作为一个基于OpenFlow的新型网络架构，其基本概念是将路由的转发控制进行分离。为此，SDN能够提供一种有效动态的方式实现QoS重配置。
由于SDN提供了很大的灵活性和可编程能力，打破了原来网络封闭的体系架构模型，为网络创新注入强大的动力。因此，很多传统网络中难以解决的问题都可能在SDN架构下得到优化。本文也为其他网络服务在SDN框架下的实现提供了重要的实际借鉴意义。
基金项目
本文受863课题(2015AA015603)资助。