下载掌阅APP，畅读海量书库
立即打开
截至2022年底，得益于兼容IPv6的优势，SRv6已经快速完成了上百个商用局点的部署，发展势头迅猛。但在SRv6实际部署中，头节点会先对报文封装外层IPv6基本报文头和SRH（使用多个SID时），再进行转发 [2,3] ，这样的封装带来了一定的报文头开销。如果SRv6 SID数量很大，SRH的长度将进一步增加，导致有效传输效率下降。
如图2-1所示，首先，在封装（Encap）模式中，40 Byte的IPv6基本报文头已经相当于10跳MPLS标签；其次，SRv6采用16 Byte的IPv6地址作为SID，而SR-MPLS采用4 Byte的MPLS标签作为SID，相比之下，SRv6的SID长度是SR-MPLS SID长度的4倍。
图2-1 SR-MPLS与SRv6
尤其在大规模网络中，如果需要逐跳指定转发路径，就会引入较多的SRv6 SID，从而导致SRv6报文头显著增大。比如，在端到端的严格显式路径转发场景中，使用的SRv6 SID数量可能超过5个，甚至达到10个。当使用10个SRv6 SID时，IPv6报文头的总长度将达到208 Byte（40 Byte的IPv6基本报文头、8 Byte的固定头部，以及10×16 Byte的Segment List，合计长度为40+8+10×16=208 Byte），如图2-2所示。
图2-2 使用10个SRv6 SID时的SRv6报文头
对于视频业务已经发展起来的网络，其报文一般比较长，因此报文头开销对传输效率的影响相对有限。但在视频业务未发展起来的网络中，大多数报文比较短，过长的报文头会导致载荷占比显著下降，降低传输效率。
为了提升SRv6的传输效率，在2019年左右，业界提出了多种方案，如G-SRv6（Generalized SRv6，通用SRv6）、uSID（Micro SID，微型SID）、Unified SID（统一SID）、vSID（variable length SID，可变长度SID）和CRH（Compact Routing Header，精简路由报文头）。面对众多的技术方案，业界展开了激烈的讨论。为了解决这个问题，完成方案收敛和标准化，IETF SPRING工作组临时设立了一个SRv6传输效率提升方案设计小组，专门讨论SRv6传输效率提升的需求，并分析当前的方案。设计组由来自中国移动、中国电信、华为、思科（Cisco）、瞻博网络（Juniper）、诺基亚（Nokia）、中兴通讯等公司的专家组成。经过一年多的讨论，设计组达成共识，形成了关于SRv6传输效率提升需求的IETF工作组草案draft-ietf-spring-compression-requirement [20] ，以及方案比较分析等工作组草案draft-ietf-spring-compression-analysis [21] 。
IETF草案draft-ietf-spring-compression-requirement详细描述了SRv6传输效率提升方案需要满足的需求，这些需求均不依赖任何方案，以确保在方案的需求满足度评估中公平对待所有方案。基于以上需求，草案draft-ietf-spring-compression-analysis详细分析了所有方案对需求的满足度。
由于G-SRv6与uSID在技术原理上十分相似，且能在一个SRH中共用，因此两个方案融合成一个方案——C-SID（Compressed-SID，压缩SID）。最终，经过接近两年的激烈讨论，各个方案的竞争逐渐收敛，IETF SPRING工作组终于形成共识，将C-SID方案接收为工作组草案draft-ietf-spring-srv6-srh-compression [4] 。该草案目前已经进入RFC发布环节，即将在2025年5月发布成RFC。
IETF草案draft-ietf-spring-srv6-srh-compression定义了C-SID的基本原理，并通过定义一些新的Behavior和Flavor来实现SRv6传输效率的提升 [4] 。整体上看，C-SID是一种完全兼容SRv6架构的传输效率提升方案，主要定义了3类Flavor：REPLACE-C-SID Flavor、NEXT-C-SID Flavor，以及两者的组合NEXT&REPLACE-C-SID Flavor。其中，REPLACE-C-SID Flavor在业界又被称为G-SRv6，NEXT-C-SID Flavor在业界又被称为uSID。这两种Flavor的技术原理十分相似，都是通过删除SID的冗余信息来减少开销，差别主要在于C-SID的编排和更新方式不同。但是，这两种Flavor都只能在特定的条件下提供最佳传输效率，NEXT&REPLACE-C-SID Flavor则可以规避二者的缺点，得到最佳的传输效率。
后来，出于标准化节奏的考虑，NEXT&REPLACE-C-SID Flavor从工作组草案中拆出，转移到个人草案中继续标准化。目前，华为等厂商设备已经实现包含NEXT&REPLACE-C-SID在内的完整C-SID方案，可以满足所有业务场景和多厂商互通的需求，且在任何条件下均可提供最佳的传输效率。下面将详细介绍C-SID方案的技术细节。
一般情况下，一个网络域中使用的SRv6 SID均从同一个用于SRv6部署的地址块中分配而来，因此这些SID都具有公共前缀（Common Prefix），在标准文稿中，这部分前缀被称为Locator Block。如果IPv6报文头的目的地址中的SID已经携带了公共前缀，那么SRH中的SID无须携带多个重复的公共前缀，从而减少报文开销。此外，如果多个SID的后半部分（如Arguments或Padding）均为0，那么会带来大量的冗余信息，减少这部分信息也可以减少报文开销。因此，在地址更新时，只需要更新差异部分，即可恢复出可用的SID作为目的地址，进而指导转发。完整SID的差异部分称为C-SID。完整SID和C-SID的关系如图2-3所示。
图2-3 完整SID和C-SID的关系
根据IETF草案draft-ietf-spring-srv6-srh-compression的定义，C-SID由对应SID的Node ID和Function ID部分构成 [4] ，有16 bit和32 bit两种长度。从硬件处理性能、后向兼容和可扩展性方面综合考虑，C-SID的理想长度是32 bit。但在中小规模网络中，也可以使用16 bit C-SID来减少开销。
一个C-SID可以携带不同的Flavor，比如REPLACE-C-SID、NEXT-C-SID和NEXT&REPLACE-C-SID。不同的Flavor对应的编码格式和处理方式略有不同，其差异在于C-SID在C-SID Container（容器）中的编码。
C-SID Container是一个128 bit的字段，可用于携带包含一个或者多个C-SID的信息。Flavor不同，对应的C-SID Container的编排方式可能就不同。比如在NEXT-C-SID Flavor中，每个C-SID Container将承载一个Locator Block和若干个C-SID。而在REPLACE-C-SID Flavor的定义中，一个C-SID Container可以携带一个完整的SID或者最多携带4个32 bit的C-SID或8个16 bit的C-SID。对于携带多个C-SID的C-SID Container，若C-SID未填满C-SID Container，通过补充0对齐128 bit。而NEXT&REPLACE-C-SID Flavor的C-SID Container编码规则是上述两种Flavor的结合：第一个C-SID Container沿用NEXT-C-SID Flavor的规则（即一个Locator Block后跟随多个C-SID），后续的C-SID Container沿用REPLACE-C-SID Flavor的规则（即整个C-SID Container均为C-SID，不携带Locator Block）。3种Flavor的C-SID Container编码格式如图2-4所示。
图2-4 3种Flavor的C-SID Container编码格式
说明
图2-4中Locator Block的长度为64 bit。
图2-4中假设C-SID均刚好填满C-SID Container。实际上存在C-SID Container未填满的情况，可使用Padding补充。
综上所述，一个C-SID Container可以有4种格式，如图2-5所示。
● 一个C-SID Container中包含多个C-SID，比如4个32 bit的C-SID。以32 bit的C-SID为例，如图2-5（a）和图2-5（b）所示。图2-5（a）和图2-5（b）为REPLACE-C-SID Flavor C-SID Container格式，也是NEXT&REPLACE-C-SID第一个C-SID Container之后的C-SID Container格式。
● 一个C-SID Container中包含一个Locator Block和若干C-SID，如图2-5（c）和图2-5（d）所示。图2-5（c）和图2-5（d）为NEXT-C-SID Flavor C-SID Container的格式，也是NEXT&REPLACE-C-SID Flavor第一个C-SID Container的格式。其中，图2-5（d）是普通SRv6 SID的编码格式，也是REPLACE-C-SID Flavor第一个C-SID Container的格式。
图2-5 携带32 bit C-SID的C-SID Container
简言之，SRv6传输效率提升的实现过程就是将包含多个C-SID的Segment List信息按照对应Flavor的编排方式写入C-SID Container。在转发过程中，节点根据SID对应的Flavor编码规则提取C-SID，还原出原始的SID，然后进行转发。
C-SID的编排和对应C-SID的更新方式由Flavor具体定义，简要介绍如下。
● REPLACE-C-SID Flavor主要将C-SID按顺序放在C-SID Container中，并通过在IPv6 DA（Destination Address，目的地址）中增加指针SI（SID Index，SID索引）来明确C-SID在对应C-SID Container中的相对位置。节点在处理这类SID时，根据SL与SI将对应的C-SID替换成IPv6 DA中的C-SID来实现更新。
● NEXT-C-SID Flavor主要在每个C-SID Container中都携带一个Locator Block和一系列C-SID。节点在处理这类SID时，通过将当前的C-SID弹出，并将后续的C-SID往前移位来更新IPv6 DA。该处理方法与MPLS标签栈弹出类似，随着报文转发，C-SID不断弹出。若SRH中没有携带完整的C-SID Container列表，就会在转发结束后，丢失完整的Segment List信息。
● NEXT&REPLACE-C-SID Flavor则结合了REPLACE-C-SID Flavor和NEXT-C-SID Flavor的处理方法。如果IPv6 DA的C-SID Container里存在多个C-SID，则执行NEXT-C-SID的处理动作，将C-SID弹出，后续C-SID左移组成新的IPv6 DA。当IPv6 DA中的C-SID更新至最后一个（此C-SID是C-SID Container的最后一个C-SID）时，说明该C-SID Container已经全部处理完毕，就进入REPLACE-C-SID的处理逻辑，从后续的C-SID Container中取出C-SID替换IPv6 DA中的C-SID。
下面将具体介绍这3种Flavor的处理细节，读者可以阅读IETF草案 [4] 获取更多信息。
C-SID的典型长度是32 bit或16 bit。当C-SID长度为32 bit时，可以包含16 bit Node ID和16 bit Function ID，或者其他长度的Node ID和Function ID的组合。因为32 bit C-SID可以提供较为充足的编码空间，所以能够方便地支持大规模网络的SRv6部署。
但当C-SID长度为16 bit时，无论如何分配，同时编码Node ID和Function ID都存在可扩展性问题。例如，16 bit C-SID中的8 bit用于Node ID，8 bit用于Function ID，这样仅能支持256个节点的编码和每个节点256个Function的编码，无法支持大规模网络的SRv6部署。
为了解决16 bit C-SID的可扩展性问题，可以将一个16 bit C-SID仅编码为Node ID或Function ID，而非同时编码两种信息。这就意味着Node ID和Function ID都具有16 bit的编码空间，但是为了避免全局可路由的Node ID和只有本地语义的Function ID的数值冲突，需要对16 bit C-SID的空间进行划分，于是引入了GIB（Global Identifiers Block，全局标识符块）和LIB（Local Identifiers Block，本地标识符块）：从GIB里面分配的C-SID为可路由的C-SID，可用于分配Node ID；从LIB中分配的C-SID仅本地有效，可用于分配Function ID。
因为有了GIB和LIB的空间划分，所以在采用16 bit C-SID传输效率提升方案时，还需要全网规划这两个空间。这个划分方法是灵活的，可根据现网具体情况进行划分，比如，可以将16 bit的前4 bit用作划分单元，将16 bit空间划分为16等份12 bit的空间，如图2-6所示。GIB可以占据前10份12 bit空间（0x0000～0x9FFF），而LIB占用后6份12 bit空间（0xA000～0xFFFF）。
图2-6 GIB和LIB的空间划分
需要注意的是，从LIB中分配的C-SID不具备全局路由能力，因此需要跨越多个节点到达某一个节点时，必须使用对应该节点的从GIB中分配的C-SID。如果还要指向该节点的特定Function，则必须使用对应该节点的、从GIB中分配的C-SID，以及对应Function的、从LIB中分配的C-SID的组合（即2个16 bit C-SID的组合）。
在RFC 8986中定义了End、End.X等多种SID的Behavior [2] 。这些Behavior均可以与REPLACE-C-SID、NEXT-C-SID和NEXT&REPLACE-C-SID Flavor相结合，支持对应的传输效率提升方法。
此外，其他类型的SRv6 SID的SID Behavior，如SFC相关的SRv6 SID的Behavior也可以与以上的3种Flavor结合，组成适用于SRv6传输效率提升的SID [22] 。