MPLS Working Group S. Boutros
Internet-Draft S. Sivabalan
Intended status: Standards Track G. Swallow
Expires: January 14, 2010 D. Ward
S. Bryant
Cisco Systems, Inc.
July 13, 2009
MPLS-TP Fault OAM
draft-boutros-mpls-tp-fault-02
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 January 14, 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.
Boutros, et al. Expires January 14, 2010 [Page 1]
Internet-Draft MPLS-TP Fault OAM July 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 Maintenance End
Point (MEP) or Maintenance Intermediate Point (MIP) to indicate a
fault on an MPLS-TP LSP. A new MPLS Operation, Administration, and
Maintenance (OAM) message is defined.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MPLS-TP Fault Indications . . . . . . . . . . . . . . . . . . . 4
2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 4
2.2. MPLS-TP Reverse Defect Indication . . . . . . . . . . . . . 5
2.3. MPLS-TP Locked Indication . . . . . . . . . . . . . . . . . 5
3. MPLS-OAM Fault Message . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS Fault Management Channel . . . . . . . . . . . . . . . 5
3.2. MPLS-TP Fault Message Format . . . . . . . . . . . . . . . 6
4. Sending and Receiving Fault Indications . . . . . . . . . . . . 7
4.1. Sending a Fault Indication . . . . . . . . . . . . . . . . 7
4.2. Clearing a Fault Indication . . . . . . . . . . . . . . . . 8
4.3. Receiving a Fault Indication . . . . . . . . . . . . . . . 8
5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Boutros, et al. Expires January 14, 2010 [Page 2]
Internet-Draft MPLS-TP Fault OAM July 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 activate a backup circuit. MPLS-TP LSP emulating
traditional transport circuits needs to provide the same Fault
Management (FM) capability. In this document, an MPLS-TP LSP means
either an MPLS transport LSP.
This document specifies an MPLS-TP Fault Management mechanism based
on a new type of MPLS OAM message called an "MPLS-OAM Fault
Management (FM)" message. This message is used to convey the
following:
Alarm Indication Signal (AIS)
Reverse Defect Indication (RDI)
Locked Indication (LCK)
The AIS message is generated in response to detecting defects in the
server layer. 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 also be used to trigger fault recovery
mechanisms.
The RDI message is generated by a MEP experiencing a defect to inform
its peer MEP(s) of the condition.
The LCK 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.
1.1. Terminology
ACH: Associated Channel Header
AII: Attachment Interface Identifier
ASN: Autonomous System Number
FEC: Forwarding Equivalence Class
Boutros, et al. Expires January 14, 2010 [Page 3]
Internet-Draft MPLS-TP Fault OAM July 2009
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 [1].
2. MPLS-TP Fault Indications
This document defines messages to indicate three kinds of fault,
Alarm Indication Signal, Reverse Defect Indication, and Lock
Indication. These are described in below.
2.1. MPLS-TP Alarm Indication Signal
The AIS message is generated in response to detecting defects in the
server layer. Its primary purpose is to suppress alarms in the
MPLS-TP layer networks above the level at which the defect occurs.
The AIS message MAY also be used to trigger fault recovery
mechanisms.
Boutros, et al. Expires January 14, 2010 [Page 4]
Internet-Draft MPLS-TP Fault OAM July 2009
When a server MEP detects a fault, AIS messages are generated by the
convergence server-to-client adaptation function. The messages are
sent to the client MEPs in the direction opposite the peer server
MEP(s). This message is sent periodically until the fault is
cleared.
2.2. MPLS-TP Reverse Defect Indication
Reverse Defect Indication is used to communicate defects from the MEP
which has detected the fault to its peer MEP(s).
The messages are sent in-band to the client MEPs in the direction
opposite the peer server MEP(s). This message is sent periodically
until the fault is cleared.
2.3. MPLS-TP Locked Indication
Locked Indication is used to communicate that the facility associated
with the MEP has been administratively locked and is not available
for client traffic. That is, the facility has been taken out-of-
service. This allows a MEP receiving a LCK message to differentiate
between a defect condition and an administrative locking action.
When a server MEP is locked, LCK messages are generated by the
convergence server-to-client adaptation function. The messages are
sent to the client MEPs in the direction opposite the peer server
MEP(s). This message is sent periodically until the lock is cleared.
3. MPLS-OAM Fault Message
A single fault message is used to carry fault indications. The
particular fault is identified by an op-code. The message is in turn
carried in a Fault Management channel identified by the Associated
Channel Header. On this channel ACH TLVs are used to carry any
necessary identifiers. In particular it is used to carry the sending
MEP-ID.
3.1. MPLS Fault Management Channel
Fault Management messages are carried in the ACH as defined in RFC
5586 [2]. MPLS-TP Fault Management (FM) code point = 0xHH. [HH to
be assigned by IANA from the PW Associated Channel Type registry.]
Messages sent on the MPLS-TP FM Channel MUST be preceded by an ACH
TLV Header and MUST include the Sending-MEP TLV as defined in
draft-ietf-mpls-ach-tlv. [3] The FM ACH Channel and ACH TLVs are
shown below.
Boutros, et al. Expires January 14, 2010 [Page 5]
Internet-Draft MPLS-TP Fault OAM July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0xHH MPLS-TP Fault Management |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ zero or more ACH TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ MPLS-TP Fault Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Fault
3.2. MPLS-TP Fault Message Format
The format of an MPLS-TP Fault 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OpCode | Cause Code | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | Total TLV Length | TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Boutros, et al. Expires January 14, 2010 [Page 6]
Internet-Draft MPLS-TP Fault OAM July 2009
The R-flag is normally set to zero. A setting on one inticates
the removal of a previously sent FM condition.
Op Code
The Op Code indicates the type of fault as listed in the table
below.
Op Code Description
------- -------------
0x0 Reserved
0x1 Alarm Indication Signal (AIS)
0x2 Remote Defect Indication (RDI)
0x3 Locked indication (LCK)
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.
Cause Code
The cause of the fault encoded as follows
Cause Code Meaning
---------- -------
0x0 No indication
0x1 Link failure
0x2 Node failure
0x3 Low memory
0x4 High CPU
0x5 Resource unavailable
4. Sending and Receiving Fault Indications
4.1. Sending a Fault Indication
Faults are indicated by sending FM messages. The op code is set to
the value corresponding to the fault. A cause may be communicated by
setting the corresponding cause code. If no cause is to be
Boutros, et al. Expires January 14, 2010 [Page 7]
Internet-Draft MPLS-TP Fault OAM July 2009
communicated this field MUST be set to zero. The R-flag MUST be set
to zero. 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 and the Sending-
MEP TLV. For AIS messages (which are sent from the convergence
server-to-client adaptation function) ID of the server MEP is used.
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.
4.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.
4.3. Receiving a Fault Indication
When a FM Indication is received, a MEP examines it to ensure that
that it is well formed. If the op code is unknown, the message is
ignored. If the cause code is unknown it is interpreted as "No
Indication". If the R-FLag is zero, the Sending-MEP_ID noted and 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 op code and Sending-MEP_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 Sending-MEP_ID exists. If it does, that
fault is cleared. Otherwise the message is ignored.
5. Issues
1. Are cause codes useful?
2. Should we include a TLV like the security TLV in BFD?
Boutros, et al. Expires January 14, 2010 [Page 8]
Internet-Draft MPLS-TP Fault OAM July 2009
6. Security Considerations
To be added.
7. IANA Considerations
To be added.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[3] 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.
[4] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-09
(work in progress), June 2009.
[5] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-02
(work in progress), June 2009.
8.2. Informative References
Authors' Addresses
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Boutros, et al. Expires January 14, 2010 [Page 9]
Internet-Draft MPLS-TP Fault OAM July 2009
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
Email: swallow@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
Boutros, et al. Expires January 14, 2010 [Page 10]