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
|
<pre>Internet Engineering Task Force (IETF) G. Swallow, Ed.
Request for Comments: 6427 Cisco Systems, Inc.
Category: Standards Track A. Fulignoli, Ed.
ISSN: 2070-1721 Ericsson
M. Vigoureux, Ed.
Alcatel-Lucent
S. Boutros
Cisco Systems, Inc.
D. Ward
Juniper Networks, Inc.
November 2011
MPLS Fault Management Operations, Administration, and Maintenance (OAM)
Abstract
This document specifies Operations, Administration, and Maintenance
(OAM) messages to indicate service disruptive conditions for MPLS-
based transport network Label Switched Paths. The notification
mechanism employs a generic method for a service disruptive condition
to be communicated to a Maintenance Entity Group End Point. This
document defines an MPLS OAM channel, along with messages to
communicate various types of service disruptive conditions.
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/rfc6427">http://www.rfc-editor.org/info/rfc6427</a>.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Requirements Language ......................................<a href="#page-5">5</a>
<a href="#section-2">2</a>. MPLS Fault Management Messages ..................................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. MPLS Alarm Indication Signal ...............................<a href="#page-5">5</a>
<a href="#section-2.1.1">2.1.1</a>. MPLS Link Down Indication ...........................<a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. MPLS Lock Report ...........................................<a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. Propagation of MPLS Fault Messages .........................<a href="#page-7">7</a>
<a href="#section-3">3</a>. MPLS Fault Management Channel ...................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. MPLS Fault Management Message Format ............................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Fault Management Message TLVs ..............................<a href="#page-9">9</a>
<a href="#section-4.1.1">4.1.1</a>. Interface Identifier TLV ...........................<a href="#page-10">10</a>
<a href="#section-4.1.2">4.1.2</a>. Global Identifier ..................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Sending and Receiving Fault Management Messages ................<a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Sending a Fault Management Message ........................<a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Clearing a Fault Management Indication ....................<a href="#page-11">11</a>
<a href="#section-5.3">5.3</a>. Receiving a Fault Management Indication ...................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Minimum Implementation Requirements ............................<a href="#page-12">12</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-13">13</a>
<a href="#section-8.1">8.1</a>. Pseudowire Associated Channel Type ........................<a href="#page-13">13</a>
<a href="#section-8.2">8.2</a>. MPLS Fault OAM Message Type Registry ......................<a href="#page-13">13</a>
<a href="#section-8.3">8.3</a>. MPLS Fault OAM Flag Registry ..............................<a href="#page-14">14</a>
<a href="#section-8.4">8.4</a>. MPLS Fault OAM TLV Registry ...............................<a href="#page-14">14</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-15">15</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-15">15</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-15">15</a>
<a href="#section-10">10</a>. Contributing Authors ..........................................<a href="#page-16">16</a>
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Proper operation of a transport network depends on the ability to
quickly identify faults and focus attention on the root cause of the
disruption. This document defines MPLS Fault Management Operations,
Administration, and Maintenance (OAM) messages. When a fault occurs
in a server (sub-)layer, Fault Management OAM messages are sent to
clients of that server so that alarms, which otherwise would be
generated by the subsequent disruption of the clients, may be
suppressed. This prevents a storm of alarms and allows operations to
focus on the actual faulty elements of the network.
In traditional transport networks, circuits such as T1 lines are
typically provisioned on multiple switches. When an event that
causes disruption occurs on any link or node along the path of such a
transport circuit, OAM indications are generated. When received,
these indications may be used to suppress alarms and/or activate a
backup circuit. The MPLS-based transport network provides mechanisms
equivalent to traditional transport circuits. Therefore, a Fault
Management (FM) capability must be defined for MPLS. This document
defines FM capabilities to meet the MPLS-TP requirements as described
in <a href="./rfc5654">RFC 5654</a> [<a href="#ref-1" title=""Requirements of an MPLS Transport Profile"">1</a>], and the MPLS-TP Operations, Administration, and
Maintenance requirements as described in <a href="./rfc5860">RFC 5860</a> [<a href="#ref-2" title=""Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks"">2</a>]. These
mechanisms are intended to be applicable to other aspects of MPLS as
well. However, applicability to other types of LSPs is beyond the
scope of this document.
Two broad classes of service disruptive conditions are identified.
1. Fault: The inability of a function to perform a required action.
This does not include an inability due to preventive maintenance,
lack of external resources, or planned actions.
2. Lock: an administrative status in which it is expected that only
test traffic, if any, and OAM (dedicated to the LSP) can be sent
on an LSP.
Within this document, a further term is defined: server-failure. A
server-failure occurs when a fault condition or conditions have
persisted long enough to consider the required service function of
the server (sub-)layer to have terminated. In the case of a
protected server, this would mean that the working facilities and any
protection facilities have all suffered faults of the required
duration.
This document specifies an MPLS OAM channel called an "MPLS-OAM Fault
Management (FM)" channel. A single message format and a set of
procedures are defined to communicate service disruptive conditions
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
from the location where they occur to the end points of LSPs that are
affected by those conditions. Multiple message types and flags are
used to indicate and qualify the particular condition.
Corresponding to the two classes of service disruptive conditions
listed above, two messages are defined to communicate the type of
condition. These are known as:
Alarm Indication Signal (AIS)
Lock Report (LKR)
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
ACH: Associated Channel Header
ACh: Associated Channel
CC: Continuity Check
FM: Fault Management
GAL: Generic Associated Channel Label
LOC: Loss of Continuity
LSP: Label Switched Path
MEP: Maintenance Entity Group End Point
MPLS: Multiprotocol Label Switching
MPLS-TP: MPLS Transport Profile
MS-PW: Multi-Segment Pseudowire
OAM: Operations, Administration, and Maintenance
PHP: Penultimate Hop Pop
PW: Pseudowire
TLV: Type, Length, Value
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Requirements Language</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">RFC 2119</a> [<a href="#ref-3" title=""Key words for use in RFCs to Indicate Requirement Levels"">3</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. MPLS Fault Management Messages</span>
This document defines two messages to indicate service disruptive
conditions, Alarm Indication Signal and Lock Report. The semantics
of the individual messages are described in subsections below. Fault
OAM messages are applicable to LSPs used in the MPLS Transport
Profile. Such LSPs are bound to specific server layers based upon
static configuration or signaling in a client/server relationship.
Fault Management messages are carried in-band of the client LSP or
MS-PW by using the Associated Channel Header (ACH). For LSPs other
than PWs, the ACH is identified by the Generic Associated Channel
Label (GAL) as defined in <a href="./rfc5586">RFC 5586</a> [<a href="#ref-4" title=""MPLS Generic Associated Channel"">4</a>]. To facilitate recognition
and delivery of Fault Management messages, the Fault Management
Channel is identified by a unique Associated Channel (ACh) code
point.
Fault OAM messages are generated by intermediate nodes where a client
LSP is switched. When a server (sub-)layer, e.g., a link or
bidirectional LSP, used by the client LSP fails, the intermediate
node sends Fault Management messages downstream towards the end point
of the LSP. The messages are sent to the client MEPs by inserting
them into the affected client LSPs in the direction downstream of the
fault location. These messages are sent periodically until the
condition is cleared.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. MPLS Alarm Indication Signal</span>
The MPLS Alarm Indication Signal (AIS) message is generated in
response to detecting faults in the server (sub-)layer. The AIS
message SHOULD be sent as soon as the condition is detected, but MAY
be delayed owing to processing in an implementation, and MAY be
suppressed if protection is achieved very rapidly. For example, an
AIS message may be sent during a protection switching event and would
cease being sent (or cease being forwarded by the protection switch
selector) if the protection switch was successful in restoring the
link. However, an implementation may instead wait to see if the
protection switch is successful prior to sending any AIS messages.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
The primary purpose of the AIS message is to suppress alarms in the
layer network above the level at which the fault occurs. When the
Link Down Indication is set, the AIS message can be used to trigger
recovery mechanisms.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. MPLS Link Down Indication</span>
The Link Down Indication (LDI) is communicated by setting the L-Flag
to 1. A node sets the L-Flag in the AIS message in response to
detecting a failure in the server layer. A node MUST NOT set the
L-Flag until the fault has been determined to be a server-failure. A
node MUST set the L-Flag if the fault has been determined to be a
server-failure. For example, during a server layer protection
switching event, a node MUST NOT set the L-Flag. However, if the
protection switch was unsuccessful in restoring the link within the
expected repair time, the node MUST set the L-Flag.
The setting of the L-Flag can be predetermined based on the
protection state. For example, if a server layer is protected and
both the working and protection paths are available, the node should
send AIS with the L-Flag clear upon detecting a fault condition. If
the server layer is unprotected, or the server layer is protected but
only the active path is available, the node should send AIS with the
L-Flag set upon detecting a loss of continuity (LOC) condition. Note
again that the L-Flag is not set until a server-failure has been
declared. Thus, if there is any hold-off timer associated with the
LOC, then the L-Flag is not set until that timer has expired.
The receipt of an AIS message with the L-Flag set MAY be treated as
the equivalent of LOC at the client layer. The choice of treatment
is related to the rate at which the Continuity Check (CC) function is
running. In a normal transport environment, CC is run at a high rate
in order to detect a failure within tens of milliseconds. In such an
environment, the L-Flag MAY be ignored and the AIS message is used
solely for alarm suppression.
In more general MPLS environments, the CC function may be running at
a much slower rate. In this environment, the Link Down Indication
enables faster switch-over upon a failure occurring along the client
LSP.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. MPLS Lock Report</span>
The MPLS Lock Report (LKR) message is generated when a server
(sub-)layer entity has been administratively locked. Its purpose is
to communicate the locked condition to the client-layer entities.
When a server layer is administratively locked, it is not available
to carry client traffic. The purpose of the LKR message is to
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
suppress alarms in the layer network above the level at which the
administrative lock occurs and to allow the clients to differentiate
the lock condition from a fault condition. While the primary purpose
of the LKR message is to suppress alarms, similar to AIS with the LDI
(L-Flag set), the receipt of an LKR message can be treated as the
equivalent of loss of continuity at the client layer.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Propagation of MPLS Fault Messages</span>
MPLS-TP allows for a hierarchy of LSPs. When the client MEP of an
LSP (that is also acting as a server layer) receives FM indications,
the following rules apply. If the CC function is disabled for the
server LSP, a node SHOULD generate AIS messages toward any clients
when either the AIS or LKR indication is raised. Note that the
L-Flag is not automatically propagated. The rules of <a href="#section-2.1.1">Section 2.1.1</a>
apply. In particular, the L-Flag is not set until a server-failure
has been declared.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. MPLS Fault Management Channel</span>
The MPLS Fault Management channel is identified by the ACH as defined
in <a href="./rfc5586">RFC 5586</a> [<a href="#ref-4" title=""MPLS Generic Associated Channel"">4</a>] with the Associated Channel Type set to the MPLS
Fault Management (FM) code point = 0x0058. The FM Channel does not
use ACh TLVs and MUST NOT include the ACh TLV header. The ACH with
the FM ACh code point is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x0058 FM Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ MPLS Fault Management Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of the MPLS Fault Management Channel
The first three fields are defined in <a href="./rfc5586">RFC 5586</a> [<a href="#ref-4" title=""MPLS Generic Associated Channel"">4</a>].
The Fault Management Channel is 0x0058.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. MPLS Fault Management Message Format</span>
The format of the Fault Management message is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Resvd | Msg Type | Flags | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Len | ~
+-+-+-+-+-+-+-+-+ TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS Fault OAM Message Format
Version
The Version Number is currently 1.
Reserved
This field MUST be set to zero on transmission and ignored on
receipt.
Message Type
The Message Type indicates the type of condition as listed in the
table below.
Msg Type Description
-------- -----------------------------
0 Reserved
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
Flags
Two flags are defined. The reserved flags in this field MUST be
set to zero on transmission and ignored on receipt.
+-+-+-+-+-+-+-+-+
| Reserved |L|R|
+-+-+-+-+-+-+-+-+
Figure 3: Flags
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
L-Flag
Link Down Indication. The L-Flag only has significance in the
AIS message. For the LKR message, the L-Flag MUST be set to
zero and ignored on receipt. See <a href="#section-2.1.1">Section 2.1.1</a> for details on
setting this bit.
R-Flag
The R-Flag is clear to indicate the presence of an FM condition
and is set to one to indicate the removal of a previously sent
FM condition.
Refresh Timer
The maximum time between successive FM messages specified in
seconds. The range is 1 to 20. The value 0 is not permitted.
Total TLV Length
The total length in bytes of all included TLVs.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Fault Management Message TLVs</span>
TLVs are used in Fault Management messages to carry information that
may not pertain to all messages as well as to allow for
extensibility. The TLVs currently defined are the IF_ID and the
Global_ID.
TLVs have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| .
. Value .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Fault TLV Format
Type
Encodes how the Value field is to be interpreted.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
Length
Specifies the length of the Value field in octets.
Value
Octet string of Length octets that encodes information to be
interpreted as specified by the Type field.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Interface Identifier TLV</span>
The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in
<a href="./rfc6370">RFC 6370</a> [<a href="#ref-5" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">5</a>]. The Type is 1. The length is 0x8.
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-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Interface Identifier TLV Format
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Global Identifier</span>
The Global Identifier (Global_ID) TLV carries the Global_ID as
defined in <a href="./rfc6370">RFC 6370</a> [<a href="#ref-5" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">5</a>]. The Type is 2. The length is 0x4.
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-TP Global Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Global Identifier TLV Format
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Sending and Receiving Fault Management Messages</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Sending a Fault Management Message</span>
Service disruptive conditions are indicated by sending FM messages.
The message type is set to the value corresponding to the condition.
The Refresh Timer is set to the maximum time between successive FM
messages. This value MUST NOT be changed on successive FM messages
reporting the same incident. If the optional clearing procedures are
not used, then the default value is one second. Otherwise, the
default value is 20 seconds.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
A Global_ID MAY be included. If the R-Flag clearing procedures are
to be used, the IF_ID TLV MUST be included. Otherwise, the IF_ID TLV
MAY be included.
The message is then sent. Assuming the condition persists, the
message MUST be retransmitted two more times at an interval of one
second. Further retransmissions are made according to the value of
the Refresh Timer. Retransmissions continue until the condition is
cleared.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Clearing a Fault Management Indication</span>
When a fault is cleared, a node MUST cease sending the associated FM
messages. Ceasing to send FM messages will clear the indication
after 3.5 times the Refresh Timer. To clear an indication more
quickly, the following procedure is used. The R-Flag of the FM
message is set to one. Other fields of the FM message SHOULD NOT be
modified. The message is sent immediately and then retransmitted two
more times at an interval of one second. Note, however, if another
fault occurs, the node MUST cease these retransmissions and generate
new FM messages for the new fault.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Receiving a Fault Management Indication</span>
When an FM message is received, a MEP examines it to ensure that it
is well formed. If the message type is reserved or unknown, the
message is ignored. If the version number is unknown, the message is
ignored.
If the R-Flag is set to zero, the MEP checks to see if a condition
matching the message type exists. If it does not, the condition
specific to the message type is entered. An Expiration timer is set
to 3.5 times the Refresh Timer. If the message type matches an
existing condition, the message is considered a refresh and the
Expiration timer is reset. In both cases, if an IF_ID TLV is
present, it is recorded.
If the R-Flag is set to one, the MEP checks to see if a condition
matching the message type and IF_ID exists. If it does, that
condition is cleared. Otherwise, the message is ignored.
If the Expiration timer expires, the condition is cleared.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Minimum Implementation Requirements</span>
At a minimum, an implementation MUST support the following:
1. Sending AIS and LKR messages at a rate of one per second.
2. Support of setting the L-Flag to indicate a server-failure.
3. Receiving AIS and LKR messages with any allowed Refresh Timer
value.
The following items are OPTIONAL to implement.
1. Sending AIS and LKR messages with values of the Refresh Timer
other than one second.
2. Support of receiving the L-Flag.
3. Support of setting the R-Flag to a value other than zero.
4. Support of receiving the R-Flag.
5. All TLVs.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
the security model of MPLS. MPLS networks make the assumption that
it is very hard to inject traffic into a network, and equally hard to
cause traffic to be directed outside the network. The control-plane
protocols utilize hop-by-hop security and assume a "chain-of-trust"
model such that end-to-end control-plane security is not used. For
more information on the generic aspects of MPLS security, see <a href="./rfc5920">RFC</a>
<a href="./rfc5920">5920</a> [<a href="#ref-8" title=""Security Framework for MPLS and GMPLS Networks"">8</a>].
This document describes a protocol carried in the G-ACh (<a href="./rfc5586">RFC 5586</a>
[<a href="#ref-4" title=""MPLS Generic Associated Channel"">4</a>]) and so is dependent on the security of the G-ACh itself. The
G-ACh is a generalization of the Associated Channel defined in <a href="./rfc4385">RFC</a>
<a href="./rfc4385">4385</a> [<a href="#ref-6" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">6</a>]. Thus, this document relies heavily on the security
mechanisms provided for the Associated Channel as described in those
two documents.
A specific concern for the G-ACh is that is can be used to provide a
covert channel. This problem is wider than the scope of this
document and does not need to be addressed here, but it should be
noted that the channel provides end-to-end connectivity and SHOULD
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
NOT be policed by transit nodes. Thus, there is no simple way of
preventing any traffic being carried in the G-ACh between consenting
nodes.
A good discussion of the data-plane security of an Associated Channel
may be found in <a href="./rfc5085">RFC 5085</a> [<a href="#ref-9" title=""Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires"">9</a>]. That document also describes some
mitigation techniques.
It should be noted that the G-ACh is essentially connection-oriented,
so injection or modification of control messages specified in this
document requires the subversion of a transit node. Such subversion
is generally considered hard to protect against in MPLS networks, and
impossible to protect against at the protocol level. Management-
level techniques are more appropriate.
Spurious fault OAM messages form a vector for a denial-of-service
attack. However, since these messages are carried in a control
channel, except for one case discussed below, one would have to gain
access to a node providing the service in order to effect such an
attack. Since transport networks are usually operated as a walled
garden, such threats are less likely.
If external MPLS traffic is mapped to an LSP via a PHP forwarding
operation, it is possible to insert a GAL followed by a fault OAM
message. In such a situation, an operator SHOULD protect against
this attack by filtering any fault OAM messages with the GAL at the
top of the label stack.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Pseudowire Associated Channel Type</span>
Fault OAM requires a unique Associated Channel Type that has been
assigned by IANA from the Pseudowire Associated Channel Types
registry.
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0058 Fault OAM No (This Document)
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. MPLS Fault OAM Message Type Registry</span>
This section details the "MPLS Fault OAM Message Type Registry", a
new sub-registry of the "Multiprotocol Label Switching (MPLS)
Operations, Administration, and Management (OAM) Parameters"
registry. The Type space is divided into assignment ranges; the
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
following terms are used in describing the procedures by which IANA
allocates values (as defined in <a href="./rfc5226">RFC 5226</a> [<a href="#ref-7" title="">7</a>]): "Standards Action" and
"Experimental Use".
MPLS Fault OAM Message Types take values in the range 0-255.
Assignments in the range 0-251 are via Standards Action; values in
the range 252-255 are for Experimental Use and MUST NOT be allocated.
Message Types defined in this document are:
Msg Type Description
-------- -----------------------------
0 Reserved (not available for allocation)
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. MPLS Fault OAM Flag Registry</span>
This section details the "MPLS Fault OAM Flag Registry", a new sub-
registry of the "Multiprotocol Label Switching (MPLS) Operations,
Administration, and Management (OAM) Parameters" registry. The Flag
space ranges from 0-7. All flags are allocated by "Standards Action"
(as defined in <a href="./rfc5226">RFC 5226</a> [<a href="#ref-7" title="">7</a>]).
Flags defined in this document are:
Bit Hex Value Description
--- --------- -----------
0-5 Unassigned
6 0x2 L-Flag
7 0x1 R-Flag
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. MPLS Fault OAM TLV Registry</span>
This sections details the "MPLS Fault OAM TLV Registry", a new sub-
registry of the "Multiprotocol Label Switching (MPLS) Operations,
Administration, and Management (OAM) Parameters" registry. The Type
space is divided into assignment ranges; the following terms are used
in describing the procedures by which IANA allocates values (as
defined in <a href="./rfc5226">RFC 5226</a> [<a href="#ref-7" title="">7</a>]): "Standards Action", "Specification
Required", and "Experimental Use".
MPLS Fault OAM TLVs take values in the range 0-255. Assignments in
the range 0-191 are via Standards Action; assignments in the range
192-247 are made via "Specification Required"; values in the range
248-255 are for Experimental Use and MUST NOT be allocated.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
TLVs defined in this document are:
Value TLV Name
----- -------
0 Reserved (not available for allocation)
1 Interface Identifier TLV
2 Global Identifier
<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-1">1</a>] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport
Profile", <a href="./rfc5654">RFC 5654</a>, September 2009.
[<a id="ref-2">2</a>] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and Maintenance
(OAM) in MPLS Transport Networks", <a href="./rfc5860">RFC 5860</a>, May 2010.
[<a id="ref-3">3</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-4">4</a>] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS
Generic Associated Channel", <a href="./rfc5586">RFC 5586</a>, June 2009.
[<a id="ref-5">5</a>] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile
(MPLS-TP) Identifiers", <a href="./rfc6370">RFC 6370</a>, September 2011.
[<a id="ref-6">6</a>] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN", <a href="./rfc4385">RFC 4385</a>, February 2006.
[<a id="ref-7">7</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>, May 2008.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-8">8</a>] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks",
<a href="./rfc5920">RFC 5920</a>, July 2010.
[<a id="ref-9">9</a>] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control Channel for
Pseudowires", <a href="./rfc5085">RFC 5085</a>, December 2007.
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Contributing Authors</span>
Stewart Bryant
Cisco Systems, Inc.
250, Longwater
Green Park, Reading RG2 6GB
UK
EMail: stbryant@cisco.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: msiva@cisco.com
<span class="grey">Swallow, 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="./rfc6427">RFC 6427</a> MPLS Fault Management OAM November 2011</span>
Authors' Addresses
George Swallow (editor)
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
EMail: swallow@cisco.com
Annamaria Fulignoli (editor)
Ericsson
Via Moruzzi
Pisa 56100
Italy
EMail: annamaria.fulignoli@ericsson.com
Martin Vigoureux (editor)
Alcatel-Lucent
Route de Villejust
Nozay 91620
France
EMail: martin.vigoureux@alcatel-lucent.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
EMail: sboutros@cisco.com
David Ward
Juniper Networks, Inc.
EMail: dward@juniper.net
Swallow, et al. Standards Track [Page 17]
</pre>
|
