SRv6主要核心是通过128位的IPv6地址的编排来实现网络的可编程。但是在实际的报文结构中可以看到IPv6的报文是40byte，如果有10层的Segment list，那么SRH的长度就是168byte，总计208byte。

出自《IPv6+系列电子书：G-SRv6》

IPv6载荷中携带的是数据报，那么实际传输的有效数据也变得更少，这也就会导致传输速率的下降。在不同的场景下SID的数量不同会导致SRH的报文长度越长。同时在SRH的演进来看，SID过多也会要求设备所读取的栈更深，也就要求对现网设备进行升级，需要投入大量的成本。同时也会导致现网老旧设备不兼容，没有办法读取更深层的栈，可能只能读取3-4层的Segment list。而SRv6不会像MPLS那样读取一个弹出一个，它会一直保存所有的Segment list，这样也就实现了路径可回溯。最后一个问题就是SID过长可能也会导致MTU的超限。

出自《IPv6+系列电子书：G-SRv6》

IETF也基于此提出了对SID压缩的需求，首先考虑的是压缩的效率，可拓展性等。由于每个SID长度是128位，因此要保证压缩的长度是8的倍数，以便和128位对齐。另外压缩SID也要基于原生IPv6路由，基于IP的可达性。还要考虑现网的地址规划，从而保证压缩方案的可拓展性。最后一点是与128位的SRv6 SID兼容，可能会有不能被压缩的地址，因此必须要实现动态编排规划。

出自《IPv6+系列电子书：G-SRv6》

针对压缩方案的研究，国内外也提出了很多的方案，而IETF任务组也对目前的已有的方案进行讨论。其中已有的方案中主要分为两类，一类是基于提取公共的路由前缀实现压缩；另一类就基于SID和IPv6地址之间的映射关系生成映射表实现压缩。

出自《IPv6+系列电子书：G-SRv6》

本篇主要介绍G-SRv6，在128位的Segment list中，前面介绍过分为三个部分分别是Locator，Function和Args，再进行细分Locator还可以分为Block和Node ID。而实际上Block在同一场景下都是一样的，那么变化的部分就只有Node ID和Function部分，Args是可选的。因此G-SRv6就只提取Node ID和Function ID，提取这两个部分压缩为32位的GSID。但是原本Segment list是128位，那么就要对齐，所以引入了G-SID Container（GSID容器）概念。这个GSID容器是128位，每一个GSID容器中可以放4个压缩的32位GSID。

出自《IPv6+系列电子书：G-SRv6》

这个时候G-SRH就变成了下图：

出自《IPv6+系列电子书：G-SRv6》

原本编排的Segment list全部改为GSID容器。那么当既存在128位的正常SID和32位的压缩SID的情况下，在SRv6的压缩子路径就是由一个128位可压缩的SID和128位的GSID容器组成。通过公共前缀进行拼接组成完整的128位地址放在IPv6报文的目的地址中。

出自《IPv6+系列电子书：G-SRv6》

因为在一个路径中可能既有压缩SID，也可能存在正常SID。

出自《IPv6+系列电子书：G-SRv6》

那么在编排过程中，G-SRv6又引入了COC Flavor的特征。这个特征主要用来表示下一个SID的类型，如果是压缩的GSID container，当前SID就携带COC Flavor，如果是普通SID，就不携带COC Flavor。通过COC Flavor来指导如何对下一个SID进行处理，同时还引入了SI的标识符。在原本的SRH中只有SL，SL是用来指导当前读取的是哪一个128位的SID。但是压缩后它同样指示的就是128位的SID,可能是普通SID也有可能是压缩的GSID container。

出自《IPv6+系列电子书：G-SRv6》

那么压缩后的GSID就由SL和SI同时控制下一个读取的哪一个SID。如果携带COC Flavor，证明这个SID是压缩SID，这个时候要判断SI的值是否大于0。如果是大于零则说明正在读取的是GSID，因此SL的值不变，而SI的值要减1， 如果SI已经为0，就要去读取下一个压缩的SID，SL减1，而SI的值再重置为3。如果不是携带COC Flavor的，证明就是普通SID，那么直接SL减1。GSRv6的编排过程的伪代码如下：

if（true）{

if（SI>0）{

 SI--;

  }else{

SL--;SI=3

}

}else{

SL--;

}

在这里假设两个GSRv6转发的场景，纯压缩的场景和混编场景。

纯压缩场景：

出自《IPv6+系列电子书：G-SRv6》

转发流程描述如下：

1. 节点 N0 封装好数据包后，将数据包发送给下一跳节点 N1，此时 SRH 中 SL = 3，SI = 0（SI 位于 IPv6 报文头目的地址字段的最后 2 bit）。

2. 节点 N1 收到数据包时，目的地址 2001:DB8:A:1:1::是本节点发布的一个可压缩的携带 COC Flavor 的 End.X SID，指示下一个 SID 是 32 bit 的 G-SID。此时的SL = 3，SI = 0，所以 SL 减 1，SI 初始化为 3，N1 将 SI 指向的 2:1 复制到 IPv6目的地址中更新G-SID，然后基于新的 IPv6 目的地址进行查表转发。

3. 节点 N2 收到数据包时，目的地址 2001:DB8:A:2:1::是本节点发布的一个支持压缩的携带 COC Flavor 的 End.X SID，指示下一个 SID 是 32 bit 的 G-SID。此时的 SL = 2，SI = 3，所以 SI - 1 = 2。然后将 SI 指向的 3:1 复制到 IPv6 目的地址中更新G-SID，并基于新的 IPv6 目的地址进行查表转发。

4. 同理，后续节点 N3～N9 基于 SL 和 SI 的值将对应 G-SID 更新到 IPv6 目的地址，然后查表转发。

5. 节点N10 收到数据包时，目的地址为 2001:DB8:A:10:10::，N10 识别出这是一个VPN SID，按照 VPN SID的指令进行后续处理。

混编场景：

出自《IPv6+系列电子书：G-SRv6》

在混编场景中，Segment List 总共包含了 10 个 SID。

转发流程描述如下：

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的指令进行后续处理。

随着 IPv6 在我国的部署加速，SRv6 也有了更好的落地基础，运营商对 SRv6 的部署进程在加速。当前标准 SRv6 报文头部占用空间大，在多跳严格路径 TE、SFC 等场景，传输效率不足。G-SID和uSID的提出，很好地解决了 SRv6 报头开销大的问题。压缩后的SID具备了SRv6的所有功能和优势，同时其头开销与 SR-MPLS 相当。这将帮助SRv6 更好地落地，进而加速了我国 IPv6 部署、商用的节奏。