DevoFlow对Openflow的优化

Openflow的标准到现在为止已经发展到了V1.4，但是离能够大规模商用部署仍有相当距离，因为它仍有一些关键问题无法解决

1）根据openflow的spec，必须使用TCAM来支持flow，flow数量巨大，所以导致TCAM必须也很大。芯片中的TCAM可是个奢侈品，占用面积大，一条TCAM entry基本上相当于5条DRAM entry的面积，且功耗也很大。这样导致整个交换机系统硬件成本和功耗都居高不下，无论是内置还是外挂。

2）每条flow都需要有一个counter,每条flow都要有一个timer，这些counter和timer都需要centralized controller来统一管理，当flow数量变大的时候，对这些counter, timer的管理开销（controller跟switch之间的通信开销，switch和controller自身的计算开销）非常巨大，scalability是个大问题

3）每条flow的创建都需要controller的参与，而且是switch跟controller之间一来一回，不仅带来额外的通信开销，而且导致flow的install有延迟，影响报文转发。

4）实际的数据中心网络里面，影响网络拥塞的可能就是10%的flow，这些flow贡献了90%的流量。所以，网络中花了那么多代价对另外90%的flow去管理，优化，性价比太低，等于是浪费了，再怎么去load balance，对网络产生的影响也很有限。而去优化那10%的significant flow，则是有价值的。

正是基于对以上的openflow中的问题的认识，Waterloo大学的研究人员发表了一个paper，介绍了一个叫DevoFlow (Devolve Flow)的机制，来优化openflow. 这个机制基于的前提假设条件就是实际的数据中心网络里面，10%的flow贡献了90%的流量，重点需要来管理优化这部分flow，对于其它flow，用最简单的load balance方式去处理就行了，管它呢。

这个机制的总体工作原理大概可以分为三部分

1）检测这些10%的flow, 这些flow称之为elephant flow（相对于其它的mice flow)

2) 抽取标志性的字段，来install exact match的flow entry (使用hash)

3) 对这些elephant flow进行管理，如路径优化

大概的工作原理如下。

1）先install少量TCAM entry,来标志一些aggregated flow (比如具有相同的destination IP,或者相同的source IP等）。

     然后对这些flow进行监控。 有几种机制，最简单的是定期看它的statistics,如果在一段时间内超过了某个threshold,

     就从报文中提取出关键字段，加到hash表里面去。或者对这条aggregated flow进行采样分析，一旦超过了threshold,

     就从报文中提取出关键字段，加到hash 表里面去。而更有效地我觉得还是使用他们所谓的approximate counter，

    这只是一个概念，具体到实现，可以才用bloom filter算法（paper中并没有提），这个算法可以用很小的误差率来检测一条elephant flow，

     而前面两个则都不能做到。

     但是无论哪种做法，最后都将标志性字段提取出来（比如IPSA+IPDA+protocol+L4dest port + l4 source port),然后install到hash table.

     在芯片里面查表的时候看，会同时查hash table和tcam table，hash table结果优先。

2）install elephant flow到hash table的时候，可以选择一条流量最轻的路径给它。

3）这些elephant flow还可以被老化

4）对于非elephant flow，直接使用传统的ECMP，根据hash结果去选择一条路径，不管是heavy utilization or light utilization.

5) elephant flow也可以不指定一条固定的路径，而是使用multiple path,但是选路的时候，是要使用DLB (dynamic load balance)机制，动态的选择流量最低的路径。 当然DLB的机制就算不使用DevoFlow, 普通的openflow也可以用。所以这个不属于DevoFlow的发明创造。

DevoFlow需要芯片的强有力的支持。

http://bbs.c114.net/blog-18988-178.html