MPLS Working Group R. Ram Internet Draft D. Cohn Intended status: Informational Orckit-Corrigent Expires: September 13, 2011 M. Daikoku KDDI M. Yuxia Yang Jian ZTE Corp. L. Levrau Alcatel-Lucent March 13, 2011 Link impairment and protection triggering in MPLS-TP draft-rkhd-mpls-tp-sd-02.txt Abstract This document describes guidelines for link impairment fault condition detection and the use 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 on September 13, 2011. Ram, et al. Expires September 13, 2011 [Page 1] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 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. SF/SD defects and MPLS-TP protection switching............... 4 4. Link impairment detection method ............................ 4 4.1. Guidelines for detection................................ 4 4.2. Examples for detection methods ......................... 5 5. Transmission of link degradation fault indication ........... 6 6. Handling of link failure and degradation fault indication ... 6 7. Security Considerations...................................... 6 8. IANA Considerations ......................................... 6 9. Acknowledgments ............................................. 6 10. References ................................................. 6 10.1. Normative References................................... 6 10.2. Informative References................................. 7 Ram, et al. Expires September 13, 2011 [Page 2] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 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, the same performance monitoring granularity provided by TDM networks is expected from MPLS-TP networks. For example, OAM maintenance points should remain in the same locations after TDM to MPLS-TP migration, as SLA revision is typically NOT feasible for telecommunication carriers and network operators. MPLS-TP LSP protection switching can be triggered by fault conditions and external manual commands. Fault conditions include Signal Failure (SF) and Signal Degrade (SD). Both conditions can be detected at an intermediate link based on lower layer indications or other sub-layer techniques. Since the protection switching is not necessarily managed by the transport entity that detects the condition, an impaired link condition indication must be sent over affected LSPs. This document describes guidelines for BER-related SF and SD detection by lower layers indication, and a mechanism for relaying the degraded LSP condition to the network element handling the LSP protection switching. 2. Conventions used in this document BER: Bits Error Rate LSP: Label Switched Path LSR: Label Switching Router MEP: Maintenance End Point MPLS: Multi-Protocol Label Switching Ram, et al. Expires September 13, 2011 [Page 3] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011 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. SF/SD defects 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. In this document, SF refers exclusively to defects derived from link impairment (i.e. high BER), as opposed to defects detected through OAM mechanisms (e.g. LOC condition) which are outside the scope of this document. 4. Link impairment detection method 4.1. Guidelines for detection The common basis for the guidelines set forth in this section is that SF and SD conditions SHOULD reflect only BER conditions in the LSP lower layers, without any influence from non-BER-related conditions such as network congestion, CPU overload, selective packet discard, etc. The following conditions SHOULD be met by the SF and SD condition detection mechanism: o Method for determining SF and SD MUST not disrupt the services transmitted over the link (e.g. add delay or jitter to real-time traffic) o Criterion for determining SF and SD MUST be agnostic to the length of frames transmitted over the link o Criterion for determining SF and SD MUST be agnostic to the transmission rate of frames transmitted over the link Ram, et al. Expires September 13, 2011 [Page 4] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011 o Criterion for determining SF and SD MUST be agnostic to the type of service carried by the frames transmitted over the link o Criterion for determining SF and SD MUST be agnostic to the traffic class of frames transmitted over the link o Criterion for determining SF and SD MUST be agnostic to drop- precedence marking of frames transmitted over the link o Criterion for determining SF and SD MUST be agnostic to link congestion level o Criterion for determining SD SHOULD be able to detect low BER levels (e.g. 10E-8) o Criterion for determining SF and SD SHOULD have low misdetection probability o Criterion for determining SF and SD SHOULD have low false alarm probability o Criterion for determining SF and SD SHOULD be agnostic to number of LSPs or PWs forwarded over the link o SF and SD conditions MUST be monitored by the lowest server layer or sub-layer that is not terminated between monitoring points o It is RECOMMENDED that the method for determining SF and SD does not require transmission of additional traffic Detection of SF and SD conditions is typically based on the same information source. SF and SD conditions have each a different associated error rate threshold. 4.2. Examples for detection methods o A Server MEP [4] related to SONET or SDH sub-layers can determine SF and SD conditions based on error indication from parity information in the path overhead. o A Server MEP related to OTN sub-layer can determine SF and SD conditions based on error indications from Forward-Error-Correction functionality inherent in encapsulation. o A Server MEP related to 10GE PCS sub-layer can determine SF and SD conditions based on rate of errored 66-bit block headers. o A Server MEP related to 1GE PCS sub-layer can determine SF and SD conditions based on rate of 10-bit code violations dispersion errors. Ram, et al. Expires September 13, 2011 [Page 5] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011 As specified in section 4.1, these examples assume that the layer carrying the information used for SF and SD detection is not terminated by non-MPLS-TP-LSR entities (e.g. media converter). 5. Transmission of link impairment fault indication When SF condition is detected, a link failure fault indication SHOULD be transmitted over affected LSPs, in the downstream direction from the detection point. The link failure indication will be transmitted immediately following the detection and periodically until the SF condition is removed. The messages will be terminated and handled by the downstream MEP. When SD condition is detected, a link degradation fault indication SHOULD be transmitted over affected LSPs, 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 MEP. The encapsulation and mechanism defined in [3] is suitable for transmission of link failure and degradation fault indications. It is RECOMMENDED that [3] will include these definitions in future work. 6. Handling of link failure and degradation fault indications LSR behavior upon receiving link failure and degradation fault indications is out of the scope of this document. SF and SD condition processing and prioritization for protection triggering is defined in [5]. 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 September 13, 2011 [Page 6] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 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-03 (work in progress), October 2010 [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-04 (work in progress), January 2011 This document was prepared using 2-Word-v2.0.template.dot. 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 Corporation 3-11-11 Iidabashi, Chiyodaku 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 Lieven Levrau Alcatel-Lucent Email: llevrau@alcatel-lucent.com Contributors Amir Halperin Ram, et al. Expires September 13, 2011 [Page 7] Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011 Shachar Katz Ram, et al. Expires September 13, 2011 [Page 8]