Internet DRAFT - draft-ietf-pals-mpls-tp-oam-config

draft-ietf-pals-mpls-tp-oam-config







Network Working Group                                      F. Zhang, Ed.
Internet-Draft                                                    Huawei
Intended status: Standards Track                              B. Wu, Ed.
Expires: January 21, 2016                                ZTE Corporation
                                                      E. Bellagamba, Ed.
                                                                Ericsson
                                                            M. Chen, Ed.
                                                                  Huawei
                                                           July 20, 2015


LDP Extensions for Proactive Operations, Administration and Maintenance
       Configuration of Dynamic MPLS Transport Profile PseudoWire
                 draft-ietf-pals-mpls-tp-oam-config-03

Abstract

   This document defines extensions to LDP to configure proactive OAM
   functions for both SS-PW and MS-PW when the PW control plane is used.

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 January 21, 2016.

Copyright Notice

   Copyright (c) 2015 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 January 21, 2016                [Page 1]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  PW OAM Configuration  . . . . . . . . . . . . . . . . . . . .   5
     3.1.  OAM Configuration for SS-PW . . . . . . . . . . . . . . .   5
       3.1.1.  Establishment of OAM Entities and Functions . . . . .   5
       3.1.2.  Adjustment of OAM Parameters  . . . . . . . . . . . .   7
       3.1.3.  Deleting OAM Entities . . . . . . . . . . . . . . . .   8
     3.2.  OAM Configuration for MS-PW . . . . . . . . . . . . . . .   8
       3.2.1.  Establishment of OAM Entities and Functions . . . . .   9
       3.2.2.  Adjustment of OAM Parameters  . . . . . . . . . . . .  10
       3.2.3.  Deleting OAM Entities . . . . . . . . . . . . . . . .  12
   4.  LDP Extensions  . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  PW OAM Administration TLV . . . . . . . . . . . . . . . .  12
     4.2.  PW OAM Functions TLV  . . . . . . . . . . . . . . . . . .  13
       4.2.1.  BFD Configuration sub-TLV . . . . . . . . . . . . . .  15
         4.2.1.1.  Local Discriminator sub-TLV . . . . . . . . . . .  16
         4.2.1.2.  Negotiation Timer Parameters sub-TLV  . . . . . .  17
         4.2.1.3.  BFD Authentication sub-TLV  . . . . . . . . . . .  18
         4.2.1.4.  Traffic Class Sub-TLV . . . . . . . . . . . . . .  19
       4.2.2.  Performance Monitoring sub-TLV  . . . . . . . . . . .  20
         4.2.2.1.  PM Loss Sub-TLV . . . . . . . . . . . . . . . . .  21
         4.2.2.2.  PM Delay Sub-TLV  . . . . . . . . . . . . . . . .  23
       4.2.3.  Fault Management Signal Sub-TLV . . . . . . . . . . .  24
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     5.1.  TLVs  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
       5.1.1.  PW OAM Configuration Sub-TLV  . . . . . . . . . . . .  26
         5.1.1.1.  BFD Configuration sub-TLVs  . . . . . . . . . . .  26
         5.1.1.2.  Performance Monitoring sub-TLVs . . . . . . . . .  26
     5.2.  OAM Configuration Status Code . . . . . . . . . . . . . .  26
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  28
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     8.1.  Normative references  . . . . . . . . . . . . . . . . . .  28
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   There are two documents that define MultiProtocol Label Switching
   (MPLS) Pseudowire (PW).  [RFC3985] defines Single Segment PW (SS-PW)
   and [RFC5659] defines Multi-Segment PW (MS-PW).  The two documents



Zhang, et al.           Expires January 21, 2016                [Page 2]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   explain how to provide emulated services over an MPLS Packet Switched
   Network (PSN).  The MPLS Transport Profile (MPLS-TP) is described in
   [RFC5291], which describes a profile of MPLS that introduces the
   operational models that were typically used in transport networks,
   while providing additional Operations, Administration and Maintenance
   (OAM), survivability and other maintenance functions that were not
   previously supported by IP/MPLS network.  The MPLS-TP requirements
   are defined in [RFC5860].

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

   When a control plane is not used the OAM functions are typically
   configured from the Network Management System (NMS).  When a control
   plane is used, requirement 51 in [RFC5654] requires that it MUST be
   able to support configuration of the OAM functions.  The control
   plane is also required to be able to configure, maintain and modify,
   as well as activation/deactivation of maintenance points.

   For MPLS-TP OAM configuration, two companion documents exists.
   [RFC7260] and [RFC7487] define extensions to Resource Reservation
   Protocol - Traffic Engineering (RSVP-TE) to support the establishment
   and configuration of OAM entities along with Label Switched Path
   (LSP) signaling.  [I-D.ietf-mpls-lsp-ping-mpls-tp-oam-conf] defines
   extensions to LSP Ping [RFC4379] to support the configuration of
   proactive MPLS-TP OAM functions.

   This document defines extensions to the Label Distribution Protocol
   (LDP) to configure proactive MPLS-TP PW OAM functions for both Point
   to Point SS-PW and MS-PW when the PW control plane is used.  The
   extensions defined in this document are aligned with those companion
   documents.  Extensions to Point to Multi-Point (P2MP) PW are for
   future study and outside the scope of this document.

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






Zhang, et al.           Expires January 21, 2016                [Page 3]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


2.1.  Acronyms

      AIS: Alarm indication signal

      BFD: Bidirectional Forwarding Detection

      CC: Continuity Check

      CV: Connectivity Verification

      DM: Delay Measurement

      FEC: Forwarding Equivalence Class

      FMS: Fault Management Signal

      G-ACh: Generic Associated Channel

      LDI: Link Down Indication

      LDP: Label Distribution Protocol

      LM: Loss Measurement

      LSP: Label Switched Path

      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, Administration and Maintenance

      P2MP: Point to Multi-Point

      PE: Provider Edge

      PHB: Per-Hop Behavior

      PM: Performance Monitoring

      PSN: Packet Switched Network




Zhang, et al.           Expires January 21, 2016                [Page 4]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


      PW: Pseudowire

      S-PE: Switching Provider Edge

      SS-PW: Single-Segment Pseudo Wire

      T-PE: Terminating Provider Edge

      TLV: Type Length Value

3.  PW OAM Configuration

   This document defines two new TLVs, the PW OAM Administration TLV and
   the PW OAM Functions TLV.

   The PW OAM Administrations TLV is used to setup/remove MIP and MEP
   functions and to control whether OAM alarm function should be
   suppressed or not.

   The PW OAM Functions TLV is used to configure, enable and disable OAM
   functions that include Continuity Check (CC), Connectivity
   Verification (CV), Packet Loss/Delay/Throught and PM and Fault
   Management Signal(FMS).  More details about the new TLVs can be found
   in Section 4.

3.1.  OAM Configuration for SS-PW

3.1.1.  Establishment of OAM Entities and Functions

   OAM entities and functions can be setup, configured and activated
   either when the PW first is signalled or on an already established
   PW.  This section describes how the OAM entities and functions are
   setup and configured with the signalling of a PW.

   For the case where OAM entities and functions are setup and
   configured after establishment of a PW, the procedures are identical
   to the "adjustment of OAM parameters" procedures, more detail can be
   found in Section 3.1.2.

   Given that a SS-PW needs to be setup between PE1 and PE2 (see
   Figure 1) . OAM functions MUST be setup and enabled in the
   appropriate order so that spurious alarms can be avoided.









Zhang, et al.           Expires January 21, 2016                [Page 5]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


            +-------+               +-------+
            |       |               |       |
            |       |---------------|       |
            |       |               |       |
            +-------+               +-------+
               PE1                     PE2

          Figure 1 SS-PW OAM Configuration Scheme

                 Figure 1: SS-PW OAM Configuration Scheme

   Fist, the ingress PE (e.g., PE1) must setup the OAM sink function and
   prepare to receive OAM messages.  Until the PW is fully established,
   any OAM alarm SHOULD be suppressed.

   To achieve this, a Label Mapping message with the "OAM Alarms
   Enabled" flag cleared is sent.  In the message, the "OAM MEP Entities
   Desired" flag is set.  Since there is no MIPs for a SS-PW, the "OAM
   MIP Entities desired" flag MUST be cleared.  In addition, to
   configure and enable particular OAM functions, the PW OAM Functions
   TLV and relevant sub-TLVs MUST be included.

   When the Label Mapping message is received by PE2, PE2 needs to check
   whether it supports the requested OAM configuration.  If it does not
   support the requested OAM configuration, a Label Release message MUST
   be returned to PE1, with a Status Code set to "PW OAM Parameters
   Rejected".  The PW signalling is complete and the PW will not be
   established.  If the requested OAM parameters and configuration are
   supported, PE2 will establish and configure the requested OAM
   entities.

   If PE2 fails to establish and configure the OAM entities, a Label
   Release message will be returned to PE1, with a Status Code set to
   "PW MEP Configuration Failed".  The PW signalling is complete and the
   PW will not be established.

   If the OAM entities are setup and configured successfully, the OAM
   sink and source functions is setup and the OAM sink function will be
   configured to receive OAM messages.

   Since the OAM alarm is disabled, no alarms will be generated.  The
   OAM source function can start to send OAM messages.  PE2 will then
   reply a Label Mapping message to PE1, the PW OAM Administration TLV
   and PW OAM Configuration TLV from the received Label Mapping message
   MUST be copied and carried in the Label Mapping message.






Zhang, et al.           Expires January 21, 2016                [Page 6]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   When PE1 receives this Label Mapping message, PE1 completes any
   pending OAM configuration and enables the OAM source function to send
   OAM messages.

   For PE1, the OAM entities and functions are now setup and configured,
   and OAM messages may be exchanged.  The OAM alarms can be safely
   enabled.  The initiator PE (PE1) will send another Label Mapping
   message with "OAM Alarms Enabled" flag set to PE2, this will allow
   PE2 to enable the OAM alarm function.

   When the Label Mapping message is received by PE2, the OAM alarm will
   be enabled.  PE2 then sends a Notification message with the Status
   Code set to "PW OAM Alarms enabled" to PE1.

   When the Notification message is received by PE1, PE1 enables the OAM
   alarm function.  At this point, data-plane OAM is fully functional.

3.1.2.  Adjustment of OAM Parameters

   Existing OAM parameters may be changed during the life time of a PW.
   To achieve this, PE1 sends a Label Mapping message with the updated
   OAM parameters to PE2.

   To avoid spurious alarms, it is important that OAM sink and source
   functions on both PEs are updated in a synchronized way.  First, the
   alarms of the OAM sink function should be suppressed.  After that,
   new OAM parameters can be adjusted.  Subsequently, the parameters of
   the OAM source function can be updated.  Finally, the alarms can be
   enabled again.

   Consequently, the ingress PE needs to keep its OAM sink and source
   functions running without any changes until the OAM parameters are
   updated.  However, in order to suppress spurious alarms, it also need
   to disable the alarm functions before the Label Mapping message, with
   the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function
   TLV, is sent.  The OAM alarm function needs to be disabled until the
   corresponding response message is received.

   On receipt of the Label Mapping message, PE2 needs to check whether
   the updated parameters can be supported.  If they can be supported,
   PE2 needs first disable the OAM alarms firstly and then update the
   OAM parameters.  When the update is done, a Notification message
   needs to be sent to PE1, with the Status Code set to "PW MEP
   Configuration Succeed", to acknowledge the update.  If PE2 can not
   support the update, a Notification message with Status Code set to
   "PW OAM Parameters Rejected" will be sent to PE1.





Zhang, et al.           Expires January 21, 2016                [Page 7]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   When PE1 receives the Notification message with the Status Code set
   to "PW MEP Configuration Succeed", PE1 will update using the new OAM
   parameters.  After the OAM parameters are updated and the OAM is
   running with the new parameter settings, OAM alarms are still
   disabled.  A subsequent Label Mapping message with "OAM Alarms
   Enabled" flag set will be sent to re-enable OAM alarms.  If the
   Status Code of the received Notification message is "PW OAM
   Parameters Rejected", it will not update the OAM parameters.  The OAM
   alarms are just enabled again and the OAM will keep running with the
   old parameters.  PE1 can also re-try changing the OAM parameters
   using a different set of parameters.

   When PE2 received the Label Mapping message with "OAM Alarms Enabled"
   flag set, it will enable the OAM alarms and reply a Notification
   message with Status Code set to "PW OAM Alarms Enabled".  When
   received the Notification message, PE1 will enable the OAM alarms
   again.

3.1.3.  Deleting OAM Entities

   In some cases it may be useful to remove all OAM entities and
   functions from a PW without actually tearing down the connection.
   The deleting procedures are defined as below:

   First, the ingress PE (e.g., PE1) disables its own the OAM alarms and
   then sends a Label Mapping message to the remote PE (e.g., PE2) with
   the "OAM Alarms Enabled" flag set but with all other OAM
   configurations unchanged.

   When received the Label Mapping message, PE2 disables the OAM alarm
   and then send a Notification message with Status Code set to "PW OAM
   Alarms Disabled" to PE1.

   When received the confirmation from PE2, it's safe to delete the OAM
   entities.  PE1 will delete the OAM entities related to the PW and
   send another Label Mapping message with the "OAM MEP Entities
   desired" flag cleared to PE2.

   When PE2 received the Label Mapping message, it will delete all OAM
   entities related to the PW and then reply a Notification message with
   the Status Code set to "PW MEP Entities Disabled" to PE1.

3.2.  OAM Configuration for MS-PW








Zhang, et al.           Expires January 21, 2016                [Page 8]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


3.2.1.  Establishment of OAM Entities and Functions

   Given that a MS-PW needs to be setup between T-PE1 and T-PE2, across
   S-PE1 and S-PE2 (see Figure 2) . 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 2 MS-PW Scenario

                 Figure 2: MS-PW OAM Configuration Scheme

   Fist, T-PE1 must setup the OAM sink function and prepare to receive
   OAM messages.  Until the PW is fully established, any OAM alarm
   SHOULD be suppressed.

   To achieve this, a Label Mapping message with the "OAM Alarms
   Enabled" flag cleared is sent.  If the S-PEs are expected to setup
   and configure the MIP entities, the "OAM MIP Entities desired" flag
   MUST be set.  In the message, the "OAM MEP Entities Desired" flag is
   set.  In addition, to configure and enable particular OAM functions,
   the PW OAM Functions TLV and relevant sub-TLVs MUST be included.

   On receipt of the Label Mapping message, S-PE(e.g., S-PE1) needs to
   check whether it supports MIP function.  If S-PE1 does not support
   MIP function, a Notification message will be sent to T-PE1, with the
   Status Code set to "PW MIP Configuration Failed".  If S-PE1 supports
   MIP function, it will establish and configure the MIP entities
   according to the "OAM MIP Entities desired" flag in the PW OAM
   Administration TLV.  No matter whether S-PE1 supports MIP function,
   it will relay the Label Mapping message downstream to the next S-PE.
   All the subsequent S-PEs along the PW will perform the same
   operations as S-PE1 does until the Label Mapping message reaches the
   remote T-PE (T-PE2).

   When the Label Mapping message is received by the remote T-PE
   (T-PE2), T-PE2 needs to check whether it support the requested OAM
   configuration.  If it does not support the requested OAM
   configuration, a Label Release message MUST be returned to its
   upstream PE, with a Status Code set to "PW MEP Configuration Failed".
   The signalling is complete and the PW will not be established.  If




Zhang, et al.           Expires January 21, 2016                [Page 9]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   the requested OAM parameters and configuration are supported, T-PE2
   will establish and configure requested OAM entities.

   If T-PE2 fails to establish and configure the OAM entities, a Label
   Release message MUST be replied to its upstream PE, with a Status
   Code set to "PW MEP Configuration Failed".  The signalling is
   complete and the PW will not be established.

   If the OAM entities established and configured successfully, the OAM
   sink and source functions are setup and the OAM sink function will be
   configured to receive OAM messages.  Since the OAM alarm is disabled,
   no alarms will be generated.  The OAM source function can start to
   send OAM messages.  T-PE2 will then reply a Label Mapping message,
   the PW OAM Administration TLV and PW OAM Function TLV from the
   received Label Mapping message MUST be copied and carried in the
   returned Label Mapping message.

   S-PEs will relay the Label Mapping message upstream until it reaches
   T-PE1.  When the Label Mapping message is received by T-PE1, T-PE1
   will complete any pending OAM configuration and enables the OAM
   source function to send OAM messages.

   For T-PE1, the OAM entities and functions are now setup and
   configured, and OAM messages may be exchanged.  The OAM alarms can be
   safely enabled.  T-PE1 will send another Label Mapping message with
   "OAM Alarms Enabled" flag set to enable the OAM alarm function.

   When the Label Mapping message is received by S-PEs, S-PEs will
   enable the OAM alarm and relay the Label Mapping message downstream
   until it reaches T-PE2.

   When the Label Mapping message is received by T-PE2, the OAM alarm
   will be enabled.  T-PE2 then sends a Notification message to T-PE1,
   with the Status Code set to "PW OAM Alarms Enabled".  Once the
   Notification message is received by T-PE1, T-PE1 enables the OAM
   alarm function.  At this point, data-plane OAM is fully functional.

3.2.2.  Adjustment of OAM Parameters

   Existing OAM parameters may be changed during the life time of a PW.
   To achieve this, the T-PE1 needs to send a Label Mapping message with
   the updated OAM parameters to adjust and update OAM parameters.

   To avoid spurious alarms, it is important that OAM sink and source
   functions on both sides are updated in a synchronized way.  Fist, the
   alarms of the OAM sink function should be suppressed.  After that,
   new OAM parameters can be adjusted.  Subsequently, the parameters of




Zhang, et al.           Expires January 21, 2016               [Page 10]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   the OAM source function can be updated.  Finally, the alarms can be
   enabled again.

   Consequently, T-PE1 needs to keep its OAM sink and source functions
   running without any changes until the OAM parameters are updated.
   However, in order to suppress spurious alarms, it also need to
   disable the alarm functions before the Label Mapping message, with
   the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function
   TLV, is sent.  The OAM alarm function needs to be disabled until the
   corresponding response message is received.

   When the Label Mapping message is received by S-PEs, each S-PE just
   disables the OAM alarm and relay the Label Mapping message downstream
   until the Label Mapping message reaches the remote T-PE (T-PE2).

   On receipt of the Label Mapping message, T-PE2 needs to check whether
   the updated parameters can be supported.  If they can be supported,
   T-PE2 needs first disable the OAM alarms and then update the OAM
   parameters.  When the update is done, a Notification message needs to
   be sent to T-PE1, with the Status Code set to "PW MEP Configuration
   Succeed", to acknowledge the update.  If T-PE2 can not support the
   update, a Notification message with Status Code set to "PW OAM
   Parameters Rejected" will be sent T-PE1.

   When T-PE1 receives the Notification message with the Status Code set
   to "PW MEP Configuration Succeed", T-PE1 will update using the new
   OAM parameters.  After the OAM parameters are updated and the OAM is
   running with the new parameter settings, OAM alarms are still
   disabled.  A subsequent Label Mapping message with "OAM Alarms
   Enabled" flag set will be sent to re-enable OAM alarms.  If the
   Status Code of the received Notification message is "PW OAM
   Parameters Rejected", it will not update the OAM parameters.  The OAM
   alarms are just enabled again and the OAM will keep running with the
   old parameters.  T-PE1 can also re-try changing the OAM parameters
   using a different set of parameters.

   When S-PEs receives the Label Mapping message, they will enable the
   OAM alarms and relay the Label Mapping message downstream.

   When T-PE2 receives the Label Mapping message with the "OAM Alarms
   Enabled" flag set, it will enable the OAM alarms and reply a
   Notification message with Status Code set to "PW OAM Alarms Enabled".
   When received the Notification message, T-PE1 will enable the OAM
   alarms again.







Zhang, et al.           Expires January 21, 2016               [Page 11]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


3.2.3.  Deleting OAM Entities

   In some cases it may be useful to remove all OAM entities and
   functions from a PW without actually tearing down the connection.
   The deleting procedures are defined as below:

   First, T-PE1disables its own the OAM alarms and then sends a Label
   Mapping message to the remote PE (e.g., T-PE2) with the "OAM Alarms
   Enabled" flag cleared but with all other OAM configurations
   unchanged.

   When received the Label Mapping message, S-PEs will disable the OAM
   alarm and relay the Mapping message downstream until the Label
   Mapping message reaches the remote T-PE (T-PE2).

   When received the Label Mapping message, T-PE2 will disable the OAM
   alarm and then reply a Notification message with Status Code set to
   "PW OAM Alarms Disabled" to T-PE1.

   When received the confirmation from T-PE2, it's safe to delete the
   OAM entities.  T-PE1 will delete the all OAM entities associated with
   the PW and send another Label Mapping message with both the "OAM MEP
   Entities desired" and "OAM MIP Entities desired" flags cleared to the
   remote T-PE.

   When received the Label Mapping message, S-PE (e.g., S-PE1) will
   delete all the OAM entities associated with the PW and relay the
   Label Mapping message downstream.  Subsequent S-PEs will do the same
   operations until the Label Mapping message reaches the remote T-PE.

   When T-PE2 receives the Label Mapping message, it will delete all OAM
   entities associated with the PW and then reply a Notification message
   with the Status Code set to "PW MEP Entities Disabled" to T-PE1.

4.  LDP Extensions

4.1.  PW OAM Administration TLV

   The PW OAM Administration TLV is used to configure and enable the
   MEP, MIP and Alarm functions.  It can be sent with the Label Mapping
   message.  The format of the TLV is as follows:










Zhang, et al.           Expires January 21, 2016               [Page 12]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


         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          |           Length(=4)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                OAM Administration Flags                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         PW OAM Administration TLV

   The PW OAM Administration TLV type is TBD1.

   The Length field is 2 octets in length.  It defines the length in
   octets of OAM Administration Flags filed, it's value is 4.

   The OAM Administration Flags is a bitmap with the length of 4 octets.

   This document defines the following flags:

    OAM Administration Flags bit#      Description
    -----------------------------      --------------------------------
    0                                  OAM MIP Entities Desired
    1                                  OAM MEP Entities Desired
    2                                  OAM Alarms Enabled
    3-31                               Reserved


   The "OAM MIP Entities Desired" flag is used to direct the S-PE(s)
   along a PW to establish (when set) or delete (when cleared ) the OAM
   MIP entities.  This flag only applies to MS-PW scenario.  For SS-PW
   case, this flag MUST be cleared when sent, and SHOULD be ignored when
   received.

   The "OAM MEP Entities Desired" flag is used to request the remote
   T-PE to establish (when set) or delete (when cleared) the OAM
   entities.

   The "OAM Alarms Enabled" flag is used to request the received PEs to
   enable (when set) or disable (when cleared) OAM alarms function.

   Reserved (3-31 bits): MUST be set to zero on transmission and SHOULD
   be ignored on receipt.

4.2.  PW OAM Functions TLV

   The PW OAM Functions TLV is defined to configure and enable specific
   OAM functions, it is carried in Label Mapping message when used.  The
   format of the TLV is as follows:



Zhang, et al.           Expires January 21, 2016               [Page 13]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


     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            |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      OAM Function Flags                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           sub-TLVs                            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           PW OAM Functions TLV

   The PW OAM Functions TLV contains a number of flags indicating which
   OAM functions should be activated and OAM function specific sub-TLVs
   with configuration parameters for particular functions.

   The PW OAM Functions TLV type is TBD2.

   The Length field is 2 octets in length.  It defines the length in
   octets of OAM Function Flags and sub-TLVs fields.

   The OAM Function Flags is a bitmap with the length of 4 octets.

   This document defines the following flags:

      OAM Function Flags bit#             Description
      ---------------------      ---------------------------
      0                          Continuity Check (CC)
      1                          Connectivity Verification (CV)
      2                          Fault Management Signals (FMS)
      3                          Performance Monitoring (PM) Loss
      4                          Performance Monitoring (PM) Delay
      5                          Performance Monitoring (PM) Throughput
      6-31                       Reserved

   The sub-TLVs corresponding to the different OAM function flags are as
   follows.

   o  BFD Configuration sub-TLV 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 as well.

   o  Performance Monitoring sub-TLV MUST be included if the PM Loss/
      Delay OAM Function flag is set.

   o  Fault Management Signal (FMS) sub-TLV MAY be included if the FMS
      OAM Function flag is set.  If the Fault Management Signal sub-TLV
      is not included, the default configuration values are used.



Zhang, et al.           Expires January 21, 2016               [Page 14]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


4.2.1.  BFD Configuration sub-TLV

   The BFD Configuration Sub-TLV (depicted below) is defined for BFD-
   OAM-specific configuration parameters.  The BFD Configuration Sub-TLV
   is carried as a sub-TLV of the PW OAM Functions TLV.

   This sub-TLV 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)       |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Vers.|N|S|I|G|U|B|       Reserved (set to all 0s)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           sub-TLVs                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         BFD Configuration sub-TLV

   Type: indicates a new type, the BFD Configuration Sub-TLV (suggested
   value 1).

   Length: Indicates the length of the Value field in octets.

   Version: Identifies the BFD protocol version.  If the egress LSR does
   not support the version, a Notification message MUST be generated,
   with the Status Code set to "OAM Problem/ Unsupported BFD Version".

   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).  If the egress LSR does not support BFD Authentication,
   an Notification message MUST be generated, with Status Code set to
   "OAM Problem/BFD Authentication unsupported".

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



Zhang, et al.           Expires January 21, 2016               [Page 15]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   the egress LSR does not support any of the ingress LSR Encapsulation
   Capabilities, an Notification message MUST be generated, with the
   Status Code set to "OAM Problem/Unsupported BFD Encapsulation
   format".

   Encapsulation Capability (U): If set, it shows the capability of
   encapsulating BFD messages into UDP packets.  If both the G bit and U
   bit are set, configuration gives precedence to the G bit.  If the
   egress LSR does not support any of the ingress LSR Encapsulation
   Capabilities, a Notification message MUST be generated, with the
   Status Code set to "OAM Problem/Unsupported BFD Encapsulation
   Format".

   Bidirectional (B): If set, it configures BFD in the Bidirectional
   mode.  If it is not set, it configures BFD in unidirectional mode.
   In the second case, the source node does not expect any Discriminator
   values back from the destination node.

   Reserved: Reserved for future specifications; set to 0 on
   transmission and ignored when received.

   The BFD Configuration Sub-TLV MUST include the following sub-TLVs in
   the Label Mapping message:

   o  BFD Identifiers Sub-TLV; and

   o  Negotiation Timer Parameters Sub-TLV if the N flag is cleared.

   The BFD Configuration Sub-TLV MUST include the following sub-TLVs in
   the "response" Label Mapping message:

   o  BFD Identifiers Sub-TLV; and

   o  Negotiation Timer Parameters Sub-TLV if:

      *  the N and S flags are cleared; or if

      *  the N flag is cleared and the S flag is set and the Negotiation
         Timer Parameters Sub-TLV received by the egress contains
         unsupported values.  In this case, an updated Negotiation Timer
         Parameters Sub-TLV containing values supported by the egress
         LSR MUST be returned to the ingress.

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




Zhang, et al.           Expires January 21, 2016               [Page 16]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


       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
   (suggested value 1).

   Length: indicates the length of the Value field 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.

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

       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
   (suggested value 2).

   Length: indicates the length of the Value field in octets (12).

   Acceptable Min. Asynchronous TX interval: in case of S (symmetric)
   flag set in the BFD Configuration sub-TLV, defined in Section 4.2.1,
   it expresses the desired time interval (in microseconds) at which the
   ingress PE intends to both transmit and receive BFD periodic control




Zhang, et al.           Expires January 21, 2016               [Page 17]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   packets.  If the receiving PE cannot support such value, it SHOULD
   reply 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-PEs can receive BFD periodic control packets.  In case this
   value is greater than the value of Acceptable Min.  Asynchronous TX
   interval received from the other edge LSR, 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
   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
   cannot support this value, a Notification message MUST be generated,
   with the Status Code set to "Unsupported BFD TX Echo rate interval".
   By default the value is set to 0.

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





Zhang, et al.           Expires January 21, 2016               [Page 18]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


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

   Length: indicates the length of the Value field in octets (4).

   Auth Type: indicates which type of authentication to use.  The same
   values as are defined in section 4.1 of [RFC5880] are used.  If the
   egress PE does not support this type, an Notification message MUST be
   generated, with the Status Code set to "OAM Problem/Unsupported BFD
   Authentication Type".

   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.  If the egress PE does
   not support this Auth Key ID, a Notification message MUST be
   generated, with the Status Code set to "OAM Problem/Mismatch of BFD
   Authentication Key ID".

   Reserved: Reserved for future specification and set to 0 on
   transmission and ignored when received.

4.2.1.4.  Traffic Class Sub-TLV

   The Traffic Class sub-TLV is carried as a sub-TLV of the BFD
   Configuration sub-TLV or Fault Management Signal sub-TLV
   (Section 4.2.3) and is depicted as 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Traffic Class sub-Type (104)  |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TC |                 Reserved (set to all 0s)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: indicates a new type, the Traffic Class sub-TLV (suggested
   value 4).

   Length: Indicates the length of the Value field in octets (4).

   Traffic Class (TC): Identifies the TC [RFC5462] for periodic
   continuity monitoring messages or packets with fault management
   information.  If the Traffic Class sub-TLV is present, then the value
   of the TC field MUST be used as the value of the TC field of an MPLS
   label stack entry.  If the Traffic Class sub-TLV is absent from BFD
   Configuration sub-TLV or Fault Management Signal sub-TLV, then
   selection of the TC value is a local decision.




Zhang, et al.           Expires January 21, 2016               [Page 19]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


4.2.2.  Performance Monitoring sub-TLV

   If the PW OAM Functions TLV has either the L (Loss), D (Delay) or T
   (Throughput) flag set, the Performance Measurement sub-TLV MUST be
   present.  Failure to include the correct sub-TLVs MUST result in a
   Notification message (with the Status Code set to "OAM Problem/
   Configuration Error") being generated.  The Performance Measurement
   sub-TLV provides the configuration information mentioned in Section 7
   of [RFC6374].  It includes support for the configuration of quality
   thresholds and, as described in [RFC6374], "the crossing of which
   will trigger warnings or alarms, and result reporting and exception
   notification will be integrated into the system-wide network
   management and reporting framework."  In case the values need to be
   different than the default ones the Performance Measurement sub-TLV
   MAY include the following sub-TLVs:

   o  "MPLS-PW PM Loss sub-TLV" if the L flag is set in the "PW OAM
      Functions TLV";

   o  "MPLS-PW PM Delay sub-TLV" if the D flag is set in the "PW OAM
      Functions TLV ".

   The "Performance Monitoring sub-TLV" depicted below is carried as a
   sub-TLV of the "PW OAM Functions 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

   Sub-type: indicates a new sub-type, the Performance Management sub-
   TLV (suggested value 2).

   Length: indicates the length of the Value field in octets (4).
   Configuration Flags, for the specific function description please
   refer to [RFC6374]:

   o  D: Delay inferred/direct (0=INFERRED, 1=DIRECT).  If the egress
      LSR does not support specified mode, a Notification message MUST



Zhang, et al.           Expires January 21, 2016               [Page 20]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


      be generated, with the Status Code set to "OAM Problem/Unsupported
      Delay Mode".

   o  L: Loss inferred/direct (0=INFERRED, 1=DIRECT).  If the egress LSR
      does not support specified mode, a Notification message MUST be
      generated, with the Status Code set to "OAM Problem/Unsupported
      Loss Mode".

   o  J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE).  If the egress
      LSR does not support Delay variation measurements and the J flag
      is set, a Notification message MUST be generated, with the Status
      Code set to "OAM Problem/Delay variation unsupported".

   o  Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE).  If the egress LSR does not
      support Dyadic mode and the Y flag is set, a Notification message
      MUST be generated, with the Status Code set to "OAM Problem/Dyadic
      mode unsupported".

   o  K: Loopback (1=ACTIVE, 0=NOT ACTIVE).  If the egress LSR does not
      support Loopback mode and the K flag is set, a Notification
      message MUST be generated, with the Status Code set to "OAM
      Problem/ Loopback mode unsupported".

   o  C: Combined (1=ACTIVE, 0=NOT ACTIVE).  If the egress LSR does not
      support Combined mode and the C flag is set, a Notification
      message MUST be generated, with the Status Code set to "OAM
      Problem/ Combined mode unsupported".

   Reserved: Reserved for future specification and set to 0 on
   transmission and ignored when received.

4.2.2.1.  PM Loss Sub-TLV

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
















Zhang, et al.           Expires January 21, 2016               [Page 21]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


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

                              PM Loss sub-TLV

   Type: indicates a new type, the PM Loss sub-TLV (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.  If the
   egress PE cannot support this value, a Notification message MUST be
   generated, with the Status Code set to "OAM Problem/Unsupported
   Timestamp Format".

   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 (100) as
   per [RFC6375]..

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




Zhang, et al.           Expires January 21, 2016               [Page 22]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   Loss Threshold: the threshold value of measured lost packets per
   measurement over which action(s) SHOULD be triggered.

4.2.2.2.  PM Delay Sub-TLV

   The PM Delay sub-TLV depicted below is carried as a sub-TLV of the PW
   OAM Functions 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                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             PM Delay sub-TLV

   Type: indicates a new type, the PM Delay sub-TLV (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.  If the
   egress LSR cannot support this value, a Notification message MUST be
   generated, with the Status Code set to "OAM Problem/Unsupported
   Timestamp Format".

   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.





Zhang, et al.           Expires January 21, 2016               [Page 23]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   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 (1000) as
   per [RFC6375].

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

   Delay Threshold: the threshold value of measured two-way delay (in
   milliseconds) over which action(s) SHOULD be triggered.

4.2.3.  Fault Management Signal Sub-TLV

   The Fault Management Signal sub-TLV depicted below is carried as a
   sub-TLV of the PW OAM Functions TLV.  When both working and
   protection paths are configured, both PWs SHOULD be configured with
   identical settings of the E flag, T flag, and the refresh timer.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       FMS sub-type (300)      |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E|S|T|            Reserved           |      Refresh Timer      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           sub-TLVs                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Fault Management Signal sub-TLV

   Type: indicates a new type, the Fault Management Signal sub-TLV
   (suggested value 4).

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

   FMS Signal Flags are used to enable the FMS signals at end point MEPs
   and the Server MEPs of the links over which the PW is forwarded.  In
   this document only the S flag pertains to Server MEPs.

   The following flags are defined:

   o  E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR)
      signaling as described in [RFC6427].  Default value is 1
      (enabled).  If the egress MEP does not support FMS signal
      generation, a Notification message MUST be generated, with the



Zhang, et al.           Expires January 21, 2016               [Page 24]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


      Status Code set to "OAM Problem/Fault management signaling
      unsupported".

   o  S: Indicate to a server MEP that it should transmit AIS and LKR
      signals on the client PW.  Default value is 0 (disabled).  If a
      Server MEP which is capable of generating FMS messages is for some
      reason unable to do so for the PW being signaled, a Notification
      message MUST be generated, with the Status Code set to "OAM
      Problem/ Unable to create fault management association".

   o  T: Set timer value, enabled the configuration of a specific timer
      value.  Default value is 0 (disabled).

   o  Remaining bits: Reserved for future specification and set to 0.

   Refresh Timer: indicates the refresh timer of fault indication
   messages, in seconds.  The value MUST be between 1 to 20 seconds as
   specified for the Refresh Timer field in [RFC6427].  If the egress PE
   receiving the Label Mapping message cannot support the value it
   SHOULD reply with a higher timer value.

   Fault Management Signal sub-TLV MAY include Traffic Class sub-TLV
   (Section 4.2.1.4).  If TC sub-TLV is present, the value of the TC
   field MUST be used as the value of the TC field of a PW label stack
   entry for FMS messages.  If the TC sub-TLV is absent, then selection
   of the TC value is local decision.

5.  IANA Considerations

5.1.  TLVs

   IANA is requested to assign two new TLV types from the registry "TLV
   Type Name Space" in the "Label Distribution Protocol (LDP)
   Parameters" registry.

      Value     TLV                            References
      -----     --------                       ----------
       TBD1     PW OAM Administration TLV      this document
       TBD2     PW OAM Functions TLV           this document

   The sub-TLV space and assignments for the PW OAM Functions TLV will
   be the same as that for the MPLS OAM Functions TLV.  Sub-types for
   the MPLS OAM Functions TLV and the PW OAM Functions TLV MUST be kept
   the same.  Any new sub-type added to the MPLS OAM Functions TLV MUST
   apply to the PW OAM Functions TLV as well.






Zhang, et al.           Expires January 21, 2016               [Page 25]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


5.1.1.  PW OAM Configuration Sub-TLV

   IANA is requested to create a registry of "Pseudowire OAM
   Configuration Sub-TLV types".  These are 16 bit values.  Sub-TLV
   types 1 through 8 are specified in this document.  Sub-TLV types 0
   and 65535 are reserved.  Sub-TLV 9 through 65534 are to be assigned
   by IANA, using the "Expert Review" policy defined in [RFC5226].

      Value     Sub-TLV                                   References
      -----     --------                                  ----------
          1     BFD Configuration sub-TLV                 this document
          2     Performance Monitoring sub-TLV            this document
          3     Fault Management Signal sub-TLV           this document

5.1.1.1.  BFD Configuration sub-TLVs

   IANA is requested to create a registry of "Pseudowire OAM BFD
   Configuration Sub-TLV types".  These are 16 bit values.  Sub-TLV
   types 1 through 3 are specified in this document.  Sub-TLV types 0
   and 65535 are reserved.  Sub-TLV 4 through 65534 are to be assigned
   by IANA, using the "Expert Review" policy defined in [RFC5226].

      Value     Sub-TLV                                   References
      -----     --------                                  ----------
          1     Local Discriminator sub-TLV               this document
          2     Negotiation Timer Parameters sub-TLV      this document
          3     BFD Authentication sub-TLV                this document
          4     Traffic Class Sub-TLV                     this document

5.1.1.2.  Performance Monitoring sub-TLVs

   IANA is requested to create a registry of "Pseudowire OAM Performance
   Monitoring Sub-TLV types".  These are 16 bit values.  Sub-TLV types 1
   through 2 are specified in this document.  Sub-TLV types 0 and 65535
   are reserved.  Sub-TLV 3 through 65534 are to be assigned by IANA,
   using the "Expert Review" policy defined in [RFC5226].

      Value     Sub-TLV                      References
      -----     --------                     ----------
          1     PM Loss TLV                  this document
          2     PM Delay TLV                 this document

5.2.  OAM Configuration Status Code

   IANA is requested to assign the following LDP status codes from the
   registry "STATUS CODE NAME SPACE" in the "Label Distribution Protocol
   (LDP) Parameters" registry.




Zhang, et al.           Expires January 21, 2016               [Page 26]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


Range/Value   E    Description                             Reference
----------- -----  -------------------------------------   -------------
      TBD3    0    "PW OAM Alarms Enabled"                 This document
      TBD4    0    "PW OAM Alarms Disabled"                This document
      TBD5    0    "PW MEP Configuration Failed"           This document
      TBD6    0    "PW MEP Configuration Succeed"          This document
      TBD7    0    "PW MEP Entities Disabled"              This document
      TBD8    0    "PW MIP Configuration Failed"           This document
      TBD9    0    "PW OAM Parameters Rejected"            This document
      TBD10   0    "OAM Problem/Unsupported BFD            This document
                    Version"
      TBD11   0    "OAM Problem/Unsupported BFD            This document
                    Encapsulation format"
      TBD12   0    "OAM Problem/Unsupported BFD            This document
                    Authentication Type"
      TBD13   0    "OAM Problem/Mismatch of BFD            This document
                    Authentication Key ID
      TBD14   0    "OAM Problem/Unsupported Timestamp      This document
                    Format"
      TBD15   0    "OAM Problem/Unsupported Delay          This document
                    Mode"
      TBD16   0    "OAM Problem/Unsupported Loss Mode"     This document
      TBD17   0    "OAM Problem/Delay variation            This document
                    unsupported"
      TBD18   0    "OAM Problem/Dyadic mode                This document
                    unsupported"
      TBD19   0    "OAM Problem/Loopback mode              This document
                    unsupported"
      TBD20   0    "OAM Problem/Combined mode              This document
                    unsupported"
      TBD21   0    "OAM Problem/Fault management           This document
                    signaling unsupported"
      TBD22   0    "OAM Problem/Unable to create           This document
                    fault management association"


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





Zhang, et al.           Expires January 21, 2016               [Page 27]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


7.  Acknowledgement

   The authors would like to thank Andrew 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.

8.  References

8.1.  Normative references

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

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447,
              DOI 10.17487/RFC4447, April 2006,
              <http://www.rfc-editor.org/info/rfc4447>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561,
              DOI 10.17487/RFC5561, July 2009,
              <http://www.rfc-editor.org/info/rfc5561>.

8.2.  Informative References

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

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <http://www.rfc-editor.org/info/rfc3985>.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <http://www.rfc-editor.org/info/rfc4379>.



Zhang, et al.           Expires January 21, 2016               [Page 28]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5291]  Chen, E. and Y. Rekhter, "Outbound Route Filtering
              Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,
              August 2008, <http://www.rfc-editor.org/info/rfc5291>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <http://www.rfc-editor.org/info/rfc5462>.

   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
              September 2009, <http://www.rfc-editor.org/info/rfc5654>.

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
              DOI 10.17487/RFC5659, October 2009,
              <http://www.rfc-editor.org/info/rfc5659>.

   [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
              "Requirements for Operations, Administration, and
              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
              DOI 10.17487/RFC5860, May 2010,
              <http://www.rfc-editor.org/info/rfc5860>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <http://www.rfc-editor.org/info/rfc5880>.

   [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
              Administration, and Maintenance Framework for MPLS-Based
              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
              September 2011, <http://www.rfc-editor.org/info/rfc6371>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <http://www.rfc-editor.org/info/rfc6374>.

   [RFC6375]  Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
              Delay Measurement Profile for MPLS-Based Transport
              Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011,
              <http://www.rfc-editor.org/info/rfc6375>.



Zhang, et al.           Expires January 21, 2016               [Page 29]

Internet-Draft        LDP Extensions for TP PW OAM             July 2015


   [RFC6427]  Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
              Boutros, S., and D. Ward, "MPLS Fault Management
              Operations, Administration, and Maintenance (OAM)",
              RFC 6427, DOI 10.17487/RFC6427, November 2011,
              <http://www.rfc-editor.org/info/rfc6427>.

   [RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
              Extensions for Operations, Administration, and Maintenance
              (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
              2014, <http://www.rfc-editor.org/info/rfc7260>.

   [RFC7487]  Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
              Skoldstrom, P., and D. Ward, "Configuration of Proactive
              Operations, Administration, and Maintenance (OAM)
              Functions for MPLS-Based Transport Networks Using RSVP-
              TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
              <http://www.rfc-editor.org/info/rfc7487>.

Authors' Addresses

   Fei Zhang (editor)
   Huawei

   Email: zhangfei7@huawei.com


   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


   Mach(Guoyi) Chen (editor)
   Huawei

   Email: mach.chen@huawei.com





Zhang, et al.           Expires January 21, 2016               [Page 30]