draft-ietf-mpls-tp-fault-00.txt   draft-ietf-mpls-tp-fault-01.txt 
MPLS Working Group G. Swallow, Ed. MPLS Working Group G. Swallow, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Fulignoli, Ed. Intended status: Standards Track A. Fulignoli, Ed.
Expires: July 30, 2010 Ericsson Expires: September 9, 2010 Ericsson
M. Vigoureux, Ed. M. Vigoureux, Ed.
Alcatel-Lucent Alcatel-Lucent
January 26, 2010 March 8, 2010
MPLS Fault Management OAM MPLS Fault Management OAM
draft-ietf-mpls-tp-fault-00 draft-ietf-mpls-tp-fault-01
Abstract Abstract
This draft specifies OAM messages to indicate service disruptive This draft specifies OAM messages to indicate service disruptive
conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths
(LSPs). The notification mechanism employs a generic method for a (LSPs). The notification mechanism employs a generic method for a
service disruptive condition to be communicated to a Maintenance End service disruptive condition to be communicated to a Maintenance End
Point (MEP). An MPLS Operation, Administration, and Maintenance Point (MEP). An MPLS Operation, Administration, and Maintenance
(OAM) channel is defined along with messages to communicate various (OAM) channel is defined along with messages to communicate various
types of service disruptive conditions. types of service disruptive conditions.
skipping to change at page 1, line 46 skipping to change at page 2, line 6
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 30, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 5
2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 5 2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . 6
2.2. MPLS-TP Link Down Indication . . . . . . . . . . . . . . . 5 2.2. MPLS-TP Link Down Indication . . . . . . . . . . . . . . . 6
2.3. MPLS-TP Locked Report . . . . . . . . . . . . . . . . . . . 6 2.3. The Relationship of AIS to LDI . . . . . . . . . . . . . . 7
3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . . 6 2.4. MPLS-TP Locked Report . . . . . . . . . . . . . . . . . . 7
4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 7
5. Sending and Receiving Fault Management Messages . . . . . . . . 8 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 8
5.1. Sending a Fault Management Message . . . . . . . . . . . . 8 5. Sending and Receiving Fault Management Messages . . . . . . . 9
5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 8 5.1. Sending a Fault Management Message . . . . . . . . . . . . 9
5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . . 8 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 10
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In traditional transport networks, circuits such as T1 lines are In traditional transport networks, circuits such as T1 lines are
provisioned on multiple switches. When a disruption occurs on any provisioned on multiple switches. When a disruption occurs on any
link or node along the path of such a transport circuit, alarms are link or node along the path of such a transport circuit, alarms are
generated which may in turn suppress alarms and/or activate a backup generated which may in turn suppress alarms and/or activate a backup
circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to
emulate traditional transport circuits. Therefore a Fault Management emulate traditional transport circuits. Therefore a Fault Management
(FM) capability must be defined for MPLS. This capability is being (FM) capability must be defined for MPLS. This capability is being
skipping to change at page 6, line 48 skipping to change at page 6, line 48
2.2. MPLS-TP Link Down Indication 2.2. MPLS-TP Link Down Indication
The LDI message is generated in response to detecting a fatal failure The LDI message is generated in response to detecting a fatal failure
in the server layer. The LDI message MUST NOT be sent until the in the server layer. The LDI message MUST NOT be sent until the
defect has been determined to be fatal. For example during a defect has been determined to be fatal. For example during a
protection switching event LDI messages are not sent. However if the protection switching event LDI messages are not sent. However if the
protection switch was unsuccessful in restoring the link within the protection switch was unsuccessful in restoring the link within the
expected repair time, an LDI message MUST be sent. expected repair time, an LDI message MUST be sent.
The receipt of an LDI message SHOULD be treated as the equivalent of The receipt of an LDI message MAY be treated as the equivalent of
loss of continuity at the client layer. Like AIS it also is used to loss of continuity at the client layer. Like AIS it also is used to
suppress alarms. suppress alarms.
2.3. MPLS-TP Locked Report 2.3. The Relationship of AIS to LDI
AIS and LDI are closely related functions and also 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 10s of milliseconds. In such an environment,
AIS and LDI should be treated the same and used solely for alarm
suppression. In more general MPLS environments the CC function may
be running at a much slower rate. In this environment, LDI enables
faster switch-over upon a failure occurring along the LSP.
2.4. MPLS-TP Locked Report
The MPLS-TP Locked Report (LKR) message is generated when a server The MPLS-TP Locked Report (LKR) message is generated when a server
layer entity has been administratively locked to communicated that layer entity has been administratively locked to communicated that
condition to inform the client layer entities of that condition. condition to inform the client layer entities of that condition.
When an MPLS-TP LSP is administratively locked it is not available to When an MPLS-TP LSP is administratively locked it is not available to
carry client traffic. Its purpose is to suppress alarms in the carry client traffic. Its purpose is to suppress alarms in the
MPLS-TP layer network above the level at which the defect occurs and MPLS-TP layer network above the level at which the defect occurs and
to allow the clients to differentiate the lock condition from a to allow the clients to differentiate the lock condition from a
defect condition. defect condition.
The receipt of an LKR message SHOULD be treated as the equivalent of The receipt of an LKR message MAY be treated as the equivalent of
loss of continuity at the client layer. Like AIS it also is used to loss of continuity at the client layer. Like AIS it also is used to
suppress alarms. suppress alarms.
3. MPLS Fault Management Channel 3. MPLS Fault Management Channel
The MPLS Fault Management channel is identified by the ACH as defined The MPLS Fault Management channel is identified by the ACH as defined
in RFC 5586 [4] with the Channel Type set to the MPLS Fault in RFC 5586 [4] with the Channel Type set to the MPLS Fault
Management (FM) code point = 0xHH. [HH to be assigned by IANA from Management (FM) code point = 0xHH. [HH to be assigned by IANA from
the PW Associated Channel Type registry.] The FM Channel uses ACH the PW Associated Channel Type registry.] The FM Channel uses ACH
TLVs and MUST include the ACH TLV header. The FM ACH Channel and ACH TLVs and MUST include the ACH TLV header. The FM ACH Channel and ACH
skipping to change at page 7, line 49 skipping to change at page 8, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ | ~
~ MPLS Fault Management Message ~ ~ MPLS Fault Management Message ~
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of the MPLS-TP Fault Management Channel Figure 1: ACH Indication of the MPLS-TP Fault Management Channel
The Fault Management Channel is 0xHH (to be assigned by IANA) The Fault Management Channel is 0xHH (to be assigned by IANA)
The ACH TLVs may include (but are not limited to) IF-ID, Global-ID, The ACH TLVs may include (but are not limited to) the IF_ID,
and ICC. Global-ID, ICC, and Authentication TLVs.
4. MPLS Fault Management Message Format 4. MPLS Fault Management Message Format
The format of the Fault Management message is shown below. The format of the Fault Management message is shown below.
0 1 2 3 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 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 |Flgs |R| Msg Type | Refresh Timer | Total TLV Len | | Vers |Flgs |R| Msg Type | Refresh Timer | Total TLV Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 50 skipping to change at page 9, line 26
-------- ----------------------------- -------- -----------------------------
0x0 Reserved 0x0 Reserved
0x1 Alarm Indication Signal (AIS) 0x1 Alarm Indication Signal (AIS)
0x2 Link Down Indication (LDI) 0x2 Link Down Indication (LDI)
0x3 Locked Report (LKR) 0x3 Locked Report (LKR)
Refresh Timer Refresh Timer
The maximum time between successive FM messages specified in The maximum time between successive FM messages specified in
seconds. The range is 1 to 65535. The value 0 is not permitted. seconds. The range is 1 to 65535. The value 0 is not permitted.
The default value is 60.
Total TLV Length Total TLV Length
The total TLV length is the total of all included TLVs. At this The total TLV length is the total of all included TLVs. At this
time no TLVs are defined. time no TLVs are defined.
5. Sending and Receiving Fault Management Messages 5. Sending and Receiving Fault Management Messages
5.1. Sending a Fault Management Message 5.1. Sending a Fault Management Message
Service disruptive conditions are indicated by sending FM messages. Service disruptive conditions are indicated by sending FM messages.
The message type is set to the value corresponding to the condition. The message type is set to the value corresponding to the condition.
The refresh timer is set to the maximum time between successive FM The refresh timer is set to the maximum time between successive FM
messages. This value SHOULD not be changed on successive FM messages. This value MUST not be changed on successive FM messages.
messages. If the optional clearing procedures are not used, then the default
value is 1. Otherwise the default value is 20.
The message is then prepended with an ACH TLV header. A Global-ID The message is then prepended with an ACH TLV header. A Global-ID
TLV or an ICC TLV MAY be included. The IF-ID TLV SHOULD be included. TLV or an ICC TLV MAY be included. The IF_ID TLV SHOULD be included.
If the R-Flag clearing procedures are to be used, the IF-ID TLV MUST If the R-Flag clearing procedures are to be used, the IF_ID TLV MUST
be included. be included.
The message is then sent. The message MUST be refreshed twice at an The message is then sent. The message MUST be refreshed twice at an
interval of one second. Further refreshes are sent according to the interval of one second. Further refreshes are sent according to the
value of the refresh timer. Refreshing continues until the condition value of the refresh timer. Refreshing continues until the condition
is cleared. is cleared.
5.2. Clearing a FM Indication 5.2. Clearing a FM Indication
Ceasing to send FM messages will clear the indication after 3.5 times Ceasing to send FM messages will clear the indication after 3.5 times
skipping to change at page 9, line 47 skipping to change at page 10, line 22
of one second. of one second.
5.3. Receiving a FM Indication 5.3. Receiving a FM Indication
When a FM message is received, a MEP examines it to ensure that that When a FM message is received, a MEP examines it to ensure that that
it is well formed. If the message type is unknown, the message is it is well formed. If the message type is unknown, the message is
ignored. If the R-Flag is zero, the condition corresponding to the ignored. If the R-Flag is zero, the condition corresponding to the
message type is entered. A timer is set to 3.5 times the refresh message type is entered. A timer is set to 3.5 times the refresh
timer. If the message is not refreshed within this period, the timer. If the message is not refreshed within this period, the
condition is cleared. A message is considered a refresh if the condition is cleared. A message is considered a refresh if the
message type and IF-ID match an existing condition and the R-Flag is message type and IF_ID match an existing condition and the R-Flag is
set to zero. set to zero.
If the R-Flag is set to one, the MEP checks to see if a condition 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 matching the message type and IF_ID exists. If it does, that
condition is cleared. Otherwise the message is ignored. condition is cleared. Otherwise the message is ignored.
6. Issues 6. Security Considerations
1. Should we include a TLV like the security TLV in BFD?
7. Security Considerations
To be added.
8. IANA Considerations Spurious fault OAM messages form a vector for a denial of service
attack. However, since these messages are carried in a control
channel, 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. However, to ensure against such an attack the Authentication
TLV MAY be included among the ACH TLVs.
To be added. 7. IANA Considerations
9. References 8. References
9.1. Normative References 8.1. Normative References
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009. September 2009.
[2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in [2] Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-04 Transport Networks", draft-ietf-mpls-tp-oam-requirements-06
(work in progress), December 2009. (work in progress), March 2010.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[5] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D. [5] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward, D.,
Ward, "Definition of ACH TLV Structure", and V. Manral, "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June 2009. draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March 2010.
8.2. Informative References
9.2. Informative References
Authors' Addresses Authors' Addresses
George Swallow (editor) George Swallow (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
United States United States
Email: swallow@cisco.com Email: swallow@cisco.com
 End of changes. 21 change blocks. 
52 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/