Internet DRAFT - draft-ietf-pwe3-oam-config

draft-ietf-pwe3-oam-config






PWE3 Working Group                                         F. Zhang, Ed.
Internet-Draft                                                B. Wu, Ed.
Intended status: Standards Track                         ZTE Corporation
Expires: February 25, 2013                            E. Bellagamba, Ed.
                                                                Ericsson
                                                         August 24, 2012


    Label Distribution Protocol Extensions for Proactive Operations,
 Administration and Maintenance Configuration of Dynamic MPLS Transport
                           Profile PseudoWire
                     draft-ietf-pwe3-oam-config-01

Abstract

   This document specifies extensions to the Label Distribution Protocol
   (LDP) to configure and control proactive Operations, Adminstration
   and Maintenance (OAM) functions, suitable for dynamic Single-Segment
   PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW).

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 February 25, 2013.

Copyright Notice

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



Zhang, et al.           Expires February 25, 2013               [Page 1]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   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
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Analysis of PW OAM Configuration Extended by MPLS-TP . . . . .  4
     3.1.  Continuity Check, Connectivity Verification and Remote
           Defect Indication  . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Performance Monitoring Loss/Delay  . . . . . . . . . . . .  5
     3.3.  FMS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  PW OAM Configuration Procedures  . . . . . . . . . . . . . . .  6
     4.1.  OAM Configuration for MS-PW  . . . . . . . . . . . . . . .  7
       4.1.1.  Establishment of OAM Entities and Functions  . . . . .  7
       4.1.2.  Adjustment of OAM Parameters . . . . . . . . . . . . .  8
       4.1.3.  Deleting OAM Entities  . . . . . . . . . . . . . . . .  9
     4.2.  OAM Configuration for SS-PW  . . . . . . . . . . . . . . .  9
   5.  LDP extensions . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  MPLS-TP PW OAM Administration TLV  . . . . . . . . . . . . 10
     5.2.  MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . . 10
       5.2.1.  BFD Configuration sub-TLV  . . . . . . . . . . . . . . 12
         5.2.1.1.  Local Discriminator sub-TLV  . . . . . . . . . . . 13
         5.2.1.2.  Negotiation Timer Parameters sub-TLV . . . . . . . 13
         5.2.1.3.  BFD Authentication sub-TLV . . . . . . . . . . . . 15
       5.2.2.  Performance Monitoring sub-TLV . . . . . . . . . . . . 15
         5.2.2.1.  MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . . 16
         5.2.2.2.  MPLS-TP PW PM Delay TLV  . . . . . . . . . . . . . 17
       5.2.3.  MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  OAM Configuration Errors . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22










Zhang, et al.           Expires February 25, 2013               [Page 2]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


1.  Introduction

   MPLS Pseudowire (PW) is defined in [RFC3985] and [RFC5659], which
   provides for emulated services over an MPLS Packet Switched Network
   (PSN).  MPLS Transport Profile (MPLS-TP) describes a profile of MPLS
   that enables operational models typical in transport networks, while
   providing additional Operations, Administration and Maintenance
   (OAM), survivability and other maintenance functions not previously
   supported by IP/MPLS.  The corresponding requirements are defined in
   [RFC5860].

   The MPLS-TP OAM mechanisms that are operated to meet transport
   requirements are described in [RFC6371], categorized into proactive
   and on-demand monitoring.  Proactive monitoring refers to OAM
   operations that are either configured to be carried out periodically
   and continuously or preconfigured to act on certain events such as
   alarm signals.  In contrast, on-demand monitoring is initiated
   manually and for a limited amount of time, usually for operations
   such as diagnostics to investigate into a defect condition.

   The Network Management System (NMS) or Label Switched Path (LSP) Ping
   [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] is used to configure these
   OAM functionalities if a control plane is not instantiated.  But if
   the control plane is used, it must support the configuration and
   modification of OAM maintenance points as well as the activation/
   deactivation of OAM when the transport path or transport service is
   established or modified [RFC5654].

   This document specifies the extensions to the LDP protocol to
   configure and bootstrap proactive PW OAM functions, suitable for
   Point to Point (P2P) SS-PW and MS-PW.  The extensions to Point to
   Multi-Point (P2MP) PW will be studied in the future.


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

2.1.  Acronyms

      AC: Attachment Circuit
      AIS: Alarm indication signal







Zhang, et al.           Expires February 25, 2013               [Page 3]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


      BFD: Bidirectional Forwarding Detection
      CC: Continuity Check
      CV: Connectivity Verification
      DM: Delay Measurement
      FEC: Forwarding Equivalence Class
      FMS: Fault Management Signal
      ICMP: Internet Control Message Protocol
      G-ACh: Generic Associated Channel
      LDI: Link Down Indication
      LDP: Label Distribution Protocol
      LKR: Lock Reporting
      LM: Loss Measurement
      LSP: Label Switched Path
      ME: Maintenance Entity
      MEG: Maintenance Entity Group
      MEP: Maintenance Entity Group End Point
      MIP: Maintenance Entity Group Intermediate Point
      MPLS-TP: MPLS Transport Profile
      MS-PW: Multi-Segment PseudoWire
      NMS: Network Management System
      OAM: Operations, Adminstration and Maintenance
      P2MP: Point to Multi-Point
      PE: Provider Edge
      PHB: Per-Hop Behavior
      PM: Performance Monitoring
      PSN: Packet Switched Network
      PW: PseudoWire
      S-PE: Switching Provider Edge
      SPME: Sub-Path Maintenance Entity
      SS-PW: Single-Segment Pseudo Wire
      T-PE: Terminating Provider Edge
      TLV: Type Length Value
      VCCV: Virtual Circuit Connectivity Verification


3.  Analysis of PW OAM Configuration Extended by MPLS-TP

3.1.  Continuity Check, Connectivity Verification and Remote Defect
      Indication

   The Proactive CC, CV and Remote Defect Indication (RDI) functions of
   MPLS-TP are based on the extensions to BFD [RFC6428], which addresses
   the proactive CV gap that VCCV BFD does not support.  The BFD packets
   can be encapsulated by IP or non-IP in G-ACh, and operate in
   coordinated or independent mode.

   Timer negotiation, such as Transmitter (TX)/Receiver (RX) interval
   can be performed in subsequent BFD control messages [RFC5880] or



Zhang, et al.           Expires February 25, 2013               [Page 4]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   directly in the LSP ping configuration messages, but it also can be
   gotten by control plane signaling [RFC6371].

   The use of the VCCV control channel provides the context, based on
   the MPLS-PW label, required to bind and bootstrap the BFD session to
   a particular PW, so local discriminator values are not exchanged
   [RFC6669].  However, in order to identify certain extreme cases of
   mis-connectivity and fulfill the requirements that the BFD mechanism
   MUST be the same for LSP, Single Segment Pseudowire (SS-PW), Multi
   Segment Pseudowire (MS-PW) and Section as well as for Sub-path
   Maintenance Element (SPME), BFD might still need to use discriminator
   values to identify the connection being verified at both ends of the
   PW.  The discriminator values can be statically configured, or
   signaled via LSP Ping or LDP extensions defined in this document.

   Per-hop Behavior (PHB), which identifies the per-hop behavior of BFD
   packet, SHOULD be configured as well.  This permits the verification
   of correct operation of Quality of Serivce (QoS) queuing as well as
   connectivity.

   When BFD Control packets are transported in the G-ACh they are not
   protected by any end-to-end checksum, only lower-layers are providing
   error detection/correction.  A single bit error, e.g. a flipped bit
   in the BFD State field could cause the receiving end to wrongly
   conclude that the link is down and in turn trigger protection
   switching.  To prevent this from happening the "BFD Configuration
   sub-TLV" has an Integrity flag that when set enables BFD
   Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880].
   This would make every BFD Control packet carry an SHA1 hash of itself
   that can be used to detect errors.

   If BFD Authentication using a shared key / password is desired (i.e.
   actual authentication not only error detection) the "BFD
   Authentication sub-TLV" MUST be included in the "BFD Configuration
   sub-TLV".  The "BFD Authentication sub-TLV" is used to specify which
   authentication method that should be used and which shared key /
   password that should be used for this particular session.  How the
   key exchange is performed is out of scope of this document.

3.2.  Performance Monitoring Loss/Delay

   Performance monitoring (PM) of PWs, especially for packet Loss
   Measurement (LM) and packet Delay Measurement (DM), are specified in
   [RFC6374], [RFC6375].

   When configuring Performance monitoring functionalities it can be
   chosen either the default configuration (by only setting the
   respective flags in the "MPLS-TP PW OAM Configuration TLV") or a



Zhang, et al.           Expires February 25, 2013               [Page 5]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   customized configuration (by including the respective MPLS-TP PW PM
   Loss and/or Delay sub-TLVs).

   By setting the PM Loss flag in the "MPLS-TP PW OAM Configuration TLV"
   and including the "MPLS-TP PW PM Loss sub-TLV" one can configure the
   measurement interval and loss threshold values for triggering
   protection.

   Delay measurements are configured by setting PM Delay flag in the
   "MPLS-TP PW OAM Configuration TLV" and including the "MPLS-TP PW PM
   Loss sub-TLV" one can configure the measurement interval and the
   delay threshold values for triggering protection.

3.3.  FMS

   Fault Management Signals (FMS) are specified in [RFC6428], with which
   a server PW can notify client PWs about various fault conditions to
   suppress alarms or to be used as triggers for actions in the client
   PWs.  The following signals are defined: Alarm Indication Signal
   (AIS), Link Down Indication (LDI) and Lock Reporting (LKR).

   For each MEP of each Maintenance Entity Group (MEG), enabling/
   disabling the generation of FMS packets, the transmitted period and
   PHB SHOULD be configured.  This can be done independently, and the
   values of configured parameters can be different, but for easy
   maintenance, these setting SHOULD be consistent.

3.4.  Conclusion

   According to the analysis above, LDP needs to be extended to
   configure and bootstrap proactive PW OAM functions, such as, CC-CV-
   RDI, PM Loss/Delay, FMS.  In this way, OAM configuration is bound to
   PW signaling, avoiding two separate management/configuration steps
   (PW establishment followed by OAM configuration) which would
   increases delay, processing and more importantly may be prune to mis-
   configuration errors.


4.  PW OAM Configuration Procedures

   A PE may play an active or passive role in the signaling of the PW.
   There exist two situations:

   a) Active/active: both PEs of a PW are active (SS-PW), they select PW
   OAM configuration parameters and send with the Label Mapping message
   to each other independently.

   b) Active/passive: one PE is active and the others are passive



Zhang, et al.           Expires February 25, 2013               [Page 6]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   (MS-PW).  The active/passive role election is defined in Section
   7.2.1 of [RFC6073] and applies here, this document does not define
   any new role election procedures.

   The general rules of OAM configuration procedures are mostly
   identical between MS-PW and SS-PW, except that SS-PW does not need to
   configure MIP function and the Mapping message are sent out
   independently.  Section 4.1 takes MS-PW as an example to describe the
   general OAM configuration procedures.  As for SS-PW, the specific
   differences would be addressed in section 4.2.

4.1.  OAM Configuration for MS-PW

4.1.1.  Establishment of OAM Entities and Functions

   Assuming there is one PW that needs to be setup between T-PE1 and
   T-PE2, across S-PE1 and S-PE2.  OAM functions must be setup and
   enabled in the appropriate order so that spurious alarms can be
   avoided.

       +-------+        +-------+        +-------+        +-------+
       |       |        |       |        |       |        |       |
       |      A|--------|B     C|--------|D     E|--------|F      |
       |       |        |       |        |       |        |       |
       +-------+        +-------+        +-------+        +-------+
         T-PE1            S-PE1            S-PE2            T-PE2


                 Figure 1: MS-PW OAM Configuration Scheme

   Fist of all, T-PE1 MUST setup the OAM sink function to be prepared to
   receive OAM messages but MUST suppress any OAM alarms (e.g., due to
   missing or unidentified OAM messages).  The Mapping message MUST be
   sent with the "OAM Alarms Enabled" cleared and "OAM MIP Entities
   desired" set in the MPLS-TP PW OAM Administation TLV.

   When the Mapping message arrives at the downstream S-PEs, such as
   S-PE1 and S-PE2, they MUST establish and configure MIP entities
   according to the set "I"flag in the MPLS-TP PW OAM Administration
   TLV.  If failure, a Notification message SHOULD be sent, with a
   Status Code set to "MIP Configuration Failure".  If OAM entities are
   established successfully, the middle points (S-PE1 and S-PE2) MUST
   forward the Mapping message downstream, the endpoint (T-PE2) MUST set
   the OAM Source function and MUST be prepared to Send OAM messages.

   The same rules are applied to the reverse direction (from T-PE2 to
   T-PE1), that is to say, T-PE2 needs to setup the OAM sink function to
   be prepared to receive OAM messages but MUST suppress any OAM alarms



Zhang, et al.           Expires February 25, 2013               [Page 7]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   (e.g., due to missing or unidentified OAM messages).  The Mapping
   message MUST be sent with the "OAM Alarms Enabled" cleared, "OAM MIP
   Entities desired" set in the MPLS-TP PW OAM Administration TLV.  When
   T-PE1 receives the Mapping message, it completes any pending OAM
   configuration and enables the OAM source function to send OAM
   messages.

   After this round, OAM entities are established and configured for the
   PW and OAM messages MAY already be exchanged, and OAM alarms can now
   be enabled.  The T-PE nodes (T-PE1 and T-PE2), while still keeping
   OAM alarms disabled send a Notification message with "OAM Alarms
   Enabled" PW status flag set, and enable the OAM alarms after
   processing the Notification message.  At this point, data-plane OAM
   is fully functional, and the MPLS-TP OAM PW configuration TLV MAY be
   omitted in subsequent Notification messages

   The PW MAY be setup with OAM entities right away with the first
   signaling, as described above, but a PW MAY be signaled and
   established without OAM configuration first, and OAM entities may be
   added later.  This can be done by sending a Notification message with
   the related configuration parameters subsequently.

4.1.2.  Adjustment of OAM Parameters

   There may be a need to change the parameters of an already
   established and configured OAM function during the lifetime of the
   PW.  To do so the T-PE nodes need to send a Notification message with
   the updated parameters.  OAM parameters that influence the content
   and timing of OAM messages and identify the way OAM defects and
   alarms are derived and generated.  Hence, to avoid spurious alarms,
   it is important that both sides, OAM sink and source, are updated in
   a synchronized way.  Firstly, the alarms of the OAM sink function
   should be suppressed and only then should expected OAM parameters be
   adjusted.  Subsequently, the parameters of the OAM source function
   can be updated.  Finally, the alarms of the OAM sink side can be
   enabled again.

   In accordance with the above operation, T-PE1 MUST send a
   Notification message with "OAM Alarms Enabled" cleared and including
   the updated MPLS-TP PW OAM Configuration TLV corresponding to the new
   parameter settings.  The initiator (T-PE1) MUST keep its OAM sink and
   source functions running unmodified, but it MUST suppress OAM alarms
   after the updated Notification message is sent.  The receiver (T-PE2)
   MUST firstly disable all OAM alarms, then update the OAM parameters
   according to the information in the Notification message and reply
   with a Notification message acknowledging the changes by including
   the MPLS-TP PW OAM Configuration TLV.  Note that the receiving side
   has the possibility to adjust the requested OAM configuration



Zhang, et al.           Expires February 25, 2013               [Page 8]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   parameters and reply with and updated MPLS-TP PW OAM Configuration
   TLV in the Notification message, reflecting the actually configured
   values.  However, in order to avoid an extensive negotiation phase,
   in the case of adjusting already configured OAM functions, the
   receiving side SHOULD NOT update the parameters requested in the
   Notification message to an extent that would provide lower
   performance than what has been configured previously.

   The initiator (T-PE1) MUST only update its OAM sink and source
   functions when it has received the Notification message from the
   peer.  After the OAM parameters are updated and OAM is running
   according the new parameter settings, OAM alarms are still disabled,
   so a subsequent Notification messages exchanges with "OAM Alarms
   Enabled" flag set are needed to enable OAM alarms again.

4.1.3.  Deleting OAM Entities

   In some cases it may be useful to remove some or all OAM entities and
   functions from one PW without actually tearing down the connection.
   To avoid any spurious alarm, the following procedure should be
   followed:

   The T-PE nodes disable OAM alarms and SHOULD send Notification
   message to each other with "OAM Alarms Enabled" cleared but unchanged
   OAM configuration and without the MPLS-TP PW OAM Configuration TLV.
   After that, T-PE1 (T-PE2) SHOULD delete OAM source functions, then
   send a Notification message with "OAM MIP Entities desired" cleared.
   While T-PE2 (T-PE1) deletes OAM sink function, S-PE1 and S-PE2 delete
   MIP configuration when they receive the Notification message with
   "OAM MIP Entities desired" cleared.

   Alternatively, if only some OAM functions need to be removed, the
   T-PE node sends the Notification message with the updated OAM
   Configuration TLV.  Changes between the contents of the previously
   signaled OAM Configuration TLV and the currently received TLV
   represent which functions SHOULD be removed/added.

4.2.  OAM Configuration for SS-PW

   Assuming there is one PW that needs to be setup between T-PE1 and
   T-PE2.

   If the receiving PE (T-PE2) have initiated the MPLS-TP PW OAM
   configuration request to the other PE (T-PE1), it MUST compare its
   AII against T-PE1's.  If it is numerically lower, will reply a
   Notification message with the updated "MPLS-TP PW OAM Configuration
   TLV", and the Status Code set to "Wrong MPLS-TP PW OAM Configuration
   TLV".



Zhang, et al.           Expires February 25, 2013               [Page 9]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   On the other hand, if the T-PE2's AII is numerically higher than
   T-PE1's, it MUST reply a Notification message with Status Code set to
   "Rejected MPLS-TP PW OAM Configuration TLV".


5.  LDP extensions

   Below, LDP extensions to configure proactive MPLS-TP PW OAM functions
   are defined.

5.1.  MPLS-TP PW OAM Administration TLV

   The format of the MPLS-TP PW OAM Administration TLV is as follows:

         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|          Type (TBD)     |            Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|A|           Reserved                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     MPLS-TP PW OAM Administration TLV

   One bit "I" (0, IANA to assign): "OAM MIP Entities Desired" is
   allocated.  If the "OAM MIP entities desired" bit is set, it is
   indicating that the establishment of OAM MIP entities is required at
   every transit node of the signaled PW.  If the establishment of a MIP
   is not supported, a Notification message MUST be sent with Status
   Code set to "MIP Configuration Failure".

   One bit "A" (1, IANA to assign): "OAM Alarms Enabled" is allocated.
   If the "OAM Alarms Enabled" bit is set, it is indicating that the
   T-PE needs to enable OAM alarms.

   Reserved (2-31 bits): This field MUST be set to zero on transmission
   and MUST be ignored on receipt.

5.2.  MPLS-TP PW OAM Configuration TLV

   The "MPLS-TP PW OAM Configuration TLV" is depicted in the following
   figure.  It may be carried in the Mapping and Notification messages,
   just following the PW Status TLV.








Zhang, et al.           Expires February 25, 2013              [Page 10]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


     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|       Type (TBD)          |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|V|L|D|F|             OAM Function Flags                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                           sub-TLVs                            ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     MPLS-TP PW OAM Configuration TLV

   The "MPLS-TP PW OAM Configuration TLV" contains a number of flags
   indicating which OAM functions should be activated as well as OAM
   function specific sub-TLVs with configuration parameters for the
   particular functions.

   Type: indicates a new type: the MPLS-TP PW OAM Configuration TLV
   (IANA to assign).

   Length: the length of the OAM Function Flags field including the
   total length of the sub-TLVs in octets.

   OAM Function Flags: a bitmap numbered from left to right as shown in
   the figure.

   These flags are defined in this document:

      OAM Function Flag bit#             Description
      ---------------------      ---------------------------
               0 (C)             Continuity Check (CC)
               1 (V)             Connectivity Verification (CV)
               2 (L)             Performance Monitoring/Loss (PM/Loss)
               3 (D)             Performance Monitoring/Delay (PM/Delay)
               4 (F)             Fault Management Signals (FMS)
               5-31              Reserved (set all to 0s)

   Sub-TLVs corresponding to the different flags are as follows.
   o  "BFD Configuration sub-TLV", which MUST be included if the CC
      and/or the CV OAM Function flag is set.  Furthermore, if the CV
      flag is set, the CC flag MUST be set at the same time.
   o  "Performance Monitoring sub-TLV", which MUST be included if the
      PM/Loss OAM Function flag is set.
   o  "MPLS-TP PW FMS sub-TLV", which MAY be included if the FMS OAM
      Function flag is set.  If the "MPLS-TP PW FMS sub-TLV" is not
      included, default configuration values are used.



Zhang, et al.           Expires February 25, 2013              [Page 11]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


5.2.1.  BFD Configuration sub-TLV

   The "BFD Configuration sub-TLV is defined for BFD specific
   configuration parameters, which accommodates generic BFD OAM
   information and carries sub-TLVs.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  BFD Conf. Type (1) (IANA)    |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Vers.| PHB |N|S|I|G|U|A|   Reserved (set to all 0s)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           sub TLVs                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         BFD Configuration sub-TLV

   Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to
   define, suggested value 1).

   Length: indicates the length of the TLV including sub-TLVs but
   excluding the Type and Length field, in octets.

   Version: identifies the BFD protocol version.  If a node does not
   support a specific BFD version, a Notification message MUST be
   generated with Status Code set to "Unsupported OAM Version".

   PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic
   continuity monitoring messages.

   BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD
   Control Messages is enabled, when cleared it is disabled.

   Symmetric session (S): If set the BFD session MUST use symmetric
   timing values.

   Integrity (I): If set BFD Authentication MUST be enabled.  If the
   "BFD Configuration sub-TLV" does not include a "BFD Authentication
   sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre-
   shared key (all 0s).

   Encapsulation Capability (G): if set, it shows the capability of
   encapsulating BFD messages into G-Ach channel without IP/UDP headers.
   If both the G bit and U bit are set, configuration gives precedence
   to the G bit.



Zhang, et al.           Expires February 25, 2013              [Page 12]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   Encapsulation Capability (U): if set, it shows the capability of
   encapsulating BFD messages into G-Ach channel with IP/UDP headers.
   If both the G bit and U bit are set, configuration gives precedence
   to the G bit.

   Operation mode (A): if set, it configures BFD in the associated mode.
   If it is not set it configures BFD in independent mode.

   Reserved: Reserved for future specification and set to 0.

   The "BFD Configuration sub-TLV" MUST include the following sub-TLVs
   in the Mapping message:
   o  "Local Discriminator sub-TLV".
   o  "Negotiation Timer Parameters sub-TLV" if the N flag is cleared.

5.2.1.1.  Local Discriminator sub-TLV

   The "Local Discriminator sub-TLV" is carried as a sub-TLV of the "BFD
   Configuration sub-TLV" and is depicted 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Lcl. Discr. Type (1) (IANA)  |         Length (4)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Local Discriminator                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Local Discriminator sub-TLV

   Type: indicates a new type, the "Local Discriminator sub-TLV" (IANA
   to define, suggested value 1).

   Length: indicates the TLV total length in octets (4).

   Local Discriminator: A unique, nonzero discriminator value generated
   by the transmitting system and referring to itself, used to
   demultiplex multiple BFD sessions between the same pair of systems.

5.2.1.2.  Negotiation Timer Parameters sub-TLV

   The "Negotiation Timer Parameters sub-TLV" is carried as a sub-TLV of
   the "BFD Configuration sub-TLV" and is depicted below.








Zhang, et al.           Expires February 25, 2013              [Page 13]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Timer Neg.  Type (2) (IANA)  |          Length (16)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Acceptable Min. Asynchronous TX interval              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Acceptable Min. Asynchronous RX interval              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Required Echo TX Interval                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Negotiation Timer Parameters sub-TLV

   Type: indicates a new type, the "Negotiation Timer Parameters sub-
   TLV" (IANA to define, suggested value 2).

   Length: indicates the TLV total length in octets (16).

   Acceptable Min. Asynchronous TX interval: in case of S (symmetric)
   flag set in the "BFD Configuration" TLV, it expresses the desired
   time interval (in microseconds) at which the T-PE initiating the
   signaling intends to both transmit and receive BFD periodic control
   packets.  If the receiving T-PE can not support such value, it is
   allowed to reply back with an interval greater than the one proposed.

   In case of S (symmetric) flag cleared in the "BFD Configuration sub-
   TLV", this field expresses the desired time interval (in
   microseconds) at which T-PE intends to transmit BFD periodic control
   packets in its transmitting direction.

   Acceptable Min. Asynchronous RX interval: in case of S (symmetric)
   flag set in the "BFD Configuration sub-TLV", this field MUST be equal
   to "Acceptable Min. Asynchronous TX interval" and has no additional
   meaning respect to the one described for "Acceptable Min.Asynchronous
   TX interval".

   In case of S (symmetric) flag cleared in the "BFD Configuration sub-
   TLV", it expresses the minimum time interval (in microseconds) at
   which T-PE can receive BFD periodic control packets.  In case this
   value is greater than the "Acceptable Min. Asynchronous TX interval"
   received from the other T-PE, such T-PE MUST adopt the interval
   expressed in this "Acceptable Min. Asynchronous RX interval".

   Required Echo TX Interval: the minimum interval (in microseconds)
   between received BFD Echo packets that this system is capable of
   supporting, less any jitter applied by the sender as described in
   [RFC5880] sect. 6.8.9.  This value is also an indication for the



Zhang, et al.           Expires February 25, 2013              [Page 14]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   receiving system of the minimum interval between transmitted BFD Echo
   packets.  If this value is zero, the transmitting system does not
   support the receipt of BFD Echo packets.  If the receiving system can
   not support this value a Notification MUST be generated with Status
   Code set to "Unsupported BFD TX Echo rate interval".  By default the
   value is set to 0.

5.2.1.3.  BFD Authentication sub-TLV

   The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD
   Configuration sub-TLV" and is depicted 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    BFD Auth. Type (3) (IANA)  |          Length = 8           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Auth Type   |  Auth Key ID  |         Reserved (0s)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        BFD Authentication sub-TLV

   Type: indicates a new type, the "BFD Authentication sub-TLV" (IANA to
   define, suggested value 3).

   Length: indicates the TLV total length in octets (8).

   Auth Type: indicates which type of authentication to use.  The same
   values as are defined in section 4.1 of [RFC5880] are used.

   Auth Key ID: indicates which authentication key or password
   (depending on Auth Type) should be used.  How the key exchange is
   performed is out of scope of this document.

   Reserved: Reserved for future specification and set to 0.

5.2.2.  Performance Monitoring sub-TLV

   If the "MPLS-TP PW OAM Configuration TLV" has either the L (Loss), D
   (Delay) flag set, the "Performance Monitoring sub-TLV" MUST be
   present.

   In case the values need to be different than the default ones the
   "MPLS-TP PW PM Loss sub-TLV, "MPLS-TP PW PM Delay sub-TLV" MAY be
   included:
   o  "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "MPLS-TP PW
      OAM Configuration TLV";




Zhang, et al.           Expires February 25, 2013              [Page 15]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   o  "MPLS-PW PM Dealy sub-TLV" if the D flag is set in the "MPLS-TP PW
      OAM Configuration TLV ".

   The "Performance Monitoring sub-TLV" depicted below is carried as a
   sub-TLV of the "MPLS-TP PW OAM Configuration TLV"

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Perf Monitoring Type (IANA)|          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|L|J|Y|K|C|            Reserved (set to all 0s)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           sub-TLVs                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Performance Monitoring sub-TLV

   o  D: Delay inferred/direct (0=INFERRED, 1=DIRECT)
   o  L: Loss inferred/direct (0=INFERRED, 1=DIRECT)
   o  J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE)
   o  Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE)
   o  K: Loopback (1=ACTIVE, 0=NOT ACTIVE)
   o  C: Combined (1=ACTIVE, 0=NOT ACTIVE)

5.2.2.1.  MPLS-TP PW PM Loss TLV

   The "MPLS-TP PW PM Loss sub-TLV" depicted below is carried as a sub-
   TLV of the "Performance Monitoring sub-TLV".

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PM Loss Type (1) (IANA)      |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OTF |T|B|                    RESERVED                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Measurement Interval                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Test Interval                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Loss Threshold                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        MPLS-TP PW PM Loss sub-TLV




Zhang, et al.           Expires February 25, 2013              [Page 16]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   Type: indicates a new type, the "MPLS-TP PW PM Loss sub-TLV" (IANA to
   define, suggested value 1).

   Length: indicates the length of the parameters in octets.

   OTF: Origin Timestamp Format of the Origin Timestamp field described
   in [RFC6374].  By default it is set to IEEE 1588 version 1.

   Configuration Flags, please refer to [RFC6374] for further details:
   o  T: Traffic-class-specific measurement indicator.  Set to 1 when
      the measurement operation is scoped to packets of a particular
      traffic class (DSCP value), and 0 otherwise.  When set to 1, the
      DS field of the message indicates the measured traffic class.  By
      default it is set to 1.
   o  B: Octet (byte) count.  When set to 1, indicates that the Counter
      1-4 fields represent octet counts.  When set to 0, indicates that
      the Counter 1-4 fields represent packet counts.  By default it is
      set to 0.

   Measurement Interval: the time interval (in microseconds) at which LM
   query messages MUST be sent on both directions.  If the T-PE
   receiving the Mapping message can not support such value, it can
   reply back with a higher interval.  By default it is set to (TBD).

   Test Interval: test messages interval as described in [RFC6374].  By
   default it is set to (TBD).

   Loss Threshold: the threshold value of lost packets over which
   protections MUST be triggered.  By default it is set to (TBD).

5.2.2.2.  MPLS-TP PW PM Delay TLV

   The "MPLS-TP PW PM Delay sub-TLV" depicted below is carried as a sub-
   TLV of the "MPLS-TP PW OAM Configuration TLV"

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PM Delay Type (2) (IANA)      |          Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | OTF |T|B|                    RESERVED                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Measurement Interval                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Test Interval                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Delay Threshold                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Zhang, et al.           Expires February 25, 2013              [Page 17]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


                        MPLS-TP PW PM Delay sub-TLV

   Type: indicates a new type, the "MPLS-TP PW PM Delay sub-TLV" (IANA
   to define, suggested value 2).

   Length: indicates the length of the parameters in octets.

   OTF: Origin Timestamp Format of the Origin Timestamp field described
   in [RFC6374].  By default it is set to IEEE 1588 version 1.

   Configuration Flags, please refer to [RFC6374] for further details:
   o  T: Traffic-class-specific measurement indicator.  Set to 1 when
      the measurement operation is scoped to packets of a particular
      traffic class (DSCP value), and 0 otherwise.  When set to 1, the
      DS field of the message indicates the measured traffic class.  By
      default it is set to 1.
   o  B: Octet (byte) count.  When set to 1, indicates that the Counter
      1-4 fields represent octet counts.  When set to 0, indicates that
      the Counter 1-4 fields represent packet counts.  By default it is
      set to 0.

   Measurement Interval: the time interval (in microseconds) at which LM
   query messages MUST be sent on both directions.  If the T-PE
   receiving the Mapping message can not support such value, it can
   reply back with a higher interval.  By default it is set to (TBD).

   Test Interval: test messages interval as described in [RFC6374].  By
   default it is set to (TBD).

   Delay Threshold: the threshold value of packet delay time over which
   protections MUST be triggered.  By default it is set to (TBD).

5.2.3.  MPLS-TP PW FMS TLV

   The "MPLS-TP PW FMS sub-TLV" depicted below is carried as a sub-TLV
   of the "MPLS-TP PW OAM Configuration TLV".

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Fault mgmt Type (4) (IANA)    |        Length (8)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|D|L|                  Reserved (set to all 0s)       |E| PHB |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Refresh Timer                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          MPLS-TP PW FMS sub-TLV



Zhang, et al.           Expires February 25, 2013              [Page 18]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   Type: indicates a new type, the "MPLS-TP PW FMS sub-TLV" (IANA to
   define, suggested value 4).

   Length: indicates the length of the parameters in octets (8).

   Signal Flags: are used to enable the following signals:
   o  A: Alarm Indication Signal (AIS) as described in [RFC6428]
   o  D: Link Down Indication (LDI) as described in [RFC6428]
   o  L: Locked Report (LKR) as described in [RFC6428]
   o  Remaining bits: Reserved for future specification and set to 0.

   Configuration Flags:
   o  E: used to enable/disable explicitly clearing faults
   o  PHB: identifies the per-hop behavior of packets with fault
      management information

   Refresh Timer: indicates the refresh timer (in microseconds) of fault
   indication messages.  If the T-PE receiving the Path message can not
   support such value, it can reply back with a higher interval.


6.  IANA Considerations

   This document specifies the following new LDP TLV types:
   o  MPLS-TP PW OAM Administration TLV;
   o  MPLS-TP PW OAM Configuration TLV;

   Sub-TLV types to be carried in the "MPLS-TP PW OAM Configuration
   TLV":
   o  BFD Configuration sub-TLV;
   o  Performance Monitoring sub-TLV
   o  MPLS-TP PW FMS sub-TLV;

   Sub-TLV types to be carried in the "BFD Configuration sub-TLV":
   o  Local Discriminator sub-TLV;
   o  Negotiation Timer Parameters sub-TLV.
   o  BFD Authentication sub-TLV

   Sub-TLV types to be carried in the "Performance Monitoring sub-TLV":
   o  MPLS-TP PW PM Loss sub-TLV;
   o  MPLS-TP PW PM Loss sub-TLV.

6.1.   OAM Configuration Errors

   This document defines several new LDP status codes, IANA already
   maintains the registry "STATUS CODE NAME SPACE" defined by [RFC5036].
   The following values are required to be assigned:




Zhang, et al.           Expires February 25, 2013              [Page 19]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   Range/Value   E    Description
   0x0000003C    0    "MIP Configuration Failure"
   0x0000003D    0    "Rejected MPLS-TP PW OAM Configuration TLV"
   0x0000003E    0    "Wrong MPLS-TP PW OAM Configuration TLV"
   0x0000003F    0    "Unsupported OAM Version"
   0x0000004A    0    "Unsupported BFD TX Echo rate interval"



7.  Security Considerations

   Security considerations relating to LDP are described in section 5 of
   [RFC5036] and section 11 of [RFC5561].  Security considerations
   relating to use of LDP in setting up PWs is described in section 8 of
   [RFC4447].

   This document defines new TLV/sub-TLV types, and OAM configuration
   procedures intended for use with MPLS-TP, which do not raise any
   additional security issues.


8.  Acknowledgement

   The authors would like to thank Andew Malis, Greg Mirsky, Luca
   Martini, Matthew Bocci, Thomas Nadeau for their valuable comments and
   discussions, especially would like to thank Eric Gray for his review
   of this document.


9.  References

9.1.  Normative references

   [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf]
              Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D.,
              and J. Drake, "Configuration of Pro-Active Operations,
              Administration, and Maintenance (OAM) Functions for MPLS-
              based Transport Networks using LSP Ping",
              draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-04 (work in
              progress), April 2012.

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

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.




Zhang, et al.           Expires February 25, 2013              [Page 20]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
              Operations, Administration, and Maintenance (OAM) in MPLS
              Transport Networks", RFC 5860, May 2010.

   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

9.2.  Informative References

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

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

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
              October 2009.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
              Maintenance Framework for MPLS-Based Transport Networks",
              RFC 6371, September 2011.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

   [RFC6375]  Frost, D. and S. Bryant, "A Packet Loss and Delay
              Measurement Profile for MPLS-Based Transport Networks",
              RFC 6375, September 2011.

   [RFC6428]  Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
              Connectivity Verification, Continuity Check, and Remote
              Defect Indication for the MPLS Transport Profile",
              RFC 6428, November 2011.

   [RFC6669]  Sprecher, N. and L. Fang, "An Overview of the Operations,
              Administration, and Maintenance (OAM) Toolset for MPLS-
              Based Transport Networks", RFC 6669, July 2012.



Zhang, et al.           Expires February 25, 2013              [Page 21]

Internet-Draft        LDP Extensions for TP PW OAM           August 2012


Authors' Addresses

   Fei Zhang (editor)
   ZTE Corporation

   Email: zhang.fei3@zte.com.cn


   Bo Wu (editor)
   ZTE Corporation

   Email: wu.bo@zte.com.cn


   Elisa Bellagamba (editor)
   Ericsson
   Farogatan 6
   Kista, 164 40
   Sweden

   Phone: +46 761440785
   Email: elisa.bellagamba@ericsson.com


   Attila Takacs
   Ericsson
   Laborc u. 1.
   Budapest, 1037
   Hungary

   Email: attila.takacs@ericsson.com


   Xuehui Dai
   ZTE Corporation

   Email: dai.xuehui@zte.com.cn


   Min Xiao
   ZTE Corporation

   Email: xiao.min2@zte.com.cn








Zhang, et al.           Expires February 25, 2013              [Page 22]