MPLS Working Group R. Ram Internet Draft D. Cohn Intended status: Informational Orckit-Corrigent Expires: November 2011 M. Daikoku KDDI M. Yuxia Y. Jian ZTE Corp. A. D'Alessandro Telecom Italia May 31, 2011 SD detection and protection triggering in MPLS-TP draft-rkhd-mpls-tp-sd-03.txt Abstract This document describes guidelines for Signal Degrade (SD) fault condition detection at an arbitrary transport path (LSP or PW) and the usage of MPLS-TP fault management [3] for triggering protection switching as defined in the MPLS-TP survivability framework [2]. Status of this Memo This Internet-Draft is submitted 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 in November 2011. Ram, et al. Expires November 2011 [Page 1] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 Copyright Notice Copyright (c) 2011 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document ........................... 3 3. Signal Degrade and MPLS-TP protection switching ............. 4 4. SD detection method ......................................... 4 4.1. Guidelines for SD detection ............................ 4 4.2. Examples for SD detection methods ...................... 6 5. Transmission of link degradation fault indication ........... 6 5.1. Lower layer Bit Error transmission ..................... 7 6. Handling of link degradation fault indication ............... 7 7. Security Considerations ..................................... 7 8. IANA Considerations ......................................... 7 9. Acknowledgments ............................................. 7 10. References ................................................. 7 10.1. Normative References .................................. 7 10.2. Informative References ................................ 8 Ram, et al. Expires November 2011 [Page 2] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 1. Introduction Telecommunication carriers and network operators expect to replace aged TDM Services (e.g. legacy VPN services) provided by legacy TDM equipment by new VPN services provided by MPLS-TP equipment. From a service level agreement (SLA) point of view, service quality and availability degradation are not acceptable, even after migration to MPLS-TP equipment. In addition, from an operational point of view, comparable performance monitoring features to those provided by TDM networks are expected from MPLS-TP networks. For example, OAM maintenance points should be the same after TDM to MPLS-TP migration, as SLA revision is typically NOT feasible for telecommunication carriers and network operators. MPLS-TP transport path (i.e. LSP,PW) resiliency actions such as protection switching can be triggered by fault conditions and external manual commands. Fault conditions include Signal Failure (SF) and Signal Degrade (SD). The SD condition could be detected at an intermediate link, based on lower layer indications or other sub- layer techniques. Since the transport path protection switching is not necessarily managed by the transport entity that detects the SD condition, an indication of the link SD condition must be sent over the transport paths that traverse the affected link. This document describes guidelines for SD detection by lower layers indication, and a mechanism for relaying the degraded transport path condition to the network element handling the protection switching at the appropriate transport path level. 2. Conventions used in this document BER: Bit Error Rate LSP: Label Switched Path LSR: Label Switching Router MEP: Maintenance End Point Ram, et al. Expires November 2011 [Page 3] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 MPLS: Multi-Protocol Label Switching MPLS-TP: MPLS Transport Profile OAM: Operations, Administration and Maintenance OTN: Optical Transport Network PCS: Physical Coding Sublayer SF: Signal Failure SD: Signal Degrade 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]. 3. Signal Degrade and MPLS-TP protection switching Network survivability, as defined in [2], is the ability of a network to recover traffic delivery following failure or degradation of network resources. [5] defines an LSP protection mechanism and state machine that handles SF, SD and operator manual commands. 4. SD detection method 4.1. Guidelines for SD detection Signal degrade is a transport path condition in which the expected quality of transport service delivery is not provided. The signal degrade condition can be used by operators to detect different types of failures, especially those with slow externalization such as optical device aging (e.g. photo detector and laser diode in line amplifier, transponder or SFP), transmission medium external impairment (e.g. temperature or pressure fluctuation, fiber elongation), and time-variable optical impairments in fiber (e.g. chromatic dispersion, polarization mode dispersion). Signal degrade condition in a transport path is derived from bit error detection in the traversed links. Bit errors in a link are caused by the following phenomena: 1. Physical conditions such as bad electrical connections, low received optical power, dispersion effects. Ram, et al. Expires November 2011 [Page 4] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 2. Non-physical conditions such as network congestion, CPU overload, selective packet discard, packet processing error. The common basis for the guidelines set forth in this section is that the SD condition SHOULD reflect only physical error conditions in the traversed links, without any influence from non-physical conditions. The following conditions SHOULD be met by the signal degrade condition detection mechanism: o Method for determining signal degrade MUST NOT affect the services transmitted over the transport path (e.g. add delay or jitter to real-time traffic) o Criterion for determining signal degrade MUST be agnostic to the length of transmitted frames o Criterion for determining signal degrade MUST be agnostic to the transmission rate of transmitted frames o Criterion for determining signal degrade MUST be agnostic to the type of service carried by the transmitted frames o Criterion for determining signal degrade MUST be agnostic to the traffic class of transmitted frames o Criterion for determining signal degrade MUST be agnostic to drop- precedence marking of transmitted frames o Criterion for determining signal degrade MUST be agnostic to congestion o Criterion for determining signal degrade SHOULD be able to detect low error levels (e.g. BER of 10E-8) o Criterion for determining signal degrade SHOULD have low misdetection probability o Criterion for determining signal degrade SHOULD have low false alarm probability o Criterion for determining signal degrade SHOULD be agnostic to number of transport paths (LSPs and PWs) transported over the transmission link o Signal degrade conditions MUST be monitored by the lowest server layer or sub-layer that is not terminated between monitoring points Ram, et al. Expires November 2011 [Page 5] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 o Method for determining signal degrade SHOULD NOT require transmission of additional packets o Method for determining signal degrade SHOULD allow to localize links that contribute to signal degrade o Method for determining signal degrade MUST be able to exit signal degrade condition when error rate returns to normal condition o Method for determining signal degrade condition MUST be scalable 4.2. Examples for SD detection methods o A Server MEP [4] related to SONET or SDH sub-layers can determine SD condition based on error indication from parity information in the path overhead. o A Server MEP related to OTN sub-layer can determine SD condition based on error indications from Forward-Error-Correction functionality inherent in encapsulation. o A Server MEP related to 10GE PCS sub-layer can determine SD condition based on rate of errored 66-bit block headers. (a.k.a. symbol errors) o A Server MEP related to 1GE PCS sub-layer can determine SD condition based on rate of 10-bit code violations dispersion errors. As specified in section 4.1, these examples assume that the layer carrying the information used for SD detection is not terminated by non-MPLS-TP-LSR entities (e.g. media converter). 5. Transmission of link degradation fault indication When SD condition is detected, a link degradation fault indication [3] SHOULD be transmitted over affected transport paths, in the downstream direction from the detection point. The link degradation indication will be transmitted immediately following the detection and periodically until the SD condition is removed. The messages will be terminated and handled by the downstream client MEP. The encapsulation and mechanism defined in [3] is suitable for transmission of link degradation fault indication. It is RECOMMENDED that [3] will include this definition in future work. Ram, et al. Expires November 2011 [Page 6] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 5.1. Lower layer Bit Error transmission There are scenarios where the lower layer bit error rate in each of the links traversed by the transport path is below the SD threshold, while the accumulated end-to-end BER on the LSP is above the threshold. This is possible in lower layer technologies where errored information is dropped, so errors in one link will not be detected by LSRs downstream of this link. An example of such a situation is when an LSP is carried over multiple Ethernet links, and each link drops errored Ethernet frames. To enable SD detection in such scenarios, LSRs MAY optionally include the measured BER in the link degradation fault indication message. The client MEP may then receive multiple link degradation fault indication messages from different LSRs. When this occurs, the client MEP SHOULD compare the sum of the received BER values with the SD threshold to decide on the LSP SD condition. 6. Handling of link degradation fault indication LSR behavior upon receiving link degradation fault indication is out of the scope of this document. SD condition processing and prioritization for protection triggering is out of the scope of this document. SD clear condition processing and prioritization for protection triggering is out of the scope of this document. 7. Security Considerations To be added in a future version of the document. 8. IANA Considerations 9. Acknowledgments The editors gratefully acknowledge the contributions of Amir Halperin and Shachar Katz. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ram, et al. Expires November 2011 [Page 7] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 10.2. Informative References [2] Sprecher,N., and Farrel,A., "Multiprotocol Label Switching Transport Profile Survivability Framework", draft-ietf-mpls-tp- survive-fwk-06(work in progress), June 2010 [3] Swallow,G., Fulignoli,A., Vigoureux,M., Boutros,S., and Ward,D., "MPLS Fault Management OAM", draft-ietf-mpls-tp- fault-04 (work in progress), April 2011 [4] Busi,I. and Allan,D., "MPLS-TP OAM Framework", draft-ietf-mpls- tp-oam-framework-11 (work in progress), February 2011 [5] Bryant,S., Osborne,E., Weingarten,Y., Sprecher,N., Fulignoli,A., "MPLS-TP Linear Protection", draft-ietf-mpls-tp- linear-protection-06 (work in progress), March 2011 This document was prepared using 2-Word-v2.0.template.dot. Ram, et al. Expires November 2011 [Page 8] Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011 Authors' Addresses Rafi Ram Orckit-Corrigent 126 Yigal Alon St. Tel Aviv Israel Email: rafir@orckit.com Daniel Cohn Orckit-Corrigent 126 Yigal Alon St. Tel Aviv Israel Email: danielc@orckit.com Masahiro Daikoku KDDI 3-10-10, Iidabashi, Chiyoda-ku, Tokyo Japan Email: ms-daikoku@kddi.com Ma Yuxia ZTE Corp. China Email: ma.yuxia@zte.com.cn Yang Jian ZTE Corp. China Email: yang.jian90@zte.com.cn Alessandro D'Alessandro Telecom Italia Italy Email: alessandro.dalessandro@telecomitalia.it Contributors Amir Halperin Shachar Katz Ram, et al. Expires November 2011 [Page 9]