SRv6在大型IP骨干网中的应用

［黄晓莹 阮科 陈迅］

1 引言

随着互联网应用的不断丰富，各类应用对时延及丢包的要求也越来越高。在线教育、游戏、无人驾驶、在线医疗等都对网络时延有严格的要求。疫情的爆发更是让互联网的重要性再次提升到新高度，互联网成为越来越不可或缺的基础设施。IP 协议灵活、自洽的特质使其成为数据业务的良好载体，随着实时业务的爆发，这些特质逐渐成为IP 网络性能提升的枷锁。为了解决IP 网络的QoS 问题，曾经出现一系列Overlay 技术，其中BGP MPLS VPN是应用比较广泛的一种解决方案，但其部署仍然存在一定的复杂性，主要体现在需要额外的信令协议及流量工程、扩展性差、不支持异构网络等。SR 的出现解决了上述问题，通过直接对IGP 协议进行扩展来取代LDP 协议，去掉RSVP 协议，推进网络集中式演进。但SR 仍然基于MPLS 实现，自然携带了MPLS 的一些局限性。随着IPv6技术的不断成熟，SRv6 应运而生，成为新一代网络智能化的重要推手，被誉为下一代IP 网络的核心协议。当前，SRv6 已逐步在运营商网络中部署，但仍然是一事一议的方式，并没有通盘考虑整个网络技术布局的演进。本文从SRv6 的特点切入，描述典型应用场景，同时结合IP 骨干网的特点对网络演进给出建议。

2 SRv6 技术简介

2.1 基本原理

随着SDN 热潮的兴起，源路由技术逐渐进入视野，SR-MPLS 率先开启了源路由技术发展的篇章。但SRMPLS 仍然与MPLS 捆绑，而SRv6 则回归IP 本质，提出一种更革命化的思路。如图1 所示，SRv6 利用IPv6 协议的扩展头机制，在IPv6 协议中增加SRH 头，实现路径可编程。利用IPv6 地址标识Segment，极大增加了SRv6 的可达性，以及易部署性。网络中间节点只要支持IPv6，就可以转发SRv6 数据包。

图1 SRv6 头格式

SRv6 采用IPv6 地址标识Segment，标签空间大，为引入可编程能力创建了有利条件。SRv6 Segment 划分成Locator 和Function 两部分。Locator 在高位，用于标识路由。Locator 的大小与网络规模、以及后续业务规划相关，骨干网、城域网、IDC 最好使用统一的规划原则，以方便后续业务发展衔接。Function 在低位，用于标识具体操作，包括常见的END、END.X 等。Function 还包含一个可选参数Arguments，作为Function 的补充，用于定义流相关或服务信息。

SRv6 路径可编程通过SRv6 Policy 实现，SRv6 Policy表示为自定义路径的Segment 列表，包括主用1 个主用Path 和至少1 个候选Path，主备用path 中间节点不相交。所有支持SRv6 的设备都可以发起SRv6 Policy。在大型网络中，这个角色通常由控制器充当。由于SRv6 Policy 信息包含在数据包中，中间节点无需维护状态信息，网络规模不再成为瓶颈。引流到SRv6 Policy 通过Color 属性实现。Color 与业务挂钩，代表SRv6 Policy 的隧道特性，例如低时延、大带宽等。路由器收到数据包后，基于目的地址的BGP 扩展团体属性所代表的Color，将其迭代到相应的SRv6 TE Policy，即可完成自动引流。

2.2 与SR 及MPLS 的比较

SR 基于MPLS 实现，同样继承了MPLS 的局限性：MPLS 部署在IP 层之上，属于2.5 层技术，借鉴了ATM交换的理念，与IP 分属不同的技术形态；不支持异构组网，在多网络域状态下，每一个网络域都必须支持MPLS，否则会出现数据断流；依赖协议多，（LDP、RSVP 等），跨域互通复杂，不利于业务大规模部署；MPLS 标签空间有限，随着网络空间的不断扩大，很难满足未来业务的发展需求；随着业务的不断发展，集中式管理的趋势越发明显，MPLS 分布式的控制面难以应付未来业务不断增长的新需求。SRv6 消除了额外的标签协议，进一步简化了网络协议栈；标签空间大；易于部署，只要支持IPv6 和SRv6 即可；天然支持SDN，更有利于集中式业务的部署。

2.3 局限性

相对于MPLS，SRv6 确实在与IP 的融合、网络扩展性等方面有很大的改进，但在实际应用中还存在着一些问题。

（1）SRv6 通过标签堆栈实现路径自定义，每个标签为1 个IPv6 地址，长128 bit，包头过长导致实际负荷率低。包头过长还带来栈深问题，尤其在大型网络中，跳数过多可能引起栈深超限，对设备的硬件能力提出了较高的要求。针对传输效率低下问题，业界提出了头压缩方案，目前还在推进标准化。

（2）SRv6 标准化进程较慢。除了技术框架（RFC 8402）、SR 封装格式（RFC 8754）、网络编程（RFC 8986）已经标准化，其他领域如安全可控、头压缩、OAM 等仍然处于草案讨论阶段，也进一步影响了SRv6的规模部署。

3 典型业务场景

SRv6 应用场景广泛，只要涉及集中控制、路径定义等智能场景都可以应用SRv6 解决。当前SRv6 的应用主要集中在整体解决方案比较成熟的基础场景，如业务隔离、低时延、大带宽等。

3.1 DDoS 回注

SRv6 是指定路由技术，跟IGP 协议的自动路由不同。头节点及中间节点按需改写目的地址，使数据包的传送达到隧道封装效果。因此，SRv6 也可以看作是一种隧道技术，天然具备承载隔离型业务的能力。隔离类业务的典型应用场景是DDoS 回注。DDOS 回注分为3 个步骤：流量牵引、流量清洗及流量回注。当前，DDoS 流量清洗通常采用发布32 位明细路由的方式，利用最长匹配原则将流量吸引到清洗服务器。由于流量牵引时网络中已发布被攻击客户的32 位明细路由，因此清洗后的流量不能直接回注到公网，这样会引起路由环路。通常做法是，清洗后的流量通过异网回注到源地址，即传输路径需绕开原网络。实现方案如图2 所示。

图2 DDoS 流量回注部署方案现状

异网回注方式安全、有效，但在实际运营过程中仍存在以下问题。

（1）需要额外通道完成回注，对网络架构要求高，清洗服务器以及客户都需要有相同的外网连接，增加了异网以及客户的网络负担。

（2）随着DDoS 业务规模的不断攀升，有可能对回注网络的流量或承载质量造成冲击。据记录，单次DDoS流量攻击规模可高达百G 甚至T 级别。这种情况下，回注网络也需要随业务发展扩容，要求不同网络规划团队加强沟通，对跨团队协作的要求更高。

（3）通过简单方式判断各节点清洗服务器忙闲状态，没有全程全网建立调度机制，不利于资源的有效利用。

（4）回注流量无法保证时延，对高等级客户的业务体验有一定影响。

SRv6 提供了通过自网通道实现流量回注的方式，回注流量被封装在SRv6 隧道，与清洗流量隔离。由于清洗中心设备一般不支持SRv6，因此初期SRv6 隧道起点和终点都在骨干网，配置流量回注专用L3VPN，Overlay 承载在SRv6 隧道上。具体实施方案如下，如图3 所示。

图3 基于骨干网SRv6 隧道的DDoS 流量回注方案

（1）创建L3VPN，包含所有PE，配置连接清洗中心的子接口；将目标地址公网路由引入VPN。

（2）创建连接清洗服务器的骨干网ASBR 到目的IDC 所连ASBR 单向隧道。

（3）将目标路由染色并发布到网内，引导流量在清洗后进入SRv6 隧道。

（4）注意不能配置出口为公网的逃生通道，因为公网中存在32 位明细路由，流量会被重新吸到清洗设备。

（5）也可以将清洗流量引入SRv6 隧道，回注流量走公网返回源地址。

SRv6 引入了业务的概念，网络进一步延伸到业务边缘，推动业务边缘主导隧道的建立及引流。随着SRv6 的逐步推广，以及清洗服务器能力的提升，隧道起点将从骨干网转移到清洗设备，隧道终点为IDC 出口设备，这样业务逻辑更清晰，流程也更畅顺，如图4 所示。

图4 基于跨域SRv6 隧道的DDoS 流量回注方案

3.2 低时延

互联网的便利性和低成本，使得网上承载的业务类型越来越多。很多时延敏感业务也逐渐移植到互联网承载，包括线上会议、在线教育、远程医疗等。以在线教育为例，2020 年初疫情爆发后在线教育用户数激增，如图5 所示。随着疫情的反复，在线教育的热潮还会持续一段时间。

图5 2020 疫情初次爆发后在线教育用户比例暴涨

网络时延跟多种因素相关，包括传输距离、拥塞程度、设备性能等。正常情况下，设备的处理时延在μs 级，传输距离是最主要的影响因素，尤其在长距离传输场景。大型IP 网络在规划设计时，为提升网络可靠性，一般同局向多个设备对链路分别承载在不同的传输路由上，以提高可靠性，如图6 所示。由于传输资源的限制，以及风险分担的布局要求，第二路由通常有一定程度的绕转，尤其对西部、边远地区等地理环境恶劣、光缆资源紧缺地区来说，情况更为严重。

图6 多传输路由组网示意图

因此，借助SRv6 的路径定制能力，将关键业务指定到短路径承载，可极大减少传输时延，如图7 所示。

图7 SRv6 低时延场景示意图

（1）设备纳管：控制器分别纳管城域网/IDC 2 台CR 以及骨干网4 台C 设备，完成拓扑收集。

（2）上报信息：各设备上报链路时延信息给控制器。

（3）骨干网隧道创建：构建起点短路径所在两台C设备间的双向隧道，配置相应Color 标识该隧道为低时延专用通道。获取BSID 信息。

（4）创建端到端SRv6 Policy 隧道：分别压入CR-C1间的peer link SID、骨干段BSID、C2-IDC 之间的peer link SID。

（5）业务引流：在城域/IDC CR 通过BGP FlowSpec引流入SRv6 Policy 隧道，实现低时延承载。

（6）可靠性部署：使能TI-LFA。

3.3 流量调度

Native IP 网络无法保证服务质量，因此长久以来流量工程都是热门话题。无论是运营商还是OTT，都在此领域做过有益探索。比较有代表性的包括MPLS/RSVPTE 以及SDN/OpenFlow。RSVP 是资源预留协议，需要逐跳做资源预留，配置复杂，需要维护状态，还存在不支持ECMP、跨域部署困难等问题，商用案例不多。SDN 流量工程的典型案例是Google B4，借助SDN/OpenFlow 将广域网利用率提升到了90%以上。Google 的成功有两个重要因素：B4 是DCI 网络，不直接面向客户，可以容忍偶尔的拥塞和丢包，成本反而是第一考虑要素；强大的开发和运维团队，通过屏蔽底层网络细节打造强大的控制面，有更多的可操作空间。这些经验对运营商来说很难借鉴。相对地，SRv6-TE 跟IP 紧密贴合，路径信息封装在数据包中，网络中间节点无需维护状态信息，更适应在大型广域网中部署。

目前，运营商间有多个直联点，直联点间通过EBGP互通。运营商之间协商路由发布策略，通常分区域疏导本地流量，保证时延最优。在Native IP 场景下，若某个出口出现拥塞，流量无法自由切换，不能保证服务质量。针对高价值客户的关键流量，通过建立集中式流量监控系统，利用SRv6 建立低利用率直达通道，引导流量走专用通道疏导，可以极大提升关键客户的业务体验，如图8 所示。

图8 SRv6 流量调度场景示意图

4 网络演进策略

4.1 转型目标

针对当前运营商管道化困境，以Segment Routing 的部署为契机，逐步构造新的IP 网络技术体系，推动网络向敏捷开放转型。

（1）智能路由：智能路由是可编程网络的核心，进一步推动网络融合承载，节省投资，是未来网络演进的趋势。以Segment Routing 的部署为契机，推动网络由自洽的分布式控制转向集中控制、智能路由演进。

（2）智慧运营：SRv6 的引入最终是为了提升关键客户访问关键业务的体验，因此自动化部署成为必备条件，网管必须具备快速将客户需求转化为网络策略的能力。

（3）安全可控：SRv6 的部署要求权力上送，因此网络的安全可控非常重要，主要从几个方面考虑：一是控制器的安全性，需配置至少两套控制器互为冗余；二是SRv6 Policy 的冗余性，一般SRv6 Policy 都会具备多个备选path；三是从网络架构层面提升冗余性，同一个目的IP可以部署关联多个尾节点的SRv6 Policy，防止单节点故障。

4.2 基础协议

打造具备SRv6 运营能力的IP 骨干网，需配置相关辅助协议，用于拓扑及性能上报，以及在集中控制环境下提升网络安全可靠性。

（1）BGP-LS

传统网络使用IGP 协议收集网络拓扑，IGP 的特点是自愈、收敛快，适合分布式控制以及对业务没有太多要求的场景。在需要集中决策的场景下，用IGP 收集拓扑的方式存在较大局限性：①控制器必须支持IGP 协议，而IGP协议更新比较频繁，对控制器性能要求也较高；② 无法获得跨域信息；③多种IGP 协议分别上送拓扑，控制器处理负担大。BGP-LS 是BGP 协议新扩展的一种NLRI，用于传递IGP 链路状态并上报给控制器。控制器汇总所有上报信息，集中计算端到端路径。网络中可以指定1～2 台设备负责信息上报。BGP-LS 将网络状态分成3 类上报给控制器：分别是节点Node、链路Link 以及前缀Prefix。

（2）Netconf

网络发展初期，CLI 由于简单及可读性强等优点，成为网络管理工具的首选。随着业务多样性不断涌现，网络规模不断扩展，CLI 的局限性逐渐凸显：①缺乏标准化，厂商通过私有方式实现，网管需单独适配② 缺乏事务性机制，回滚困难，操作存在安全隐患；③缺乏数据建模思维，新业务配置复杂。Netconf 由IETF 在2006 年提出，最初只定义了基本框架，没有配套的建模语言，一开始并没有得到推广应用。2010 年IETF 发布了YANG Model 建模语言，通过抽象网络功能逻辑屏蔽底层差异，这是网络可编程的重要特征之一。Netconf/ YANG 搭配使用极大提升了网络管理的效率及安全性，进一步推动了Netconf 的应用部署。

（3）Telemetry

随着网络规模以及网络监控复杂度的不断扩大，传统的运维模式已无法满足多维度、高频率、高精度的信息采集和处理需求。基于SRv6 的集中式业务部署，要求控制器实时掌控网络性能，快速精确定位故障。与SNMP 的查询模式不同，Telemetry 采用订阅模式，即设备主动上报信息，上层控制器可以及时了解网络性能，实现TE 路径的快速切换。Telemetry 多用于智能运维场景，包括微突发检测、性能监控等。

（4）TE-FRR

IGP 收敛时间跟网络规模有关，一般可以达到数百毫秒，难以满足关键业务的时延要求。IP FRR 的基本思路是提前生成绕开故障点的备用路径，实现故障时毫秒级切换到备用路径。SRv6 通过TI-LFA（Topology-Independent Loop-free Alternate，拓扑无关的无环备份路径）FRR技术，实现网络链路和节点保护，提升关键业务的承载能力。

4.3 组网架构

基于SRv6 的网络架构包括3 个层次。

（1）编排器：负责整体业务编排，与SDN 控制器通过北向接口交互，赋予顶层业务调用底层资源的能力。编排器具有全局资源视图，尤在跨域场景中，编排器起到汇总多个控制器资源信息的纽带作用，保证SRv6 路径端到端最优。

（2）控制器：相当于网络的大脑，负责管理底层转发设备，具有收集拓扑、计算路由、监控流量和时延等功能。同时控制器还与上层编排器互通，负责将业务需求转换成SRv6 Policy 并下发给转发器。控制器应支持BGPLS、PCEP、Netconf 等基础协议，支持低时延、大带宽、自定义等多维度的路径计算；能快速感知网络变动，及时响应；与业务系统联动，快速解读业务需求；与网管系统联动，提供可视化界面。

（3）转发器：网络策略的执行单元。转发器负责上报拓扑信息、接收控制器下发的SRv6 Policy 并执行路径建立，同时需要向控制器汇报SRv6 Policy 状态。

4.4 业务编排

（1）业务管理

在Native IP 网络中，边缘业务节点（MAN、IDC）通过EBGP 上联本省骨干网节点，在路径选择上不存在话语权，所有流量默认上送骨干网，骨干网负责具体路径计算。在SRv6 路径定制场景中，为了保证端到端路径最优，隧道通常需要在网络边缘发起。即边缘业务节点需要清楚骨干网内部拓扑、链路性能等信息。在这种情况下，需引入控制器收集全局信息，保证端到端路径最优。控制器可以单级部署，即一个控制器控制多域网络，也可以分域部署，域间通过东西向协议交互。当前东西向协议进展较慢，缺乏标准化，异构厂家之间互通难，一定程度上阻碍了大规模的业务部署。

（2）隧道建立

隧道按管理主体来划分，有两种创建模式。

（1）隧道起点和终点在骨干网：如图9 所示，MAN/IDC 通过静态路由引流到指定的骨干网边缘设备。这种方案的优点是边缘节点不需要支持SRv6，缺点是：①隧道非端到端创建，可能导致次优路由；② 业务节点没有参与隧道创建，需手工指定下一跳，人工介入多，故障应对不够灵活；③骨干网需参与隧道创建、业务引流等，与业务紧耦合，不利于新业务快速上线。

图9 隧道在骨干网的构建场景

（2）隧道起点和终点在业务节点：如图10 所示，骨干网内两两设备间建立隧道，获取BSID 信息；控制器创建城域网到城域网的端到端隧道，分别压入CR-C1 间的peer link SID、骨干段BSID、C2/C3-IDC 之间的peer link SID，并将最优路径以及引流策略发给业务节点。这种方案的优点是隧道端到端建立，保证最优路径，自动化程度高；缺点是业务节点需要支持SRv6，对某些小节点来说由于设备更迭慢，需引入新平台以支持SRv6。

图10 BSID 跨域隧道

5 基于Flex-Algo 的差异化平面探讨

5.1 网络切片架构

随着差异化承载需求的不断扩大，网络切片的概念也逐渐深入到网络规划设计领域。网络切片的核心是通过提升运维管理水平换取底层资源最大程度的复用，从而更经济地提供差异化服务。从架构上，网络切片可以分为3 个层次：是管理层、控制层、转发层。管理层用于提供网络切片生命周期管理，对接上层业务需求；控制层用于针对业务逻辑生成不同的切片实例、分配资源标识、提供切片性能管理等；转发层即切片的执行主体，用于接收切片策略，并根据策略划分转发资源。

5.2 Flex-Algo 基本概念

Flex-Algo 是一种新的网络切片手段，通过定义不同的算法约束路径范围，控制流量走不同的网络平面。用户可定义的算法范围从Alex-Algo（128）到Flex-Algo（255），最多可以有128 个，每一个算法Flex-Algo（k）都只在本地范围生效。Flex-Algo 引入了FAD 的概念（Flexible Algorithm Definition，灵活算法定义），用于定义具体的算法规则。一个算法规则通常用三元组表示，分别为Metric Type（代价类型），Calc-Type（计算类型）和Constraints（约束条件）Metric-Type目前定义了三大类，分别为IGP Cost 值、时延以及TE 度量；Calc-Type 有两种，一种是IGP 的SPF 算法，一种是自定义的最短路径算法；Constraints 一般用于定义计算时包含/不包含哪些拓扑。

5.3 基于Flex-Algo 的多平面组网

Flex-Algo 引入虚拟平面的概念，最大化复用宝贵的IP 端口资源。实际部署时，可以基于业务类型，将骨干网分成多个运行不同Flex-Algo 算法的平面。初期可以分成几个基础平面：基础平面、低时延平面、隔离平面，后期再逐步根据业务类型进行新平面叠加。基础平面用于承载互联网业务，由于无具体的QoS 要求，Metric、Calc以及Constraint 都可以设置为默认值。低时延平面用于承载对时延有要求的业务，以时延作为Metric-Type，Calc-Type 定义为时延最短路径算法，Constraint 可以结合SDN控制器的监控数据动态调整，将利用率较高节点或传输路由较长的链路剔除；隔离平面用于承载需要隔离通道的业务，如DDoS 回注，Metric-Type 和Cal-Type 设为默认值，重点在于Constraint 的设置，必须强制回注流量跑在SRv6 隧道中，否则流量还是会被吸到公网从而形成死循环。由于各切片平面的Metric type 对流量有聚合作用，为避免引起平面性能劣化，控制器需动态监控各平面状态，及时更新调度策略，例如Metric type 的更新设置，以及Constraint 范围的更新等。

6 结束语

由于SRv6 的Native IP 特性以及出众的可编程能力，产业链成熟度较高，以SRv6 为核心构建差异化的多业务承载网，推动网络可编程能力的提升，已经成为业界共识。基于SRv6 重构差异化平面，需要从上而下进行控制面、业务编排、隧道搭建等多个方面的改造，循序渐进。本着业务端到端的原则，隧道应由边缘业务节点发起，骨干网开放BSID 给端节点，避免深度参与，扰乱业务逻辑。在应用部署层面，初期先尝试基础场景，包括低时延、流量调度等，后期在积累了足够的运营经验后逐步扩大到组网层面的改造，通过Flex-Algo 方式构建多平面承载网，逐步推动网络朝智能、敏捷、开放演进。