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) L. Berger
Request for Comments: 6689 LabN
Category: Informational July 2012
ISSN: 2070-1721
<span class="h1">Usage of the RSVP ASSOCIATION Object</span>
Abstract
The Resource Reservation Protocol (RSVP) ASSOCIATION object is
defined in the context of GMPLS-controlled label switched paths
(LSPs). In this context, the object is used to associate recovery
LSPs with the LSP they are protecting. This document reviews how the
association is to be provided in the context of GMPLS recovery. No
new procedures or mechanisms are defined by this document, and it is
strictly informative in nature.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <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/rfc6689">http://www.rfc-editor.org/info/rfc6689</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
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.
<span class="grey">Berger Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Background ......................................................<a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. LSP Association ............................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. End-to-End Recovery LSP Association ........................<a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. Segment Recovery LSP Association ...........................<a href="#page-7">7</a>
<a href="#section-2.4">2.4</a>. Resource Sharing LSP Association ...........................<a href="#page-8">8</a>
<a href="#section-3">3</a>. Association of GMPLS Recovery LSPs ..............................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Acknowledgments ................................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
End-to-end and segment recovery are defined for GMPLS-controlled
label switched paths (LSPs) in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>], respectively.
Both definitions use the ASSOCIATION object to associate recovery
LSPs with the LSP they are protecting. This document provides
additional narrative on how such associations are to be identified.
This document does not define any new procedures or mechanisms and is
strictly informative in nature.
It may not be immediately obvious to the informed reader why this
document is necessary; however, questions were repeatedly raised in
the Common Control and Measurement Plane (CCAMP) working group on the
proper interpretation of the ASSOCIATION object in the context of
end-to-end and segment recovery, and the working group agreed that
this document should be produced in order to close the matter. This
document formalizes the explanation provided in an e-mail to the
working group authored by Adrian Farrel, see [<a href="#ref-AF-EMAIL" title=""Re: Clearing up your misunderstanding of the Association ID"">AF-EMAIL</a>]. This
document in no way modifies the normative definitions of end-to-end
and segment recovery, see [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] or [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
This section reviews the definition of LSP association in the
contexts of end-to-end and segment recovery as defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. This section merely reiterates what has been defined;
if differences exist between this text and [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] or [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>],
the earlier RFCs provide the authoritative text.
<span class="grey">Berger Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. LSP Association</span>
[<a id="ref-RFC4872">RFC4872</a>] introduces the concept and mechanisms to support the
association of one LSP to another LSP across different RSVP - Traffic
Engineering (RSVP-TE) sessions. Such association is enabled via the
introduction of the ASSOCIATION object. The ASSOCIATION object is
defined in <a href="./rfc4872#section-16">Section 16 of [RFC4872]</a>. It is explicitly defined as
having both general application and specific use within the context
of recovery. End-to-end recovery usage is defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and
is covered in <a href="#section-2.2">Section 2.2</a> of this document. Segment recovery usage
is defined in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>] and is covered in <a href="#section-2.3">Section 2.3</a> of this
document. Resource sharing type LSP association is also defined in
[<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. While strictly speaking, such association is beyond the
scope of this document, it is covered in <a href="#section-2.4">Section 2.4</a> of this document
for completeness. The remainder of this section covers generic usage
of the ASSOCIATION object.
In general, LSP association using the ASSOCIATION object can take
place based on the values carried in the ASSOCIATION object. This
means that association between LSPs can take place independently of
and across different sessions. This is a significant enhancement
from the association of LSPs that is possible in base MPLS [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]
and GMPLS [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>].
When using the ASSOCIATION object, LSP association is always
initiated by an upstream node that inserts appropriate ASSOCIATION
objects in the Path message of LSPs that are to be associated.
Downstream nodes then correlate LSPs based on received ASSOCIATION
objects. Multiple types of LSP association are supported by the
ASSOCIATION object, and downstream correlation is made based on the
type.
[<a id="ref-RFC4872">RFC4872</a>] defines Class Types (C-Types) 1 and 2 of the ASSOCIATION
object. Both objects have essentially the same semantics, only
differing in the type of address carried (IPv4 and IPv6). The
defined objects carry multiple fields. The fields, taken together,
enable the identification of which LSPs are in association with one
another. The [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]-defined fields are:
o Association Type:
This field identifies the usage, or application, of the
ASSOCIATION object. The currently defined values are
"Recovery" [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and "Resource Sharing" [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. This
field also scopes the interpretation of the object. In other
words, the type field is included when matching LSPs (i.e., the
type fields must match), and the way associations are
identified may be type dependent.
<span class="grey">Berger Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
o Association Source:
This field is used to provide global scope (within the address
space) to the identified association. There are no specific
rules in the general case for which an address should be used
by a node creating an ASSOCIATION object beyond that the
address is "associated to the node that originated the
association", see [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
o Association ID:
This field provides an "identifier" that further scopes an
association. Again, this field is combined with the other
ASSOCIATION object fields to support identification of
associated LSPs. The generic definition does not provide any
specific rules on how matching is to be done, so such rules are
governed by the Association Type. Note that the definition
permits the association of an arbitrary number of LSPs.
As defined, the ASSOCIATION object may only be carried in a Path
message, so LSP association takes place based on the Path state. The
definition permits one or more objects to be present. The support
for multiple objects enables an LSP to be associated with other LSPs
in more than one way at a time. For example, an LSP may carry one
ASSOCIATION object to associate the LSP with another LSP for
end-to-end recovery, and at the same time carry a second ASSOCIATION
object to associate the LSP with another LSP for segment recovery,
and at the same time carry a third ASSOCIATION object to associate
the LSP with yet another LSP for resource sharing.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. End-to-End Recovery LSP Association</span>
The association of LSPs in support of end-to-end LSP recovery is
defined in <a href="./rfc4872#section-16.2">Section 16.2 of [RFC4872]</a>. There are also several
additional related conformance statements (i.e., use of [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>]
defined key words) in Sections <a href="#section-7.3">7.3</a>, <a href="#section-8.3">8.3</a>, <a href="#section-9.3">9.3</a>, and <a href="#section-11.1">11.1</a> of [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
When analyzing the definition, as with any Standards Track RFC, it is
critical to note and differentiate which statements are made using
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] defined key words, which relate to conformance, and which
statements are made without such key words, and are thereby only
informative in nature.
As defined in <a href="#section-16.2">Section 16.2</a>, end-to-end recovery-related LSP
association may take place in two distinct forms:
a. Between multiple (one or more) working LSPs and a single shared
(associated) recovery LSP. This form essentially matches the
shared 1:N (N >= 1) recovery type described in the other
sections of [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
<span class="grey">Berger Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
b. Between a single working LSP and multiple (one or more)
recovery LSPs. This form essentially matches all other
recovery types described in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
Both forms share the same Association Type (Recovery) and the same
Association Source (the working LSP's tunnel sender address). They
also share the same definition of the Association ID, which is
(quoting [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]):
The Association ID MUST be set to the LSP ID of the LSP being
protected by this LSP or the LSP protecting this LSP. If unknown,
this value is set to its own signaled LSP_ID value (default).
Also, the value of the Association ID MAY change during the
lifetime of the LSP.
The interpretation of the above is fairly straightforward. The
Association ID carries one of three values:
- The LSP ID of the LSP being protected.
- The LSP ID of the protection LSP.
- In the case where the matching LSP is not yet known (i.e.,
initiated), the LSP ID value of the LSP itself.
The text also explicitly allows for changing the Association ID
during the lifetime of an LSP. However, this is only an option, and
is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD").
It should be noted that [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] does not describe when such a
change should be initiated or the procedures for executing such a
change. Clearly, care needs to be taken when changing the
Association ID to ensure that the old association is not lost during
the transition to a new association.
The text does not preclude, and it is therefore assumed, that one or
more ASSOCIATION objects may also be added to an LSP that was
originated without any ASSOCIATION objects. Again, this is a case
that is not explicitly discussed in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
From the above, this means that the following combinations may occur:
Case 1. When the ASSOCIATION object of the LSP being protected is
initialized before the ASSOCIATION objects of any recovery
LSPs are initialized, the Association ID in the LSP being
protected and any recovery LSPs will carry the same value,
and this value will be the LSP ID value of the LSP being
protected.
<span class="grey">Berger Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
Case 2. When the ASSOCIATION object of a recovery LSP is
initialized before the ASSOCIATION object of any protected
LSP is initialized, the Association ID in the recovery LSP
and any LSPs being protected by that LSP will carry the
same value, and this value will be the LSP ID value of the
recovery LSP.
Case 3. When the ASSOCIATION objects of both the LSP being
protected and the recovery LSP are concurrently
initialized, the value of the Association ID carried in
the LSP being protected is the LSP ID value of the
recovery LSP, and the value of the Association ID carried
in the recovery LSP is the LSP ID value of the LSP being
protected. As this case can only be applied to LSPs with
matching tunnel sender addresses, the scope of this case
is limited to end-to-end recovery. Note that this is
implicit in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>], as its scope is limited to end-to-
end recovery.
In practical terms, Case 2 will only occur when using the shared 1:N
(N >= 1) end-to-end recovery type, and Case 1 will occur with all
other end-to-end recovery types. Case 3 is allowed, and it is
subject to interpretation as to how often it will occur. Some
believe that this will be the common case and, furthermore, that
working and recovery LSPs will often first be initiated without any
ASSOCIATION objects, and then Case 3 objects will be added once the
LSPs are established. Others believe that Case 3 will rarely, if
ever occur. Such perspectives have little impact on
interoperability, as an [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]-compliant implementation needs to
properly handle (identify associations for) all three cases.
It is important to note that <a href="./rfc4872#section-16.2">Section 16.2 of [RFC4872]</a> provides no
further requirements on how or when the Association ID value is to be
selected. The other sections of the document do provide further
narrative and three additional requirements. In general, the
narrative highlights Case 3 identified above but does not preclude
the other cases. The three additional requirements are, by [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
section number:
o <a href="#section-7.3">Section 7.3</a> -- "The Association ID MUST be set by default to the
LSP ID of the protected LSP corresponding to N = 1."
When considering this statement together with the three cases
enumerated above, it can be seen that this statement clarifies
which LSP ID value should be used when a single shared protection
LSP is established simultaneously with Case 3, or after Case 2,
and with more than one LSP to be protected.
<span class="grey">Berger Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
o <a href="#section-8.3">Section 8.3</a> -- "Secondary protecting LSPs are signaled by setting
in the new PROTECTION object the S bit and the P bit to 1, and in
the ASSOCIATION object, the Association ID to the associated
primary working LSP_ID, which MUST be known before signaling of
the secondary LSP."
This requirement clarifies that when using the "Rerouting without
Extra-Traffic" type of recovery, it is required to follow either
Case 1 or 3, but not 2, as enumerated above.
o <a href="#section-9.3">Section 9.3</a> -- "Secondary protecting LSPs are signaled by setting
in the new PROTECTION object the S bit and the P bit to 1, and in
the ASSOCIATION object, the Association ID to the associated
primary working LSP_ID, which MUST be known before signaling of
the secondary LSP."
This requirement clarifies that when using the "Shared-Mesh
Restoration" type of recovery, it is required to follow either
Case 1 or 3, but not 2, as enumerated above.
o <a href="#section-11.1">Section 11.1</a> -- "In both cases, the Association ID of the
ASSOCIATION object MUST be set to the LSP ID value of the
signaled LSP."
This requirement clarifies that when using the "LSP Rerouting"
type of recovery, it is required to follow either Case 1 or 3,
but not 2, as enumerated above.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Segment Recovery LSP Association</span>
GMPLS segment recovery is defined in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. Segment recovery
reuses the LSP association mechanisms, including the Association Type
field value, defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]. The primary text to this effect
in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>] is:
3.2.1. Recovery Type Processing
Recovery type processing procedures are the same as those defined
in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>], but processing and identification occur with respect
to segment recovery LSPs. Note that this means that multiple
ASSOCIATION objects of type recovery may be present on an LSP.
This statement means that Case 2, as enumerated above, is to be
followed; furthermore, the Association Source is set to the tunnel
sender address of the segment recovery LSPs. The explicit exclusion
of Case 3 is not listed, as its non-applicability is considered
<span class="grey">Berger Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
obvious to the informed reader. (Perhaps having this exclusion
explicitly identified would have obviated the need for this
document.)
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Resource Sharing LSP Association</span>
<a href="./rfc4873#section-3.2.2">Section 3.2.2 of [RFC4873]</a> defines an additional type of LSP
association that is used for "Resource Sharing". Resource sharing
enables the sharing of resources across LSPs with different SESSION
objects. Without this object, only sharing across LSPs with a shared
SESSION object is possible, see [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
Resource sharing is indicated using a new Association Type value. As
the Association Type field value is not the same as what is used in
recovery type LSP association, the semantics used for the association
of LSPs using an ASSOCIATION object containing the new type differs
from recovery type LSP association.
<a href="./rfc4873#section-3.2.2">Section 3.2.2 of [RFC4873]</a> states the following rules for the
construction of an ASSOCIATION object in support of resource sharing
type LSP association:
o The Association Type value is set to "Resource Sharing".
o Association Source is set to the originating node's router
address.
o The Association ID is set to a value that uniquely identifies
the set of LSPs to be associated.
The setting of the Association ID value to the working LSP's
LSP ID value is mentioned, but using the "MAY" key word. Per
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>], this translates to the use of the LSP ID value as
being completely optional and that the choice of Association ID
is truly up to the originating node.
Additionally, the identical ASSOCIATION object is used for all LSPs
that should be associated using Resource Sharing. This differs from
recovery type LSP association where it is possible for the LSPs to
carry different Association ID fields and still be associated (see
Case 3 in <a href="#section-2.2">Section 2.2</a>).
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Association of GMPLS Recovery LSPs</span>
The previous section reviews the construction of an ASSOCIATION
object, including the selection of the value used in the Association
ID field, as defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. This section
reviews how a downstream receiver identifies that one LSP is
<span class="grey">Berger Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
associated within another LSP based on ASSOCIATION objects. Note
that this section in no way modifies the normative definitions of
end-to-end and segment recovery, see [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] or [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
As the ASSOCIATION object is only carried in Path messages, such
identification only takes place based on Path state. In order to
support the identification of the recovery type association between
LSPs, a downstream receiver needs to be able to handle all three
cases identified in <a href="#section-2.2">Section 2.2</a>. Cases 1 and 2 are simple, as the
associated LSPs will carry the identical ASSOCIATION object. This is
also always true for resource sharing type LSP association, see
<a href="#section-2.4">Section 2.4</a>. Case 3 is more complicated, as it is possible for the
LSPs to carry different Association ID fields and still be
associated. The receiver also needs to allow for changes in the set
of ASSOCIATION objects included in an LSP.
Based on the [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>] definitions related to the
ASSOCIATION object, the following behavior can be followed to ensure
that a receiver always properly identifies the association between
LSPs:
o Covering Cases 1 and 2 and resource sharing type LSP
association:
For ASSOCIATION objects with the Association Type field values
of "Recovery" (1) and "Resource Sharing" (2), the association
between LSPs is identified by comparing all fields of each of
the ASSOCIATION objects carried in the Path messages associated
with each LSP. An association is deemed to exist when the same
values are carried in all fields of an ASSOCIATION object
carried in each LSP's Path message. As more than one
association may exist (e.g., in support of different
association types or end-to-end and segment recovery), all
carried ASSOCIATION objects need to be examined.
o Covering Case 3:
Any ASSOCIATION object with the Association Type field value of
"Recovery" (1) that does not yield an association in the prior
comparison needs to be checked to see if a Case 3 association
is indicated. As this case only applies to end-to-end recovery,
the first step is to locate any other LSPs with the identical
SESSION object fields and the identical tunnel sender address
fields as the LSP carrying the ASSOCIATION object. If such
LSPs exist, a case 3 association is identified by comparing the
value of the Association ID field with the LSP ID field of the
other LSP. If the values are identical, then an end-to-end
recovery association exists. As this behavior only applies to
<span class="grey">Berger Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
end-to-end recovery, this check need only be performed at the
egress.
No additional behavior is needed in order to support changes in the
set of ASSOCIATION objects included in an LSP, as long as the change
represents either a new association or a change in identifiers made
as described in <a href="#section-2.2">Section 2.2</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document reviews procedures defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]
and does not define any new procedures. As such, no new security
considerations are introduced in this document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
This document formalizes the explanation provided in an e-mail to the
working group authored by Adrian Farrel, see [<a href="#ref-AF-EMAIL" title=""Re: Clearing up your misunderstanding of the Association ID"">AF-EMAIL</a>]. This
document was written in response to questions raised in the CCAMP
working group by Nic Neate <nhn@dataconnection.com>. Valuable
comments and input were also received from Dimitri Papadimitriou,
Francois Le Faucheur, and Ashok Narayanan.
<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-RFC4872">RFC4872</a>] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", <a href="./rfc4872">RFC 4872</a>, May 2007. Lang, J., Rekhter, Y., and
Papadimitriou, D., "RSVP-TE
[<a id="ref-RFC4873">RFC4873</a>] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", <a href="./rfc4873">RFC 4873</a>, May 2007.
[<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</a>
<a href="./rfc3473">3473</a>, January 2003.
<span class="grey">Berger Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6689">RFC 6689</a> RSVP ASSOCIATION Object Usage July 2012</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-AF-EMAIL">AF-EMAIL</a>] Farrel, A. "Re: Clearing up your misunderstanding of the
Association ID", CCAMP working group mailing list,
<a href="http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html">http://www.ietf.org/mail-archive/web/ccamp/</a>
<a href="http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html">current/msg00644.html</a>, November 18, 2008.
Author's Address
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net
Berger Informational [Page 11]
</pre>
|
