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;