摘要

  • 运营者选择 Uniform、Pipe 或 Short Pipe，并配置新压入标签使用的 TTL；RFC 3443 没有定义模型信令机制，而是把选择留给命令行或管理接口上的运营配置。
  • Uniform 传播 MPLS 与承载报文的 TTL 状态，使隧道中的 LSR 对隧道外的流量保持可见；Pipe 旨在让隧道在外部看来像一跳；Short Pipe 在出口采用不同的处理。
  • 普通转发约束仍然有效：除非模型另有规定，输出 TTL 是输入 TTL 减一；输出 TTL 检查失败时不得转发。Pipe 或 Short Pipe 不是加密、认证、访问控制或路线授权。

关键操作发生在标签边界。入口 LSR 在压入标签时必须依据模型处理标签下方的 IP TTL；中转 LSR 在交换标签时执行相应的 TTL 检查与递减；出口 LSR 在弹出标签时把承载报文交给后续转发语义。RFC 3032 的标签栈编码使多层标签成为可能，RFC 3443 则规定这些操作怎样保持或隐藏跳数状态。这里的“隐藏”只表示外部探测可能看不到隧道内部的跳点，不表示内部设备没有执行 TTL 控制。

Uniform 模型沿标签边界传播 hop-limit 状态，因此外部 traceroute 可以暴露隧道中的中转 LSR。Pipe 模型在压入标签时使用运营者配置的 TTL，而不是复制下方报头的 TTL，目标是让整个隧道对外表现为一跳。RFC 3443 提到文档发布时许多实现使用 255，但这只是历史实现倾向，不是普遍强制值。Short Pipe 也使用配置的压入 TTL，却在隧道出口把承载报文视为经过普通转发出口，执行规定的递减；无论是否采用 PHP，RFC 都给出等效的端到端递减结果。

PHP 是正确性边界，而非一个可以忽略的优化名词。若倒数第二跳弹出外层标签，出口看到的标签栈与未 PHP 时不同；出口仍必须对实际收到的报文和栈应用相符的 TTL 规则。层级标签栈同样要求每一层 push、swap、pop 的行为一致。边界设备配置不一致，可能造成 hop-limit 被多减、少减或在错误位置检查，进而产生不可解释的丢包或 traceroute 结果。RFC 并未提供厂商默认值、部署比例、事故下降率或强制遥测阈值。

验证用例应把机制与推论分开：准备一个带已知 IP TTL 的报文，记录入口压入标签后的 TTL、每次中转交换标签后的递减与检查、出口弹出标签后的报头 TTL；分别在启用和不启用 PHP、单层和层级标签栈情况下重复。再以 Uniform、Pipe、Short Pipe 各跑一次路径跟踪，并注明“看不到内部跳点”本身不能证明所用模型、实际路径或每台设备都一致实现。可将 RFC 3443 的操作步骤与 RFC 3032 的栈编码逐项对照；RFC 3270 提供差分服务标签处理背景，但不把 TTL 模型变成授权机制。

运营者决策路径

  1. 先确认需要的是可见性模型，而不是建立 LSP、批准路由、认证 peer、授予访问权或改变转发策略。
  2. 若外部诊断必须看见隧道内 hop，评估 Uniform；若隧道应在外部呈现为一跳，评估 Pipe；若出口必须采用额外的普通转发式处理，评估 Short Pipe。
  3. 明确配置的初始标签 TTL；不要把 255 当作普遍要求。
  4. 用 push、swap、pop、PHP 和层级栈夹具验证每个边界，再检查失败时是否按规则丢弃。
  5. 把 traceroute、TTL 观测和设备行为记录为证据，不把单一探测现象当成模型识别或路径证明。

来源