[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
MPLS Working Group                                             H. Zhang
Internet Draft                                                    J. He
Intended status: Standards Track                                 Huawei

                                                                  H. Li
                                                           China Mobile
                                                       October 26, 2009
Expires: April 2010



               SD-Triggered Protection Switching in MPLS-TP
                        draft-zhl-mpls-tp-sd-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 April 26, 2010.

Copyright Notice

   Copyright (c) 2009 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 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.




Zhang and He           Expires April 26, 2010                 [Page 1]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


Abstract

   In MPLS-TP survivability framework, a fault condition includes both
   Signal Failure (SF) and Signal Degrade (SD) that can be used to trigger
   protection switching. This document describes Signal Degrade (SD)
   detection and the consequent protection switching mechanism.

Table of Contents


   1. Introduction.................................................2
   2. Terminology..................................................3
   3. SD-Triggered Protection Switching............................4
      3.1. General Operation.......................................4
         3.1.1. General protection architecture....................4
         3.1.2. APS Protocol.......................................4
      3.2. SD-Triggered Protection Based on other Traffic (i.e. non
      normal traffic)..............................................5
         3.2.1. Detection of SD....................................5
         3.2.2. Protection Switching and APS Protocol..............6
      3.3. SD-Triggered Protection Based on Normal Traffic.........6
         3.3.1. Broadcast Bridge with special APS request priority.6
         3.3.2. Broadcast Bridge with extra protection switching
         coordination..............................................7
   4. Analysis.....................................................7
   5. Security Considerations......................................7
   6. IANA Considerations..........................................7
   7. Acknowledgments..............................................8
   8. References...................................................9
      8.1. Normative References....................................9
      8.2. Informative References..................................9
   Author's Addresses..............................................9

1. Introduction

   In packet transport network, protection switching can be triggered by
   fault conditions and external manual commands. The fault conditions
   include Signal Failure (SF) and Signal Degrade (SD). SF on a
   transport entity can be detected by fault management OAM functions;
   SD on a transport entity can be detected by performance monitoring
   OAM functions.

   The SD condition used for protection switching mostly depends on
   packet loss ratio. For some services that are sensitive to time and
   synchronization, the SD condition may depend on packet loss ratio,
   packet delay and delay variation.



Zhang and He           Expires April 26, 2010                 [Page 2]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


   In MPLS-TP OAM tools, the packet loss measurement (LM) is used to
   measure the amount of the lost service packets and compute the loss
   ratio of service packet. The packet Delay Measurement (DM) is used to
   measure the packet delay and delay variation by sending periodic DM
   packets during the diagnostic interval. The LM and DM mechanisms are
   out of scope of this document.

   The detection of SD (e.g. packet loss) must be based on service
   packets. But in some situation, there is no normal traffic on
   working/protection transport entity, which makes the detection of SD
   based on service packets impossible and causes switch flapping.

   This document describes the mechanism for SD detection and consequent
   protection switching in 1:1 and 1:n protection architecture.

2. Terminology

   The reader is assumed to be familiar with the terminology in MPLS-TP.
   The relationship between ITU-T and IETF terminologies on MPLS-TP can
   be found in [Rosetta stone].

       MPLS-TP: MPLS Transport Profile

       SF: Signal Failure

       SF-W: SF for working entity

       SF-P: SF for protection entity

       SD: Signal Degrade

       SD-W: SD for working entity

       SD-P: SD for protection entity

       APS: Automatic Protection Switching

       OAM: Operations, Administration and Maintenance

       CC/CV: Continuity Check/Connectivity Verification

       LM: Loss Measurement

       DM: Delay Measurement





Zhang and He           Expires April 26, 2010                 [Page 3]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


3. SD-Triggered Protection Switching

3.1. General Operation

3.1.1. General protection architecture

   In case of MPLS-TP 1+1 protection architecture, the normal traffic is
   permanently sent on both working and protection entities by the
   permanent bridge at the source. Therefore, the detection of SD or the
   clearing of SD on both working and protection entities can be based
   on the characteristics of the original traffic.

   In case of MPLS-TP revertive 1:1 and 1:n protection architecture:

   - If the protection switching is not active, normal traffic is
      transported together with OAM on the working entity while on the
      protection entity OAM is transported alone or together with the
      possible extra traffic.

   - If the protection switching is active, only OAM is transported on
      the working entity. Normal traffic is transported on the
      protection entity together with OAM. The extra traffic originally
      transported on protection entity is disrupted.

   In case of MPLS-TP non-revertive 1:1 and 1:n protection architecture:

   - If the protection switching is not active, normal traffic is
      transported together with OAM on the working entity while on the
      protection entity OAM is transported alone or together with the
      possible extra traffic.

   - If the protection switching is active, OAM is transported alone or
      possibly together with extra traffic on the working entity. Normal
      traffic is transported on the protection entity together with OAM
      traffic. That is, the normal traffic is switched from the working
      entity to the protection entity and the extra traffic is switched
      from the protection entity to the working entity.

   As mentioned above, in case of 1:1 and 1:n protection architecture,
   there may be no normal traffic on working/protection transport entity,
   which makes the detection of SD impossible and consequently switch
   flapping may happen.

3.1.2. APS Protocol

   In APS request types, similar to the definition of SF-W (SF for
   working entity) and SF-P (SF for protection entity), a definition of


Zhang and He           Expires April 26, 2010                 [Page 4]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


   SD-W (SD for working entity) and SD-P (SD for protection entity) is
   required to prevent flapping.

3.2. SD-Triggered Protection Based on other Traffic (i.e. non normal
   traffic)

3.2.1. Detection of SD

   In case of 1:1 and 1:n protection architecture, for the transport
   entity on which there is no normal traffic, the detection of SD can
   be based on other service packets, e.g.

   - Extra traffic

   The extra traffic can be used instead of normal traffic in packet
   loss measurement. That is, the performance monitoring OAM packets (LM)
   will count the number of extra service packets and the loss
   measurement is based on extra service, which will be used as the
   input of SD condition of the transport entity that lacks normal
   service.

   - OAM packets for Test

   The Test OAM packets can be used to simulate the characteristics of
   the normal traffic and replace the normal service. With the
   performance monitoring OAM packets (LM) the SD condition of the
   transport entity can be detected.

   - OAM packets for CC/CV

   The CC/CV OAM packets can be used instead of normal service in packet
   loss measurement. That is, the performance monitoring OAM packets (LM)
   will count CC/CV packets and the loss measurement is based on CC/CV
   packets, which will be used as the input of SD condition of the
   transport entity where there is no normal service.

   The above-mentioned SD-triggered protection switching mechanism based
   on other traffic is general and flexible without constraint on the
   bridge type by using the extra traffic, OAM packets (test or CC/CV).

   However, the characteristics of the extra traffic are usually not the
   same as that of the normal traffic so that the performance
   measurement is not exactly reflecting the condition of real service.
   OAM packets for CC/CV are sent in fixed transmission period (3.3ms,
   10ms, 1s, etc.) which as well doesn't reflect the condition of real
   services. It is applicable in places without strict requirement for
   SD measurement.


Zhang and He           Expires April 26, 2010                 [Page 5]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


   The performance measurement by Test OAM packets is accurate. But the
   usage of test packets on protection entity defeats the objective of
   the 1:1 and 1:n architectures, which is to have the protection entity
   bandwidth available for best effort traffic during the time there is
   no fault or degradation of the working transport entity. The test
   packets consume now this bandwidth. For the case of the 1:1
   protection, this makes the bandwidth usage of this 1:1 architecture
   similar to the bandwidth usage of the 1+1 architecture.

3.2.2. Protection Switching and APS Protocol

   For the SD-triggered protection based on other traffic, if a
   broadcast bridge is used, the other traffic used to detect SD is
   required on the protection transport entity only.

   The priority of SD-P and SD-W shall be fixed as SD-P > SD-W similar
   to SF-P > SF-W. Therefore, a protection switching based on SD
   detection shall not be initiated if there exists also an SD condition
   on the protection transport entity. The priority of SD-P and SD-W can
   be flexible as well based on the actual degraded degree of signal.
   Therefore, traffic is sent on the transport entity with better SD
   condition if both SD-W and SD-P exist.

3.3. SD-Triggered Protection Based on Normal Traffic

   In case of 1:1 and 1:n protection architecture, a broadcast bridge
   can be applied to assist SD detection in SD-triggered protection.

3.3.1. Broadcast Bridge with special APS request priority

   In the normal state, the normal traffic is sent only on the working
   transport entity and only the SD condition of the working transport
   entity can be evaluated.

   When SD is detected on the working transport entity, sink end sends
   SD-W indication to the source end and the selector at the sink end
   switches to the protection transport entity. The broadcast bridge at
   the source end will then send the normal traffic on both working and
   protection transport entities and the performance of both working and
   protection transport entities can be monitored.

   If SD is detected on protection transport entity as well, i.e. SD-W
   and SD-P exist simultaneously, normal traffic is selected at the sink
   still from the protection transport entity to avoid flapping between
   protection and working states.




Zhang and He           Expires April 26, 2010                 [Page 6]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


   In this case the priority of SD-W and SD-P in the APS protocol is
   fixed as SD-W > SD-P to avoid flapping of between protection and
   working states.

3.3.2. Broadcast Bridge with extra protection switching coordination

   The SD-W based protection switch action described in section 3.3.1 is
   performed under the assumption that a SD condition on a transport
   entity is a rare condition, and it is thus unlikely that SD on
   protection will co-exist with SD on working. When such assumption is
   not considered to be reasonable, the operation of the selector may be
   modified as described hereafter.

   When the sink end detects an SD condition, it does not switch to the
   protection entity immediately. Instead, the broadcast bridge at the
   source end will send the normal traffic on both working and
   protection transport entity after receiving SD-W indication sent by
   the sink end. Then sink end is able to detect the SD condition of
   working and protection transport entity.

   If SD is detected on the protection transport entity as well, the
   normal traffic is sent to both working and protection transport
   entities and is selected from the working transport entity; if no SD
   is detected on the protection transport entity the normal traffic is
   selected from the protection entity.

   SD-triggered protection switching based normal traffic is simple and
   efficient by applying a specific broadcast bridge but with a minor
   modification to the priority order of APS request (i.e. SD-W > SD-P)
   or to the operation order.

4. Analysis

   In section 3.2 and 3.3, the different mechanisms are described. They
   may be suitable in differenct application scenarios with different
   requirements for simplicity, accuracy, flexibility.

   [More analysis may be needed in a future version of this draft]

5. Security Considerations

   To be added in a future version of the document.

6. IANA Considerations

   No new IANA considerations.



Zhang and He           Expires April 26, 2010                 [Page 7]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


7. Acknowledgments

   To be added in a future version of the document.













































Zhang and He           Expires April 26, 2010                 [Page 8]


Internet-Draft       draft-zhl-mpls-tp-sd-01.txt          October 2009


8. References

8.1. Normative References

   [MPLS-TP Framework] Bocci,M., and Bryant,S., "A Framework for MPLS in
             Transport Networks", draft-ietf-mpls-tp-framework-06 (Work
             in progress), October 2009

   [RFC5654] Niven-Jenkins,B., Brungard,D., and Betts,M., "Requirements
             of an MPLS Transport Profile", RFC5654, September 2009

   [ITU-T Recommendation G.808.1] "Generic protection switching - Linear
             trail and subnetwork protection", ITU-T G.808.1 (03/2006)

   [MPLS-TP OAM Requirements] Vigoureux,M., Ward,D., and Betts,M.,
             "Requirements for OAM in MPLS Transport Networks", draft-
             ietf-mpls-tp-oam-requirements-03(work in progress), August
             2009

8.2. Informative References

   [MPLS-TP Survive Frmk] Sprecher,N., and Farrel,a., "Multiprotocol
             Label Switching Transport Profile Survivability Framework",
             draft-ietf-mpls-tp-survive-fwk-00(work in progress), April
             2009

Author's Addresses

   Haiyan Zhang
   Huawei Technologies Co., Ltd.

   Phone: +86-755-28972333
   Email: zhanghaiyan@huawei.com


   Jia He
   Huawei Technologies Co., Ltd.

   Phone: +86-755-28972333
   Email: hejia@huawei.com


   Han Li
   China Mobile Communications Corporation

   Email: lihan@chinamobile.com



Zhang and He           Expires April 26, 2010                 [Page 9]