system: [SYSTEM]

user: 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调度。