Neutron社区每周记(1.9-1.13)|两种云交换技术

背景介绍

在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交换网络。
image2017-1-10 15_17_6图1 生成树网络

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

image2017-1-10 15_24_1图2 TRILL拓扑抽象

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

image2017-1-10 15_41_52图3 端到端转发路径

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

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

image2017-1-10 16_44_45
图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封装的帧格式:

import12121
图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转发流程,首先如下图所示:

image2017-1-10 17_59_44
图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有云)

订阅本站 打印文章

发表评论