1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 7274 Juniper Networks
Updates: <a href="./rfc3032">3032</a>, <a href="./rfc3038">3038</a>, <a href="./rfc3209">3209</a>, <a href="./rfc3811">3811</a>, <a href="./rfc4182">4182</a>, <a href="./rfc4928">4928</a>, <a href="./rfc5331">5331</a>, L. Andersson
<a href="./rfc5586">5586</a>, <a href="./rfc5921">5921</a>, <a href="./rfc5960">5960</a>, <a href="./rfc6391">6391</a>, <a href="./rfc6478">6478</a>, <a href="./rfc6790">6790</a> Huawei
Category: Standards Track A. Farrel
ISSN: 2070-1721 Juniper Networks
June 2014
<span class="h1">Allocating and Retiring Special-Purpose MPLS Labels</span>
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7274">http://www.rfc-editor.org/info/rfc7274</a>.
<span class="grey">Kompella, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Questions .......................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Answers .........................................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Extended Special-Purpose MPLS Label Values .................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Process for Retiring Special-Purpose Labels ................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Updated RFCs ....................................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Acknowledgments .................................................<a href="#page-9">9</a>
<a href="#section-8">8</a>. References ......................................................<a href="#page-9">9</a>
<a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-9">9</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-10">10</a>
<span class="grey">Kompella, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The MPLS Label Stack Encoding specification [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] 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 [<a href="./rfc6790" title=""The Use of Entropy Labels in MPLS Forwarding"">RFC6790</a>], [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>],
and [<a href="./rfc3429" title=""Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions"">RFC3429</a>], 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.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Questions</span>
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
[<a href="./rfc7120" title=""Early IANA Allocation of Standards Track Code Points"">RFC7120</a>] be allowed? Should there be labels for experimental
use or private use [<a href="./rfc5226" title="">RFC5226</a>]?
<span class="grey">Kompella, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
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"
[<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>]) 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?
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Answers</span>
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 [<a href="./rfc5226" title="">RFC5226</a>].
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 <a href="#section-3.2">Section 3.2</a>.
<span class="grey">Kompella, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
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 <a href="#section-3.1">Section 3.1</a>.
6. [<a href="./rfc6790" title=""The Use of Entropy Labels in MPLS Forwarding"">RFC6790</a>] 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
<a href="#section-3.1">Section 3.1</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Extended Special-Purpose MPLS Label Values</span>
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 <a href="#section-5">Section 5</a>). 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 <a href="#section-5">Section 5</a>.
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.
<span class="grey">Kompella, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
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.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Forwarding Packets with Extended Special-Purpose Labels</span>
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 [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>]. 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 <a href="#section-3">Section 3</a>.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Choosing a New Special-Purpose Label</span>
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.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Process for Retiring Special-Purpose Labels</span>
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.
<span class="grey">Kompella, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Updated RFCs</span>
The following RFCs contain references to the term "reserved labels":
o [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>] ("MPLS Label Stack Encoding")
o [<a href="./rfc3038" title=""VCID Notification over ATM link for LDP"">RFC3038</a>] ("VCID Notification over ATM link for LDP")
o [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] ("RSVP-TE: Extensions to RSVP for LSP Tunnels")
o [<a href="./rfc3811" title=""Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management"">RFC3811</a>] ("Definitions of Textual Conventions (TCs) for
Multiprotocol Label Switching (MPLS) Management")
o [<a href="./rfc4182" title=""Removing a Restriction on the use of MPLS Explicit NULL"">RFC4182</a>] ("Removing a Restriction on the use of MPLS Explicit
NULL")
o [<a href="./rfc4928" title=""Avoiding Equal Cost Multipath Treatment in MPLS Networks"">RFC4928</a>] ("Avoiding Equal Cost Multipath Treatment in MPLS
Networks")
o [<a href="./rfc5331" title=""MPLS Upstream Label Assignment and Context-Specific Label Space"">RFC5331</a>] ("MPLS Upstream Label Assignment and Context-Specific
Label Space")
o [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>] ("MPLS Generic Associated Channel")
o [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>] ("A Framework for MPLS in Transport Networks")
o [<a href="./rfc5960" title=""MPLS Transport Profile Data Plane Architecture"">RFC5960</a>] ("MPLS Transport Profile Data Plane Architecture")
o [<a href="./rfc6391" title=""Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network"">RFC6391</a>] ("Flow-Aware Transport of Pseudowires over an MPLS
Packet Switched Network")
o [<a href="./rfc6478" title=""Pseudowire Status for Static Pseudowires"">RFC6478</a>] ("Pseudowire Status for Static Pseudowires")
o [<a href="./rfc6790" title=""The Use of Entropy Labels in MPLS Forwarding"">RFC6790</a>] ("MPLS Entropy Labels")
All such references should be read as "special-purpose labels".
<span class="grey">Kompella, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
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 [<a href="./rfc5226" title="">RFC5226</a>]). Early allocation following
the policy defined in [<a href="./rfc7120" title=""Early IANA Allocation of Standards Track Code Points"">RFC7120</a>] 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
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
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 [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>] and in the
MPLS and GMPLS Security Framework [<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>].
<span class="grey">Kompella, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
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.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
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.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3031">RFC3031</a>] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", <a href="./rfc3031">RFC 3031</a>, January 2001.
[<a id="ref-RFC3032">RFC3032</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.
[<a id="ref-RFC3038">RFC3038</a>] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P.
Doolan, "VCID Notification over ATM link for LDP", <a href="./rfc3038">RFC</a>
<a href="./rfc3038">3038</a>, January 2001.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-RFC3811">RFC3811</a>] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
Textual Conventions (TCs) for Multiprotocol Label
Switching (MPLS) Management", <a href="./rfc3811">RFC 3811</a>, June 2004.
[<a id="ref-RFC4182">RFC4182</a>] Rosen, E., "Removing a Restriction on the use of MPLS
Explicit NULL", <a href="./rfc4182">RFC 4182</a>, September 2005.
<span class="grey">Kompella, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
[<a id="ref-RFC4928">RFC4928</a>] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", <a href="https://www.rfc-editor.org/bcp/bcp128">BCP 128</a>, <a href="./rfc4928">RFC</a>
<a href="./rfc4928">4928</a>, June 2007.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC5331">RFC5331</a>] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", <a href="./rfc5331">RFC</a>
<a href="./rfc5331">5331</a>, August 2008.
[<a id="ref-RFC5960">RFC5960</a>] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
Transport Profile Data Plane Architecture", <a href="./rfc5960">RFC 5960</a>,
August 2010.
[<a id="ref-RFC6391">RFC6391</a>] 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", <a href="./rfc6391">RFC</a>
<a href="./rfc6391">6391</a>, November 2011.
[<a id="ref-RFC6478">RFC6478</a>] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", <a href="./rfc6478">RFC 6478</a>, May
2012.
[<a id="ref-RFC6790">RFC6790</a>] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
<a href="./rfc6790">RFC 6790</a>, November 2012.
[<a id="ref-RFC7120">RFC7120</a>] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", <a href="https://www.rfc-editor.org/bcp/bcp100">BCP 100</a>, <a href="./rfc7120">RFC 7120</a>, January 2014.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3429">RFC3429</a>] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions", <a href="./rfc3429">RFC 3429</a>,
November 2002.
[<a id="ref-RFC5586">RFC5586</a>] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", <a href="./rfc5586">RFC 5586</a>, June 2009.
[<a id="ref-RFC5920">RFC5920</a>] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", <a href="./rfc5920">RFC 5920</a>, July 2010.
[<a id="ref-RFC5921">RFC5921</a>] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", <a href="./rfc5921">RFC 5921</a>, July 2010.
<span class="grey">Kompella, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7274">RFC 7274</a> Special-Purpose MPLS Labels June 2014</span>
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]
</pre>
|
