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
|
<pre>Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 6511 G. Swallow
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Juniper Networks
February 2012
<span class="h1">Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for</span>
<span class="h1">RSVP-TE Label Switched Paths</span>
Abstract
There are many deployment scenarios that require an egress Label
Switching Router (LSR) to receive binding of the Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to
an application and a payload identifier using some "out-of-band"
(OOB) mechanism. This document defines protocol mechanisms to
address this requirement. The procedures described in this document
are equally applicable for point-to-point (P2P) and point-to-
multipoint (P2MP) LSPs.
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/rfc6511">http://www.rfc-editor.org/info/rfc6511</a>.
Copyright Notice
Copyright (c) 2012 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
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</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>. RSVP-TE Signaling Extensions ....................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Signaling Non-PHP Behavior .................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Signaling OOB Mapping Indication ...........................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Relationship between OOB and Non-PHP Flags .................<a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. Egress Procedure for Label Binding .........................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Attribute Flags for LSP Attributes Object ..................<a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. New RSVP Error Sub-Code ....................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Acknowledgements ................................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Informative References .....................................<a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
When Resource Reservation Protocol - Traffic Engineering (RSVP-TE) is
used for applications like Multicast Virtual Private Network (MVPN)
[<a href="./rfc6513" title=""Multicast in MPLS/BGP IP VPNs"">RFC6513</a>] and Virtual Private LAN Service (VPLS) [<a href="./rfc4761" title=""Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"">RFC4761</a>], an egress
Label Switching Router (LSR) receives the binding of the RSVP-TE
Label Switched Path (LSP) to an application and a payload identifier
using an "out-of-band" (OOB) mechanism (e.g., Border Gateway Protocol
(BGP)). In such cases, the egress LSR cannot make correct forwarding
decisions until such OOB mapping information is received.
Furthermore, in order to apply the binding information, the egress
LSR needs to identify the incoming LSP on which traffic is coming.
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
Therefore, non-Penultimate Hop Popping (non-PHP) behavior is required
to apply OOB mapping. Non-PHP behavior requires the egress LSRs to
assign a non-NULL label for the LSP being signaled.
There are other applications that require non-PHP behavior. When
RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP
multicast traffic non-PHP behavior enables a leaf LSR to identify the
P2MP TE LSP on which traffic is received. Hence, the egress LSR can
determine whether traffic is received on the expected P2MP LSP and
discard traffic that is not received on the expected P2MP LSP. Non-
PHP behavior is also required to determine the context of upstream
assigned labels when the context is a MPLS LSP. Non-PHP behavior may
also be required for MPLS Transport Profile (MPLS-TP) LSPs [<a href="./rfc5921" title=""A Framework for MPLS in Transport Networks"">RFC5921</a>].
This document defines two new flags in the Attributes Flags TLV of
the LSP Attributes object defined in [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]: one flag for
communication of non-PHP behavior and one flag to indicate that the
binding of the LSP to an application and a payload identifier
(Payload ID) needs to be learned via an out-of-band mapping
mechanism. As there is one-to-one correspondence between bits in the
Attribute Flags TLV and the Record Route Object (RRO) Attributes
subobject, corresponding flags to be carried in the RRO Attributes
subobject are also defined.
The procedures described in this document are equally applicable for
point-to-point (P2P) and P2MP LSPs. Specification of the OOB
communication mechanism(s) is beyond the scope of this document.
<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">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. RSVP-TE Signaling Extensions</span>
This section describes the signaling extensions required to address
the above-mentioned requirements.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Signaling Non-PHP Behavior</span>
In order to request non-PHP behavior for an RSVP-TE LSP, this
document defines a new flag in the Attributes Flags TLV of the LSP
Attributes object defined in [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]:
Bit Number 7: Non-PHP behavior flag
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
In order to indicate to the ingress LSR that the egress LSR
recognizes the "Non-PHP behavior flag", the same bit is used in the
Flags field of the Record Route Object (RRO) Attributes subobject.
An ingress LSR sets the "Non-PHP behavior flag" to signal that the
egress LSRs SHOULD assign a non-NULL label for the LSP being
signaled. This flag MUST NOT be modified by any other LSRs in the
network. LSRs other than the egress LSRs SHOULD ignore this flag.
If an egress LSR receiving the Path message supports the LSP
Attributes object and the Attributes Flags TLV and also recognizes
the "Non-PHP behavior flag", it MUST allocate a non-NULL local label.
The egress LSR MUST also set the "Non-PHP behavior flag" in the Flags
field of the RRO Attributes subobject.
If the egress LSR
- supports the LSP Attributes object but does not recognize the
Attributes Flags TLV; or
- supports the LSP Attributes object and recognizes the Attributes
Flags TLV, but does not recognize the "Non-PHP behavior flag";
then it silently ignores the request according to the processing
rules of [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>].
An ingress LSR requesting non-PHP behavior SHOULD examine the "Non-
PHP behavior flag" in the Flags field of the RRO Attributes subobject
and MAY send a Path Tear to the egress, which has not set the "Non-
PHP behavior flag". An ingress LSR requesting non-PHP behavior MAY
also examine the label value corresponding to the egress LSR(s) in
the RRO and MAY send a Path Tear to the egress, which assigns a NULL
label value.
When signaling a P2MP LSP, a source node may wish to solicit an
individual response to the "Non-PHP behavior flag" from the leaf
nodes. Given the constraints on how the LSP Attributes may be
carried in Path and Resv messages according to [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], in this
situation, the source node MUST use a separate Path message for each
leaf in networks where [<a href="./rfc6510" title=""Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects"">RFC6510</a>] is not supported. In networks with
[<a href="./rfc6510" title=""Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects"">RFC6510</a>] deployed, either a single leaf per Path message or multiple
leaves per Path message MAY be used by the source node.
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Signaling OOB Mapping Indication</span>
This document defines a single flag to indicate that the normal
binding mechanism of an RSVP session is overridden. The actual out-
of-band mappings are beyond the scope of this document. The flag is
carried in the Attributes Flags TLV of the LSP Attributes object
defined in [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>] and is defined as follows:
Bit Number 8: OOB mapping flag
In order to indicate to the ingress LSR that the egress LSR
recognizes the "OOB mapping flag", the following same bit is used in
the Flags field of the Record Route object (RRO) Attributes
subobject.
An ingress LSR sets the "OOB mapping flag" to signal the egress LSR
that the binding of RSVP-TE LSP to an application and a payload
identifier is being signaled out-of-band. This flag MUST NOT be
modified by any other LSRs in the network. LSRs other than the
egress LSRs SHOULD ignore this flag.
When an egress LSR that supports the "OOB mapping flag" receives a
Path message with that flag set, the egress LSR MUST set the "OOB
mapping flag" in the Flags field of the RRO Attributes subobject.
The rest of the RSVP signaling proceeds as normal. However, the LSR
MUST have received the OOB mapping before accepting traffic on the
LSP. This implies that the egress LSR MUST NOT set up forwarding
state for the LSP before it receives the OOB mapping.
Note that the payload information SHOULD be supplied by the OOB
mapping. If the egress LSR receives the payload information from OOB
mapping, then the LSR MUST ignore the L3PID (Layer 3 Protocol ID) in
the Label Request Object [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
If the egress LSR
- supports the LSP Attributes object but does not recognize the
Attributes Flags TLV; or
- supports the LSP Attributes object and recognizes the Attributes
Flags TLV, but does not recognize the "OOB mapping flag";
then it silently ignores the request according to the processing
rules of [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>].
An ingress LSR requesting OOB mapping SHOULD examine the "OOB mapping
flag" in the Flags field of the RRO Attributes subobject and MAY send
a Path Tear to the egress, which has not set the "OOB mapping flag".
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
When signaling a P2MP LSP, a source node may wish to solicit an
individual response to the "OOB mapping flag" from the leaf nodes.
Given the constraints on how the LSP Attributes object may be carried
in Path and Resv messages according to [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], in this situation,
the source node MUST use a separate Path message for each leaf in
networks where [<a href="./rfc6510" title=""Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects"">RFC6510</a>] is not supported. In networks with
[<a href="./rfc6510" title=""Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects"">RFC6510</a>] deployed, either a single leaf per Path message or multiple
leaves per Path message MAY be used by the source node.
In deploying applications where the egress LSR receives the binding
of the RSVP-TE LSP to an application and a payload identifier using
an OOB mechanism, it is important to recognize that the OOB mapping
is sent asynchronously with respect to the signaling of RSVP-TE LSP.
The egress LSR only installs forwarding state for the LSP after it
receives the OOB mapping. In deploying applications using an OOB
mechanism, an ingress LSR may need to know when the egress is
properly set up for forwarding (i.e., has received the OOB mapping).
How the ingress LSR determines that the LSR is properly set up for
forwarding at the egress LSR is beyond the scope of this document.
Nonetheless, if the OOB mapping is not received by the egress LSR
within a reasonable time, the procedure defined in <a href="#section-2.4">Section 2.4</a> to
tear down the LSP is followed.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Relationship between OOB and Non-PHP Flags</span>
The "Non-PHP behavior flag" and "OOB mapping flag" can appear and be
processed independently of each other. However, as mentioned
earlier, in the context of the applications discussed in this
document, OOB mapping requires non-PHP behavior. An ingress LSR
requesting the OOB mapping MAY also set the "Non-PHP behavior flag"
in the LSP Attributes object in the Path message.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Egress Procedure for Label Binding</span>
RSVP-TE signaling completion and the OOB mapping information
reception happen asynchronously at the egress. As mentioned in
<a href="#section-2.2">Section 2.2</a>, egress waits for the OOB mapping before accepting
traffic on the LSP. Nonetheless, MPLS Operations, Administration,
and Maintenance (OAM) mechanisms, e.g., LSP ping and traceroute, as
defined in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>] and [<a href="./rfc6425" title=""Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"">RFC6425</a>], are expected to work
independently of OOB mapping learning process.
In order to avoid unnecessary use of the resources and possible
black-holing of traffic, an egress LSR MAY send a Path Error message
if the OOB mapping information is not received within a reasonable
time. This Path Error message SHOULD include the error code/sub-code
"Notify Error / no OOB mapping received" for all affected LSPs. If a
notify request was included when the LSP was initially set up, a
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
Notify message (as defined in [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]) MAY also be used for
delivery of this information to the ingress LSR. An egress LSR MAY
implement a cleanup timer for this purpose. The time-out value is a
local decision at the egress, with a RECOMMENDED default value of 60
seconds.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>
The addition of non-PHP behavior adds a variety of attacks on the
label assigned by the egress node. As change in the value of the
egress label reported in the RRO can cause the LSP to be torn down,
additional security considerations for protecting labels assigned by
the egress node are required. Security mechanisms as identified in
[<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>], [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>], [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], and [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]
can be used for this purpose. This document does not introduce any
additional security issues above those identified in [<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>],
[<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>], [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], and [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
The following changes to the Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Parameters registry are required.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Attribute Flags for LSP Attributes Object</span>
The following new flags are defined for the Attributes Flags TLV in
the LSP Attributes object.
o Non-PHP behavior flag:
This flag is used in the Attributes Flags TLV in a Path message.
The flag has a corresponding new flag to be used in the RRO
Attributes subobject. As per [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], the bit numbering in the
Attribute Flags TLV and the RRO Attributes subobject is identical.
That is, the same attribute is indicated by the same bit in both
places. This flag is not allowed in the Attributes Flags TLV in a
Resv message. Specifically, attributes of this flag are as
follows:
- Bit Number: 7
- Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No
- Attribute flag carried in RRO message: Yes
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
o OOB mapping flag:
This flag is used in the Attributes Flags TLV in a Path message.
The flag has a corresponding new flag to be used in the RRO
Attributes subobject. As per [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], the bit numbering in the
Attribute Flags TLV and the RRO Attributes subobject is identical.
That is, the same attribute is indicated by the same bit in both
places. This flag is not allowed in the Attributes Flags TLV in a
Resv message. Specifically, attributes of this flag are as
follows:
- Bit Number: 8
- Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No
- Attribute flag carried in RRO message: Yes
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. New RSVP Error Sub-Code</span>
For Error Code = 25 "Notify Error" (see [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]), the following
sub-code is defined.
Sub-code Value
-------- -----
No OOB mapping received 12
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
The authors would like to thank Yakov Rekhter for his suggestions on
this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.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-RFC2205">RFC2205</a>] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.
[<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.
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", <a href="./rfc3473">RFC 3473</a>,
January 2003.
[<a id="ref-RFC4875">RFC4875</a>] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", <a href="./rfc4875">RFC 4875</a>, May
2007.
[<a id="ref-RFC5420">RFC5420</a>] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", <a href="./rfc5420">RFC 5420</a>, February 2009.
[<a id="ref-RFC6510">RFC6510</a>] Berger, L. and G. Swallow, "Resource Reservation Protocol
(RSVP) Message Formats for Label Switched Path (LSP)
Attributes Objects", <a href="./rfc6510">RFC 6510</a>, February 2012.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC4379">RFC4379</a>] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", <a href="./rfc4379">RFC 4379</a>,
February 2006.
[<a id="ref-RFC4761">RFC4761</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", <a href="./rfc4761">RFC 4761</a>, January 2007.
[<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.
[<a id="ref-RFC6425">RFC6425</a>] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", <a href="./rfc6425">RFC 6425</a>, November 2011.
[<a id="ref-RFC6513">RFC6513</a>] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
MPLS/BGP IP VPNs", <a href="./rfc6513">RFC 6513</a>, February 2012.
<span class="grey">Ali, 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="./rfc6511">RFC 6511</a> Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012</span>
Authors' Addresses
Zafar Ali
Cisco Systems, Inc.
EMail: zali@cisco.com
George Swallow
Cisco Systems, Inc.
EMail: swallow@cisco.com
Rahul Aggarwal
Juniper Networks
EMail: raggarwa_1@yahoo.com
Ali, et al. Standards Track [Page 10]
</pre>
|
