摘要

  • RFC 5152 适用于入口无法获得或没有下发完整跨域路径、只能逐域计算 TE LSP 的场景。
  • 每个边界 LSR 依据本域 TED、可达性、能力与政策计算下一段,并可能选择本域出口。
  • ERO 可以混合严格与松散跳点,让部分路径预先固定,部分路径在信令过程中才展开。
  • 下一边界可静态配置,也可从 IGP、BGP 或政策路由信息发现;缺少可用出口信息会让计算失败。
  • 下游无法满足约束时返回 PathErr;允许 crankback 时,上游边界可尝试另一个出口。
  • 入口还可更换松散跳点序列、怀疑 TED 陈旧时重试,或放宽约束,但这些动作回答的是不同问题。
  • RFC 明确指出,逐域计算不能保证找到全局最优的跨域路径。
  • trapping 示例进一步证明:第一条可行路径可能阻断第二条路径的发现,即使多样路径对客观存在。
  • 因而“未找到第二条”只对既定第一条、搜索顺序、可见拓扑、排除条件和算法成立。
  • 域内再优化可以改善各段,却保留同一组边界,无法自动纠正错误的跨域组合。
  • 运营者可按 LSP 选择其他计算方法,但 PCE、重试、crankback 或放宽约束都不是普遍成功保证。
  • 可信结论必须保存成对目标、计算方法、拓扑版本、出口序列、已占资源、失败分支与真实流量结果。

否定结论有一个常被省略的前提

“没有多样路径”听起来像拓扑事实。RFC 5152 的四点图却把隐藏前提摊开:如果先把 A-B-C-D 固定为工作路径,随后确实找不到一条与它分离的替代路径;但若一开始把问题设为寻找路径对,A-C-D 与 A-B-D 同时存在。

第二次搜索没有撒谎。它忠实回答了“在避开已经选定的 A-B-C-D 后,还剩什么”。出错的是结论升级:把一个有条件的搜索结果,提升成网络不存在多样路径的无条件判断。

因此,每个否定结果都该带上它的基准路径。没有第一条路径的指纹、排除的风险集合和计算顺序,“找不到”就无法复核,也不能用于证明采购目标在物理上不可能实现。

路径是在请求前进时被拼成的

逐域计算并不要求入口掌握端到端图。Path 消息携带目的地和到下一边界为止的已知节点,也可以携带更后面的边界或域标识。请求到达 ABR 或 ASBR 后,该边界用自己的 TE 信息继续计算。

负责计算的节点本身位于最终 LSP 上。这不是一组脱离执行路径的顾问,而是一条按传播顺序逐步承诺的决策链。一个 AS 内还有多个 area 或子 AS 时,相同方法可以递归应用。

这种安排保护域内自主权,也避免为了计算而导出完整拓扑。但每一次早期选择都会改变下游收到的问题:选哪个出口、占用哪些资源、把哪个松散跳点展开成哪组严格跳点,都在缩小下一步的可选空间。

ERO 把控制权切成严格与松散两部分

ERO 可以写出完整严格路径,也可以只写源域严格路径加后续边界、完整边界列表,甚至当前边界与最终目的地。严格跳点与松散跳点还可以混用。

严格的下一节点按 RSVP-TE 常规流程处理;松散跳点或代表多个 LSR 的抽象节点,则把展开权交给边界。运营者因此可以在掌握信息的地方精确指定,在看不见的地方授权本域计算。

最终成功的 ERO 记录了被各域接受的路径描述,却不是搜索历史。它不会自动列出被比较的出口、被剪枝的候选、算法究竟优化单条路径还是路径对,也不会解释某个较早决定是否消耗了后续多样性。

“出口可达”只回答继续发送的问题

下一域出口可以预配置,也可以由 IGP、BGP 或政策路由信息动态发现。当下一跳不在本域 TED 时,边界要检查它是否确在域外、下一域是否满足包交换与带内控制假设,并检查 IP 可达性。

若不可达,边界应返回 Routing Problem PathErr。若既没有发现机制,也没有替代方式提供出口,跨域计算就无法继续。

这套检查十分具体,却不应被赋予额外含义。IP 可达说明请求能走到下一边界,不证明下游有满足约束的 TE 资源;出口能用说明它是一个可行分支,不证明它为整条路径或路径对保留了最佳组合。

crankback 是分支探索,不是穷尽证明

下游 ASBR 找不到符合约束的路径段时,会把 PathErr 发回上一个边界。若该 LSP 允许且本地配置启用 crankback,上游可以改选另一个出口;否则就停止并把错误继续送回入口。

入口还可以尝试另一个松散跳点序列。若怀疑下游 IGP-TE 数据库陈旧,可以重试原序列;也可以放宽某项约束后再试。

三个动作的语义不同。换出口是在原目标下探索另一条局部分支;原样重试是在测试状态是否已更新;放宽约束则是在询问另一种服务能否建立。若把它们混在一个“最终成功/失败”字段里,组织就无法判断原始要求究竟被满足、被放弃,还是根本没有被充分搜索。

多样性属于路径对,而不是第二条路径

多样性必须指明不许共享什么:节点、链路、设施、共享风险组,还是某组行政边界。它描述的是两条或多条路径之间的关系,不是先选一条以后再给备份贴上的标签。

若业务承诺是“一对多样路径”,计算目标就应在第一条路径固定前成立。先求最好的单条路径,再求“任何不与它重叠的第二条”,可能比联合寻找路径对更弱。RFC 5152 的 trapping 图正是最小反例。

规范允许服务提供商按 LSP 选择计算技术,并在最优性或多样路径集合成为要求时考虑 PCE 等方法。这里的边界很重要:PCE 是另一种可能适用的技术,不是脱离信息新鲜度、约束定义、算法和部署条件的成功担保。

再优化可能只在原边界框内变得更好

连续 LSP 的再优化由入口控制。下游域可通过 RFC 4736 告知有更优路径,再由入口执行 make-before-break。嵌套或拼接 LSP 则可由各域局部再优化 H-LSP 或 S-LSP,对端到端入口保持透明。

各域的触发频率、度量与带宽准则可能不同。若运营者不希望某些 LSP 被透明局部调整,相关事件必须按可配置政策报告给入口。

问题在于,松散边界跳点保持不变时,各域内部都可能得到更优路径,跨域 LSP 却仍穿过同一组边界。局部改进不会自动重新打开在第一次边界选择中失去的组合。再优化收据必须说明,它改变的是域内段、边界序列,还是整个路径对。

保密减少共享图,也减少统一证明者

RFC 5152 的方法不要求 AS 之间增加拓扑信息交换,因而保留拓扑保密。每个域可以用私有细节计算,而不是把整张图交给外部入口。这是部署价值,不是缺陷本身。

相应地,没有任何一方天然拥有证明全局最优或多样性所需的全部搜索空间。可以通过可信计算、受限披露或可验证断言来组合证明,但不能把“每个域都做了正确计算”直接改写成“全局目标已经最优解决”。

边界计算还会消耗资源并暴露攻击面。运营者需要拒绝未授权 ERO 展开、按合同过滤带宽和优先级、限制请求与错误速率、处理出站 RSVP 对象并协调认证密钥。这些措施保护控制关系,仍不证明最优出口、多样路径对、成功恢复或客户流量到达。

Sources

  1. RFC 5152, HTML
  2. RFC 5152, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5152 history
  6. RFC 5152 references
  7. RFC 5152 errata
  8. RFC 3209
  9. RFC 3473
  10. RFC 5151
  11. RFC 5150
  12. RFC 4920
  13. RFC 4655
  14. RFC 4726
  15. RFC 4105
  16. RFC 4216
  17. RFC 4736
  18. RFC 2747
  19. RFC 3097
  20. RFC 3630
  21. RFC 4203
  22. RFC 4205
  23. RFC 6805
  24. RFC 8694
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy