openflow流表转发分析

openflow转发和流表分析

本文基于Openflow 1.3.1版本分析报文转发过程和流表设计。

1.Hub

这是Openflow Tutorial中的示例，用Openflow实现Hub功能：把一个端口接收到的报文广播到所有其他端口。

在Openflow tutorial的示例中，Switch把所有报文都发送给Controller，Switch本身没有流表项。Controller负责广播报文。

改进：Controller可以下发（Match *, Output ALL）的流表项，这样Hub流量就不必送Controller 了。

问题：在FlowVisor的环境下，为了实现网络Slice的隔离，Output ALL流表项是否需要修改？

2.Learning Switch

这是Openflow Tutorial中的示例，用Openflow实现Learning Switch功能。Learning Switch是经典的交换机二层转发。经典交换机二层转发的机制包含两部分，第一部分是源地址学习，第二部分是目的地址转发。

示例中，Controller实现了MAC Learning和MAC Forwarding，交换机则没有流表项，所有报文送Controller转发。

讨论：Controller是否可以把MAC表项下发到Switch（Match DMAC，Output PORT），让流量直接在Switch转发，而不用通过Controller？

分析：假设Controller把MAC转发表下发到Switch（Match DMAC，Output PORT），那么我们可以分析一下h2与h4之间的通信过程，以及交换机的流表变化：

1)h2发送ARP请求，DMAC为广播，SMAC为h2。

2)Switch接收到ARP请求，没有匹配的流表项，把报文转发给Controller

3)Controller通过ARP请求报文学习到h2的MAC地址，并把MAC表项下发给Switch。

4)Controller把ARP报文广播出去（Output ALL），ARP报文到达h4

5)h4发送ARP应答报文，SMAC为h4，DMAC为h2

6)Switch收到ARP应答报文，由于DMAC h2可以匹配到流表项，因此ARP应答被直接转

发到h2

7)此后，h2和h4之间的通信，仍然与上述ARP交互类似，即h2→h4通过Controller转发，

h4→h2通过交换机直接转发

由上面的分析可以看到，当h2 ping h4时，h4→h2的反向流量能够直接在Switch转发，而h2→h4的正向流量则需要由Controller转发。原因在于h4→h2的反向流量没有机会被转发到Controller，使得Learning Switch学习不到h4的MAC。只有在其他情形下，使得h4的MAC能够被Controller学习到的时候，才能完全卸载Controller的流量。

结论：简单的把MAC table下发到Switch的做法不能有效的卸载Controller的流量处理压力。

3.Flow-based Switch

这个是Openflow Tutorial中的示例。基于前述Learning Switch的讨论，把MAC表项简单的下发给Switch并不能有效的卸载Controller处理压力，Flow-based Switch则提供了一种改进。Flow-based Switch的转发过程如下（仍然以h2与h4通信为例）：

1)h2发送ARP请求，SMAC为h2，DMAC为广播

2)Switch收到ARP请求报文，由于没有匹配的流表项，把报文转发给Controller

3)Controller从ARP请求报文中学习到h2的MAC地址，但是并不下发流表项

4)Controller把ARP报文广播出去，ARP报文到达h4

5)h4发送ARP应答报文，SMAC为h4，DMAC为h2

6)Switch收到ARP应答报文，由于没有匹配的流表项，把报文转发给Controller

7)Controller从ARP应答报文学习到h4的MAC地址。由于Controller同时学习到了SMAC

和DMAC，因此下发一对流表项给Switch：

a)Match DMAC=h2 and SMAC=h4, Output s1-eth0

b)Match DMAC=h4 and SMAC=h2, Output s1-eth2

8)Controller把ARP应答报文发送给h2

9)此后，h2与h4之间的通信可以直接在Switch上转发

可以看到，基于流后，一旦完成下发流表项，Switch能够完全卸载Controller的处理压力。

4.FlowVisor

这是Openflow Tutorial的一个示例。这个示例演示了通过对网络进行分片（Slice），来实现虚拟化的步骤：

1）配置控制网络：FlowVisor、Controller、Switch之间通信的网络。

2）定义流空间：对于示例，流空间就是Wireless设备收发的报文（SMAC或者DMAC匹配）3）运行Controller，FlowVisor能够自动代理Controller和Switch之间的Openflow通信，并对报文进行适当修改，以满足隔离的需求。具体参见openflow-tr-2009-flowvisor。

5.

L3 Routing

Cloud

为什么需要L3路由

在Flow-based Switch转发模型中，Controller并没有预先计算流的转发路径。当Controller 收到未知的packet-in消息时，Controller的行为与传统二层交换机类似：泛洪。因此，整个Switch Cloud是一个二层广播域，流的路径是“发现出来”的，而不是“计算出来”的。

在一个较大的网络里，如果仍然使用一个大的二层Switch Cloud，会有什么后果呢？由于接入用户数量巨大，流的数量也巨大，核心设备需要巨大的流表空间。另外，用户的流大部分是短生命期的流，导致核心层Controller需要频繁处理packet-in消息，核心设备则需要频繁更新流表。

上述问题并不是SDN/Openflow独有的问题。实际上，上述问题都是传统网络中的问题，也

是为了解决上述问题，传统网络才使用了分层的组网模型：在核心层使用L3路由来转发流

量。L3路由的转发是拓扑驱动的，只要拓扑稳定，L3路由就是稳定的，因此L3路由并不需

要频繁变动。另外，通过L3地址的聚合，还可以有效减少L3路由的容量需求。