[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
PROPOSED STANDARD
Updated by: 9017 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
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.
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.
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.
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.
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.
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.
Kompella, et al. Standards Track [Page 1]
RFC 7274 Special-Purpose MPLS Labels June 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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
Kompella, et al. Standards Track [Page 2]
RFC 7274 Special-Purpose MPLS Labels June 2014
1. Introduction
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.
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.
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.
1.1. Conventions Used in This Document
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].
Two new acronyms are introduced:
XL Extension Label. A label that indicates that an extended
special-purpose label follows.
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.
2. Questions
In re-appraising MPLS special-purpose labels, the following questions
come to mind:
1. What allocation policies should be applied by IANA for the
allocation of special-purpose labels? Should Early Allocation
[