SR与LDP互操作研究

何晓明 杨广铭 刘志华

【摘  要】对SR与LDP两种标签交换技术在同一网络中共存及SR与LDP互操作性进行了详细的原理性分析和实验验证。并结合运营商网络的三种典型应用场景深入探讨了SR与LDP互操作，对传统IP/MPLS网络中引入SR技术具有较好的指导意义。

【关键词】分段路由;标签分发协议;互操作;SR隧道和LDP隧道无缝对接

1   引言

多协议标签交换（MPLS， Multi-Protocol Label Switching）技术因其具有端到端面向连接的特点，目前已广泛应用于运营商的IP网络基础设施，用于提供二层/三层VPN服务、QoS、快速重路由（FRR， Fast Reroute）以及流量工程。然而，传统MPLS网络基于标签分发协议（LDP， Label Distribution Protocol），这种复杂的控制协议带来网络运维复杂性的同时，LDP与内部网关协议（IGP， Interior Gateway Protocol）的同步问题也增加了网络部署的难度。基于流量工程扩展的资源预留协议（RSVP-TE， Resource Reservation Protocol-Traffic Engineering）在实现全网流量工程时需要网络中间节点维护每流的状态信息，存在网络扩展性问题，实际网络中很少部署。

近年来，一种基于源路由网络（SPRING， Source Packet Routing in Networking）的分段路由（SR， Segment Routing）技术引起了网络界的广泛关注，并成为业界研究的热点。SR只需要通过对IGP和BGP进行协议扩展，进而实现段标签的分发，并在网络节点中维护段标签的转发信息表。边缘入口节点为报文流维护策略状态信息，无需中间节点维护每报文流的策略状态信息，即可实现IP报文按指定路径在一个IGP域内甚至跨域的端到端转发，极大地简化了网络设备的复杂性。分段路由是对MPLS技术的继承和发展，并能支持同现有网络基础设施的互操作和平滑演进，在实现网络虚拟化（如二层/三层VPN实现）、网络节点及链路保护、负载均衡和流量工程等方面具有独特优势。分段路由技术产生的初衷并不是为了取代LDP，而是为了弥补现有IP/MPLS技术的不足。

当前，IP RAN网络广泛应用于全球主流运营商移动网络的3G/4G业务承载。IP RAN基于IP/MPLS技术提供二层/三层VPN、QoS、业务保护等服务。由于构建IP RAN的网元数量巨大，并且多种网络技术的叠加增加了网络控制的复杂度，使得网络运维压力日益凸显。随着5G商用临近，5G承载网需要满足“增强移动带宽（eMBB）、超可靠低时延通信（uRLLC）、大规模机器类通信（mMTC）”等多业务场景的差异化承载，这对承载网功能和性能以及运维管理提出了更高要求。IP RAN需要在能力方面有所提升以适应5G承载需求。在IP RAN中引入SR技术也成为业界研究的热点。

鉴于传统MPLS网络基础设施已在运营商网络中广泛部署，并仍将发挥重要作用。SR作为一种可替代LDP的标签交换新技术还处于不断完善和发展的过程中，可以预计SR与LDP将会在网络中长期共存。本文对SR与LDP在网络中共存及其互操作进行技术分析，并结合运营商网络实际应用场景，试图从LDP Tunnel保护、LDP Tunnel向SR Tunnel迁移、LDP Tunnel与SR Tunnel跨域互连等三个方面对SR与LDP的互操作进行深入探讨。

2   SR与LDP共存分析

基于LDP的MPLS技术提供的VPN服务在运营商网络中得到了广泛部署，同样，SR也可用于实现VPN。为便于问题描述，现以图1为例分析SR与LDP在网络中的共存，互为独立地为各自客户提供VPN服务。

假设运营商为银行客户提供PE1<->PE3的三层VPN服务，而为保险客户提供PE2<->PE4的三层VPN服务。运营商想为PE1<->PE3之间提供基于LDP的Tunnel，为PE2<->PE4之间提供基于SR的Tunnel。

为达成这个目的，可对图1中PE1、PE2、PE3、PE4、P1、P2、P3做如下数据配置：

PE1、PE2、PE3、PE4的loopback地址分别配置为192.0.2.201/32、192.0.2.202/32、192.0.2.203/32、192.0.2.204/32。PE1與PE3之间、PE2与PE4之间分别建立MP-iBGP会话。同时，PE在MP-BGP中通告各自的VPN路由时设置next-hop为各自的loopback地址，如PE1通告银行客户路由时设置next-hop为192.0.2.201/32。

P1、P2、P3的loopback地址分别配置为192.0.2.1/32、192.0.2.2/32、192.0.2.3/32。

为PE2、P1、P2、P3、PE4的loopback地址分别绑定全局唯一的Node-SID：202、101、102、103、204。网络设备在通告各自loopback地址与Node-SID绑定关系时可配置为次末跳弹出机制。

配置PE1、P1、P2、P3、PE3为LDP使能，配置PE2、P1、P2、P3、PE4为SR使能。

上述配置完成后，PE之间开始交换客户VPN路由。

假设PE3向PE1发送的VPN路由的next-hop地址为192.0.2.203，携带的VPN标签为10001。同时，PE1收到来自P1的关于FEC为192.0.2.203的LDP标签绑定（假设为1037），P1收到来自P2的关于FEC为192.0.2.203的LDP标签绑定（假设为2048）。同样，P2和P3都会收到来自下游节点关于FEC为192.0.2.203的LDP标签绑定。当PE1收到发往PE3的客户流量时，PE1对发送到PE3的客户流量报文进行2层标签封装：顶层标签为1037，底层标签为10001，然后转发到P1。P1对收到的PE1的VPN客户流量报文进行顶层标签交换为2048，然后转发给P2。同样，P2和P3对收到的VPN客户报文进行顶层标签交换，然后转发给下游节点。最终，该VPN客户报文转发给PE3。

又假设PE4向PE2发送的VPN路由的next-hop地址为192.0.2.204，携带的VPN标签为10002。同时，PE4的loopback地址为192.0.2.204，绑定的Node-SID（204）通过IGP扩展向全网发布，这时PE2、P1、P2、P3的转发表（FIB）都安装了SID为204的转发信息。当PE2收到发往PE4的客户流量时，PE2對发送到PE4的客户流量报文进行2层标签封装：顶层标签为204，底层标签为10002，然后转发到P1。P1对收到的PE2的VPN客户流量报文进行顶层标签交换为204，然后转发给P2。同样，P2和P3对收到的VPN客户报文进行顶层标签交换，然后转发给下游节点。最终，该VPN客户报文转发给PE4。

根据上述分析，发现两种模式的MPLS Tunnel在同一个网络和设备中可以和谐共存。对于同一个Prefix，网络设备只需同时保存基于LDP和基于SR的标签转发条目。以P1为例，PE3的loopback地址192.0.2.203，通过LDP分发得到的标签转发条目：入标签为1037，出标签为2048，下一跳为P2;通过IGP扩展分发得到的标签转发条目：入标签为203，出标签为203，下一跳为P2。

为了评估设备同时开启LDP和SR时的转发性能，测试了华为、思科的多款路由设备。测试结果表明同时开启LDP和SR时设备转发性能同只开启任一项特性时的转发性能相当。查看设备转发表发现，对于同一个Prefix，测试设备的标签转发表（LFIB）同时生成了LDP和SR两个转发条目，跟上述SR与LDP共存的原理分析一致。由于转发表查找匹配基于硬件TCAM芯片，因此对设备的转发性能基本没有影响。

3   SR与LDP互操作分析

当前，基于LDP的MPLS作为一种非常成熟的技术已经在运营商网络中得到广泛部署。而SR技术因其具有简化网络优势所赋予的强大生命力，正逐渐被越来越多的运营商所接受。为保护现有网络投资，运营商希望通过现网升级，为网络注入新动能。因此，在同样一张网络中实现SR与LDP的互操作成为一种必然选择。为模拟真实场景，假设在一个提供端到端业务的运营商网络中，一部分新网络支持SR，而另一部分旧网络支持LDP。那么，怎样在这张新旧共存的网络中建立一个连续的MPLS Tunnel呢？

现以图2为例分析SR与LDP互操作过程：

假设P2、P3、P4、PE3、PE4支持LDP，PE1、PE2、P1、P2支持SR。P2充当网关设备，同时支持LDP和SR。显而易见，LDP/SR节点必须具备一种把LDP标签和SR标签进行拼接的机制。为简化分析，从MPLS Tunnel建立的两个方向分别讨论SR与LDP的互操作过程。

（1）从LDP到SR方向建立MPLS Tunnel

PE3收到来自PE1的客户VPN路由，下一跳为PE1。同时，PE3收到来自P4的关于PE1 loopback地址的LDP标签绑定信息，于是PE3把去往PE1的客户流量转发给P4。P4的标签转发表存在一个来自P3的关于PE1 loopback地址的LDP标签绑定信息，于是P4继续把该客户流量转发到P3。P3的标签转发表存在一个来自P2的关于PE1 loopback地址的LDP标签绑定信息，于是P3继续把该客户流量转发到P2。由于P1不支持LDP，P2没有来自P1的关于PE1 loopback地址的LDP标签绑定信息。然而，P2通过IGP扩展学到了关于PE1 loopback地址的SR标签绑定信息，因此，P2把关于PE1 loopback地址的本地分发的LDP标签同SR标签进行交换，并把标签修改后的客户流报文转发给P1。P1弹出关于PE1 loopback地址的SR标签（PE1支持次末跳弹出机制），最后转发到头端PE1。PE1接收到带业务标签的客户报文并对其进行处理。

这样，一条从LDP标签到SR标签的端到端MPLS Tunnel建立完成。

需要注意，从LDP域到SR域的隧道建立过程中，网络设备无需使能附加的信令或状态。然而，作为同时支持SR和LDP的网关节点P2必须为SR域学到的每个Prefix-SID或Node-SID创建LDP标签绑定关系，即为LDP域中每个FEC，把进入的LDP标签拼接成外出的SR标签。

（2）从SR到LDP方向建立MPLS Tunnel

为实现从SR到LDP方向MPLS Tunnel的建立，需引入分段路由映射服务器（Segment Routing Mapping Server，SRMS）。支持SR的SRMS通过IGP扩展，可代理不支持SR节点实现附着该节点的Prefix或Node对应的SID映射关系在本SR域内通告。SRMS可位于IGP泛洪区域的任何位置，并且在同一个IGP区域可存在多个SRMS（如实现冗余备份）。当多个SRMS通告同一Prefix与SID映射关系时必须保证通告信息的一致性。在图2中，可配置P1为SRMS，代理P3、P4、PE3、PE4通告Prefix与SID映射关系，分别假定为（P3， 103）、（P4， 104）、（PE3， 203）、（PE4， 204）。IGP区域内的SR节点在标签转发表安装对应SR标签的转发条目，这些Prefix与SID映射关系就像不支持SR节点本身通告一样。下面描述SR到LDP方向标签交换及转发过程。

例如，PE1通过P1代理学到PE3 loopback地址的SR标签并安装了SID为203的标签转发条目，下一跳为P1。当PE1通过MP-BGP收到来自PE3的客户路由时，由于PE1事先保存有节点PE3的SID转发条目，PE1为转发到P1的客户流报文封装2层标签：顶层标签为203，底层标签为客户VPN标签。P1根据对应SR标签转发条目修改外出标签203，并转发到P2。由于P2的下一跳P3不支持SR，然而，P2作为标签翻译网关，在标签转发表中保存有下一跳（P3）分发的关于PE3的loopback地址（FEC）对应的LDP标签（1037），因此，P2把SR标签203修改成外出的LDP标签1037，客户流报文转发给P3。因P4、P5、PE3都支持LDP，客户流报文经过标签交换和逐跳转发，最终，PE3接收到客户流报文并对底层业务标签进行处理。

这样，一条从SR标签到LDP标签的端到端MPLS Tunnel建立完成。

为了进一步验证上述分析的正确性，搭建了图2所示的网络拓扑，从MPLS Tunnel建立的两个方向分别验证了SR与LDP互操作过程。验证结果发现两个方向端到端MPLS Tunnel都能够成功建立，完全符合预期。

4   SR與LDP互操作应用场景

LDP和SR两种标签转发技术将长期共存，并互为补充。在运营商实际网络中，SR与LDP存在多种互操作的应用场景。本文试着从LDP Tunnel保护、LDP Tunnel向SR Tunnel迁移、LDP Tunnel与SR Tunnel跨域互连等三个应用场景对SR与LDP互操作进行探讨。

4.1  LDP Tunnel保护

为便于分析，以图3为例，假设除FG的链路代价为30外，其它所有的链路代价都为10，所有路由器都使能LDP。X、Y、Z充当PE路由器，为某个重要客户提供VPN业务，并要求提供50 ms的链路保护。同时，A、B、C、D、E、F、G也使能SR，但X、Y、Z还不具备支持SR的能力。

运营商希望为X->Y的VPN业务提供链路BA的50 ms保护倒换，为X->Z的VPN业务提供链路BE的50 ms保护倒换。

基于环路避免备份路径（Loop-Free Alternates， LFA）的IP FRR规范（RFC5286）给出了LFA存在的必要条件，表述如式（1）：

式（1）中，S表示计算节点，也即本地修复节点（PLR），N表示S的候选邻居节点，D表示目的节点。Distance （N， D）表示邻居节点N到目的节点D的最短距离，Distance （N， S）表示邻居节点N到修复节点S的最短距离，Distance （S， D）表示修复节点S到目的节点D的最短距离。对照图3所示的拓扑，当链路BA故障时，需要提供一条无环路的备份路径。根据式（1），B即为S节点，Y为目的节点D，C为B的唯一候选邻居节点N。因此无法为链路BA提供基于LFA的IP FRR路径。同样，也无法为链路BE提供基于LFA的IP FRR路径。

RFC7490提出了一种基本IP FRR的扩展机制，通过构建修复Tunnel方式（虚邻居）提供环路避免备份路径，以弥补RFC5286的不足，这种方式被称为远端环路避免的备份路径（Remote Loop-Free Alternate， RLFA）。根据RFC7490给出的方法，在图3拓扑中，存在节点D为被保护链路BA的PQ节点。因此，节点B到节点D的修复Tunnel可为链路BA提供一条RLFA。但是，对于链路BE故障的保护，不存在PQ节点，因此，当链路BE故障时，无法为X->Z的VPN业务提供RLFA。然而，这种情况仍可通过有保证的FRR方案提供链路保护。

假设为节点A、B、C、D、E、F、G配置的Node-SID分别为101、102、103、104、105、106、107。配置节点D作为SRMS，分别代理不支持SR的X、Y、Z向全网通告Node与SID映射关系（X， 201）、（Y， 202）、（Z， 203），同时，节点F为链路FG通告ADJ-ID：9001。

P节点A、B、C、D、E、F、G以及PE节点X、Y、Z都使能LDP，因此X->Y以及X->Z的VPN业务在正常情况下可以通过端到端的LDP Tunnel承载。

例如，节点B的基于LDP的标签装发表（LFIB）安装的出入标签条目如下：

入标签：到FEC Y的本地LDP标签;

出标签：节点A分发的FEC Y的LDP标签;

下一跳：节点A;

入标签：到FEC Z的本地LDP标签;

出标签：节点E分发的FEC Z的LDP标签;

下一跳：节点E。

当链路BA或BE故障时，端到端的LDP Tunnel不可用，此时需要为VPN业务提供RLFA或有保证的FRR备份路径。基于RLFA备份路径可依据RFC7490给出的方法自动计算得到，运营商只需为被保护的链路使能RLFA机制，便可触发备份路径的计算和安装。

运营商希望LDP Tunnel的SR保护能够满足以下4个方面的需求：

◆消除T-LDP会话;

◆提供有保证的FRR备份路径;

◆在稳定状态下，业务流仍能由LDP Tunnel承载;

◆SR仅按需在部分节点加以部署。

（1）消除T-LDP会话

根据上面的分析，节点D可为链路BA提供一条RLFA，因此，节点B为转发到Y的业务流安装的标签转发条目如下：

入标签：到FEC Y的本地LDP标签;

出标签：节点A分发的FEC Y的LDP标签;

备份出标签：节点Y的SID：202;

下一跳：节点A;

备份下一跳：经由节点C的修复Tunnel到节点D： {104}。

当链路BA发生故障时，节点B需要把到节点Y的业务流报文经由修复Tunnel转发到节点D，因此节点B把报文转发到下一跳节点C时需携带2层SR标签{104， 202}。节点C弹出外层标签104并转发到节点D，D根据SID： 202的下一跳转发到节点A，由于A的下一跳Y不支持SR，因此节点A把入标签202交换成外出的LDP标签（Implicit Null），然后转发到节点Y。

当IGP收敛后，节点B的标签转发条目重新生成：

入标签：到FEC Y的本地LDP标签;

出标签：节点C分发的FEC Y的LDP标签;

下一跳：节点C。

因此，在稳定状态下X->Y的VPN业务重新由LDP Tunnel承载。

从上述分析中可以看到，SR提供LDP Tunnel保护可以消除T-LDP会话，而且在稳定状态下的业务仍然可由LDP Tunnel承载。SR部署仅局限于图3中的P路由器。更为有利的是，无需网络手工配置T-LDP会话，简化操作维护，减少设备运行的信令和协议数量。

（2）提供有保证的FRR备份路径

对于链路BE故障的保护，由于扩展P空间和Q空间没有重合，因此，当链路BE故障时，无法为X->Z的VPN业务提供RLFA。但是，节点G属于链路BE的Q空间节点，如果能够指定一条从节点B->节点G的显式路径，当报文到达节点G时，仍可以基于最短路径到达目的节点Z，避免路径折返到故障链路BE。这种方法被称为有保证的FRR备份路径。

节点B->Z标签转发条目如下：

入标签：到FEC Z的本地LDP标签;

出标签：节点E分发的FEC Z的LDP标签;

备份出标签：节点Z的SID： 203;

下一跳：节点E;

备份下一跳：经由节点C的修复Tunnel到节点G： {106， 9001}。

当链路BE发生故障时，节点B需要把到节点Z的业务流报文经由修复Tunnel转发到节点G，因此节点B把报文转发到下一跳节点C时需携带3层SR标签{106， 9001， 203}。

当IGP收敛后，节点B的标签转发条目重新生成：

入标签：到FEC Z的本地LDP标签;

出标签：节点C分发的FEC Z的LDP标签;

下一跳：节点C。

因此，在稳定状态下X->Z的VPN业务重新由LDP Tunnel承载。

同样，基于SR提供有保证的FRR备份路径无需增加任何信令协议，也不需要在节点B和G之间建立T-LDP会话，简化网络操作。

4.2  业务从LDP Tunnel向SR Tunnel迁移

前面分析了SR和LDP可以在网络中和谐共存，不存在“非此即彼”的对立关系。因此，很容易实现业务从LDP Tunnel向SR Tunnel迁移。当网络设备同时使能LDP和SR时，由于在它们的标签转发表中同时维护着互为独立的两份标签转发条目，可以通过网管系统指定一部分业务（如新增业务）改为SR Tunnel承載，其它业务（如原有业务）仍由LDP Tunnel承载。并且可使用SR技术为LDP Tunnel提供业务保护，提高网络的生存性水平。

仍以图1为例，最初所有P和PE设备都使能LDP，所有业务都由LDP Tunnel承载。当全网设备都升级支持SR时，所有设备都维护互为独立的两份标签转发条目。通过网管可以配置全网设备默认选择业务报文优先使用LDP方式的MPLS封装。在某个时候，运营商希望PE2->任何其它PE的业务流换成基于SR的Tunnel承载，只需对PE2修改报文封装策略：优选SR标签转发。这样，PE2->任何其它PE的业务流报文按照SR标签转发，而除PE2外的所有业务流报文仍以LDP标签转发。经历一段时间的运行，运营商发现基于SR Tunnel承载业务是个不错的选择，决定把所有业务全部迁移到SR Tunnel上来。这时，需要修改所有边缘设备（如图1中PE1、PE2、PE3、PE4）的报文封装策略为SR标签封装。虽然全网业务实现了SR Tunnel承载，但LDP还在正常运行，运营商可以根据意愿实现业务承载方式平滑切换。当所有业务完成了向SR Tunnel承载迁移后，运营商也可以考虑全网关闭LDP，最终达到简化网络的目的。

4.3  LDP Tunnel与SR Tunnel跨域互连

在SR网络与LDP网络长期共存当中，可能出现这两种网络归属于不同运营商或不同AS的情形，需要实现SR网络与LDP网络的跨域互联互通，共同协作完成端到端的业务部署。一种典型的场景是MPLS L3VPN跨域，目前存在Option A/B/C三种MPLS L3VPN跨域实现方式，Option C扩展性好，更适合运营商开展大规模VPN业务的部署。现以Option C方式为例分析分属不同AS的两种网络跨域互连方法。图4给出跨域Option C方式示意图：

假设AS1网络使能SR，而AS2网络使能LDP，PE1<->PE2的L3VPN跨域采用Option C方式。PE1与PE2之间通过多跳MP-EBGP交换客户VPN路由，B1与B2之间通过EBGP扩展发布各自AS域内带公网标签的PE地址信息，并在AS内通过IBGP扩展传递到PE。如：B2向B1发布PE2的loopback地址，携带的公网标签为1000，B1在LFIB的出标签中保存该PE地址与标签的映射关系，同时为通告的PE地址生成另一个入标签（如标签2000）并向PE1传递，使下一跳为B1自身。于是PE1转发到PE2的MPLS VPN报文将携带3层标签：顶层标签为到B1的SR标签，中间层标签为PE2的公网标签2000，最底层标签为PE2的客户路由标签。当顶层SR标签经逐跳交换到达B1时弹出外层标签，此时中间层标签变成了顶层标签，B1查找LFIB，把入标签2000交换成出标签1000，由于顶层标签1000是由B2发布的，因此B1把携带2层标签的报文转发给B2，B2把标签1000替换成上游（P2）经由LDP分发的外出标签，经过逐跳LDP标签转发，这个MPLS VPN报文最终到达PE2。

从上述跨域路由交换以及标签转发过程来看，AS1网络采用SR标签交换，AS2网络采用LDP标签交换。AS1中的SR Tunnel与AS2中的LDP Tunnel实现无缝对接。两个自治域网络采用各自独立的标签转发方式，无需对网络边界设备进行任何适配和增强，即可实现良好的互操作。

5   结束语

本文全面深入地分析了SR与LDP两种标签交换技术在网络中共存及互操作的技术原理，并搭建实验环境验证了SR与LDP互操作技术的可实现性。同时结合运营商网络引入SR技术的三种典型应用场景深入探讨了SR与LDP互操作性。通过对SR与LDP互操作进行全面分析和探讨，发现SR可以代替LDP来实现MPLS隧道建立、无环路保护、FRR、流量工程等功能，网络设备无需支持传统MPLS网络中复杂的LDP及RSVP-TE协议，极大地降低了设备控制面要求。而且，SR与LDP具有良好的互操作性保证了SR Tunnel和LDP Tunnel无缝对接。通过在LDP网络中按需部署SR技术，可弥补LDP在流量工程、业务保护能力方面的不足，并且可以简化网络运维。可以展望，随着5G商用化进程的加速，在IP RAN引入SR技术，实现多种应用场景下SR与LDP互操作，能够满足5G场景下大带宽流量调度、低时延应用、泛在连接、网络分片等差异化承载需求。

参考文献：

[1] L Andersson， Ed Acreo AB， I Minei. RFC5036 LDP Specification[S]. 2007.

[2] M Jork， L Fang. RFC5433 LDP IGP Synchronization[S]. 2009.

[3] D Awduche， L Berger， D Gan， et al. RFC3209 RSVP-TE： Extensions to RSVP for LSP Tunnels[S]. 2001.

[4] S Previdi Ed， C Filsfils Ed， B Decraene， et al. RFC7855 SPRING Problem Statement and Requirements[S]. 2016.

[5] C Filsfils Ed， S Previdi Ed， B Decraene， et al. Segment Routing Architecture[S]. 2018.

[6] C Filsfils Ed， S Previdi Ed， A Bashandyet， et al. Segment Routing interoperability with LDP[S]. 2018.

[7] S Bryant Ed， A Farrel Ed， J Drake， et al. MPLS Segment Routing in IP Networks[S]. 2018.

[8] 何曉明，冀晖，毛东峰，等. 电信IP网向SDN演进的探讨[J]. 电信科学， 2014（6）： 131-137.

[9] A Atlas Ed， A Zinin Ed. RFC 5286 Basic Specification for IP Fast Reroute： Loop-Free Alternates[S]. 2008.

[10] S Bryant， C Filsfils， S Previdi， et al. RFC 7490 Remote Loop-Free Alternate （LFA） Fast Reroute （FRR）[S]. 2015.

[11] E Rosen. RFC 4364 BGP/MPLS IP Virtual Private Networks （VPNs）[S]. 2006.

[12] S Previdi Ed， C Filsfils， A Bashandy， et al. IS-IS Extensions for Segment Routing[S]. 2018.

[13] P Psenak Ed， S Previdi Ed， C Filsfils， et al. OSPF Extensions for Segment Routing[S]. 2018.

[14] S Previdi Ed， C Filsfils， S Ray， et al. Segment Routing Egress Peer Engineering BGP-LS Extensions[S]. 2018.