[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-mpls-tp-csf

Network Working Group                                            J.He
Internet Draft                                       Huawei Technologies
Intended status: Standard Track
                                                                 H.Li
                                                           China Mobile


  Expires: April 2010                                   October 26, 2009




                  Indication of Client Failure in MPLS-TP
                        draft-he-mpls-tp-csf-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, 2009.

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.



He, et al.             Expires April 26, 2010                 [Page 1]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


Abstract

   This document describes a Multi-Protocol Label Switching Transport
   Profile (MPLS-TP) Operations, Administration and Maintenance (OAM)
   tool to propagate a client failure indication across an MPLS-TP
   network in case the propagation of failure status in the client layer
   is not supported.

Table of Contents


   1. Introduction................................................2
   2. Conventions used in this document...........................3
      2.1. Terminology............................................3
   3. Mechanisms of CSF...........................................4
      3.1. General................................................4
      3.2. Transmission of CSF....................................5
      3.3. Reception of CSF.......................................5
      3.4. Configuration of CSF...................................5
   4. Frame format of CSF.........................................5
   5. Consequent actions..........................................7
   6. Security Considerations.....................................7
   7. IANA Considerations.........................................7
   8. References..................................................7
      8.1. Normative References...................................7
      8.2. Informative References.................................8
   9. Acknowledgments.............................................8

1. Introduction

   In transport network OAM functionalities are important and
   fundamental to ease operational complexity, enhance network
   availability and meet service performance objectives by efficient and
   automatic detection, handling, diagnosis and appropriate reporting of
   defects and performance monitoring.

   In the case of server layer defects detected in a transport network,
   normally an AIS/FDI is generated for the downstream client signal as
   an indication to the downstream network elements that the Client
   signal is missing due to a server layer defect.

   According to [MPLS-TP Framework], MPLS-TP clients include PW and
   network layer clients. Examples of network layer clients include IP,
   MPLS and MPLS-TP.

   In cases where the client service to be carried by MPLS-TP networks
   does not provide mechanisms to propagate its failure information


He, et al.             Expires April 26, 2010                 [Page 2]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


   across MPLS-TP networks (e.g. not needed in the original application
   of the client signal, the signal was originally at the bottom of the
   layer stack and it was not expected to be transported over a server
   layer), while such an indication is needed by the downstream, it is
   necessary that MPLS-TP OAM provides such a tool to help propagate
   client failure indication to the far end on detection of a failure of
   the ingress client signal.

   This document defines a MPLS-TP OAM tool as Client Signal Fail
   indication (CSF) to propagate client failures and their clearance
   across a MPLS-TP domain.

2. Conventions used in this document

   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].

2.1. 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].

       ACH: Associated Channel Header

       AIS: Alarm Indication Signal

       CSF: Client Signal Fail indication

       FDI: Forward Defect Indication

       LSR: Label Switching Router

       MEP: Maintenance End Point

       MIP: Maintenance Intermediate Point

       OAM: Operations, Administration and Maintenance

       MPLS-TP: MPLS Transport Profile

       RDI: Remote Defect Indication






He, et al.             Expires April 26, 2010                 [Page 3]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


3. Mechanisms of CSF

3.1. General

   Client Signal Fail indication (CSF) provides a function to enable a
   MEP to propagate a client failure indication to its peer MEP across a
   MPLS-TP network in case the client service itself does not support
   propagation of its failure status.

   Packets with CSF information can be issued by a MEP, upon receiving
   failure information from its client service. Detection rules for
   client failure events are client-specific and are therefore outside
   the scope of this document.


             +---+     +---+                 +---+      +---+
             |   |     |   |-->CSF           |   |      |   |
             | A |--X--| B |-----------------| C |------| D |
             +---+     +---+                 +---+      +---+
                          |<--MPLS-TP domain-->|

                         Figure 1 Use case of CSF

   Figure 1 depicts a typical connection scenario between two client
   network elements (Node A and Node D) interconnected through MPLS-TP
   transport network. Client Node A connects to MPLS-TP Node B and
   Client Node D connects to MPLS-TP Node C. Node B and C support MPLS-
   TP MEP function.

   If a failure is detected between Node A and Node B and is taken as a
   native client failure condition, the MEP function in Node B will
   initiate CSF signal and it will be sent to Node C through MPLS-TP
   network. CSF signal will be extracted at Node C as an indication of
   client signal failure. Further, this may be mapped back into native
   client failure indication and regenerated towards client Node D.

   Node B learns the failure between A and B either by direct detection
   of signal fail (e.g. loss of signal) or by some fault indications
   between A and B (e.g. RDI, AIS/FDI).

   If the connection between Node A and B recovers, Node B may stop
   sending CSF signals to Node C (implicit failure clearance mechanism)
   or explicitly send failure clearance indication (e.g. by flags in CSF
   PDU format) to Node C to help expedite clearance of native client
   failure conditions.




He, et al.             Expires April 26, 2010                 [Page 4]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


   Accordingly, Node C will clear client failure condition when no CSF
   is received (implicit failure clearance mechanism) or upon receiving
   explicit failure clearance indication.

   Consideration of client failure clearance is to be added in the
   following part in the further version of this document.

3.2. Transmission of CSF

   Upon learning signal failure condition of its client-layer the MEP
   can immediately start transmitting periodic packets with CSF
   information. A MEP continues to transmit periodic packets with CSF
   information until the client-layer signal failure condition is
   cleared.

   The period of CSF generation is client and application specific. For
   further study.

3.3. Reception of CSF

   Upon receiving a packet with CSF information a MEP declares a client-
   layer signal fail condition and forwards this as a signal fail
   indication to its client-layer.

3.4. Configuration of CSF

   Specific configuration information required by a MEP to support CSF
   transmission is the following:

   CSF transmission period - this is application dependent. For further
   study

   PHB - identifies the per-hop behavior of packet with CSF information.

   A MIP is transparent to packets with CSF information and therefore
   does not require any information to support CSF functionality.

4. Frame format of CSF

   Figure 2 depicts the frame format of CSF. CSF PDUs are encapsulated
   using the ACH, according to [RFC 5586].








He, et al.             Expires April 26, 2010                 [Page 5]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|      MPLS-TP CSF(0xXX)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Reserved 1         |     Flags     |   Reserved 2  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 2  Frame format of CSF


                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  Res  |    Type   |   Period  |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3 Format of Flags in CSF PDU

   The first four bytes represent the G-ACH ([RFC 5586]):

       - first nibble: set to 0001b to indicate a control channel
       associated with a PW, a LSP or a Section;

       - G-ACH Version(bits 4 to 7): set to 0, as specified in [RFC 5586]

       - G-ACH Reserved (bits 8 to 15): set to 0 and ignored on
       reception, as specified in [RFC 5586];

       - G-ACH Channel Type (Bits 16 to 31): value 0xXX identifies the
       payload as CSF PDU. To be assigned by IANA.

       - CSF Reserved 1 (Bits 32 to 47): Set to 0;

       - CSF Reserved 2 (Bits 56 to 63): Set to 0;

   Figure 3 depicts the format of Flags in CSF PDU

       - Flag Reserved (Bits 48 to 49): Set to 0;

       - Type (Bits 50 to 52): Set to the following values to indicate
       CSF types

         Value   Type

         111     Client Signal Fail



He, et al.             Expires April 26, 2010                 [Page 6]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


         000     Clearance of Client Signal Fail

       - Period (Bits 53 to 55): CSF transmission period. For further
       study



5. Consequent actions

   To be added in the further version of this document.

6. Security Considerations

   To be added in a future version of the document

7. IANA Considerations

   This document requests that IANA allocates a channel type of G-ACH
   for CSF function to be used in MPLS-TP OAM.



8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5586] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal,
             R., "MPLS Generic Associated Channel", RFC5586, 2009

   [ITU-T Recommendation G.7041] "Generic framing procedure (GFP)", ITU-
             T G.7041, October 2008

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

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

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



He, et al.             Expires April 26, 2010                 [Page 7]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


8.2. Informative References

   [MPLS-TP OAM Frmk] Busi,I., Niven-Jenkins, B., "MPLS-TP OAM Framework
             and Overview", draft-ietf-mpls-tp-oam-framework-01(work in
             progress),  July 2009

   [Rosetta stone] Van Helvoort, H., Andersson, L., Sprecher, N., "A
             Thesaurus for the Terminology used in Multiprotocol Label
             Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-
             T's Transport Network Recommendations", draft-ietf-mpls-tp-
             rosetta-stone-00 (work in progress), June 2009



9. Acknowledgments

   To be added in a future version of the document

   This document was prepared using 2-Word-v2.0.template.dot.





























He, et al.             Expires April 26, 2010                 [Page 8]


Internet-Draft    Indication of Client Failure in MPLS-TP  October 2009


Authors' Addresses

   Jia He
   Huawei Technologies Co., Ltd.

   Email: hejia@huawei.com


   Han Li
   China Mobile Communications Corporation

   Email: lihan@chinamobile.com


































He, et al.             Expires April 26, 2010                 [Page 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/