


MPLS Working Group                                       G. Swallow, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                       A. Fulignoli, Ed.
Expires: March 5, 2012                                          Ericsson
                                                       M. Vigoureux, Ed.
                                                          Alcatel-Lucent
                                                              S. Boutros
                                                     Cisco Systems, Inc.
                                                                 D. Ward
                                                  Juniper Networks, Inc.
                                                       September 2, 2011


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

Abstract

   This document specifies Operations, Administration, and Maintenance
   messages to indicate service disruptive conditions for MPLS based
   Transport Network Label Switched Paths.  The notification mechanism
   employs a generic method for a service disruptive condition to be
   communicated to a Maintenance Entity Group End Point.  This document
   defines an MPLS OAM channel, along with messages to communicate
   various types of service disruptive conditions.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 5, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Swallow, et al.           Expires March 5, 2012                 [Page 1]

Internet-Draft          MPLS Fault Management OAM         September 2011


   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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  MPLS Fault Management Messages . . . . . . . . . . . . . . . .  5
     2.1.  MPLS Alarm Indication Signal . . . . . . . . . . . . . . .  5
       2.1.1.  MPLS Link Down Indication  . . . . . . . . . . . . . .  6
     2.2.  MPLS Lock Report . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Propagation of MPLS Fault Messages . . . . . . . . . . . .  7
   3.  MPLS Fault Management Channel  . . . . . . . . . . . . . . . .  7
   4.  MPLS Fault Management Message Format . . . . . . . . . . . . .  7
     4.1.  Fault Management Message TLVs  . . . . . . . . . . . . . .  9
       4.1.1.  Interface Identifier TLV . . . . . . . . . . . . . . . 10
       4.1.2.  Global Identifier  . . . . . . . . . . . . . . . . . . 10
   5.  Sending and Receiving Fault Management Messages  . . . . . . . 11
     5.1.  Sending a Fault Management Message . . . . . . . . . . . . 11
     5.2.  Clearing a FM Indication . . . . . . . . . . . . . . . . . 11
     5.3.  Receiving a FM Indication  . . . . . . . . . . . . . . . . 11
   6.  Minimum Implementation Requirements  . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Pseudowire Associated Channel Type . . . . . . . . . . . . 13
     8.2.  MPLS Fault OAM Message Type Registry . . . . . . . . . . . 14
     8.3.  MPLS Fault OAM Flag Registry . . . . . . . . . . . . . . . 14
     8.4.  MPLS Fault OAM TLV Registry  . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16










Swallow, et al.           Expires March 5, 2012                 [Page 2]

Internet-Draft          MPLS Fault Management OAM         September 2011


1.  Introduction

   Proper operation of a transport network depends on the ability to
   quickly identify faults and focus attention on the root cause of the
   disruption.  This document defines MPLS Fault Management Operations,
   Administration, and Maintenance (OAM) messages.  When a fault occurs
   in a server (sub-)layer, Fault Management OAM messages are sent to
   clients of that server so that alarms, which otherwise would be
   generated by the subsequent disruption of the clients, may be
   suppressed.  This prevents a storm of alarms and allows operations to
   focus on the actual faulty elements of the network.

   In traditional transport networks, circuits such as T1 lines are
   typically provisioned on multiple switches.  When an event that
   causes disruption occurs on any link or node along the path of such a
   transport circuit, OAM indications are generated.  When received,
   these indications may be used to suppress alarms and/or activate a
   backup circuit.  The MPLS based Transport Network provides mechanisms
   equivalent to traditional transport circuits.  Therefore a Fault
   Management (FM) capability must be defined for MPLS.  This document
   defines FM capabilities to meet the MPLS-TP requirements as described
   in RFC 5654 [1], and the MPLS-TP Operations, Administration, and
   Maintenance Requirements as described in RFC 5860 [2].  These
   mechanisms are intended to be applicable to other aspects of MPLS as
   well.  However, applicability to other types of LSPs is beyond the
   scope of this document.

   Two broad classes of service disruptive conditions are identified.

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

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

   Within this document a further term is defined, server-(sub-)layer-
   failure, or more briefly server-failure.  A server-failure occurs
   when a fault condition or conditions have persisted long enough to
   consider the required service function to have terminated.  In the
   case of a protected server, this would mean that both the working and
   and any protection facilities have suffered faults of the required
   duration.

   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



Swallow, et al.           Expires March 5, 2012                 [Page 3]

Internet-Draft          MPLS Fault Management OAM         September 2011


   from the location where they occur to the endpoints of LSPs which are
   affected by those conditions.  Multiple message types and flags are
   used to indicate and qualify the particular condition.

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

      Alarm Indication Signal (AIS)

      Lock Report (LKR)

1.1.  Terminology

   ACH: Associated Channel Header

   ACh: Associated Channel

   CC: Continuity Check

   FM: Fault Management

   GAL: Generic Associated Channel Label

   LOC: Loss of Continuity

   LSP: Label Switched Path

   MEP: Maintenance Entity Group End Point

   MPLS: Multi-Protocol Label Switching

   MPLS-TP: MPLS Transport Profile

   MS-PW: Multi-Segment Pseudowire

   OAM: Operations, Administration, and Maintenance

   PHP: Penultimate Hop Pop

   PW: Pseudowire

   TLV: Type, Length, Value

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Swallow, et al.           Expires March 5, 2012                 [Page 4]

Internet-Draft          MPLS Fault Management OAM         September 2011


   document are to be interpreted as described in RFC 2119 [3].


2.  MPLS Fault Management Messages

   This document defines two messages to indicate service disruptive
   conditions, Alarm Indication Signal, and Lock Report.  The semantics
   of the individual messages are described in subsections below.  Fault
   OAM messages are applicable to LSPs used in the MPLS Transport
   Profile.  Such LSPs are bound to specific server layers based upon
   static configuration or signaling in a client/server relationship.

   Fault Management messages are carried in-band of the client LSP or
   MS-PW by using the Associated Channel Header (ACH).  For LSPs other
   than PWs, the ACH is identified by the 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 Associated Channel (ACh) codepoint.

   Fault OAM messages are generated by intermediate nodes where a client
   LSP is switched.  When a server (sub-)layer, (e.g. a link or
   bidirectional LSP) used by the client LSP fails, the intermediate
   node sends Fault Management messages downstream towards the endpoint
   of the LSP.  The messages are sent to the client MEPs by inserting
   them into the affected client LSPs in the direction downstream of the
   fault location.  These messages are sent periodically until the
   condition is cleared.

2.1.  MPLS Alarm Indication Signal

   The MPLS Alarm Indication Signal (AIS) message is generated in
   response to detecting faults in the server (sub-)layer.  The AIS
   message SHOULD be sent as soon as the condition is detected, but MAY
   be delayed owing to processing in an implementation, and MAY be
   suppressed if protection is achieved very rapidly.  For example, an
   AIS message may be sent during a protection switching event and would
   cease being sent (or cease being forwarded by the protection switch
   selector) if the protection switch was successful in restoring the
   link.  However, an implementation may instead wait to see if the
   protection switch is successful prior to sending any AIS messages.

   The primary purpose of the AIS message is to suppress alarms in the
   layer network above the level at which the fault occurs.  When the
   Link Down Indication is set, the AIS message MAY be used to trigger
   recovery mechanisms.






Swallow, et al.           Expires March 5, 2012                 [Page 5]

Internet-Draft          MPLS Fault Management OAM         September 2011


2.1.1.  MPLS Link Down Indication

   The Link Down Indication (LDI) is communicated by setting the L-flag
   to 1.  A node sets the L-flag in the AIS message in response to
   detecting a failure in the server layer.  A node MUST NOT set the
   L-flag until the fault has been determined to be a server-failure.  A
   node MUST set the L-flag if the fault has been determined to be a
   server-failure.  For example during a server layer protection
   switching event, a node MUST NOT set the L-flag.  However if the
   protection switch was unsuccessful in restoring the link within the
   expected repair time, the node MUST set the L-flag.

   The setting of the L-flag can be predetermined based on the
   protection state.  For example, if a server layer is protected and
   both the working and protection paths are available, the node should
   send AIS with the L-flag clear upon detecting a fault condition.  If
   the server layer is unprotected or the server layer is protected but
   only the active path is available, the node should send AIS with the
   L-flag set upon detecting a loss of continuity (LOC) condition.  Note
   again that the L-flag is not set until a server-failure has been
   declared.  Thus if there is any hold-off timer associated with the
   LOC, then the L-flag is not set until that timer has expired.

   The receipt of an AIS message with the L-flag set MAY be treated as
   the equivalent of LOC at the client layer.  The choice of treatment
   is related to the rate at which the Continuity Check (CC) function is
   running.  In a normal transport environment, CC is run at a high rate
   in order to detect a failure within 10s of milliseconds.  In such an
   environment, the L-flag MAY be ignored and the AIS message is used
   solely for alarm suppression.

   In more general MPLS environments the CC function may be running at a
   much slower rate.  In this environment, the Link Down Indication
   enables faster switch-over upon a failure occurring along the client
   LSP.

2.2.  MPLS Lock Report

   The MPLS Lock Report (LKR) message is generated when a server
   (sub-)layer entity has been administratively locked.  Its purpose is
   to communicate the locked condition to the client layer entities.
   When a server layer is administratively locked it is not available to
   carry client traffic.  The purpose of the LKR message is to suppress
   alarms in the layer network above the level at which the
   administrative lock occurs and to allow the clients to differentiate
   the lock condition from a fault condition.  While the primary purpose
   of the LKR message is to suppress alarms, similar to AIS with the LDI
   (L-flag set), the receipt of an LKR message MAY be treated as the



Swallow, et al.           Expires March 5, 2012                 [Page 6]

Internet-Draft          MPLS Fault Management OAM         September 2011


   equivalent of loss of continuity at the client layer.

2.3.  Propagation of MPLS Fault Messages

   MPLS-TP allows for a hierarchy of LSPs.  When the client MEP of an
   LSP which is also acting as a server layer receives FM indications,
   the following rules apply.  If the CC function is disabled for the
   server LSP, a node SHOULD generate AIS messages toward any clients
   when either the AIS or LKR indication is raised.  Note that the
   L-flag is not automatically propagated.  The rules of Section 2.1.1
   apply.  In particular, the L-flag is not set until a server-failure
   has been declared.


3.  MPLS Fault Management Channel

   The MPLS Fault Management channel is identified by the ACH as defined
   in RFC 5586 [4] with the Associated Channel Type set to the MPLS
   Fault Management (FM) code point = 0xHHHH.  [HHHH to be assigned by
   IANA from the PW Associated Channel Type registry.]  The FM Channel
   does not use ACh TLVs and MUST NOT include the ACh TLV header.  The
   ACH with the FM ACh code point 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|   Reserved    |       0xHHHH FM Channel       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               ~
      ~                  MPLS Fault Management Message                ~
      ~                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: ACH Indication of the MPLS Fault Management Channel

   The first three fields are defined in RFC 5586 [4].

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


4.  MPLS Fault Management Message Format

   The format of the Fault Management message is shown below.







Swallow, et al.           Expires March 5, 2012                 [Page 7]

Internet-Draft          MPLS Fault Management OAM         September 2011


       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  | Resvd |   Msg Type    |     Flags     | Refresh Timer |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Total TLV Len |                                               ~
      +-+-+-+-+-+-+-+-+              TLVs                             ~
      ~                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: MPLS Fault OAM Message Format

   Version

      The Version Number is currently 1.

   Reserved

      This field MUST be set to zero on transmission and ignored on
      receipt.

   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              Lock Report (LKR)

   Flags

      Two flags are defined.  The reserved flags in this field MUST be
      set to zero on transmission and ignored on receipt.




             +-+-+-+-+-+-+-+-+
             | Reserved  |L|R|
             +-+-+-+-+-+-+-+-+


                               Figure 3: Flags




Swallow, et al.           Expires March 5, 2012                 [Page 8]

Internet-Draft          MPLS Fault Management OAM         September 2011


      L-flag

         Link Down Indication.  The L-flag only has significance in the
         AIS message.  For the LKR message the L-flag MUST be set to
         zero and ignored on receipt.  See Section 2.1.1 for details on
         setting this bit.

      R-flag

         The R-flag is clear to indicate the presence of an FM condition
         and is to one to indicate the removal of a previously sent FM
         condition.

   Refresh Timer

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

   Total TLV Length

      The total length in bytes of all included TLVs.

4.1.  Fault Management Message TLVs

   TLVs are used in Fault Management messages to carry information that
   may not pertain to all messages as well as to allow for
   extensibility.  The TLVs currently defined are the IF_ID, and the
   Global_ID.

   TLVs (Type-Length-Value tuples) have the following format:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
      |                                                               .
      .                             Value                             .
      .                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 4: Fault TLV Format

   Type





Swallow, et al.           Expires March 5, 2012                 [Page 9]

Internet-Draft          MPLS Fault Management OAM         September 2011


      Encodes how the Value field is to be interpreted.

   Length

      Specifies the length of the Value field in octets.

   Value

      Octet string of Length octets that encodes information to be
      interpreted as specified by the Type field.

4.1.1.  Interface Identifier TLV

   The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in
   draft-ietf-mpls-tp-identifiers [5].  The Type is 0x1.  The length is
   0x8.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MPLS-TP Node Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MPLS-TP Interface Number                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                 Figure 5: Interface Identifier TLV Format

4.1.2.  Global Identifier

   The Global Identifier (Global_ID) TLV carries the Global_ID as
   defined in draft-ietf-mpls-tp-identifiers [5].  The Type is 0x2.  The
   length is 0x4.



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   MPLS-TP Global Identifier                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 6: Global Identifier TLV Format




Swallow, et al.           Expires March 5, 2012                [Page 10]

Internet-Draft          MPLS Fault Management OAM         September 2011


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 MUST NOT be changed on successive FM messages
   reporting the same incident.  If the optional clearing procedures are
   not used, then the default value is 1 second.  Otherwise the default
   value is 20 seconds.

   A Global_ID MAY be included.  If the R-flag clearing procedures are
   to be used, the IF_ID TLV MUST be included.  Otherwise, the IF_ID TLV
   MAY be included.

   The message is then sent.  Assuming the condition persists, the
   message MUST be retransmitted two more times at an interval of one
   second.  Further retransmissions are made according to the value of
   the refresh timer.  Retransmissions continue until the condition is
   cleared.

5.2.  Clearing a FM Indication

   When a fault is cleared, a node MUST cease sending the associated FM
   messages.  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 retransmitted two
   more times at an interval of one second.  Note, however if another
   fault occurs, the node MUST cease these retransmissions and a
   generate new FM messages for the new fault.

5.3.  Receiving a FM Indication

   When a FM message is received, a MEP examines it to ensure that it is
   well formed.  If the message type is reserved or unknown, the message
   is ignored.  If the version number is unknown, the message is
   ignored.

   If the R-flag is set to zero, the MEP checks to see if a condition
   matching the message type exists.  If it does not, the condition
   specific to the message type is entered.  An expiration-timer is set
   to 3.5 times the refresh timer.  If the message type matches an
   existing condition, the message is considered a refresh and the
   expiration-timer is reset.  In both cases, if an IF_ID tlv is
   present, it is recorded.



Swallow, et al.           Expires March 5, 2012                [Page 11]

Internet-Draft          MPLS Fault Management OAM         September 2011


   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
   condition is cleared.  Otherwise the message is ignored.

   If the expiration-time expires, the condition is cleared.


6.  Minimum Implementation Requirements

   At a minimum an implementation MUST support the following:

   1.  Sending AIS and LKR messages at a rate of 1 per second.

   2.  Support of setting the L-flag to indicate a server-failure.

   3.  Receiving AIS and LKR messages with any allowed Refresh Timer
       value.

   The following items are OPTIONAL to implement.

   1.  Sending AIS and LKR message with values of the Refresh Timer
       other than 1 second.

   2.  Support of receiving the L-flag.

   3.  Support of setting the R-flag to a value other than zero.

   4.  Support of receiving the R-flag.

   5.  All TLVs.


7.  Security Considerations

   MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
   the security model of MPLS.  MPLS networks make the assumption that
   it is very hard to inject traffic into a network, and equally hard to
   cause traffic to be directed outside the network.  The control plane
   protocols utilize hop-by-hop security, and assume a "chain-of-trust"
   model such that end-to-end control plane security is not used.  For
   more information on the generic aspects of MPLS security, see RFC
   5920 [8].

   This document describes a protocol carried in the G-ACh RFC 5586 [4],
   and so is dependent on the security of the G-ACh, itself.  The G-ACh
   is a generalization of the Associated Channel defined in RFC 4385
   [6].  Thus, this document relies heavily on the security mechanisms
   provided for the Associated Channel and described in those two



Swallow, et al.           Expires March 5, 2012                [Page 12]

Internet-Draft          MPLS Fault Management OAM         September 2011


   documents.

   A specific concern for the G-ACh is that is can be used to provide a
   covert channel.  This problem is wider than the scope of this
   document and does not need to be addressed here, but it should be
   noted that the channel provides end-to-end connectivity and SHOULD
   NOT be policed by transit nodes.  Thus, there is no simple way of
   preventing any traffic being carried in the G-ACh between consenting
   nodes.

   A good discussion of the data plane security of an associated channel
   may be found in RFC 5085 [9].  That document also describes some
   mitigation techniques.

   It should be noted that the G-ACh is essentially connection-oriented
   so injection or modification of control messages specified in this
   document requires the subversion of a transit node.  Such subversion
   is generally considered hard in MPLS networks, and impossible to
   protect against at the protocol level.  Management level techniques
   are more appropriate.

   Spurious fault OAM messages form a vector for a denial of service
   attack.  However, since these messages are carried in a control
   channel, except for one case discussed below, one would have to gain
   access to a node providing the service in order to effect such an
   attack.  Since transport networks are usually operated as a walled
   garden, such threats are less likely.

   If external MPLS traffic is mapped to an LSP via a PHP forwarding
   operation, it is possible to insert a GAL followed by a fault OAM
   message.  In such a situation an operator SHOULD protect against this
   attack by filtering any fault OAM messages with the GAL at the top of
   the label stack.


8.  IANA Considerations

8.1.  Pseudowire Associated Channel Type

   Fault OAM requires a unique Associated Channel Type which are
   assigned by IANA from the Pseudowire Associated Channel Types
   Registry.

   Registry:
   Value        Description              TLV Follows  Reference
   -----------  -----------------------  -----------  ---------
   0xHHHH       Fault OAM                No           (This Document)




Swallow, et al.           Expires March 5, 2012                [Page 13]

Internet-Draft          MPLS Fault Management OAM         September 2011


   [Note: An early codepoint allocation was made: 0x0058 Fault OAM
   (TEMPORARY - expires 2012-07-20)]

8.2.  MPLS Fault OAM Message Type Registry

   This section details the MPLS Fault OAM Message Type Registry, a new
   name space to be managed by IANA.  The Type space is divided into
   assignment ranges; the following terms are used in describing the
   procedures by which IANA allocates values: "Standards Action" (as
   defined in RFC 5226 [7]) and "Experimental Use".

   MPLS Fault OAM Message Types take values in the range 0-255.
   Assignments in the range 0-251 are via Standards Action; values in
   the range 252-255 are for Experimental Use, and MUST NOT be
   allocated.

   Message Types defined in this document are:

      Msg Type           Description
      --------           -----------------------------
        0x0              Reserved (not available for allocation)
        0x1              Alarm Indication Signal (AIS)
        0x2              Lock Report (LKR)

8.3.  MPLS Fault OAM Flag Registry

   This section details the MPLS Fault OAM Flag Registry, a new name
   space to be managed by IANA.  The Flag space ranges from 0-7.  All
   flags are allocated by "Standards Action".

   Flags defined in this document are:

      Bit        Hex Value         Description
      ---        ---------         -----------
      0-5                          Unassigned
       6            0x2            L-Flag
       7            0x1            R-Flag

8.4.  MPLS Fault OAM TLV Registry

   This sections details the MPLS Fault OAM TLV Registry, a new name
   spaces to be managed by IANA.  The Type space is divided into
   assignment ranges; the following terms are used in describing the
   procedures by which IANA allocates values: "Standards Action" (as
   defined in RFC 5226 [7]), "Specification Required" and "Private Use".

   MPLS Fault OAM TLVs which take values in the range 0-255.
   Assignments in the range 0-191 are via Standards Action; assignments



Swallow, et al.           Expires March 5, 2012                [Page 14]

Internet-Draft          MPLS Fault Management OAM         September 2011


   in the range 192-247 are made via "Specification Required"; values in
   the range 248-255 are for Experimental Use, and MUST NOT be
   allocated.

   TLVs defined in this document are:

      Value    TLV Name
      -----    -------
          0    Reserved (not available for allocation)
          1    Interface Identifier TLV
          2    Global Identifier


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
        Operations, Administration, and Maintenance (OAM) in MPLS
        Transport Networks", RFC 5860, May 2010.

   [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]  Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers",
        draft-ietf-mpls-tp-identifiers-07 (work in progress), July 2011.

   [6]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
        "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
        over an MPLS PSN", RFC 4385, February 2006.

   [7]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

9.2.  Informative References

   [8]  Fang, L., "Security Framework for MPLS and GMPLS Networks",
        RFC 5920, July 2010.

   [9]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
        Connectivity Verification (VCCV): A Control Channel for



Swallow, et al.           Expires March 5, 2012                [Page 15]

Internet-Draft          MPLS Fault Management OAM         September 2011


        Pseudowires", RFC 5085, December 2007.


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 March 5, 2012                [Page 16]

Internet-Draft          MPLS Fault Management OAM         September 2011


   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 March 5, 2012                [Page 17]

