SRv6网络编程：开启IP网络新时代 | 一文读懂SRv6 Policy

Posted 2022-02-25 一个热爱编程的通信人

SRv6 Policy利用Segment Routing的源路由机制，通过在头节点封 装一个有序的指令列表来指导报文穿越网络。SRv6利用IPv6 128 bit地 址的可编程能力，丰富了SRv6指令表达的网络功能，除了用于标识转 发路径的指令外，还能标识VAS（Value-Added Service，增值服务）， 例如防火墙、应用加速或者用户网关等。除此之外，SRv6还有着非常 强大的扩展能力，如果要部署一个新的网络功能，只需要定义一个新 的指令即可，不需要改变协议的机制或部署，这大大缩短了新网络业 务的交付周期。所以说，SRv6 Policy可以实现业务的端到端需求，是实现SRv6网络编程的主要机制。

通过在SRH中封装一系列的SRv6 Segment ID，可以显式地指导报 文按照规划的路径转发，实现对转发路径端到端的细粒度控制，满足 业务的高可靠、大带宽、低时延等SLA需求。如图4-20所示，在头节点 1插入两个SRv6 Segment ID，分别是节点4到节点5的End.X SID和节点7 的End SID，这样就可以指导报文沿着特定的链路转发，或者沿着支持负载分担的最短路径转发。SRv6就是通过这种方式实现了TE。

为了实现SR-TE，业界引入了SR Policy的框架 [15]。SR Policy支持 描述SR-MPLS和SRv6的业务路径策略。本节介绍如何利用SR Policy实 现SRv6 TE，包括SR Policy模型的定义、控制平面如何算路、数据平面 如何转发，以及故障场景下的保护措施等。在本节中，将实现SRv6 TE的SR Policy简称为SRv6 Policy。

SRv6 Policy模型

如下图所示，SRv6 Policy模型包含如下要素。

Key值：SRv6 Policy使用以下三元组作为Key，全局唯一标识一个SRv6 Policy。

• Headend（头节点）：标识SRv6 Policy的头节点。头节点可以将流量导入一个SRv6 Policy中。
• Color（颜色）：标识指定头节点和目的节点的不同SRv6Policy，可与一系列业务属性相关联，例如低时延、高带宽等，可理解为业务需求模板ID。目前没有统一规定的编码规则，其值由管理者分配。例如，端到端时延小于10 ms的策略可分配Color的值为100。Color提供了一种业务和SRv6 Policy的关联机制。
• Endpoint（目的节点）：标识SRv6 Policy的目的地址。

当下发SRv6 Policy到头节点时，由于所有SRv6 Policy的头节点字段的取值均为表示自身的值，所以在头节点上通过<Color,Endpoint>即可唯一标识一个SRv6 Policy。在头节点上可以通过<Color,Endpoint>来引导流量进入SRv6 Policy。

Candidate Path：一个SRv6 Policy可能关联多个Candidate Path，每 个Candidate Path附带Preference（优先级）。存在多个Candidate Path时，SRv6 Policy选择优先级最高的Candidate Path作为主路径。Candidate Path是通过BGP SRv6 Policy/PCEP等协议向头节点发送SRv6 Policy可选路径的基础单元，不同的协议会下发不同的Candidate Path。

从图中可知，<Protocol-origin,Originator,Discriminator>是在SRv6 Policy内部唯一标识一条Candidate Path的标识，其中Protocol-origin描述Candidate Path通过何种协议/途径生成 ，Originator描述了生成该Candidate Path的节点，Discriminator则是在<Protocol-origin,Originator>空间下区分Candidate Path的ID。例如，某节点通过BGP发布了属于SRv6 Policy1的3个Candidate Path，这3个Candidate Path可以通过Discriminator来区分。

Segment List：Segment List标识通过SRv6 Policy向Endpoint发送流量的源路由路径。一个Candidate Path可以关联多个Segment List，通过Segment List附带的Weight（权重）属性来控制流量在多个SR路径中的负载比例，从而实现ECMP/UCMP（Unequal-Cost Multiple Path，非等值负载分担）。

此外，SRv6 Policy还可以分配Binding SID（BSID）。Binding SID也是Segment Routing的基础指令，它用于标识整个Candidate Path，提供隧道连接、流量引导等功能。报文如果携带Candidate Path对应的Binding SID，会被引导到对应的Candidate Path。Binding SID可以理解为业务调用网络功能，选择Candidate Path的接口。

如果我们把SRv6 Policy看成网络服务，那Binding SID就是访问这个服务的接口。所以，SRv6 Policy的这个设计是一个订阅发布模型，业务根据自身的需求来订阅网络服务，网络可以把服务接口提供给业务。Binding SID既然是接口，就要满足接口的原则。

• 独立性：任何业务都可以调用该接口，而不需要关注系统内部细节。SRv6 Policy把所有的细节都封装在内部，业务在使用SRv6 Policy的时候，只需要查找到这个接口即可。
• 可靠性：在接口已经发布的情况下，接口应该对契约负责。不管多少业务调用这个接口，SRv6 Policy需要保证契约里面承诺的服务，这就要求SRv6 Policy具备网络资源的弹性伸缩能力。
• 稳定性：接口需要不易变性，在SRv6 Policy生命周期内，不管网络拓扑发生变化，还是业务本身发生变化或路径发生变化，Binding SID都需要尽量维持不变。

SRv6 Policy算路

SRv6 Policy可以通过多种方式生成Candidate Path，主要包括静态指定路径、头节点算路和控制器算路。不同方式生成的Candidate Path可以通过Protocol-origin和Originator字段来区分。

1． 静态指定路径

静态指定路径是指通过CLI/NETCONF等方式人工规划，手动配置SRv6 Policy 。 如下图所示 ，静态配置显式路径（A4::45,A7::1,A6::1），并在SRv6 Policy中引用该显式路径。这样就通过静态配置的方式创建了SRv6 Policy的一个路径。静态配置SRv6 Policy时，必须配置Endpoint、Color以及Candidate Path的Preference和Segment List，且不允许配置重复的Preference。对于静态配置的SRv6 Policy，在Locator的静态段范围内配置BSID。

静态配置路径的方式无法自动响应网络拓扑的变化，当指定的链路或节点发生故障的时候，无法触发SRv6 Policy重路由，那会导致流量持续中断。因此在部署的时候，静态配置的SRv6 Policy一般需要规划两条不相交的路径，并使用连通性检测机制来检查路径的可达性。当某条路径发生故障的时候，可以快速切换到其他路径，以保证网络可靠性。

2． 头节点算路

如下图所示，头节点算路和RSVP-TE类似。首先头节点利用IGP携带的TE信息和IGP链路状态信息组成TEDB，然后基于CSPF算法，按照带宽、时延、SRLG（Shared Risk Link Group，共享风险链路组）和不相交路径等约束计算满足条件的路径，并安装相应的SRv6 Policy指导转发。

头节点算路有以下限制：由于头节点没有跨域的拓扑，所以只能计算单个IGP域的路径，无法支持跨域的路径计算；由于SR中间节点不维护连接状态，所以无法支持资源占用，也不支持预留带宽算路。

3． 控制器算路

如下图所示，控制器通过BGP-LS等收集网络拓扑、TE信息以及SRv6信息，并根据业务需求集中计算路径，然后通过BGP/PCEP等协议将SRv6 Policy下发到头节点。控制器算路支持全局调优、资源预留和端到端跨域。

控制器最初下发SRv6 Policy时不携带BSID，转发器接收SRv6 Policy后主动在Locator的动态段范围内随机分配一个BSID，然后通过BGP-LS上报SRv6 Policy状态时携带BSID。这样控制器就能感知SRv6 Policy的BSID，利用BSID编排SRv6路径。

不同算路方式的功能对比如下表所示。

总体而言，由于控制器能够通过BGP-LS获取到全局的拓扑和TE等信息，所以基于控制器计算SRv6 Policy可以实现全局流量的调优，而静态指定路径和头节点算路方式只能实现IGP域内的最优路径计算。此外，控制器算路还可以支持带宽预留和优先级抢占，能够更好地支持TE。

SRv6 Policy引流

将SRv6 Policy部署在头节点之后，还需要完成引流工作，将流量引导到SRv6 Policy中。目前有Binding SID和Color匹配这两大类引流方式。

1. Binding SID引流

如下图所示，节点A创建SRv6 Policy，该SRv6 Policy的BindingSID为B1::100,Segment List为<B3::4,B4::6,B5::55>。上游节点向节点A发送了一个报文，报文目的地址为B1::100。节点A收到该报文，发现报文的目的地址是本地SRv6 Policy的Binding SID。节点A处理Binding SID，具体流程如下。

1. 将原始报文的SRH的SL值减1，指向下一个SID。
2. 为报文封装一个新的IPv6报文头，目的地址为对应SRv6 Policy的第一个SID B3::4，源地址为本地的一个接口地址。
3. 然后封装SRH，携带该Binding SID对应的SRv6 Policy的Segment List。
4. 更新对应的其他字段，然后查表转发报文。

通过使用Binding SID可以引入SRv6 Policy的流量，这种方式一般常用在隧道拼接、跨域路径拼接等场景，可以很好地减小SRv6 SID栈深；同时也可以显著地降低不同网络域之间的耦合程度，某个网络域内转发路径的变化也不需要扩散到其他网络域。

2. Color引流

因为SRv6 Policy引入了Color，而Color可以作为BGP路由携带的扩展团体属性，因此在将业务引流到SRv6 Policy时，可以精确到逐条路由的控制粒度。

Color是SRv6 Policy非常重要的属性，它是业务和隧道的锚点。如下图所示，Color能够关联一个或多个业务需求模板，例如低时延、带宽以及亲和属性等。SRv6 Policy根据Color进行算路。此外，业务也使用Color定义网络连接的需求。通过匹配业务和SRv6 Policy的Color，就能实现自动引流。在部署业务的时候，不依赖隧道的定义，只需要定义业务的需求即可，这样实现了业务部署和隧道部署的解耦。

如下图所示，通过Color进行引流的具体流程介绍如下。

1. 控制器通过BGP或其他方式下发SRv6 Policy，Color为123。
2. 节点E通过路由策略设置路由的Color扩展团体属性值为123，并在发布路由时携带该属性。
3. 节点A收到路由以后，会进行路由迭代。使用BGP路由的原始下一跳匹配SRv6 Policy的Endpoint，使用BGP路由的Color属性匹配SRv6 Policy的Color，这样一条BGP路由就能通过SRv6 Policy的Key值<Color, Endpoint>匹配到一个SRv6 Policy。路由迭代成功之后，节点A将路由和关联的SRv6 Policy安装到FIB（Forwarding Information Base，转发信息库）。

通过以上方法，当流量到达节点A时，根据目的地址查询路由，得到隧道的出接口为SRv6 Policy的隧道接口，然后封装SRv6报文并转发，实现Color自动引流到SRv6 Policy。

这种引流模式一般可以通过路由策略控制BGP路由携带的Color值，这叫作着色。着色策略十分灵活，可以根据需求修改尾节点、头节点甚至RR反射器的Color的值。

3. DSCP引流

除了Binding SID引流和Color引流，还可以通过IP报文头中封装的DSCP（Differentiated Services Code Point，区分服务码点）值来引流，这种方式可以对命中同一个路由但不同来源的业务进一步细分。例如，可以在头节点将多个SRv6 Policy组成一个Group（组），并在Group内指定每个SRv6 Policy和DSCP值的映射关系，然后将业务绑定到指定的Group。这样当头节点收到业务流量时，可以根据IP报文头中携带的DSCP值，在对应的Group中找到对应的SRv6 Policy，从而完成引流。这种引流方式要求在源头区分业务，并且指定不同的DSCP值。

在一些场景下希望结合以上两种引流方式（既要匹配业务的下一跳 +Color，又要区分DSCP），可以为Group引入Color，将Group的标识也定义为<Color,Endpoint>。通过引流策略指定，一条业务路由根据下一跳和Color属性不再去匹配一个SRv6 Policy，而是匹配一个Group，同时转发平面再根据收到的业务流量的DSCP值，在该Group内匹配对应的SRv6 Policy。

SRv6 Policy数据转发

前面介绍了如何计算SRv6 Policy以及如何向SRv6 Policy引流，下面以L3VPNv4为例，介绍SRv6 Policy的数据转发过程。具体如下图所示。

1. 控制器向头节点PE1下发SRv6 Policy，Color为123，Endpoint为PE2的地址2001:db8::1，只有一个Candidate Path，且Candidate Path也只包含一个Segment List <2::1,3::1,4::1>。
2. 尾节点PE2向PE1发布BGP VPNv4路由10.2.2.2/32，BGP路由的下一跳是PE2的地址2001:db8::1/128，Color为123。
3. PE1在接收到BGP路由以后，利用路由的Color和下一跳迭代到SRv6 Policy。
4. PE1接收到CE1发送的普通单播报文后，查找VPN实例路由表，该路由迭代到了一个SRv6 Policy。PE1为报文插入SRH信息，封装SRv6 Policy的Segment List，同时封装IPv6报文头信息，并查表转发。
5. P1和P2节点根据SRH信息逐跳转发。
6. 报文到达PE2之后，PE2使用报文的IPv6目的地址4::1查找本地SID表，命中了End SID，所以PE2将报文的SL值减1，将IPv6 DA更新 为VPN SID 4::100。
7. PE2使用VPN SID 4::100查找本地SID表，命中了End.DT4 SID，PE2执行End.DT4 SID的指令，解封装报文，去掉SRH信息和IPv6报文头，使用内层报文的目的地址查找VPN SID 4::100对应的VPN实例路由表，然后将报文转发给CE2。

SRv6 Policy故障检测

前文介绍了正常情况下SRv6 Policy的数据转发，下面介绍在发生故障时SRv6 Policy的故障检测机制。

1. SBFD for SRv6 Policy

与RSVP-TE不同，SR不会在路由设备之间建立信令连接，所以只要在头节点下发相应的配置，就会成功建立SRv6 Policy，且除了撤销SRv6 Policy以外，SRv6 Policy不会出现状态变为Down的情况。所以SRv6 Policy故障检测需要依靠其他手段，例如通过SBFD（Seamless Bidirectional Forwarding Detection，无缝双向转发检测）快速检测故障并切换到备份路径。SBFD是一种无缝双向转发检测技术，它提供了一 种简化的机制，可以实现灵活的路径检测。SBFD for SRv6 Policy是一种端到端的快速检测机制，用于快速检测SRv6 Policy所经过的链路中所发生的故障。

SBFD for SRv6 Policy的检测过程如下图所示。

1. 头节点PE1使能SBFD检测SRv6 Policy，并配置SBFD的目的地址和描述符。
2. PE1对外发送SBFD报文，SBFD报文封装SRv6 Policy对应的SID栈。
3. 尾节点PE2收到SBFD报文后，通过IPv6链路，按照最短路径发送SBFD应答报文。
4. PE1如果收到SBFD应答报文，则认为SRv6 Policy的Segment List正常，否则会认为Segment List发生故障。如果一个候选路径下所有Segment List都发生故障，则SBFD触发切换候选路径。

2． 头节点故障感知

如果头节点不支持SBFD检测或某些场景要求不配置SBFD检测，则当SRv6 Policy的Candidate Path发生故障时，头节点不能快速感知故障，只能通过控制器感知拓扑变化的收敛来更新SRv6 Policy。

如果控制器或与控制器连接的通道发生故障，头节点就无法感知故障切换路径，可能会导致流量丢失。因此，为了提升发生故障时切换流量的速度，推出了头节点故障感知功能。通过此功能，头节点能够在Segment List的路径发生故障时，触发设备将Segment List置为Down状态，进而触发SRv6 Policy内部切换路径或触发业务切换。

头节点故障感知功能的主要实现原理是要求头节点能够收集网络 的拓扑信息，然后根据Segment List中的SRv6 SID在拓扑中是否存在及路由是否可达，来校验Segment List是否有效。

当Segment List中的所有SRv6 SID都在拓扑中存在并且路由也可达时，将Segment List的状态设置为Up。只要Segment List中有一个SRv6 SID在拓扑中不存在或者路由不可达，设备就将Segment List的状态置为Down，并删除Segment List表项。

当Segment List发生故障时，设备根据SRv6 Policy及Candidate Path的情况进行如下处理。

• 如果SRv6 Policy优选的Candidate Path有多个Segment List进行负载分担，其中一个Segment List发生故障，将发生故障的Segment List从负载分担列表中删除，将流量分担到其他的Segment List。
• 如果SRv6 Policy优选的Candidate Path中所有的Segment List都发生故障，SRv6 Policy有备Candidate Path，则将流量切换到备Candidate Path。
• 如果SRv6 Policy下主备Candidate Path都发生故障，则通告SRv6 Policy状态为Down，触发业务切换。
• 由于头节点需要对SRv6 SID状态和路由状态进行检测，所以头节点需要获取IGP域的所有SRv6 SID和路由信息。然而，当Segment List路径中存在Binding SID时，由于Binding SID不通过IGP泛洪，所以路径校验会失败，因此，在部署了Binding SID的场景中不能配置头节点故障感知功能。

SRv6 Policy路径切换

采用上述的SBFD和头节点故障感知等技术可以检测Segment List以及Candidate Path的可靠性。当 SRv6 Policy 的所有Candidate Path和Segment List都发生故障时，需要进行SRv6 Policy的保护倒换。下面以一个例子介绍SRv6 Policy的保护机制。

目前在VPN双归场景下，如果一个VPN节点发生故障，所有到达该节点的SRv6 Policy都会发生故障，此时需要切换到指向另一个VPN节点的SRv6 Policy。

如下面2个图所示，SRv6 Policy1的Headend是PE1，Endpoint是PE2。另外SRv6 Policy2的 Headend是PE1，Endpoint是PE3。SRv6 Policy1和SRv6 Policy2可以形成VPN FRR，即PE2和PE3分别互为VPN备份节点。

SRv6 Policy1的主路径和备份路径之间部署了HSB保护。Segment List1指定的路径包含P1、P2、PE2的End SID，并且节点上部署了TI-LFA等保护机制。

在图中，相关故障切换过程如下。

1. 当P1和P2之间的链路发生故障时，P1、P2上的TI-LFA局部保护生效。PE1上对应Segment List1的SBFD如果在局部保护生效之前就检测到故障，则SBFD联动将Segment List1置为Down状态，节点切换到SRv6 Policy1的负载分担路径Segment List2。
2. 当P2发生故障且局部保护未生效时，PE1通过SBFD感知到P2发生故障，将Segment List1置为Down状态，SRv6 Policy1切换到备份路径Segment List2。
3. 当PE2发生故障时，通过SBFD可以探测到SRv6 Policy1的所有Candidate Path都不可用，将SRv6 Policy1置为Down状态，同时触发VPN FRR切换到SRv6 Policy2。另外，如果部署了尾节点保护，数据流量也可以通过PE3绕行到CE2。