[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
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

   <N/A>

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]