summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7274.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7274.txt')
-rw-r--r--doc/rfc/rfc7274.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7274.txt b/doc/rfc/rfc7274.txt
new file mode 100644
index 0000000..2cb0940
--- /dev/null
+++ b/doc/rfc/rfc7274.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+ [RFC7120] be allowed? Should there be labels for experimental
+ use or private use [RFC5226]?
+
+
+
+Kompella, et al. Standards Track [Page 3]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+ 2. What documentation is required for special-purpose labels
+ allocated henceforth?
+
+ 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?
+
+ 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?
+
+ 5. What is a feasible mechanism to extend the space of special-
+ purpose labels should this become necessary?
+
+ 6. Should extended special-purpose labels be used for load
+ balancing?
+
+3. Answers
+
+ This section provides answers to the questions posed in the previous
+ section.
+
+ 1.
+
+ A. Allocation of special-purpose MPLS labels is via "Standards
+ Action".
+
+ B. The IANA registry will be renamed "Special-Purpose MPLS Label
+ Values".
+
+ C. Early allocation may be allowed on a case-by-case basis.
+
+ 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.
+
+ 2. A Standards Track RFC must accompany a request for allocation of
+ Standards Action special-purpose labels, as per [RFC5226].
+
+ 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.
+
+
+
+
+Kompella, et al. Standards Track [Page 4]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+ 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.
+
+ 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.
+
+ 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".
+
+ 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.
+
+3.1. Extended Special-Purpose MPLS Label Values
+
+ 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.
+
+ The label value 15 is set aside as the XL as shown in Section 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.
+
+
+
+
+
+Kompella, et al. Standards Track [Page 5]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+ 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.
+
+3.1.1. Forwarding Packets with Extended Special-Purpose Labels
+
+ 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.
+
+ 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.
+
+3.1.2. Choosing a New Special-Purpose Label
+
+ 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.
+
+3.2. Process for Retiring Special-Purpose Labels
+
+ 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.
+
+ The RFC will direct 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.
+
+
+
+
+
+Kompella, et al. Standards Track [Page 6]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+ 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.
+
+ 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.
+
+4. Updated RFCs
+
+ The following RFCs contain references to the term "reserved 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".
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 7]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+5. IANA Considerations
+
+ IANA has made the following changes and additions to its registration
+ of MPLS labels.
+
+ 1. Changed the name of the "Multiprotocol Label Switching
+ Architecture (MPLS) Label Values" registry to "Special-Purpose
+ MPLS Label Values".
+
+ 2. Changed the allocation policy for the "Special-Purpose MPLS Label
+ Values" registry to Standards Action.
+
+ 3. Assigned value 15 from the "Special-Purpose MPLS Label Values"
+ registry, naming it the "Extension Label" and citing this
+ document as the reference.
+
+ 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.
+
+ +---------------------+---------------------------------------------+
+ | 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
+
+6. Security Considerations
+
+ 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].
+
+
+
+
+
+Kompella, et al. Standards Track [Page 8]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+ 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.
+
+ 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.
+
+7. Acknowledgments
+
+ 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.
+
+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., Tappan, D., Fedorkow, G., Rekhter, Y.,
+ Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+ Encoding", RFC 3032, January 2001.
+
+ [RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P.
+ Doolan, "VCID Notification over ATM link for LDP", RFC
+ 3038, January 2001.
+
+ [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.
+
+ [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.
+
+
+
+Kompella, et al. Standards Track [Page 9]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+ [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., 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.
+
+ [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
+ "Pseudowire Status for Static Pseudowires", RFC 6478, May
+ 2012.
+
+ [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
+ L. Yong, "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., Vigoureux, M., Ed., and S. Bryant, Ed.,
+ "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., Bryant, S., Ed., Frost, D., Ed., Levrau,
+ L., and L. Berger, "A Framework for MPLS in Transport
+ Networks", RFC 5921, July 2010.
+
+
+
+Kompella, et al. Standards Track [Page 10]
+
+RFC 7274 Special-Purpose MPLS Labels June 2014
+
+
+Authors' Addresses
+
+ Kireeti Kompella
+ Juniper Networks
+ 1194 N. Mathilda Ave
+ Sunnyvale, CA 94089
+ US
+
+ EMail: kireeti.kompella@gmail.com
+
+
+ Loa Andersson
+ Huawei
+
+ EMail: loa@mail01.huawei.com
+
+
+ Adrian Farrel
+ Juniper Networks
+
+ EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kompella, et al. Standards Track [Page 11]
+