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
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Request for Comments: 8537 Cisco Systems, Inc.
Updates: <a href="./rfc4090">4090</a>, <a href="./rfc7551">7551</a> H. Shah
Category: Standards Track Ciena
ISSN: 2070-1721 J. Whittaker
Verizon
February 2019
<span class="h1">Updates to the Fast Reroute Procedures for Co-routed Associated</span>
<span class="h1">Bidirectional Label Switched Paths (LSPs)</span>
Abstract
Resource Reservation Protocol (RSVP) association signaling can be
used to bind two unidirectional Label Switched Paths (LSPs) into an
associated bidirectional LSP. When an associated bidirectional LSP
is co-routed, the reverse LSP follows the same path as its forward
LSP. This document updates the fast reroute procedures defined in
<a href="./rfc4090">RFC 4090</a> to support both single-sided and double-sided provisioned
associated bidirectional LSPs. This document also updates the
procedure for associating two reverse LSPs defined in <a href="./rfc7551">RFC 7551</a> to
support co-routed bidirectional LSPs. The fast reroute procedures
can ensure that, for the co-routed LSPs, traffic flows on co-routed
paths in the forward and reverse directions after a failure event.
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="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8537">https://www.rfc-editor.org/info/rfc8537</a>.
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
Copyright Notice
Copyright (c) 2019 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="https://trustee.ietf.org/license-info">https://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>. Assumptions and Considerations .............................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Key Word Definitions .......................................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-2.2.1">2.2.1</a>. Forward Unidirectional LSPs .........................<a href="#page-5">5</a>
<a href="#section-2.2.2">2.2.2</a>. Reverse Co-routed Unidirectional LSPs ...............<a href="#page-5">5</a>
<a href="#section-3">3</a>. Problem Statement ...............................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Fast Reroute Bypass Tunnel Assignment ......................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Node Protection Bypass Tunnels .............................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Bidirectional LSP Association at Midpoints .................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Signaling Procedure .............................................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Associated Bidirectional LSP Fast Reroute ..................<a href="#page-8">8</a>
4.1.1. Restoring Co-routing with Node Protection
Bypass Tunnels ......................................<a href="#page-9">9</a>
<a href="#section-4.1.2">4.1.2</a>. Unidirectional Link Failures .......................<a href="#page-10">10</a>
<a href="#section-4.1.3">4.1.3</a>. Revertive Behavior after Fast Reroute ..............<a href="#page-10">10</a>
<a href="#section-4.1.4">4.1.4</a>. Bypass Tunnel Provisioning .........................<a href="#page-10">10</a>
<a href="#section-4.1.5">4.1.5</a>. One-to-One Bypass Tunnel ...........................<a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Bidirectional LSP Association at Midpoints ................<a href="#page-11">11</a>
<a href="#section-5">5</a>. Compatibility ..................................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-13">13</a>
<a href="#appendix-A">Appendix A</a>. Extended Association ID ..............................<a href="#page-14">14</a>
Acknowledgments ...................................................<a href="#page-16">16</a>
Authors' Addresses ................................................<a href="#page-16">16</a>
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
Object is specified in [<a href="./rfc6780" title=""RSVP ASSOCIATION Object Extensions"">RFC6780</a>] and can be used generically to
associate Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs).
[<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>] defines mechanisms for binding two point-to-point (P2P)
unidirectional LSPs [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] into an associated bidirectional LSP.
There are two models described in [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>] for provisioning an
associated bidirectional LSP: single-sided and double-sided. In both
models, the reverse LSP of the bidirectional LSP may or may not be
co-routed and follow the same path as its forward LSP.
In some packet transport networks, there are requirements where the
reverse LSP of a bidirectional LSP needs to follow the same path as
its forward LSP [<a href="./rfc6373" title=""MPLS Transport Profile (MPLS- TP) Control Plane Framework"">RFC6373</a>]. The MPLS Transport Profile (MPLS-TP)
[<a href="./rfc6370" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">RFC6370</a>] architecture facilitates the co-routed bidirectional LSP by
using GMPLS extensions [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>] to achieve congruent paths.
However, RSVP association signaling allows enabling co-routed
bidirectional LSPs without having to deploy GMPLS extensions in the
existing networks. The association signaling also allows taking
advantage of the existing TE and fast reroute mechanisms in the
network.
[<a id="ref-RFC4090">RFC4090</a>] defines fast reroute extensions for RSVP-TE LSPs, which are
also applicable to the associated bidirectional LSPs. [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]
defines fast reroute procedures for GMPLS signaled bidirectional LSPs
such as coordinating bypass tunnel assignments in the forward and
reverse directions of the LSP. The mechanisms defined in [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]
are also useful for the fast reroute of associated bidirectional
LSPs.
This document updates the fast reroute procedures defined in
[<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] to support both single-sided and double-sided provisioned
associated bidirectional LSPs. This document also updates the
procedure for associating two reverse LSPs defined in [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>] to
support co-routed bidirectional LSPs. The fast reroute procedures
can ensure that for the co-routed LSPs, traffic flows on co-routed
paths in the forward and reverse directions after fast reroute.
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Assumptions and Considerations</span>
The following assumptions and considerations apply to this document:
o The fast reroute procedure for the unidirectional LSPs is defined
in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] and is not modified by this document.
o The fast reroute procedure when using unidirectional bypass
tunnels is defined in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] and is not modified by this
document.
o This document assumes that the fast reroute bypass tunnels used
for protected associated bidirectional LSPs are also associated
bidirectional.
o This document assumes that the fast reroute bypass tunnels used
for protected co-routed associated bidirectional LSPs are also co-
routed associated bidirectional.
o The fast reroute procedure to coordinate the bypass tunnel
assignment defined in this document may be used for protected
associated bidirectional LSPs that are not co-routed but requires
that the downstream Point of Local Repair (PLR) and Merge Point
(MP) pair of the forward LSP matches the upstream MP and PLR pair
of the reverse LSP.
o Unless otherwise specified in this document, the fast reroute
procedures defined in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] are used for associated
bidirectional LSPs.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Key Word Definitions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Terminology</span>
The reader is assumed to be familiar with the terminology defined in
[<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="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>], [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>], and [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>].
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Forward Unidirectional LSPs</span>
Two reverse unidirectional P2P LSPs are set up in opposite directions
between a pair of source and destination nodes to form an associated
bidirectional LSP. In the case of single-sided provisioned LSP, the
originating LSP with a REVERSE_LSP Object [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>] is identified as
a forward unidirectional LSP. In the case of double-sided
provisioned LSP, the LSP originating from the higher node address (as
source) and terminating on the lower node address (as destination) is
identified as a forward unidirectional LSP.
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Reverse Co-routed Unidirectional LSPs</span>
Two reverse unidirectional P2P LSPs are set up in opposite directions
between a pair of source and destination nodes to form an associated
bidirectional LSP. A reverse unidirectional LSP originates on the
same node where the forward unidirectional LSP terminates, and it
terminates on the same node where the forward unidirectional LSP
originates. A reverse co-routed unidirectional LSP traverses along
the same path as the forward-direction unidirectional LSP in the
opposite direction.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problem Statement</span>
As specified in [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>], in the single-sided provisioning case, the
RSVP-TE tunnel is configured only on one endpoint node of the
bidirectional LSP. An LSP for this tunnel is initiated by the
originating endpoint with the (Extended) ASSOCIATION Object
containing Association Type set to "Single-Sided Associated
Bidirectional LSP" and the REVERSE_LSP Object inserted in the RSVP
Path message. The remote endpoint then creates the corresponding
reverse TE tunnel and signals the reverse LSP in response using the
information from the REVERSE_LSP Object and other objects present in
the received RSVP Path message. As specified in [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>], in the
double-sided provisioning case, the RSVP-TE tunnel is configured on
both endpoint nodes of the bidirectional LSP. Both forward and
reverse LSPs are initiated independently by the two endpoints with
the (Extended) ASSOCIATION Object containing Association Type set to
"Double-Sided Associated Bidirectional LSP". With both single-sided
and double-sided provisioned bidirectional LSPs, the reverse LSP may
or may not be congruent (i.e., co-routed) and follow the same path as
its forward LSP.
Both single-sided and double-sided associated bidirectional LSPs
require solutions to the following issues for fast reroute to ensure
co-routing after a failure event.
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Fast Reroute Bypass Tunnel Assignment</span>
In order to ensure that the traffic flows on a co-routed path after a
link or node failure on the protected co-routed LSP path, the
midpoint PLR nodes need to assign matching bidirectional bypass
tunnels for fast reroute. Such bypass assignment requires
coordination between the PLR nodes in both the forward and reverse
directions when more than one bypass tunnel is present on a PLR node.
<-- Bypass N -->
+-----+ +-----+
| H +---------+ I |
+--+--+ +--+--+
| |
| |
LSP1 --> | LSP1 --> | LSP1 --> LSP1 -->
+-----+ +--+--+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
| |
| |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
Figure 1: Multiple Bidirectional Bypass Tunnels
As shown in Figure 1, there are two bypass tunnels available: bypass
tunnel N (on path B-H-I-C) and bypass tunnel S (on path B-F-G-C).
The midpoint PLR nodes B and C need to coordinate bypass tunnel
assignment to ensure that traffic in both directions flows through
either bypass tunnel N or bypass tunnel S after the link B-C failure.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Node Protection Bypass Tunnels</span>
When using a node protection bypass tunnel with a protected
associated bidirectional LSP, after a link failure, the forward and
reverse LSP traffic can flow on different node protection bypass
tunnels in the upstream and downstream directions.
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
<-- Bypass N -->
+-----+ +-----+
| H +------------------------+ I |
+--+--+ +--+--+
| <-- Rerouted-LSP2 |
| |
| |
| LSP1 --> LSP1 --> | LSP1 --> LSP1 -->
+--+--+ +-----+ +--+--+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +-----+ +--+--+ +-----+
<-- LSP2 | <-- LSP2 <-- LSP2 | <-- LSP2
| |
| |
| Rerouted-LSP1 --> |
+--+--+ +--+--+
| F +------------------------+ G |
+-----+ +-----+
<-- Bypass S -->
Figure 2: Node Protection Bypass Tunnels
As shown in Figure 2, after the link B-C failure, the downstream PLR
node B reroutes the protected forward LSP1 traffic over bypass tunnel
S (on path B-F-G-D) to reach downstream MP node D, whereas the
upstream PLR node C reroutes the protected reverse LSP2 traffic over
bypass tunnel N (on path C-I-H-A) to reach the upstream MP node A.
As a result, the traffic in the forward and reverse directions flows
on different bypass tunnels, which can cause the co-routed associated
bidirectional LSP to be no longer co-routed. However, unlike GMPLS
LSPs, the asymmetry of paths in the forward and reverse directions
does not result in RSVP soft-state timeout with the associated
bidirectional LSPs.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Bidirectional LSP Association at Midpoints</span>
In packet transport networks, a restoration LSP is signaled after a
link failure on the protected LSP path, and the protected LSP may or
may not be torn down [<a href="./rfc8131" title=""RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing"">RFC8131</a>]. In this case, multiple forward and
reverse LSPs of a co-routed associated bidirectional LSP may be
present at midpoint nodes with identical (Extended) ASSOCIATION
Objects. This creates an ambiguity at midpoint nodes to identify the
correct associated LSP pair for fast reroute bypass assignment (e.g.,
during the recovery phase of the RSVP graceful restart procedure).
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
LSP3 --> LSP3 --> LSP3 -->
LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+
| A +--------+ B +----X----+ C +--------+ D +--------+ E |
+-----+ +--+--+ +--+--+ +-----+ +-----+
<-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2
<-- LSP4 | | <-- LSP4 <-- LSP4
| |
| LSP3 --> |
+--+--+ +--+--+
| F +---------+ G |
+-----+ +-----+
<-- Bypass S -->
<-- LSP4
Figure 3: Restoration LSP Setup after Link Failure
As shown in Figure 3, the protected LSPs (LSP1 and LSP2) are an
associated LSP pair; similarly, the restoration LSPs (LSP3 and LSP4)
are an associated LSP pair. Both pairs belong to the same associated
bidirectional LSP and carry identical (Extended) ASSOCIATION Objects.
In this example, the midpoint node D may mistakenly associate LSP1
with the reverse LSP4 instead of the reverse LSP2 due to the matching
(Extended) ASSOCIATION Objects. This may cause the co-routed
associated bidirectional LSP to be no longer co-routed after fast
reroute. Since the bypass assignment needs to be coordinated between
the forward and reverse LSPs, this can also lead to undesired bypass
tunnel assignments.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Signaling Procedure</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Associated Bidirectional LSP Fast Reroute</span>
For both single-sided and double-sided associated bidirectional LSPs,
the fast reroute procedure specified in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] is used. In
addition, the mechanisms defined in [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>] are used as follows:
o The BYPASS_ASSIGNMENT IPv4 subobject (value 38) and IPv6 subobject
(value 39) defined in [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>] are used to coordinate bypass
tunnel assignment between the PLR nodes in both the forward and
reverse directions (see Figure 1). The BYPASS_ASSIGNMENT and
Node-ID address [<a href="./rfc4561" title=""Definition of a Record Route Object (RRO) Node-Id Sub-Object"">RFC4561</a>] subobjects MUST be added by the
downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP
Path message of the forward LSP to indicate the local bypass
tunnel assignment using the procedure defined in [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]. The
upstream node uses the bypass assignment information (namely,
bypass tunnel source address, destination address, and Tunnel ID)
in the received RSVP Path message of the protected forward LSP to
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
find the associated bypass tunnel in the reverse direction. The
upstream PLR node MUST NOT add the BYPASS_ASSIGNMENT subobject in
the RRO of the RSVP Path message of the reverse LSP.
o The downstream PLR node initiates the bypass tunnel assignment for
the forward LSP. The upstream PLR (forward-direction LSP MP) node
reflects the associated bypass tunnel assignment for the reverse-
direction LSP. The upstream PLR node MUST NOT initiate the bypass
tunnel assignment.
o If the indicated forward bypass tunnel or the associated reverse
bypass tunnel is not found, the upstream PLR SHOULD send a Notify
message [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>] with Error Code "FRR Bypass Assignment Error"
(value 44) and Sub-code "Bypass Tunnel Not Found" (value 1)
[<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>] to the downstream PLR.
o If the bypass tunnel cannot be used as described in <a href="./rfc8271#section-4.5.3">Section 4.5.3
of [RFC8271]</a>, the upstream PLR SHOULD send a Notify message
[<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>] with Error Code "FRR Bypass Assignment Error" (value 44)
and Sub-code "Bypass Assignment Cannot Be Used" (value 0)
[<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>] to the downstream PLR.
o After a link or node failure, the PLR nodes in both forward and
reverse directions trigger fast reroute independently using the
procedures defined in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] and send the forward and protected
reverse LSP modified RSVP Path messages and traffic over the
bypass tunnel. The RSVP Resv signaling of the protected forward
and reverse LSPs follows the same procedure as defined in
[<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] and is not modified by this document.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Restoring Co-routing with Node Protection Bypass Tunnels</span>
After fast reroute, the downstream MP node assumes the role of
upstream PLR and reroutes the reverse LSP RSVP Path messages and
traffic over the bypass tunnel on which the forward LSP RSVP Path
messages and traffic are received. This procedure is defined as
"restoring co-routing" in [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]. This procedure is used to
ensure that both forward and reverse LSP signaling and traffic flow
on the same bidirectional bypass tunnel after fast reroute.
As shown in Figure 2, when using a node protection bypass tunnel with
protected co-routed LSPs, asymmetry of paths can occur in the forward
and reverse directions after a link failure [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]. In order to
restore co-routing, the downstream MP node D (acting as an upstream
PLR) MUST trigger the procedure to restore co-routing and reroute the
protected reverse LSP2 RSVP Path messages and traffic over the bypass
tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving
the protected forward LSP modified RSVP Path messages and traffic
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
over the bypass tunnel S (on path D-G-F-B) from node B. The upstream
PLR node C stops receiving the RSVP Path messages and traffic for the
reverse LSP2 from node D (resulting in RSVP soft-state timeout), and
it stops sending the RSVP Path messages for the reverse LSP2 over the
bypass tunnel N (on path C-I-H-A) to node A.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Unidirectional Link Failures</span>
The unidirectional link failures can cause co-routed associated
bidirectional LSPs to be no longer co-routed after fast reroute with
both link protection and node protection bypass tunnels. However,
the unidirectional link failures in the upstream and/or downstream
directions do not result in RSVP soft-state timeout with the
associated bidirectional LSPs as upstream and downstream PLRs trigger
fast reroute independently. The asymmetry of forward and reverse LSP
paths due to the unidirectional link failure in the downstream
direction can be corrected by using the procedure to restore co-
routing specified in <a href="#section-4.1.1">Section 4.1.1</a>.
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Revertive Behavior after Fast Reroute</span>
When the revertive behavior is desired for a protected LSP after the
link is restored, the procedure defined in <a href="./rfc4090#section-6.5.2">Section 6.5.2 of [RFC4090]</a>
is followed.
o The downstream PLR node starts sending the RSVP Path messages and
traffic flow of the protected forward LSP over the restored link
and stops sending them over the bypass tunnel [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>].
o The upstream PLR node (when the protected LSP is present) also
starts sending the RSVP Path messages and traffic flow of the
protected reverse LSPs over the restored link and stops sending
them over the bypass tunnel [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>].
o For node protection bypass tunnels (see Figure 2), after restoring
co-routing, the upstream PLR node D SHOULD start sending RSVP Path
messages and traffic for the reverse LSP over the original link
(C-D) when it receives the unmodified RSVP Path messages and
traffic for the protected forward LSP over it and stops sending
them over the bypass tunnel S (on path D-G-F-B).
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Bypass Tunnel Provisioning</span>
Fast reroute bidirectional bypass tunnels can be single-sided or
double-sided associated tunnels. For both single-sided and double-
sided associated bypass tunnels, the fast reroute assignment policies
need to be configured on the downstream PLR nodes of the protected
<span class="grey">Gandhi, 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="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
LSPs that initiate the bypass tunnel assignments. For single-sided
associated bypass tunnels, these nodes are the originating endpoints
of their signaling.
<span class="h4"><a class="selflink" id="section-4.1.5" href="#section-4.1.5">4.1.5</a>. One-to-One Bypass Tunnel</span>
The fast reroute signaling procedure defined in this document can be
used for both facility backup described in <a href="./rfc4090#section-3.2">Section 3.2 of [RFC4090]</a>
and one-to-one backup described in <a href="./rfc4090#section-3.1">Section 3.1 of [RFC4090]</a>. As
described in <a href="./rfc8271#section-4.5.2">Section 4.5.2 of [RFC8271]</a>, in the one-to-one backup
method, if the associated bidirectional bypass tunnel is already in
use at the upstream PLR, it SHOULD send a Notify message [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]
with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code
"One-to-One Bypass Already in Use" (value 2) to the downstream PLR.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Bidirectional LSP Association at Midpoints</span>
In order to associate the LSPs unambiguously at a midpoint node (see
Figure 3), the endpoint node MUST signal the Extended ASSOCIATION
Object and add a unique Extended Association ID for each associated
forward and reverse LSP pair forming the bidirectional LSP. An
endpoint node MAY set the Extended Association ID to the value
formatted according to the structure shown in <a href="#appendix-A">Appendix A</a>.
o For single-sided provisioned bidirectional LSPs [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>], the
originating endpoint signals the Extended ASSOCIATION Object with
a unique Extended Association ID. The remote endpoint copies the
contents of the received Extended ASSOCIATION Object including the
Extended Association ID in the RSVP Path message of the reverse
LSP's Extended ASSOCIATION Object.
o For double-sided provisioned bidirectional LSPs [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>], both
endpoints need to ensure that the bidirectional LSP has a unique
Extended ASSOCIATION Object for each forward and reverse LSP pair
by selecting appropriate unique Extended Association IDs signaled
by them. A controller can be used to provision a unique Extended
Association ID on both endpoints. The procedure for selecting
unique Extended Association IDs is outside the scope of this
document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Compatibility</span>
This document updates the procedures for fast reroute for associated
bidirectional LSPs defined in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] and the procedures for
associating bidirectional LSPs defined in [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>]. The procedures
use the signaling messages defined in [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]; no new signaling
messages are defined in this document. The procedures ensure that
for the co-routed LSPs, traffic flows on co-routed paths in the
<span class="grey">Gandhi, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
forward and reverse directions after fast reroute. Operators wishing
to use this function SHOULD ensure that it is supported on all the
nodes on the LSP path. The nodes not supporting this function can
cause the traffic to flow on asymmetric paths in the forward and
reverse directions of the associated bidirectional LSPs after fast
reroute.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document updates the signaling mechanisms defined in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>]
and [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>]. It does not introduce any additional security
considerations other than those already covered in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>],
[<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>], [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>], and the MPLS/GMPLS security framework
[<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document has no IANA actions.
<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>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<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>, DOI 10.17487/RFC2205,
September 1997, <<a href="https://www.rfc-editor.org/info/rfc2205">https://www.rfc-editor.org/info/rfc2205</a>>.
[<a id="ref-RFC4090">RFC4090</a>] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", <a href="./rfc4090">RFC 4090</a>,
DOI 10.17487/RFC4090, May 2005,
<<a href="https://www.rfc-editor.org/info/rfc4090">https://www.rfc-editor.org/info/rfc4090</a>>.
[<a id="ref-RFC4561">RFC4561</a>] Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition
of a Record Route Object (RRO) Node-Id Sub-Object",
<a href="./rfc4561">RFC 4561</a>, DOI 10.17487/RFC4561, June 2006,
<<a href="https://www.rfc-editor.org/info/rfc4561">https://www.rfc-editor.org/info/rfc4561</a>>.
[<a id="ref-RFC6780">RFC6780</a>] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
ASSOCIATION Object Extensions", <a href="./rfc6780">RFC 6780</a>,
DOI 10.17487/RFC6780, October 2012,
<<a href="https://www.rfc-editor.org/info/rfc6780">https://www.rfc-editor.org/info/rfc6780</a>>.
<span class="grey">Gandhi, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
[<a id="ref-RFC7551">RFC7551</a>] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", <a href="./rfc7551">RFC 7551</a>, DOI 10.17487/RFC7551, May 2015,
<<a href="https://www.rfc-editor.org/info/rfc7551">https://www.rfc-editor.org/info/rfc7551</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8271">RFC8271</a>] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
M. Bhatia, "Updates to the Resource Reservation Protocol
for Fast Reroute of Traffic Engineering GMPLS Label
Switched Paths (LSPs)", <a href="./rfc8271">RFC 8271</a>, DOI 10.17487/RFC8271,
October 2017, <<a href="https://www.rfc-editor.org/info/rfc8271">https://www.rfc-editor.org/info/rfc8271</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<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>, DOI 10.17487/RFC3209, December 2001,
<<a href="https://www.rfc-editor.org/info/rfc3209">https://www.rfc-editor.org/info/rfc3209</a>>.
[<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>,
DOI 10.17487/RFC3473, January 2003,
<<a href="https://www.rfc-editor.org/info/rfc3473">https://www.rfc-editor.org/info/rfc3473</a>>.
[<a id="ref-RFC5920">RFC5920</a>] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", <a href="./rfc5920">RFC 5920</a>, DOI 10.17487/RFC5920, July 2010,
<<a href="https://www.rfc-editor.org/info/rfc5920">https://www.rfc-editor.org/info/rfc5920</a>>.
[<a id="ref-RFC6370">RFC6370</a>] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", <a href="./rfc6370">RFC 6370</a>,
DOI 10.17487/RFC6370, September 2011,
<<a href="https://www.rfc-editor.org/info/rfc6370">https://www.rfc-editor.org/info/rfc6370</a>>.
[<a id="ref-RFC6373">RFC6373</a>] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar,
N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-
TP) Control Plane Framework", <a href="./rfc6373">RFC 6373</a>,
DOI 10.17487/RFC6373, September 2011,
<<a href="https://www.rfc-editor.org/info/rfc6373">https://www.rfc-editor.org/info/rfc6373</a>>.
[<a id="ref-RFC8131">RFC8131</a>] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
GMPLS Restoration and Resource Sharing", <a href="./rfc8131">RFC 8131</a>,
DOI 10.17487/RFC8131, March 2017,
<<a href="https://www.rfc-editor.org/info/rfc8131">https://www.rfc-editor.org/info/rfc8131</a>>.
<span class="grey">Gandhi, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Extended Association ID</span>
The Extended Association ID in the Extended ASSOCIATION Object
[<a href="./rfc6780" title=""RSVP ASSOCIATION Object Extensions"">RFC6780</a>] can be set to the value formatted according to the
structure shown in the following example to uniquely identify
associated forward and reverse LSP pairs of an associated
bidirectional LSP.
An example of the IPv4 Extended Association ID format is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Extended Association ID Format Example
IPv4 LSP Source Address
IPv4 source address of the forward LSP [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
LSP ID
16-bit LSP ID of the forward LSP [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
Variable Length ID
Variable length Extended Association ID [<a href="./rfc6780" title=""RSVP ASSOCIATION Object Extensions"">RFC6780</a>] inserted by the
endpoint node of the associated bidirectional LSP [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>].
<span class="grey">Gandhi, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
An example of the IPv6 Extended Association ID format is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 LSP Source Address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Variable Length ID :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Extended Association ID Format Example
LSP Source Address
IPv6 source address of the forward LSP [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
LSP ID
16-bit LSP ID of the forward LSP [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
Variable Length ID
Variable length Extended Association ID [<a href="./rfc6780" title=""RSVP ASSOCIATION Object Extensions"">RFC6780</a>] inserted by the
endpoint node of the associated bidirectional LSP [<a href="./rfc7551" title=""RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"">RFC7551</a>].
In both IPv4 and IPv6 examples, the Reserved flags MUST be set to 0
on transmission.
<span class="grey">Gandhi, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8537">RFC 8537</a> Associated Bidirectional LSP Fast Reroute February 2019</span>
Acknowledgments
A special thanks to the authors of [<a href="./rfc8271" title=""Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)"">RFC8271</a>]; this document uses the
signaling mechanisms defined in that document. The authors would
also like to thank Vishnu Pavan Beeram, Daniele Ceccarelli, Deborah
Brungard, Adam Roach, and Benjamin Kaduk for reviewing this document
and providing valuable comments.
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Himanshu Shah
Ciena
Email: hshah@ciena.com
Jeremy Whittaker
Verizon
Email: jeremy.whittaker@verizon.com
Gandhi, et al. Standards Track [Page 16]
</pre>
|
