Allocating and Retiring Special Purpose MPLS Labels
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale
CA
94089
US
kireeti.kompella@gmail.com
Huawei
loa@mail01.huawei.com
Juniper Networks
adrian@olddog.co.uk
Routing
MPLS, reserved label
Some MPLS labels have been allocated for specific purposes. A
block of labels (0-15) has been set aside to this end, and are
commonly called "reserved labels". They will be called
"special purpose labels" in this document. As there are only
16 of these labels, caution is needed in the allocation of new
special purpose labels, yet at the same time allow forward
progress when one is called for. This memo defines some
procedures to follow in the allocation and retirement of
special purpose labels, as well as a method to extend the
special purpose label space. Finally, this memo renames the
IANA registry for these labels to "Special Purpose MPLS Label
Values", and creates a new one called the "Extended Special
Purpose MPLS Label Values" registry.
The specification of the Label Stack Encoding for
Multi-Protocol Label Switching (MPLS)
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 , and ,
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.
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 .
In re-appraising MPLS special purpose labels, the following
questions come to mind:
What allocation policies should be applied by IANA for the
allocation of special purpose labels? Should Early
Allocation be allowed? Should
there be labels for Experimental Use or Private Use ?
What documentation is required for special purpose labels
allocated henceforth?
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?
The special purpose label value of 3 (the "Implicit Null
Label", ) 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?
What is a feasible mechanism to extend the space of
special purpose labels, should this become necessary?
This section provides answers to the questions posed in the
previous section.
Allocation of special purpose MPLS labels is via
"Standards Action".
The IANA registry will be renamed "Special Purpose
MPLS Labels".
Early allocation may be allowed on a case-by-case
basis.
The current space of 16 special purpose labels is too
small for setting aside value for experimental or
private use. However, the extended special purpose
labels registry created by this document has enough
space, and this document defines a range for
experimental use.
A Standards Track RFC must accompany a request for
allocation of Standards Action special purpose labels, as
per .
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 .
For now, the use of the "implicit null label" (label 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.
A special purpose label (the "extension" label, label 15)
is to be set aside for the purpose of extending the space
of special purpose labels. Further details are described
in .
A further question to be settled in this regard is whether a
"regular" special purpose label retains its meaning if it
follows the extension label; see .
An extension label MUST be followed by another label L (and
thus MUST have the bottom-of-stack bit clear). L MUST be
interpreted as an "extended special purpose label" and
interpreted as defined in a new registry created by this
document (see ). Whether or not L has
the bottom-of-stack bit set depends on whether other labels
follow L. The extension label only assigns special meaning
to L. A label after L (if any) is parsed as usual, and thus
may be a regular label, a special purpose label or (if
prefixed by another extension label) an extended special
purpose label.
IANA is asked to set aside label value 15 as the extension
label.
Values 0-6 and 8-15 of the extended special purpose label
registry are set aside as reserved; these MUST NOT appear in
the data plane. Label 7 (when received) retains its meaning
as ELI whether a regular or an extended special purpose
label; however, an implementation SHOULD NOT insert a label
of 7 as an extended special purpose label, preferring
instead to send 7 as a regular special purpose label.
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 label value that has been assigned from the "Special
Purpose MPLS Label Values" 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.
The RFC will direct the IANA to mark the label value as
"deprecated" in the registry, but will not release it at
this stage.
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 deprecated value in new implementations and to
operators to avoid including it in new deployments.
12 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 a further 6
months.
24 months after the RFC that deprecated the label value
was published and if the survey indicates that
deprecated label value is not in use, publication may be
requested of an IETF Standards Track Internet-Draft that
retires the deprecated the label value. This document
will request IANA to release the label value for for
future use and assignment.
The following RFCs contain references to the term "reserved
labels": ("MPLS Label Stack
Encoding"), ("VCID Notification for
LDP"), ("Extensions to RSVP for LSP
Tunnels"), ("MPLS TC MIB"), ("Removing a Restriction on the use of
MPLS"), ("Avoiding ECMP Treatment in
MPLS Networks"), , ("G-ACh and GAL"),
("MPLS Transport Profile Framework"),
("MPLS-TP Data Plane Architecture"),
("MPLS Entropy Labels"), ("FAT-PW"),
and ("Pseudowire Status for Static
Pseudowires"). All such references should be read as "special
purpose labels".
This document requests IANA to make the following changes and
additions to its registration of MPLS Labels.
Change the name of the "Multiprotocol Label Switching
Architecture (MPLS) Label Values" registry to the "Special
Purpose MPLS Label Values".
Change the allocations policy for the "Special Purpose MPLS
Label Values" registry to Standards Action.
Note: any new allocation from the Special Purpose MPLS
Label Values registry MUST be also say whether the same
value needs to be reserved in the Extended Special Purpose
MPLS Label Values registry.
Assign label 15 from the "Special Purpose MPLS Label Values"
registry, naming it the "extension label", and citing this
document as the reference.
Create a new registry called the "Extended Special Purpose
MPLS Label Values" registry. The ranges and allocation
policies for this registry are as follows (using
terminology from ). Early
allocation following the policy defined in is allowed only for those values
assigned by Standards Action.
Range
Allocation Policy
0 - 6, 8 - 15
Reserved. Not to be allocated. MUST NOT appear
in the data plane.
7
Allocated; meaning is ELI
16 - TBD1 Standards Action
TBD1+1 - TBD2 Reserved
TBD2+1 - 1048559 First Come, First Served
1048560 - 1048575 Experimental
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 and in the MPLS and GMPLS Security Framework
.
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 arbitrarily increase the label stack and
so might provide a way to attack some nodes in a network without
violating the protocol rules.