蒋暕青，华东师范大学研究生学历，先后于思博伦通信、上海宽带技术及工程研究中心、九州云就职。
一、引言
随着互联网的发展，为终端用户提供的新型网络应用和服务(如VoIP，电子邮件，音频，视频会议和流媒体，在线游戏，电子商务等)已经出现。这些应用程序和服务生成的特征流需要互联网来传递。但是，所有这些应用程序都需要针对自己的流量进行不同的处理，以使通过网络交付成功。例如，一些应用程序，如视频会议，需要一定的带宽，而VoIP等应用程序对网络上延迟更敏感。解决这些需求需要网络中定义良好的服务质量(QoS)机制。但是，当今互联网上的事实上的交付模式，即尽力而为交付（Best-effort)，不能满足上述所有需求。另外，现已提出的QoS解决方案还不足以成功解决传统网络的QoS问题。
互联网工程任务组（IETF）已定义了各种类型的QoS体系结构以支持QoS设置。集成服务(IntServ)模型[1]基于per-flow的概念。它利用资源保留协议(RSVP)[2]为终端用户提供QoS服务。在IntServ模型中，端到端路径显式地保留资源，因此所有路由器都将网络状态存储到服务中。因此，它存在可伸缩性和复杂性问题。为了缓解这种可伸缩性问题，研究人员提出了区分服务 (DiffServ)模型[3]，该模型基于流聚合，利用逐跳过程（hop-by-hop）。它根据信息包头中的服务类型(ToS)字段对输入流量进行分类(使用预配置的类)。由于DiffServ对同一类中的包的处理方式是相同的，因此很难向单个流提供定量的QoS。它在简单性方面很出色，但在保证方面却很弱。多协议标签交换(MPLS)[4]是另一种通过标签技术来减少复杂的路由表查找的技术。以上所述现有的网络解决方案所有这些优点和缺点都表明当前的QoS体系结构在为服务提供商，企业或最终用户提供QoS支持方面并不是真正成功的。
软件定义网络(Solftware Defined Network，SDN)是近年来出现的一种新型网络结构。SDN在开放网络基金会的定义中被描述为“在SDN体系结构中，控制平面和数据平面是解耦的，网络智能和状态在逻辑上是集中的，底层网络基础设施是从应用程序中抽象出来的”。这种分离为网络操作员和管理员提供了高效使用网络资源和简化资源配置的能力。此外，SDN还带来了可编程的功能，可以很容易地更改整个网络的特性。这种能力简化了网络的管理，因为它与数据平面是分离的。因此，网络运营商可以轻松快速地管理，配置和优化网络资源，使用自己在SDN体系结构中编写的动态，自动化，专有的程序。
此外，由于SDN在逻辑上是集中的，所以控制器对整个网络具有全局可见性，这与传统的网络工作方式不同。因此，它们可以动态地优化流程管理和资源。此外，对于网络管理员而言，按流（per-flow)或应用程序级QoS设置变得更加容易和可行。由于这些原因，SDN成功地吸引了公司，大学，数据中心和服务提供商的注意，并将其部署到他们的网络中。Google的专用WAN（B4 [5]）连接了全球各个位置的Google数据中心，这是在具有上述目的的大规模网络中采用SDN的示例之一。
二、SDN架构和OpenFlow协议概述
与传统网络相比，具有OpenFlow协议的SDN架构使网络运营商能够通过控制器以更细粒度的方式处理流。在传统网络中，流量（或数据包）主要根据数据包头的单个或几种属性组合来处理，例如最长的目标IP前缀，目标MAC地址，或IP地址和TCP/UDP端口号等的组合。SDN允许我们通过控制器-数据平面接口(C-DPI)，如OpenFlow协议，来管理基于更多包头属性的流。如图1所示，Open Networking Foundation (ONF)将SDN架构垂直分为三个主要平面。
图1 SDN网络概念图
数据平面：数据平面是底部平面，由路由器，物理/虚拟交换机，接入点等网络设备组成。这些设备可由SDN控制器通过C-DPI(控制器-数据平面接口)访问和管理。网络元素和控制器可以通过安全连接(如TLS连接)进行通信。OpenFlow协议是最流行的C-DPI标准，用于控制器和数据平面设计之间的通信。
控制器平面:SDN控制器平面由一个或多个基于软件的SDN控制器组成，通过C-DPI监控网络转发行为，提供控制功能。它具有用来支持控制平面内的控制器之间的通信接口(中间控制器平面接口，即I-CPI[6]，可选地使用TLS进行保护)，控制器和网络设备之间的通信(C-DPI)，以及控制器和应用程序之间的通信(应用-控制器平面接口，即A-CPI)。A-CPI使网络应用程序/服务与控制器之间的通信成为可能，以实现网络安全性，管理等。控制器由两个主要组件组成：功能组件和控制逻辑。控制器包括多个功能组件（例如协调器（Coordinator），虚拟器（Virtualizer）等）以管理控制器的行为。此外，控制逻辑将应用程序的网络需求映射为网络元素资源的指令。
应用平面:SDN应用程序平面由一个或多个网络应用程序组成，这些应用程序与控制器交互以将网络的抽象视图用于其内部决策过程。这些应用程序通过一个开放的A-CPI（例如RESTAPI）与控制器进行通信。SDN应用程序包含SDN App逻辑和A-CPI驱动程序。
在支持OpenFlow交换机的SDN网络中，交换机中有三个主要部分:流表，安全通道和OpenFlow协议。OpenFlow交换机维护许多包含流表项的流表。每个流表项由3部分组成：一个“规则”字段（Rule field），用于定义基于某些数据包报头属性（例如源/目标地址）的表项；适用于与“规则”字段中的值匹配的数据包的“操作”字段（Action field）；以及用于维护表项的某些计数器的“统计”字段（Stats field)[7] 。安全通道(例如TLS)是将数据平面元素连接到远程控制器的接口。交换机由安全通道上的控制器管理和配置。此外，控制器从交换机接收事件并通过此通道向交换机发送数据包。在SDN中控制器可以在三个运行状态下工作设置新的流规则的模式（也称为流表项，flow entry）：响应模式，主动模式和混合模式。
响应模式 在响应模式下，当新数据包到达网络设备(例如交换机)时，交换机在其流表中执行流规则查找。如果没有找到匹配的流，交换机使用C-DPI将其转发给控制器，以便控制器决定如何处理数据包。控制器根据网络策略处理数据包后，创建并发送一个要安装在网络设备中的流表项。基于数据包头属性与此流表项匹配的未来的流将根据相应的匹配规则进行处理。
主动模式 在主动模式下，在新的流到达交换机之前，先在交换机的流表中设置流序。当一个包到达一个交换机时，交换机已经知道如何处理这个包。在这种情况下，控制器不参与任何流规则设置过程。
混合模式 在混合模式下，控制器同时具有响应模式和主动模式的优点。网络管理员很可能会在数据平面设备中主动安装某些流表项，并且控制器会做出响应性的修改（删除/更新）它们甚至是根据传入的流量添加新的流量表项。
虽然主动模式带来了一些问题，即是关于交换机内存使用效率低下的担忧，但响应模式为控制器和交换机提供了更灵活、灵活和动态的环境[8，9]。
三、支持openflow的SDN网络中的QoS实现
尽管SDN和OpenFlow耦合支持一些有限的QoS功能，但与传统架构相比，它允许我们以一种更可伸缩，更灵活，细粒度更高的方式获得per-flow的QoS控制。
3.1 OpenFlow协议中的QoS
以下内容将重点介绍在OpenFlow规范的不同版本中实现的与QoS相关的特性和更改。
OpenFlow 1.0版本有一个名为enqueue的可选操作，它通过连接到端口的队列转发数据包。OpenFlow交换机根据其端口可以具有一个或多个队列。OpenFlow控制器可以查询有关队列的信息。但是，队列的行为是在OpenFlow范围之外定义，可以通过OF-CONFIG协议进行配置交换机。不过需要在OpenFlow 1.2以上版本才能得到支持。报文字段可以包括VLAN优先级和IP ToS，因此可以将数据包与规则进行匹配，并且可以重写其相关的标头字段。
OpenFlow 1.1执行VLAN和MPLS标签和流量类的匹配和标记。OpenFlow规范的早期版本限制了对VLAN的支持(仅支持语义模糊的单层VLAN标记)。新的标记支持具有添加，修改和删除VLAN标签的显式操作，并且可以支持多个级别的VLAN标签。这个版本的OpenFlow还添加了对MPLS填充头(shim headers)的类似支持。
OpenFlow 1.2增加了一种功能，使控制器能够查询交换机中的所有队列。它还增加了实验者队列属性。此版本OpenFlow中另一个与QoS相关的改进是添加了最大速率队列支持。此外，该版本指定可以将队列附加到端口并用于在端口上映射流。
OpenFlow 1.3引入了由Meter表项组成的Meter表（计量表）的限速功能（Meter表用于计量和限速，Meter表项可以针对流制定对应的限速等规则，从而实现丰富的QoS功能）。每个Meter表项的组织结构如下：
一个Meter表项可以包含一个或者多个Meter Band，每个Meter Band定义了速率以及动作，如果报文的速率超过了某些Meter Band，根据这些Meter Band中速率最大的那个定义的动作进行处理。计数器（Counters）可以按per-queue, per-meter,和per-meter band等方式进行维护。计数器可以帮助控制器收集有关网络的统计信息。每个表项可能有一个或多个Meter Band。计量表可以与可选的set_queue操作相结合，该操作将一个包与每个端口的队列相关联，以实现复杂的QoS框架(如DiffServ，区分服务QoS框架)。这些计量表通过允许在输出之前对流量进行速率监视，对OpenFlow中已经存在的队列框架进行了补充。具体地说，使用计量表，我们可以监控流量规则定义的流量进入率。可以使用可选的计量表(meter_id)指令将数据包定向到特定的计量表，然后计量表可以根据它接收数据包的速率执行一些操作。
OpenFlow 1.4提供了流监控框架，允许控制器实时监控其他控制器对流表的任何子集所做的更改。为此，控制器可以定义一些监视器，每个监视器选择流表的一个子集。每个监视器包括一个表id和一个定义所监视的子集的匹配模式。当在流监控器定义的一个子集中添加，修改或删除流表项时，将向控制器发送一个事件，通知其更改。
OpenFlow 1.5用一个meter动作替换了先前版本中用于计量的meter指令。因此，可以将多个meter连接到一个流表项，并且可以在组桶中使用meter。
3.2 SDN控制器中的QoS
由于OpenFlow规范中目前不支持队列配置，所以队列配置由特定的OF-CONFIG和OVSDB (Open vSwitch数据库管理协议)协议处理。前者目前正在由ONF进行标准化，而后者已经由IETF进行标准化。尽管OVSDB已经在OVS交换机中实现，但是还没有提供标准化队列管理的可用控制器。目前，有许多不同的SDN控制器平台为用户提供各种功能。虽然有许多来自不同供应商的商业和专有的SDN控制器，但也存在一些来自研究社区和业界的积极开发支持的合作和开源项目。下面，将讨论一些在较为活跃的开放源码SDN控制器项目，这些项目都支持QoS。
OpenDayLight(ODL)是一个社区主导的开源控制器平台。这是一个Linux基金会的协作项目，支持SDN的使用。ODL社区共同建立一个开放的参考控制器框架，致力于自由编程和控制SDN架构。ODL项目由许多其他子项目组成，如南向协议插件(如OpenFlow、NetCONF、SNMP和BGP)和应用程序(如DDoS保护和虚拟化协调器)，它们相互补充，构成了一个完整的异构网络参考控制器平台。PCMM (Packet Cable Multi Media)是在2015年6月的ODL-Lithium发布会上发布的，它是另一个南向接口的插件，用于为DOCSIS基础设施提供基于流的动态QoS。分组电缆多媒体（PCMM）为CMTS网络元素提供了控制和管理服务流的接口。另外，OVSDB 南向接口插件已经在ODL-Lithium 发行版中引入，它可以管理和配置交换机中的队列。此外，ODL中的预留模块还旨在提供动态的底层资源重分配，以便用户可以在特定的时间内获得网络服务，连接或资源池(端口，带宽)。
ONOS (Open Network Operating System，开放网络操作系统)是一个分布式SDN网络控制平台，旨在为服务提供商提高网络的可伸缩性，性能和可用性。它也是一个开源平台，拥有超过50个合作伙伴和合作者，为项目的各个方面做出了贡献。目前ONOS具有有限的QoS支持。它支持OpenFlow计量机制，但是这个特性很少在现有的交换机中实现。这种支持背后的思想是基于ONOS中OpenFlow集合队列功能的实现。作为ONOS中另一个QoS支持改进尝试，在org.onosproject.net.flow.instructions库中实现了一个新的高级指令SetQueueInstruction，并对ONOS库中相应的引用进行了相应的修改。
Floodlight是另一个基于java的开源SDN控制器，它得到了社区开发人员(包括来自大型交换机网络的工程师)的支持。在Floodlight的基础上建立了一些社区驱动的项目，这些项目建议集成和更新，新的和现有的模块。为Floodlight控制器实施的QoS模块旨在提供一种应用程序，该应用程序负责进行QoS的匹配，分类，流插入，流删除和策略处理等工作。该模块利用OpenFlow 1.0 enqueue操作和网络流量的ToS位。它控制跟踪和存储带有DSCP值的服务，为服务类应用策略，以及在交换机中跟踪策略。QueuePusher扩展利用与Floodlight的北向API集成的OVSDB协议来生成适当的队列配置消息。QueuePusher模块使用CRUD(创建、读取、更新、删除)API，该API由Floodlight公开，允许外部实体管理Open vSwitch。
四、SDN和QoS之间的关系
QoS通常定义为网络为选定的网络流量提供所需服务的能力。QoS的主要目标是提供与QoS参数相关的优先级，包括但不限于：（1）带宽或吞吐量；（2）时延；（3）抖动（时延变化）和（4）丢包率等QoS指标。为了提供QoS，需要对应用程序流进行差异化处理，因为它们共同争夺可用的网络资源。必须对这些网络资源进行分配，以确保较高优先级的流量优先于适当的网络工作资源分配。此过程通常需要了解当前的网络状态，以便可以就数据包转发做出正确的决定。
目前，QoS配置主要依赖于终端用户和服务提供者之间的服务水平协议(sla)。这种方法适用于Best-off服务，不支持细粒度的流量控制。然而，还有其他类型的应用程序，如VoIP，在线游戏和视频会议，其流量对延迟，抖动和带宽非常敏感，因此需要特殊处理。此外，Internet的逐跳决策体系结构有时很难监控，这主要是由于在使用的许多特定于供应商的固件不同造成的。对于流量分化的深度，目前还没有统一的方法来规定高层次的流量控制策略和限制。
QoS主要有两种实现方式：硬QoS（hard QoS）和软QoS（soft QoS）。硬QoS方法保证了连接的QoS要求，但存在资源限制。IntServ方法就是硬QoS保证方法的示例方法。另一方面，软QoS方法在QoS要求上没有硬QoS方法严格。DiffServ是软QoS的一个示例方法。SDN网络采用数据平面与控制平面分离的网络方式。这种分离增强了网络控制器对网络的控制。此外，在SDN中网络应用程序不必处理数据平面设备的底层配置，控制器可以提供网络的抽象视图。
五、基于多媒体流的路由机制
随着互联网上新型应用(例如视频会议，VoIP等)的普及，这些类型的应用需要更复杂和更有效的路由机制来满足它们的QoS需求。但是，当今传统网络中的路由存在一些未解决的问题（例如网络的全局视野有限，路由每跳决策和流量的QoS能力有限等问题）。SDN和OpenFlow对被认为是解决当前网络路由问题的一个有前景的解决方案架构。SDN中控制平面和数据平面的解耦带来了很多路由功能的机会。由于SDN的逻辑集中控制器组件，使得在SDN/OpenFlow网络中支持实现QoS变得更加可行。使用OpenFlow，可以在控制器中使用具有不同目的的各种路由算法，例如某些延迟限制或包丢失(而不仅仅是最短路径路由)，并在转发设备中相应地生成流表。网络流量可以在per-flow的基础上进行动态路由，通过控制器实现路径的端到端QoS。此外，它允许以一种比现在网络架构更有效的方式利用网络资源。
近年来，一些如视频会议，远程学习和交互式教学等对于QoS具有高要求的多媒体应用越来越普遍。在互联网上高效传输流媒体带来了许多挑战。这些多媒体流需要稳定的网络资源，很少或没有丢包和延迟能够随应用程序的变化而变化。例如，VoIP数据是对时延敏感的HTTP数据，要求可靠的传输。这说明不同类型的媒体在相同的情况下可能存在不同的质量损失。因此，设计能够适应不同网络条件的多媒体流路由框架就变得非常重要。流的分类和优先级是设计此类框架的关键。
在[10]中研究了视频流在OpenFlow网络上的QoS路由问题。提出了一种基于线性规划的可伸缩视频编码(SVC，Scalable Video Coding)底层视频流在计算QoS流路由时可减少丢包和保持可容忍延迟的计算公式。其思想是保持典型最短路径上的尽力而为的流量（best-effort traffic），并维护一个尽力而为的流量表（best-effort traffic table），同时视频流在根据所提公式计算出的QoS丰富（QoS-rich）的路径上进行路由，并为其维护QoS流表。HiQoS应用程序[11]利用了[12]中提出的基于SDN的等代价多路径路由算法(ECMP，(Equal Cost Multipath Routing))来查找源地址和目的地址之间的多条路径，并使用排队机制为不同类型的流量提供带宽保障。它通过SDN交换机上的排队机制来区分不同类型的流量，并为不同的服务提供不同的带宽保证。多路径路由组件在源节点和目标节点之间找到满足一定QoS约束的多条路径，通过实时监测网络状态，计算出per-flow的最优路径。在文献[13]中提出了一种支持QoS的视频流的OpenFlow控制器(OpenQoS)设计。该体系结构的关键概念是将传入流分类为多媒体流和使用数据包报头字段的数据流。这些流是在QoS支持的路径上动态路由的，而数据流则遵循最优路由。另一种支持SDN网络视频应用QoS的控制器体系结构和协议(VSDN)在[14]中提出。它允许视频应用程序从网络请求端到端保证服务。它们通过修改OpenFlow提供的有限的交换功能来实现有保证的服务（GS，Guaranteed Services ）。OpenFlow的队列属性结构，ofp队列属性已经被修改为支持基于GS的队列，因为ofp队列支持GS速率以包含基于令牌桶的流量整形所需的字段。VSDN交换机为每个请求流创建一个令牌桶整形队列。使用GS的排队过程根据VSDN控制器提供的流量规范来调节per-flow的流量。[15]中的研究是VSDN体系结构的扩展，通过在要求的QoS路径的路径计算问题中增加可靠性约束，解决视频流的可靠QoS支持。针对网络中不同的路由处理，采用流分类的方法。Tomovic等人[16]还提出了一种SDN控制器体系结构，该结构基于自动化流程中的优先流规范执行路由计算和资源保留。它使用一种算法来避免高利用率的链接，即使通过流量也是以尽力而为的（Best-effort)方式处理的。
显然，要找到为流量提供最佳QoS的路由并不是一项简单的任务。此外，计算这样的路由是不够的，因为网络资源可以随时动态变化。因此，对于流来说某个路径可能不是一个好的路径。为此，需要考虑这些网络变化的框架来保证流在QoS保证路由下，并提供优化的QoS。QoS路由应该优化一个不同于简单路径长度的成本函数。例如，即使距离较长，容量也更大的路由可能比可能导致数据包丢失的较短的路由更可取。在[17,18]中，文献作者提出了一个在OpenFlow控制器上具有动态重路由能力的视频流优化框架。为此，他们引入了两个优化问题及其公式。在第一个问题中，只在拥塞条件下路由无丢包的QoS流(SVC编码视频的底层)。在第二个问题中，无损QoS流和有损QoS流(SVC编码视频的增强层)分别以无丢包和最小丢包为目标进行路由。自适应路由视频流算法((Adaptive Routing Video Stream ing，ARVS)[19]也研究了同样的视频数据包自适应路由优化问题。在ARVS中，如果最短路径不满足时延变化约束，那么基于该路径的可用带宽，底层数据包有优先级被重路由到计算出的可行路径，而增强层数据包将保持在最短路径上。但是，如果此路径中没有可用带宽，则基础层数据包将保留在最短路径上，而增强层数据包将重新路由到此路径。
服务器负载平衡会影响最终用户的视频流质量。服务器负载平衡需要持续监视每个服务器的负载，并动态地将当前或新服务请求重新路由到可用的服务器，以降低服务器过载时的延迟和失真。SDN可以帮助缓解这一问题，因为它可以向用户提供全局网络视图。针对这个问题，在文献[20]中提出了一个负载平衡应用程序，它可以重定向视频流的流向。当应用程序检测到服务器过载时，它计算连接用户到每个服务器的每个路由的成本指标(包丢失和延迟)。旧的流被删除，新的流沿着新的成本最低的路由推送到所有的交换机。
对网络运营商来说，为网络工作流程提供QoS保证的路径是一项具有挑战性的任务。这一目标要求在提供这些路径之前考虑许多限制因素(例如带宽、延迟等)。研究人员预计，SDN和OpenFlow耦合可以帮助网络管理员使基于流的路由与其当前状态相比更加容易，因为它可以提供集中的，更细粒度的流管理以及全局网络视图。因此，他们提出了各种路由框架，利用SDN和OpenFlow的优势，以使网络路径的QoS配置更容易。
参考文献
[1]R. Braden, D. Clark, S. Shenker, RFC 1633 : Integrated Services in the Internet Architecture: an Overview (1994). URL www.ietf.org/rfc/rfc1633.txt
[2] L. Zhang, S. Berson, S. Herzog, S. Jamin, RFC 2205 : Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification (1997). URL www.ietf.org/rfc/rfc2205.txt
[3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475 : An Architecture for Differentiated Service (1998). URL www.ietf.org/rfc/rfc2475.txt
[4] E. Rosen, A. Viswanathan, R. Callon, RFC 3031 : Multiprotocol Label Switching Architecture (2001). URL www.ietf.org/rfc/rfc3031.txt
[5] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. H¨olzle, S. Stuart, A. Vahdat, B4: Experience with a globally-deployed software defined wan, in: Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM, SIGCOMM ’13, ACM, New York, NY, USA, 2013, pp. 3–14. doi:10.1145/2486001.2486019.
[6] P. Lin, J. Bi, S. Wolff, Y. Wang, A. Xu, Z. Chen, H. Hu, Y. Lin, A west-east bridge based sdn inter-domain testbed, Communications Magazine, IEEE 53 (2) (2015) 190–197. doi:10.1109/MCOM.2015.7045408.
[7] OpenFlow Switch Specification, 1.5.0 (December 2014). URL https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/ openflow-switch-v1.5.0.noipr.pdf
[8] M. Fernandez, Comparing OpenFlow Controller Paradigms Scalability: Reactive and Proactive, in: Advanced Information Networking and Applications (AINA), 2013 IEEE 27th International Conference on, 2013, pp. 1009–1016. doi: 10.1109/AINA.2013.113.
[9] W. Braun, M. Menth, Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices, Future Internet 6 (2) (2014) 302. doi: 10.3390/fi6020302. URL http://www.mdpi.com/1999-5903/6/2/302
[10] S. Civanlar, M. Parlakisik, A. Tekalp, B. Gorkemli, B. Kaytaz, E. Onem, A qos-enabled openflow environment for scalable video streaming, in: GLOBECOM Workshops (GC Wkshps), 2010 IEEE, 2010, pp. 351–356. doi:10.1109/GLOCOMW. 2010.5700340.
[11] Y. Jinyao, Z. Hailong, S. Qianjun, L. Bo, G. Xiao, Hiqos: An sdn-based multipath qos solution, Communications, China 12 (5) (2015) 123–133. doi:10.1109/CC.2015.7112035.
[12]H. Zhang, X. Guo, J. Yan, B. Liu, Q. Shuai, Sdn-based ecmp algorithm for data center networks, in: Computing, Communications and IT Applications Conference (ComComAp), 2014 IEEE, 2014, pp. 13–18. doi:10.1109/ComComAp.2014. 7017162.
[13] H. Egilmez, S. Dane, K. Bagci, A. Tekalp, Openqos: An openflow controller design for multimedia delivery with endto-end quality of service over software-defined networks, in: Signal Information Processing Association Annual Summit and Conference (APSIPA ASC), 2012 Asia-Pacific, 2012, pp. 1–8.
[14] H. Owens, A. Durresi, Video over software-defined networking (vsdn), in: Network-Based Information Systems (NBiS), 2013 16th International Conference on, 2013, pp. 44–51. doi:10.1109/NBiS.2013.10.
[15] H. Owens, A. Durresi, R. Jain, Reliable video over softwaredefined networking (rvsdn), in: 2014 IEEE Global Communications Conference, 2014, pp. 1974–1979. doi:10.1109/ GLOCOM.2014.7037097.
[16] S. Tomovic, N. Prasad, I. Radusinovic, Sdn control framework for qos provisioning, in: Telecommunications Forum Telfor (TELFOR), 2014 22nd, 2014, pp. 111–114. doi: 10.1109/TELFOR.2014.7034369.
[17] H. Egilmez, B. Gorkemli, A. Tekalp, S. Civanlar, Scalable video streaming over openflow networks: An optimization framework for qos routing, in: Image Processing (ICIP), 2011 18th IEEE International Conference on, 2011, pp. 2241–2244. doi:10.1109/ICIP.2011.6116083.
[18] H. Egilmez, S. Civanlar, A. Tekalp, An optimization framework for qos-enabled adaptive video streaming over openflow networks, Multimedia, IEEE Transactions on 15 (3) (2013) 710–715. doi:10.1109/TMM.2012.2232645.
[19] T.-F. Yu, K. Wang, Y.-H. Hsu, Adaptive routing for video streaming with qos support over sdn networks, in: 2015 International Conference on Information Networking (ICOIN), 2015, pp. 318–323. doi:10.1109/ICOIN.2015.7057904.
【转载须知】
若转载文章为原创文章，可在相应文章下或公众号后台留言；其他非转载类文章须在文首以不小于14号字体标明转载自SDNLAB。
