SRv6扩展阅读-故障保护LFA+Flex-Algo+G-SRv6+网络切片

关于SRv6基本原理的相关内容，可参考博客SRv6(BE)-原理介绍+报文解析+配置示例。
关于SRv6 TE原理的相关内容，可参考博客SRv6 TE Policy场景-原理浅谈及配置示例。

• 关于LFA FRR基本原理的相关内容，可参考2008年发布RFC5286-Basic Specification for IP Fast Reroute: Loop-Free Alternates
• 关于LFA FRR应用的相关内容，可参考2012年发布RFC6571-Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks
• 关于RLFA FRR基本原理的相关内容，可参考2015年发布RFC7490-Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)
• 关于TI-LFA FRR基本原理的相关内容，可参考Internet-Draft-Topology Independent Fast Reroute using Segment Routing
• 关于增强型TI-LFA基本原理的相关内容，可参考Internet-Draft-Enhanced Topology Independent Loop-free Alternate Fast Re-route
• 关于G-SRv6基本原理的相关内容，可参考Internet-Draft-Generalized SRv6 Network Programming for SRv6 Compression。（目前该草案已被废弃。）
• 关于SRv6 SL压缩原理的相关内容，可参考Internet-Draft-Compressed SRv6 Segment List Encoding。（目前该草案于2023-10-23年更新G-SRv6为REPLACE-C-SID Flavor。）
• 关于Flex-Algo基本原理的相关内容1，可参考Internet-Draft-Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
• 关于Flex-Algo基本原理的相关内容2，可参考2023年发布的RFC9350-IGP Flexible Algorithm

…
SRv6存在大量相关RFC及其他文档，感兴趣者可查阅相关资料。

本文的主要目的在于记录和学习SRv6的基本内容，详细内容可查阅相关资料。并且鉴于个人能力限制和SRv6技术仍在持续发展的因素，因此难免有纰漏之处。敬请各位专家不吝指导。
参考资料存在实时更新，引用不当烦请理解。
第2和第3章节具体描述了SRv6的相关内容，有基础者可直接对相关内容进行指教。

目录

1.故障保护Fast ReRoute

1.1.背景介绍

传统IGP协议通过各自产生和泛洪相应的链路状态，（在一定范围内）维护相同的LSDB。一旦网络中链路状态发生改变，节点将重新通告链路状态。IGP域将重新进行一次网络拓扑的收敛。

然而IGP的收敛往往取决于设备硬件的相应处理速度，更不用提IGP协议对相应链路状态处理上的限制。比如，OSPFv2的默认Hello时间为10s，也即一旦节点宕机网络最晚可感知10s，更不用说RFC2328中还为OSPFv2的LSA的重传定义了定时器。并且控制面收敛完成下发转发面也需要一定时间。一旦IGP网络因链路等问题而未收敛完成，此时不可避免的就是产生流量中断。这对流量损失非常敏感的业务是不可接收的。

基于以上考虑，提出了Fast ReRoute（FRR，快速重路由）机制主要用于解决由于链路故障导致收敛期间发生的故障丢包。

FRR的基本思想在于，在正常路由转发的基础上，计算额外的备份保护路径放入转发面。一旦感知链路问题，可不经控制面收敛完成，优先走转发面的FRR备份路径转发。待控制面重新收敛完成后，依照控制面下发给转发面的路径进行转发。最大程度上减少流量丢失。

相似的，STP/RSTP/MSTP生成树协议在收到TC报文时会将接口MAC/ARP表项进行清除。这种机制也是为了防止在生成树未收敛完成时导致的拓扑环路。

FRR通常可分为IP FRR、LDP FRR、TE FRR、VPN FRR和PE FRR等。
这里着重介绍IP FRR的三种技术：
LFA：Loop-Free Alternates，无环备份。
RLFA：Remote Loop-Free Alternate，远程无环备份。
TI-LFA：Topology-Independent Loop-free Alternate，拓扑独立无环备份。

1.2.三种IP FRR

在介绍IP FRR之前，应当说明的是全网网络是一个稳定状态，并且节点之间已经形成了LSDB的同步。否则相应的IP FRR是没有意义的。

这里要求形成LSDB的同步，是因为计算节点应当能依据同步的LSDB计算出邻居节点的SPF路径。因为邻居节点/备份路径的下一跳在故障发生的瞬时状态是无法感知的，需要邻居同步相应的状态信息才可感知到。
计算节点需要保证将流量导向邻居节点/备份路径时，邻居节点/备份路径不会将相应的流量在重新发给计算节点。这就需要计算节点能够根据LSDB以不同节点（包括邻居节点/备份路径等）作为根节点计算SPF，从而保证路径无环。
换句话说，需要计算节点不仅需要知道自己本身流程的转发路径，还需要知道流量转发到邻居节点/备份节点后的路径。从而确保流量不会发回自身。
理解这一点非常重要。

1.2.1.LFA

LFA也即Loop-Free Alternates具有两种保护场景：链路保护和节点保护，以及广播型链路上的使用。

链路保护：
要求计算节点（以S标识）的邻居节点/备份下一跳（以N标识）到目的节点（以D标识）的SPF最短路径不经过计算节点（以S标识）。
其数学表达为：公式1
$$Distance\_opt(N,D)<Distance\_opt(N,S)+Distance\_opt(S,D)$$
也即邻居到流量目的地址的开销，小于邻居计算的将流量绕回至计算节点S之后走向目的地址的开销。

计算节点/需执行LFA的节点有时也称为Point of Local Repair，PLR本地修复节点。上述公式为
Distance_opt(N, D) < Distance_opt(N, PLR) + Distance_opt(PLR, D)

满足此要求的网络可选择N作为S—>E链路的邻居节点/备份下一跳。

这里需要注意的是：

• 保护链路的方向性。因为链路的开销计算是具有方向性的。链路来回的开销有可能不一致，虽然往往一致。
• S节点不一定指的是源节点，而是指的是计算节点。通常需要LFA的都是链路上的中间节点。
• 在某些场景下有更严格的约束：Distance_opt(N, D) < Distance_opt(S, D)。

节点保护：
要求计算节点（以S标识）的邻居节点/备份下一跳（以N标识）到目的节点（以D标识）的SPF最短路径不经过故障节点（以E标识）。
其数学表达为：公式2
$$Distance\_opt(N,D)<Distance\_opt(N,E)+Distance\_opt(E,D)$$
也即邻居到流量目的地址的开销，小于邻居计算的将流量绕回至计算节点S之后走向目的地址的开销。
满足此要求的网络可选择N作为S—>D路径上，E节点故障时的邻居节点/备份下一跳。

但就给出的场景和拓扑来看，链路保护和节点保护非常相似。
Q：那么两者的区别在哪里，公式定义上差别的作用是？
A：链路保护允许邻居计算的下一跳经过故障节点（故障节点的链路发生故障，而节点本身可能未发生故障）。而节点保护不允许经过故障节点。
//如上图所示，S—>E故障链路时，邻居节点允许其经过E节点。但是E节点本身如果故障，上述场景将无法执行S对E的节点保护。

广播型链路上的LFA：
如果主下一跳使用广播链路，则备用链路应相对于该链路的伪节点（PN）无环路，以提供链路保护。

其数学表达为：公式3
$$Distance\_opt(N,D)<Distance\_opt(N,PN)+Distance\_opt(PN,D)$$

这一要求的目的在于：

• 要获得链路保护，来自所选备用下一跃点的路径必须不遍历感兴趣的链路，并且从 S 用于到达该备用下一跃点的链路必须不是感兴趣的链路。
• 要使 N 提供链路保护，首先必须确保 N 到 D 的最短路径不遍历伪节点 PN。 其次，S 选择的备用下一跃点必须不遍历 PN。

此外RFC5286在OSPF网络中应用时给出了如下提醒：
@：不建议在配置了虚链路的情况下对骨干区域配置LFA。而对非骨干区域无此限制。
@：对具有多个备份ABR的域间路由不应当使用LFA。
@：不建议对特定非骨干域的Type-4 ASBR路由和Type-5 AS-External路由使用LFA。该特定非骨干域存在两个以上的ABR，其中一个兼具ASBR角色，另一个ABR也作为其他非骨干域的ABR存在。
@：不建议对不同非骨干域通告相同external metric的ASBR的特定网络配置LFA。该特定网络的不同ASBR具有相同的ABR。
自动换行
相应的在ISIS网络中应用时给出了如下提醒：
@：不应当选择具有过载标识的IS作为可用的邻居节点/备选路径。
@：对于携带Link-Attributes Sub-TLV等特定TLV时，路由器不应由于具有 LFA 而指定“本地保护可用”标志。
@：邻居节点/备份下一跳链路已通告为“从本地保护路径中排除的链路”或属性“需要本地维护”，不应使用其作为备份下一跳。

对于ECMP场景和SRLG等其他详细内容，可查阅相关资料。并且注意以上公式是不允许等式存在的，以防止可能的环路。

1.2.2.RLFA

在上一个章节，我们介绍了RFA的使用原理及其场景，并且可以发现LFA的使用是受到网络结构的限制的。并且链路上的开销也非常影响LFA的使用。

出了上文网络结构上无法提供节点保护的情况外，下图场景也无法提供相应的保护。
场景1@：无法提供链路保护。自动换行
场景2@：无法提供节点保护。

因此提出了RLFA，Remote Loop-Free Alternate。RLFA提出P空间和Q空间的概念，将LFA节点的计算范围扩大到了远端节点而不仅限于邻居节点，从而提高了LFA计算的成功概率。

RFC7490定义的RLFA中引入如下概念：
P-Space：计算节点/PLR使用预收敛最短路径从该特定路由器访问的路由器集，该预收敛最短路径（包括等价路径拆分）不应当通过该受保护链路。
Extended P-space：计算节点/PLR的直连下一跳节点使用预收敛最短路径从该特定路由器访问的路由器集，该预收敛最短路径（包括等价路径拆分）不应当通过该受保护链路。
Q-space：对于被保护链路的 Q 空间是任何使用预收敛最短路径不通过该受保护链路的路由器集。
PQ node：节点 S 对保护链路 S-E 的 PQ 节点是 S 的 P 空间（或扩展 P 空间）相对于该受保护链路 S-E 和 E 的 Q 空间（相对于该受保护链路 S-E）的成员交集。
在得出PQ节点后，S/PLR 节点在感知到故障发生时将流量导向PQ节点。由PQ节点负责进行相应转发。

RLFA的这些关键概念在于SPF最短路径的节点。对于节点 S 对保护链路 S-E 有：
P空间应当以 S/PLR 为根，计算到其他节点而来的不经过S-E的最短路径路由器集。
扩展P空间应当以直连下一跳为根，计算到其他节点且不经过S-E的最短路径路由器集。
Q空间应当以 其他节点 为根，计算到目的节点 D 且不经过S-E的最短路径路由器集。
自动换行
@：扩展P空间用于防止不存在PQ节点的情况。
@：上述情况的计算仍然都是由 S/PLR 节点计算而来。

相似的P空间的数学表达为：公式4
$$Distance\_opt(N,P)<Distance\_opt(N,S)+Distance\_opt(S,P)$$
该公式的含义为邻居节点到P空间的SPF路径不经过计算节点 S/PLR。

而相应的Q空间的数学表达为：公式5
$$Distance\_opt(Q,D)<Distance\_opt(Q,S)+Distance\_opt(S,D)$$
该公式的含义为Q节点到目标节点的SPF路径不经过计算节点 S/PLR。

LFA无法链路保护，RLFA可以保护的场景1@：链路P1—>P4S/PLR节点计算得到：
P空间/扩展P空间：[PE1，P1 ，P2，P3]；
Q空间：[PE2，P4，P3]；
PQ节点：[P3]。
因此在链路故障时，S/PLR节点将流量导向P3节点。待IGP收敛完成后重新导向相应节点。

LFA无法节点保护，RLFA可以保护的场景2@：节点E
S/PLR节点计算得到：
P空间/扩展P空间：[PE2，P4，P3]；
Q空间：[P3]；
PQ节点：[P3]。
因此在E节点故障时，S/PLR节点将流量导向P3节点。待IGP收敛完成后重新导向相应节点。

RLFA转发原理：
本质是在计算节点 S/PLR 和 PQ 节点之间建立隧道。
由于计算节点 S/PLR 和 PQ 节点之间往往是非直连下一跳，如果计算节点 S/PLR 单纯将流量导向去往 PQ 节点的下一跳时必定发生流量丢弃。

此时计算节点 S/PLR 和 PQ 节点建立Target LDP或者Remote LDP邻居关系，报文中嵌套相应的隧道协议。

如果源节点至目标节点之间本身位于 IP/MPLS LDP 隧道中，计算节点 S/PLR 和 PQ 节点的TLDP或RLDP还需要传递相应 PQ 节点发向目标节点的Label。否则由于PQ节点收到相应流量后，无法识别相应的标签造成流量丢弃。
这是由于传统的LDP分配的标签通常仅具有本地意义或者一跳之内的可识别性。如果可以全局获取相应的Label，计算节点 S/PLR 则可以之间建立相应的流量转发指导。
这也是RLFA的缺陷所在，扩展性差（LDP需要保证Label的连续性）并且引入了额外的保护隧道状态。

@：对于RLFA可能还存在一个问题需要说明，
Q：为什么扩展空间要求的是 S/PLR 节点的直连下一跳？
A：在详细介绍这一点之前，首先介绍下之前的内容。
对于 LFA： 其工作原理在于 S/PLR 将流量不经修改的向自己计算得到的以 S/PLR 为根计算的下一跳转发。下一跳收到后可直接依照目的地址进行转发，后续转发的最短路径树必然不途径故障链路。
对于普通的 RLFA： 其工作原理在于 S/PLR 将流量添加隧道信息后向自己计算以 S/PLR 为根计算到达 PQ 节点的下一跳转发。流量利用隧道到达 PQ 节点。PQ 节点收到后脱去隧道信息可直接依照流量原始目的地址进行转发，后续转发的最短路径树必然不途径故障链路。
对需扩展的 RLFA：在普通的 RLFA下没有 PQ 节点，其实意味着不存在一个中间节点同时满足
1@： S/PLR 到中间节点的最短路径树不途径故障链路/故障节点。
2@： 从中间节点到目标节点的最短路径树不途径故障链路/故障节点。
扩展 P 空间/扩展的 RLFA 的解决办法是由自己的直连下一跳来承担这一功能找寻 PQ 节点。随后自己的直连下一跳按普通的RLFA执行。而自己到直连下一跳必然是路径无环的。相比于选择其他非直连下一跳，这样操作较为简单功能程序处理可以不用考虑更多复杂情况。

点击此处回到目录

1.2.3.TI-LFA

传统的LFA/RLFA都是基于IGP开销进行备份下一跳选择。即使功能已经非常强大，但是在某些场景下无法计算 PQ 节点也就无法进行备份路径选择。

扩展 P 空间后仍无PQ节点的链路保护：自动换行
无PQ节点的节点保护：-

因此基于SR思想提出了Topology-Independent Loop-free Alternate拓扑独立的无环备份。TI-LFA仍然继承了RLFA的相关概念进行备份下一跳的计算。

TI-LFA可以100%的网络保护，并且可以避免次优路径。

LFA/RLFA的次优路径问题：
LFA/RLFA 计算得到备份邻居下一跳节点和远端 PQ 下一跳节点往往都是计算节点 S/PLR 根据 LSDB 以非下一跳为根计算得到的。而故障收敛后的流量下一跳是以自己为根根计算得到的。因此备份下一跳节点和故障后收敛到的下一跳节点很有可能非同一个节点。
在这种情况下，往往意味着计算的备份节点是次优路径。

TI-LFA基本原理：
计算节点 S/PLR 封装相应的SID信息将其向备份下一跳进行转发。

对于LFA场景使用TI-LFA：
此时备份节点必定是备份下一跳，并且该备份下一跳可直接转发流量。此时计算节点 S/PLR 可直接将流量转发给，备份节点可依照自身IGP得到的转发面将流量导向正确的目标节点。

无需扩展P空间的RLFA场景使用TI-LFA：
由于备份下一跳为PQ节点且不是直连下一跳，无法直接导通流量。此时需计算节点 S/PLR 将流量导向 PQ 节点。

基于SRv6网络平面的计算节点 S/PLR 可进行如下操作：
1@在IPv6的SRH中插入指向PQ空间的SID。

这里的SID可选择PQ空间的End SID，或者可以选择路径上到直连PQ空间的End.X SID。两者的区别在SID的处理方式不同。此外还可结合相应的Flavor行为进行相应处理。

2@将原有数据流作为Payload，重新封装一层IPv6头部。目的IPv6选择相应的PQ空间SID，因为SID本身也就是IPv6地址。

这种方式还可插入SRH进行相应操作。

所需扩展P空间的RLFA场景使用TI-LFA：
此时，计算节点 S/PLR 到PQ节点的SPF路径会途经故障点。
//例如此时C节点只能作为扩展P空间后的PQ节点。此时A节点不能直接将流量导向C节点。需要额外的流量转发指导。

RLFA不满足场景使用TI-LFA：
TI-LFA应当指导流量先后导向P空间和Q空间节点。此时的P节点和Q节点应当是P空间和Q空间的边界设备。
以及可进行
如上图有P节点P2和Q节点P3，此时需要支持2 Segment的转发行为。

上述图示展示了在一个SRH中插入了2个SID，还可采用双SRH的方式进行相应转发。在到达相应节点后，进行第一层SRH的剥离。

TI-LFA的相应原则
@：SRLG（Share Risk Link Group）链路 > 节点保护 > 链路保护。

SRLG类似于Uplink/monitor-link，在进行相应计算时对同一个链路组内的链路具有相同的判断原则。详细内容可查阅相关资料。

@：对于有约束路径的场景的情况，TI-LFA可能存在失效情况。此时需要进行Midpoint中间节点保护。

为了解决SRv6 TE Policy场景由于严格节点约束导致的TI-LFA FRR保护失效问题，需要由中间节点（Midpoint）的上游节点代替它完成这个转发处理，这个上游节点称之为代理转发（Proxy Forwarding）节点。
代理转发节点感知到报文的下一跳接口故障，并且下一跳是报文目的地址，且SL > 0时，代理转发节点代替中间节点执行End行为，将SL减1，并将下层要处理的SID更新到外层IPv6报文头，然后按照下层SID的指令进行转发，从而绕过故障节点，实现SRv6中间节点故障的保护。
自动换行
发生Mindpoint的场景：

• FIB查询没有命中，触发FIB-MISS。
• 报文IPv6目的地址为本地接口的地址且出端口Down, TI-LFA FRR也不是Node保护时。
• 本地SID表命中为End.X SID且出端口Down时。
• 从路由表中查到的路由为NULL0路由时。

需要注意的是进行Midpoint保护功能的节点应当是Segment List中的上游设备。

1.2.4.防微环

前文我们介绍IP FRR主要用于解决全网设备IGP收敛时间的差异导致网络中发生短时流量中断的场景。

尽管最新的TI-LFA已经可以100%覆盖各种拓扑，但是此种现象仍然是不可避免的。因为前文重点描述的是 PLR （Ponit of Local Repair）节点上缺少转发路径时的解决方案。那么很有可能PLR已经完成IGP的收敛，而其他节点还未完成收敛。此时就会发生相应的环路问题。

基于以上场景，TI-LFA另有防微环方案：正切防微环和回切防微环。

正切防微环：

本端正切防微环：PE1—>PE2
如上图所示，在P1—P3链路故障时，计算节点 S/PLR 节点无法得到PQ节点。在应用了TI-LFA之后，计算节点 S/PLR 节点将插入相应2段SID将以此流量依次转发给P2，P4，P3和PE2。计算节点 S/PLR 节点自身收敛完成后，不在进行SID插入或封装隧道。此时P2如果未感知 P1—P3 链路故障，将在 P1—P2 之间发生流量短时微环。

基本逻辑为：

• 正常转发。
• P1—P3 链路故障，触发 P1/PLR 节点的TI-LFA备份路径。流量经P2，P4，P3和PE2到达目的节点。
• P1/PLR 节点优先收敛完成，走转发面下发的路径信息。流量导向P2。
• P2 节点如果未感知故障未收敛完成，此时P2 节点认为到达PE2的最优路径为 P1—>P3—>PE2。
• 最终流量在 P1—P2 之间发生环路。

解决办法：在PLR节点启用定时器，确保网络收敛完成后在撤销TI-LFA的备份路径。

远端正切防微环：PE1—>PE2
如上图所示，在P2—P4链路故障时，计算节点 S/PLR 节点无法得到PQ节点。在应用了TI-LFA之后，计算节点 S/PLR 节点将插入相应2段SID将以此流量依次转发给P，P1，P3和PE2。计算节点 S/PLR 节点自身收敛完成后，不在进行SID插入或封装隧道。此时P如果优先P1感知 P2—P4 链路故障，将在 P1—P 之间发生流量短时微环。

基本逻辑为：

• 正常转发。
• P2—P4 链路故障，触发 P2/PLR 节点的TI-LFA备份路径。流量经P，P1，P3和PE2到达目的节点。
• P 节点优先P1收敛完成，P 节点认为到达PE2的最优路径为 P1—>P3—>PE2。
• P1 节点如果未感知故障未收敛完成，此时P2 节点认为到达PE2的最优路径为 P1—>P3—>PE2。
• 最终流量在 P1—P 之间发生环路。

解决办法：由于此时流量不经过 P2/PLR 节点，则此时TI-LFA备份路径完全无法生效导致环路。在P节点开启定时器插入了防微环Segment List <P3，P1>，所以消除了网络中潜在的环路。

防微环Segment List也可选择 P3—P1 的End.X SID。

回切防微环：相似的在故障恢复时也可能产生环路。
本端正切防微环：PE1—>PE2
本端回切防微环的逻辑在于其他节点优于PLR收敛导致环路，也即 P2 节点优于 P1/PLR 节点收敛导致流量在 P1—P2 上的环路。

解决办法：由于回切不会进入 P1/PLR 节点的 TI-LFA 转发流程，所以无法像正切一样使用延时收敛的方式解决回切微环问题。可通过在P2节点开启定时器插入了防微环Segment List <P3，P1>，消除了网络中潜在的环路。

远端正切防微环：PE1—>PE2
远端回切防微环的逻辑在于如果离故障点更远的节点先于离故障点近的节点收敛，就可能会导致环路，也即 P1节点优于 P 节点收敛导致流量在 P1—P 上的环路。

解决办法：可通过在P1节点开启定时器插入了防微环Segment List <P4，P2>，消除了网络中潜在的环路。

1.3.IP FRR的实现

//ipv6 avoid-microloop segment-routing rib-update-delay：在ISIS视图下配置SRv6场景IS-IS路由的延迟下发时间。
需要提前开启ipv6 avoid-microloop segment-routing防微环功能，在IGP收敛期间，头节点严格按照显式路径转发流量，转发过程不依赖于各设备的IGP收敛，可以避免各设备的IGP收敛，可以避免环路产生。

//loop-free-alternate level-2ti-lfa命令配置的Level依赖loop-free-alternate命令配置的Level，即只有LFA使能了相应的Level，ti-lfa才可能在指定Level生效，否则配置不成功。

点击此处回到目录

2.SRH压缩之G-SRv6/C-SID

2.1.背景介绍

SRv6使用128bits的IPv6地址作为SID填充在SL中，如果SRH需要封装的SID较多，则会使得SRv6报文头明显增大。

携带过多的SID有如下后果：
@：数据包携带有效载荷量下降。在给定数据包长度的前提下，包头越长可携带的有效数据就越短。这是由于客观上IPv6/SID的长度所决定的。

@：老旧设备兼容问题。SRv6报文头开销过大带来的第二个问题是SID栈太深。在博客SRv6(BE)-原理介绍+报文解析+配置示例中我们提出目前设备对SRH扩展头中的SL处理是有限制，一大限制因素是芯片本身处理能力的限制。因此某些节点在处理携带过多的SID的SRH时，可能无法处理造成流量黑洞。

@：MTU超限风险较大。报文头增大，可能导致MTU（Maximum Transmission Unit，最大传输单元）超限。通常只有IPv6源节点和目的节点才会解析IPv6扩展头部，所以只有IPv6源节点始发IPv6报文时才会进行IPv6 MTU分片，中间节点转发IPv6报文时不进行IPv6 MTU分片。当IPv6报文长度大于出接口IPv6 MTU时，设备会丢弃报文，并进行Path MTU发现。SRv6使用IPv6作为数据平面协议，MTU问题对SRv6的影响较大

即使有Binding SID可以进行SL的交换，但是数据报文仍然可能较大。因此，提出了G-SRv6（Generalized Segment Routing over IPv6，通用SRv6）技术以解决SRv6报文头开销过大的问题。

目前G-SRv6方案已在Internet-Draft-Compressed SRv6 Segment List Encoding草案中融合为C-SID（Compressed-SID）方案。在 C-SID 方案中，新定义了两种 flavors：NEXT-C-SID 和 REPLACE-C-SID。每种 C-SID 都可用于指导 End, End.X, End.T, End.B6.Encaps, End.B6.Encaps.Red, 和 End.BM 行为转发。

NEXT-C-SID flavors 和 REPLACE-C-SID flavors 都利用 SID Argument 来确定如何处理下一个 segment，但采用不同的 Segment List 压缩方案。

• NEXT-C-SID flavors 表示所处理的每一个 C-SID container 为完整的 SRv6 SID。其中包含了 C-SID 集合中所有 C-SID container 公共的 Locator-Block，并且其 Argument 携带后续 C-SIDs 信息。
• REPLACE-C-SID flavors 表示仅有第一个 C-SID 中的元素为完整的 SRv6 SID。其中包含了 C-SID 集合中所有 C-SID container 公共的 Locator-Block，并且 C-SID 集合的其余元素不在携带公共的 Locator-Block。

后文介绍的 G-SRv6 也即 REPLACE-C-SID flavors。

2.2.设计思想

为了解决上述问题，G-SRv6需要兼容现有SRv6环境包括支持SRH以及相应的Behavior。并且需要考虑方案的可扩展性和字节对齐等因素。目前主流的方式是进行32-bits的SID压缩方案。这一考虑是压缩效率和兼容性综合考虑的结果。

方案逻辑：
通常我们指定的SID由三部分组成：Locator+Function+Arg。其中Arg为增强功能可选参数，使用较少。Function为自定义设置，不具备压缩适用性。Locator虽然基于节点进行分配，但通常其部分前缀具有相同属性。因此可以将SID中Locator中相同的部分进行压缩。

在某些时候有可进行上图细分：Locator=Block和Node ID。Block是区域的Common Prefix公共前缀，Node ID是相应的节点标识。
Internet-Draft-Compressed SRv6 Segment List Encoding草案将其分别定义为 Locator-Block 和 Locator-Node。
自动换行
比如，我们通常可以为PE1分配2001:DB8:1:1::/64，P分配2001:DB8:2:2::/64，PE2分配2001:DB8:3:3::/64。其中有Common Prefix公共前缀2001:DB8::/32。
//SL栈深为6的SRH进行32-bit压缩示例。这里的G-SID指的就是G-SRv6压缩后的SID，相似的概念还有G-SRH。

每4个G-SID组成一个G-SID Container，也即一个G-SID Container相当于一个标准的SID。
一个G-SID Container只有128bits长，可封装1-4个32-bits的G-SID。对于未填充满G-SID的Container，其余字节为全0的Padding字段。通过这种方式从而实现格式上的兼容性。

G-SRH也可以允许G-SID和标准SID共存的情况出现。
//此时Segment List的效果如上图所示，SRv6子路径可以是标准SID也可以是128 bit的G-SID。

报文转发：
为了指示SRH中G-SID的存在，G-SRv6定义了一种COC Flavor。当节点处理携带COC Flavor的SID时，SL指针不在偏移128-bits而是32-bits。

@：常见的Flavor行为可参考博客SRv6(BE)-原理介绍+报文解析+配置示例的3.1.2.章节。
@：这里简单说明下COC Flavor的实现原理及效果：在SID全网泛洪时，IGP报文中的相应字段可标识相应的SID为具有COC Flavor行为的SID。源节点在进行SRH封装时，可依照G-SRv6相应规则压入G-SID。转发面在收到Destination为特定G-SID的IPv6报文时，进行特定Segment Index的偏移完成SWAP操作。
@：在2023年10月发布的最新草案Internet-Draft Compressed SRv6 Segment List Encoding中，这种 Flavor 已被更新为 REPLACE-C-SID。

并且为了特定标明G-SID的具体位置，额外定义了2-bits的SID Index标识位。

@：SID Index效果有点类似SRH头部中的Segment Left字段，都是为了标识SID的存在位置以便将特定Segment List[]填充到IPv6报文的Destination中。
@：SID Index初始值为0，取值0-3标识了G-SID Container中G-SID的选择位置。
@：与Segment List相似，SID Index的取值也是倒数计数。从底层至上层SID Index降序排列，并且大序号SID Index先填充入IPv6报文的Destination中。

//最终有类似上图效果。

压缩路径在Segment List中的编码规则为:

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

2.3.实现效果

实际转发案例分析：
控制面:
@：具有COC Flavor行为的SID在全网进行泛洪，以便所有SRv6节点知晓网络中有哪些设备支持SID压缩功能。
@：控制器或头节点收集SID信息，以便在头节点创建SRH压入相应的SID。
转发面
@：头节点依照全网信息进行相应的SID压入并创建SRH。
@：中间节点，（如果支持SID压缩功能），依照收到报文的Destination IPv6地址与本地SID表的匹配程度来判断后续进行Segment Left指针偏移还是Segment Index的指针偏移。

通常SRH中的第一需转发的SID不加入Segment List栈中。

纯压缩域的报文转发：图中结果仅用于示例，相应错误请忽略。
//如上图所示的SRH转发行为
N0：节点创建SRH填充相应SID，Segment Left取3，Destination IPv6地址填充2001:DB8:A:1:1::。随后向邻居节点N1进行转发。
N1：收到该数据报文后，根据2001:DB8:A:1:1::指示下一个SID是32bit的G-SID。将2:1填充入相应的字段，并将Segment Index初始化为3进行相应转发。
…
N10：收到表示End.DT4的Destination IPv6地址2001:DB8:A:10:10::3后。脱掉SRH和IPv6头部向对应VPN实例进行转发。

自动换行
混合场景的报文转发：
//如上图所示的SRH转发行为与纯压缩场景基本类似。这里仅作简单介绍。
N4：收到Destination IPv6地址2001:DB8:A:4:2::1后匹配到本地发布的普通SID，直接Segment Left-1并读取相应的SID填充入Destination IPv6地址中。

@：通常IGP在发布SID时，会发布两套SID。一套为普通SID另一套为携带COC Flavor的SID。
@：普通SID则可通过判断“Node ID+Function ID”的长度是否等于32，以及Arguments字段长度是否不短于2 bits且值为0（避免有的SID使用了Arguments导致不可压缩）来判断SID格式支持G-SRv6压缩。
因此压缩功能的实现实际上与上一节点的选择相关。
@：最后一个SID通常用于标识业务，一般不进行G-SRv6压缩。

最后我们以9个栈深SID浅谈下G-SRv6的压缩效果：
首先定义压缩效果
$$压缩效率=(压缩前长度-压缩后长度)/压缩前长度$$
因此这里
$$压缩前长度为9\ast 16字节。$$
由于G-SRv6的第一个SID需要携带相应的Common Prefix公共前缀，实际上不进行压缩。
所以
$$压缩后长度为1\ast 16+8/4\ast 16字节。$$
因此，
$$压缩效率=(9\ast 16-1\ast 16-8/4\ast 16)/9\ast 16，为66.67\%。$$
这是一个理论上的最优效率，并且随着栈深的增加压缩效率随之提升。如果栈深非4的倍数，G-SID Container就需要有Padding字段进行填充。此时效率就会下降。

点击此处回到目录

3.Flexible Algorithms

3.1.背景及术语

传统的IGP协议等都是基于链路的开销值来计算到达目的地的最优路径，但是采用这种方式往往存在很大的局限性。运营商处于业务SLA或者业务分级的需求，希望能根据自己的需求去定义路径计算规则。
一种实现方式是通过Traffic Engineering流量工程的技术实现基于一定的约束条件，使网络流量按照指定的路径进行传输。但是TE存在配置复杂、扩展性差的问题，并且设备上还需要维护大量的状态信息 。

@例如OSPF的默认开销计算为100M/链路带宽，一般来说带宽越大开销越小。通过这种方式实现的路径选择，往往不是所需的最优路径。一个简单的比喻就是节假日的高速路（高带宽链路）往往比乡道（低速链路）行驶体验更差。传统的IGP无法针对此种情况做优化。
@也即，传统的IGP无法根据额外的约束条件或依照时延调整选路。

因此Flexible Algorithm灵活算法应用而生，Flex-Algo可以允许IGP（IS-IS和OSPF）自己计算基于约束的网络路径，能够更简单和灵活的实现网络的TE能力。

Flexible Algorithm技术的基本原理在于定义了其他非IGP开销计算算法，全网依照新算法计算SPF路径。

Flexible Algorithm技术和传统的IGP算法都要计算路径，并要保证路径无环。区别在于形成路径树的计算逻辑不同。
Flexible Algorithm技术需要经过定义算法、通告算法、生成拓扑、计算路径。而传统IGP省略了定义和通告算法一步，因为默认进行携带基于链路开销的SPF算法。两者都根据相应算法形成邻居表、拓扑表和路由表。

相关术语：
FAD：Flexible Algorithm Definition，由calculation-type计算类型，metric-type度量类型和一系列constraints约束组成的的集合。
Flex-Algorithm：128-255范围内的数字标识符，通过配置与FAD相关联。
IGP-Algorithm：也即传统的IGP路径算法。可以理解为metric-type度量类型和constraints约束未指定的特殊FAD。
FADF：Flexible Algorithm Definition Flags，FAD标志位。
FAPM：Flexible Algorithm Prefix Metric，FA前缀度量。

3.2.基本原理

详细内容可参考2023年发布的RFC9350-IGP Flexible Algorithm或其他资料。

为了实现以上功能，IGP协议做出了相应的协议扩展。
这里的IGP协议主要指集成ISIS协议、OSPFv2和OSPFv3。

ISIS协议扩展：以ISIS为例进行介绍。OSPF报文字段与之类似也就不在说明，感兴趣者可查阅RFC9350等相关资料。
IS-IS Router CAPABILITY TLV（Type=242，RFC7981）中新定义Sub-TLV IS-IS FAD sub-TLV（Type=26）
Flex-Algorithm：1字节。取值128-255，通过配置与FAD相关联。用户可以自定义这些值代表的具体算法。
Metric-Type：1字节。目前仅定义了3种–0表示IGP Metric，1表示最小单向链路延迟，2表示TE默认Metric。
Calc-Type：1字节。取值0-127，指定相应的计算类型。Metric和Constraints不得继承。如果取0表示SPF，1表示严格SPF算法。
Priority：1字节。取值0-255，
Sub-TLVs：不定长，可选的Sub-TLV。
@IS-IS FAD Sub-TLV 可以在任何编号的LSP中通告。
@L1/L2 路由器不得从Level-1重新生成任何 FAD Sub-TLV 到级Level-2。

Sub-TLV IS-IS FAD sub-TLV（Type=26）还定义了Sub-TLV的Sub-TLV，这里进行简单介绍：主要与FAD三要素的约束条件对应。
IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV（Type=1）：用于通告Flex-Algo算法约束条件中亲和属性的Exclude-Any排除规则。也即不能包含任何一个引用的亲和属性名称，不满足的链路将被排除，不能参与算路。
IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV（Type=2）：用于通告Flex-Algo算法约束条件中亲和属性的Include-Any规则。也即只要包含一个引用的亲和属性名称，该链路就可以参与算路。
IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV（Type=3）：通告Flex-Algo算法约束条件中亲和属性的Include-All规则。也即要包含所有引用的亲和属性名称，不满足的链路将被排除，不能参与算路。
IS-IS Flexible Algorithm Definition Flags Sub-TLV（Type=4）：特定功能标识，目前仅定义M-bit。设置后，必须使用特定于 Flex 算法的前缀指标进行区域间和外部前缀计算。此标志不适用于通告为SRv6 locators的前缀。
IS-IS Flexible Algorithm Exclude SRLG Sub-TLV（Type=5）：通告Flex-Algo算法约束条件中的共享风险链路组Exclude SRLG规则。是具有相同故障风险的一组链路集合，使用Exclude SRLG来描述对风险共享链路组的约束。

不同类型的子TLV只能在ISIS FAD Sub-TLV中出现一次。如果出现了多次，则该ISIS FAD Sub-TLV不会被接收者处理。

除以上TLV外，RFC9350还定义IS-IS Flexible Algorithm Prefix Metric Sub-TLV（Type=6）主要在Extended IP reachability（Type=135），MT IP. Reach（Type=235），IPv6 IP. Reach（Type=236）和MT IPv6 IP. Reach（Type=137）中携带，用于通告指定前缀携带特定Flexible Algorithm Prefix Metric。

在同一个IGP域内，不同设备可能定义算法值相同但是含义不同的算法，当出现灵活算法定义不一致时，各个设备按如下规则进行处理：

• 选择优先级（Priority）最大的Flex-Algo定义。
• 当有多个节点通告优先级相同的算法定义时，选择System-ID最大的节点发布的算法定义。

RFC8667还定义IS-IS Router CAPABILITY TLV（Type=242，RFC7981）的子TLV==SR-Algorithm Sub-TLV（Type=19）用于通告自己所使用的算法。
每种算法占1字节，且必须携带Algorithm 0表示最基本的SPF算法。SR-Algorithm Sub-TLV只能在同一个IS-IS Level里传播，不能传播到该Level区域之外。也即distribution flags应进行相应设置。与FAD的Calc-Type相对应。

3.3.SRv6 Flex-Algo实现

一方面各个设备的IGP协议会通过FAD Sub-TLV对外通告本机支持的算法，以及某一个Flex-Algo的具体计算规则。

另外一方面，用户在配置Locator时，可以配置关联的算法。IGP会将算法和Locator一起通过SRv6 Locator TLV对外发布。

以上图为例对Flex-Algo基于链路静态时延的SRv6的应用进行说明：主要介绍PE1上关于Flex-Algo与普通SRv6的区别，仅供参考不具备实际意义。

te attribute enable
#

flex-algo identifier 128
 priority 100
 metric-type delay
 affinity include-all green
# 
//主要定义FAD的三要素calculation-type，metric-type和constraints约束。
//灵活算法metric-type默认为IGP，constraints默认不约束

path-constraint affinity-mapping                             
 attribute green bit-sequence 1                              
 attribute red bit-sequence 9                                
# 
//定义约束路径映射

segment-routing ipv6                                         
 encapsulation source-address 1::1                           
 locator as1 ipv6-prefix 10:: 64 static 32 flex-algo 128     
#  
//通告携带 flex-algo 的Locator。

isis 1        
 is-level level-1                                            
 cost-style wide                                             
 network-entity 10.0000.0000.0001.00                                                                  
 flex-algo 128 level-1                                       
 #            
 ipv6 enable topology ipv6  
 ipv6 traffic-eng level-1                                 
 segment-routing ipv6 locator as1                            
 #            
# 
//定义IGP携带Flex-Algo

interface GigabitEthernet1/0/0
 undo shutdown  
 ipv6 enable
 ipv6 address 2001:db8:1::1/96
 isis ipv6 enable 1  
 te link-attribute-application flex-algo
  delay 10 
  link administrative group name red 
# 
//接口指定Flex-Algo基本条件

点击此处回到目录

4.SRv6与网络切片

网络切片是指在同一个共享的网络基础设施上提供多个逻辑网络（切片），每个逻辑网络服务于特定的业务类型或者行业用户。运营商将基于一套共享的网络基础设施来为多租户提供不同的网络切片服务，满足不同行业的差异化网络需求，各垂直行业客户将会以切片租户的形式来使用网络。

网络切片从广义上来说，是一整套解决方案，涉及无线接入网、IP网络和移动核心网三个部分，这里主要介绍IP网络的网络切片。

4.1.背景及相关术语

5G时代存在三种主要业务需求：
eMBB：Enhanced Mobile Broadband，增强型移动宽带。聚焦对带宽有高要求的业务。
uRLLC：Ultra-Reliable Low-Latency Communication，超高可靠超低时延通信。聚焦对时延有高要求的业务。
mMTC：Massive Machine Type Communication，大规模机器通信。聚焦对复杂业务类型有高要求的业务。

5G核心网：
UPF：User Plane Function，用户面功能。
MEC：Mobile Edge Compute，移动边缘计算。

网络切片实现需求：
业务隔离：针对不同业务在公共网络中建立不同的网络切片，提供业务连接和访问的隔离。
资源隔离：网络切片所使用的网络资源与其他网络切片所使用资源之间是否存在共享。
运维隔离：对运营商分配的网络切片进行独立的管理和维护操作，即做到对网络切片的使用近似于使用一张专用网络。

网络切片方案：
基于亲和属性的方案：每个亲和属性对应一个网络切片。亲和属性可以标识不同切片的转发资源接口，每个切片资源接口均需要配置IP地址和SR SID。

控制平面：每个切片基于亲和属性计算SR-MPLS和SRv6 Policy路径，用于业务承载。
功能实现上使用亲和属性将链路标识成不同颜色（如蓝、黄等），相同颜色的链路组成一个网络。将不同的亲和属性配置在各个网络切片对应的预留资源接口或子接口上，实现基于亲和属性划分出独立的网络切片。

数据平面：切片基于SR-MPLS标签栈或SRv6 SRH头封装和逐跳转发业务报文。
不同网络切片预留的资源接口或子接口具有不同的SRv6 End.X SID，这样网络中每一个转发节点在转发报文时可以根据SID确定用于执行报文转发的接口或子接口资源。

基于Slice ID的方案：
引入全局唯一的Slice ID标识网络切片，每个Slice ID对应一个网络切片。Slice ID可以标识切片内转发资源接口，不需要为每个切片接口配置独立的IP地址和SR SID。

控制平面：基于Slice ID计算SR-MPLS或SRv6 BE或TE Policy路径，用于业务承载。
功能实现上为不同平面网络引入了二维地址标识网络切片ID。通过网络物理节点IP地址+网络切片ID来唯一标识网络切片中的逻辑节点。

数据平面：各转发节点根据数据报文中携带的Slice ID匹配切片资源接口转发业务。为了进行区分，数据报文中需要额外携带全局的网络切片标识。一种典型的实现方式是，在IPv6的逐跳选项（Hop-by-Hop options，HBH）扩展报文头中携带网络切片的Slice ID。

网络切片和FlexE技术结合：
FlexE技术通过FlexE Shim把物理接口资源按时隙池化，在大带宽物理端口上通过时隙资源池灵活划分出若干子通道端口（FlexE接口），实现对接口资源的灵活、精细化管理。
每个FlexE接口之间带宽资源严格隔离，等同于物理口。FlexE接口相互之间的时延干扰极小，可提供超低时延。FlexE接口的这一特性使其可用于承载对时延SLA要求极高的uRLLC业务。

4.2.基于Slice ID的网络切片

控制面：
控制器或人为将业务路径与Network Slice进行绑定并进行网络通告。在此过程，在隧道封装属性（Tunnel Encapsulation Attribute）的Tunnel-Type TLV（Type=23）中新定义了一个Slice ID Sub-TLV。

Slice ID Sub-TLV的Type值，当前为126。该Type后续可能将发生改变。
SRv6 TE Policy可以通过静态配置生成，也可以由控制器通过BGP IPv6 SR-Policy扩展来下发。在静态配置场景，Slice ID也是静态配置指定；在控制器下发场景，控制器下发SRv6 TE Policy路由时需要携带Slice ID信息。

网络设备需要生成两张转发表：

一张是路由表，用于根据报文的目的地址确定三层出接口；

另一张是切片接口的Slice ID映射表，用于根据报文中的Slice ID确定切片在三层接口下的预留资源。

转发面：
使用IPv6的扩展选项头Hop-by-Hop Options header来携带Slice ID值进行业务区分。依照相应的Segment List进行转发，并在转发时根据Slice ID关联的接口进行相应转发。

//指定携带Slice ID的扩展头，默认为HBH（Next Header=0）携带Slice ID。

相应的报文转发封装：
CE1向PE1发送一个普通IPv4单播报文。

1. PE1接收到CE1发送的报文之后，迭代路由的出接口是SRv6 TE Policy。PE1为报文插入SRH信息，封装SRv6 TE Policy的SID List，然后封装HBH扩展头，扩展头里携带SRv6 TE Policy的Slice ID信息，最后封装IPv6基本报文头。完成之后，PE1将报文对P1转发，转发时通过Slice ID信息关联到指定的网络切片接口。

2. 中间P1设备根据SRH信息转发，转发时使用HBH扩展头里的Slice ID信息关联到指定的网络切片接口。P3和P5的转发过程与P1类似。

3. PE2使用内层VPN SID查找My Local SID表，命中到End.DT4 SID，PE2解封装报文，去掉SRH扩展头、HBH扩展头和IPv6报文头，使用内层IPv4报文的目的地址10.2.2.2查找VPN SID对应的VPN实例路由表，然后将报文转发给CE2。

4.3.网络切片实现

相比于传统SRv6，
PE节点上需要实现：
1@创建网络切片实例：

network-slice instance 10
 description Basic                                         
#                                                    
network-slice instance 20
 description vpn1 
#  

2@网络切片与业务进行绑定：

segment-routing ipv6
  encapsulation source-address 2001:DB8:1::1
  locator <PE1> ipv6-prefix 2001:DB8:100:: 64 static 32
    opcode ::10 end psp
  #
  srv6-te-policy locator <PE1>
  segment-list <list1>
    index 5 sid ipv6 2001:DB8:120::20
    index 10 sid ipv6 2001:DB8:130::30
  #
 srv6-te policy <policy1> endpoint 2001:DB8:3::3 color 101
   candidate-path preference 100
     network-slice 20 data-plane
     segment-list <list1>
  #

3@网络切片与接口绑定：

interface GigabitEthernet1/0/0
 undo shutdown  
 ipv6 enable    
 ipv6 address 2001:DB8:10::1/64
 isis ipv6 enable 1 
 network-slice 10 data-plane
#               
interface GigabitEthernet1/0/0.1 
 vlan-type dot1q 11
 ipv6 enable    
 mode channel enable 
 mode channel bandwidth 500
 basic-slice 10 
 network-slice 20 data-plane
#  

如果采用BE模式，则需要在PE节点上为Network Slice进行着色以便进行相应区分。

network-slice color-mapping
  color 101 network-slice 20
#
ip vpn-instance vpn1
  import route-policy <rp11>
#
route-policy <rp11> permit node 10
  apply extcommunity color 0:101
# 

P节点上需要实现：
1@创建网络切片并与接口绑定：

network-slice instance 10
 description Basic 
#                                                    
network-slice instance 20
 description vpn1
# 
interface GigabitEthernet1/0/0
 undo shutdown  
 ipv6 enable    
 ipv6 address 2001:DB8:10::2/64
 isis ipv6 enable 1
 network-slice 10 data-plane
#               
interface GigabitEthernet1/0/0.1 
 vlan-type dot1q 11
 ipv6 enable    
 ipv6 address auto link-local
 mode channel enable 
 mode channel bandwidth 500
 basic-slice 10 
 network-slice 20 data-plane
#    

更新

点击此处回到目录