Internet Engineering Task Force (IETF) E. Osborne
Request for Comments: 7308 July 2014
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Osborne
Request for Comments: 7308 July 2014
Category: Standards Track
ISSN: 2070-1721
Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)
MPLS流量工程（MPLS-TE）中的扩展管理组
Abstract
摘要
MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).
MPLS流量工程（MPLS-TE）使用管理组子TLV宣传32个管理组（通常称为“颜色”或“链接颜色”）。这是为OSPFv2（RFC 3630）、OSPFv3（RFC 5329）和is-is（RFC 5305）定义的。
This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.
本文件将子TLV添加到IGP TE扩展“扩展管理组”。此子TLV提供了超出当前32个限制的其他管理组（链接颜色）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7308.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7308.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Extended Administrative Groups Sub-TLV . . . . . . . . . . . 3
2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Admin Group Numbering . . . . . . . . . . . . . . . . . . 4
2.3. Backward Compatibility . . . . . . . . . . . . . . . . . 4
2.3.1. AG and EAG Coexistence . . . . . . . . . . . . . . . 4
2.3.2. Desire for Unadvertised EAG Bits . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Extended Administrative Groups Sub-TLV . . . . . . . . . . . 3
2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Admin Group Numbering . . . . . . . . . . . . . . . . . . 4
2.3. Backward Compatibility . . . . . . . . . . . . . . . . . 4
2.3.1. AG and EAG Coexistence . . . . . . . . . . . . . . . 4
2.3.2. Desire for Unadvertised EAG Bits . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Do we need more than 32 bits?
我们需要超过32位吗？
The IGP extensions to support MPLS-TE (RFCs 3630 [RFC3630] and 5305 [RFC5305]) define a link TLV known as Administrative Group (AG) with a limit of 32 AGs per link. The concept of Administrative Groups comes from Section 6.2 of RFC 2702 [RFC2702], which calls them Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] describe the mechanics of the TLV and use the term Administrative Groups (sometimes abbreviated herein as AGs), as does this document.
支持MPLS-TE的IGP扩展（RFCs 3630[RFC3630]和5305[RFC5305]）定义了一个称为管理组（AG）的链路TLV，每个链路的限制为32个AGs。管理组的概念来自RFC 2702[RFC2702]的第6.2节，该节称之为资源类。RFCs 3630[RFC3630]和5305[RFC5305]描述了TLV的机制，并使用了术语“管理组”（在本文中有时缩写为AGs），本文件也是如此。
Networks have grown over time, and MPLS-TE has grown right along with them. Administrative Groups are advertised as fixed-length 32-bit bitmasks. This can be quite constraining, as it is possible to run out of values rather quickly. One such use case is #5 in Section 6.2 of RFC 2702 [RFC2702], using AGs to constrain traffic within specific topological regions of the network. A large network may well have far more than 32 geographic regions. One particular operator builds their network along the lines of this use case, using AGs to flag network regions down to the metro scale, e.g., Seattle, San Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are then specified with affinities to include or exclude specific metro regions in their path calculation. Each metro region is given its own bit in the AG bitmask. This means that 32 bits can only (cleanly) represent 32 metro areas. It should be obvious that 32 may not be enough even for a US-based network, never mind a worldwide network.
网络随着时间的推移而增长，MPLS-TE也随之增长。管理组作为固定长度的32位位掩码播发。这可能会有很大的限制，因为可能会很快用完值。RFC 2702[RFC2702]第6.2节中的#5就是这样一个用例，它使用AGs来限制网络特定拓扑区域内的流量。一个大型网络可能有超过32个地理区域。一个特定的操作员沿着该用例的线构建他们的网络，使用AGS将网络区域标记到地铁规模，例如西雅图、旧金山、达拉斯、芝加哥、圣路易斯等。然后MPLS-TE隧道被指定为亲和性，以在其路径计算中包括或排除特定的城域区域。每个metro区域在AG位掩码中都有自己的位。这意味着32位只能（干净地）表示32个地铁区域。很明显，即使是美国的网络，32个可能也不够，更不用说全球网络了。
There may be some opportunity for color reuse; that is, bit 0x8 may mean 'Seattle' or 'Prague' or 'Singapore' depending on the geography in which it is used. In practice, coordinating this reuse is fraught with peril and the reuse effectively becomes the limiting factor in MPLS-TE deployment. With this example, it is not possible to build a Label Switched Path (LSP) that avoids Seattle while including Prague, as it is the same AG value.
可能有一些重新使用颜色的机会；也就是说，位0x8可能表示“西雅图”或“布拉格”或“新加坡”，具体取决于使用它的地理位置。在实践中，协调这种重用充满了危险，有效的重用成为MPLS-TE部署的限制因素。在本例中，不可能构建一个标签交换路径（LSP），该路径在包含布拉格的同时避免西雅图，因为它是相同的AG值。
This document provides Extended Administrative Groups (EAGs). The number of EAGs has no fixed limit, it is constrained only by protocol-specific restrictions such as Link State Advertisement (LSA) or MTU size. While an operator may one day need to go beyond these protocol-specific restrictions, allowing for an arbitrary number of EAGs should easily provide the operator with hundreds or thousands of bit values, thus no longer making the number of AGs an impediment to network growth.
本文档提供扩展管理组（EAG）。EAG的数量没有固定的限制，它仅受到特定于协议的限制，如链路状态公告（LSA）或MTU大小。虽然运营商有朝一日可能需要超越这些特定于协议的限制，但允许任意数量的EAG应该可以轻松地为运营商提供数百或数千位的值，从而不再使AGs的数量成为网络增长的障碍。
EAG's intended use case is within a single domain. As such, this document provides no support for signaling an EAG. It provides no analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in [RFC3209] nor the LSP Attributes (LSPA) object of the Path Computation Element Communication Protocol (PCEP), defined in [RFC5440]. Since this specification provides no way of signaling an LSP's path requirements in reference to the EAG, such constraints may only be applied at the ingress.
EAG的预期用例位于单个域中。因此，本文件不支持向EAG发送信号。它既不模拟[RFC3209]中定义的C-Type 1的会话_属性，也不模拟[RFC5440]中定义的路径计算元素通信协议（PCEP）的LSP属性（LSPA）对象。由于本规范没有提供参考EAG的LSP路径要求的信令方式，因此此类约束只能应用于入口。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document defines the Extended Administrative Group (EAG) sub-TLV for both OSPF [RFC3630] and IS-IS [RFC5305]. The EAG sub-TLV is used in addition to the Administrative Groups when an operator wants to make more than 32 colors available for advertisement in a network. The EAG sub-TLV is optional. Coexistence of EAG and AG TLVs is covered in Section 2.3.1 of this document.
本文件定义了OSPF[RFC3630]和IS-IS[RFC5305]的扩展管理组（EAG）子TLV。当运营商希望在网络中提供超过32种颜色的广告时，除管理组外，还使用EAG子TLV。EAG子TLV是可选的。本文件第2.3.1节介绍了EAG和AG TLV的共存情况。
This document uses the term 'colors' as a shorthand to refer to particular bits with an AG or EAG. The examples in this document use 'red' to represent the least significant bit in the AG (red == 0x1), 'blue' to represent the second bit (blue == 0x2). To say that a link has a given color or that the specified color is set on the link is to say that the corresponding bit or bits in the link's AG are set to 1.
本文档使用术语“颜色”作为简写，表示带有AG或EAG的特定位。本文档中的示例使用“红色”表示AG中的最低有效位（红色==0x1），使用“蓝色”表示第二位（蓝色==0x2）。要说链路具有给定的颜色或在链路上设置了指定的颜色，就是说链路的AG中的对应位被设置为1。
The format of the Extended Administrative Groups sub-TLV is the same for both OSPF and IS-IS:
OSPF和is-is的扩展管理组子TLV的格式相同：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the sub-TLV for OSPF is 26 and for IS-IS is 14. The Length is the size of the Extended Admin Group (EAG) value in bytes. The EAG may be of any non-zero length, but it MUST be a multiple of 4 bytes. The only limits on EAG size are those that are imposed by protocol-specific or media-specific constraints (e.g., max packet length).
OSPF的子TLV类型为26，is-is的子TLV类型为14。长度是扩展管理组（EAG）值的大小（以字节为单位）。EAG可以是任何非零长度，但必须是4字节的倍数。EAG大小的唯一限制是特定于协议或特定于媒体的限制（例如，最大数据包长度）。
By convention, the existing Administrative Group sub-TLVs are numbered 0 (least significant bit) to 31 (most significant bit). The EAG values are a superset of AG. That is, bits 0-31 in the EAG have the same meaning and MUST have the same values as an AG flooded for the same link. If an EAG's length is more than 4 bytes, numbering for these additional bytes picks up where the previous byte left off. For example, the least significant bit in the fifth byte of an 8-byte EAG is referred to as bit 32.
按照惯例，现有管理组子TLV编号为0（最低有效位）到31（最高有效位）。EAG值是AG的超集。也就是说，EAG中的位0-31具有相同的含义，并且必须具有与相同链路的AG相同的值。如果一个EAG的长度超过4个字节，那么这些额外字节的编号将从上一个字节的结束处开始。例如，8字节EAG的第五字节中的最低有效位称为位32。
There are two questions to consider for backward compatibility with existing AG implementations -- how do AG and EAG coexist, and what happens if a node has matching criteria for unadvertised EAG bits?
与现有AG实现的向后兼容性有两个问题要考虑：AG和EAG是如何共存的，如果一个节点对于未公告的EAG比特具有匹配标准，则会发生什么？
If a node advertises EAG, it MAY also advertise AG.
如果节点播发EAG，它也可以播发AG。
If a node advertises both AG and EAG, then the first 32 bits of the EAG MUST be identical to the advertised AG.
如果节点同时播发AG和EAG，则EAG的前32位必须与播发的AG相同。
If both an AG and EAG are present, a receiving node MUST use the AG as the first 32 bits (0-31) of administrative color and use the EAG for bits 32 and higher, if present.
如果AG和EAG都存在，则接收节点必须将AG用作管理颜色的前32位（0-31），并将EAG用于位32及更高（如果存在）。
A receiving node that notices that the AG differs from the first 32 bits of the EAG SHOULD report this mismatch to the operator.
注意到AG与EAG的前32位不同的接收节点应向操作员报告此不匹配。
This process allows nodes that do not support EAG to obtain some link color information from the network, while also allowing for an eventual migration away from AG.
此过程允许不支持EAG的节点从网络获取一些链路颜色信息，同时也允许最终从AG迁移。
The existing AG sub-TLV is optional; thus a node may be configured with a preference to include red or exclude blue and may be faced with a link that is not advertising a value for either blue or red. What does an implementation do in this case? It shouldn't assume that red is set, but it is also arguably incorrect to assume that red is NOT set, as a bit must first exist before it can be set to 0.
现有AG子TLV是可选的；因此，节点可以被配置为具有包括红色或排除蓝色的偏好，并且可以面对不宣传蓝色或红色的值的链接。在这种情况下，实现做什么？它不应该假设设置了red，但是假设没有设置red也是不正确的，因为在将其设置为0之前必须先存在一个位。
Practically speaking, this has not been an issue for deployments, as many implementations always advertise the AG bits, often with a default value of 0x00000000. However, this issue may be of more concern once EAGs are added to the network. EAGs may exist on some nodes but not others, and the EAG length may be longer for some links than for others.
实际上，这对于部署来说并不是一个问题，因为许多实现总是公布AG位，通常默认值为0x00000000。然而，一旦EAG被添加到网络中，这个问题可能会引起更多的关注。EAG可能存在于某些节点上，但不存在于其他节点上，并且某些链路的EAG长度可能比其他链路的长。
To allow for maximum interoperability, an implementation SHOULD treat desired but unadvertised EAG bits as if they were set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, the setting of the 127th EAG bit is not known -- that is, it is neither explicitly 0 nor 1. The node that wants the 127th EAG bit to be 1 will not use this link when implementing the recommended behavior, as the assumption is than the unadvertised 127th bit is set to 0.
为了实现最大程度的互操作性，实现应该将所需但未经广告的EAG位视为设置为0。考虑节点希望只使用EAG的第一百二十七位设置为1的链路的情况。如果一个链路只播发64个EAG位，则第127个EAG位的设置是未知的——也就是说，它既不是显式的0也不是1。希望第127个EAG位为1的节点在实现建议的行为时将不使用此链接，因为假设未广告的第127位设置为0。
That said, each implementation makes its own choices based on necessary constraints, and there might be reasons to provide other strategies for handling this case. A strategy that deviates from the behavior this document recommends SHOULD be configurable to use the recommended behavior, in order to provide maximum interoperability.
也就是说，每个实现都会根据必要的约束做出自己的选择，可能有理由提供其他策略来处理这种情况。与本文档建议的行为不同的策略应可配置为使用建议的行为，以提供最大的互操作性。
This extension adds no new security considerations.
此扩展没有添加新的安全注意事项。
This document registers a sub-TLV allocation in both OSPF and ISIS.
本文件在OSPF和ISIS中登记了子TLV分配。
For OSPF, the subregistry is the "Types for sub-TLVs of TE Link TLV (Value 2)" in the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry.
对于OSPF，子区域是“开放最短路径优先（OSPF）流量工程TLV”注册表中的“TE链路TLV的子TLV类型（值2）”。
For IS-IS, it is "Sub-TLVs for TLV 22, 141, and 222" subregistry in the "IS-IS TLV Codepoints" registry. For IS-IS, the value should be marked 'y' for Sub-TLVs 22, 141 and 222; this is identical to the allocation for the Administrative Group sub-TLV (value 3 in the same subregistry).
对于IS-IS，它是“IS-IS TLV代码点”注册表中的“TLV 22、141和222的子TLV”。对于IS-IS，子TLV 22、141和222的值应标记为“y”；这与管理组子TLV的分配相同（同一子区域中的值3）。
The assigned value from the OSPF registry is 26 and the assigned value from the IS-IS registry is 14. The sub-TLV is called "Extended Administrative Group".
OSPF注册表的赋值为26，is-is注册表的赋值为14。子TLV称为“扩展管理组”。
Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad, Robert Sawaya, Andy Malis, Les Ginsberg and Adrian Farrel for their review and comments.
感谢圣地亚哥·阿尔瓦雷斯、罗希特·古普塔、利姆·阮、塔里克·萨阿德、罗伯特·萨瓦亚、安迪·马利斯、莱斯·金斯伯格和阿德里安·法雷尔的评论和评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
Author's Address
作者地址
Eric Osborne
埃里克·奥斯本
EMail: eric.osborne@notcom.com
EMail: eric.osborne@notcom.com