首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >ONOS构建开源Leaf-Spine Fabric

ONOS构建开源Leaf-Spine Fabric

作者头像
SDNLAB
发布2018-04-02 10:46:15
9240
发布2018-04-02 10:46:15
举报
文章被收录于专栏:SDNLABSDNLABSDNLAB

On.Lab ONOS项目组领导下的一个工作组近日发布了一个开源的leaf-spine fabric架构,以期进一步推动开放网络的发展。

开放网络基金会(ONF)首席架构师Saurav Das认为,这个全新的开源leaf-spine fabric架构也证明了OpenFlow是有效的。

这个项目是ONOS、ONF、Broadcom和Edgecore共同合作的一个项目。

该架构(leaf-spine fabric架构)使用的是白盒交换机上运行的OpenFlow 1.3,是开放计算项目(OCP)和白盒交换机生态系统共同的目标。目的是通过让用户能够混搭组件,如交换机硬件和网络操作系统,提供一个专有网络的替代品。

这个架构也需要云巨头们的支持,包括FaceBook、Google和LinkedIn。Das承认这个架构需要很长的时间才能获得企业的支持。

很多厂商在开源的项目(如开源的操作系统)上努力,认为整个网络的架构开源只是不太明显的一个进步,特别是leaf-spine架构如此出名的情况下。

这样做的原因之一是证明开放网络组建也可以构建出一个完整的架构,也就是说不依赖任何提供完整的硬件和软件组合的厂商。但是这个项目本身也只是软件定义网络(SDN)的试水项目。

Saurav Das说:“我们想使用最经典的SDN——基于OpenFlow的SDN,但是在过去几年中基于OpenFlow的SDN一直被许多挑战所限制,这些挑战来自于控制平面和数据平面。”

Das表示:在数据平面,OpenFlow 1.0在交换机芯片里的内存表使用上有所限制,这阻碍了其规模化的脚步。OpenFlow 1.3解决了这个问题,但是厂商并没有在该协议的发展商付出100%的支持。

Das说:“实际上,厂商们还是像OpenFlow 1.0那样只控制一个内存表。”使用博通公司的OpenFlow Data Plane Abstraction(OF-PDA)修正了这个问题,并且适用于几乎所有的交换机芯片。

Das表示:OpenFlow在控制平面上的问题是每个数据包都必须经过OpenFlow控制器,这是网络中多余的一步,大大影响了性能,但是这不是OpenFlow必备的需求。

ONOS的架构通过控制器发送控制平面数据包,此外,多个交换机之间可以共享多个控制器,如果一个控制器出现故障或者网络堵塞等造成的后果就会大大减轻。

这是ONOS团队想要开发该架构的另一个原因,他们认为该架构已经有了一个典型的用例:CORD项目(the Central Office Reimagined as a Data Center)。

CORD项目已经成为ONOS的前沿项目,该工作组甚至开发出了移动网络版本(M-CORD)和企业网络版本(E-CORD)。ONOS认为开源leaf-spine架构是CORD实现的良好的基础。

该架构通过一个接口应用2层网络进行通信,且接口间使用3层IP/MPLS增强容错能力。3层网络是基于开源路由堆栈Quagga实现的。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-07-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SDNLAB 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档