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

Versions: (draft-sfv-mpls-tp-fault) 00 01 02 03 04 05 06 07 RFC 6427

MPLS Working Group                                       G. Swallow, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                       A. Fulignoli, Ed.
Expires: July 30, 2010                                          Ericsson
                                                       M. Vigoureux, Ed.
                                                          Alcatel-Lucent

                                                        January 26, 2010


                       MPLS Fault Management OAM
                      draft-ietf-mpls-tp-fault-00

Abstract

   This draft specifies OAM messages to indicate service disruptive
   conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths
   (LSPs).  The notification mechanism employs a generic method for a
   service disruptive condition to be communicated to a Maintenance End
   Point (MEP).  An MPLS Operation, Administration, and Maintenance
   (OAM) channel is defined along with messages to communicate various
   types of service disruptive conditions.

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 July 30, 2010.






Swallow, et al.           Expires July 30, 2010                 [Page 1]

Internet-Draft          MPLS Fault Mangement OAM            January 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.




































Swallow, et al.           Expires July 30, 2010                 [Page 2]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  MPLS Fault Management Messages  . . . . . . . . . . . . . . . . 4
     2.1.  MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 5
     2.2.  MPLS-TP Link Down Indication  . . . . . . . . . . . . . . . 5
     2.3.  MPLS-TP Locked Report . . . . . . . . . . . . . . . . . . . 6
   3.  MPLS Fault Management Channel . . . . . . . . . . . . . . . . . 6
   4.  MPLS Fault Management Message Format  . . . . . . . . . . . . . 7
   5.  Sending and Receiving Fault Management Messages . . . . . . . . 8
     5.1.  Sending a Fault Management Message  . . . . . . . . . . . . 8
     5.2.  Clearing a FM Indication  . . . . . . . . . . . . . . . . . 8
     5.3.  Receiving a FM Indication . . . . . . . . . . . . . . . . . 8
   6.  Issues  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Swallow, et al.           Expires July 30, 2010                 [Page 3]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


1.  Introduction

   In traditional transport networks, circuits such as T1 lines are
   provisioned on multiple switches.  When a disruption occurs on any
   link or node along the path of such a transport circuit, alarms are
   generated which may in turn suppress alarms and/or activate a backup
   circuit.  The MPLS Transport Profile (MPLS-TP) provides mechanisms to
   emulate traditional transport circuits.  Therefore a Fault Management
   (FM) capability must be defined for MPLS.  This capability is being
   defined to meet the MPLS-TP requirements as defined in RFC 5654 [1],
   and the MPLS-TP Operations, Administration and Maintenance
   Requirements as defined in draft-ietf-mpls-tp-oam-requirements [2].
   However, this mechanism is intended to be applicable to other aspects
   of MPLS as well.

   Three broad classes service disruptive conditions are identified.

   1.  Defect: the situation in which the density of anomalies has
       reached a level where the ability to perform a required function
       has been interrupted.

   2.  Fault: the inability of a function to perform a required action.
       This does not include an inability due to preventive maintenance,
       lack of external resources, or planned actions (e.g.,
       Administrative Locking).  A fault is a persistent defect.

   3.  Lock: an administrative status in which it is expected that only
       test traffic, if any, and OAM (dedicated to the LSP) can be
       mapped on an LSP.

   This document specifies an MPLS OAM channel called an "MPLS-OAM Fault
   Management (FM)" channel.  A single message format and a set of
   procedures are defined to communicate service disruptive conditions
   from the location where they occur to the endpoints of LSPs which are
   affected by those conditions.  Multiple message types are used to
   indicate the particular condition.

   Corresponding to the three classes of service disruptive conditions
   listed above, three messages are defined to communicate the type of
   condition.  These are known as:

      Alarm Indication Signal (AIS)

      Link Down Indication (LDI)

      Locked Report (LKR)





Swallow, et al.           Expires July 30, 2010                 [Page 4]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


1.1.  Terminology

   ACH: Associated Channel Header

   AII: Attachment Interface Identifier

   ASN: Autonomous System Number

   FEC: Forwarding Equivalence Class

   FM: Fault Management

   LSP: Label Switched Path

   LSR: Label Switching Router

   MEP: Maintenance End Point

   MIP: Maintenance Intermediate Point

   MPLS: Multi-Protocol Label Switching

   MPLS-TP: MPLS Transport Profile

   OAM: Operations, Administration and Maintenance

   P2MP: Point to Multi-Point

   P2P: Point to Point

   PSC: Protection State Coordination

   PW: Pseudowire

   TLV: Type Length Value

   TTL: Time To Live

Requirements Language

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


2.  MPLS Fault Management Messages

   This document defines messages to indicate three types of service



Swallow, et al.           Expires July 30, 2010                 [Page 5]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


   disruptive conditions, Alarm Indication Signal, Link Down Indication,
   and Locked Report.  These semantics of the individual messages are
   described in subsections below.  Although only one of the conditions
   is named "Fault", we use the term "Fault Management" to generically
   mean management of all three conditions.

   Fault Management messages are carried in-band by using the Associated
   Channel Header (ACH) and Generic Associated Channel Label (GAL) as
   defined in RFC5586 [4].  To facilitate recognition and delivery of
   Fault Management messages, the Fault Management Channel is identified
   by a unique codepoint.

   When a server MEP detects a service disruptive condition, Fault
   Management messages are generated by the convergence server-to-client
   adaptation function.  The messages are sent to the client MEPs by
   inserting them into the affected LSPs in the direction opposite to
   the detecting MEP's peer server MEP(s).  The message is sent
   periodically until the condition is cleared.

2.1.  MPLS-TP Alarm Indication Signal

   The MPLS-TP Alarm Indication Signal (AIS) message is generated in
   response to detecting defects in the server layer.  The AIS message
   SHOULD be sent as soon is the condition is detected, that is before
   any determination has been made as to whether the condition is fatal.
   For example an AIS message may be sent during a protection switching
   event and would cease being sent if the protection switch was
   successful in restoring the link.

   Its primary purpose is to suppress alarms in the MPLS-TP layer
   network above the level at which the defect occurs.  The AIS message
   MAY be used to trigger recovery mechanisms.  It should be noted that
   such use would be subject to false positives, e.g. unnecessary
   protection switching events in the client layer.

2.2.  MPLS-TP Link Down Indication

   The LDI message is generated in response to detecting a fatal failure
   in the server layer.  The LDI message MUST NOT be sent until the
   defect has been determined to be fatal.  For example during a
   protection switching event LDI messages are not sent.  However if the
   protection switch was unsuccessful in restoring the link within the
   expected repair time, an LDI message MUST be sent.

   The receipt of an LDI message SHOULD be treated as the equivalent of
   loss of continuity at the client layer.  Like AIS it also is used to
   suppress alarms.




Swallow, et al.           Expires July 30, 2010                 [Page 6]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


2.3.  MPLS-TP Locked Report

   The MPLS-TP Locked Report (LKR) message is generated when a server
   layer entity has been administratively locked to communicated that
   condition to inform the client layer entities of that condition.
   When an MPLS-TP LSP is administratively locked it is not available to
   carry client traffic.  Its purpose is to suppress alarms in the
   MPLS-TP layer network above the level at which the defect occurs and
   to allow the clients to differentiate the lock condition from a
   defect condition.

   The receipt of an LKR message SHOULD be treated as the equivalent of
   loss of continuity at the client layer.  Like AIS it also is used to
   suppress alarms.


3.  MPLS Fault Management Channel

   The MPLS Fault Management channel is identified by the ACH as defined
   in RFC 5586 [4] with the Channel Type set to the MPLS Fault
   Management (FM) code point = 0xHH.  [HH to be assigned by IANA from
   the PW Associated Channel Type registry.]  The FM Channel uses ACH
   TLVs and MUST include the ACH TLV header.  The FM ACH Channel and ACH
   TLVs are shown below.


       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|Version|   Reserved    | 0xHH Fault Management Channel |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         ACH TLV Header                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               ~
      ~                      zero or more ACH TLVs                    ~
      ~                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               ~
      ~                  MPLS Fault Management Message                ~
      ~                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 1: ACH Indication of the MPLS-TP Fault Management Channel

   The Fault Management Channel is 0xHH (to be assigned by IANA)

   The ACH TLVs may include (but are not limited to) IF-ID, Global-ID,
   and ICC.



Swallow, et al.           Expires July 30, 2010                 [Page 7]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


4.  MPLS Fault Management Message Format

   The format of the Fault Management message is shown below.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  |Flgs |R| Msg Type      | Refresh Timer | Total TLV Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             TLVs                              |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: MPLS-TP OAM Message Format

   Version

      The Version Number is currently 1.

   Flags

      One flag, the R-Flag is defined.  The other flags in this field
      MUST be set to zero on transmission and ignored on receipt.

      R-flag

         The R-flag is normally set to zero.  A setting of one indicates
         the removal of a previously sent FM condition.

   Message Type

      The Message Type indicates the type of condition as listed in the
      table below.

      Msg Type           Description
      --------           -----------------------------
        0x0              Reserved
        0x1              Alarm Indication Signal (AIS)
        0x2              Link Down Indication (LDI)
        0x3              Locked Report (LKR)

   Refresh Timer

      The maximum time between successive FM messages specified in
      seconds.  The range is 1 to 65535.  The value 0 is not permitted.
      The default value is 60.




Swallow, et al.           Expires July 30, 2010                 [Page 8]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


   Total TLV Length

      The total TLV length is the total of all included TLVs.  At this
      time no TLVs are defined.


5.  Sending and Receiving Fault Management Messages

5.1.  Sending a Fault Management Message

   Service disruptive conditions are indicated by sending FM messages.
   The message type is set to the value corresponding to the condition.
   The refresh timer is set to the maximum time between successive FM
   messages.  This value SHOULD not be changed on successive FM
   messages.

   The message is then prepended with an ACH TLV header.  A Global-ID
   TLV or an ICC TLV MAY be included.  The IF-ID TLV SHOULD be included.
   If the R-Flag clearing procedures are to be used, the IF-ID TLV MUST
   be included.

   The message is then sent.  The message MUST be refreshed twice at an
   interval of one second.  Further refreshes are sent according to the
   value of the refresh timer.  Refreshing continues until the condition
   is cleared.

5.2.  Clearing a FM Indication

   Ceasing to send FM messages will clear the indication after 3.5 times
   the Refresh Timer.  To clear an indication more quickly, the
   following procedure is used.  The R-Flag of the FM message is set to
   one.  Other fields of the FM message SHOULD NOT be modified.  The
   message is sent immediately and then refreshed twice at an interval
   of one second.

5.3.  Receiving a FM Indication

   When a FM message is received, a MEP examines it to ensure that that
   it is well formed.  If the message type is unknown, the message is
   ignored.  If the R-Flag is zero, the condition corresponding to the
   message type is entered.  A timer is set to 3.5 times the refresh
   timer.  If the message is not refreshed within this period, the
   condition is cleared.  A message is considered a refresh if the
   message type and IF-ID match an existing condition and the R-Flag is
   set to zero.

   If the R-Flag is set to one, the MEP checks to see if a condition
   matching the message type and IF_ID exists.  If it does, that



Swallow, et al.           Expires July 30, 2010                 [Page 9]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


   condition is cleared.  Otherwise the message is ignored.


6.  Issues

   1.  Should we include a TLV like the security TLV in BFD?


7.  Security Considerations

   To be added.


8.  IANA Considerations

   To be added.


9.  References

9.1.  Normative References

   [1]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
        Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
        September 2009.

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

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

   [4]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
        Associated Channel", RFC 5586, June 2009.

   [5]  Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D.
        Ward, "Definition of ACH TLV Structure",
        draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June 2009.

9.2.  Informative References










Swallow, et al.           Expires July 30, 2010                [Page 10]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


Authors' Addresses

   George Swallow (editor)
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, Massachusetts  01719
   United States

   Email: swallow@cisco.com


   Annamaria Fulignoli (editor)
   Ericsson

   Email: annamaria.fulignoli@ericsson.com


   Martin Vigoureux (editor)
   Alcatel-Lucent
   Route de Villejust
   Nozay,   91620
   France

   Email: martin.vigoureux@alcatel-lucent.com


   Sami Boutros
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, California  95134
   USA

   Email: sboutros@cisco.com


   David Ward
   Juniper Networks, Inc.

   Email: dward@juniper.net












Swallow, et al.           Expires July 30, 2010                [Page 11]

Internet-Draft          MPLS Fault Mangement OAM            January 2010


   Stewart Bryant
   Cisco Systems, Inc.
   250, Longwater
   Green Park, Reading  RG2 6GB
   UK

   Email: stbryant@cisco.com


   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada

   Email: msiva@cisco.com



































Swallow, et al.           Expires July 30, 2010                [Page 12]


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