背景介绍

在OpenStack Neutron中，我们可以认为在neutron控制面的帮助下，我们可以在预部署的硬件资源上分配租户所需要的网络网络拓扑，数据路径等，并规定租户的流量进入虚拟网络后的行为约束，如过滤(filtering)，协议窥探(snooping)等，因此neutron可以类比成传统的电路交换(circiut switching)网络，用户接入网络预先分配并独占网络资源。在这样的前提下，用户很难对虚拟出来的网络资源表现得非常自信，原因有包括但不限于如下的几方面：

▪ 租户对网络基础设施资源的可见性低。尤其是在NFV场景下，租户不能感知当前流量在真实的物理网络设备上的流向。

▪ 租户对网络基础设施资源的可审计性非常差。如在NFV场景下，现有的neutron网络很难保证在任何情况下(无论其他租户的流量业务有多么繁忙)一条端到端的10G虚拟链路。

▪ 租户不能很好感知网络资源的利用情况。

其原因是neutron所提供的框架和API是厂商中立的(vendor neutral),从而导致物理网络与虚拟网络在一定程度上不能很好的契合。

本文不再综述目前厂商的软硬件一体化网络解决方案，也不提出一种新的面向商业硬件的neutron的解决方案构思，而简单介绍两种在云环境下的二层交换技术，并在一定程度上解决上述列出的需求。

TRILL

TRILL 是一个IETF规范，最开始由cisco贡献的草案，作为标准，其内容被包含在RFC 6325（https://tools.ietf.org/html/rfc6325）等中，其核心思想是借助路由(routing)来完成L2 交换功能，因此，TRILL设备也被称为Rbridge。

在传统的802.1d兼容的桥中，我们为了提高桥的高可用性和防止冗余链路环回，我们引入了生成树协议STP以及一系列的变种，通过图1，我们可以看出一个典型的利用STP部署的L2交换网络。
图1 生成树网络

图中有两个端系统接入L2网络，一个可能的active的拓扑确实会存在(例如推举后的root bridge为图1中最左侧的桥)，可以看出，如果这种情况下的端系统之间的代价将会非常的大。但是我们有没有一种办法把处于blocking的链路都使用起来从而得到更高的使用率以及端到端的通信效率，即最短路径问题？ TRILL通过将RBridges部署到现有的802.1d兼容的网络中，在多路径网络中实现最短路径转发。
其拓扑抽象如下：

图2 TRILL拓扑抽象

TRILL中Rbridge可以以多链路的方式接入到现有的交换网络中，并不旨在完全替代现有的交换网络，而是增量部署RBridge的方式来扩展原有的桥功能，因此其本质customer bridge，对provider bridge甚至provider backbone bridge的支持，RFC6325明确指出会在将来的规范中支持。接下来，RBridge中有多条链路接入现有的交换网，对于一个客户的流量，Rbridge必须明确的知道报文从其中的某条链路上转发，确定这个链路的过程就是路由。一个用户端到端的转发流程如下所示：

图3 端到端转发路径

用户流量以vlan的方式进入Ingress Rbridge，Ingress Rbridge根据目的用户目的mac地址以及vlan对报文TRILL封装，接下来开始一系列的路由和转发，最后解封装并到目的达端系统。

接下来简介TRILL 数据帧封装格式，TRILL采用mac-in-mac的封装格式，用户流量与TRILL核心网络的流量完全隔离，因此可扩展性非常的好。

图4 TRILL封装帧格式

其中，以太网类型为0x22F3，接下来的两个字节中包含了标志(是否是多播、版本号，选项长度)字段和hop数，hop count计数器先当于IP头部的TTL字段。

任何RBridge接收到Hop count为0的数据包都应该丢弃，并且Transit Rbridge在每次转发的时候会对hop count的值减少1（或者大于1）来确保TRILL核心网络中不会出现永无休止的广播风暴。接下来是Egress和Ingress nickname，其长度分别为2个字节，作用相当于IP头部中的目的IP地址和源IP地址。

Transit Rbridge知道对于一个Egress Nickname，应该从哪一个链路上转发该报文。

对于TRILL的控制面，这里不再详细述说，最后我们可以总结出几点：

▪ TRILL支持多路径转发，在网状结构的网络中，TRILL能更好的利用网络带宽资源。
由于TRILL 头部中hop count存在，环路可以存在。但在有限的转发后终止。

▪ mac 和vlan以及port的映射关系只有在ingress/egress Rbridges中学习到，transit Rbridge不关心任何用户的数据。

▪ nickname组成的转发表只在TRILL核心网络中扩展。综上两点，TRILL是一个扩展性非常好的大二层协议。

▪ TRILL核心网可以引入802.1q 进而更细粒度的转发。

SPB（Shortest Path Bridge）

SPB是IEEE 规范，其内容包含在802.1aq(http://www.ieee802.org/1/pages/802.1aq.html)草案中,与TRILL一样，旨在使用多路径最短路径转发的方式来对mesh-like网状结构的网络支持，但是TRILL把分层的路由转发的思想实施得更为透彻，接下来我们会通过介绍SPB说明这一点。

首先SPB利用802.1ah PBB封装来只提供backbone bridge 服务，因此，其本质上可以兼容802.1d，802.1q和802.1ad用户流量。下面我们简述PBB封装的帧格式：

图5 PBB报文帧封装格式

在PBB是一种Mac-in-Mac的封装格式，在PBB帧中存在4中tag，他们分别是：B-tag,I-tag,S-tag,C-tag。

其中B-tag为backbone中vlan 标识。I-Tag为 PBB实例tag，其格式如图5所示，其中I-tag中包含一个24bit的实例标识符，称为I-Tag，用于标识数据帧属于的用户。S-Tag和C-tag为802.1ad QinQ和802.1Q报文中的VLAN标签，用户细分用户流量。

802.1ah规定数据帧的封装方式，但不规定封装后的帧应该如何转发，802.1aq恰好弥补这一点。PBB规定，S-Tag/C-Tag可以n:1映射为一个I-Tag，I-Tag可以n:1再次映射成B-tag。

有关PBB的规范参见：http://www.ieee802.org/1/pages/802.1ah.html
接下来简述SPB转发流程，首先如下图所示：

图6 SPB转发封装示例

端系统数据帧(这里假设用户采用基于端口的策略)的进入Backbone Edge Bridge（BEB，类似TRILL中的Ingress/Egress Bridge）后，会按照PBB的格式分装成一个PBB帧，这里我们主要关心的是外层以太网帧的头部，其中B-DA为目的BEB的核心网侧的添加都B-VLAN的端口的mac地址，类似地，B-SA为源BEB的某核心网侧的附加到B-VLAN的端口的mac地址。

B-VLAN通过配置，并与I-TAG绑定，BEB收到PBB封装的帧后，解封装，进入用户桥流程。流量在经过Backbone Core Bridge时，其转发依据为I-Tag，但不会修改帧的内容。

同样，这里不再述说SPB控制面的细节。我们可以有如下几点总结：

▪ SPB依靠PBB封装，并且转发流程中隔离了用户侧和核心网络侧的流量，因此具有不错的可扩展性。

▪ SPB中通过I-Tag来标识用户，并且以此作为转发依据，可以支持2^24个用户。

▪ SPB转发依靠B-VLAN，因此要求现有网络必须是802.1q兼容网络。

▪ 从SPB工作流程，我们可以发现它更像VXLAN协议。

总结

TRILL和SPB均是一种网状结构网络下的多路径最短路径转发的二层桥技术，其侧重点有所不同，SPB侧重于多用户的支持，非常容易支持云环境下的多租户，TRILL侧重于转发层面的路由功能，因此，TRILL更像是一种应用到L2 交换中L3路由转发技术。这两种协议并不是相互排斥，而是互补的。

回到最开始的问题，我们可以发现两中协议对底层基础设施网络结构都有着强的可见性，并且两种协议均支持等价多路径（ECMP），在一定程度上可计量对底层基础设施网络资源的利用情况。

最重要的一点是基础设施网络中，由于充分利用多路径，使得链路带宽资源非常有效。另一方面，如果(NFV)IaaS中虚拟网络和物理网络有着紧密结合的趋势，那么这种Ethernet Cloud上的交换技术很可能会成为一种选择。（作者：郑杰，UnitedStack有云）