51学通信论坛2017新版

标题: 云数据中心网络虚拟化——大二层技术巡礼之L2 Fabric技术传输隧道 [打印本页]

作者: admin    时间: 2017-9-17 12:35
标题: 云数据中心网络虚拟化——大二层技术巡礼之L2 Fabric技术传输隧道
NVo3是L2 over IP/MPLS,利用IP网络的智能传输作为大二层虚拟交换机的背板走线,其好处是利用现有的设备即可完成隧道的传输。不过同时这也带来了一定的问题——IP网络的传输路径、服务质量难以控制,而且往往需要IP网络支持组播。尽管MPLS能解决这一问题,但是其部署过于复杂,开通一个租户的实例动辄要上月的时间,已经难以跟上公有云业务的发展。从NVo3工作组形成Geneve的思路来看,是希望IP Router能够感知到隧道承载的内部L2业务的需求以便提供匹配的传输管道,不过要改造现网的设备可绝非一件容易的事情。这几年以TRILL和SPB为代表的Switch Fabric技术则另起炉灶,走了一条非IP传输的路线,同样满足了大二层所需要的传输智能和可扩展性。

[attach]888[/attach]

1)TRILL
TRILL(Transparent Interconnection of Lots of Links,RFC 6325),是一种把三层的链路状态路由技术应用于二层流量传输的协议。TRILL为二层网络添加了基于IS-IS路由协议的控制平面,这种基于路由的寻址方式使得二层网络的转发变得更加智能,同时也使得二层网络摆脱了STP的束缚,获得了高效性和可扩展性。下面来看TRILL的报文格式。

[attach]889[/attach]

TRILL的封装在本质上是一种路由封装,它的寻址发生在网络层,因此不妨将TRILL比对着IP路由来看。TRILL设备被称作RB(Routing Bridge),可类比IP路由器。报头中,DA/SA为Egress/Ingress RB的MAC地址,在转发过程中逐跳重写。TRILL hdr可类比为IP header,其中Ingress/Egress Nickname唯一标识了Egress/Ingress RB的网络层地址,是TRILL寻址的依据,类比于源/目的IP地址,Hop字段则可类比于TTL用于环路避免。
TRILL控制平面的工作可概括为:首先在RB间建立邻居,绘制拓扑,然后生成RB Nickname路由表,同时允许通过ESADI协议维护虚拟机MAC地址和其所在RB的 Nickname间的映射关系。数据平面转发流程可概括为:收到虚拟机的原始帧后,Ingress RB为Original Frame封装TRILL报头,根据C-DA标记Egress Nickname,并根据Egress Nickname路由给下一跳的Transit RB,Transit RB继续逐跳路由到Egress RB,最后Egress RB剥掉TRILL报头,根据C-DA进行转发。TRILL域中,单播流量的路由依赖于RB Nickname路由表,组播流量的路由依赖于双向组播分发树MDT。下图给出了TRILL域中,终端A向终端C单播的完整通信流程,和IP的路由过程没什么区别,这里就不再做细致的说明了。
[attach]890[/attach]


[attach]891[/attach]

TRILL是独立于IP的网络层协议,或者说是一套庞大的协议集。除了上述的转发过程外,还规范了RB间点对点的PPP封装,Nickname的动态配置协议DNCP(类似于IP中的DHCP),Nickname的解析机制(类似于ARP),RB发现TRILL Hello,MAC地址分发协议ESADI,单播路由协议IS-IS,多路径负载均衡机制,组播分发树计算,路径MTU探测机制,等等。TRILL还考虑了RB间通过以太网交换机互联可能产生的种种问题,支持TRILL RB与以太网交换机的混合组网。
总之,作者很难用高度概括的语言把TRILL的技术细节都说清楚,下面列出一些作者在阅读TRILL RFC文档时注意到的技术点,可能比较琐碎,仅供读者参考。

标准的TRILL使用VLAN作为租户的标签,在租户数量上收到了很大的限制。因此,TRILL工作组在RFC 7172中提出了对TRILL中VLAN标签的扩展技术FGL(Fine-Grained Labelling),其封装格式如下图所示,Inner Label High Part和Inner Label Low Part中的后12位,合起来提供了16million的租户数量。至此,TRILL在技术上体系算是齐活儿了,既提供了足量的Tag,又有着智能、可扩展的backplane,通过TRILL的连接,整个以太网变成了一台无阻塞的巨型交换机,为实现数据中心内部的大二层提供了完整的解决方案。

[attach]892[/attach]

Cisco有一个私有技术,名为Fabric Path,除了实现TRILL的功能外还有很多自己的私货,如跨多拓扑FTAG、设备链路聚合vPC和基于会话的MAC地址学习等等,不过Fabric Path不支持与以太网交换机混合组网。TRILL的很多东西都是从Fabric Path那里copy来的,当然Cisco也乐于看到这种情况,毕竟技术上一脉相承,两者是站在同一条船上的。Cisco号称Fabric Path能够完美地兼容TRILL,不过看其它厂家的资料都说Fabric Path和TRILL还无法混合组网。
有人先成功,就有人要插一脚。瞅准了TRILL报头中增加了新字段,避免不了要设计新的芯片,对传统网络的兼容性不够好,SPB就趁机崛起了。
2)SPB
SPB(Shortest Path Bridging,802.1aq),常指SPBM,是前面提到的PBB(802.1ah)的小兄弟。两者的封装完全相同,都属于MACinMAC的隧道技术,两者主要区别在于PBB的转发是通过STP和自学习完成的,而SPB则为以太网引入了控制平面,通过IS-IS协议学习转发信息。SPB设计之处是为了解决运营商骨干PBB网络中STP收敛太慢、链路利用率低下的痼疾,恰好数据中心中内部也面临着同样的问题,市场不愿TRILL一家独大,便把SPB拿来与TRILL做了对头。

[attach]893[/attach]

上图最右边给出了SPBM的帧格式,其中B-SA和B-DA为外层MAC地址,结合B-VLAN作为传输网络中的转发依据,而I-SID是24位的业务标识,作为租户的标识,同样提供了16million的租户数量。除了SPBM以外,SPB还有另外一种模式SPBV。这种模式与802.1ad类似,是一种QinQ的VLAN标签栈技术,不属于隧道技术的范畴,下面主要对SPBM模式进行介绍。
SPB控制平面的工作可概括为:在BEB(Backbone Edge Bridge)间建立邻居,绘制拓扑,然后根据最短路径算法生成B-MAC转发表。数据平面上,入口BEB根据原始帧内部的目的MAC地址标记B-DA,并根据B-DA地址转发给下一跳的BCB(Backbone Core Bridge),BCB继续逐跳转发到出口BEB,最后出口BEB剥掉外层的封装,再根据内部目的MAC地址进行转发。
同TRILL一样,SPB也是独立于IP的一套完整的转发机制。不过相比于TRILL,SPB由于用到的是MAC寻址,不用设计新的网络层协议,因此相对来说要简单一些。虽然如此,SPB的内容也是很多的,下面列出一些作者在阅读SPB RFC文档时注意到的技术点,IEEE的标准文案作者没有权限查看,如果哪里写的不对请大家多多指教。


TRILL和SPB对比如下

隧道类型

控制平面

多路径ECMP

组播树

头端复制

多拓扑

TRILL

MACinNickname

IS-IS

基于Hash

全网一棵MDT

不支持

不支持

SPB

MACinMAC

IS-IS

基于ECT

SPT per BEB

支持

支持

MTU探测

网关一体化

租户数量

兼容性

OAM

场景

TRILL

支持

计划支持

通过FGL扩展为16 million

可与以太网交换机混合组网

目前不支持

数据中心内部

SPB

配合其他机制

不支持

I-SID作为标签,支持16million

天然的兼容性

可以配套其他机制

数据中心,运营商骨干网

从技术上来看,TRILL数据平面和控制平面兼修,更为完整也更有深度。而SPB则更为取巧,利用了现成的数据封装格式,只是添加了一些控制平面的逻辑。如果从市场反应来看,倒也不好说谁胜过了谁,毕竟SPB不需要对芯片做大型手术(可能要增加硬件对I-SID的支持),配套的协议也更成熟一些。Cisco肯定是TRILL这边挑大梁的,而SPB的阵营主力则是Avaya。Huawei和H3C则是两头堵,相对来说华为在TRILL上投入的更多一些,H3C可能在SPB上花的心思多一点。不过随着VxLAN的兴起,TRILL/SPB的势头也没有以前猛了,再算上DCI技术,三类隧道技术目前纠缠不清,市场究竟会做出什么样的选择呢?
作者简介:
张晨,北京邮电大学未来网络理论与应用实验室研究生
主要研究方向:SDN、虚拟化、数据中心
个人博客:www.sdnv.xyz
个人邮箱:zhangchen9211@126.com
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。




欢迎光临 51学通信论坛2017新版 (http://bbs.51xuetongxin.com/) Powered by Discuz! X3