在前面,我们将基于目的地转发的特征总结为两个步骤:
查找目的IP地址(匹配),然后将分组发送到有特定输出端口的交换结构(“动作”)。
但是这种转发特征会带来许多问题,列如很多中间盒都有自己特殊的硬件、软件和管理界面,这对
于网络管理员来说是大麻烦,为此人们设计出了一种新的转发结构:“通用转发”。并且将使用通用
转发的中间盒叫作:“分组交换机。”
在通用转发中,一张“匹配加动作表”讲我们的基于目的地的转发表一般化了。
下图是一个位于每台分组交换机中的一张匹配加动作表,该表由远程控制器计算。
在这里,我们有必要了解一下OpenFlow标准,这是一个SDN革命的先驱标准。
我们主要探讨OpenFlow1.0.
其中,匹配加动作转发表在OpenFlow中称为:“流表”。
首部字段值的集合,在进入流表后会进行匹配。匹配不上的分组会被丢弃。
当分组与流表项匹配上后,就会更新计数器。
这些计数器可以包括已经与该表项匹配的分组数量。
这些动作可能将分组转发到给定的输出端口,丢弃该分组、复制该分组和将它们发送到多个输出端
口,或重写所选的首部字段。
值得注意的是,流表本质上是一个API,通过这种抽象每台分组交换机的行为能够被编程,类似
的,网络范围的行为也能够被编程。
下图是一个匹配示意图:
上图显示了11个分组首部字段和入端口IP,该IP能够被OpenFlow1.0中的匹配加动作所匹配。
OpenFlow的匹配抽象允许对上面的三个层次协议的首部所选择的字段进行匹配。
需要注意的是:
OpenFlow也可以有通配符,例如在流表中IP地址128.119.*.*将匹配其地址的前16比特为128.119的
任何数据报所对应的地址字段。
同时,流表也具有优先权,优先权越高,选定的匹配和对应的动作将是其中有最高优先权的那个。
对于流表项,其实都有零个或多个动作列表,这些动作决定了以用于流表项匹配的分组的处理。
但是如果以后有多个动作,它们在表中按以下规定的次序执行:
一个入分组可以转发到一个特定的物理输出端口,广播到所有端口,或通过所选的端口集合进行多播。
该分组也可能被封装并发送到用于该设备的远程控制器,该控制器则可能对该分组采取某些动作,
也可能忽略这个分组。
没有动作的流表项表明某个匹配的分组应当被丢弃。
在分组被转发到所选的输出端口之前,分组首部10个字段中的值可以重写。
也就是上图(图4-29中显示的除IP协议字段外的所有第二、三、四层字段)中的值可以重写。
下图是一个使用OpenFlow标准的网络图:
现在我们假定一个转发行为:“来自h5或h6发往h3或h4的分组从s3转发到s1,然后从s1转发到
S2(完全避免使用s2和s3之间的链路。)”
对于上面例子,在s1中的流表项将是下图:
同时s3中也会有一个流表项:
最后,还需要在s2中也有一个流表项用来完成例子,使得从s1到达的数据报转发到它们的目的主机
h3或者h4:
下面我们来考虑一个负载均衡的例子,其中来自h3发往10.1.*.*的数据报经过s1和s2之间的直接链
路转发,与此同时来自h4发送10.1.*.*的数据报也经过s2和s3转发,注意的这种行为将不能通过基
于IP的目的地转发取得,因此,此时的s2中的流表项如下图所示:
在s1中需要流表项将从s2收到的数据报转发到h1或h2,在s3中需要流表项将接口4上从s2收到的数
据报经过接口3转发到s1。
例如s2仅希望接收来自与s3相连的主机所发送的流量:
如果在s2的流表中没有其他表项,仅有来自10.3.*.*的流量将被转发到与s2相连的主机。