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
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
|
<pre>Internet Engineering Task Force (IETF) H. Chen
Request for Comments: 8400 Huawei Technologies
Category: Standards Track A. Liu
ISSN: 2070-1721 Ciena
T. Saad
Cisco Systems
F. Xu
Verizon
L. Huang
China Mobile
June 2018
<span class="h1">Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection</span>
Abstract
This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting the egress
node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP)
Traffic Engineered (TE) Label Switched Path (LSP).
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/rfc8400">https://www.rfc-editor.org/info/rfc8400</a>.
Copyright Notice
Copyright (c) 2018 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.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Local Protection of Egress Nodes . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Extensions to SERO . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1.1">4.1.1</a>. Primary Egress Subobject . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1.2">4.1.2</a>. P2P LSP ID Subobject . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Egress Protection Behaviors . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Ingress Behavior . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Primary Egress Behavior . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. Backup Egress Behavior . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.4">5.4</a>. Transit Node and PLR Behavior . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.4.1">5.4.1</a>. Signaling for One-to-One Protection . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.4.2">5.4.2</a>. Signaling for Facility Protection . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.4.3">5.4.3</a>. Signaling for S2L Sub-LSP Protection . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.4.4">5.4.4</a>. PLR Procedures during Local Repair . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. Application Traffic Considerations . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.1">6.1</a>. A Typical Application . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.2">6.2</a>. PLR Procedure for Applications . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-6.3">6.3</a>. Egress Procedures for Applications . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC4090">RFC4090</a>] describes two methods for locally protecting the transit
nodes of a P2P LSP: one-to-one and facility protection. [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]
specifies how these methods can be used to protect the transit nodes
of a P2MP LSP. These documents do not discuss the procedures for
locally protecting the egress node(s) of an LSP.
This document fills that void and specifies extensions to RSVP-TE for
local protection of the egress node(s) of an LSP. "Egress node" and
"egress" are used interchangeably.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Local Protection of Egress Nodes</span>
In general, locally protecting an egress node of an LSP means that
when the egress node fails, the traffic that the LSP carries will be
delivered to its destination by the direct upstream node of the
egress node to a backup egress node. Without protecting the egress
node of the LSP, when the egress node fails, the traffic will be lost
(i.e., the traffic will not be delivered to its destination).
Figure 1 shows an example of using backup LSPs to locally protect
egress nodes L1 and L2 of a primary P2MP LSP starting from ingress
node R1. La and Lb are the designated backup egress nodes for
primary egress nodes L1 and L2, respectively. The backup LSP for
protecting L1 is from its upstream node R3 to backup egress node La,
and the backup LSP for protecting L2 is from R5 to Lb.
******* ******* S Source
[R2]-----[R3]-----[L1] CEx Customer Edge
*/ &\ \ Rx Non-Egress
*/ &\ \ Lx Egress
*/ &\ [CE1] *** Primary LSP
*/ &\ / &&& Backup LSP
*/ &\ /
*/ [La]
*/
*/
*/
*/ ******** ******** *******
[S]---[R1]------[R4]------[R5]-----[L2]
&\ \
&\ \
&\ [CE2]
&\ /
&\ /
[Lb]
Figure 1: Backup LSP for Locally Protecting Egress
During normal operations, the traffic carried by the P2MP LSP is sent
through R3 to L1, which delivers the traffic to its destination CE1.
When R3 detects the failure of L1, R3 switches the traffic to the
backup LSP to backup egress node La, which delivers the traffic to
CE1. The time for switching the traffic is within tens of
milliseconds.
The exact mechanism by which the failure of the primary egress node
is detected by the upstream node R3 is out of the scope of this
document.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
In the beginning, the primary P2MP LSP from ingress node R1 to
primary egress nodes L1 and L2 is configured. It may be used to
transport the traffic from source S, which is connected to R1, to
destinations CE1 and CE2, which are connected to L1 and L2,
respectively.
To protect the primary egress nodes L1 and L2, one configures on the
ingress node R1 a backup egress node for L1, another backup egress
node for L2, and other options. After the configuration, the ingress
node sends a Path message for the LSP with information such as the
Secondary Explicit Route Objects (SEROs), refer to <a href="#section-4.1">Section 4.1</a>,
containing the backup egress nodes for protecting the primary egress
nodes.
After receiving the Path message with the information, the upstream
node of a primary egress node sets up a backup LSP to the
corresponding backup egress node for protecting the primary egress
node.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</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="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
The following terminology is used in this document.
LSP: Label Switched Path
TE: Traffic Engineering
P2MP: Point-to-Multipoint
P2P: Point-to-Point
LSR: Label Switching Router
RSVP: Resource Reservation Protocol
S2L: Source-to-Leaf
SERO: Secondary Explicit Route Object
RRO: Record Route Object
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
BFD: Bidirectional Forwarding Detection
VPN: Virtual Private Network
L3VPN: Layer 3 VPN
VRF: Virtual Routing and Forwarding
LFIB: Label Forwarding Information Base
UA: Upstream Assigned
PLR: Point of Local Repair
BGP: Border Gateway Protocol
CE: Customer Edge
PE: Provider Edge
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Extensions</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Extensions to SERO</span>
The Secondary Explicit Route Object (SERO) is defined in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
The format of the SERO is reused.
The SERO used for protecting a primary egress node of a primary LSP
may be added into the Path messages for the LSP and sent from the
ingress node of the LSP to the upstream node of the egress node. It
contains three subobjects.
The first subobject (refer to <a href="./rfc4873#section-4.2">Section 4.2 of [RFC4873]</a>) indicates the
branch node that is to originate the backup LSP (to a backup egress
node). The branch node is typically the direct upstream node of the
primary egress node of the primary LSP. If the direct upstream node
does not support local protection against the failure of the primary
egress node, the branch node can be any (upstream) node on the
primary LSP. In this case, the backup LSP from the branch node to
the backup egress node protects against failures on the segment of
the primary LSP from the branch node to, and including, the primary
egress node.
The second subobject is an Egress Protection subobject, which is a
PROTECTION object with a new C-Type (3). The format of the Egress
Protection subobject is defined as follows:
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |E-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Subobjects |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Flags are defined for local protection of egress nodes.
Bit 31 ("egress local protection" flag): It is the least significant
bit of the 32-bit word and is set to 1, which indicates that local
protection of egress nodes is desired.
Bit 30 ("S2L sub-LSP backup desired" flag): It is the second least
significant bit of the 32-bit word and is set to 1, which
indicates an S2L sub-LSP (refer to [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]) is desired for
protecting an egress node of a P2MP LSP.
The Reserved parts MUST be set to zero on transmission and MUST be
ignored on receipt.
Four optional subobjects are defined: they are IPv4 and IPv6 primary
egress node subobjects as well as IPv4 and IPv6 P2P LSP ID
subobjects. IPv4 and IPv6 primary egress node subobjects indicate
the IPv4 and IPv6 address of the primary egress node, respectively.
IPv4 and IPv6 P2P LSP ID subobjects contain the information for
identifying IPv4 and IPv6 backup P2P LSP tunnels, respectively.
Their contents are described in Sections <a href="#section-4.1.1">4.1.1</a> through <a href="#section-4.1.2.2">4.1.2.2</a>. They
have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents / Body of Subobject |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where Type is the type of a subobject and Length is the total size of
the subobject in bytes, including Type, Length, and Contents fields.
The Reserved field MUST be set to zero on transmission and MUST be
ignored on receipt.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
The third (final) subobject (refer to <a href="./rfc4873#section-4.2">Section 4.2 of [RFC4873]</a>) in
the SERO contains the egress node of the backup LSP, i.e., the
address of the backup egress node in the place of the merge node.
After the upstream node of the primary egress node (a.k.a. the branch
node) receives the SERO and determines a backup egress node for the
primary egress node, it computes a path from itself to the backup
egress node and sets up a backup LSP along the path for protecting
the primary egress node according to the information in the
FAST_REROUTE object in the Path message. For example, if facility
protection is desired, it is provided for the primary egress node.
The upstream node constructs a new SERO based on the SERO received
and adds the new SERO into the Path message for the backup LSP. The
new SERO also contains three subobjects as the SERO for the primary
LSP. The first subobject in the new SERO indicates the upstream
node, which may be copied from the first subobject in the SERO
received. The second subobject in the new SERO includes a primary
egress node, which indicates the address of the primary egress node.
The third one contains the backup egress node.
The upstream node updates the SERO in the Path message for the
primary LSP. The Egress Protection subobject in the SERO contains a
subobject called a P2P LSP ID subobject, which contains the
information for identifying the backup LSP. The final subobject in
the SERO indicates the address of the backup egress node.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Primary Egress Subobject</span>
There are two primary egress subobjects: the IPv4 primary egress
subobject and the IPv6 primary egress subobject.
The Type of an IPv4 primary egress subobject is 1, and the body of
the subobject is given 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 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv4 Address: The IPv4 address of the primary egress node.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
The Type of an IPv6 primary egress subobject is 2, and the body of
the subobject 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 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6 Address: The IPv6 address of the primary egress node.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. P2P LSP ID Subobject</span>
A P2P LSP ID subobject contains the information for identifying a
backup P2P LSP tunnel.
<span class="h5"><a class="selflink" id="section-4.1.2.1" href="#section-4.1.2.1">4.1.2.1</a>. IPv4 P2P LSP ID Subobject</span>
The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the
subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2P LSP Tunnel Egress IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o P2P LSP Tunnel Egress IPv4 Address: The IPv4 address of the egress
node of the tunnel.
o Tunnel ID (refer to [<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="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]): A 16-bit identifier
that remains constant over the life of the tunnel and occupies the
least significant 16 bits of the 32-bit word.
o Extended Tunnel ID (refer to [<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="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]): A 4-byte
identifier that remains constant over the life of the tunnel.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
<span class="h5"><a class="selflink" id="section-4.1.2.2" href="#section-4.1.2.2">4.1.2.2</a>. IPv6 P2P LSP ID Subobject</span>
The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the
subobject is illustrated 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P2P LSP Tunnel Egress IPv6 Address (16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Extended Tunnel ID (16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o P2P LSP Tunnel Egress IPv6 Address: The IPv6 address of the egress
node of the tunnel.
o Tunnel ID (refer to [<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="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]): A 16-bit identifier
that remains constant over the life of the tunnel and occupies the
least significant 16 bits of the 32-bit word.
o Extended Tunnel ID (refer to [<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="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]): A 16-byte
identifier that remains constant over the life of the tunnel.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Egress Protection Behaviors</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Ingress Behavior</span>
To protect a primary egress node of an LSP, the ingress node MUST set
the "label recording desired" flag and the "node protection desired"
flag in the SESSION_ATTRIBUTE object.
If one-to-one backup or facility backup is desired to protect a
primary egress node of an LSP, the ingress node MUST include a
FAST_REROUTE object and set the "one-to-one backup desired" or
"facility backup desired" flag, respectively.
If S2L sub-LSP backup is desired to protect a primary egress node of
a P2MP LSP, the ingress node MUST set the "S2L sub-LSP backup
desired" flag in an SERO object.
The decision to instantiate a backup egress node for protecting the
primary egress node of an LSP can be initiated by either the ingress
node or the primary egress node of that LSP, but not both.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
A backup egress node MUST be configured on the ingress node of an LSP
to protect a primary egress node of the LSP if and only if the backup
egress node is not configured on the primary egress node (refer to
<a href="#section-5.2">Section 5.2</a>).
The ingress node MUST send a Path message for the LSP with the
objects above and the SEROs for protecting egress nodes of the LSP if
protection of the egress nodes is desired. For each primary egress
node of the LSP to be protected, the ingress node MUST add an SERO
object into the Path message if the backup egress node, or some
options, are given. If the backup egress node is given, then the
final subobject in the SERO contains it; otherwise, the address in
the final subobject is zero.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Primary Egress Behavior</span>
To protect a primary egress node of an LSP, a backup egress node MUST
be configured on the primary egress node of the LSP to protect the
primary egress node if and only if the backup egress node is not
configured on the ingress node of the LSP (refer to <a href="#section-5.1">Section 5.1</a>).
If the backup egress node is configured on the primary egress node of
the LSP, the primary egress node MUST send its upstream node a Resv
message for the LSP with an SERO for protecting the primary egress
node. It sets the flags in the SERO in the same way as an ingress
node.
If the LSP carries the service traffic with a service label, the
primary egress node sends its corresponding backup egress node the
information about the service label as a UA label (refer to
[<a href="./rfc5331" title=""MPLS Upstream Label Assignment and Context-Specific Label Space"">RFC5331</a>]) and the related forwarding.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Backup Egress Behavior</span>
When a backup egress node receives a Path message for an LSP, it
determines whether the LSP is used for egress local protection by
checking the SERO with an Egress Protection subobject in the message.
If there is an Egress Protection subobject in the Path message for
the LSP and the "egress local protection" flag in the object is set
to 1, the LSP is the backup LSP for local protection of an egress
node. The primary egress node to be protected is in the primary
egress subobject in the SERO.
When the backup egress node receives the information about a UA label
and its related forwarding from the primary egress node, it uses the
backup LSP label as a context label and creates a forwarding entry
using the information about the UA label and the related forwarding.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
This forwarding entry is in a forwarding table for the primary egress
node.
When the primary egress node fails, its upstream node switches the
traffic from the primary LSP to the backup LSP to the backup egress
node, which delivers the traffic to its receiver, such as a CE, using
the backup LSP label as a context label to get the forwarding table
for the primary egress node and using the service label as a UA label
to find the forwarding entry in the table to forward the traffic to
the receiver.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Transit Node and PLR Behavior</span>
If a transit node of an LSP receives the Path message with the SEROs
and it is not an upstream node of any primary egress node of the LSP
as a branch node, it MUST forward them unchanged.
If the transit node is the upstream node of a primary egress node to
be protected as a branch node, it determines the backup egress node,
obtains a path for the backup LSP, and sets up the backup LSP along
the path. If the upstream node receives the Resv message with an
SERO object, it MUST send its upstream node the Resv message without
the object.
The PLR (which is the upstream node of the primary egress node a.k.a.
the branch node) MUST extract the backup egress node from the
respective SERO object in either a Path or a Resv message. If no
matching SERO object is found, the PLR tries to find the backup
egress node, which is not the primary egress node but has the same IP
address as the destination IP address of the LSP.
Note that if a backup egress node is not configured explicitly for
protecting a primary egress node, the primary egress node and the
backup egress node SHOULD have the same local address configured, and
the cost to the local address on the backup egress node SHOULD be
much bigger than the cost to the local address on the primary egress
node. Thus, the primary egress node and backup egress node are
considered as a "virtual node". Note that the backup egress node is
different from this local address (e.g., from the primary egress
node's point of view). In other words, it is identified by an
address different from this local address.
After obtaining the backup egress node, the PLR computes a backup
path from itself to the backup egress node and sets up a backup LSP
along the path. It excludes the segment including the primary egress
node to be protected when computing the path. The PLR sends the
primary egress node a Path message with an SERO for the primary LSP,
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
which indicates the backup egress node by the final subobject in the
SERO. The PLR puts an SERO into the Path messages for the backup
LSP, which indicates the primary egress node.
The PLR MUST provide one-to-one backup protection for the primary
egress node if the "one-to-one backup desired" flag is set in the
message; otherwise, it MUST provide facility backup protection if the
"facility backup desired" flag is set.
The PLR MUST set the protection flags in the RRO subobject for the
primary egress node in the Resv message according to the status of
the primary egress node and the backup LSP protecting the primary
egress node. For example, it sets the "local protection available"
flag and the "node protection" flag, which indicate that the primary
egress node is protected when the backup LSP is up and ready to
protect the primary egress node.
<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Signaling for One-to-One Protection</span>
The behavior of the upstream node of a primary egress node of an LSP
(as a PLR) is the same as that of a PLR for one-to-one backup
described in [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>], except that the upstream node (as a PLR)
creates a backup LSP from itself to a backup egress node in a session
different from the primary LSP.
If the LSP is a P2MP LSP and a primary egress node of the LSP is also
a transit node (i.e., bud node), the upstream node of the primary
egress node (as a PLR) creates a backup LSP from itself to each of
the next hops of the primary egress node.
When the PLR detects the failure of the primary egress node, it
switches the packets from the primary LSP to the backup LSP to the
backup egress node. For the failure of the bud node of a P2MP LSP,
the PLR also switches the packets to the backup LSPs to the bud
node's next hops, where the packets are merged into the primary LSP.
<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>. Signaling for Facility Protection</span>
Except for backup LSP and downstream label, the behavior of the
upstream node of the primary egress node of a primary LSP (as a PLR)
follows the PLR behavior for facility backup, which is described in
[<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>].
For a number of primary P2P LSPs going through the same PLR to the
same primary egress node, the primary egress node of these LSPs MAY
be protected by one backup LSP from the PLR to the backup egress node
designated for protecting the primary egress node.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
The PLR selects or creates a backup LSP from itself to the backup
egress node. If there is a backup LSP that satisfies the constraints
given in the Path message, then this one is selected; otherwise, a
new backup LSP to the backup egress node is created.
After getting the backup LSP, the PLR associates the backup LSP with
a primary LSP for protecting its primary egress node. The PLR
records that the backup LSP is used to protect the primary LSP
against its primary egress node failure and MUST include an SERO
object in the Path message for the primary LSP. The object MUST
contain the backup LSP ID. It indicates that the primary egress node
MUST send the backup egress node the service label as a UA label and
also send the information about forwarding the traffic to its
destination using the label if there is a service carried by the LSP
and the primary LSP label as a UA label (if the label is not implicit
null). How a UA label is sent is out of scope for this document
(refer to [<a href="#ref-FRAMEWK" title=""MPLS Egress Protection Framework"">FRAMEWK</a>]).
When the PLR detects the failure of the primary egress node, it
redirects the packets from the primary LSP into the backup LSP to the
backup egress node and keeps the primary LSP label from the primary
egress node in the label stack if the label is not implicit null.
The backup egress node delivers the packets to the same destinations
as the primary egress node using the backup LSP label as a context
label and the labels under as UA labels.
<span class="h4"><a class="selflink" id="section-5.4.3" href="#section-5.4.3">5.4.3</a>. Signaling for S2L Sub-LSP Protection</span>
The S2L sub-LSP protection uses an S2L sub-LSP (refer to [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>])
as a backup LSP to protect a primary egress node of a P2MP LSP. The
PLR MUST determine to protect a primary egress node of a P2MP LSP via
S2L sub-LSP protection when it receives a Path message with the "S2L
sub-LSP backup desired" flag set.
The PLR MUST set up the backup S2L sub-LSP to the backup egress node
and create and maintain its state in the same way as if setting up a
S2L sub-LSP 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>] from the signaling's point of view.
It computes a path for the backup LSP from itself to the backup
egress node, constructs and sends a Path message along the path, and
receives and processes a Resv message responding to the Path message.
After receiving the Resv message for the backup LSP, the PLR creates
a forwarding entry with an inactive state or flag called "inactive
forwarding entry". This inactive forwarding entry is not used to
forward any data traffic during normal operations.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
When the PLR detects the failure of the primary egress node, it
changes the forwarding entry for the backup LSP to "active". Thus,
the PLR forwards the traffic to the backup egress through the backup
LSP, which sends the traffic to its destination.
<span class="h4"><a class="selflink" id="section-5.4.4" href="#section-5.4.4">5.4.4</a>. PLR Procedures during Local Repair</span>
When the upstream node of a primary egress node of an LSP (as a PLR)
detects the failure of the primary egress node, it follows the
procedures defined in <a href="./rfc4090#section-6.5">Section 6.5 of [RFC4090]</a>. It SHOULD notify the
ingress node about the failure of the primary egress node in the same
way as a PLR notifies the ingress node about the failure of a transit
node.
Moreover, the PLR MUST let the upstream part of the primary LSP stay
alive after the primary egress node fails by sending the Resv message
to its upstream node along the primary LSP. The downstream part of
the primary LSP from the PLR to the primary egress node SHOULD be
removed. When a bypass LSP from the PLR to a backup egress node
protects the primary egress node, the PLR MUST NOT send any Path
message for the primary LSP through the bypass LSP to the backup
egress node.
In the local revertive mode, the PLR will re-signal each of the
primary LSPs that were routed over the restored resource once it
detects that the resource is restored. Every primary LSP
successfully re-signaled along the restored resource will be switched
back.
Note that the procedure for protecting the primary egress node is
triggered on the PLR if the primary egress node failure is
determined. If link (from PLR to primary egress node) failure and
primary egress node alive are determined, then the link protection
procedure is triggered on the PLR. How to determine these is out of
scope for this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Application Traffic Considerations</span>
This section focuses on an example with application traffic carried
by P2P LSPs.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. A Typical Application</span>
L3VPN is a typical application. Figure 2 below shows a simple VPN
that consists of two CEs, CE1 and CE2, connected to two PEs, R1 and
L1, respectively. There is a P2P LSP from R1 to L1, which is
represented by stars (****). This LSP is called the primary LSP. R1
is the ingress node of the LSP and L1 is the (primary) egress node of
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
the LSP. R1 sends the VPN traffic received from CE1 through the P2P
LSP to L1, which delivers the traffic to CE2. R1 sends the VPN
traffic with an LSP label and a VPN label via the LSP. When the
traffic reaches the egress node L1 of the LSP, L1 pops the LSP label
and uses the VPN label to deliver the traffic to CE2.
In previous solutions based on ingress protection to protect the VPN
traffic against failure of the egress node L1 of the LSP, when the
egress node fails, the ingress node R1 of the LSP does the reroute
(refer to Figure 2). This solution entailed:
1. A multi-hop BFD session between ingress node R1 and egress node
L1 of the primary LSP. The BFD session is represented by dots
(....).
2. A backup LSP from ingress node R1 to backup egress node La, which
is indicated by ampersands (&&&&).
3. La sends R1 a VPN backup label and related information via BGP.
4. R1 has a VRF with two sets of routes for CE2: one set uses the
primary LSP and L1 as the next hop; the other uses the backup LSP
and La as the next hop.
***** *****
CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP
one VPN */ : \ &&&& Backup LSP
*/ .................: \ .... BFD Session
[CE1]--[R1] ..: [CE2]
&\ /
&\ /
[R4]-----[R5]-----[La](BGP sends R1 VPN backup label)
&&&&& &&&&&
Figure 2: Protect Egress for L3VPN Traffic
In normal operations, R1 sends the VPN traffic from CE1 through the
primary LSP with the VPN label received from L1 as the inner label to
L1, which delivers the traffic to CE2 using the VPN label.
When R1 detects the failure of L1, R1 sends the traffic from CE1 via
the backup LSP with the VPN backup label received from La as the
inner label to La, which delivers the traffic to CE2 using the VPN
backup label.
<span class="grey">Chen, 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="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
The solution defined in this document that uses egress local
protection for protecting L3VPN traffic entails (refer to Figure 3):
1. A BFD session between R3 (i.e., upstream node of L1) and egress
node L1 of the primary LSP. This is different from the BFD
session in Figure 2, which is a multi-hop between ingress node R1
and egress node L1. The PLR R3 is closer to L1 than the ingress
node R1. It may detect the failure of the egress node L1 faster
and more reliably. Therefore, this solution can provide faster
protection for failure of an egress node.
2. A backup LSP from R3 to backup egress node La. This is different
from the backup LSP in Figure 2, which is an end-to-end LSP from
ingress node R1 to backup egress node La.
3. Primary egress node L1 sends backup egress node La the VPN label
as a UA label and also sends related information. The backup
egress node La uses the backup LSP label as a context label and
creates a forwarding entry using the VPN label in an LFIB for the
primary egress node L1.
4. L1 and La are virtualized as one node (or address). R1 has a VRF
with one set of routes for CE2, using the primary LSP from R1 to
L1 and a virtualized node as the next hop. This can be achieved
by configuring the same local address on L1 and La using the
address as a destination of the LSP and BGP next hop for the VPN
traffic. The cost to L1 is configured to be less than the cost
to La.
***** *****
CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP
one VPN */ &\:.....: \ &&&& Backup LSP
*/ &\ \ .... BFD Session
[CE1]--[R1] &\ [CE2]
&\ /
&\ /
[La](VPN label from L1 as a UA label)
Figure 3: Locally Protect Egress for L3VPN Traffic
In normal operations, R1 sends the VPN traffic from CE1 via the
primary LSP with the VPN label as an inner label to L1, which
delivers the traffic to CE2 using the VPN label.
When the primary egress node L1 fails, its upstream node R3 detects
it and switches the VPN traffic from the primary LSP to the backup
LSP to La, which delivers the traffic to CE2 using the backup LSP
<span class="grey">Chen, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
label as a context label to get the LFIB for L1 and the VPN label as
a UA label to find the forwarding entry in the LFIB to forward the
traffic to CE2.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. PLR Procedure for Applications</span>
When the PLR gets a backup LSP from itself to a backup egress node
for protecting a primary egress node of a primary LSP, it includes an
SERO object in the Path message for the primary LSP. The object
contains the ID information of the backup LSP and indicates that the
primary egress node sends the backup egress node the application
traffic label (e.g., the VPN label) as a UA label when needed.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Egress Procedures for Applications</span>
When a primary egress node of an LSP sends the ingress node of the
LSP a label for an application such as a VPN label, it sends the
label (as a UA label) to the backup egress node for protecting the
primary egress node. Exactly how the label is sent is out of scope
for this document.
When the backup egress node receives a UA label from the primary
egress node, it adds a forwarding entry with the label into the LFIB
for the primary egress node. When the backup egress node receives a
packet from the backup LSP, it uses the top label as a context label
to find the LFIB for the primary egress node and uses the inner label
to deliver the packet to the same destination as the primary egress
node according to the LFIB.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
This document builds upon existing work, specifically, the security
considerations of [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</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>], [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], and [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>]
continue to apply. Additionally, protecting a primary egress node of
a P2P LSP carrying service traffic through a backup egress node
requires out-of-band communication between the primary egress node
and the backup egress node in order for the primary egress node to
convey a service label as a UA label and also convey its related
forwarding information to the backup egress node. It is important to
confirm that the identifiers used to identify the primary and backup
egress nodes in the LSP are verified to match with the identifiers
used in the out-of-band protocol (such as BGP).
<span class="grey">Chen, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA maintains a registry called "Class Names, Class Numbers, and
Class Types" under "Resource Reservation Protocol (RSVP) Parameters".
IANA has assigned a new C-Type under the PROTECTION object class,
Class Number 37:
Value Description Definition
----- ----------- ----------
3 Egress Protection <a href="#section-4.1">Section 4.1</a>
IANA has created and now maintains a registry under the PROTECTION
object class (Class Number 37) and Egress Protection (C-Type 3).
Initial values for the registry are given below. Future assignments
are to be made through IETF Review [<a href="./rfc8216" title=""HTTP Live Streaming"">RFC8216</a>].
Value Description Definition
----- ----------- ----------
0 Reserved
1 IPv4_PRIMARY_EGRESS <a href="#section-4.1.1">Section 4.1.1</a>
2 IPv6_PRIMARY_EGRESS <a href="#section-4.1.1">Section 4.1.1</a>
3 IPv4_P2P_LSP_ID <a href="#section-4.1.2">Section 4.1.2</a>
4 IPv6_P2P_LSP_ID <a href="#section-4.1.2">Section 4.1.2</a>
5-127 Unassigned
128-255 Reserved
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.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-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-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-RFC4873">RFC4873</a>] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", <a href="./rfc4873">RFC 4873</a>, DOI 10.17487/RFC4873,
May 2007, <<a href="https://www.rfc-editor.org/info/rfc4873">https://www.rfc-editor.org/info/rfc4873</a>>.
<span class="grey">Chen, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
[<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>,
DOI 10.17487/RFC4875, May 2007,
<<a href="https://www.rfc-editor.org/info/rfc4875">https://www.rfc-editor.org/info/rfc4875</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-RFC8216">RFC8216</a>] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
<a href="./rfc8216">RFC 8216</a>, DOI 10.17487/RFC8216, August 2017,
<<a href="https://www.rfc-editor.org/info/rfc8216">https://www.rfc-editor.org/info/rfc8216</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-FRAMEWK">FRAMEWK</a>] Shen, Y., Jeganathan, J., Decraene, B., Gredler, H.,
Michel, C., Chen, H., and Y. Jiang, "MPLS Egress
Protection Framework", Work in Progress, <a href="./draft-ietf-mpls-egress-protection-framework-00">draft-ietf-mpls-</a>
<a href="./draft-ietf-mpls-egress-protection-framework-00">egress-protection-framework-00</a>, January 2018.
[<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-RFC5331">RFC5331</a>] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
<a href="./rfc5331">RFC 5331</a>, DOI 10.17487/RFC5331, August 2008,
<<a href="https://www.rfc-editor.org/info/rfc5331">https://www.rfc-editor.org/info/rfc5331</a>>.
Acknowledgements
The authors would like to thank Richard Li, Nobo Akiya, Lou Berger,
Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe,
Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan
Sampath, Yimin Shen, Ronhazli Adam, and Quintin Zhao for their
valuable comments and suggestions on this document.
<span class="grey">Chen, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
Contributors
The following people contributed significantly to the content of this
document and should be considered coauthors:
Ning So
Tata
Email: ningso01@gmail.com
Mehmet Toy
Verizon
Email: mehmet.toy@verizon.com
Lei Liu
Fujitsu
Email: lliu@us.fujitsu.com
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
We also acknowledge the contributions of the following individuals:
Boris Zhang
Telus Communications
Email: Boris.Zhang@telus.com
Nan Meng
Huawei Technologies
Email: mengnan@huawei.com
Prejeeth Kaladharan
Huawei Technologies
Email: prejeeth@gmail.com
Vic Liu
China Mobile
Email: liu.cmri@gmail.com
<span class="grey">Chen, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8400">RFC 8400</a> RSVP LSP Egress Protection June 2018</span>
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA
United States of America
Email: huaimo.chen@huawei.com
Autumn Liu
Ciena
United States of America
Email: hliu@ciena.com
Tarek Saad
Cisco Systems
Email: tsaad@cisco.com
Fengman Xu
Verizon
2400 N. Glenville Dr
Richardson, TX 75082
United States of America
Email: fengman.xu@verizon.com
Lu Huang
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing 100053
China
Email: huanglu@chinamobile.com
Chen, et al. Standards Track [Page 21]
</pre>
|
