什么是G-SRv6？

SRv6报文头开销问题

SRv6是基于源路由理念而设计的新一代IP承载协议，其丰富的网络编程能力能够很好地满足新的网络服务需求。SRH（Segment Routing Header）扩展报文头是实现SRv6的关键扩展。在封装模式下，SRv6头节点会对报文封装上外层IPv6报文头和SRH扩展报文头，再进行转发，但这带来了一定的报文头开销，而且当SRv6 SID数目很多时，SRH扩展报文头的长度将进一步增长。由此可能产生如下问题。

有效传输效率下降

SRv6报文头开销过大带来的第一个问题是每个报文携带的载荷变小，有效传输效率下降。

如下图所示，Segment Routing（SR）主要应用于两种数据平面，分别形成SR-MPLS（Segment Routing with MPLS，基于MPLS的段路由）和SRv6（Segment Routing over IPv6，基于IPv6的段路由）。SRv6采用128 bit的IPv6地址作为SID，而SR-MPLS采用32 bit的MPLS标签作为SID，二者相比，SRv6的SID长度是SR-MPLS SID长度的4倍。

SR的两种数据平面

使用SRv6进行数据转发时，头节点会给报文封装外层IPv6报文头和SRH，其中SRH里携带Segment List。在大规模网络中，如果需要逐跳指定转发路径，则会引入较多的SRv6 SID。比如，在端到端严格显式路径转发场景下，使用的SRv6 SID数目可能超过5个，甚至达到10个。当使用10个SRv6 SID时，IPv6报文头包括如下3个部分：40 Byte的IPv6基本报文头、8 Byte的固定头部，以及10*16 Byte的Segment List，合计长度将达到40 + 8 + 10*16 = 208 Byte，具体如下图所示。

使用10个SRv6 SID时SRv6报文头开销

报文的总长度是有限的，过长的报文头会带来更多的传输开销，导致SRv6报文里IPv6载荷占比下降，传输效率降低。

现网老旧设备不兼容

SRv6报文头开销过大带来的第二个问题是SID栈太深，导致对现网设备的兼容性不好，而兼容现网设备也是任何新协议取得成功的关键。

支持SRv6需要对网络设备的软硬件进行升级。软件需要升级支持SRv6相关控制协议，比如IGP、BGP扩展支持SRv6等，这对现有网络设备的影响可控。硬件设备升级则存在比较大的挑战，面临着大量的投资。

SRv6赋予了IPv6地址更为丰富的含义，同时还引入了SRH和转发平面TLV（Type Length Value，类型长度值）封装等机制。这些机制带来了丰富的网络编程能力，但与此同时也对网络硬件设备的处理能力提出了更高的要求。通常，为了实现高性能的报文处理和转发，对SRH扩展头和TLV的处理都需要用硬件来实现。另外，为了支持更精细化的流量工程、SFC（Service Function Chaining，业务功能链）和IOAM（In-situ Operations，Administration，and Maintenance，随流操作管理和维护）等功能，网络硬件设备需要具备处理更深SRv6 SID栈的能力。

下图给出了SRv6对网络设备SID栈处理能力要求的初步评估。可以看到，支持L3VPN over SRv6 BE不需要引入SRH扩展报文头；支持L3VPN over SRv6 BE + TI-LFA需要具备大约4层左右SRv6 SID栈的处理能力；如果要支持L3VPN over SRv6 TE Policy，可能需要设备具备10层的SRv6 SID栈的处理能力；如果要支持基于SRv6的SFC和IOAM，则需要更高的SRv6 SID栈的处理能力。

SRv6对网络设备SID栈处理能力要求初步评估

随着SID数目增加，SID在SRv6报文中的位置可能超过硬件一次读取的深度，导致硬件进行二次读取，造成转发性能下降。更严重的是，SRv6报文处理对硬件要求高，现网部分老旧设备难以支持深度的报文头复制操作，必须升级硬件，这些问题也导致运营商现网无法平滑升级到SRv6。

MTU 超限风险较大

SRv6报文头开销过大带来的第三个问题就是报文头增大，可能导致MTU（Maximum Transmission Unit，最大传输单元）超限。

SRv6的一个独特优势就是支持TI-LFA和中间节点保护等新技术，这些技术使用SRv6显式路径作为故障后的修复路径，提升了IP网络故障保护成功率，是构建确定性IP网络的重要技术。但是SRv6保护常常会在原始报文里增加1～3个16 Byte（128 bit）的SID，强制报文沿着指定路径转发，这样就有可能导致SRv6的报文长度进一步增加，如下图所示。

SRv6报文长度变化示意图

通常只有IPv6源节点和目的节点才会解析IPv6扩展头部，所以只有IPv6源节点始发IPv6报文时才会进行IPv6 MTU分片，中间节点转发IPv6报文时不进行IPv6 MTU分片。当IPv6报文长度大于出接口IPv6 MTU时，设备会丢弃报文，并进行Path MTU发现。SRv6使用IPv6作为数据平面协议，MTU问题对SRv6的影响较大。

为什么说G-SRv6是更高效的SRv6？

G-SRv6是一种兼容SRv6的演进型方案，G-SRv6保留了原来SRv6具有的源路由、Native IPv6、可编程和简化协议等优点，还解决了业界对于SRv6报文头过长的担忧。G-SRv6作为一种更高效的SRv6，对于SRv6的广泛部署具有重要的促进意义。相比于SRv6，G-SRv6的技术价值可体现在以下几个方面。

提高传输效率

如下图所示，G-SRv6使用32 bit的压缩SID时，最多可减少75%的Segment List开销，显著地提高了网络传输效率。比如，传递相同大小的数据块，如果使用SRv6耗费10GB流量，使用G-SRv6可能仅需耗费7GB流量。在SD-WAN（Software Defined Wide Area Network，软件定义广域网）等对传输效率敏感的场景中，G-SRv6可以很好地帮助客户降低成本。

使用10个SRv6 SID时SRv6报文头开销

提升转发性能

SRv6转发的主要转发动作是读取Segments Left（SL）指向的Segment List中的活跃SID，并复制到IPv6报文头中的DA（Destination Address，目的地址）字段。使用G-SRv6时，由于整个Segment List变短，所以硬件读取Segment List中SID的深度变浅了，避免了硬件二次读取的发生。在华为某款设备使用10层SID的转发测试中，基于SRv6的转发速率为400Mpps，而基于G-SRv6的转发速率则可以达到620Mpps，实现了55%的转发性能提升。由于G-SRv6降低了对设备硬件能力的要求，所以现网部分老旧设备通过软件升级也可以支持G-SRv6，避免了硬件升级带来的额外成本，更有利于现网平滑升级。

防止MTU超限

G-SRv6场景，使用TI-LFA保护时可能新增1～3个32 bit的压缩SID，增加的长度比SRv6场景显著缩短，可以大大降低MTU超限的风险。

G-SID

在SRv6中，SID是一个128 bit的IPv6地址。其格式目前由5部分组成，如下图所示。

SRv6 SID格式示意图

在一个SRv6域中，SRv6 SID都是从同一个地址块中分配出来的，因此都具有相同的地址前缀（Common Prefix），比如2001:DB8:1:1::/64。同时，对于表征节点的End SID和表征链路的End.X SID来说，由于含义单一，通常Arguments字段设置为默认值0，Padding部分也为0。因此，在整个128 bit SRv6 SID中存在差异的部分，目前只有Node ID和Function ID两部分。

G-SRv6通过将这些冗余信息从Segment List中删除，仅携带变化的Node ID和Function ID，从而实现压缩。在转发的过程中，G-SRv6也不需要像SRv6那样将128 bit SID更新到IPv6目的地址字段，仅需将变化的Node ID与Function ID更新到IPv6的目的地址的对应部分，即可生成新的IPv6目的地址。这就是G-SRv6压缩的基本思想，具体如下图所示。在当前G-SRv6方案中，使用G-SID（Generalized SID，通用SID）直接指代压缩SID。G-SID 可以是一个压缩 SID，也可以是一个标准 SRv6 SID 或其他 SID，因此称为通用 SID。

G-SRv6压缩的基本思想

G-SID Container

为了兼容SRH，需要在SRH中按照128 bit对齐的方式来编排G-SID，即一个128 bit单元需要排放4个32 bit的G-SID，或8个16bit的G-SID。如果排不满，则需要使用0进行填充，对齐128 bit。因此G-SRv6方案定义了G-SID Container的概念，用于明确表示128 bit的单元。G-SID Container是一个128 bit的值，一个G-SID Container可以包含一个普通的SRv6 SID或多个G-SID，例如1～4个32 bit的G-SID，如下图所示。

G-SID Container

G-SRH

引入G-SID之后，多种类型的SID可以被编码到SRv6 SRH中，所以这个SRH我们称为G-SRH。G-SRH与SRH格式保持一致，但Segment List支持128 bit SRv6 SID和32 bit G-SID混合编码。如下图所示，原本的128 bit SID变为现在的G-SID Container，G-SID Container可以承载一个SRv6 SID或多个G-SID。

G-SRH格式

当128 bit SRv6 SID和32 bit G-SID混编在G-SRH中时，其编码示例如下图所示。

G-SRv6 Segment List编码

在G-SRv6中，一段路径可以由SRv6压缩子路径和SRv6子路径组成，这两段子路径由各自的SID来编码体现：

• SRv6压缩子路径：由支持压缩的一系列G-SID编码体现，其中第一个G-SID是一个128 bit支持压缩的SRv6 SID，后续是多个32 bit的压缩SID。第一个G-SID携带包含Common Prefix的完整128 bit信息，用于构建完整可路由SID。
• SRv6子路径：由128 bit的G-SID，也即SRv6 SID编码。

所有G-SID在Segment List中按照128 bit编排，因此如果G-SID无法排满128 bit，则需补齐对应的Padding。

COC Flavor

当前SRv6是将SL指针指向的活跃SID更新到IPv6报文头的目的地址字段。但将G-SID编码到G-SRH中之后，每次更新的SID不一定是128 bit SID，还可能是32 bit G-SID，因而还需要定义32 bit G-SID更新的动作。

为指示处理SRv6压缩SID，G-SRv6定义了一种COC Flavor（特征）。当节点处理携带COC Flavor的SID时，表示需要将Segment List中下一个32 bit的G-SID更新到目的地址字段。

一个G-SID Container可能包含多个G-SID，为了定位下一个G-SID在G-SID Container中的具体位置，还需要新增SI（SID Index），SI在G-SRv6报文头目的地址字段中Arguments的最低2位。为了方便硬件实现和未来扩展，可以使用128 bit的SRv6 SID（没有Padding），使得SI的位置在整个128 bit的最低2位，如下图所示。

SI指针位置

在生成压缩SID时，需预留空间给SI，其初始值为0。在转发的过程中，只有当目的地址字段的SID为可压缩SID时，目的地址中的SI字段才有意义。此时，SL指示了G-SRH中的活跃的G-SID Container，而SI指示了G-SID在该G-SID Container中的位置。按照Segment List的倒序排列规则（即Segment List[0]为最后一跳，Segment List[n]为第一跳），G-SID的排列顺序也是倒序的，即SI = 3时，定位到G-SID Container的最低32 bit值；SI = 0时，定位到G-SID Container的最高32 bit值。

G-SRv6方案更新目的地址的思想为：通过携带COC Flavor的SID指示更新下一个位于G-SRH的32 bit G-SID到IPv6报文头的目的地址进行转发。G-SRv6压缩处理流程由COC Flavor触发，操作也局限在携带COC Flavor的SID之内，对已有SID以及SRH的处理无影响。

以纯压缩路径搭配128 bit的VPN SID为例，G-SRH的Segment List编码与G-SID更新示例如下图所示。

结合SRv6 SID编码规则，压缩路径在Segment List中的编码规则为：

1. SRv6压缩路径的开始由一个128 bit的携带COC Flavor的SID指示，该COC Flavor SID携带了完整的SID信息，包含Common Prefix等信息，可用于与后续G-SID恢复出完整的下一个SID。
2. 压缩路径中间的G-SID均为携带COC Flavor的G-SID，指示下一个G-SID是32 bit G-SID。
3. 压缩路径的最后一个G-SID不能携带COC Flavor。其与目的地址中其他部分组成的完整SID将被节点按照128 bit SRv6 SID处理：更新下一个128 bit的SRv6 SID到IPv6目的地址字段，从而实现从32 bit G-SID到普通SRv6 SID的变化。

这种编码规则支持普通SRv6 SID与压缩SID混编，从而支持从SRv6网络存量演进、平滑升级到G-SRv6网络。

G-SRH的Segment List编码与G-SID更新示例

报文转发流程

以穿越压缩与非压缩的SRv6域为例，说明G-SRv6方案的转发过程。

如下图所示，假设报文需要从节点N0转发至节点N10，仅节点N5不支持压缩，因此2001:DB8:A1::5:1将被完整的编码在Segment List中。节点N10为End.DT4类型的VPN SID，2001:DB8:A:10:10::也作为128 bit的SID被完整编码到Segment List中。因此，节点N1、N2、N3、N6、N7、N8对应的SID中均携带COC Flavor，指示下一个SID为压缩SID。编码之后的Segment List如下图所示。

混编转发示意图

转发流程描述如下：

1. 节点N1收到数据包时，目的地址2001:DB8:A:1:1::在本地SID表中，N1命中到本地发布的携带COC Flavor的End.X SID，此时SRH中SL = 5，SI = 0，因此SL减1，SI = 3，指向2:1，将G-SID 2:1更新到IPv6目的地址中，转发到下一个节点N2。此时目的地址为2001:DB8:A:2:1::3。
2. 节点N2收到数据包时，目的地址2001:DB8:A:2:1::3在本地SID表中，N2命中到本地发布的携带COC Flavor的End.X SID，此时SL = 4，由于SI为3，所以N2将SI减1，将G-SRH中的下一个G-SID 3:1更新到目的地址中，转发到下一个节点。此时目的地址为2001:DB8:A:3:1::2。
3. 节点N3的操作同节点N2，将IPv6目的地址更新为2001:DB8:A:4:2::1并转发到节点N4。
4. 节点N4收到数据包时，目的地址2001:DB8:A:4:2::1在本地SID表中，N4命中到本地发布的End.X SID，因此，SL - 1 = 3，将2001:DB8:A1::5:1复制到目的地址中进行转发。
5. 节点N5是一个普通SRv6节点，将执行SRv6转发动作，更新IPv6目的地址为2001:DB8:A:6:1::，转发到下一个节点。
6. 节点N6收到数据包时，目的地址2001:DB8:A:6:1::在本地SID表中，N6命中到本地发布的COC Flavor End.X SID，此时SRH中SL = 2，SI = 0，所以SL减1，SI = 3，指向7:1，将G-SID 7:1更新到目的地址中，转发到下一个节点。此时目的地址为2001:DB8:A:7:1::3。
7. 同理，节点N7、N8收到数据包时，处理COC Flavor SID，更新目的地址，转发数据包。
8. 节点N9收到数据包之后，步骤同节点N4，由于目的地址中SID在本地SID表中，N9命中到本地发布的End.X SID，无COC Flavor，所以N9将SL减1，并将SL指向的VPN SID复制到目的地址中转发到节点N10。
9. 节点N10按照VPN SID的指令进行后续处理。