Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 7274 Juniper Networks
Updates: 3032, 3038, 3209, 3811, 4182, 4928, 5331, L. Andersson
5586, 5921, 5960, 6391, 6478, 6790 Huawei
Category: Standards Track A. Farrel
ISSN: 2070-1721 Juniper Networks
June 2014
Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 7274 Juniper Networks
Updates: 3032, 3038, 3209, 3811, 4182, 4928, 5331, L. Andersson
5586, 5921, 5960, 6391, 6478, 6790 Huawei
Category: Standards Track A. Farrel
ISSN: 2070-1721 Juniper Networks
June 2014
Allocating and Retiring Special-Purpose MPLS Labels
分配和停用专用MPLS标签
Abstract
摘要
Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.
一些MPLS标签已分配用于特定目的。为此，已留出一块标签（0-15）；这些标签通常称为“保留标签”。在本文件中，它们将被称为“专用标签”。
As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.
由于这些专用标签只有16个，因此在分配新的专用标签时需要谨慎；然而，与此同时，在需要时应该允许向前推进。
This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.
本备忘录定义了专用标签分配和报废的新程序，以及扩展专用标签空间的方法，并说明了如何在数据平面中处理扩展的专用标签。最后，本备忘录将IANA专用标签注册表重命名为“专用MPLS标签值”，并创建一个名为“扩展专用MPLS标签值”注册表的新注册表。
This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.
本文件更新了以前使用术语“保留标签”的许多RFC。具体而言，本文档更新了RFCs 3032、3038、3209、3811、4182、4928、5331、5586、5921、5960、6391、6478和6790。
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/rfc7274.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7274.
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 ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Questions .......................................................3
3. Answers .........................................................4
3.1. Extended Special-Purpose MPLS Label Values .................5
3.2. Process for Retiring Special-Purpose Labels ................6
4. Updated RFCs ....................................................7
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Acknowledgments .................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Questions .......................................................3
3. Answers .........................................................4
3.1. Extended Special-Purpose MPLS Label Values .................5
3.2. Process for Retiring Special-Purpose Labels ................6
4. Updated RFCs ....................................................7
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Acknowledgments .................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
The MPLS Label Stack Encoding specification [RFC3032] defined four special-purpose label values (0 to 3) and set aside values 4 through 15 for future use. These labels have special significance in both the control and the data plane. Since then, three further values have been allocated (values 7, 13, and 14 in [RFC6790], [RFC5586], and [RFC3429], respectively), leaving nine unassigned values from the original space of sixteen.
MPLS标签堆栈编码规范[RFC3032]定义了四个专用标签值（0到3），并留出值4到15供将来使用。这些标签在控件和数据平面中都具有特殊意义。此后，又分配了三个值（分别为[RFC6790]、[RFC5586]和[RFC3429]中的值7、13和14），从原始的16个空间中留下了九个未分配的值。
While the allocation of three out of the remaining twelve special-purpose label values in the space of about 12 years is not in itself a cause for concern, the scarcity of special-purpose labels is. Furthermore, many of the special-purpose labels require special processing by forwarding hardware, changes to which are often expensive and sometimes impossible. Thus, documenting a newly allocated special-purpose label value is important.
虽然在大约12年的时间里，剩余12种特殊用途标签价值中的3种价值的分配本身并不令人担忧，但特殊用途标签的稀缺性令人担忧。此外，许多专用标签需要通过转发硬件进行特殊处理，对其进行更改通常代价高昂，有时甚至不可能。因此，记录新分配的专用标签值非常重要。
This memo outlines some of the issues in allocating and retiring special-purpose label values and defines mechanisms to address these. This memo also extends the space of special-purpose labels.
本备忘录概述了分配和停用专用标签值时的一些问题，并定义了解决这些问题的机制。此备忘录还扩展了专用标签的空间。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Two new acronyms are introduced:
引入了两个新的首字母缩略词：
XL Extension Label. A label that indicates that an extended special-purpose label follows.
XL扩展标签。一种标签，指示扩展的专用标签紧随其后。
ESPL Extended Special-Purpose Label. A special-purpose label that is placed in the label stack after the Extension Label. The combination of XL and ESPL might be regarded as a new form of "compound label" comprising more than one consecutive entry in the label stack.
ESPL扩展专用标签。一种特殊用途标签，放置在扩展标签之后的标签堆栈中。XL和ESPL的组合可能被视为一种新形式的“复合标签”，包括标签堆栈中的多个连续条目。
In re-appraising MPLS special-purpose labels, the following questions come to mind:
在重新评估MPLS专用标签时，会想到以下问题：
1. What allocation policies should be applied by IANA for the allocation of special-purpose labels? Should Early Allocation [RFC7120] be allowed? Should there be labels for experimental use or private use [RFC5226]?
1. IANA在分配专用标签时应采用哪些分配政策？是否应允许提前分配[RFC7120]？是否有试验用或私人使用的标签[RFC5226]？
2. What documentation is required for special-purpose labels allocated henceforth?
2. 今后分配的专用标签需要哪些文件？
3. Should a special-purpose label ever be retired? What criteria are relevant here? Can a retired special-purpose label ever be re-allocated for a different purpose? What procedures and time frames are appropriate?
3. 特殊用途标签是否应该退役？什么标准与此相关？退役的专用标签是否可以重新分配用于其他用途？什么程序和时限是适当的？
4. The special-purpose label value of 3 (the "Implicit NULL Label" [RFC3032]) is only used in signaling, never in the data plane. Could it (and should it) be used in the data plane? If so, how and for what purpose?
4. 专用标签值3（“隐式空标签”[RFC3032]）仅用于信令，而不用于数据平面。它能（也应该）用于数据平面吗？如果是，如何以及出于什么目的？
5. What is a feasible mechanism to extend the space of special-purpose labels should this become necessary?
5. 如果有必要，扩大特殊用途标签空间的可行机制是什么？
6. Should extended special-purpose labels be used for load balancing?
6. 是否应使用扩展的专用标签进行负载平衡？
This section provides answers to the questions posed in the previous section.
本节回答了上一节提出的问题。
1.
1.
A. Allocation of special-purpose MPLS labels is via "Standards Action".
A.通过“标准行动”分配专用MPLS标签。
B. The IANA registry will be renamed "Special-Purpose MPLS Label Values".
B.IANA注册表将更名为“特殊用途MPLS标签值”。
C. Early allocation may be allowed on a case-by-case basis.
C.可根据具体情况提前分配。
D. The current space of 16 special-purpose labels is too small for setting aside values for experimental or private use. However, the "Extended Special-Purpose MPLS Label Values" registry created by this document has enough space, and this document defines a range for experimental use.
D.目前16个专用标签的空间太小，无法留出数值供实验或私人使用。但是，本文档创建的“扩展专用MPLS标签值”注册表有足够的空间，并且本文档定义了一个实验使用范围。
2. A Standards Track RFC must accompany a request for allocation of Standards Action special-purpose labels, as per [RFC5226].
2. 根据[RFC5226]，标准跟踪RFC必须随附标准行动专用标签分配请求。
3. The retirement of a special-purpose MPLS label value must follow a strict and well-documented process. This is necessary since we must avoid orphaning the use of this label value in existing deployments. This process is detailed in Section 3.2.
3. 特殊用途MPLS标签值的失效必须遵循严格且有充分记录的流程。这是必要的，因为我们必须避免在现有部署中孤立使用此标签值。第3.2节详细介绍了该过程。
4. For now, the use of the "Implicit NULL Label" (value 3) in the data plane will not be allowed. If this decision is revisited later, an accompanying Standards Track RFC that details the use of the label, a discussion of possible sources of confusion between signaling and data plane, and mitigation thereof shall be required.
4. 目前，不允许在数据平面中使用“隐式空标签”（值3）。如果以后再次讨论该决定，则需要随附的标准跟踪RFC，详细说明标签的使用，讨论信号和数据平面之间可能产生混淆的来源，以及缓解混淆的措施。
5. A special-purpose label (the "Extension Label", XL, value 15) is set aside for the purpose of extending the space of special-purpose labels. Further details are described in Section 3.1.
5. 专用标签（“扩展标签”，XL，值15）用于扩展专用标签的空间。更多详情见第3.1节。
6. [RFC6790] says that special-purpose labels MUST NOT be used for load balancing. The same logic applies to extended special-purpose labels (ESPLs). Thus, this document specifies that ESPLs MUST NOT be used for load balancing. It is noted that existing implementations would violate this, as they do not recognize XL as anything other than a single special-purpose label and will not expect an ESPL to follow. The consequence is that if ESPLs are used in some packets of a flow, these packets may be delivered on different paths and so could be re-ordered. However, it is important to specify the correct behavior for future implementations, hence the use of "MUST NOT".
6. [RFC6790]指出，专用标签不得用于负载平衡。同样的逻辑也适用于扩展专用标签（ESPL）。因此，本文件规定ESPL不得用于负载平衡。需要注意的是，现有的实现可能会违反这一点，因为它们不将XL识别为除单个专用标签之外的任何东西，并且不希望遵循ESPL。结果是，如果在流的某些数据包中使用ESPL，这些数据包可能会在不同的路径上传递，因此可能会重新排序。但是，为将来的实现指定正确的行为很重要，因此使用“不得”。
A further question that needed to be settled in this regard was whether a "regular" special-purpose label retains its meaning if it follows the XL. The answer to this question is provided in Section 3.1.
在这方面需要解决的另一个问题是，如果“常规”专用标签跟随XL，它是否保留其含义。第3.1节提供了该问题的答案。
The XL MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an ESPL and interpreted as defined in a new registry created by this document (see Section 5). Whether or not L has the bottom-of-stack bit set depends on whether other labels follow L. The XL only assigns special meaning to L. A label after L (if any) is parsed as usual and thus may be a regular label or a special-purpose label; if the latter, it may be the XL and thus followed by another ESPL.
XL后面必须跟着另一个标签L（因此必须清除堆栈底部的位）。L必须解释为ESPL，并按照本文件创建的新注册表中的定义进行解释（见第5节）。L是否具有堆栈底部位集取决于是否有其他标签跟随L。XL仅赋予L特殊含义。L（如果有）后的标签通常被解析，因此可能是常规标签或特殊用途标签；如果是后者，则可能是XL，然后是另一个ESPL。
The label value 15 is set aside as the XL as shown in Section 5.
标签值15被保留为XL，如第5节所示。
Values 0-15 of the "Extended Special-Purpose MPLS Label Values" registry are set aside as reserved. Furthermore, values 0-6 and 8-15 MUST NOT appear in the data plane following an XL; an LSR processing a packet with an XL at the top of the label stack followed by a label with value 0-6 or 8-15 MUST drop the packet.
“扩展专用MPLS标签值”注册表的值0-15被保留。此外，值0-6和8-15不得出现在XL后面的数据平面中；处理标签堆栈顶部带有XL的数据包，后面带有值为0-6或8-15的标签的LSR必须丢弃该数据包。
Label 7 (when received) retains its meaning as Entropy Label Indicator (ELI) whether a regular special-purpose label or an ESPL; this is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR inserts an entropy label, it MUST insert the ELI as a regular special-purpose label, not as an ESPL.
标签7（收到时）保留其作为熵标签指示器（ELI）的含义，无论是常规专用标签还是ESPL；这是因为与现有已实现和部署的代码和硬件向后兼容，这些代码和硬件在不验证前一个标签是否为XL的情况下查找ELI。但是，当LSR插入熵标签时，它必须将ELI作为常规专用标签插入，而不是作为ESPL插入。
If an LSR encounters the XL at the top of stack and it doesn't understand extension labels, it MUST drop the packet as specified for the handling of an invalid incoming label according to [RFC3031]. If an LSR encounters an ESPL at the top of stack (after the XL) that it does not understand, it MUST drop the packet, again following the same procedure. In either case, the LSR MAY log the event, but such logging MUST be rate-limited.
如果LSR在堆栈顶部遇到XL，并且它不理解扩展标签，则它必须按照[RFC3031]的规定丢弃数据包，以处理无效的传入标签。如果LSR在堆栈顶部（在XL之后）遇到它不理解的ESPL，它必须按照相同的过程丢弃数据包。在任何一种情况下，LSR都可以记录事件，但这种记录必须是速率受限的。
An LSR SHOULD NOT make forwarding decisions on labels not at the top of stack. For load-balancing decisions, see Answer 6 in Section 3.
LSR不应该对不在堆栈顶部的标签做出转发决定。有关负载平衡决策，请参阅第3节中的答案6。
When allocating a new special-purpose label, protocol designers should consider whether they could use an extended special-purpose label. Doing so would help to preserve the scarce resources of "normal" special-purpose labels for use in cases where minimizing the size of the label stack is particularly important.
当分配一个新的专用标签时，协议设计者应该考虑他们是否可以使用扩展的专用标签。这样做将有助于保留“普通”专用标签的稀缺资源，以便在最小化标签堆栈的大小特别重要的情况下使用。
While the following process is defined for the sake of completeness, note that retiring special-purpose labels is difficult. It is recommended that this process be used sparingly.
虽然以下过程是为了完整性而定义的，但请注意，停用专用标签是很困难的。建议谨慎使用此过程。
a. A label value that has been assigned from the "Special-Purpose MPLS Label Values" registry may be deprecated by IETF consensus with review by the MPLS working group (or designated experts if the working group or a successor does not exist). An RFC with at least Informational status is required.
a. 经MPLS工作组（或指定专家，如果工作组或继任者不存在）审查，IETF协商一致可能会否决从“特殊用途MPLS标签值”注册表分配的标签值。需要至少具有信息状态的RFC。
The RFC will direct IANA to mark the label value as "deprecated" in the registry but will not release it at this stage.
RFC将指示IANA在注册表中将标签值标记为“已弃用”，但在此阶段不会发布它。
Deprecating means that no further specifications using the deprecated value will be documented.
弃用意味着不会记录使用弃用值的进一步规范。
At the same time, this is an indication to vendors not to include the deprecated value in new implementations and to operators to avoid including it in new deployments.
同时，这也表明供应商不应在新的实施中包含不推荐的值，也表明运营商应避免在新的部署中包含该值。
b. Twelve months after the RFC deprecating the label value is published, an IETF-wide survey may be conducted to determine if the deprecated label value is still in use. If the survey indicates that the deprecated label value is in use, the survey may be repeated after an additional 6 months.
b. 在不推荐标签值的RFC发布12个月后，可进行IETF范围的调查，以确定不推荐的标签值是否仍在使用。如果调查表明不推荐使用的标签值正在使用中，则可在另外6个月后重复调查。
c. If the survey indicates that a deprecated label value is not in use, 24 months after the RFC that deprecated the label value was published, publication may be requested of an IETF Standards Track Internet-Draft that retires the deprecated label value. This document will request that IANA release the label value for future use and assignment.
c. 如果调查表明弃用标签值未被使用，则在弃用标签值的RFC发布24个月后，可能会要求发布一份使弃用标签值失效的IETF标准跟踪互联网草案。本文件将要求IANA发布标签值，以备将来使用和分配。
The following RFCs contain references to the term "reserved labels":
以下RFC包含对术语“保留标签”的引用：
o [RFC3032] ("MPLS Label Stack Encoding")
o [RFC3038] ("VCID Notification over ATM link for LDP")
o [RFC3209] ("RSVP-TE: Extensions to RSVP for LSP Tunnels")
o [RFC3811] ("Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management")
o [RFC4182] ("Removing a Restriction on the use of MPLS Explicit
NULL")
o [RFC4928] ("Avoiding Equal Cost Multipath Treatment in MPLS
Networks")
o [RFC5331] ("MPLS Upstream Label Assignment and Context-Specific
Label Space")
o [RFC5586] ("MPLS Generic Associated Channel")
o [RFC5921] ("A Framework for MPLS in Transport Networks")
o [RFC5960] ("MPLS Transport Profile Data Plane Architecture")
o [RFC6391] ("Flow-Aware Transport of Pseudowires over an MPLS
Packet Switched Network")
o [RFC6478] ("Pseudowire Status for Static Pseudowires")
o [RFC6790] ("MPLS Entropy Labels")
o [RFC3032] ("MPLS Label Stack Encoding")
o [RFC3038] ("VCID Notification over ATM link for LDP")
o [RFC3209] ("RSVP-TE: Extensions to RSVP for LSP Tunnels")
o [RFC3811] ("Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management")
o [RFC4182] ("Removing a Restriction on the use of MPLS Explicit
NULL")
o [RFC4928] ("Avoiding Equal Cost Multipath Treatment in MPLS
Networks")
o [RFC5331] ("MPLS Upstream Label Assignment and Context-Specific
Label Space")
o [RFC5586] ("MPLS Generic Associated Channel")
o [RFC5921] ("A Framework for MPLS in Transport Networks")
o [RFC5960] ("MPLS Transport Profile Data Plane Architecture")
o [RFC6391] ("Flow-Aware Transport of Pseudowires over an MPLS
Packet Switched Network")
o [RFC6478] ("Pseudowire Status for Static Pseudowires")
o [RFC6790] ("MPLS Entropy Labels")
All such references should be read as "special-purpose labels".
所有此类参考应理解为“专用标签”。
IANA has made the following changes and additions to its registration of MPLS labels.
IANA对MPLS标签的注册做了以下更改和补充。
1. Changed the name of the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry to "Special-Purpose MPLS Label Values".
1. 将“多协议标签交换体系结构（MPLS）标签值”注册表的名称更改为“特殊用途MPLS标签值”。
2. Changed the allocation policy for the "Special-Purpose MPLS Label Values" registry to Standards Action.
2. 将“特殊用途MPLS标签值”注册表的分配策略更改为标准操作。
3. Assigned value 15 from the "Special-Purpose MPLS Label Values" registry, naming it the "Extension Label" and citing this document as the reference.
3. 从“特殊用途MPLS标签值”注册表中分配值15，将其命名为“扩展标签”，并引用本文件作为参考。
4. Created a new registry called the "Extended Special-Purpose MPLS Label Values" registry. The registration procedure is Standards Action, and the ranges for this registry are as shown in Table 1 (using terminology from [RFC5226]). Early allocation following the policy defined in [RFC7120] is allowed only for those values assigned by Standards Action.
4. 创建了一个名为“扩展特殊用途MPLS标签值”注册表的新注册表。注册程序为标准行动，该注册的范围如表1所示（使用[RFC5226]中的术语）。仅允许按照[RFC7120]中定义的策略提前分配标准操作分配的值。
+---------------------+---------------------------------------------+
| Range | Allocation Policy |
+---------------------+---------------------------------------------+
| 0 - 15 | Reserved. Never to be made available for |
| | allocation. |
| | |
| 16 - 239 | Unassigned |
| | |
| 240 - 255 | Reserved for Experimental Use |
| | |
| 256 - 1048575 | Reserved. Not to be made available for |
| | allocation without a new Standards Track |
| | RFC to define an allocation policy. |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Range | Allocation Policy |
+---------------------+---------------------------------------------+
| 0 - 15 | Reserved. Never to be made available for |
| | allocation. |
| | |
| 16 - 239 | Unassigned |
| | |
| 240 - 255 | Reserved for Experimental Use |
| | |
| 256 - 1048575 | Reserved. Not to be made available for |
| | allocation without a new Standards Track |
| | RFC to define an allocation policy. |
+---------------------+---------------------------------------------+
Table 1
表1
This document does not make a large change to the operation of the MPLS data plane, and security considerations are largely unchanged from those specified in the MPLS Architecture [RFC3031] and in the MPLS and GMPLS Security Framework [RFC5920].
本文件并未对MPLS数据平面的操作进行重大更改，安全注意事项与MPLS体系结构[RFC3031]以及MPLS和GMPLS安全框架[RFC5920]中规定的安全注意事项基本相同。
However, it should be noted that increasing the label stack can cause packet fragmentation and may also make packets unprocessable by some implementations. This document provides a protocol-legal way to increase the label stack through the insertion of additional {XL,ESPL} pairs at a greater rate than insertion of single "rogue" labels. This might provide a way to attack some nodes in a network that can only process label stacks of a certain size without violating the protocol rules.
然而，应该注意，增加标签堆栈可能导致数据包碎片，并且也可能使一些实现无法处理数据包。本文件提供了一种协议合法方法，通过以比插入单个“rogue”标签更高的速率插入额外的{XL，ESPL}对来增加标签堆栈。这可能会提供一种攻击网络中某些节点的方法，这些节点只能处理特定大小的标签堆栈，而不会违反协议规则。
This document also describes events that may cause an LSR to issue event logs at a per-packet rate. It is critically important that implementations rate-limit such logs.
本文档还描述了可能导致LSR以每包速率发布事件日志的事件。实现速率限制这样的日志是至关重要的。
Thanks to Pablo Frank and Lizhong Jin for useful discussions. Thanks to Curtis Villamizar, Mach Chen, Alia Atlas, Eric Rosen, Maria Napierala, Roni Even, Stewart Bryant, John Drake, Andy Malis, and Tom Yu for useful comments.
感谢Pablo Frank和Lizhong Jin进行了有益的讨论。感谢Curtis Villamizar、Mach Chen、Alia Atlas、Eric Rosen、Maria Napierala、Roni Even、Stewart Bryant、John Drake、Andy Malis和Tom Yu的有用评论。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.
[RFC3038]Nagami，K.，Katsube，Y.，Demizu，N.，Esaki，H.，和P.Doolan，“LDP ATM链路上的VCID通知”，RFC 3038，2001年1月。
[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月。
[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3811]Nadeau，T.，Ed.，和J.Cucchiara，Ed.，“多协议标签交换（MPLS）管理的文本约定（TC）定义”，RFC 3811，2004年6月。
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
[RFC4182]Rosen，E.，“消除对MPLS显式NULL使用的限制”，RFC 41822005年9月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，2007年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]Frost，D.，Ed.，Bryant，S.，Ed.，和M.Bocci，Ed.，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]Bryant，S.，Ed.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 63912011年11月。
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.
[RFC6478]Martini，L.，Swallow，G.，Heron，G.，和M.Bocci，“静态伪线的伪线状态”，RFC 6478，2012年5月。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 67902012年11月。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，2014年1月。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429]Ohta，H.，“多协议标签交换体系结构（MPLS）操作和维护（OAM）功能的‘OAM警报标签’分配”，RFC 34292002年11月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 US
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州，美国94089
EMail: kireeti.kompella@gmail.com
EMail: kireeti.kompella@gmail.com
Loa Andersson Huawei
安徒生华为酒店
EMail: loa@mail01.huawei.com
EMail: loa@mail01.huawei.com
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk