跳到主要内容

3. 答案

本节回答上一节提出的问题.

  1. 分配策略如下:

    A. 特殊用途 MPLS 标签通过"Standards Action"分配.

    B. IANA 注册表将重命名为"Special-Purpose MPLS Label Values".

    C. 可以根据具体情况允许提前分配.

    D. 现有 16 个特殊用途标签的空间过小, 无法再为实验用途或私有用途预留值. 不过, 本文创建的"Extended Special-Purpose MPLS Label Values"注册表具有足够空间, 并由本文定义一个实验用途范围.

  2. 根据 [RFC5226], Standards Action 类型的特殊用途标签分配请求必须附带一份 Standards Track RFC.

  3. 特殊用途 MPLS 标签值的退役必须遵循严格且有充分文档记录的流程, 以避免现有部署中仍在使用该标签值的设备成为孤立实现. 第 3.2 节详述此流程.

  4. 目前不允许在数据平面中使用"Implicit NULL Label" (值 3). 如果将来重新审议该决定, 必须同时提供一份 Standards Track RFC, 详细说明该标签的用法、信令与数据平面之间可能产生混淆的来源及其缓解措施.

  5. 保留一个特殊用途标签 ("Extension Label", XL, 值 15), 用于扩展特殊用途标签空间. 详见第 3.1 节.

  6. [RFC6790] 规定特殊用途标签 MUST NOT 用于负载均衡. 相同逻辑也适用于扩展特殊用途标签 (ESPL), 因此本文规定 ESPL MUST NOT 用于负载均衡. 现有实现会违反这一要求, 因为它们只把 XL 识别为单个特殊用途标签, 不会预期其后出现 ESPL. 如果在一个流的部分数据包中使用 ESPL, 这些数据包可能沿不同路径传递, 从而发生乱序. 但是, 为未来实现规定正确行为十分重要, 因此这里使用 "MUST NOT".

还需要确定一个普通特殊用途标签紧跟在 XL 之后时是否保留原有含义. 第 3.1 节给出答案.

3.1. 扩展特殊用途 MPLS 标签值​

XL 后面 MUST 跟随另一个标签 L, 因而 XL 的栈底位 MUST 为 0. L MUST 被解释为 ESPL, 并按本文创建的新注册表中的定义解释 (见第 5 节). L 的栈底位是否置位取决于 L 后面是否还有其他标签. XL 只赋予 L 特殊含义. L 之后的标签 (如果存在) 按通常方式解析, 因而可以是普通标签或特殊用途标签; 如果是后者, 它可以再次为 XL, 并再跟随一个 ESPL.

如第 5 节所示, 标签值 15 被保留为 XL.

"Extended Special-Purpose MPLS Label Values"注册表中的值 0-15 被保留. 此外, 值 0-6 和 8-15 MUST NOT 出现在数据平面中的 XL 之后. LSR 处理标签栈顶部为 XL、其后标签值为 0-6 或 8-15 的数据包时, MUST 丢弃该数据包.

标签 7 在接收时仍保留其 Entropy Label Indicator (ELI, 熵标签指示器) 含义, 无论它是普通特殊用途标签还是 ESPL. 这是为了向后兼容已经实现和部署的代码与硬件; 这些实现会查找 ELI, 但不会验证其前一个标签是否为 XL. 不过, LSR 插入熵标签时, MUST 将 ELI 作为普通特殊用途标签插入, 而不能将其作为 ESPL 插入.

3.1.1. 转发带扩展特殊用途标签的数据包​

如果 LSR 在栈顶遇到 XL 但不理解扩展标签, 它 MUST 按 [RFC3031] 对无效入站标签的处理规定丢弃数据包. 如果 LSR 在栈顶 (XL 之后) 遇到无法理解的 ESPL, 它同样 MUST 按相同流程丢弃数据包. 无论哪种情况, LSR MAY 记录该事件, 但此类日志 MUST 受到速率限制.

LSR SHOULD NOT 根据不在栈顶的标签作出转发决策. 关于负载均衡决策, 见第 3 节的答案 6.

3.1.2. 选择新的特殊用途标签​

分配新的特殊用途标签时, 协议设计者应考虑能否使用扩展特殊用途标签. 这样有助于为特别需要减小标签栈大小的场景保留稀缺的普通特殊用途标签资源.

3.2. 特殊用途标签退役流程​

下面的流程是为完整性而定义的. 应注意, 退役特殊用途标签非常困难, 建议谨慎使用此流程.

a. 从"Special-Purpose MPLS Label Values"注册表分配的标签值, 可以在 MPLS 工作组审阅后经 IETF 共识废弃. 如果该工作组或其后继不存在, 则由指定专家审阅. 此操作需要一份至少具有 Informational 状态的 RFC.

该 RFC 将指示 IANA 在注册表中把此标签值标记为"deprecated", 但此时不会释放它.

废弃意味着不再制定使用该废弃值的新规范. 同时, 这也通知供应商不要在新实现中包含该值, 并通知运营者避免在新部署中使用该值.

b. 废弃标签值的 RFC 发布 12 个月后, 可以开展一次 IETF 全范围调查, 确定该废弃标签值是否仍在使用. 如果调查表明它仍在使用, 可以再过 6 个月重复调查.

c. 如果调查表明废弃标签值已不再使用, 则在废弃该标签值的 RFC 发布 24 个月后, 可以请求发布一份退役该标签值的 IETF Standards Track Internet-Draft. 该文档将请求 IANA 释放此标签值, 供将来使用和分配.