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
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
|
<pre>Internet Engineering Task Force (IETF) N. Bahadur
Request for Comments: 6424 K. Kompella
Updates: <a href="./rfc4379">4379</a> Juniper Networks, Inc.
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
November 2011
<span class="h1">Mechanism for Performing Label Switched Path Ping (LSP Ping)</span>
<span class="h1">over MPLS Tunnels</span>
Abstract
This document describes methods for performing LSP ping (specified in
<a href="./rfc4379">RFC 4379</a>) traceroute over MPLS tunnels and for traceroute of stitched
MPLS Label Switched Paths (LSPs). The techniques outlined in <a href="./rfc4379">RFC</a>
<a href="./rfc4379">4379</a> are insufficient to perform traceroute Forwarding Equivalency
Class (FEC) validation and path discovery for an LSP that goes over
other MPLS tunnels or for a stitched LSP. This document deprecates
the Downstream Mapping TLV (defined in <a href="./rfc4379">RFC 4379</a>) in favor of a new
TLV that, along with other procedures outlined in this document, can
be used to trace such LSPs.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6424">http://www.rfc-editor.org/info/rfc6424</a>.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Summary of Changes . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. New Return Codes . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2.1">3.2.1</a>. Return Code per Downstream . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2.2">3.2.2</a>. Return Code for Stitched LSPs . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Downstream Detailed Mapping TLV . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.3.1.1">3.3.1.1</a>. Multipath Data Sub-TLV . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4">3.4</a>. Deprecation of Downstream Mapping TLV . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4">4</a>. Performing MPLS Traceroute on Tunnels . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. Transit Node Procedure . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1.1">4.1.1</a>. Addition of a New Tunnel . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1.2">4.1.2</a>. Transition between Tunnels . . . . . . . . . . . . . . <a href="#page-14">14</a>
4.1.3. Modification to FEC Validation Procedure on Transit . 16
<a href="#section-4.2">4.2</a>. Modification to FEC Validation Procedure on Egress . . . . <a href="#page-16">16</a>
<a href="#section-4.3">4.3</a>. Ingress Node Procedure . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-4.3.1">4.3.1</a>. Processing Downstream Detailed Mapping TLV . . . . . . <a href="#page-17">17</a>
<a href="#section-4.3.1.1">4.3.1.1</a>. Stack Change Sub-TLV Not Present . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-4.3.1.2">4.3.1.2</a>. Stack Change Sub-TLV(s) Present . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-4.3.2">4.3.2</a>. Modifications to Handling a Return Code 3 Reply. . . . <a href="#page-19">19</a>
<a href="#section-4.3.3">4.3.3</a>. Handling of New Return Codes . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-4.4">4.4</a>. Handling Deprecated Downstream Mapping TLV . . . . . . . . <a href="#page-20">20</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This documents describes methods for performing LSP ping (specified
in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]) traceroute over MPLS tunnels. The techniques in
[<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>] outline a traceroute mechanism that includes Forwarding
Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP)
path discovery. Those mechanisms are insufficient and do not provide
details when the FEC being traced traverses one or more MPLS tunnels
and when Label Switched Path (LSP) stitching [<a href="./rfc5150" title=""Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)"">RFC5150</a>] is in use.
This document deprecates the Downstream Mapping TLV [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>],
introducing instead a new TLV that is more extensible and that
enables retrieval of detailed information. Using the new TLV format
along with the existing definitions of [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>], this document
describes procedures by which a traceroute request can correctly
traverse MPLS tunnels with proper FEC and label validations.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Motivation</span>
An LSP ping traceroute may cross multiple MPLS tunnels en route to
the destination. Let us consider a simple case.
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
Figure 1: LDP over RSVP Tunnel
When a traceroute is initiated from router A, router B returns
downstream mapping information for node C in the MPLS echo reply.
The next MPLS echo request reaches router C with an LDP FEC. Node C
is a pure RSVP node and does not run LDP. Node C will receive the
MPLS echo request with two labels but only one FEC in the Target FEC
stack. Consequently, node C will be unable to perform a complete FEC
validation. It will let the trace continue by just providing next-
hop information based on the incoming label, and by looking up the
forwarding state associated with that label. However, ignoring FEC
validation defeats the purpose of control-plane validations. The
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
MPLS echo request should contain sufficient information to allow node
C to perform FEC validations to catch any misrouted echo requests.
The above problem can be extended for a generic case of hierarchical
tunnels or stitched tunnels (e.g., B-C can be a separate RSVP tunnel
and C-D can be a separate RSVP tunnel). The problem of FEC
validation for tunnels can be solved if the transit routers (router B
in the above example) provide some information to the ingress
regarding the start of a new tunnel.
Stitched LSPs involve two or more LSP segments stitched together.
The LSP segments can be signaled using the same or different
signaling protocols. In order to perform an end-to-end trace of a
stitched LSP, the ingress needs to know FEC information regarding
each of the stitched LSP segments. For example, consider the figure
below.
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 2: Stitched LSP
Consider ingress (A) tracing end-to-end stitched LSP A--F. When an
MPLS echo request reaches router C, there is a FEC stack change
happening at router C. With current LSP ping [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>] mechanisms,
there is no way to convey this information to A. Consequently, when
the next echo request reaches router D, router D will know nothing
about the LDP FEC that A is trying to trace.
Thus, the procedures defined in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>] do not make it possible for
the ingress node to:
1. Know that tunneling has occurred.
2. Trace the path of the tunnel.
3. Trace the path of stitched LSPs.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Packet Format</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Summary of Changes</span>
In many cases, there is a need to associate additional data in the
MPLS echo reply. In most cases, the additional data needs to be
associated on a per-downstream-neighbor basis. Currently, the MPLS
echo reply contains one Downstream Mapping TLV (DSMAP) per downstream
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
neighbor. However, the DSMAP format is not extensible; hence, it is
not possible to associate more information with a downstream
neighbor. This document defines a new extensible format for the
DSMAP and provides mechanisms for solving the tunneled LSP ping
problem using the new format. In summary, this document makes the
following TLV changes:
o Addition of new Downstream Detailed Mapping TLV (DDMAP).
o Deprecation of existing Downstream Mapping TLV (DSMAP).
o Addition of Downstream FEC stack change sub-TLV to DDMAP.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. New Return Codes</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Return Code per Downstream</span>
A new Return Code is being defined "See DDM TLV for Return Code and
Return Subcode" (<a href="#section-6.3">Section 6.3</a>) to indicate that the Return Code is per
Downstream Detailed Mapping TLV (<a href="#section-3.3">Section 3.3</a>). This Return Code MUST
be used only in the message header and MUST be set only in the MPLS
echo reply message. If the Return Code is set in the MPLS echo
request message, then it MUST be ignored. When this Return Code is
set, each Downstream Detailed Mapping TLV MUST have an appropriate
Return Code and Return Subcode. This Return Code MUST be used when
there are multiple downstreams for a given node (such as Point to
Multipoint (P2MP) or Equal Cost Multi-Path (ECMP)), and the node
needs to return a Return Code/Return Subcode for each downstream.
This Return Code MAY be used even when there is only one downstream
for a given node.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Return Code for Stitched LSPs</span>
When a traceroute is being performed on stitched LSPs
(<a href="#section-4.1.2">Section 4.1.2</a>), the stitching point SHOULD indicate the stitching
action to the node performing the trace. This is done by setting the
Return Code to "Label switched with FEC change" (<a href="#section-6.3">Section 6.3</a>). If a
node is performing FEC hiding, then it MAY choose to set the Return
Code to a value (specified in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]) other than "Label switched
with FEC change". The Return Code "Label switched with FEC change"
MUST NOT be used if no FEC stack sub-TLV (<a href="#section-3.3.1.3">Section 3.3.1.3</a>) is present
in the Downstream Detailed Mapping TLV(s). This new Return Code MAY
be used for hierarchical LSPs (for indicating the start or end of an
outer LSP).
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Downstream Detailed Mapping TLV</span>
Type # Value Field
------ ------------
20 Downstream Detailed Mapping
The Downstream Detailed Mapping object is a TLV that MAY be included
in an MPLS echo request message. Only one Downstream Detailed
Mapping object may appear in an echo request. The presence of a
Downstream Detailed Mapping object is a request that Downstream
Detailed Mapping objects be included in the MPLS echo reply. If the
replying router is the destination (Label Edge Router) of the FEC,
then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
MPLS echo reply. Otherwise, the replying router SHOULD include a
Downstream Detailed Mapping object for each interface over which this
FEC could be forwarded.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-tlv Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Downstream Detailed Mapping TLV
The Downstream Detailed Mapping TLV format is derived from the
Downstream Mapping TLV format. The key change is that variable
length and optional fields have been converted into sub-TLVs. The
fields have the same use and meaning as in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]. A summary of
the fields taken from the Downstream Mapping TLV is as below:
Maximum Transmission Unit (MTU)
The MTU is the size in octets of the largest MPLS frame (including
label stack) that fits on the interface to the Downstream Label
Switching Router (LSR).
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
Address Type
The Address Type indicates if the interface is numbered or
unnumbered. It also determines the length of the Downstream IP
Address and Downstream Interface fields.
DS Flags
The DS Flags field is a bit vector of various flags.
Downstream Address and Downstream Interface Address
IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets. For details regarding setting
the address value, refer to [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>].
The newly added sub-TLVs and their fields are as described below.
Return Code
The Return Code is set to zero by the sender. The receiver can
set it to one of the values specified in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, "Return Codes" sub-registry.
If the receiver sets a non-zero value of the Return Code field in
the Downstream Detailed Mapping TLV, then the receiver MUST also
set the Return Code field in the echo reply header to "See DDM TLV
for Return Code and Return Subcode" (<a href="#section-6.3">Section 6.3</a>). An exception
to this is if the receiver is a bud node [<a href="./rfc4461" title=""Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)"">RFC4461</a>] and is replying
as both an egress and a transit node with a Return Code of 3
("Replying router is an egress for the FEC at stack-depth <RSC>")
in the echo reply header.
If the Return Code of the echo reply message is not set to either
"See DDM TLV for Return Code and Return Subcode" (<a href="#section-6.3">Section 6.3</a>) or
"Replying router is an egress for the FEC at stack-depth <RSC>",
then the Return Code specified in the Downstream Detailed Mapping
TLV MUST be ignored.
Return Subcode
The Return Subcode is set to zero by the sender. The receiver can
set it to one of the values specified in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, "Return Codes" sub-registry. This field is filled in
with the stack-depth for those codes that specify the stack-depth.
For all other codes, the Return Subcode MUST be set to zero.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
If the Return Code of the echo reply message is not set to either
"See DDM TLV for Return Code and Return Subcode" (<a href="#section-6.3">Section 6.3</a>) or
"Replying router is an egress for the FEC at stack-depth <RSC>",
then the Return Subcode specified in the Downstream Detailed
Mapping TLV MUST be ignored.
Sub-tlv Length
Total length in bytes of the sub-TLVs associated with this TLV.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Sub-TLVs</span>
This section defines the sub-TLVs that MAY be included as part of the
Downstream Detailed Mapping TLV.
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change
<span class="h5"><a class="selflink" id="section-3.3.1.1" href="#section-3.3.1.1">3.3.1.1</a>. Multipath Data Sub-TLV</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Multipath Sub-TLV
The multipath data sub-TLV includes Multipath Information. The sub-
TLV fields and their usage is as defined in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]. A brief
summary of the fields is as below:
Multipath Type
The type of the encoding for the Multipath Information.
Multipath Length
The length in octets of the Multipath Information.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
MBZ
MUST be set to zero when sending; MUST be ignored on receipt.
Multipath Information
Encoded multipath data, according to the Multipath Type.
<span class="h5"><a class="selflink" id="section-3.3.1.2" href="#section-3.3.1.2">3.3.1.2</a>. Label Stack Sub-TLV</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Label Stack Sub-TLV
The Label stack sub-TLV contains the set of labels in the label stack
as it would have appeared if this router were forwarding the packet
through this interface. Any Implicit Null labels are explicitly
included. The number of label/protocol pairs present in the sub-TLV
is determined based on the sub-TLV data length. The label format and
protocol type are as defined in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]. When the Downstream
Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be
included.
Downstream Label
A Downstream label is 24 bits, in the same format as an MPLS label
minus the Time to Live (TTL) field, i.e., the MSBit of the label
is bit 0, the LSBit is bit 19, the Traffic Class (TC) field
[<a href="./rfc5462" title=""Multiprotocol Label Switching (MPLS) Label Stack Entry: "">RFC5462</a>] is bits 20-22, and S is bit 23. The replying router
SHOULD fill in the TC field and S bit; the LSR receiving the echo
reply MAY choose to ignore these.
Protocol
This specifies the label distribution protocol for the Downstream
label.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
<span class="h5"><a class="selflink" id="section-3.3.1.3" href="#section-3.3.1.3">3.3.1.3</a>. FEC Stack Change Sub-TLV</span>
A router MUST include the FEC stack change sub-TLV when the
downstream node in the echo reply has a different FEC Stack than the
FEC Stack received in the echo request. One or more FEC stack change
sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The
format is as 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FEC Stack Change Sub-TLV
Operation Type
The operation type specifies the action associated with the FEC
stack change. The following operation types are defined:
Type # Operation
------ ---------
1 Push
2 Pop
Address Type
The Address Type indicates the remote peer's address type. The
Address Type is set to one of the following values. The length of
the peer address is determined based on the address type. The
address type MAY be different from the address type included in
the Downstream Detailed Mapping TLV. This can happen when the LSP
goes over a tunnel of a different address family. The address
type MAY be set to Unspecified if the peer address is either
unavailable or the transit router does not wish to provide it for
security or administrative reasons.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16
FEC TLV Length
Length in bytes of the FEC TLV.
Reserved
This field is reserved for future use and MUST be set to zero.
Remote Peer Address
The remote peer address specifies the remote peer that is the
next-hop for the FEC being currently traced. For example, in the
LDP over RSVP case in Figure 1, router B would respond back with
the address of router D as the remote peer address for the LDP FEC
being traced. This allows the ingress node to provide information
regarding FEC peers. If the operation type is PUSH, the remote
peer address is the address of the peer from which the FEC being
pushed was learned. If the operation type is POP, the remote peer
address MAY be set to Unspecified.
For upstream-assigned labels [<a href="./rfc5331" title=""MPLS Upstream Label Assignment and Context-Specific Label Space"">RFC5331</a>], an operation type of POP
will have a remote peer address (the upstream node that assigned
the label) and this SHOULD be included in the FEC stack change
sub-TLV. The remote peer address MAY be set to Unspecified if the
address needs to be hidden.
FEC TLV
The FEC TLV is present only when the FEC-tlv length field is non-
zero. The FEC TLV specifies the FEC associated with the FEC stack
change operation. This TLV MAY be included when the operation
type is POP. It MUST be included when the operation type is PUSH.
The FEC TLV contains exactly one FEC from the list of FECs
specified in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]. A Nil FEC MAY be associated with a PUSH
operation if the responding router wishes to hide the details of
the FEC being pushed.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
FEC stack change sub-TLV operation rules are as follows:
a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT
be followed by a FEC stack change sub-TLV containing a POP
operation.
b. One or more POP operations MAY be followed by one or more PUSH
operations.
c. One FEC stack change sub-TLV MUST be included per FEC stack
change. For example, if 2 labels are going to be pushed, then
one FEC stack change sub-TLV MUST be included for each FEC.
d. A FEC splice operation (an operation where one FEC ends and
another FEC starts, see Figure 7) MUST be performed by including
a POP type FEC stack change sub-TLV followed by a PUSH type FEC
stack change sub-TLV.
e. A Downstream detailed mapping TLV containing only one FEC stack
change sub-TLV with Pop operation is equivalent to IS_EGRESS
(Return Code 3, [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]) for the outermost FEC in the FEC
stack. The ingress router performing the MPLS traceroute MUST
treat such a case as an IS_EGRESS for the outermost FEC.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Deprecation of Downstream Mapping TLV</span>
This document deprecates the Downstream Mapping TLV. LSP ping
procedures should now use the Downstream Detailed Mapping TLV.
Detailed procedures regarding interoperability between the deprecated
TLV and the new TLV are specified in <a href="#section-4.4">Section 4.4</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Performing MPLS Traceroute on Tunnels</span>
This section describes the procedures to be followed by an LSP
ingress node and LSP transit nodes when performing MPLS traceroute
over MPLS tunnels.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Transit Node Procedure</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Addition of a New Tunnel</span>
A transit node (Figure 1) knows when the FEC being traced is going to
enter a tunnel at that node. Thus, it knows about the new outer FEC.
All transit nodes that are the origination point of a new tunnel
SHOULD add the FEC stack change sub-TLV (<a href="#section-3.3.1.3">Section 3.3.1.3</a>) to the
Downstream Detailed Mapping TLV (Figure 3) in the echo reply. The
transit node SHOULD add one FEC stack change sub-TLV of operation
type PUSH, per new tunnel being originated at the transit node.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
A transit node that sends a Downstream FEC stack change sub-TLV in
the echo reply SHOULD fill the address of the remote peer; which is
the peer of the current LSP being traced. If the transit node does
not know the address of the remote peer, it MUST set the address type
to Unspecified.
The Label stack sub-TLV MUST contain one additional label per FEC
being PUSHed. The label MUST be encoded as per Figure 5. The label
value MUST be the value used to switch the data traffic. If the
tunnel is a transparent pipe to the node, i.e. the data-plane trace
will not expire in the middle of the new tunnel, then a FEC stack
change sub-TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD
NOT contain a label corresponding to the hidden tunnel.
If the transit node wishes to hide the nature of the tunnel from the
ingress of the echo request, then it MAY not want to send details
about the new tunnel FEC to the ingress. In such a case, the transit
node SHOULD use the Nil FEC. The echo reply would then contain a FEC
stack change sub-TLV with operation type PUSH and a Nil FEC. The
value of the label in the Nil FEC MUST be set to zero. The remote
peer address type MUST be set to Unspecified. The transit node
SHOULD add one FEC stack change sub-TLV of operation type PUSH, per
new tunnel being originated at the transit node. The Label stack
sub-TLV MUST contain one additional label per FEC being PUSHed. The
label value MUST be the value used to switch the data traffic.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Transition between Tunnels</span>
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 7: Stitched LSPs
In the above figure, we have three separate LSP segments stitched at
C and D. Node C SHOULD include two FEC stack change sub-TLVs. One
with a POP operation for the LDP FEC and one with the PUSH operation
for the BGP FEC. Similarly, node D SHOULD include two FEC stack
change sub-TLVs, one with a POP operation for the BGP FEC and one
with a PUSH operation for the RSVP FEC. Nodes C and D SHOULD set the
Return Code to "Label switched with FEC change" (<a href="#section-6.3">Section 6.3</a>) to
indicate change in FEC being traced.
If node C wishes to perform FEC hiding, it SHOULD respond back with
two FEC stack change sub-TLVs, one POP followed by one PUSH. The POP
operation MAY either exclude the FEC TLV (by setting the FEC TLV
length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
operation SHOULD have the FEC TLV containing the Nil FEC. The Return
Code SHOULD be set to "Label switched with FEC change".
If node C performs FEC hiding and node D also performs FEC hiding,
then node D MAY choose to not send any FEC stack change sub-TLVs in
the echo reply since the number of labels has not changed (for the
downstream of node D) and the FEC type also has not changed (Nil
FEC). In such a case, node D MUST NOT set the Return Code to "Label
switched with FEC change". If node D performs FEC hiding, then node
F will respond as IS_EGRESS for the Nil FEC. The ingress (node A)
will know that IS_EGRESS corresponds to the end-to-end LSP.
A B C D E F
o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP
| \_______________________________/|
| RSVP-B |
\________________________________/
LDP
Figure 8: Hierarchical LSPs
In the above figure, we have an end-to-end LDP LSP between nodes A
and F. The LDP LSP goes over RSVP LSP RSVP-B. LSP RSVP-B itself
goes over another RSVP LSP RSVP-A. When node A initiates a
traceroute for the end-to-end LDP LSP, then following sequence of FEC
stack change sub-TLVs will be performed
Node B:
Respond with two FEC stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
Node D:
Respond with Return Code 3 when RSVP-A is the top of FEC stack. When
the echo request contains RSVP-B as top of stack, respond with
Downstream information for node E and an appropriate Return Code.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
If node B is performing tunnel hiding, then:
Node B:
Respond with two FEC stack change sub-TLVs: PUSH Nil FEC, PUSH Nil
FEC.
Node D:
If D determines that the Nil FEC corresponds to RSVP-A, which
terminates at D, then it SHOULD respond with Return Code 3. D can
also respond with FEC stack change sub-TLV: POP (since D knows that
number of labels towards next-hop is decreasing). Both responses
would be valid.
A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP
\_____________/
LDP
Figure 9: Stitched Hierarchical LSPs
In the above case, node D will send three FEC stack change sub-TLVs.
One POP (for the BGP FEC) followed by two PUSHes (one for LDP and one
for RSVP). Nodes C and D SHOULD set the Return Code to "Label
switched with FEC change" (<a href="#section-6.3">Section 6.3</a>) to indicate change in FEC
being traced.
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Modification to FEC Validation Procedure on Transit</span>
<a href="./rfc4379#section-4.4">Section 4.4 of [RFC4379]</a> specifies Target FEC stack validation
procedures. This document enhances the FEC validation procedures as
follows. If the outermost FEC of the target FEC stack is the Nil
FEC, then the node MUST skip the target FEC validation completely.
This is to support FEC hiding, in which the outer hidden FEC can be
the Nil FEC.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Modification to FEC Validation Procedure on Egress</span>
<a href="./rfc4379#section-4.4">Section 4.4 of [RFC4379]</a> specifies Target FEC stack validation
procedures. This document enhances the FEC validation procedures as
follows. If the outermost FEC of the Target FEC stack is the Nil
FEC, then the node MUST skip the target FEC validation completely.
This is to support FEC hiding, in which the outer hidden FEC can be
the Nil FEC.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Ingress Node Procedure</span>
It is the responsibility of an ingress node to understand tunnel
within tunnel semantics and LSP stitching semantics when performing a
MPLS traceroute. This section describes the ingress node procedure
based on the kind of reply an ingress node receives from a transit
node.
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Processing Downstream Detailed Mapping TLV</span>
Downstream Detailed Mapping TLV should be processed in the same way
as the Downstream Mapping TLV, defined in <a href="./rfc4379#section-4.4">Section 4.4 of [RFC4379]</a>.
This section describes the procedures for processing the new elements
introduced in this document.
<span class="h5"><a class="selflink" id="section-4.3.1.1" href="#section-4.3.1.1">4.3.1.1</a>. Stack Change Sub-TLV Not Present</span>
This would be the default behavior as described in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]. The
ingress node MUST perform MPLS echo reply processing as per the
procedures in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>].
<span class="h5"><a class="selflink" id="section-4.3.1.2" href="#section-4.3.1.2">4.3.1.2</a>. Stack Change Sub-TLV(s) Present</span>
If one or more FEC stack change sub-TLVs (<a href="#section-3.3.1.3">Section 3.3.1.3</a>) are
received in the MPLS echo reply, the ingress node SHOULD process them
and perform some validation.
The FEC stack changes are associated with a downstream neighbor and
along a particular path of the LSP. Consequently, the ingress will
need to maintain a FEC stack per path being traced (in case of
multipath). All changes to the FEC stack resulting from the
processing of FEC stack change sub-TLV(s) should be applied only for
the path along a given downstream neighbor. The following algorithm
should be followed for processing FEC stack change sub-TLVs.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
push_seen = FALSE
fec_stack_depth = current-depth-of-fec-stack-being-traced
saved_fec_stack = current_fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
if (sub-tlv == NULL) break
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Figure 10: FEC Stack Change Sub-TLV Processing Guideline
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
The next MPLS echo request along the same path should use the
modified FEC stack obtained after processing the FEC stack change
sub-TLVs. A non-Nil FEC guarantees that the next echo request along
the same path will have the Downstream Detailed Mapping TLV validated
for IP address, Interface address, and label stack mismatches.
If the top of the FEC stack is a Nil FEC and the MPLS echo reply does
not contain any FEC stack change sub-TLVs, then it does not
necessarily mean that the LSP has not started traversing a different
tunnel. It could be that the LSP associated with the Nil FEC
terminated at a transit node and at the same time a new LSP started
at the same transit node. The Nil FEC would now be associated with
the new LSP (and the ingress has no way of knowing this). Thus, it
is not possible to build an accurate hierarchical LSP topology if a
traceroute contains Nil FECs.
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Modifications to Handling a Return Code 3 Reply.</span>
The procedures above allow the addition of new FECs to the original
FEC being traced. Consequently, a reply from a downstream node with
Return Code 3 (IS_EGRESS) may not necessarily be for the FEC being
traced. It could be for one of the new FECs that was added. On
receipt of an IS_EGRESS reply, the LSP ingress should check if the
depth of Target FEC sent to the node that just responded, was the
same as the depth of the FEC that was being traced. If it was not,
then it should pop an entry from the Target FEC stack and resend the
request with the same TTL (as previously sent). The process of
popping a FEC is to be repeated until either the LSP ingress receives
a non-IS_EGRESS reply or until all the additional FECs added to the
FEC stack have already been popped. Using an IS_EGRESS reply, an
ingress can build a map of the hierarchical LSP structure traversed
by a given FEC.
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. Handling of New Return Codes</span>
When the MPLS echo reply Return Code is "Label switched with FEC
change" (<a href="#section-3.2.2">Section 3.2.2</a>), the ingress node SHOULD manipulate the FEC
stack as per the FEC stack change sub-TLVs contained in the
downstream detailed mapping TLV. A transit node can use this Return
Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or
P2MP, there could be multiple paths and Downstream Detailed Mapping
TLVs with different Return Codes (<a href="#section-3.2.1">Section 3.2.1</a>). The ingress node
should build the topology based on the Return Code per ECMP path/P2MP
branch.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Handling Deprecated Downstream Mapping TLV</span>
The Downstream Mapping TLV has been deprecated. Applications should
now use the Downstream Detailed Mapping TLV. The following
procedures SHOULD be used for backward compatibility with routers
that do not support the Downstream Detailed Mapping TLV.
o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV
MUST never be sent together in the same MPLS echo request or in
the same MPLS echo reply.
o If the echo request contains a Downstream Detailed Mapping TLV and
the corresponding echo reply contains a Return Code 2 ("One or
more of the TLVs was not understood"), then the sender of the echo
request MAY resend the echo request with the Downstream Mapping
TLV (instead of the Downstream Detailed Mapping TLV). In cases
where a detailed reply is needed, the sender can choose to ignore
the router that does not support the Downstream Detailed Mapping
TLV.
o If the echo request contains a Downstream Mapping TLV, then a
Downstream Detailed Mapping TLV MUST NOT be sent in the echo
reply. This is to handle the case that the sender of the echo
request does not support the new TLV. The echo reply MAY contain
Downstream Mapping TLV(s).
o If echo request forwarding is in use (such that the echo request
is processed at an intermediate LSR and then forwarded on), then
the intermediate router is responsible for making sure that the
TLVs being used among the ingress, intermediate and destination
are consistent. The intermediate router MUST NOT forward an echo
request or an echo reply containing a Downstream Detailed Mapping
TLV if it itself does not support that TLV.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
1. If a network operator wants to prevent tracing inside a tunnel,
one can use the Pipe Model [<a href="./rfc3443" title=""Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks"">RFC3443</a>], i.e., hide the outer MPLS
tunnel by not propagating the MPLS TTL into the outer tunnel (at
the start of the outer tunnel). By doing this, MPLS traceroute
packets will not expire in the outer tunnel and the outer tunnel
will not get traced.
2. If one doesn't wish to expose the details of the new outer LSP,
then the Nil FEC can be used to hide those details. Using the
Nil FEC ensures that the trace progresses without false negatives
and all transit nodes (of the new outer tunnel) perform some
minimal validations on the received MPLS echo requests.
<span class="grey">Bahadur, 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="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
Other security considerations, as discussed in [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>], are also
applicable to this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. New TLV</span>
IANA has assigned a TLV type value to the following TLV from the
"Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-
registry.
Downstream Detailed Mapping TLV (see <a href="#section-3.3">Section 3.3</a>): 20.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. New Sub-TLV Types and Associated Registry</span>
IANA has registered the Sub-Type field of Downstream Detailed Mapping
TLV. The valid range for this is 0-65535. Assignments in the range
0-16383 and 32768-49161 are made via Standards Action as defined in
[<a href="./rfc3692" title=""Assigning Experimental and Testing Numbers Considered Useful"">RFC3692</a>]; assignments in the range 16384-31743 and 49162-64511 are
made via Specification Required [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]; values in the range 31744-
32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be
allocated. If a sub-TLV has a Type that falls in the range for
Vendor Private Use, the Length MUST be at least 4, and the first four
octets MUST be that vendor's SMI Enterprise Code, in network octet
order. The rest of the Value field is private to the vendor.
IANA has assigned the following sub-TLV types (see <a href="#section-3.3.1">Section 3.3.1</a>):
Multipath data: 1
Label stack: 2
FEC stack change: 3
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. New Return Codes</span>
IANA has assigned new Return Code values from the "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, "Return Codes" sub-registry, as follows using a Standards
Action value.
Value Meaning
----- -------
14 See DDM TLV for Return Code and Return Subcode
15 Label switched with FEC change
<span class="grey">Bahadur, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors would like to thank Yakov Rekhter and Adrian Farrel for
their suggestions on the document.
<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>, March 1997.
[<a id="ref-RFC3692">RFC3692</a>] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", <a href="https://www.rfc-editor.org/bcp/bcp82">BCP 82</a>, <a href="./rfc3692">RFC 3692</a>, January 2004.
[<a id="ref-RFC4379">RFC4379</a>] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", <a href="./rfc4379">RFC 4379</a>,
February 2006.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3443">RFC3443</a>] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
<a href="./rfc3443">RFC 3443</a>, January 2003.
[<a id="ref-RFC4461">RFC4461</a>] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", <a href="./rfc4461">RFC 4461</a>, April 2006.
[<a id="ref-RFC5150">RFC5150</a>] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", <a href="./rfc5150">RFC 5150</a>, February 2008.
[<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>, August 2008.
[<a id="ref-RFC5462">RFC5462</a>] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", <a href="./rfc5462">RFC 5462</a>, February 2009.
<span class="grey">Bahadur, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6424">RFC 6424</a> LSP Ping over MPLS Tunnels November 2011</span>
Authors' Addresses
Nitin Bahadur
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
EMail: nitinb@juniper.net
URI: www.juniper.net
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
URI: www.juniper.net
George Swallow
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
US
EMail: swallow@cisco.com
URI: www.cisco.com
Bahadur, et al. Standards Track [Page 23]
</pre>
|
