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
|
<pre>Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 8237 Monoski LLC
Category: Standards Track G. Swallow
ISSN: 2070-1721 SETC
E. Bellagamba
Ericsson
October 2017
<span class="h1">MPLS Label Switched Path (LSP) Pseudowire (PW)</span>
<span class="h1">Status Refresh Reduction for Static PWs</span>
Abstract
This document describes a method for generating an aggregated
pseudowire (PW) status message transmitted for a statically
configured PW on a Multiprotocol Label Switching (MPLS) Label
Switched Path (LSP) to indicate the status of one or more PWs carried
on the LSP.
The method for transmitting the PW status information is not new;
however, this protocol extension allows a Service Provider (SP) to
reliably monitor the individual PW status while not overwhelming the
network with multiple periodic status messages. This is achieved by
sending a single cumulative summary status verification message for
all the PWs grouped in the same 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/rfc8237">https://www.rfc-editor.org/info/rfc8237</a>.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language ......................................<a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-1.3">1.3</a>. Notational Conventions .....................................<a href="#page-5">5</a>
<a href="#section-2">2</a>. PW Status Refresh Reduction Protocol ............................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Protocol States ............................................<a href="#page-5">5</a>
<a href="#section-2.1.1">2.1.1</a>. INACTIVE ............................................<a href="#page-5">5</a>
<a href="#section-2.1.2">2.1.2</a>. STARTUP .............................................<a href="#page-6">6</a>
<a href="#section-2.1.3">2.1.3</a>. ACTIVE ..............................................<a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Timer Value Change Transition Procedure ....................<a href="#page-6">6</a>
<a href="#section-3">3</a>. PW Status Refresh Reduction Procedure ...........................<a href="#page-7">7</a>
<a href="#section-4">4</a>. PW Status Refresh Reduction Message Encoding ....................<a href="#page-8">8</a>
<a href="#section-5">5</a>. PW Status Refresh Reduction Control Messages ...................<a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. Notification Message ......................................<a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. PW Configuration Message ..................................<a href="#page-12">12</a>
<a href="#section-5.2.1">5.2.1</a>. MPLS-TP Tunnel ID ..................................<a href="#page-13">13</a>
<a href="#section-5.2.2">5.2.2</a>. PW ID Configured List ..............................<a href="#page-14">14</a>
<a href="#section-5.2.3">5.2.3</a>. PW ID Unconfigured List ............................<a href="#page-15">15</a>
<a href="#section-6">6</a>. PW Provisioning Verification Procedure .........................<a href="#page-15">15</a>
<a href="#section-6.1">6.1</a>. PW ID List Advertising and Processing .....................<a href="#page-16">16</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-16">16</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. PW Status Refresh Reduction Message Types .................<a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. PW Configuration Message Sub-TLVs .........................<a href="#page-17">17</a>
<a href="#section-8.3">8.3</a>. PW Status Refresh Reduction Notification Codes ............<a href="#page-18">18</a>
<a href="#section-8.4">8.4</a>. PW Status Refresh Reduction Message Flags .................<a href="#page-18">18</a>
<a href="#section-8.5">8.5</a>. G-ACh Registry Allocation .................................<a href="#page-19">19</a>
<a href="#section-8.6">8.6</a>. Guidance for Designated Experts ...........................<a href="#page-19">19</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-19">19</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-19">19</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-20">20</a>
Authors' Addresses ................................................<a href="#page-20">20</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
When PWs use a Multiprotocol Label Switching (MPLS) network as the
Packet Switched Network (PSN), they are set up using static label
assignment per <a href="./rfc8077#section-4">Section 4 of [RFC8077]</a>, and the PW status information
is propagated using the method described in [<a href="./rfc6478" title=""Pseudowire Status for Static Pseudowires"">RFC6478</a>]. There are two
basic modes of operation described in <a href="./rfc6478#section-5.3">[RFC6478], Section 5.3</a>:
(1) periodic retransmission of non-zero status messages and (2) a
simple acknowledgment of PW status (<a href="./rfc6478#section-5.3.1">Section 5.3.1 of [RFC6478]</a>). The
LSP-level protocol described below applies to the case when
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
PW status is acknowledged immediately with a requested refresh value
of zero (no refresh). In this case, the PW status refresh reduction
protocol is necessary for several reasons, such as the following:
i. The PW status refresh reduction protocol greatly increases the
scalability of the PW status protocol by reducing the amount of
messages that a Provider Edge (PE) needs to periodically send to
its neighbors.
ii. The PW status refresh reduction protocol will detect a remote PE
restart.
iii. If the local state is lost for some reason, the PE needs to be
able to request a status refresh reduction from the remote PE.
iv. The PW status refresh reduction protocol can optionally detect a
remote PE provisioning change.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
FEC: Forwarding Equivalence Class
LDP: Label Distribution Protocol
LSP: Label Switched Path
MS-PW: Multi-Segment Pseudowire
PE: Provider Edge
PW: Pseudowire
S-PE: Switching Provider Edge Node of MS-PW
SS-PW: Single-Segment Pseudowire
T-PE: Terminating Provider Edge Node of MS-PW
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Notational Conventions</span>
All multiple-word atomic identifiers use underscores ("_") between
the words to join the words. Many of the identifiers are composed of
a concatenation of other identifiers. These are expressed using
double-colon ("::") notation.
Where the same identifier type is used multiple times in a
concatenation, they are qualified by a prefix joined to the
identifier by a dash ("-"). For example, Src-Node_ID is the Node_ID
of a node referred to as "Src" ("Src" is short for "source").
The notation does not define an implicit ordering of the information
elements involved in a concatenated identifier.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. PW Status Refresh Reduction Protocol</span>
The PW status refresh reduction protocol consists of a simple message
that is sent at the LSP level, using the MPLS Generic Associated
Channel (G-ACh) [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>].
For a particular LSP where the PW status refresh reduction protocol
is enabled, a PE using this protocol MUST send the PW status refresh
reduction Message as soon as a PW is configured on that LSP. The
message is then retransmitted at a locally configured interval
indicated in the Refresh Timer field. If no acknowledgment is
received, the protocol does not reach the ACTIVE state
(<a href="#section-2.1.3">Section 2.1.3</a>), and the PE SHOULD NOT send any PW status messages
with a Refresh Timer of zero as described in <a href="./rfc6478#section-5.3.1">[RFC6478],
Section 5.3.1</a>.
It is worth noting that no relationship exists between the locally
configured timer for the PW status refresh reduction protocol and the
individual PW status Refresh Timers.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Protocol States</span>
The protocol can be in three possible states: INACTIVE, STARTUP, and
ACTIVE.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. INACTIVE</span>
This state is entered when the protocol is turned off. This state is
also entered if all PWs on a specific LSP are deprovisioned.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. STARTUP</span>
In this state, the PE transmits periodic PW status refresh reduction
Messages with the Ack Session ID (<a href="#section-4">Section 4</a>) set to 0. The PE
remains in this state until a PW status refresh message is received
with the correct local Session ID in the Ack Session ID field. State
can transition from the STARTUP state to the ACTIVE or INACTIVE
state.
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. ACTIVE</span>
This state is entered once the PE receives a PW status refresh
reduction Message with the correct local Session ID in the Ack
Session ID field within 3.5 times the Refresh Timer field value of
the last PW status refresh reduction Message transmitted. This state
is immediately exited in the following scenarios:
i. A valid PW status refresh reduction Message is not received
within 3.5 times the current Refresh Timer field value (assuming
that a timer transition procedure is not in progress).
New state: STARTUP.
ii. A PW status refresh reduction Message is received with the wrong
Ack Session ID field value or a zero Ack Session ID field value.
New state: STARTUP.
iii. All PWs using the particular LSP are deprovisioned, or the
protocol is disabled.
New state: INACTIVE.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Timer Value Change Transition Procedure</span>
If a PE needs to change the value of the Refresh Timer field while
the PW status refresh reduction protocol is in the ACTIVE state, the
following procedure must be followed:
i. A PW status refresh reduction Message is transmitted with the
new timer value.
ii. If the new value is greater than the original one, the PE will
operate according to the new timer value immediately.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
iii. If the new value is smaller than the original one, the PE will
operate according to the original timer value for a period
3.5 times the original timer value or until the first valid PW
status refresh reduction Message is received.
A PE receiving a PW status refresh reduction Message with a new
timer value will immediately acknowledge the new value via a PW
status refresh reduction Message and will start operating
according to the new timer value.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. PW Status Refresh Reduction Procedure</span>
When the PW status refresh reduction protocol on a particular LSP is
in the ACTIVE state, the PE can send all PW status messages, for PWs
on that LSP, with a Refresh Timer value of zero. This greatly
decreases the amount of messages that the PE needs to transmit to the
remote PE because once the PW status message for a particular PW is
acknowledged, further repetitions of that message are no longer
necessary.
To further reduce the amount of possible messages when an LSP starts
forwarding traffic, care should be taken to permit the PW status
refresh reduction protocol to reach the ACTIVE state quickly, and
before the first PW status Refresh Timer expires. This can be
achieved by using a PW status refresh reduction Message Refresh Timer
value that is much smaller than the PW status message Refresh Timer
value in use (<a href="./rfc6478#section-5.3.1">Section 5.3.1 of [RFC6478]</a>).
If the PW status refresh reduction protocol session is terminated by
entering the INACTIVE state or the STARTUP state, the PE MUST
immediately resend all the previously sent PW status messages for
that particular LSP for which the session was terminated. In this
case, the Refresh Timer value MUST NOT be set to 0 and MUST be set
according to the local policy of the PE router. Implementations MUST
take care to avoid flooding the remote PE with a large number of PW
status messages at once. If the PW status refresh reduction protocol
session is terminated for administrative reasons and the local PE can
still communicate with the remote PE, the local PE SHOULD pace the
transmission of PW status messages to the remote PE.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. PW Status Refresh Reduction Message Encoding</span>
The packet containing the PW status refresh reduction Message is
encoded as follows (omitting link-layer information):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS LSP (tunnel) Label Stack Entry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x29 PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Ack Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | Total Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Message Type |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Control Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message contains the following fields:
* MPLS LSP (tunnel) Label Stack Entry
The label stack is explained in [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>].
* GAL
The G-ACh Label (GAL) and the next 4 octets (including the PW
OAM Message field as the Channel Type) are explained in
<a href="./rfc5586#section-2.1">Section 2.1 of [RFC5586]</a>.
* PW OAM Message
This field indicates the Channel Type in the G-ACh header, as
described in <a href="./rfc5586#section-2.1">Section 2.1 of [RFC5586]</a>.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
* Session ID
A non-zero locally selected session number that is not
preserved if the local PE restarts.
In order to get a locally unique Session ID, the recommended
choice is to perform a CRC-16 ("CRC" stands for "Cyclic
Redundancy Check"), giving as input the following data:
|YY|MM|DD|HHMMSSLLL|
Where:
YY = the last two decimal digits of the current year
MM = the two decimal digits of the current month
DD = the two decimal digits of the current day
HHMMSSLLL = the decimal digits of the current time,
expressed in hours (HH), minutes (MM), seconds (SS), and
milliseconds (LLL)
If the calculation results in an already-existing Session ID, a
unique Session ID can be generated by adding 1 to the result
until the Session ID is unique. Any other method to generate a
locally unique Session ID is also acceptable.
* Ack Session ID
The Acknowledgment Session ID received from the remote PE.
* Refresh Timer
A non-zero unsigned 16-bit integer value greater than or equal
to 10, expressed in milliseconds, that indicates the desired
refresh interval. The default value of 30000 is RECOMMENDED.
* Total Message Length
Total length in octets of the Checksum, Message Type, Flags,
Message Sequence Number, and Control Message Body. A value of
zero means that no control message is present and, therefore,
that no Checksum or subsequent fields are present either.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
* Checksum
A 16-bit field containing the one's complement of the one's
complement sum of the entire message (including the G-ACh
header), with the Checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value means
that no checksum was transmitted. Note that when the checksum
is not computed, the header of the bundle message will not be
covered by any checksum.
* Message Sequence Number
An unsigned 16-bit integer that is started from 1 when the
protocol enters the ACTIVE state. The sequence number wraps
back to 1 when the maximum value is reached. The value 0 is
reserved and MUST NOT be used.
* Last Received Message Sequence Number
The sequence number of the last message received. If no
message has yet been received during this session, this field
is set to 0.
* Message Type
The type of control message that follows. Control message
types are allocated in this document and by IANA.
* (U) Unknown flag bit
Upon receipt of an unknown message or TLV, if U is clear (0),
a notification message with code "Unknown TLV (U-Bit=0)"
(code 0x4) MUST be sent to the remote PE, and the keepalive
session MUST be terminated by entering the STARTUP state; if
U is set (1), the unknown message, or message containing an
unknown TLV, MUST be acknowledged and silently ignored, and the
following messages, or TLVs, if any, processed as if the
unknown message or TLV did not exist. In this case, the PE MAY
send back a single notification message per keepalive session
with code "Unknown TLV (U-Bit=1)". This last step is OPTIONAL.
* (C) Configuration flag bit
The C-Bit is used to signal the end of PW configuration
transmission. If it is set, the sending PE has finished
sending all of its current configuration information.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
* Flags
The remaining 6 bits of PW status refresh reduction Message
Flags to be allocated by IANA. These unallocated bits MUST be
set to 0 on transmission and ignored on reception.
* Control Message Body
The Control Message Body is defined in <a href="#section-5">Section 5</a> and is
specific to the type of message.
It should be noted that the Checksum, Message Sequence Number, Last
Received Message Sequence Number, Message Type, Flags, and Control
Message Body are OPTIONAL. The Total Message Length field is used to
parse how many optional fields are included. Hence, all optional
fields that precede a specific field that needs to be included in a
specific implementation MUST be included if that optional field is
also included.
If any of the above values are outside the specified range, a
notification message is returned with code "PW configuration not
supported", and the message is ignored.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. PW Status Refresh Reduction Control Messages</span>
PW status refresh reduction Control Messages consist of the Checksum,
Message Sequence Number, Last Received Message Sequence Number,
Message Type, Flags, and Control Message Body.
When a PW status refresh reduction Control Message needs to be sent,
the system can attach it to a scheduled PW status refresh reduction
Message or send one ahead of time. In any case, PW status refresh
reduction Control Messages always piggyback on normal messages.
A PW status refresh reduction Message is also called a PW status
refresh reduction Control Message if it contains a control message
construct.
There can only be one control message construct per PW status refresh
reduction Message. If the U-Bit is set and a PE receiving the PW
status refresh reduction Message does not understand the control
message, the control message MUST be silently ignored. However, the
Message Sequence Number MUST still be acknowledged by sending a Null
Notification message back with the appropriate value in the Last
Message Received field. If a control message is not acknowledged
after 3.5 times the value of the Refresh Timer, a fatal notification
-- "Unacknowledged control message" -- MUST be sent, and the PW
status refresh reduction session MUST be terminated.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
If a PE does not want or need to send a control message, the Checksum
and all subsequent fields MUST NOT be sent, and the Total Message
Length field is then set to 0.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Notification Message</span>
The most common use of the notification message is to acknowledge the
reception of a message by indicating the received Message Sequence
Number in the Last Received Sequence Number field. The notification
message is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Type=0x01 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message type is set to 0x01, and the U-Bit is treated as
described in <a href="#section-4">Section 4</a>. The Notification Codes are 32-bit quantities
assigned by IANA (see the IANA Considerations section). Notification
codes are considered either "Error codes" or simple notifications.
If the Notification Code is an Error code as indicated in the IANA
allocation registry, the keepalive session MUST be terminated by
entering the STARTUP state.
When there is no notification information to be sent, the
notification code is set to 0 to indicate a "Null Notification". The
C-Bit MUST always be set to 0 in this type of message. The remaining
6 bits of PW status refresh reduction Message Flags are to be
allocated by IANA. These unallocated bits MUST be set to 0 on
transmission and ignored on reception.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. PW Configuration Message</span>
The PW status refresh reduction TLVs are informational TLVs that
allow the remote PE to verify certain provisioning information. This
message contains a series of sub-TLVs, in no particular order, that
contain PW and LSP configuration information. The message has no
preset length limit; however, its total length will be limited by the
transport network's Maximum Transmission Unit (MTU). PW status
refresh reduction Messages MUST NOT be fragmented. If a sender has
more configuration information to send than will fit into one PW
Configuration Message, it may send additional messages carrying
additional TLVs.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Received Sequence Number | Type=0x02 |U|C| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| PW Configuration Message Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Configuration Message type is set to 0x02. For this message,
the U-Bit is set to 1, as processing of these messages is OPTIONAL.
The C-Bit is used to signal the end of PW configuration transmission.
If it is set, the sending PE has finished sending all of its current
configuration information. The PE transmitting the configuration
MUST set the C-Bit on the last PW Configuration Message when all
current PW configuration information has been sent.
PW Configuration Message sub-TLVs have the following generic 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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Value (Continued) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. MPLS-TP Tunnel ID</span>
This TLV contains the MPLS-TP Tunnel ID ("MPLS-TP" stands for "MPLS
Transport Profile"). When the configuration message is used for a
particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be
sent at least once.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
The MPLS-TP Tunnel ID is encoded as follows:
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=0x01 | Length=20 | MPLS-TP Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| MPLS-TP Tunnel ID (Continued) (20 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPLS point-to-point tunnel ID is defined in [<a href="./rfc6370" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">RFC6370</a>]. The
coding used by the node that is the source of a message is:
Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
Dst-Tunnel_Num
Note that a single tunnel ID is enough to identify the tunnel and the
source end of the message.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. PW ID Configured List</span>
This OPTIONAL sub-TLV contains a list of the provisioned PWs on
the LSP.
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=0x02 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW Path ID (Continued) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Path ID is a 32-octet PW path identifier [<a href="./rfc6370" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">RFC6370</a>]. The
coding used by the node that is the source of a message is:
AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
Dst-Global_ID::Dst-Node_ID::Dst-AC_ID
The number of PW Path IDs in the TLV will be inferred by the length
of the TLV, up to a maximum of 8. The procedure for processing this
TLV will be described in <a href="#section-6">Section 6</a>.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. PW ID Unconfigured List</span>
This OPTIONAL sub-TLV contains a list of the PWs that have been
deprovisioned on the LSP. Note that sending the same PW address in
both the PW ID Configured List sub-TLV and the PW ID Unconfigured
List sub-TLV in the same configuration message constitutes a fatal
session error. If this error occurs, an error notification message
is returned with the Error code "PW Configuration TLV conflict", and
the session is terminated by entering the STARTUP state.
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=0x03 | Length | PW Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PW Path ID (Continued) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Path ID is a 32-octet PW path identifier as defined in
<a href="#section-5.2.2">Section 5.2.2</a>.
The number of PW Path IDs in the TLV will be inferred by the length
of the TLV, up to a maximum of 8.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. PW Provisioning Verification Procedure</span>
The advertisement of the PW Configuration Message is OPTIONAL.
A PE that desires to use the PW Configuration Message to verify the
configuration of PWs on a particular LSP should advertise its PW
configuration to the remote PE on LSPs that have active keepalive
sessions. When a PE receives PW configuration information using this
protocol and it does not support processing the information or is not
willing to process it, it MUST acknowledge all the PW Configuration
Messages with the notification code "PW configuration not supported".
In this case, the information in the PW Configuration Message is
silently ignored. If a PE receives such a notification, it SHOULD
stop sending PW Configuration Messages for the duration of the PW
status refresh reduction keepalive session.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
If PW configuration information is received, it is used to verify the
accuracy of the local configuration information against the remote
PE's configuration information. If a configuration mismatch is
detected, where a particular PW is configured locally but not on the
remote PE, the following actions SHOULD be taken:
i. The local PW MUST be considered in "Not Forwarding" state
(<a href="./rfc8077#section-6.3.2">Section 6.3.2 of [RFC8077]</a>).
ii. The PW Attachment Circuit status is set to reflect the PW fault.
iii. An alarm SHOULD be raised to a network management system.
iv. A notification message with the notification code "PW
configuration mismatch" MUST be sent to the remote PE. Only one
such message is REQUIRED per configuration message even if the
configuration message is split into multiple configuration
messages due to individual message-size restrictions on a
particular link. Upon receipt of such a message, the receiving
PE MAY raise an alarm to a network management system. This
alarm MAY be cleared when the configuration is updated.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. PW ID List Advertising and Processing</span>
When configuration messages are advertised on a particular LSP, the
PE sending the messages needs to checkpoint the configuration
information sent by setting the C-Bit when all currently known
configuration information has been sent. This process allows the
receiving PE to immediately proceed to verify all the currently
configured PWs on that LSP, eliminating the need for a long waiting
period.
If a new PW is added to a particular LSP, the PE MUST place the
configuration verification of this PW on hold for a period of at
least 30 seconds. This is necessary to minimize false-positive
events of misconfiguration due to the ends of the PW being slightly
out of sync.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The security considerations discussed in [<a href="./rfc6478" title=""Pseudowire Status for Static Pseudowires"">RFC6478</a>] are adequate for
the mechanism described in this document, since the operating
environment is almost identical to the one where this protocol would
be deployed. It should also be noted that since this protocol is
designed to be deployed between two adjacent PEs connected by a
physical link, it is not possible to misdirect or inject traffic
without compromising the PW transport link itself.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
The registries in this section have been created or updated as
appropriate in the "Pseudowire Name Spaces (PWE3)" registry or the
"Generic Associated Channel (G-ACh) Parameters" registry. For the
allocation ranges designated as "vendor-proprietary extensions", the
respective IANA registry contains the vendor name in brackets at the
end of the Description field.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. PW Status Refresh Reduction Message Types</span>
IANA has set up the "PW Status Refresh Reduction Control Messages"
registry. This registry contains 8-bit values. Type values 1 and 2
are defined in this document. Type values 3 through 64 and 128
through 254 are to be assigned by IANA using the "Expert Review"
policy defined in [<a href="./rfc8126" title="">RFC8126</a>]. Type values 65 through 127, 0, and 255
are to be allocated using the "IETF Review" policy defined in
[<a href="./rfc8126" title="">RFC8126</a>].
The Type values are assigned as follows:
Type Message Description
---- ------------------------
0x01 Notification message
0x02 PW Configuration Message
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. PW Configuration Message Sub-TLVs</span>
IANA has set up the "PW Status Refresh Reduction Configuration
Message Sub-TLVs" registry. This registry contains 8-bit values.
Type values 1 through 3 are defined in this document. Type values 4
through 64 and 128 through 254 are to be assigned by IANA using the
"Expert Review" policy defined in [<a href="./rfc8126" title="">RFC8126</a>]. Type values 65 through
127, 0, and 255 are to be allocated using the "IETF Review" policy
defined in [<a href="./rfc8126" title="">RFC8126</a>].
The Type values are assigned as follows:
Sub-TLV Type Description
------------ -----------------------
0x01 MPLS-TP Tunnel ID
0x02 PW ID Configured List
0x03 PW ID Unconfigured List
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. PW Status Refresh Reduction Notification Codes</span>
IANA has set up the "PW Status Refresh Reduction Notification Codes"
registry. This registry contains 32-bit values. Type values 0
through 7 are defined in this document. Type values 8 through 65536
and 134,217,729 through 4,294,967,294 are to be assigned by IANA
using the "Expert Review" policy defined in [<a href="./rfc8126" title="">RFC8126</a>]. Type values
65537 through 134,217,728, 0, and 4,294,967,295 are to be allocated
using the "IETF Review" policy defined in [<a href="./rfc8126" title="">RFC8126</a>].
For each value assigned, IANA should also track whether the value
constitutes an error as described in <a href="#section-5.1">Section 5.1</a>. When values are
assigned by IETF Review, the settings in the "Error?" column must be
documented in the RFC that requests the allocation. For
"Expert Review" assignments, the settings in the "Error?" column must
be made clear by the requester at the time of assignment.
The Type values are assigned as follows:
Code Error? Description
---------- ------ ------------------------------
0x00000000 No Null Notification
0x00000001 No PW configuration mismatch
0x00000002 Yes PW Configuration TLV conflict
0x00000003 No Unknown TLV (U-Bit=1)
0x00000004 Yes Unknown TLV (U-Bit=0)
0x00000005 No Unknown Message Type
0x00000006 No PW configuration not supported
0x00000007 Yes Unacknowledged control message
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. PW Status Refresh Reduction Message Flags</span>
IANA has set up the "PW Status Refresh Reduction Message Flags"
registry. This is an 8-bit registry, with the first two most
significant bits allocated by this document as follows:
Bit Position Name Description
------------ ---- ----------------------
0 U Unknown flag bit
1 C Configuration flag bit
The remaining bits are to be allocated using the "IETF Review" policy
defined in [<a href="./rfc8126" title="">RFC8126</a>].
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>. G-ACh Registry Allocation</span>
IANA maintains a registry called "MPLS Generalized Associated Channel
(G-ACh) Types (including Pseudowire Associated Channel Types)". IANA
has allocated a new value as follows:
Value Description Reference
----- --------------------------- ---------
0x29 PW Status Refresh Reduction <a href="./rfc8237">RFC 8237</a>
<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>. Guidance for Designated Experts</span>
In all cases of review by the Designated Expert (DE) described here,
the DE is expected to ascertain the existence of suitable
documentation (a specification) as described in [<a href="./rfc8126" title="">RFC8126</a>] and to
verify that the document is permanently and publicly available. The
DE is also expected to check that the clarity of purpose and use of
the requested code points fit the general architecture and intended
purpose of the respective message or TLV. Lastly, the DE should
check that any assignment does not duplicate or conflict with work
that is active or already published within the IETF.
<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-RFC3031">RFC3031</a>] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", <a href="./rfc3031">RFC 3031</a>,
DOI 10.17487/RFC3031, January 2001,
<<a href="https://www.rfc-editor.org/info/rfc3031">https://www.rfc-editor.org/info/rfc3031</a>>.
[<a id="ref-RFC6370">RFC6370</a>] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", <a href="./rfc6370">RFC 6370</a>,
DOI 10.17487/RFC6370, September 2011,
<<a href="https://www.rfc-editor.org/info/rfc6370">https://www.rfc-editor.org/info/rfc6370</a>>.
[<a id="ref-RFC6478">RFC6478</a>] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", <a href="./rfc6478">RFC 6478</a>,
DOI 10.17487/RFC6478, May 2012,
<<a href="https://www.rfc-editor.org/info/rfc6478">https://www.rfc-editor.org/info/rfc6478</a>>.
<span class="grey">Martini, 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="./rfc8237">RFC 8237</a> MPLS LSP PW Status Refresh Reduction October 2017</span>
[<a id="ref-RFC8077">RFC8077</a>] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, <a href="./rfc8077">RFC 8077</a>, DOI 10.17487/RFC8077, February 2017,
<<a href="https://www.rfc-editor.org/info/rfc8077">https://www.rfc-editor.org/info/rfc8077</a>>.
[<a id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
<a href="./rfc2119">RFC 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>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC5586">RFC5586</a>] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", <a href="./rfc5586">RFC 5586</a>,
DOI 10.17487/RFC5586, June 2009,
<<a href="https://www.rfc-editor.org/info/rfc5586">https://www.rfc-editor.org/info/rfc5586</a>>.
Authors' Addresses
Luca Martini
Monoski LLC
Email: lmartini@monoski.com
George Swallow
Southend Technical Center
Email: swallow.ietf@gmail.com
Elisa Bellagamba
Ericsson EAB
Torshamnsgatan 48
16480, Stockholm
Sweden
Email: elisa.bellagamba@gmail.com
Martini, et al. Standards Track [Page 20]
</pre>
|
