UDP 中的 MPLS：为下层网络提供熵，为域设定规则

两家供应商描述同一个业务标签，却只有一家提到 UDP 报文头。差异并非表面文章：把 MPLS 放进 UDP 会改变外层 IP 网络能看到什么，因而也改变它能在并行链路上哈希什么。它还会改变谁被允许部署它。

分层结构短到足以记住：外层 IP、UDP、MPLS 标签栈，最后是业务载荷。标签栈并未消失；在恢复标签交换的端点，它仍然决定转发。

UDP 封装增加了什么

RFC 7510 用 UDP 目的端口 6635 定义这种封装，并用源端口字段承载流熵。执行封装的设备决定什么算一条流以及如何取值；标准刻意不强制某一种哈希。这给厂商行为留出空间，也意味着两种实现可能对同一流量组合产生不同分布。请把该值读作提供给下层的提示，而不是标准做出的路由决策。

好处是间接的。按外层五元组做负载均衡的传输网络如今有东西可哈希，而裸 MPLS 报文可能只提供最上层标签。这是否有帮助，取决于执行均衡的平台以及它实际考虑哪些字段。

熵不是带宽

把流量更均匀地分配到可用链路上，并不等于把它们合并成一条更快的路径。单个应用流仍然只走一条路径，按流均衡也无法超过它所落地链路的容量。该机制也不保证均匀分布；它只是给哈希函数更好的输入。

对给定流保持封装稳定，除非可以接受乱序。若源端口逐包变化，下层会乐于把一次会话分散到多条路径，重组就成了应用的问题。目标是每条流的一致熵，而不是不断变化。

部署边界是规范的一部分

RFC 7510 将部署限制在单一运营商的网络，或相邻的一组协作运营商之内，并对流量加以管理以避免拥塞。它还要求进行过滤，防止封装流量逃出该域。这些不是装饰性条件；它们源于封装本身不提供安全这一事实。应把它们视为合法部署的前提，而不是设计说明中的建议。

UDP 报文头中没有任何东西能认证发送方，也没有任何东西为载荷提供机密性或完整性。若流量需要保护，那要来自具有自身密钥管理的独立机制。选择 MPLS-in-UDP 并不会提升信任模型。

留意保护对你想要的哈希做了什么

加上 IPsec 或其他安全封装后，中转设备用于哈希的外层报文头可能完全变形。隧道模式可以把内层 UDP 源端口藏到新的外层报文头之后，这意味着你精心提供的熵在均衡发生处可能不可见。先加密再封装与相反顺序是不同设计，差异会表现为某条链路承载的流量远高于邻居。

评估线上实际出现的完整报文，而不只是标准描述的那一层。这也是重新考虑 MTU 和端点容量的时机，因为 UDP 报文头加上任何安全开销都会减少可容纳的载荷。

看清整条路径再作决定

按对你网络重要的标准，把 MPLS-in-UDP 与 GRE 等替代方案比较：下层按哪些字段均衡、你能承担多少开销、需要何种安全包裹，以及域边界能否强制执行。断言它对 GRE 有无条件性能优势，是标准并不支持的结论。

然后用真实流量组合测试，并检查每个成员的链路利用率，因为实验室里看起来不错的哈希，在所有流共享同一元组时可能挤到一条链路上。诚实的总结是：封装在下层可以使用的信息，是在一个同意管理它的域内被暴露出来的。