SRv6可编程技术-SRv6 Policy
作者简介：
胡志波：华为SR与IGP高级协议专家。负责华为的SR与IGP协议规划和创新工作。目前主要从事SR/SRv6协议以及5G切片相关技术的研究。自2017年起积极参与IETF标准创新工作，主导和参与SRv6可靠性保护，SRv6 Yang, 5G 切片，IGP协议等相关标准。致力于通过SRv6协议创新支撑网络向5G，云化的演进。
李振斌：华为首席协议专家/IETF互联网架构委员会（IAB）委员。负责华为的IP协议研究和标准推动工作。自2009年起积极参与IETF标准创新工作，主导和参与了大量IETF RFC/草案。在过去六年内持续推动了SDN演进的BGP/PCEP/Netconf/YANG的协议创新和标准化，当前研究的重点包括SRv6、网络智能、Telemetry、5G承载等。2019年当选IETF互联网架构委员会（IAB）委员，承担2019 - 2021年的互联网架构管理工作。
随着企业信息化建设的深入、移动互联网和云数据中心的发展，社会走向全面数字化和智能化。传统只能提供有限电信级连接的网络已经无法满足以云为中心的业务对网络海量的、随时随地可能发起的数据连接的要求。未来网络应当满足以下要求：
信息自动化、IoT等业务发展，要求网络的连接数量可以无限扩展。除了带宽，网络中应尽量减少其他与业务相关的限制。未来网络应当在带宽能够满足的情况下，可以任意发展业务，减少业务对网络能力的感知。
传统的电信网络严格限制了业务接入点，在全面数字化的时代，业务接入点不可控。网络需要满足业务任意点接入，跨越任意区域连接的能力。
传统的电信网络为用户提供了无差异的连接服务，导致对网络质量要求不高的业务获得了过高的服务，造成资源浪费，而一些有特别质量要求的业务却难以保证。未来的网络应当由业务根据需求选择网络质量，既节省资源，又保障业务。
网络编程的概念来自于计算机编程。在计算机编程中，人类可以将自己的意图翻译成计算机可以理解的一系列指令，计算机通过执行指令来完成工作，满足人类的各种需求。类似地，如果网络也能像计算机一样，将网络承载的业务的意图翻译成沿途网络设备的一系列转发指令，就可以实现网络编程，满足业务的定制化需求。
SRv6就是基于如上考虑，将网络功能指令化，通过一个128比特的指令来表达网络功能。在SRv6网络里，业务需求可以被翻译成有序的指令列表，由沿途的网络设备去执行，达到网络业务的灵活编排和按需定制。
图1.SRv6 Policy基本原理
SRv6 Policy利用Segment Routing的源路由机制，通过在头结点封装一个有序的指令列表来指导报文穿越网络。SRv6利用IPv6地址128 bit的可编程能力，丰富了SRv6指令表达的网络功能范畴，除了用于标示转发路径的指令外，还能标示VAS，例如：防火墙，应用加速等网络功能，或者用户网关等功能。除此之外，SRv6还有着非常强大的扩展性，如果要支持一个新的网络功能，只需要定义一个新的指令即可，而不需要改变协议的机制或部署。这大大缩短了网络创新业务的交付周期。所以说，SRv6 Policy可以实现业务的端到端需求，是实现SRv6网络编程主要的机制。
表2-1 SRv6 Policy和传统隧道的区别
目标：TE Tunnel面向的是两个网元之间的一个连接。是站在网络的角度定义的，它还是网络基础设施范畴。SRv6 Policy面向的是特定业务的体验，交付的是服务。对基础设施而言，不承诺用户使用这个基础设施的体验，只满足交付这个设施时定义的规格即可，例如：带宽。SRv6 Policy交付的是服务，对业务最终体验负责。
功能：TE Tunnel的功能是流量工程，优化网络资源和提升网络质量。SRv6 Policy的功能是满足业务的端到端需求，连接，SLA,可靠性，安全，SFC。
部署：传统TE Tunnel以静态人工规划为主，SRv6 Policy根据业务动态，按需自动化创建为主。
变化：TE Tunnel只需要关注网络本身变化，例如：网络故障切换等。而SRv6 Policy需要响应各种变化，除了网络本身的变化，还需要响应包括用户业务量的变化，用户体验变化等。
数量：SRv6 Policy的目标是支持百万级的连接数量，所以，SRv6 Policy的设计原则是轻量化，尽量减少SRv6 Policy对设备资源的占用，得益于Segment Routing源路由中间节点无状态，SRv6 Policy只需要在头节点维护连接状态，这使得网络状态数量从N2级下降的N。同时，对了减少对资源占用的特性依赖，例如：BFD，SRv6 Policy支持端到端本地保护能力。还有，提升自动化能力，减少单SRv6 Policy的运维工作量，使得维护百万级的SRv6 Policy成为可能。
自动化：除了减少部署，运维工作量，SRv6 Policy的自动化还体现在自动响应网络变化，业务需求变化，用户体验变化等。
图2.SRv6 Policy模型
SRv6 Policy模型包含如下要素：
（1）Key值：SRv6 Policy使用如下三元组作为Key，全局唯一标识一个SRv6 Policy：
头节点（Headend）：标识SRv6 Policy的头节点。Headend可以将流量导入一个SRv6 Policy中。
颜色（Color）：标识SRv6 Policy的ID，可与一系列业务属性相关联，比如低时延、高带宽等，可理解为业务需求模板ID。目前没有显示编码规则，其值由管理者分配。比如，端到端时延小于10毫秒的策略可分配Color为100。
目的节点（ Endpoint）：标识SRv6 Policy的目的地址。
当SRv6 Policy下发到头节点时，由于所有SRv6 Policy的Headend字段均为此节点，所以在头节点上通过即可唯一标识一个SRv6 Policy。所以在头节点上通过来引导流量进入SRv6 Policy。
前面我们讲过，SRv6 Policy是面向业务体验设计的，Color描述的就是满足业务体验对网络的要求：例如：时延，带宽，可靠性等。SRv6 Policy的这个设计使得SRv6 Policy可以直接和业务交互，省略了从业务需求到网络语言再到网络对象的翻译过程。
（2）Candidate Path：一个SRv6 Policy可能关联多个Candidate Path，每个Candidate Path附带优先级（Preference）。存在多个Candidate Path时，SRv6 Policy选择优先级最高的Candidate Path作为主路径。Candidate path是通过BGP SR Policy/PCEP等协议向头端发送SR Policy可选路径的基础单元，不同的协议会下发不同的Candidate path。
从图2可知，是在SRv6 Policy内部唯一标识一条Candidate Path的标识，其中Protocol-Origin描述Candidate Path通过什么协议/途径生成，originator描述了生成该Candidate path的节点，discriminator则是在空间下区分Candidate path的ID。比如某节点通过BGP发布了属于SRv6 Policy的3个Candidate Path，这3个Candidate Path可以通过discriminator来区分。
SRv6 Policy支持多种算路方式：PCE集中算路，头节点算路，手工规划路径，FlexAlgo算路，多Candidate Path的设计可以对业务屏蔽这些细节，业务不需要关心具体的算路方式，只需要关注业务需求本身，这些不同的算路方式形成的路径通过多个Candidate Path都封装在SRv6 Policy内部。而传统TE Tunnel不同算路方式则采用不同的TE tunnel承载，业务需要看到不同的TE tunnel，了解这些TE tunnel的实现细节，才能匹配到响应的隧道。同时，Candidate Path也用于支持主备冗余路径，逃生路径，SRv6 Policy把这些保护，逃生路径也都封装在SRv6 Policy内部，业务也不需要看到这些细节。
（3）Segment List：Segment List标识通过SRv6 Policy向Endpoint发送流量的源路由路径。一个Candidate Path可以关联多个Segment List，通过Segment List附带的权重属性（Weight）来控制流量在多个SR路径中的负载比例，从而实现ECMP/UCMP。
多SegmentList的设计可以提升网络弹性，满足业务实时变化的需求，实现网络资源的动态弹性扩展。例如：某类业务需要将带宽从2G增加到5G，SRv6 Policy可以再计算一条3G带宽的路径。同时UCMP也可以更方便的实现对网络资源的优化，如果某条SegmentList路径的流量出现了过载，可以调整SegnemtList的权重以降低该路径的负载。
（4）Binding SID：Binding SID（BSID）也是Segment Routing的基础指令，它用于标识整个Candidate path，提供隧道连接，流量引导等功能。报文如果携带Candidate path对应的BSID，会被引导到对应的Candidate path。
如果我们把SRv6 Policy看成是一个网络服务，那Binding Sid就是访问这个服务的接口。所以，SRv6 Policy的这个设计是一个订阅发布模型，业务根据自身的需求来订阅网络服务，网络可以把他提供的连接服务的接口提供给业务。那Binding Sid既然是接口，它就要满足接口的原则：
平台独立性：任何业务都可以调用该接口，而不需要关注系统内部实现。前面我们已经提到，SRv6 Policy把所有的实现细节都封装在内部，业务在使用SRv6 Policy的时候，只需要看到这个接口就可以。
系统可靠性：在接口已经发布的情况下，接口应该对契约负责。这里其实分两种情况，如果该接口是为特定业务服务的，那SRv6 Policy就需要保证，不管这个业务本身如何变化，SRv6 Policy都需要保证契约里面承诺的服务，这个契约就是Color里面定义的内容。如果SRv6 Policy是为广泛业务服务的，那它就要保证，不管多少业务调用这个接口，它也要保证契约里面承诺的服务，这就要求SRv6 Policy具备网络资源的弹性伸缩能力。
稳定性：接口需要具备不易变性，Bsid需要维持在SRv6 Policy生命周期内维持不变，不管网络拓扑的变化，还是业务本身的变化，路径变化，SRv6 Policy都需要维持Bsid尽量不变。
引流意味着SRv6 Policy对业务提供服务的方式，前面章节中我们介绍了SRv6 Policy几种访问接口：Binding Sid，Endpoint + Color。不同的接口提供多种引流方式，以适用于不同的业务场景：
Binding SID引流
图3.Binding SID引流
Binding SID引流是一种数据面引流方式，用于业务头结点和SRv6 Policy头结点不是同一个结点的场景。例如：跨管理域提供SRv6 Policy连接服务，或者SRv6 Policy作为端到端Path的一个子Path场景。
如上图所示，结点A和结点B要穿越一个第三方网络，希望第三方网络提供一个低时延的连接服务，我们可以在第三方网络的边缘结点C创建一个低时延的SRv6 Policy，其Binding Sid为B1::B100，结点A需要使用该连接服务的时候，只需要将Binding Sid B1::B100插入到结点A发起的报文中的SegmentList即可。报文转发到结点C的时候，结点C执行End.B6.Insert指令，会将结点C的SRv6 Policy的路径插入一个新的扩展头，引导报文走低时延路径。
这种场景使用Binding Sid的好处是：
网络以透明的方式对外提供连接服务，可以在不体现网络内部路径细节的情况下对外提供连接服务。
隔离两个网络的变化，当网络低时延路径发生变化的时候，访问该连接服务的网络设备不用感知。
Color引流
因为SRv6 Policy引入了Color，而Color可以作为BGP路由的扩展团体属性携带，因此在将业务引流到SRv6 Policy时，可以精确到逐条路由的控制粒度。
Color是SRv6 Policy非常重要的属性，它是业务和隧道的锚点。如图3所示，Color能够关联一个或多个业务需求模板，例如：低时延，带宽和亲和属性等。SRv6 Policy根据Color进行算路。另一方面，业务也使用Color定义网络连接的需求。这样，通过业务和SRv6 Policy的Color进行匹配，就能实现自动引流。这样，在部署业务的时候，不依赖关心隧道的定义，只需要定义业务的需求即可，这样实现了业务部署和隧道部署的解耦。
图4.SRv6 Policy引流示意图
如图4所示，通过Color进行引流的具体流程介绍如下：
控制器通过BGP或其他方式下发SRv6 Policy，Color为123。
节点E通过路由策略设置路由的Color扩展团体属性值为123，并在发布路由时携带该属性。
节点A收到路由以后，会进行路由迭代。迭代的过程是：使用BGP路由的原始下一跳匹配SRv6 Policy的Endpoint，使用BGP路由的Color属性匹配SRv6 Policy的Color，这样一条BGP路由就能通过SRv6 Policy的Key值匹配到一个SRv6 Policy。路由迭代成功之后，节点A将路由和关联的SRv6 Policy安装到FIB表。
图5.Color引流
通过以上方法，当流量到达节点A时，根据目的地址查询路由将得到隧道出接口为SRv6 Policy，然后执行对应的SRv6 Policy，进行SRv6报文封装并转发，实现Color自动引流到SRv6 Policy。
这种引流模式下一般可以通过路由策略控制BGP路由携带的Color值，叫做着色。着色策略十分灵活，不仅是尾节点，而且头节点甚至RR反射器，都可以根据需求修改Color的值。
DSCP引流
除了Binding SID和Color引流，还可以通过IP报文头中封装的DSCP值来引流，这种方式可以对命中同一个路由但不同来源的业务进一步细分。例如，可以在头节点将多个SRv6 Policy形成一个组（Group），并在Group内指定每个SRv6 Policy和DSCP值的映射关系，然后将业务绑定到指定的Group。这样当头节点收到业务流量时，可以根据IP报文头中携带的DSCP值在对应的Group中找到对应的SRv6 Policy，从而完成引流。这种引流方式要求在源头区分业务，并且指定不同的DSCP值。
在一些场景下，可能希望结合以上两种引流方式（即，既要匹配业务的下一跳 + Color，又要区分DSCP），那么可以为Group引入Color，将Group的标识也定义为。通过引流策略指定，一条业务路由根据下一跳和Color属性不再是去匹配一个SRv6 Policy，而是匹配一个Group，同时转发平面再根据收到的业务流量的DSCP值在该Group内匹配对应的SRv6 Policy。
Color only引流
图6.Color Only引流
某些场景，我们并不关心隧道目的地址，如上图，网络中部署了一个流量清洗中心，我们可以创建一个SRv6 Policy，目的地址为0::0，Color 123表示流量需要引导到清洗中心，SegmentList只需要指定清洗中心这一个结点即可，由于VPN Sid本身就具备路由能力，所以即使SRv6 Policy无法将报文引导到真正的目的地址，通过VPN Sid还是可以做到，这样做的好处是我们全网只需要创建一个SRv6 Policy，然后下发到所有边缘结点，然后将需要引导到清洗中心的流量引流到这个SRv6 Policy，就可以替代从任意源到任意目的地的SRv6 Policy。Color only引流优选匹配目的地址和Color都能匹配的SRv6 Policy，如果匹配不到，则只匹配Color。
SRv6 Policy的Candidate Path可以通过多种方式生成，主要包括静态指定路径，头节点算路和控制器算路三类。不同方式生成的Candidate Path可以通过Protocol-Origin字段来区分。以下展开介绍。
静态指定路径
静态指定路径是指通过CLI/Netconf等方式人工规划，手工配置SRv6 Policy, 通过静态配置的方式创建了SRv6 Policy的一个路径。静态配置SRv6 Policy时，Endpoint、Color、以及Candidate Path的Preference和Segment List等都是必须配置，且Preference不允许重复。对于静态配置的SRv6 Policy，Binding SID在Locator的静态段范围内配置。
静态配置路径的方式无法自动响应网络拓扑的变化，当指定的链路或节点故障的时候，无法触发SRv6 Policy重路由，会导致流量持续中断。因此在部署的时候，静态配置的SRv6 Policy一般需要规划两条不相交路径，并使用连通性检测机制来检查路径的可达性。当某条路径故障的时候，可以快速切换到其他路径，以保证网络可靠性。同时，为了保证手工配置的SegmentList不变，使用静态配置SRv6 Sid来保证持久化，以使得设备重启，倒换，邻居UP/Down等厂家Sid能维持不变。
头节点算路
如图8所示，头节点算路和RSVP-TE类似。首先头节点利用IGP携带的TE信息和IGP链路状态信息组成TEDB，然后基于CSPF算法按照带宽、时延、SRLG和不相交路径等约束计算满足条件的路径，并安装相应的SRv6 Policy指导转发。
图7.头节点算路
头节点算路有如下限制：
由于头节点没有跨域的拓扑，所以只能计算单个IGP域的路径，无法支持跨域的路径计算。
由于SR中间节点不维护连接状态，所以无法支持资源占用，也不支持预留带宽算路。
控制器算路
如图9所示，控制器通过BGP-LS等收集网络拓扑、TE信息以及SRv6信息，并根据业务需求集中进行路径计算，然后通过BGP/PCEP等协议将SRv6 Policy下发到头节点。控制器算路能够支持全局调优、资源预留和端到端跨域。
图8.控制器算路
对于控制器下发的SRv6 Policy，控制器最初下发SRv6 Policy时不携带Binding SID，路由器接收SRv6 Policy后主动在Locator的动态段范围内随机分配一个Binding SID，然后通过BGP-LS上报SRv6 Policy状态并携带Binding SID。这样控制器就能感知SRv6 Policy的Binding SID，利用Binding SID进行SRv6路径编排。
不同算路方式的功能对比如表3-1所示。
表3-1 不同算路方式的功能对比
总体而言，由于控制器能够通过BGP-LS获取到全局的拓扑和TE等信息，所以基于控制器计算SRv6 Policy可以实现全局的流量调优，而静态指定路径和头节点算路方式只能实现IGP域内的最优路径计算。此外，控制器算路还可以支持带宽预留和优先级抢占，能够更好的支持TE。
不同的算路方式形成的路径可以安装到同一个SRv6 Policy，以不同的Candidate Path体现，根据默认或人工指定的优先级，SRv6 Policy会在可用的Candidate Path里优选一个可用的，这种设计使得业务使用SRv6 Policy的时候，不需要关心算路方式这些细节，业务只需要关心自身对网络的需求即可，将算路，优选这些细节都封装在SRv6 Policy内部，简化业务和网络的交互。
图9.SRv6 Policy 流量工程
流量工程是SRv6 Policy应用场景之一。SRv6 Policy结合检测，Telemetry可以构成一套用于满足业务SLA的通用解决方案。以低时延场景为例：
使用Twamp检测链路时延，并通过IGP/BGP_LS通报给控制器。
控制器基于时延计算满足SLA要求的路径，并通过BGP SRv6 Policy将SRv6路径信息下发给头结点。
头结点将流量导入到SRv6 Policy，按照控制器计算的路径转发报文，以满足流量SLA要求。
使用Twamp检测SRv6端到端路径时延，并通过Telemetry上送给控制器，控制器实时监控路径时延是否满足SLA要求，当时延劣化的时候，控制器重新计算新路径，以保证时延路径可以满足SLA要求。
图10.SRv6 业务链
应对移动，固网的业务云化发展的趋势带来的业务链新诉求，各种业务链技术在研究和发展。其中SRv6技术对于SF设备要求更低（支持IPv6转发或者L2透传即可），具有更好的普适性。使用SRv6 业务链技术，我们可以实现一个融合的业务链。
在业务链场景中，SRv6 Policy被表征为一个业务功能的有序集，可以使指定的业务流按照指定的顺序依次经过指定的增值业务设备，以便于业务流量获取一种或多种增值服务。
相比传统SFC技术（PBR/NSH），SRv6 SFC有如下优势：
跨站点业务链：使用SRv6 SFC Metadata技术，支持流分类器和VAS异地部署。大大提升VAS部署灵活性，降低部署成本。
开放生态：基于linux SRv6构建开放VAS生态，大大降低VAS厂商集成难度，消除设备厂商锁定。
业务快速开通：SRv6 VAS模式，业务开通分类器单节点部署，中间节点无感知。
SRv6 Policy是实现SRv6网络可编程的关键技术。随着5G和云时代的加速到来，新业务给运营商带来了全新的机会窗，除了满足用户的连通需求外，提供极致的用户体验是网络要面临的一个新的挑战。SRv6 Policy融合IP本身海量连接的功能，同时又提供网络可控的能力以及可扩展的网络编程能力，将会得到越来越广泛的应用。