OpenFlow Switch学习笔记(五)——Group Table、Meter Table及Counters

OpenFlow Switch学习笔记(五)——Group Table、Meter Table及Counters

来源：http://www.cnblogs.com/CasonChan/p/4623931.html?utm_source=tuicool&utm_medium=referral

　　本文主要详述OpenFlow Switch的另外两个主要组件——Group Table和Meter Table，它们在整个OpenFlow Swtich Processing中也起到了重要作用。

 

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、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仲裁器。

 

5、Counters

　　如前面几篇学习笔记中描述的，每一个Flow Table、Flow Entry、Group、Action Bucket、Meter和Meter Band都有一个Counters域，表示被其处理的数据包的统计量。这种机制可以由软件方式实现，也可以由硬件方式实现。下表列出了Counters的集合，但并不需要所有的Counter都需要支持：

            

Duration（Seconds）记录了该Flow Table或者Meter被安装到OpenFlow Switch内的时间，并且必须以秒为记录单位。

Receive Errors记录了所有接收到Switch里，但是发生碰撞冲突或者其他原因没有转发出去的数据包的数量。

每个Counter都是无符号的，并且没有溢出检查机制，如果一个数字Counter在Switch中不可用，那么我们需要将其默认设置为最大值。