摘要
- 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
- RFC 5152, HTML
- RFC 5152, text
- RFC Editor record
- IETF Datatracker record
- RFC 5152 history
- RFC 5152 references
- RFC 5152 errata
- RFC 3209
- RFC 3473
- RFC 5151
- RFC 5150
- RFC 4920
- RFC 4655
- RFC 4726
- RFC 4105
- RFC 4216
- RFC 4736
- RFC 2747
- RFC 3097
- RFC 3630
- RFC 4203
- RFC 4205
- RFC 6805
- RFC 8694
- Minimum Initial Specification
- On Reality Layers
- Running-Code Primacy
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
