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
|
<pre>Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6510 LabN
Updates: <a href="./rfc4875">4875</a>, <a href="./rfc5420">5420</a> G. Swallow
Category: Standards Track Cisco
ISSN: 2070-1721 February 2012
<span class="h1">Resource Reservation Protocol (RSVP) Message Formats for</span>
<span class="h1">Label Switched Path (LSP) Attributes Objects</span>
Abstract
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions may be signaled with a set of LSP-
specific attributes. These attributes may be carried in both Path
and Resv messages. This document specifies how LSP attributes are to
be carried in RSVP Path and Resv messages using the Routing Backus-
Naur Form and clarifies related Resv message formats. This document
updates <a href="./rfc4875">RFC 4875</a> and <a href="./rfc5420">RFC 5420</a>.
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/rfc6510">http://www.rfc-editor.org/info/rfc6510</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
to this document. Code Components extracted from this document must
<span class="grey">Berger & Swallow Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
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-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>. Path Messages ...................................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Path Message Format ........................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Resv Messages ...................................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Resv Message Format -- Per LSP Operational Status ..........<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Resv Message Format -- Per S2L Operational Status ..........<a href="#page-6">6</a>
<a href="#section-3.2.1">3.2.1</a>. Compatibility .......................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Acknowledgments .................................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. References ......................................................<a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. Normative References .......................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Informative References .....................................<a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Signaling in support of Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs)
is defined in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] and [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]. [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] defines signaling
support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs.
Two LSP Attributes objects are defined in [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]. These objects
may be used to provide additional information related to how an LSP
should be set up when carried in a Path message and, when carried in
a Resv message, how an LSP has been established. The definition of
the objects includes a narrative description of related message
formats (see <a href="./rfc5420#section-9">Section 9 of [RFC5420]</a>). This definition does not
provide the related Routing Backus-Naur Form (BNF) [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>] that is
typically used to define how messages are to be constructed using
RSVP objects. The current message format description has led to the
open question of how the LSP Attributes objects are to be processed
in Resv messages of P2MP LSPs (which are defined in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]).
This document provides the BNF for Path and Resv messages carrying
the LSP Attributes object. The definition clarifies how the objects
are to be carried for all LSP types. Both Path and Resv message BNF
is provided for completeness.
<span class="grey">Berger & Swallow Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
This document presents the related RSVP message formats as modified
by [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]. This document modifies formats defined in [<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>], 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>]. See [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>] for the syntax used by RSVP.
Unmodified formats are not listed. An example of a case where the
modified formats are applicable is described in [<a href="./rfc6511" title=""Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths"">RFC6511</a>].
<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>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Path Messages</span>
This section updates [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]. Path message formatting is
unmodified from the narrative description provided in <a href="./rfc5420#section-9">Section 9 of
[RFC5420]</a>:
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object
MAY be carried in a Path message....
The order of objects in RSVP-TE messages is recommended, but
implementations must be capable of receiving the objects in any
meaningful order.
On a Path message, the LSP_ATTRIBUTES object and
LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed
immediately after the SESSION_ATTRIBUTE object if it is present,
or otherwise immediately after the LABEL_REQUEST object.
If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES
object are present, the LSP_REQUIRED_ATTRIBUTES object is
RECOMMENDED to be placed first.
LSRs MUST be prepared to receive these objects in any order in any
position within a Path message. Subsequent instances of these
objects within a Path message SHOULD be ignored and MUST be
forwarded unchanged.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Path Message Format</span>
This section presents the Path message format as modified by
[<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]. Unmodified formats are not listed.
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<span class="grey">Berger & Swallow Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <LSP_REQUIRED_ATTRIBUTES> ... ]
[ <LSP_ATTRIBUTES> ... ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L sub-LSP descriptor list>]
Note that PathErr and PathTear messages are not impacted by the
introduction of the LSP Attributes objects.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Resv Messages</span>
This section updates [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] and [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]. <a href="./rfc5420#section-9">Section 9 of [RFC5420]</a>
contains the following text regarding Resv messages:
The LSP_ATTRIBUTES object MAY be carried in a Resv message.
The order of objects in RSVP-TE messages is recommended, but
implementations must be capable of receiving the objects in any
meaningful order.
...
On a Resv message, the LSP_ATTRIBUTES object is placed in the flow
descriptor and is associated with the FILTER_SPEC object that
precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be
placed immediately after the LABEL object.
LSRs MUST be prepared to receive this object in any order in any
position within a Resv message, subject to the previous note.
Only one instance of the LSP_ATTRIBUTES object is meaningful
within the context of a FILTER_SPEC object. Subsequent instances
of the object SHOULD be ignored and MUST be forwarded unchanged.
This means that LSP attributes may be present per sender (LSP) and
allows for the LSP Attributes object to be modified using make-
before-break (see [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]). This definition is sufficient for
point-to-point ([<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] and [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]) LSPs and the special case
where all point-to-multipoint source-to-leaf (S2L) sub-LSPs
([<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]) report the same operational status (as used in
[<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]). However, this definition does not allow for different
<span class="grey">Berger & Swallow Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
egress Label Switching Routers (LSRs) to report different operational
statuses. In order to allow such reporting, this document adds the
following definition:
An LSR that wishes to report the operational status of a (point-
to-multipoint) S2L sub-LSP may include the LSP Attributes object
in a Resv message or update the object that is already carried in
a Resv message. LSP Attributes objects representing S2L sub-LSP
status MUST follow a S2L_SUB_LSP object. Only the first instance
of the LSP Attributes object is meaningful within the context of a
S2L_SUB_LSP object. Subsequent instances of the object SHOULD be
ignored and MUST be forwarded unchanged.
When an LSP Attributes object is present before the first
S2L_SUB_LSP object, the LSP Attributes object represents the
operational status of all S2L sub-LSPs identified in the message.
Subsequent instances of the object (e.g., in the filter spec or
the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be
forwarded unchanged. When a branch node is combining Resv state
from multiple receivers into a single Resv message and an LSP
Attributes object is present before the first S2L_SUB_LSP object
in a received Resv message, the received LSP Attributes object
SHOULD be moved to follow the first received S2L_SUB_LSP object
and then SHOULD be duplicated for, and placed after, each
subsequent S2L_SUB_LSP object.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Resv Message Format -- Per LSP Operational Status</span>
This section presents the Resv message format for LSPs as modified by
[<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>] and can be used to report operational status per LSP.
Unmodified formats are not listed. The following is based on
[<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>].
<FF flow descriptor list> ::= <FF flow descriptor>
[ <FF flow descriptor list> ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <LSP_ATTRIBUTES> ... ]
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
[ <SE filter spec list> ]
<span class="grey">Berger & Swallow Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
<SE filter spec> ::= <FILTER_SPEC> <LABEL>
[ <LSP_ATTRIBUTES> ... ]
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Resv Message Format -- Per S2L Operational Status</span>
This section presents the Resv message format for LSPs as modified by
this document and [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], and can be used to report operational
status per S2L sub-LSP. Unmodified formats are not listed. The
following is based on [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>].
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor list> ::=
<S2L sub-LSP flow descriptor>
[ <S2L sub-LSP flow descriptor list> ]
<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
[ <LSP_ATTRIBUTES> ... ]
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Compatibility</span>
A node that supports [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] and [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>], but not this document,
will interpret the first LSP Attributes object present in a received
message, which is formatted as described in this document, as
representing LSP operational status rather than S2L sub-LSP status.
It is unclear if this is a significant issue as the LSP Attributes
object is currently considered to be an unsuitable mechanism for
reporting operational status of P2MP LSPs, for example, see <a href="./rfc6511#section-2.1">Section</a>
<a href="./rfc6511#section-2.1">2.1 of [RFC6511]</a>. The intent of this document is to correct this
limitation; it is expected that networks that wish to make use of
such operational reporting will deploy this extension.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document clarifies usage of objects defined in [<a href="./rfc5420" title=""Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)"">RFC5420</a>]. No
new information is conveyed; therefore, no additional security
considerations are included here. For a general discussion on MPLS-
and GMPLS-related security issues, see the MPLS/GMPLS security
framework [<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>].
<span class="grey">Berger & Swallow Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
The authors would like to acknowledge the contributions of Adrian
Farrel.
<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-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-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-RFC5511">RFC5511</a>] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", <a href="./rfc5511">RFC 5511</a>, April 2009.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<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-RFC6511">RFC6511</a>] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
Label Switched Paths", <a href="./rfc6511">RFC 6511</a>, February 2012.
<span class="grey">Berger & Swallow Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6510">RFC 6510</a> RSVP Message Formats for LSP Attributes February 2012</span>
Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net
George Swallow
Cisco Systems, Inc.
EMail: swallow@cisco.com
Berger & Swallow Standards Track [Page 8]
</pre>
|
