Dynamically managing the QoS with SDN (From ICC16.pdf)

 
介绍
    控制层和数据层的分开使SDN有可编程性，这种对于转发的抽象控制使得管理员可以动态调整网络流量，来适应变化的需求。SDN的主要架构设计包括基础设施，控制，应用，管理层。在控制器层面，通过配置policies来定义SDN应用控制的范围。传统SDN依靠管理平面来设置/管理/修改应用于switch的规则处理QoS。所以，终端不能与control plane进行交互，他们的功能只限于发送和接收packet。这样会进一步限制网络的适应性，因为动态QoS改变需要通过管理/控制平面，这可能直接影响请求新QoS与网络准备好管理它之间的时间间隔。

    为此，我们提出一种新的动态QoS管理方法，在SDN中的一个流的请求初始化由终端设备触发。在这个新的设计时，流程是以特定的QoS Request通过特定的端到端（E2E）通信路径由终端设备发起，并且基于实际通信而终止。这种技术将允许提供多样化和动态的QoS到垂直行业。我们的方法是，通过终端设备与control/management plane的直接交互来实现敏捷的QoS（重）配置。


SDN的QoS管理
                                                                                                                                                               
OpenFlow是控制与基础设施层之间的坚固接口。它通过添加或移除交换机中的flow table的rules来获得和管理基础设施层的配置。这些rules被SDN Controller使用北向接口编写。并使用OpenFlow来推送给基础设施层。这样，forwarding plan配置为执行一系列的功能，例如，基于packet到达switch的速率来有条件的转发。

QoS可以通过两种途径来管理：1. OpenFlow 2. SDN Controller。基于第一种，QoS可以通过OpenFlow的两个特性，queue 和 meter，来在基础设施层实现。属于某一个Flow的packet可以被设置到交换机的一个queue上，可以提供预设置的具有特定传输速率的output port。IP
 header的type of service 可以用于queue来实现QoS控制，比如DiffServ。Meter是可以用于设置一个传输速率阀值，作为一个限制器或一旦超过后可以触发其他的function。一个packet可以被分配到多个meter，每个都有自己的function。Meter和Queue的结合可以提供复杂的QoS管理。

DiffServ, IntServ, MPLS可以提供不同程度的保证和粒度的QoS，但是他们不允许一个特定应用为了E2E通信请求一定程度的QoS。在这个方向上，SDN提供了灵活性和动态性。尽管SDN控制器有建立一个数据流（flow）的能力，但是它不提供QoS Policy和管理机制来定义E2E流的限制。在这个方向上，有一个SDN网络的enforcing policies框架，名叫“PolicyCop”。这个框架允许SDN自动重新配置网络基于收集得到的网络元素统计信息，和他们与服务级别协议以及QoS参数之间的对比。尽管使用了这个框架，对于特定流或流的集合的Qos可以被动态的调整，packet loss可能会有所增加。另一种针对multimedia traffic prioritisation的QoS管理方案为“OpenQoS”。Packet首部被用于识别多媒体流量。Prioritisation通过访问所有转发设备的状态来获取每个设备的当前负载来实现。路径计算基于每个转发设备和多媒体packet的路径的负载来有根据的满足与要求的QoS。与PolicyCop相似，在OpenQoS流量分类被分配到特定QoS层次，是基于预设定的关于packet怎么被转发的policies。一旦路径被计算，频繁的对转发设备的负载测量会被用于一种反馈，以判断路径是否需要重新被计算。与PoliceCop相比OpenQos的范围更加有限，因为它基于链路使用转发设备的link utilisation作为measurement基础，而不是实际的多媒体应用需要的QoS metrics（延迟，jitter，throughput，丢包）。PoliceCop则使用实际的throughput测量，并证明了它重新路由（reroute）流的能力

在[10]中，北行的SDN的API用于将满足，实时在线交互式应用程序（ROIA）的实时动态QoS适配要求。作者认为ROIA根据应用程序状态可能有不同的QoS要求，他们使用在线游戏和电子学习作为例子说明如何应用程序和参与者的状态与它的交互转化为更高或更低的吞吐量和网络上的延迟。 他们建议北上API用于允许ROIA应用程序与SDN控制器通信，定义所需的服务水平网络。



终端流初始化

现有问题：
The end-devices are not able to interact with the network in the control and management planes.
1. request QoS characteristics
2. influence how their traffic is being forwarded.

解决：
SDN provides the use of controller modules for this functionality
End-devices can request
(i) QoS parameters according to the application needs
(ii) flow instantiation so as to satisfy these requirements.

Logical connection between end-devices and the management/control plane:
 1. Request/set-up
 2. Delete flows directly by the end-devices.

Introduce a new SDN controller module (or a new application)
 1. plays the role of QoS Broker in the network.
 2. End-devices contact the QoS Broker to request the level of service
 3. At different levels of granularity such as at device level or at application level.
 4. The request could be in form of a “service level bundle”
 5. QoS metrics are predefined in standardised policies or in the form of “explicit QoS values” for
     e.g., throughput, latency, jitter and packet loss.
6. The criticality of the communication should also be reported to the controller for prioritization  
     purposes, in particular if network lacks sufficient resources to satisfy QoS for all flows.