Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan
Intended status: Standards Track George Swallow
Expires: July 2009 David Ward
Stewart Bryant
Cisco Systems, Inc.
January 9, 2009
Fault Management for the MPLS Transport Profile
draft-boutros-mpls-tp-fault-00.txt
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 July 12, 2009.
Abstract
This draft specifies a fault management mechanism for MPLS
Transport Profile(MPLS-TP) Label Switched Path (LSP). The
proposed mechanism is based on a generic way of notifying a
Maintenance End Point (MEP) or Maintenance Intermediate Point
(MIP) of a fault on an MPLS-TP LSP using new type of MPLS
Operation, Administration, and Maintenance (OAM) messages.
Boutros Expires July 12, 2009 [Page 1]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. MPLS-TP Performance Monitor Mechanism..........................3
4. MPLS-OAM Fault Message.........................................4
4.1. Downstream/Upstream Fault TLV.............................5
4.2. Fault Removal TLV.........................................6
5. Operation......................................................7
6. Security Considerations........................................9
7. IANA Considerations............................................9
TBD...............................................................9
8. References.....................................................9
8.1. Normative References......................................9
8.2. Informative References...................................10
Author's Addresses...............................................11
Full Copyright Statement.........................................11
Intellectual Property Statement..................................12
1. Introduction
In traditional transport networks, circuits such as T1 lines are
provisioned on multiple switches. When a fault happens on any link or
node on 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 need to provide the same Fault
Management (FM) capability. In this document, an MPLS-TP LSP means
either an MPLS transport LSP or an MPLS Pseudowire (PW).
This document specifies an MPLS-TP FM mechanism based on a new type
of MPLS-OAM packets called "MPLS-OAM Fault Management (FM)" packets.
Upon receiving an MPLS OAM FM message:
1. A MIP/MEP activates the backup MPLS-TP LSP (if available) rather
than waiting for notification from other fault detection
mechanism such as Bidirectional Forwarding Detection (BFD).
2. A MEP sends MPLS-OAM Connection Verification (CV) Message
described in [2] to verify the new end-to-end path of the MPLS-
TP LSP.
The proposed mechanism is based on a set of new TLVs which can be
transported using one of the following two methods:
1. Using in-band MPLS OAM messages which are forwarded as MPLS
packets (non-IP based).
Boutros Expires June 12, 2009 [Page 2]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP
packets are used (IP-based). The LSP-Ping messages are sent
using the codepoint defined in [4].
Method (1) and (2) are referred to as "Non-IP option" and "LSP-Ping
option" respectively in the rest of the document.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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. Terminology
ACH: Associated Channel Header
CV: Connection Verification
FM: Fault Management
LSR: Label Switching Router
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile
NMS: Network Management System
PM: Performance Monitoring
TTL: Time To Live
TLV: Type Length Value
3. MPLS-TP Performance Monitor Mechanism
For the Non-IP option, the proposed mechanism uses a new code points
in the Associated Channel Header (ACH) described in [5].
Boutros Expires June 12, 2009 [Page 3]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
The LSP-Ping option will be in compliance to specifications [3],[4],
and [8].
Also, the proposed mechanism requires a set of new TLVs called Fault
Addition TLV, Fault Removal TLV.
The new TLVs are described below.
4. MPLS-OAM Fault Message
To support the Non-IP option, a new ACH code-point called "MPLS-OAM
Fault Management" is introduced as part of this specification. In
addition, a 32-bit field is added to carry the message ID and the
message length as 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|0 0 0 0|Flags | MPLS-TP Fault Management |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MPLS-TP OAM Message Header
First nibble = 0001b.
The value of the MPLS-TP FM code point is TBD.
The Message ID is set by the sender. The receiver MUST include the
Message ID in the response. This way, the sender can correlate a
reply with the corresponding request.
The Message Length is the total length of the message in bytes
excluding the length of the MPLS-TP OAM message header.
Flags in the ACH
0x01 local repair happened.
0x02 Fault added.
0x04 Fault removed.
Boutros Expires June 12, 2009 [Page 4]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
4.1. Downstream/Upstream Fault TLV
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 = TBD | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address block TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Connection-ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fault Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag |
+-+-+-+-+-+-+-+-+
Type = 0xHH DownStream Fault.
Type = 0xhh UpStream Fault.
Address block TLV defined in [6] includes Source and destination
addresses of the two LSRs associated with the fault segment.
Connection ID TLV defined in [6] includes Connection ID of the MPLS-
TP LSP.
Fault Code Description
---------- -------------
0x0 no fault
0x1 Link failure
0x2 Node failure
0x3 Low memory
0x4 High CPU
0x5 Resource unavailable
Boutros Expires June 12, 2009 [Page 5]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
Flag Value Meaning
---------- -------
0x0 no Local repair done
0x1 Local repair done
The receiver MEP or MIP can send a NAK response to the sender MEP
using an MPLS OAM message with a Response TLV described in [7] if it
does not support the Fault TLV.
4.2. Fault Removal TLV
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 = TBD | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address block TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Connection-ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fault Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag |
+-+-+-+-+-+-+-+-+
The fault removal TLV has a Fault Code of 0.
Fault Code Description
---------- -------------
0x0 no fault
Flag Value FM Mode
---------- -------------
0x0 no Local repair done
0x1 Local repair done
The receiver MEP or MIP MUST send a NAK response to the sender MEP
using an MPLS OAM message with a Response TLV described in [loop] if
it does not support the Fault Removal TLV.
Boutros Expires June 12, 2009 [Page 6]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
5. Operation
Scenario-1 Link Failure detected by only one node:
LSR-1 <-> LSR-2 <- X -> LSR-3 <-> LSR-4
| |
--- LSR-5 ---
There is an MPLS-TP LSP spanning LSR-1, LSR-2, LSR-3, and LSR-4. LSR-
1 and LSR-4 act as MEPs and LSR-2 and LSR-3 act as a MIP.
Furthermore, the segment between LSR-2 and LSR-3 is protected by
another MPLS-TP LSP as shown above.
Assume that there is a fault on segment between LSR-2 and LSR-3, it
was detected only by LSR-2.
The proposed scheme operates as follows:
1. Upon detecting failure, LSR-2 activates the backup MPLS-TP LSP that
protects the failure, and sends MPLS-OAM FM messages to LSR-1
(upstream) and LSR-5 (downstream via backup MPLS-TP LSP). The MPLS-
OAM FM message has an indication that local repair is active on
LSR-2.
2. MPLS-OAM FM message arrives at LSR-5 which simply forwards it to
downstream over the backup MPLS-TP LSP.
3. MPLS-OAM FM message arrives at LSR-3, and since backup MPLS-TP LSP
exists on LSR-3, the backup is activated. The MPLS-OAM FM message
is forwarded downstream.
4. Upon receiving MPLS-OAM FM messages, LSR-1 and LSR-4 send MPLS-OAM
CV message to verify the new end-to-end path.
Scenario-2 Link Failure detected by both nodes adjacent to the
failure:
LSR-1 <-> LSR-2 <- X -> LSR-3 <-> LSR-4
| |
---- LSR-5 ---
Boutros Expires June 12, 2009 [Page 7]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
This example is similar to the first one except that both LSR-2 and
LSR-3 detect the failure.
The proposed scheme operates as follows:
1. Upon detecting failure, LSR-2 activates the backup MPLS-TP LSP that
protects the failure, and sends MPLS-OAM FM messages to LSR-1
(upstream) and LSR-5 (downstream via backup MPLS-TP LSP). The MPLS-
OAM FM message has an indication that local repair is active on
LSR-2. Also, since LSR-3 also detects the failure, it also
activates the backup MPLS-TP LSP and sends an MPLS-OAM FM message
upstream and downstream. The MPLS-OAM FM message has an indication
that local repair is active on LSR-3 as well.
2. MPLS-OAM FM messages arrive at LSR-5 which simply forwards it to
upstream and downstream over the backup MPLS-TP LSP.
3. MPLS-OAM FM message arrives at LSR-3 and LSR-2. Since the failure
is already known to LSR-3 and LSR-2, the MPLS-OAM FM message is
discarded.
4. Upon receiving MPLS-OAM FM messages, LSR-1 and LSR-4 send MPLS-OAM
CV message to verify the new end-to-end path.
Proposed Solution: Fault Removal
LSR-1 <-> LSR-2 <-> LSR-3 <-> LSR-4
| |
-- LSR-5 --
Assuming LSR-2 detects fault removal proposed solution operates as
follows:
1. LSR-2 activates the primary MPLS-TP LSP back and sends MPLS-OAM FM
messages to LSR-1 (upstream) and LSR-3 (downstream via primary
MPLS-TP LSP). The MPLS-OAM FM message has an indication that the
specified fault is removed on LSR-2.
2. MPLS-OAM FM message arrives at LSR-3. Since LSR-3 activates the
primary MPLS-TP LSP back, and which forwards the MPLS-OAM FM
message downstream to LSR-4.
3. Upon receiving MPLS-OAM FM messages, LSR-1 and LSR-4 send MPLS-OAM
CV message to verify the new end-to-end path.
Boutros Expires June 12, 2009 [Page 8]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
A MEP or MIP in response to the MPLS-OAM Fault Management message
Must send a response TLV with an error code:
1. if the message is malformed, it sends a response with the error
code 2 back to LSR-1.
2. if any of the TLV is not known, it sends a response with error
code 3 back to LSR-1. It may also include the unknown TLVs.
3. if message authentication fails, it sends a response with the
error code 4 back to LSR-1.
4. if the MPLS-TP is already locked, it sends a response with error
code 5 back to A.
5. if connection-ID cannot be matched, it sends a response with
error code 14.
6. if PM packet rate cannot be handled, it sends a response with
error code 15.
Note that MPLS TTL value is set to 255 in the response message.
6. Security Considerations
The security considerations for the authentication TLV need further
study.
7. IANA Considerations
TBD
8. References
8.1. Normative References
[1] Bradner. S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
[2] S. Boutros, et. al., "Connection verification for MPLS
Transport Profile LSP", draft-boutros-mpls-tp-cv-00.txt, Work
in Progress, November, 2008.
[3] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
Boutros Expires June 12, 2009 [Page 9]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
[4] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity
Verification (VCCV): A Control Channel for Pseudowires ", RFC
5085, December 2007.
[5] M. Bocci, et. al., "MPLS Generic Associated Channel", draft-
ietf-mpls-tp-gach-gal-01.txt, work in progress, January 6,
2009.
[6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009.
[7] S. Boutros, et. al., "MPLS-TP Loopback", draft-boutros-mpls-tp-
loopback-01.txt, Work in Progress, November, 2008.
8.2. Informative References
[8] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3)", RFC5254, October 2008.
Boutros Expires June 12, 2009 [Page 10]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
Author's Addresses
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
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
UK
Email: stbryant@cisco.com
Full Copyright Statement
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
(http://trustee.ietf.org/license-info) in effect on the date of
Boutros Expires June 12, 2009 [Page 11]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
Boutros Expires June 12, 2009 [Page 12]
Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009
For the avoidance of doubt, each Contributor to the UETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boutros Expires June 12, 2009 [Page 13]