[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: April 28, 2011                                         Ericsson
                                                       M. Vigoureux, Ed.
                                                          Alcatel-Lucent
                                                              S. Boutros
                                                     Cisco Systems, Inc.
                                                                 D. Ward
                                                  Juniper Networks, Inc.

                                                        October 25, 2010


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

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 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 April 28, 2011.








Swallow, et al.          Expires April 28, 2011                 [Page 1]

Internet-Draft          MPLS Fault Management OAM           October 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 Simplified BSD License.


Table of Contents

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







Swallow, et al.          Expires April 28, 2011                 [Page 2]

Internet-Draft          MPLS Fault Management OAM           October 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, OAM 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 RFC 5860 [2].  However, this mechanism is
   intended to be applicable to other aspects of MPLS as well.

   Two broad classes of 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.  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 the Defect class, a further category, Fault is identified.  A
   fault is the inability of a function to perform a required action.  A
   fault is a persistent defect.

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

   ASN: Autonomous System Number



Swallow, et al.          Expires April 28, 2011                 [Page 3]

Internet-Draft          MPLS Fault Management OAM           October 2010


   CC: Continuity Check

   FM: Fault Management

   GAL: Generic Associated Channel Label

   LOC: Loss of Continuity

   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 service disruptive
   conditions.  Two messages are defined, Alarm Indication Signal, and
   Lock Report.  These semantics of the individual messages are
   described in subsections below.




Swallow, et al.          Expires April 28, 2011                 [Page 4]

Internet-Draft          MPLS Fault Management OAM           October 2010


   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 ACH codepoint.

   Fault OAM messages are generated by intermediate nodes where an LSP
   is switched.  When a server layer, (e.g. a link) used by the LSP
   fails, the intermediate node sends Fault Management messages using
   the LSP's Fault associated channel back to the endpoint of the LSP.
   Strictly speaking, 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 as the condition is detected, that is before
   any determination has been made as to whether the condition is
   persistent and therefore fatal.  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.

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

2.1.1.  MPLS-TP Link Down Indication

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

   The setting of the LDI flag can be predetermined based on the
   protection state.  If the Server Layer is protected and both the
   working and protection paths are available, both the active and
   standby MEPs should be programmed to send AIS with LDI clear upon
   detecting a defect condition.  If the Server Layer is unprotected or



Swallow, et al.          Expires April 28, 2011                 [Page 5]

Internet-Draft          MPLS Fault Management OAM           October 2010


   the Server Layer is protected but only the active path is available,
   the active MEP should be programmed to send AIS with LDI set upon
   detecting a defect condition.

   The receipt of an AIS message with the LDI flag set MAY be treated as
   the equivalent of loss of continuity (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 LDI flag may be ignored.
   AIS messages with the LDI flag set SHOULD be treated the same as any
   other AIS message, that 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 LDI flag enables faster
   switch-over upon a failure occurring along the LSP.

2.2.  MPLS-TP Lock Report

   The MPLS-TP Lock 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.  The purpose of the LKR message 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 primary purpose of the LKR message is to suppress alarms in the
   MPLS-TP layer network above the level at which the defect occurs.
   Like AIS with the LDI flag set, the receipt of an LKR message MAY be
   treated as the equivalent of loss of continuity at the client layer.


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.  Note: An early codepoint
   allocation has made: 0x0058 Fault OAM (TEMPORARY - expires
   2011-07-16)] The FM Channel does not use ACH TLVs and MUST not
   include the ACH TLV header.  The FM ACH Channel is shown below.








Swallow, et al.          Expires April 28, 2011                 [Page 6]

Internet-Draft          MPLS Fault Management OAM           October 2010


       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 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               ~
      ~                  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)


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

                   Figure 2: MPLS-TP 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.






Swallow, et al.          Expires April 28, 2011                 [Page 7]

Internet-Draft          MPLS Fault Management OAM           October 2010


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

   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 TLV length is the total of all included TLVs.

   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

      L-flag

         Link Down Indication.  See section Section 2.1.1 for details on
         setting this bit.

      R-flag

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

4.1.  Fault Management Message TLVs

   TLVs are used in fault OAM 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, Global-ID, and ICC.

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






Swallow, et al.          Expires April 28, 2011                 [Page 8]

Internet-Draft          MPLS Fault Management OAM           October 2010


       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

      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

   This TLV carries the Interface Identifier 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







Swallow, et al.          Expires April 28, 2011                 [Page 9]

Internet-Draft          MPLS Fault Management OAM           October 2010


4.1.2.  Global Identifier

   This TLV carries the Interface Identifier 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

4.1.3.  International Carrier Code

   This TLV carries the International Carrier Code.  The Type is 0x3.
   The length is 0x8.  The value is an Octet string padded with nulls.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   International Carrier Code                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                International Carrier Code (Cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 7: International Carrier Code


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.
   If the optional clearing procedures are not used, then the default
   value is 1.  Otherwise the default value is 20.




Swallow, et al.          Expires April 28, 2011                [Page 10]

Internet-Draft          MPLS Fault Management OAM           October 2010


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


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.  In
       particular other values of the Refresh Timer and setting the R
       bit to value other than zero need not be supported.

   2.  Support of the sending the LDI flag.

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

   The following items are optional to implement.



Swallow, et al.          Expires April 28, 2011                [Page 11]

Internet-Draft          MPLS Fault Management OAM           October 2010


   1.  Support of receiving the LDI flag.

   2.  Support of receiving the R flag.

   3.  All TLVs.


7.  Security Considerations

   Spurious fault OAM messages form a vector for a denial of service
   attack.  However, since these messages are carried in a control
   channel, 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.


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)

8.2.  MPLS Fault OAM Message Type 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 [6]) and "Private 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 251-255 are for Private Use, and MUST NOT be allocated.

   Message Types defined in this document are:

      Msg Type           Description
      --------           -----------------------------
        0x0              Reserved
        0x1              Alarm Indication Signal (AIS)



Swallow, et al.          Expires April 28, 2011                [Page 12]

Internet-Draft          MPLS Fault Management OAM           October 2010


        0x2              Lock Report (LKR)

8.3.  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 [6]), "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
   in the range 192-248 are made via "Specification Required"; values in
   the range 248-255 are for Private Use, and MUST NOT be allocated.

   TLVs defined in this document are:

      Value    TLV Name
      -----    -------
          0    Reserved
          1    Interface Identifier TLV
          2    Global Identifier
          3    International Carrier Code


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-03 (work in progress),
        October 2010.

   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA



Swallow, et al.          Expires April 28, 2011                [Page 13]

Internet-Draft          MPLS Fault Management OAM           October 2010


        Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

9.2.  Informative References


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 April 28, 2011                [Page 14]

Internet-Draft          MPLS Fault Management OAM           October 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 April 28, 2011                [Page 15]


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