Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan (Ed.)
Intended status: Standards Track George Swallow
Expires: September 2009 David Ward
Stewart Bryant
Cisco Systems, Inc.
March 9, 2009
Fault Management for the MPLS Transport Profile
draft-boutros-mpls-tp-fault-01.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 September 9, 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 September 9, 2009 [Page 1]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. MPLS-TP Fault Mechanism........................................3
4. MPLS-OAM Fault Message.........................................4
4.1. In-band Message Identification............................4
4.2. Out-of-band Message Identification........................4
4.3. MPLS-TP Fault Message Format..............................5
5. Operation......................................................7
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. References....................................................10
8.1. Normative References.....................................10
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 Fault Management 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 September 9, 2009 [Page 2]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 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 Fault 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 September 9, 2009 [Page 3]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
The LSP-Ping option will be in compliance to specifications [3],[4],
and [8].
Also, the proposed mechanism requires a new message type as described
below, and uses the LSPI and address TLVs defined in [6].
4. MPLS-OAM Fault Message
4.1. In-band Message Identification
In the in-band option, under MPLS label stack of the MPLS-TP LSP, the
ACH with "MPLS-TP Fault" code point indicates that the message is
an MPLS OAM Fault message.
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|Flags | 0xHH MPLS-TP Fault Management |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Fault
The first nibble (0001b) indicates the ACH. The version and the
reserved values are both set to 0 as specified in [1]. MPLS-TP
Fault code point = 0xHH. [HH to be assigned by IANA from the PW
Associated Channel Type registry.]
4.2. Out-of-band Message Identification
[To be added]
Boutros Expires September 9, 2009 [Page 4]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
4.3. 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 | Message Type | Operation | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Cause Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV's |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP OAM Message Format
Version
The Version Number is currently 1.
Message Type
Three message types are defined as shown below.
Message Type Description
------------ -------------
0x0 Downstream Fault
0x1 Upstream Fault
0x2 Fault Response
Operation
Three operations are defined as shown below. The three operations
can appear in a Downstream or an Upstream fault message. Detailed
descriptions of the operations appear in the next section.
Boutros Expires September 9, 2009 [Page 5]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
Operation Description
--------- -------------
0x01 Fault added and local repair activated.
0x02 Fault added with no local repair.
0x03 Fault removed.
Sender's Handle
The Sender's Handle is filled in by the sender. There are no
semantics associated with this handle.
Message Length
The total length of any included TLVs.
Message ID
The Message ID is set by the sender and is incremented everytime the
sender sends a new message. The receiver MUST include the Message ID
in it needs to send a Fault response message back to the sender.
Return code
Value Meaning
----- -------
0 Fault Code
1 Success
2 Failure
Cause code for return code = Fault Code
Value Meaning
----- -------
0x0 no fault
0x1 Link failure
0x2 Node failure
0x3 Low memory
0x4 High CPU
0x5 Resource unavailable
Boutros Expires September 9, 2009 [Page 6]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
Cause code for return code = Success or Failure
Value Meaning
----- -------
1 Fail to match MPLS-TP LSP ID
2 Malformed Fault message received
3 One or more of the TLVs is/are unknown
4 Authentication failed
The fault return code is used in both Downstream fault and upstream
fault message types. The other return codes are used in the Fault
response messages.
Downstream and Upstream fault messages MUST contain a source and a
destination address TLVs defined in [6] filled with Source and
destination addresses of the two LSRs associated with the fault
segment, and LSPI TLV defined in [6] filled with the ID of the MPLS-
TP LSP. A fault message can optionally include an Authentication TLV
specified in [7].
The receiver MEP or MIP may send a Fault response to the sender MEP
or MIP using an MPLS Fault response message, the fault response MUST
contain a source address TLV defined in [6] filled with the sender
address, and LSPI TLV defined in [6] filled with the ID of the MPLS-
TP LSP.
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.
Boutros Expires September 9, 2009 [Page 7]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
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 ---
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.
Boutros Expires September 9, 2009 [Page 8]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
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. LSR-3 activates the primary
MPLS-TP LSP back, and 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.
A MEP or MIP in response to the MPLS-OAM Fault Management message may
send a Fault response message with return code = (1) success and
cause code = 0 or return code = (2) failure and a cause code as
follow:
1. if LSP ID cannot be matched, it sends a response with cause code
1 back to the sender MEP or MIP.
2. if the message is malformed, it sends a response with the cause
code 2 back to to the sender MEP or MIP.
3. if any of the TLV is not known, it sends a response with cause
code 3 back to to the sender MEP or MIP. It may also include the
unknown TLVs.
Boutros Expires September 9, 2009 [Page 9]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
4. if message authentication fails, it sends a response with the
cause code 4 back to to the sender MEP or MIP.
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
To be added.
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.
[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-02.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 September 9, 2009 [Page 10]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 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.
Boutros Expires September 9, 2009 [Page 11]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
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.
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
Boutros Expires September 9, 2009 [Page 12]
Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
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 September 9, 2009 [Page 13]