摘要：本文介绍最新的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效率？
原文地址：https://blog.51cto.com/14355923/2421518