open flow续

3、OpenFlow网络简介

从2007年提出至今，OpenFlow得到十足的发展，首先，好多设备厂商例如CISCO，Junifer，Toroki，pronto等相继推出支持OpenFlow协议的交换机、路由器、网络接入点等网络设备。同时，OpenFlow协议在全球得到很大的发展应用而不是仅仅局限于科研理论研究，例如OpenFlow已经在美国斯坦福大学、Internet2、日本的JGN2plus以及其他的10-15个科研机构中部署，并将在国家科研骨干网以及其他科研和生产中应用。OpenFlow的国际覆盖已经包括日本、葡萄牙、意大利、西班牙、波兰和瑞典等。
3.1OpenFlow架构
图 3‑1，这是最基本的OpenFlow网络架构图，主要分为三个部分，控制器（controller）、OpenFlow交换机（OpenFlow switch），终端（terminal）。

 

图3-1 OpenFlow架构

 

3.1.1控制器（Controller）

OpenFlow实现了数据层和控制层的分离，其中OpenFlow交换机进行数据层的转发，而Controller实现了控制层的功能。
Controller通过OpenFlow 协议与OF交换机的连接，对OF交换机内的流表和流表项的控制，然后数据流通过交换机的时候，通过与交换机内的流表以及流表项的匹配，使交换机完成对数据流的操作。Controller的这一切功能都要通过运行NOX来实现，NOX就像是OpenFlow网络的操作系统。
此外，在NOX上还可以运行Plug-n-serve、OpenRoads以及OpenPipes等应用程序。
Plug-n-Serve通过规定数据传输路径来控制网络以及服务器上的负载，从而使得负载均衡并降低响应时间。
OpenRoads是支持OpenFlow无线网络移动性研究的框架。
OpenPipes可以在网络系统中通过移动每个子模块来测试每个子模块，并可以决定如何划分设计单元。
3.1.2 OpenFlow交换机（OF Switch）

OpenFlow交换机由流表、安全通道和OpenFlow协议三部分组成。图3‑2，OpenFlow 交换机的逻辑结构图。

 

图3-2 OpenFlow交换机逻辑结构图

3.2.1.1流表
在交换机中的每个流表中包含的一组流表项，用来匹配数据包，每组流表项就是一个转发规则。进入交换机的数据包通过查询流表来获得转发的目的端口。流表项由头域（匹配字段）、计数器和操作（指令）组成；其中头域是个十元组，是流表项的标识；计数器用来计数流表项的统计数据；操作标明了与该流表项匹配的数据包应该执行的操作。

3.2.1.2 流表项
流表项包含：
匹配字段：对数据包匹配。包括入口端口和数据包匹配，以及由前一个表指定的可选的元数据。
优先级：流表项的匹配次序。
计数器：更新匹配数据包的计数。
流表项可能包含数据包转发到某个端口。这通常是一个物理端口，但它也可能是由交换机定义的一个逻辑端口或通过本规范中定义的一个保留的端口。保留端口可以指定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发。如“普通”交换机转发处理；而交换机定义的逻辑端口，可以指定链路汇聚组，隧道或环回接口。
3.2.1.3 指令

指令存在于流表项中，描述报文匹配流表项时OpenFlow的处理方式。指令可以修改流水线处理，如指导包匹配另一个流表，也可以包含一系列添加到行动集的行动，还可以包含一系列立即应用到数据包的行动。
3.2.1.4 安全通道

连接OpenFlow交换机到控制器的接口。控制器通过这个接口控制和管理交换机，同时控制器接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信，而且所有的信息必须按照OpenFlow协议规定的格式来执行。
3.2.1.5 行动

行动描述了数据包转发，数据包的修改和组表处理。流水线处理的指令允许数据包被发送到后面的表进行进一步的处理，并允许信息以元数据的形式在表之间进行通信。当与一个匹配的流表项相关联的指令集没有指向下一个表的时候，表流水线处理停止，这时该数据包通常被修改和转发。流表项相关的行动，也可直接把数据包发送到组，进行额外的处理。
3.2.1.6 行动集

行动集与数据包相关的行动集合，在报文被每个表处理的时候这些行动可以累加，在指令集指导报文退出处理流水线的时候这些行动会被执行。
3.2.1.7 组

组表示一组泛洪的指令集，以及更复杂的转发（如多路径，快速重路由，链路聚合）。作为间接的通用层，组也使多个流表项转发到一个单一的标识符（例如一个共同的下一跳的IP转发）。这种抽象的行为使相同的输出行动非常有效。
3.2.1.8 组表

组表包含组表项，每个组表项包含了一系列依赖于组类型的特定规范的行动存储段。一个或多个操作的行动用来使数据包发送到该组。

1、Group Table

 　　Group Table给OpenFlow Switch提供了更加高级的数据包转发特性（比如select或者all），其由多个Group Entries组成，而每个Group Entry结构如下所示：

                  

 每个Group Entry根据其Group Identifier来唯一定位，每项具体说明如下：

1）Group Identifier：一个32位无符号整数，Group Entry的唯一标识。

2）Group Type：决定了Group的语义，通俗地讲，就是表明了对数据包的处理行为，具体参考下文。

3）Counters：被该Group Entry处理过的数据包的统计量。

4）Action Buckets：一个Action Bucket的有序列表，每个Action Bucket又包含了一组Action集合及其参数。

 

2、Group Types

　　一个OpenFlow Switch不需要支持下列所有的Group Types，但必须支持下面加黑的类型：

1）all：Group Table中所有的Action Buckets都会被执行，这种类型的Group Table主要用于数据包的多播或者广播。数据包对于每一个Action Bucket都会被克隆一份，进而克隆体被处理。如果一个Action Bucket显示地将数据包发回其 ingress port，那么该数据包克隆体会被丢弃；但是，如果确实需要将数据包的一个克隆体发送回其 ingress port，那么该Group Table里就需要一个额外的Action Bucket，它包含了一个 output action 将数据包发送到 OFPP_IN_PORT Reserved Port。

2）select：仅仅执行Group Table中的某一个Action Bucket，基于OpenFlow Switch的调度算法，比如基于用户某个配置项的hash或者简单的round robin，所有的配置信息对于OpenFlow Switch来说都是属于外部的。当将数据包发往一个当前down掉的port时，Switch能将该数据包替代地发送给一个预留集合（能将数据包转发到当前live的ports上），而不是毫无顾忌地继续将数据包发送给这个down的port，这或许可以明显降低由于一个down的link或者switch带来的灾难。

3）indirect：执行Group Table中已经定义好的Action Bucket，这种类型的Group Table仅仅只支持一个Action Bucket。允许多个Flow Entries或者Groups 指向同一个通用的 Group Identifier，支持更快更高效的聚合。这种类型的Group Table与那些仅有一个Action Bucket的Group Table是一样的。

4）fast failover：执行第一个live的Action Bucket，每一个Action Bucket都关联了一个指定的port或者group来控制它的存活状态。Buckets会依照Group顺序依次被评估，并且第一个关联了一个live的port或者group的Action Bucket会被筛选出来。这种Group类型能够自行改变Switch的转发行为而不用事先请求Remote Controller。如果当前没有Buckets是live的，那么数据包就被丢弃，因此这种Group必须要实现一个管理存活状态的机制。

3.2.1.9 计量

一个交换机元件，可以测量和控制数据包的速度。当数据包速率或通过计量的字节速率超过预定义的阈值时，计量触发计量带。如果计量带丢弃数据包的功能，它则被称为一个速率限制器。
3.1.3 数据包在交换机中的处理

3、Meter Table

 　　Meter Table同样是由多个Meter Enties构成，每个Meter Entry定义每个 Flow 的 meters。基于此结构，OpenFlow Switch可以实现各种简单的QoS功能，比如速率限制等，再结合每个port的queues，可以实现更加复杂的QoS框架，例如DiffServ。

　　一个meter可以衡量与它关联的数据包的速率，并进而可以控制其聚合速率。任何一个Flow Entry都可以在其Instructions Set里指定某一个Meter，从而控制与该Flow Entry能够成功匹配的数据包的聚合速率。

　　Meter Entry的具体结构如下：

    

 同样地，每个Meter Entry都是由其Meter Identifier来唯一定位。具体每项说明如下：

1）Meter Identifier：一个32位无符号整数，作为一个Meter Entry的唯一标识。

2）Meter Bands：一个无序的Meter Band集合，每个Meter Band指明了带宽速率以及处理数据包的行为。

3）Counters：被该Meter Entry处理过的数据包的统计量。

 

4、Meter Bands

　　每一个Meter Entry都可能有一个或者多个Meter Bands，每个Meter Band指明了带宽速率以及对数据包的处理行为。数据包基于其当前的速率会被其中一个Meter Band来处理，其筛选策略是选择那个定义的带宽速率略低于当前数据包的测量速率的Meter Band， 假若当前数据包的测试速率均低于任何一个Meter Band定义的带宽速率，那么不会筛选任何一个Meter Band。

 　　Meter Band的具体结构如下：

        　　

这里，每个Meter Band以其定义的Rate来唯一标识。每项具体说明如下：

1）Band Type：定义了数据包的处理行为。

2）Rate：Meter Band的唯一标识，定义了Band可以应用的最低速率。

3）Counters：被该Meter Band处理过的数据包的统计量。

4）Type specific arguments：某些Meter Band有一些额外的参数。

　　Band Type的类型有如下两种，它们都是可选的：

1）drop：丢包，可以被用来实现一个rate limiter。

2）dscp remark：增加数据包IP头DSCP域的丢弃优先级，可以被用来实现一个DiffServ仲裁器。

 

OpenFlow 交换机具体的实现过程可以通过图3‑3得到直观的展示。

 

图3-3 OpenFlow交换机的实现过程

OpenFlow交换机在接收一个数据包时，执行在图 3‑4中所示的功能。交换机开始执行一个查找表中的第0个流表，并基于流水线处理，也可能在其它流表中执行表查找。
数据匹配字段从数据包中提取。用于表查找的数据包匹配字段依赖与数据包类型，这些类型通常包括各种数据包的报头字段，如以太网源地址或IPv4目的地址。除了通过数据包报头中进行匹配，也可以通过入口端口和元数据字段进行匹配。元数据可以用来在一个交换机的不同表里面传递信息。报文匹配字段表示报文的当前状态，如果在前一个表中使用Apply-Actions改变了数据包的报头，那么这些变化也会在数据包匹配字段中反映。
数据包匹配字段中的值用于查找匹配的流表项，然后再通过流表项对数据包进行处理，每个数据包在相应的流表中会有相应的流表项进行处理。如果流表项字段具有值的ANY（字段省略），它就可以匹配包头中的所有可能的值。如果交换机支持任意的的位掩码对特定的匹配字段，这些掩码可以更精确地进行匹配。
    数据包与表进行匹配，优先级最高的表项必须被选择，此时与选择流表项相关的计数器也会被更新，选定流表项的指令集也被执行。如果有多个匹配的流表项具有相同的最高的优先级的，所选择的流表项被确定为未定义表项。只有控制器记录器在传统的流信息中没有设置OFPFF_CHECK_OVERLAP位并且增加了重复的表项的时候，这种情况才能出现。
如果在流水线处理前，交换机配置包含OFPC_FRAG_REASM标志，IP碎片必须被重新组装。
当交换机接收到一个格式不正确或损坏的数据包，此版本的规范没有定义预期的行为。

                                         

     图3-4 数据包流流过交换机的详细过程