uSID来源于2019年7月8日提交的IETF草案draft-filsfils-spring-srv6-net-pgm-extension-uSID-00。这个草案对现有SRv6框架做了扩展，定义了新的Segment类型uSID（Micro Segment）。uSID可以彻底解决上述的协议开销、承载效率、MTU和对硬件要求高方面的问题。uSID将极大加速SRv6在网络侧的部署，并成为SRv6新范式。一个典型的uSID如下图所示。可见一个128bit的IPv6地址被分为8份，第1份（16bit）用于表示uSID块信息，另外7份每份用于表示一个Segment信息（uSID），这意味着SRv6 Segment效率提高了7倍！

图片来自网络

uSID相关概念如下：

uSID承载器(uSID Carrier)：128bit的SRv6 Segment，其格式为<活动uSID><下一个uSID>…<最后一个uSID><承载器结束标志><承载器结束标志>

uSID：16bit的Segment ID。也可采用其他长度；

uSID块(uSID Block)：uSID地址块；

活动uSID(Active uSID)：在uSID地址块后的第一个uSID；

下一个uSID(Next uSID)：在活动uSID之后的uSID；

最后一个uSID(Last uSID)：在第一个承载器结束标志前的uSID。

承载器结束标志(End-of-Carrier )：16进制值“0000”作为承载器结束标志。承载器内所有空闲的位置都需要用承载器结束标志来填充，因此承载器结束标志可以在一个承载器内出现多次。

uSID的设计在一定程度上借鉴了MPLS封装，但保持了对IP路由最长匹配机制的支持。如果将uSID承载器中每个16bits的uSID类比于一个32 bits的MPLS标签，则可以将整个uSID承载器中除了uSID块（前16个bits）以外的部分看做最多7个MPLS标签。uSID相对于MPLS标签的一个优化是每个uSID只包含Segment信息（即MPLS 标签中的20bits的部分），而去除了3 bits的TC(Traffic Class，之前叫EXP)、1bit的栈底标志和8bits的TTL——TC和TTL信息在IPv6报头字段体现，栈底标志由承载器结束标志表示。

图片来自网络

uSID相关操作

目前草案里只定义了一个操作uN，功能类似于SRv6标准的End操作。假设uSID块=FC00::/16(ULA地址，详见RFC 4193),节点N对应的uSID=0N00, 则在节点N上uN操作会与以下两条FIB条目相关联：

FC00:0N00/32绑定至“Shift & Forward（位移 & 转发）”伪代码。

FC00:0N00:0000/48绑定至End操作（弹出uSID承载器，处理下一SRv6 Segment）。

其中“Shift & Forward”伪代码如下：

把 uSID承载器中第32至127位的内容拷贝至第16-111位（即二进制左移16位，注意从0开始编号）。

把第112至127位的内容置为 16进制的“0000”（承载器结束标志）；

在FIB中查找更新后的目的地址（即uSID块和活动uSID组合起来的前缀）；

按照匹配的条目转发数据包。

uN操作中设备转发表项设计的巧妙构思，可以将IP路由最长匹配的优势发挥得淋漓尽致。设备利用一长一短两条FIB条目进行最长匹配查找，若匹配到长条目（uSID块+活动uSID+承载器结束标志），说明被处理的uSID是uSID承载器中的最后一个Segment，从而执行uSID承载器的弹出；若匹配到短条目（uSID块+活动uSID，下一个uSID不是承载器结束标志），说明被处理的uSID不是整个uSID承载器的最后一个Segment，则执行“Shift & Forward”操作。uSID对栈底标志的处理，更接近于MPLS，而不是常规的SRv6使用的Segment Left指针。

uSID在转发时则完全继承了SRv6的特点。不同uSID之间完全是标准的IPv6路由，遵循IP路由最长匹配原则。因此，用户完全可以只通告uSID块的汇总路由(甚至只通告默认路由)给末端接入网络，而无须像MPLS一样一定要建立端到端LSP才能转发。这无疑将极大简化了全网的路由设计和减少 了FIB条目。需要注意的是，uSID操作形成的Segment是固定可预知的(uSID块+活动uSID)，无须建立和维护复杂的映射表，这使得硬件设备实现起来非常简单。由此可见，uSID操作是非常简单的，现有的硬件芯片完全可以完成；并且由于uSID将SRv6 Segment效率提高了7倍，因此硬件芯片只需要读取有限的包长就可以完成转发。

uSID转发流程示例

以下基于IETF草案draft-filsfils-spring-srv6-net-pgm-extension-uSID-00中的示例，介绍uSID转发流程。本示例将介绍如何基于uSID实现低延迟IPv4 L3VPN业务，示例拓扑如下图所示：

图片来自网络

假设uSID块=FC00::/16,节点N对应的uSID=0N00。图中节点1-节点8位于同一IGP域中，节点1和节点8是SRv6 PE节点。此IGP域中所有链路的IGP度量相等，链路3->4->5->6->7具有更低的延迟。节点1/节点3/节点5/节点6/节点7/节点8均支持uSID，且都在IGP中通告FC00:0N00::/32路由。图中节点X和节点Y是IPv4 CE节点，不属于SRv6域。现在要基于uSID为IPv4 数据包(X,Y)提供低延迟的L3VPN业务。

转发流程如下：

PE节点1把IPv4数据包(X,Y)封装入IPv6报头内，并转发给节点3。此IPv6报头的目的地址=FC00:0300:0500:0700::，SRH= (B:8:D0::; SL=1; NH=4)。其中FC00:0300:0500:0700::是承载器，用于编码3->4->5->6->7的低延迟路径（注意不需要把路径中的每一跳进行编码，而只需要对航路点进行编码，以充分发挥IP路由ECMP能力）；B:8:D0::是表示End.DT4操作（Per-VRF IPv4 VPN）的常规SRv6 Segment。此时完整的数据包格式是：(A1::, FC00:0300:0500:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)。由于节点3通告了FC00:0300::/32路由，因此数据包将根据IGP路由转发给节点3。节点2在从节点1去往节点3的IGP最短路径上，因此节点2会收到PE节点1发出的上述数据包。由于目的地址FC00:0300:0500:0700::不是节点2上的地址，因此根据RFC 8200的规定，节点2不处理扩展头，而只是简单地查自身路由表把数据包发给节点3。节点3收到数据包(A1::, FC00:0300:0500:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)，FC00:0300::/32在本地SID表中的uN操作匹配，节点3执行“Shift & Forward”操作：把目的地址更新为FC00:0500:0700::；查找路由表，匹配到最长条目FC00:0500::/32，于是把数据包转发给节点5。此时完整的数据包格式是：(A1::, FC00:0500:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)节点4在从节点3去往节点5的IGP最短路径上。节点4的处理与节点2类似，只是简单地按照IGP路由把数据包转发至节点5。节点5收到数据包(A1::, FC00:0500:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)，FC00:0500::/32在本地SID表中的uN操作匹配，节点5执行“Shift & Forward”操作：把目的地址更新为FC00:0700::；查找路由表，匹配到最长条目FC00:0700::/32，于是把数据包转发给节点7。此时完整的数据包格式是：(A1::, FC00:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)节点6在从节点5去往节点7的IGP最短路径上。节点6的处理与节点2类似，只是简单地按照IGP路由把数据包转发至节点7。节点7收到数据包(A1::, FC00:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)，FC00:0700:0000::/48与本地SID表中的uN操作匹配（注意由于IP路由最长匹配的特性，此时不是匹配FC00:0700::/32这个条目），因此节点7执行支持PSP[4]和USD[5]的End操作 ：将SL递减1，SL=0，把IPv6报头的目的地址更新为Segment列表[0]，即B:8:D0::；由于此时SL=0，节点7执行PSP操作，把SRH弹出；根据新的目的地址B:8:D0::查找路由表，把数据包沿最短路径转发至节点8。此时完整的数据包格式是：(A1::, B:8:D0::)(X, Y)。节点8收到数据包(A1::, B:8:D0::)(X, Y)，执行End.DT4操作：去掉外层的IPv6报头，在相应的VRF表中查找VPN前缀路由并转发。

uSID优势--互操作性

uSID完全遵循srv6-network-programming框架，并非是重新发明一套体系。事实上，uSID只是一系列符合srv6-network-programming框架的新指令。正是由于uSID本质上只是一个新的SRv6 Segment，因此uSID可以与常规的SRv6 Segment互操作，也可以与纯IPv6节点(Non-SR)互操作。例如在第3.3节中，PE节点1生成数据包(A1::, FC00:0300:0500:0700::)(B:8:D0::; SL=1; NH=4)(X, Y)，此数据包使用uSID编码路径，沿途经过纯IPv6节点（节点2/节点4/节点6），最后在节点8基于常规SRv6 Segment完成标准的End.DT4操作。uSID与常规SRv6 Segment、纯IPv6转发的互操作能力使用户可以在现网增量部署uSID，无需对现有的硬件做全面的替换；利用IPv6提供的可达性，轻松实现uSID的跨域部署。典型的互操作场景如下图所示：

图片来自网络

由于现网部署SRv6的案例很少，因此如果业界能迅速地接纳并部署uSID，那么未来很可能是第三种互操作场景成为主流。相信未来绝大多数的SRv6部署应该是基于uSID的，uSID将是SRv6新范式。产业链的聚合有利于加速SRv6发展。当uSID解锁了Underlay的SRv6能力后，更多的应用场景将被激活，例如基于SRv6/uSID打造Underlay和Overlay一体的智能网络平台。未来uSID发展空间巨大，大有可为。诚然，uSID还刚起步，目前业界厂商也只有演示代码实现，尚未正式支持。还需要业界各方一起努力，不断完善uSID相关操作，打造强健的生态系统，积极推动现网部署。（部分内容来源：SDNLAB）