「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；

Filed under: K4NZDROID - @ 12:36 AM