码迷,mamicode.com
首页 > 其他好文 > 详细

uSID:SRv6新范式

时间:2019-07-18 23:43:43      阅读:137      评论:0      收藏:0      [点我收藏+]

标签:发展   href   缓存   就是   指令集   简单   app   linux   raft   

摘要:本文介绍最新的SRv6创新uSID(Micro Segment)。uSID兼容既有的SRv6框架,将极大地改变SRv6的设计、实现和部署方式,成为SRv6的新范式。

111111111111111

一、SRv6 101

Segment Routing(以下简称SR)指由思科院士Clarence Filsfils发明,并主要由IETF SPRING(Source Packet Routing In Networking)工作组进行标准化的新一代网络传送技术。SR基于源路由并且只在网络边缘维持状态,这使得SR非常适合于超大规模SDN部署,现已成为支持5G、物联网、多云、微服务发展的标准网络传送技术。

Clarence在发明SR的第一天,就为SR数据平面设计了两种实现方式(详见RFC 8402):一种是SR-MPLS,其重用了MPLS数据平面,可以在现有IP/MPLS网络上增量部署;另一种是SRv6,使用IPv6数据平面,基于IPv6路由扩展头进行扩展(SRv6报头格式详见IETF草案draft-ietf-6man-segment-routing-header-21),可以在现有IPv6网络上增量部署。

如果说SR-MPLS可以简单地认为是“下一代MPLS”的话,那么SRv6则是代表了全新的思考、设计、运营网络的方式?——网络即计算机(详见IETF草案draft-ietf-spring-srv6-network-programming-01)。下图是笔者经常使用的一张类比示意图:

222222222222
图1 网络即计算机-X86架构vs SRv6架构
图中左侧是大家熟悉的X86体系,程序最终是通过X86的CPU指令来操控服务器;右侧是SRv6体系,SDN通过SRv6 Segment来操控网络。
与X86 CPU指令是固定的不同,SRv6 Segment指令是可以任意扩充的(我们建议把新的Segment指令提交IETF进行标准化,但私有的Segment指令也是允许的),这赋予了SRv6极高的灵活性和极强的可扩展性。
目前多个IETF草案定义了多种SRv6 Segment指令,包括Underlay的Segment(转发、TE),也包括Overlay的Segment(L2/L3 ×××),还包括服务编程的Segment(服务链)以及用于5G移动核心网用户面的Segment等。可以看出,SRv6早已超出了Underlay的范畴,朝着全功能、网络级指令集演进。
还需要强调的是,SRv6实现了网络极简:控制平面是支持IPv6的IGP/BGP,转发平面则是纯IPv6。“简单即力量”,SRv6无疑在降低OPEX/CAPEX方面有着非常好的前景。
SRv6极简和可编程两大特性得到了业界的广泛认可。事实上,SRv6的生态系统发展的很快,如下图所示:

3333333333333333333
图2 SRv6生态系统
但SRv6在实际网络中的部署却很少,部署的业务也只是尽力而为的L3××× over SRv6,没有SRv6流量工程,更没有服务链这类高级功能。与之相对的是,随着Linux/VPP/智能网卡对SRv6的支持,SRv6在主机侧的应用和创新则是蓬勃发展(详见本文作者发表的Linux SRv6系列文章)。

SRv6在网络侧和主机侧呈现完全不同的情况,原因是什么?如何加速网络侧的SRv6部署?网络侧SRv6与主机侧SRv6如何整合/联动从而实现“网络即计算机”的愿景?

二、SRv6的阿喀琉斯之踵

前面谈到了SRv6在网络侧和主机侧呈现出完全不同的发展速度,根本原因是两者在查找和转发机制上存在根本的差异。

网络侧:ASIC/NPU收到数据包后,把数据包存在外置的内存中。ASIC/NPU读取固定长度的报头内容(一般是96~128字节),然后查找芯片本地/外部内存中的转发表,进行转发。如果报文头太长,无法在一个处理周期完成读取,则需要使用两个处理周期进行读取(Recycle),这将导致吞吐量下降一半。
主机侧:CPU读取完整的(一组)数据包,查找路由表/缓存,进行转发。因此报文头的长度对主机的吞吐不会有太大的影响,当然代价就是吞吐量远低于ASIC/NPU。
在SR-MPLS下,协议引入的开销较小,因此现有的大多数网络设备硬件均可以在一个处理周期内读取完SR报头信息,完成转发,意味着现有的硬件无须替换,只需升级软件即可支持SR-MPLS。这是SR-MPLS能迅速得到大量部署的技术基础之一。

但SRv6引入的协议开销远大于SR-MPLS[1] ,Segment所对应的操作也比SR-MPLS复杂,因此SRv6对网络设备提出了非常高的要求。如果按照目前的SRv6协议实现,要么需要替换掉绝大多数的网络设备,要么网络吞吐降低一半(Recycle),这对于很多用户而言是难以接受的。毕竟SRv6虽好,但如果其前期门槛是如此高的话,网络业界都会踌躇不前;缺乏网络侧SRv6(Underlay)的支持,主机侧(APP/Overlay)的SRv6创新也难以大规模部署,因为无法确保端到端的用户体验——这成为了SRv6的阿喀琉斯之踵。

下面我们通过一个例子来具体分析SR-MPLS和SRv6在协议开销、承载效率、MTU和对硬件芯片要求等方面的异同。假设净荷是IPv4报文,净荷长度是IMIX 440B,需要经过具有5个Segment的路径转发数据包。

44444444444444444444
表1 SR-MPLS vs SRv6
从上表可以看出,SRv6在网络可编程性和负载均衡方面有着巨大的优势,但要发挥其优势,需要迫切解决SRv6在协议开销、承载效率、MTU和对硬件要求方面的问题。这几个问题,其实本质上都是同一个问题:如何提高SRv6 Segment效率?

三、uSID原理是什么呢?

uSID:SRv6新范式

标签:发展   href   缓存   就是   指令集   简单   app   linux   raft   

原文地址:https://blog.51cto.com/14355923/2421518

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!