MPLS Working Group R. Ram Internet Draft S. Katz Intended status: Standard Track A. Halperin Orckit-Corrigent M. Daikoku KDDI June 28, 2010 Expires: January 2011 SD detection and protection triggering in MPLS-TP draft-rkhd-mpls-tp-sd-00.txt Abstract This document describes a guide lines for Signal Degrade (SD) link fault condition detection and the use of MPLS-TP fault management [5] for triggering protection switching as define in the MPLS-TP survivability framework [3]. 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 January 2011. Ram, et al. Expires January 30, 2011 [Page 1] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 Copyright Notice Copyright (c) 2010 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.......................5 5. Transmission of link degradation fault indication............6 6. Handling of link degradation fault indication................6 7. Security Considerations......................................6 8. IANA Considerations.........................................6 9. References..................................................6 9.1. Normative References....................................6 9.2. Informative References..................................6 Ram, et al. Expires January 30, 2011 [Page 2] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 1. Introduction Telecommunication carriers expect to replace aged TDM Services (e.g. legacy VPN services) provided by legacy TDM equipments to new VPN services provided by MPLS-TP Equipments. From service level agreement (SLA) point of view, any degradations of service quality and service availability even after migration of legacy TDM equipment are not allowed. And, from viewpoint of operational feasibility, the same performance monitoring granularity and unit are expected. This is because customer's requirements for network are NOT changed even after migrating from TDM to MPLS-TP. MPLS-TP LSP protection switching can be triggered by fault conditions and external manual commands. The 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 protection switching may be managed at a different transport entity, an indication about the link condition is required to be sent over each affected LSP. This document describes the guidelines for SD detection oriented by lower layers indications, and overview of mechanism from 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 FM: Fault Management LM: Loss Measurement LSP: Label Switched Path LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS: Multi-Protocol Label Switching Ram, et al. Expires January 30, 2011 [Page 3] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 MPLS-TP: MPLS Transport Profile OAM: Operations, Administration and Maintenance PSC: Protection State Coordination 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 MPLS-TP survivability framework [3] ability of a network to recover traffic delivery following degradation of network resources. draft- ietf-mpls-tp-oam-requirements [6] defines LSP protections mechanism and the state machine that prioritizes between SF, SD and operator manual commands. An LSP is considered to have SD fault, when at least one of the links it forwarded through has rate of errored bits exceeding a predetermined BER threshold. 4. SD detection method 4.1. Guidelines for SD detection The following are principals for determining link signal degrade condition: o Method for determining signal degrade MUST not disrupt the services transmitted over the link (e.g. add delay or jitter to real time traffic) o Criterion for determining signal degrade MUST be agnostic to the length of frames transmitted over the link o Criterion for determining signal degrade MUST be agnostic to the rate of frames transmitted over the link o Criterion for determining signal degrade MUST be agnostic to the type of service carried by the frames transmitted over the link Ram, et al. Expires January 30, 2011 [Page 4] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 o Criterion for determining signal degrade MUST be agnostic to the traffic class of frames transmitted over the link o Criterion for determining signal degrade MUST be agnostic to drop precedence marking of frames transmitted over the link o Criterion for determining signal degrade MUST be agnostic to link congestion level o Criterion for determining signal degrade SHOULD be able to detect low BER condition (e.g. 10E-5) o Criterion for determining signal degrade SHOULD have low miss- detection 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 LSPs or PWs forwarded over the link o Method for determining signal degrade is RECOMMENDED not to require transmission of traffic exclusively dedicated for this purpose 4.2. Examples for SD detection methods A Server MEP [7] related to SONET or SDH sub-layers can determine SD condition based on errors indication from parity information embedded in encapsulation. A Server MEP related to OTN sub-layer can determine SD condition based on errors indication from Forward-Error-Correction functionality embedded in encapsulation. A Server MEP related to 10GE PCS sub-layer can determine SD condition based on rate of errored 66bit block headers. A Server MEP related to 1GE PCS sub-layer can determine SD condition based on rate of 10bit code violations dispersion errors. These examples would work as long as the layer carrying the information used for SD detection is not terminated in between two MPLS-TP transport entities (e.g. by use of media converter). Ram, et al. Expires January 30, 2011 [Page 5] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 5. Transmission of link degradation fault indication When SD condition is detected, a link degradation fault indication [5] is transmitted over each affected LSP, in the down stream direction from the detection point. The encapsulation and mechanism for transmission of link degradation fault indication OAM message [5] are out of the scope of this document. 6. Handling of link degradation fault indication The mechanism for entering link degraded fault condition [5] is out of the scope of this document. Processing SD fault condition for protection triggering and prioritization [6] 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. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [2] Bocci,M., and Bryant,S., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-10 (Work in progress), February 2010 [3] Sprecher,N., and Farrel,a., "Multiprotocol Label Switching Transport Profile Survivability Framework", draft-ietf-mpls-tp- survive-fwk-06(work in progress), [4] Vigoureux,M., Ward,D., and Betts,M., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 06 (work in progress), March 2010 Ram, et al. Expires January 30, 2011 [Page 6] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 [5] Swallow,G., Fulignoli,A., and Vigoureux,M., "MPLS Fault Management OAM", draft-ietf-mpls-tp-fault-01 (work in progress), March 2010 [6] Bryant,S., Sprecher,N., Van Helvoort,H., Fulignoli,A., "MPLS-TP Linear Protection", draft-ietf-mpls-tp-linear-protection-01 (work in progress), March 2010 [7] Busi,I., Niven-Jenkins,B., Allan,D., "MPLS-TP OAM Framework", draft-ietf-mpls-tp-oam-framework-06 (work in progress), April 2010 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 Shachar Katz Orckit-Corrigent 126 Yigal Alon st. Tel Aviv Israel Email: shachark@orckit.com Ram, et al. Expires January 30, 2011 [Page 7] Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010 Amir Halperin Orckit-Corrigent 126 Yigal Alon st. Tel Aviv Israel Email: amirh@orckit.com Masahiro Daikoku KDDI Email: ms-daikoku@kddi.com Ram, et al. Expires January 30, 2011 [Page 8]