「SR-MPLS-TE-POLICY」- 概念术语

SR-MPLS Policy 标准介绍 | RFC

在 RFC-draft-ietf-spring-segment-routing-policy 中,提出 MP-BGP 新增地址族 BGP SR Policy(SAFI=73)用于下发 SR-MPLS Policy 信息。

控制器通过 BGP 协议下发 SR 的 SID 组合给 Ingress 节点;
在头端节点中,将创建出一条到 Egress 节点的、带 Policy Color 的 TE 隧道;
当需要引用此隧道时,可以使用 Policy Color 对应到隧道;

针对 SR Policy 的实现,主流有三种方式:

  • BGP-LS 用于收集拓扑,对于客户自研控制器,其无需引入一个新的接口协议;BGP SR Policy 下发路径路由信息;
  • PCEP:在 SR-MPLS TE 场景下,其作为南向协议较为成熟,但是由于各厂家隧道实现模型不统一,无法实现互通,且 PCEP 交互流程较于 BGP 更复杂,推荐使用 BGP 扩展协议;
  • NETCONF/YANG:把隧道路径作为配置下发到转发器。本质上是配置下发,性能最差,不推荐。在整体解决方案中,使用 NETCONF 下发其他配置,而不是隧道配置;

更详细的 SR Policy 细节和功能在[I-D.ietf-spring-segment-routing-policy]介绍,https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy

SR-MPLS Policy 元组标识

根据 RFC 定义,一个 SR Policy 由一个三元组标识,<Headend, Color, Endpoint>,包含多条候选路径;

对于一个指定的节点 SR-MPLS Policy 则由 <color, endpoint> 标识:

  • 头端(headend):SR-MPLS Policy 生成的节点,一般是全局唯一的 IP 地址;
  • 颜色(color):32bit 扩展团体属性,用于标识某一种业务意图(例如低延时);
  • 尾端(endpoint):SR-MPLS Policy 的目的地址,一般是全局唯一的 IP 地址;

Color 和 endpoint 被用于 SR-MPLS Policy 在特定头端标识转发路径;

SR-MPLS Policy 方案架构

在华为 SR-MPLS Policy 解决方案架构中,包含三个关键协议:

  • BGP-LS:收集隧道拓扑、网络带宽、链路时延等信息并上报隧道状态,该信息用于控制器计算 SR Policy 路径和隧道状态呈现;
  • BGP SR Policy:控制器用于下发 SR Policy 信息(color、headend、endpoint 等);
  • NETCONF:控制其用于下发业务接口、路由策略(添加 Color 属性)等其他配置;

BGP-LS 连接

收集隧道拓扑信息,用于控制器计算 SR Policy 路径;

BGP-LS 协议扩展支持收集 SR Policy 状态信息,用于控制器实现隧道状态呈现。https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/

BGP-LS 协议扩展支持 SRLB 信息封装和解封装,用于控制器获取 SRLB 信息以分配 BSID(每一条 SR-Policy 隧道的备份路径都对应一个 Binding SID);

BGP SR Policy 连接

控制器向转发器下发 SR Policy 信息,生成 SR Policy 隧道;

控制器下发 BGP 路由携带 Color 团体属性,并支持此属性传递。隧道头端节点匹配 BGP 路由后基于 Color+Endpoint 方式迭代到 SR Policy 隧道;

SR policy 方案中需要在控制器根据业务 SLA 要求统一规划各个应用的网络隧道算路约束,并通过不同的 color 来标识。根据{头节点,尾节点,COLOR}来唯一确定一个 SR policy 隧道。业务报文迭代隧道时其 BGP 路由需要携带对应的 color 扩展团体属性;

SR-MPLS Policy 模型

SR policy P1 <headend, color, endpoint>
  Candidate-path CP1 <protocol, origin, discriminator>
    Preference 200
      Weight W1, SID-List1 <SID11...SID1i>
      Weight W2, SID-List2 <SID21...SID2j>
  Candidate-path CP2 <protocol, origin, discriminator>
    Preference 100
      Weight W3, SID-List3 <SID31...SID3i>
      Weight W4, SID-List4 <SID41...SID4j>

候选路径(Candidate Path)

一个 SR-MPLS Policy 可以包含多个候选路径(Candidate Path)。一个候选路径就是 SR-MPLS Policy 通过 PCEP 或者 BGP SR Policy 向头端发送的段列表;

如 CP1,CP2,每个路径由三元组 <protocol, origin, discriminator> 唯一确定

主路径

候选路径携带优先级属性(Preference)。优先级最高的有效候选路径为 SR Policy 的主路径;

若优先级相同,则都为主路径;

备路径

优先级次高的有效路径为 SR-MPLS Policy 的备份路径;

转发列表(Segment List)

一条候选路径可包含多条转发列表(Segment List),基于权重进行负载分担。候选路径之间根据优先级形成主备关系;

CP1 是激活路径 (原因是合法且优先级高)。CP1 的两个 SID-list 会被下发到转发器,并且流量转发时会在两个隧道路径上基于权重负载分担,如 SID-List <SID11…SID1i> 按 W1/(W1+W2) 比例分担;

但是,当前主流实现上一个候选路径只有一个 Segment List;

Binding SID

为了提供更好的扩展性、网络不透明度、服务独立性,SR 运用 BSID(Binding SID) [RFC 8402-5.Binding Segment]。每条候选路径都可以被定义一个 BSID 值;

与 RSVP-TE 隧道相似,SR-MPLS TE 隧道也可做为一种转发邻接。如果将 SR-MPLS TE 隧道做为转发邻接分配一个邻接 SID,这个 SID 就被称为 Binding SID。一个 Binding SID 代表一条 SR-MPLS TE 隧道;

静态配置 BSID:

sr-te policy P1
  binding-sid 200
  endpoint 5.5.5.5 color 100

每个 SR-MPLS Policy 最多配置 1 个 Binding SID,Binding SID 可以像其他类型 SID 一样,用于 SR-MPLS TE 路径计算;

BSID 的来源可以是 SRLB 和 SRGB;
SR policy 每个备选路径都有一个 BSID,并且对于相同的 SR policy 的不同备选路径的 BSID 一般相同;不同的 SR policy BSID 一定不同。BSID 一般需要预先规划预留范围,不可以和其他业务共用;

SR 策略的转发头端通过 BSID 将报文转发绑定到 SR 策略上。例如当头端设备收到一个带有这个 BSID 的报文时,头端设备就会使用相应的 SR 策略对这个报文进行转发;

BSID 用于标签流量引流场景,特别是在标签粘连场景,和不同的隧道协议 interworking 场景,如 LDP over SR;