One document matched: draft-sfv-mpls-tp-fault-00.txt
MPLS Working Group G. Swallow, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Fulignoli, Ed.
Expires: April 21, 2010 Ericsson
M. Vigoureux, Ed.
Alcatel-Lucent
October 18, 2009
MPLS Fault OAM
draft-sfv-mpls-tp-fault-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Swallow, et al. Expires April 21, 2010 [Page 1]
Internet-Draft MPLS Fault OAM October 2009
Abstract
This draft specifies a fault management indications for MPLS
Transport Profile (MPLS-TP) Label Switched Paths (LSPs). The
notification mechanism employs a generic method for a fault to be
communicated to a Maintenance End Point (MEP) to indicate a fault
condition on an MPLS LSP. A MPLS Operation, Administration, and
Maintenance (OAM) channel is defined along with messages to
communicate various types of fault conditions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4
2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 5
2.2. MPLS-TP Link Down Indication . . . . . . . . . . . . . . . 5
2.3. MPLS-TP Locked Report . . . . . . . . . . . . . . . . . . . 5
3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . . 6
4. MPLS Fault Management Message Format . . . . . . . . . . . . . 6
5. Sending and Receiving Fault Management Messages . . . . . . . . 8
5.1. Sending a Fault Indication . . . . . . . . . . . . . . . . 8
5.2. Clearing a Fault Indication . . . . . . . . . . . . . . . . 8
5.3. Receiving a Fault Indication . . . . . . . . . . . . . . . 8
6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Swallow, et al. Expires April 21, 2010 [Page 2]
Internet-Draft MPLS Fault OAM October 2009
1. Introduction
In traditional transport networks, circuits such as T1 lines are
provisioned on multiple switches. When a fault occurs on any 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 circuit.
The MPLS Transport Profile (MPLS-TP) provides mechanisms to emulate
traditional transport circuits. Therefore a Fault Management (FM)
capability must be defined for MPLS. This capability is being
defined to meet the MPLS-TP requirements as defined in RFC 5654 [1],
and the MPLS-TP Operations, Administration and Maintenance
Requirements as defined in draft-ietf-mpls-tp-oam-requirements [2].
However, this mechanism is intended to be applicable to other aspects
of MPLS as well.
Three broad classes of faults are identified.
1. Transient faults, that is conditions that are not yet known to be
fatal
2. Fatal faults, that is service disrupting conditions that are of
longer duration that the expected recovery time
3. Administrative Locking, that is disruptions that due to
administrative locking of a server layer link
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 faults from the location where
they occur to the endpoints of LSPs which are affected by those
faults. Multiple message types are used to indicate the particular
class of fault.
Corresponding to the three classes of faults listed above, three
messages are defined to communicate the type of fault. These are
known as:
Alarm Indication Signal (AIS)
Link Down Indication (LDI)
Locked Report (LKR)
1.1. Terminology
ACH: Associated Channel Header
AII: Attachment Interface Identifier
Swallow, et al. Expires April 21, 2010 [Page 3]
Internet-Draft MPLS Fault OAM October 2009
ASN: Autonomous System Number
FEC: Forwarding Equivalence Class
FM: Fault Management
LSP: Label Switched Path
LSR: Label Switching Router
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS: Multi-Protocol Label Switching
MPLS-TP: MPLS Transport Profile
OAM: Operations, Administration and Maintenance
P2MP: Point to Multi-Point
P2P: Point to Point
PSC: Protection State Coordination
PW: Pseudowire
TLV: Type Length Value
TTL: Time To Live
Requirements Language
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 RFC 2119 [3].
2. MPLS Fault Management Messages
This document defines messages to indicate three types of fault,
Alarm Indication Signal, Link Down Indication, and Locked Report.
These semantics of the individual messages are described in
subsections below.
Fault management messages are carried inband by using the Associated
Channel Header and Generalized Alert Label as defined in RFC5586 [4].
Swallow, et al. Expires April 21, 2010 [Page 4]
Internet-Draft MPLS Fault OAM October 2009
To facilitate recognition and delivery of Fault Management messages,
the Fault Management channel is identified by a unique codepoint.
When a server MEP detects a fault, fault messages are generated by
the convergence server-to-client adaptation function. The messages
are sent to the client MEPs by inserting them into the affected LSPs
in the direction opposite to the detecting MEP's peer server MEP(s).
The message is sent periodically until the fault is cleared.
2.1. MPLS-TP Alarm Indication Signal
The MPLS-TP Alarm Indication Signal (AIS) message is generated in
response to detecting defects in the server layer. The AIS message
MAY be sent as soon is the condition is detected, that is before any
determination has been made as to whether the condition is fatal.
For example an AIS message may be sent during a protection switching
event and would cease being sent if the protection switch was
successful in restoring the link.
Its primary purpose is to suppress alarms in the MPLS-TP layer
network above the level at which the defect occurs. The AIS message
MAY be used to trigger fault recovery mechanisms. It should be noted
that such use would be subject to false positives, e.g. unnecessary
protection switching events in the client layer.
2.2. MPLS-TP Link Down Indication
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
defect has been determined to be fatal. For example during a
protection switching event LDI messages are not sent. However if the
protection switch was unsuccessful in restoring the link within the
expected repair time, an LDI message MUST be sent.
The receipt of an LDI message SHOULD be treated as the equivalent of
loss of continuity at the client layer. Like AIS it also is used to
suppress alarms.
2.3. MPLS-TP Locked Report
The MPLS-TP Locked Report (LKR) message is generated when a server
layer entity has been administratively locked to communicated that
condition to inform the client layer entities of that condition.
When an MPLS-TP LSP is administratively locked it is not available to
carry client traffic. Its purpose is to suppress alarms in the
MPLS-TP layer network above the level at which the defect occurs and
to allow the clients to differentiate the lock condition from a
defect condition.
Swallow, et al. Expires April 21, 2010 [Page 5]
Internet-Draft MPLS Fault OAM October 2009
The receipt of an LKR message SHOULD be treated as the equivalent of
loss of continuity at the client layer. Like AIS it also is used to
suppress alarms.
3. MPLS Fault Management Channel
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
Management (FM) code point = 0xHH. [HH to be assigned by IANA from
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 are 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 | 0xHH Fault Management Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ zero or more ACH TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ MPLS Fault Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Fault
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,
and ICC.
4. MPLS Fault Management Message Format
The format of the Fault Management message is shown below.
Swallow, et al. Expires April 21, 2010 [Page 6]
Internet-Draft MPLS Fault OAM October 2009
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 |Flgs |R| Msg Type | Refresh Timer | Total TLV Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP OAM Message Format
Version
The Version Number is currently 1.
Flags
One flag, the R-Flag is defined. The other flags in this field
MUST be set to zero on transmission and ignored on receipt.
R-flag
The R-flag is normally set to zero. A setting of one indicates
the removal of a previously sent FM condition.
Message Type
The Message Type indicates the type of fault as listed in the
table below.
Msg Type Description
-------- -----------------------------
0x0 Reserved
0x1 Alarm Indication Signal (AIS)
0x2 Link Down Indication (LDI)
0x3 Locked Report (LKR)
Refresh Timer
The maximum time between successive FM messages specified in
seconds. The range is 1 to 65535. The value 0 is not permitted.
The default value is 60.
Total TLV Length
The total TLV length is the total of all included TLVs. At this
time no TLVs are defined.
Swallow, et al. Expires April 21, 2010 [Page 7]
Internet-Draft MPLS Fault OAM October 2009
5. Sending and Receiving Fault Management Messages
5.1. Sending a Fault Indication
Faults are indicated by sending FM messages. The message type is set
to the value corresponding to the fault. The refresh timer is set to
the maximum time between successive FM messages. This value SHOULD
not be changed on successive FM messages.
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.
If the R-Flag clearing procedures are to be used, the the IF-ID TLV
MUST be included.
The message is then sent. The message MUST be refreshed twice at an
interval of one second. Further refreshes are sent according to the
value of the refresh timer. Refreshing continues until the fault is
cleared.
5.2. Clearing a Fault Indication
Ceasing to send FM messages will clear the fault after 3.5 times the
Refresh Timer. To clear a fault 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 refreshed twice at at an interval of one
second.
5.3. Receiving a Fault Indication
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
ignored. If the R-Flag is zero, the corresponding defect state is
entered. A timer is set to 3.5 times the refresh timer. If the
message is not refreshed within this period, the fault is cleared. A
message is considered a refresh if the message type and IF-ID match
an existing fault and the R-Flag is set to zero.
If the R-Flag is set to one, the MEP checks to see if a fault
matching the op-code and IF_ID exists. If it does, that fault is
cleared. Otherwise the message is ignored.
6. Issues
1. Should we include a TLV like the security TLV in BFD?
Swallow, et al. Expires April 21, 2010 [Page 8]
Internet-Draft MPLS Fault OAM October 2009
7. Security Considerations
To be added.
8. IANA Considerations
To be added.
9. References
9.1. Normative References
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009.
[2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-03
(work in progress), August 2009.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[5] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D.
Ward, "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June 2009.
9.2. Informative References
Authors' Addresses
George Swallow (editor)
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
Email: swallow@cisco.com
Swallow, et al. Expires April 21, 2010 [Page 9]
Internet-Draft MPLS Fault OAM October 2009
Annamaria Fulignoli (editor)
Ericsson
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
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: wardd@cisco.com
Stewart Bryant
Cisco Systems, Inc.
250, Longwater
Green Park, Reading RG2 6GB
UK
Email: stbryant@cisco.com
Swallow, et al. Expires April 21, 2010 [Page 10]
Internet-Draft MPLS Fault OAM October 2009
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com
Swallow, et al. Expires April 21, 2010 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 17:25:03 |