摘要

  • 入口 LSR 选择合适的报文字段作为流量键，运行负载均衡函数并得到 EL。传输 LSR 可以读取标签栈中的这一熵值，在不做深度载荷检查的情况下参与 ECMP 或 LAG 选择。
  • EL 不是转发标签，也不是信令对象；它不授权路由创建、路径建立、策略变更或新的 LSP。保留标签值 7 的熵标签指示器（ELI）必须紧邻地位于 EL 之前，因此每个插入动作使标签栈增加两项。
  • ELI/EL 的使用以能力为前提：出口为某条隧道通告熵标签能力，入口再自行决定是否插入；具备能力的出口必须能处理带有和不带有 ELI/EL 的报文。RFC 7447 已废弃 RFC 6790 中的 BGP ELCA，不能把该属性当作当前的普遍信令机制。
  • RFC 8012 为 LSP 与 PW ping/traceroute 增加熵感知的多路径信息和标志，以便探测使用熵标签的 ECMP；但它明确不负责验证增强方法是否得到端到端支持。

机制边界

EL 的值不能落入保留标签范围 0 至 15；ELI 使用保留值 7，帮助下游节点把熵值与应用标签区分开。EL 本身不承担转发语义，也不是密码学安全控制。设计以两个额外栈项换取较少的每 FEC 控制面和转发状态。每流保持一致的路径映射很重要，因为同一流在不同路径间跳转可能带来抖动、时延和报文重排。

这不是故障检测：BFD 改变存活状态，而 EL 只提供每流哈希输入。它也不是 BGP 的路由、传播或会话行为；这里讨论的是已经选定拓扑内的 MPLS 数据面分布。HTTP Priority 表达应用请求紧急程度，EL 向转发节点提供不透明的负载均衡熵，两者不是同一控制面。MP-DCCP 会认证并接纳新子流，而 RFC 6790 不接纳或认证路径，只操作 MPLS 标签栈。

运营决策路径

  1. 先确认目标隧道的出口能力通告和入口、传输、出口对 ELI/EL 的处理约定；不要把能力通告解释成路由授权。
  2. 盘点标签栈深度、硬件或软件限制、混合能力节点以及 OAM 处理。没有统一的阈值、哈希算法、流量键集合或 rollout 顺序是 RFC 强制要求。
  3. 在不改变路由策略的对照条件下，选择少量可回退的业务流进行验证，检查每流稳定性、ECMP/LAG 分布、时延和重排；不要把结果写成普遍收益率。
  4. 用 RFC 8012 的熵感知 ping/traceroute 夹具分别测试预期路径和多路径信息，同时记录哪些节点依据 EL、哪些节点依据 IP 或其他标签。测试通过不等于所有节点支持增强方法，也不等于所有流量经过每条被测路径。
  5. 若栈深度、互操作性或观测结果不可接受，保持不插入 ELI/EL，并回到粗粒度标签哈希、在可行时检查更深层报头或其他既有机制；这些替代方案同样不授予路径权力。

验证夹具

  • 栈夹具：构造一组带 ELI（标签 7）紧接 EL 的报文，以及一组没有这两个标签的报文；确认 EL 值不在 0–15，确认每次插入使栈增加两项，且出口两种形式都能处理。
  • 一致性夹具：用组织实际定义的同一流键重复发送，观察映射是否稳定；改变一个已定义的键后再比较路径。RFC 没有规定唯一键集合或哈希算法，因此记录实际选择而非声称标准要求。
  • 路径夹具：通过 RFC 8012 的熵感知 LSP/PW ping 与 traceroute 请求多路径信息并使用相应标志；把探测结果与转发节点的 EL、IP 或其他标签选择依据逐项对照。它验证探测程序的可用信息，不验证端到端支持。
  • 负面夹具：比较插入前后的路由、LSP 和策略状态，确认没有因 EL 产生新路由、新 LSP 或策略变化；另行记录 BFD 状态，避免把它与熵分布混为一谈。

RFC 不规定当前部署普及率、统一利用率增益、事故减少率、运营阈值或 rollout 顺序。分布良好的熵值也不能证明路由策略、容量规划或故障恢复正确。

来源