摘要

  • RFC 3988 没让任何一台路由器替整条 LSP 宣布容量，而是要求每一跳从本地孔径和当前下游声明中不断取最小值。
  • 容量下降必须尽快向上游传播；容量上升可以等待，因为过时的乐观值会导致丢包，过时的保守值通常只是浪费带宽。

2005 年 2 月，RFC 3988 以实验性规范提出 LDP 的 MTU 扩展。它的状态页、勘误页和文档历史记录了一个狭窄但重要的问题：LDP 能分发标签，却不能把整条标签交换路径可承载的报文上限交给入口。若仍靠静态配置，入口可能发送在中间节点被无声丢弃的过大报文。

扩展只增加一个 MTU TLV，真正的新意却在计算责任。相邻节点并不自动进入答案。RFC 把“对等 LSR”和“下游 LSR”分开：前者向本机发送某个 FEC 的标签映射，后者是路由表实际选来转发该 FEC 的子集。一条控制会话可以存在，却不承担这批流量。只有当前转发集合中的路径才进入最小值。

计算还必须先说明数字的边界。链路 MTU 包括 IP 头、载荷和标签栈，不包括更低层头部；所谓链路也可能是一条 GRE、IPsec 隧道或另一条 LSP。跳 MTU 描述一对上下游 LSR 之间的可用上限；若有多条实际转发链路，要取其中最小值。LSP MTU 则覆盖从当前节点到一个或多个出口的全部有效转发路径。

RFC 3032及其状态、勘误和历史解释了为什么标签数量会进入这本账。一个普通 MPLS 标签占四个字节，所以 1500 字节链路对新增一层标签可能只剩 1496。若该 LSP 又搭在另一条隧道 LSP 上，可用上限还会继续下降。端口标称帧长不是最终答案，封装状态也是事实的一部分。

RFC 3988 的算法从出口向入口回传。出口先用 65535 作为哨兵值。每个节点针对每个已选下游，把本地跳 MTU 与对方通告的 LSP MTU 取较小者，再在所有下游结果中取最小值。若某个下游的标签映射没有 MTU TLV，就把该项当作 65535，让已知的本地约束继续发挥作用。65535 不是对巨型报文能力的测量，更不是交付证明。

节点可以因策略通告比计算值更小的数字，却绝不能通告更大的数字。这条单向规则说明错误并不对称。低估会让网络少用一部分容量；高估会让入口相信一个不存在的通道宽度。这个最小值是安全包络，不是吞吐承诺。

时间因此也有方向。下游通告变化，或实际下游集合变化，节点都要重新计算。结果不变时不应制造新通告；结果下降时应立即重发；结果上升时可以抑制一段时间。路径变宽后继续使用旧的小值，报文仍然安全，只是效率较低。路径变窄后继续使用旧的大值，报文则可能在内部消失。

未知 TLV 的处理又划出一道边界。RFC 3988 设置了允许未知节点忽略并转发的传播位。中间 LSR 即使不理解 MTU 扩展，也必须把 TLV 继续送往上游。规范同时承认，这可能产生错误的 LSP MTU 计算。透明携带保住了尽可能多的证据，却没有让中间节点突然成为计算者或验证者。

这一机制建立在 RFC 3036 的 LDP 规则上；其状态、勘误和历史保留了当时的上下文。后来取代它的 RFC 5036及其状态、勘误和历史说明基础 LDP 的演进，但不能把 RFC 3988 的实验性设计变成某个现实网络已经部署的证据。

入口拿到这个上限后，才进入 RFC 1191 的 IPv4 行为。该规范的状态、勘误和历史把允许分片的报文与设置 DF 的报文分开。入口可以分片，或丢弃并返回“需要分片”的 ICMP。这个动作仍只是依据控制面包络作出的入口决定，不能证明尺寸合规的报文最终到达应用。

RFC 3209及其状态、勘误和历史提供了 RSVP-TE 隧道背景。RFC 3988 可以把隧道视为链路，于是路径上限可能依赖另一条路径的上限，并再扣除标签开销。运营记录若只保存一个“MTU”字段，就会丢失下游选择、封装深度、来源、年龄和是否被本节点理解等关键证据。

RFC 3988 留下的历史原则不是“永远选择最小报文”，而是承认限制性变化和扩张性变化的风险不同。坏消息晚到会制造虚假的可行性；好消息晚到只会暂时保守。真正可审计的系统要优先传播会阻止损失的事实，同时拒绝把一串已接受的控制消息写成一张端到端交付收据。

来源