摘要

  • RFC 5150 用专属的 GMPLS 段 LSP（S-LSP）拼成一条端到端 LSP。
  • 每条 S-LSP 至多关联一条 e2e LSP，并把整段带宽分配给该关联。
  • 段首在 LSP_ATTRIBUTES 中设置位 5 请求拼接，段尾在 RRO 中返回对应的 ready bit。
  • 支持拼接的段尾还返回非空标签；明确不支持时使用 Routing Problem 值 30。
  • 就绪交换证明协议参与和段准备，不证明后续 e2e 转发状态已经安装。
  • S-LSP 两端可在 TE 拓扑中表现为相邻，数据平面却不存在 forwarding adjacency。
  • e2e 逻辑 hop 上交换的 Label 与 Upstream Label 没有转发意义，接收方必须忽略。
  • 真正的连续性依赖入口和出口分别安装 swap；双向业务还需要反向状态。
  • e2e RRO 记录段端点，却按规范省略 S-LSP 内部的节点与链路。
  • S-LSP 与 e2e LSP 的拆除彼此独立；段故障后的具体恢复信令不在 RFC 5150 范围内。
  • RSVP 认证保护控制邻居，而不能替分离的数据接口或用户流量作证。
  • 请求、就绪、边界读回、段内健康、拆除与业务结果属于不同证据层。

拼接不是一个动作，而是两个边界动作

入口节点收到 e2e Path 并选定 S-LSP 后，需要把来自上游 e2e LSP 的流量交换进该段。段尾则要把从 S-LSP 到达的流量交换到下游 e2e LSP。若是双向 LSP，两端还要为反方向准备对应动作。

这些状态存在于不同设备，也可能在不同时间写入。入口成功并不能说明出口成功，正向正确不能说明反向正确，控制平面会话存在也不能说明 ASIC 或其他执行面已经接受配置。把它们折叠成一个“拼接成功”会隐藏最重要的故障组合。

证据链应分别保存入口 swap 的目标、段内转发状态、出口 swap 的目标和双向读回，再以真实数据流确认。缺一项时，结论只能停在已观察到的层级。

就绪位先证明段愿意参与

S-LSP 的准备发生在 e2e 使用之前。段首在 Path 的 LSP_ATTRIBUTES Attributes Flags TLV 中设置 LSP stitching desired 位 5。识别并支持该行为的段尾在 Resv 中分配非空标签，并在 RRO Attributes 子对象里设置 LSP segment stitching ready 位。

若段尾认识请求却无法支持，就返回 PathErr：Routing Problem，值 30 Stitching unsupported。若实现认识对象但不认识 TLV 或该位，它可以忽略请求。段首因此必须检查返回位；ready bit 未置位时不得把这条 S-LSP 用于拼接。

这是一份有边界的声明：段尾同意按该机制参与，段已经完成规定的预备。它不是后来两端 swap 的读回，也没有穿过隐藏的段内路径。运维系统应尊重其权威，同时避免扩大其含义。

强制携带的标签可以没有转发含义

e2e 请求必须与 S-LSP 的 switching type 一致，并结合 ERO、带宽和本地 TE 策略选择段。双向 e2e LSP 还必须在 S-LSP hop 上的 Path 中携带 Upstream Label；段尾在 Resv 中也必须返回 Label。

正常情况下，标签似乎天然等于转发指令。RFC 5150 在这里明确给出反例：S-LSP 两端之间没有 forwarding adjacency，因此这两个值都没有意义，可以由实现任意选择，接收方必须忽略。它们维持 RSVP-TE 在抽象 hop 上的消息结构，却不指向两端之间的一项直接转发资源。

因此，“Label 对象存在”不能作为转发表项的替身。真正要验证的是边界节点如何把上游、段内与下游的本地标签或资源连接起来。协议字段存在与运行状态正确是两种记录。

TE 邻接把内部路径折叠起来

一条 S-LSP 可以跨越零个或多个中间 GMPLS 节点，也可以被管理或发布成 TE link。它的两个端点在 TE 拓扑里像相邻节点，在数据平面却没有直接邻接。发布并非拼接的必要条件；启用发布还会增加链路状态数据库的规模与复杂度。

e2e RRO 应记录 S-LSP TE link 的编号地址或无编号标识，但不应把段内经过的中间节点和链路写进这个 hop。于是，一份完整而简洁的 RRO 只能证明抽象边界，不能证明内部每一跳、物理多样性、容量或故障位置。

跨域时，这种可见性还可能进一步缩小。段内 TE link 通常不向外域发布，头端依赖逐域或 PCE 计算。抽象使协调可扩展，也要求证据系统承认自己看不到什么。

独占分配解决的是准入冲突

层次化 H-LSP 可以承载多条更高层 LSP，并用有意义的标签区分。S-LSP 留在同一交换层，每段至多服务一条 e2e LSP，整段带宽都分配给它。分配完成后，未预留带宽应设为零，阻止第二条 e2e LSP 被准入。

多个 S-LSP 组件可以 bundle 成一个 TE link，但每个组件仍保持单一关联。这个约束保护资源核算和排他性，却不测量实际吞吐、不证明队列与物理隔离，也不确认应用会话。

RFC 还提出利用拼接跨越不支持新能力的 legacy 节点，例如让 P2MP 能力节点之间的段屏蔽旧 LSR，同时提醒这种设计可能降低 RSVP P2MP 的吸引力。绕开能力缺口的同时，也把更多运行细节藏进段内。

两套会话可以用不同方式结束

S-LSP 与 e2e LSP 拥有独立 RSVP 会话。一个可以按 ADMIN_STATUS 优雅退出，另一个可以用 PathTear、ResvTear 或带状态移除的 PathErr 立即清理。静态段可以在 e2e 结束后继续存在，动态段可依据本地策略在无人使用时删除。

删除 S-LSP 应被视为其 e2e LSP 的故障，并触发拆除或恢复。但实际响应信令被明确留在 RFC 5150 范围之外。触发器不是恢复签收，必须继续观察新路径与业务。

规范建议在 e2e 拆除完成后延迟删除动态段，推荐值为 30 秒，以减少多个事件同时产生的 RSVP 错误和拆除消息。这个本地定时器管理消息风暴，不保证服务连续。

控制消息还可能沿不同于数据接口的路径传送。安全关联应绑定通信邻居及其 IP 身份，认证或 IPsec 证明受保护的控制交换，却不会读取边界 swap 或传送用户 payload。IANA 位 5 和错误值 30 提供共同坐标，不是部署清单。

来源

  1. RFC 5150，HTML
  2. RFC 5150，文本
  3. RFC Editor 条目
  4. IETF Datatracker 条目
  5. RFC 5150 历史
  6. RFC 5150 引用关系
  7. RFC 5150 勘误
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. IANA RSVP 参数
  20. 最小初始规范
  21. 论现实层
  22. 运行代码优先