跳到主要内容

RFC 7274 - 特殊用途 MPLS 标签的分配与退役 (Allocating and Retiring Special-Purpose MPLS Labels)

  • 状态: Standards Track
  • 发布日期: June 2014
  • 更新: RFC 3032, RFC 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 5921, RFC 5960, RFC 6391, RFC 6478, RFC 6790
  • 作者: K. Kompella, L. Andersson, A. Farrel

摘要 (Abstract)​

一些 MPLS 标签已被分配用于特定目的. 为此预留了一个标签块 (0-15), 这些标签通常称为"保留标签". 本文将其称为"特殊用途标签" (special-purpose labels).

特殊用途标签只有 16 个, 因此分配新的特殊用途标签时必须谨慎; 同时, 在确有需要时也应允许协议继续发展.

本文定义分配和退役特殊用途标签的新流程, 给出扩展特殊用途标签空间的方法, 并说明如何在数据平面中处理扩展特殊用途标签. 最后, 本文将特殊用途标签的 IANA 注册表重命名为"Special-Purpose MPLS Label Values", 并创建名为"Extended Special-Purpose MPLS Label Values"的新注册表.

本文更新了多份使用"reserved label"一词的 RFC, 具体包括 RFC 3032、3038、3209、3811、4182、4928、5331、5586、5921、5960、6391、6478 和 6790.

本备忘录状态 (Status of This Memo)​

本文是一份 Internet Standards Track 文档, 是互联网工程任务组 (Internet Engineering Task Force, IETF) 的产物, 代表 IETF 社区的共识. 本文经过公开审阅, 并已获互联网工程指导组 (Internet Engineering Steering Group, IESG) 批准发布. 有关 Internet Standards 的更多信息, 见 RFC 5741 第 2 节.

本文的当前状态、勘误以及反馈方式见 http://www.rfc-editor.org/info/rfc7274.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

本文受 BCP 78 以及发布之日有效的 IETF Trust 关于 IETF 文档的法律条款 (http://trustee.ietf.org/license-info) 约束. 从本文提取的代码组件必须包含法律条款第 4.e 节所述的 Simplified BSD License 文本, 并按该许可证的规定不提供任何保证.

目录 (Table of Contents)​

    1. 引言
    • 1.1. 本文使用的约定
    1. 问题
    1. 答案
    • 3.1. 扩展特殊用途 MPLS 标签值
      • 3.1.1. 转发带扩展特殊用途标签的数据包
      • 3.1.2. 选择新的特殊用途标签
    • 3.2. 特殊用途标签退役流程
    1. 更新的 RFC
    1. IANA 考虑
    1. 安全考虑
    1. 致谢
    1. 参考文献

1. 引言 (Introduction)​

MPLS 标签栈编码规范 [RFC3032] 定义了 4 个特殊用途标签值 (0 至 3), 并将 4 至 15 留作将来使用. 这些标签在控制平面和数据平面中都具有特殊意义. 此后又分配了 3 个值: [RFC6790] 中的值 7、[RFC5586] 中的值 13 和 [RFC3429] 中的值 14. 因此, 最初 16 个值的空间中还剩 9 个未分配值.

大约 12 年中仅从剩余 12 个特殊用途标签值中分配 3 个, 本身并不足以引起担忧; 真正的问题是特殊用途标签的稀缺性. 此外, 许多特殊用途标签要求转发硬件进行特殊处理, 而硬件变更通常成本高昂, 有时甚至无法实现. 因而, 为新分配的特殊用途标签值提供正式文档十分重要.

本文概述分配和退役特殊用途标签值时涉及的问题, 并定义相应机制. 本文还扩展特殊用途标签空间.

1.1. 本文使用的约定 (Conventions Used in This Document)​

本文中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按 [RFC2119] 解释.

本文引入两个新缩写:

  • XL (Extension Label, 扩展标签): 表示其后跟随一个扩展特殊用途标签的标签.
  • ESPL (Extended Special-Purpose Label, 扩展特殊用途标签): 位于标签栈中 XL 之后的特殊用途标签. XL 与 ESPL 的组合可以看作一种由标签栈中多个连续表项构成的新型"复合标签".

2. 问题 (Questions)​

重新评估 MPLS 特殊用途标签时, 会产生以下问题:

  1. IANA 分配特殊用途标签时应采用什么分配策略? 是否应允许提前分配 (Early Allocation) [RFC7120]? 是否应为实验用途或私有用途 [RFC5226] 保留标签?

  2. 今后分配特殊用途标签时需要提供什么文档?

  3. 特殊用途标签是否应当退役? 哪些标准与此相关? 已退役的特殊用途标签能否为其他用途重新分配? 应采用什么流程和时间表?

  4. 特殊用途标签值 3 ("Implicit NULL Label", 隐式空标签 [RFC3032]) 仅用于信令, 从不用于数据平面. 它能否以及是否应当用于数据平面? 如果可以, 应如何使用、用于什么目的?

  5. 必要时, 使用什么可行机制扩展特殊用途标签空间?

  6. 扩展特殊用途标签是否应当用于负载均衡?

3. 答案 (Answers)​

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

  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 标签值 (Extended Special-Purpose MPLS Label Values)​

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. 转发带扩展特殊用途标签的数据包 (Forwarding Packets with Extended Special-Purpose Labels)​

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

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

3.1.2. 选择新的特殊用途标签 (Choosing a New Special-Purpose Label)​

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

3.2. 特殊用途标签退役流程 (Process for Retiring Special-Purpose Labels)​

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

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 释放此标签值, 供将来使用和分配.

4. 更新的 RFC (Updated RFCs)​

以下 RFC 包含对"reserved labels"一词的引用:

  • [RFC3032], "MPLS Label Stack Encoding"
  • [RFC3038], "VCID Notification over ATM link for LDP"
  • [RFC3209], "RSVP-TE: Extensions to RSVP for LSP Tunnels"
  • [RFC3811], "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management"
  • [RFC4182], "Removing a Restriction on the use of MPLS Explicit NULL"
  • [RFC4928], "Avoiding Equal Cost Multipath Treatment in MPLS Networks"
  • [RFC5331], "MPLS Upstream Label Assignment and Context-Specific Label Space"
  • [RFC5586], "MPLS Generic Associated Channel"
  • [RFC5921], "A Framework for MPLS in Transport Networks"
  • [RFC5960], "MPLS Transport Profile Data Plane Architecture"
  • [RFC6391], "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network"
  • [RFC6478], "Pseudowire Status for Static Pseudowires"
  • [RFC6790], "MPLS Entropy Labels"

所有此类引用都应理解为"special-purpose labels".

5. IANA 考虑 (IANA Considerations)​

IANA 对 MPLS 标签注册作出以下变更和补充:

  1. 将"Multiprotocol Label Switching Architecture (MPLS) Label Values"注册表重命名为"Special-Purpose MPLS Label Values".

  2. 将"Special-Purpose MPLS Label Values"注册表的分配策略改为 Standards Action.

  3. 从"Special-Purpose MPLS Label Values"注册表中分配值 15, 命名为"Extension Label", 并以本文作为参考规范.

  4. 创建名为"Extended Special-Purpose MPLS Label Values"的新注册表. 注册流程为 Standards Action, 注册表范围见表 1 (使用 [RFC5226] 的术语). 只有通过 Standards Action 分配的值才允许采用 [RFC7120] 定义的提前分配策略.

范围 (Range)分配策略 (Allocation Policy)
0-15保留, 永不开放分配.
16-239未分配.
240-255保留用于实验用途.
256-1048575保留. 在新的 Standards Track RFC 定义分配策略之前不得开放分配.

6. 安全考虑 (Security Considerations)​

本文没有大幅改变 MPLS 数据平面的运行方式, 因此安全考虑与 MPLS 架构 [RFC3031] 以及 MPLS 和 GMPLS 安全框架 [RFC5920] 中的规定基本相同.

但是, 应注意增加标签栈深度可能导致数据包分片, 也可能使某些实现无法处理数据包. 本文提供一种协议上合法的方法, 通过插入额外的 {XL,ESPL} 对来增加标签栈, 其增长速度可能高于插入单个"rogue"标签. 在不违反协议规则的情况下, 攻击者可能利用这一点攻击只能处理一定标签栈深度的网络节点.

本文还描述了可能导致 LSR 以每个数据包一次的频率生成事件日志的情况. 实现对此类日志进行速率限制至关重要.

7. 致谢 (Acknowledgments)​

感谢 Pablo Frank 和 Lizhong Jin 所作的有益讨论. 感谢 Curtis Villamizar、Mach Chen、Alia Atlas、Eric Rosen、Maria Napierala、Roni Even、Stewart Bryant、John Drake、Andy Malis 和 Tom Yu 提供的宝贵意见.

8. 参考文献 (References)​

8.1. 规范性引用 (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [RFC3032] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001.
  • [RFC3038] Nagami, K., et al., "VCID Notification over ATM link for LDP", RFC 3038, January 2001.
  • [RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
  • [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
  • [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
  • [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
  • [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
  • [RFC6391] Bryant, S., Ed., et al., "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
  • [RFC6478] Martini, L., et al., "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.
  • [RFC6790] Kompella, K., et al., "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
  • [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.

8.2. 资料性引用 (Informative References)​

  • [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
  • [RFC5586] Bocci, M., Ed., et al., "MPLS Generic Associated Channel", RFC 5586, June 2009.
  • [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
  • [RFC5921] Bocci, M., Ed., et al., "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.

作者地址 (Authors' Addresses)​

Kireeti Kompella
Juniper Networks
Email: [email protected]

Loa Andersson
Huawei
Email: [email protected]

Adrian Farrel
Juniper Networks
Email: [email protected]

最后于 更新