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

Versions: 00 01 02 03 04 05 06 draft-ietf-pwe3-oam-config

MPLS Working Group                                         F. Zhang, Ed.
Internet-Draft                                                B. Wu, Ed.
Intended status: Standards Track                         ZTE Corporation
Expires: April 28, 2011                               E. Bellagamba, Ed.
                                                               A. Takacs
                                                                Ericsson
                                                                  X. Dai
                                                                 M. Xiao
                                                         ZTE Corporation
                                                        October 25, 2010


  LDP Extensions for Proactive OAM Configuration of Dynamic MPLS-TP PW
                  draft-zhang-mpls-tp-pw-oam-config-03

Abstract

   This document specifies extensions to the LDP protocol to configure
   and control proactive OAM functions, suitable for dynamic SS-PW and
   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 April 28, 2011.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Analysis of existing PW OAM Configuration  . . . . . . . .  3
       1.1.1.  MPLS PW OAM Functions  . . . . . . . . . . . . . . . .  3
       1.1.2.  VCCV . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.3.  VCCV BFD . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.4.  PW Status  . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.5.  Conclusion . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Analysis of PW OAM Configuration Extended by MPLS-TP . . .  5
       1.2.1.  CC-CV-RDI  . . . . . . . . . . . . . . . . . . . . . .  5
       1.2.2.  PM Loss/Delay  . . . . . . . . . . . . . . . . . . . .  6
       1.2.3.  FMS  . . . . . . . . . . . . . . . . . . . . . . . . .  6
       1.2.4.  On-demand OAM functions  . . . . . . . . . . . . . . .  6
       1.2.5.  Conclusion . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  8
   3.  MPLS-TP PW OAM Capability Advertisement  . . . . . . . . . . .  8
   4.  PW OAM Configuration Procedures  . . . . . . . . . . . . . . .  8
     4.1.  Establishment of OAM Entities and Functions  . . . . . . .  8
     4.2.  Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10
     4.3.  Deleting OAM Entities  . . . . . . . . . . . . . . . . . . 11
   5.  LDP extensions . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  MPLS-TP PW OAM capability TLV  . . . . . . . . . . . . . . 11
     5.2.  MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . . 12
       5.2.1.  BFD Configuration TLV  . . . . . . . . . . . . . . . . 13
       5.2.2.  MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . . . . 14
       5.2.3.  MPLS-TP PW PM Delay TLV  . . . . . . . . . . . . . . . 14
       5.2.4.  MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  LDP TLV Types  . . . . . . . . . . . . . . . . . . . . . . 15
     6.2.  LDP Status Code  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Normative references . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18










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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


1.  Introduction

   MPLS PWs are defined in [RFC3985] and [RFC5659], which provide 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 OAM, survivability and other maintenance functions not
   previously supported by IP/MPLS, including PW.  The corresponding
   requirements are defined in [I-D.ietf-mpls-tp-oam-requirements].

   [I-D.ietf-mpls-tp-oam-framework] describes how MPLS-TP OAM mechanisms
   are operated to meet transport requirements, categorized into
   proactive and on-demand monitoring.  Proactive monitoring is
   typically configured at transport path creation time, either be
   carried out periodically and continuously or act on certain events
   such as alarm signals.  In contract 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.

   NMS or LSP Ping [I-D.absw-mpls-lsp-ping-mpls-tp-oam-conf] are used to
   configure these OAM functionalities if a control plane is not
   instantiated.  But if the control plane is used, it must support to
   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 extensions to the LDP protocol to negotiate
   PW OAM capabilities, configure and bootstrap proactive PW OAM
   functions, suitable for SS-PW and MS-PW.  Configuration of OAM
   entities for MS-PW SPME will be added in the future, and P2MP PW is
   out of the scope of this document.

1.1.  Analysis of existing PW OAM Configuration

1.1.1.  MPLS PW OAM Functions

   Before MPLS-TP standards, PW OAM functions are implemented by
   [RFC5085], [RFC5885], [RFC4447] and [I-D.ietf-pwe3-static-pw-status].
   [RFC5085] defines CV(connectivity verification),which belongs to on-
   demand PW monitoring.  [RFC5885] defines proactive connectivity
   connection and PW/AC status notification.  [RFC4447] and
   [I-D.ietf-pwe3-static-pw-status] give some other ways of PW/AC status
   notification.

1.1.2.  VCCV

   The goal of VCCV is to verify and further diagnose PW forwarding
   path.  The extension to LDP is signaling VCCV capabilities to a peer



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   PE.

   The extension to LDP is signaling VCCV LSP ping/ICMP ping
   capabilities to a peer PE.

1.1.3.  VCCV BFD

   [RFC5885] specifies four CV types for BFD by combining two types of
   encapsulation with two types of functionality.  When multiple BFD CV
   Types are advertised, it also describes how to select one to use.

   The extension to LDP is to signal VCCV BFD capabilities to a peer PE,
   and activate BFD protocol after PW is established.  If the BFD
   parameters(such as sending interval) need to be modified, BFD itself
   will handle it.

1.1.4.  PW Status

   PW status codes provides a mechanism to signal the status of PW, or
   AC failure between the two PEs at each end of the PW.  When PW
   control plane exists, the PW status TLV is carried in the initial
   Label Mapping message or Notification message to signal all PW status
   messages.

   The extension to LDP is to signal PW status capabilities to a peer
   PE, and activate PW status notification function after PW is
   established.  So when a event occurs, an update PW status will be
   sent.

1.1.5.  Conclusion

   In summary, IP/MPLS PW OAM functions and relation with control plane/
   NMS is described in the table.  This document will not replace or
   deprecate this; e.g.,VCCV capability advertisement and PW status
   negotiation for MPLS networks.
















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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   |----------------------------------------------------------------------|
   |              |              |  LDP         | LSP Ping |     NMS      |
   |----------------------------------------------------------------------|
   |              |   VCCV       |  Capability  |          |  Capability  |
   |              |  LSP ping    |  negotiation |          |configuration&|
   |  On-demand   |              |              |          | Bootstrapping|
   |   MPLS PW    |-------------------------------------------------------|
   |     OAM      |   VCCV       |  Capability  |          |  Capability  |
   |              |  ICMP ping   |  negotiation |          |configuration&|
   |              |              |              |          | Bootstrapping|
   |----------------------------------------------------------------------|
   |              |   VCCV BFD   |  Capability  |          | Capability   |
   |              |              | negotiation& |          |configuration&|
   |              |              | Bootstrapping|          | Bootstrapping|
   |  Proactive   |-------------------------------------------------------|
   |    OAM       |   PW status  | Capability   |          | Capability   |
   |              |              | negotiation& |          |configuration&|
   |              |              | Bootstrapping|          | Bootstrapping|
   |----------------------------------------------------------------------|


                    Figure 1: IP/MPLS PW OAM functions

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

1.2.1.  CC-CV-RDI

   [I-D.ietf-mpls-tp-cc-cv-rdi] has been chosen to be the basis of pro-
   active MPLS-TP OAM functions.  Because VCCV BFD currently has no CV
   function, it SHOULD evolve with [I-D.ietf-mpls-tp-cc-cv-rdi] to
   provide this function in TP environment.  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 (FEC) so local
   discriminator values are not exchanged; please refer to the analysis
   in [I-D.ietf-mpls-tp-oam-analysis] and [RFC5885].  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, (MS-)PW
   and Section as well as for SPME, BFD MAY 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.

   Timer negotiation, such as TX/RX interval is performed in subsequent
   BFD control messages [RFC5880], but it also can be gotten by control
   plane signaling [I-D.ietf-mpls-tp-oam-framework].

   The source MEP-ID does not need to be carried, for they can be



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   deduced from the advertised FEC (129) TLV, as described in
   [I-D.ietf-mpls-tp-identifiers].

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

   In conclusion, the configuration of VCCV BFD by control plane is not
   necessary, but for consistent operation of transport path and
   section, it SHOULD be an option.

1.2.2.  PM Loss/Delay

   [I-D.frost-mpls-tp-loss-delay]specifies mechanisms for performance
   monitoring of PWs, in particular it specifies loss and delay
   measurements.

   For proactive LM, the transmission rate and PHB associated with the
   LM OAM packets originating from a MEP need be negotiated with the
   other MEP.  LM OAM packets should be transmitted with the same PHB
   class that the LM is intended to measure.

   Just like LM, Both one way and two way mode of proactive DM need the
   two MEPs nodes of PW to negotiate the measure interval and PHB value
   of OAM packets.

1.2.3.  FMS

   [I-D.ietf-mpls-tp-fault]specifies fault management signals 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 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.

   In conclusion, the configuration of FMS by control plane is not
   necessary, but for easy maintenance, it SHOULD be an option also.

1.2.4.  On-demand OAM functions

   The extended on-demand OAM functions MAY need capability negotiation
   in the initialized LDP mapping message.  However, On-demand PW OAM
   functions are expected to be carried out by directly accessing



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   network nodes via a management interface; hence configuration and
   control of on-demand PW OAM functions are out-of-scope for this
   document.

1.2.5.  Conclusion

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

   Furthermore, LSP ping can be used to configure the proactive PW OAM
   function extended by MPLS-TP also, suitable for dynamic and static
   PW.  For reference, the following table describes the different scope
   of different proactive OAM bootstrapping schemes of dynamic PW.



   |-------------------------------------------------------------------------|
   |            |               |  LDP         | LSP Ping     |   NMS        |
   |-------------------------------------------------------------------------|
   |            |               |Capability    |              | Capability   |
   |            |               |negotiation&  |              |configuration&|
   |            |  CC/CV/RDI    |Function      | Function     | Function     |
   |            |               |configuration&|configuration&|configuration&|
   |            |               |Bootstrapping |Bootstrapping | Bootstrapping|
   |            |------------------------------------------------------------|
   | Proactive  |               |Capability    |              |  Capability  |
   |    OAM     |               |negotiation&  |              |configuration&|
   |            |     FMS       |Function      | Function     | Function     |
   |            |               |configuration&|configuration&|configuration&|
   |            |               |Bootstrapping |Bootstrapping | Bootstrapping|
   |            |------------------------------------------------------------|
   |            |               |Capability    |              |  Capability  |
   |            |               |negotiation&  |              |configuration&|
   |            | PM Loss/Delay |Function      | Function     | Function     |
   |            |               |configuration&|configuration&|configuration&|
   |            |               |Bootstrapping |Bootstrapping | Bootstrapping|
   |------------|------------------------------------------------------------|


                    Figure 2: MPLS-TP PW OAM functions





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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


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.


3.  MPLS-TP PW OAM Capability Advertisement

   When a PW is first set up, the PEs MUST attempt to negotiate the
   usage of what kind of OAM functions.  Up to now, there are PW status
   negotiation and VCCV capability advertisement.  For the newly
   extended OAM function by MPLS-TP, such as PM loss/delay and FMS, the
   capability negotiation is accomplished as follows: A PE that supports
   the MPLS-TP PW OAM capability MUST include MPLS-TP PW OAM capability
   TLV in the initial Label Mapping message, following the PW Status TLV
   or VCCV parameter field in Interface Parameters TLV.  If the extended
   on-demand OAM functions also need capability negotiation, just follow
   the same rules.


4.  PW OAM Configuration Procedures

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

   a) Active/active "C 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 "C One PE is active and the others are passive
   (MS-PW).  The active/passive role election is defined in Section
   7.2.1 of [I-D.ietf-pwe3-segmented-pw] 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.  This section takes MS-PW as an example to describe
   the general OAM configuration procedures.  As for SS-PW, there may be
   some collisions of PW OAM configuration parameters, and these
   specific differences would be addressed in section 6.

4.1.  Establishment of OAM Entities and Functions

   Assuming there is one PW 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.



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


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


                 Figure 3: 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, "OAM MEP Entities
   desired" set and "OAM MIP Entities desired" set in the MPLS-TP PW OAM
   capability TLV.

   When the Mapping message arrives at the down receivers, such as
   S-PE1, S-PE2 and T-PE2, they MUST establish and configure OAM
   entities according to the OAM information provided in mapping
   message.  If this is not possible, a Label Release message SHOULD be
   sent and neither the OAM entities nor the PW SHOULD be established.
   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
   (e.g., due to missing or unidentified OAM messages).  The Mapping
   message MUST be sent with the "OAM Alarms Enabled" cleared, "OAM MEP
   Entities desired" set, "OAM MIP Entities desired" set in the MPLS-TP
   PW OAM capability 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.  Data plane OAM is now fully functional, by the
   way, the MPLS-TP PW OAM Configuration TLV is not needed to be carried
   in the Notification message.

   The PW may be setup with OAM entities right away with the first
   signaling, as described above, but a PW may be signaled and



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   established without OAM configuration first, and OAM entities may be
   added later.  This can be done by sending Notification message with
   the related configuration parameters subsequently.

4.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 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.  First, 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 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
   first 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
   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 after it received the Notification message.  After this
   Notification messages that exchange (in both directions) the OAM
   parameters are updated and OAM is running according the new parameter
   settings.  However OAM alarms are still disabled, a subsequent
   Notification messages exchanges with "OAM Alarms Enabled" flag set
   are needed to enable OAM alarms again.






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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


4.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 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 Notification message with "OAM MEP Entities desired" and "OAM
   MIP Entities desired" cleared.  While T-PE2 (T-PE1) deletes OAM sink
   function when it receives the Notification message with "OAM MEP
   Entities desired" cleared, 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.


5.  LDP extensions

   Below, extensions to LDP are defined in order to configure MPLS-TP PW
   OAM functionalities during the PW setup.

5.1.  MPLS-TP PW OAM capability TLV

   The format of the MPLS-TP PW OAM Capability 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|  MPLS-TP PW OAM Capability |           Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E|I|A|      MPLS-TP PW OAM Capability Flags              |F|D|L|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4:  MPLS-TP PW OAM Capability TLV

   Currently defined OAM Capability Flags are:






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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   0                         PM Loss supported
   1                         PM Delay supported
   2                         FMS supported

   29                        OAM Alarms Enabled
   30                        OAM MIP entities desired
   31                        OAM MEP entities desired


   One bit (0, IANA to assign): "PM Loss supported" is allocated.

   One bit (1, IANA to assign): "PM delay supported" is allocated.

   One bit (2, IANA to assign): "FMS supported" is allocated.

   One bit (31, IANA to assign): "OAM MEP entities desired" is
   allocated.  If the "OAM MEP entities desired" bit is set it is
   indicating that the establishment of OAM MEP entities are required at
   the endpoints of the signaled PW.  If the establishment of MEPs is
   not supported, a Label Release message MUST be sent.  If the "OAM MEP
   entities desired" bit is set and additional parameters are needed to
   be configured on the OAM entities, an "MPLS-TP PW OAM Configuration
   TLV" may be included in the Mapping or Notification message.

   One bit (30, IANA to assign): "OAM MIP entities desired" is
   allocated.  This bit can only be set if the "OAM MEP entities
   desired" bit is set.  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 Label Release message MUST
   be sent.

   One bit (29, IANA to assign): "OAM Alarms Enabled" is allocated.
   This bit can only be set if the "OAM MEP entities desired" bit is
   set.  If the "OAM Alarms Enabled" bit is set, it is indicating that
   the T-PE needs to enable OAM alarms.  If the establishment of a MIP
   is not supported, a Label Release message MUST be sent.

   [Editor notes]: If the MPLS-TP equipments support all the PW OAM
   functions defined and the OAM capability negotiation is not needed,
   this MPLS-TP PW OAM capability TLV just use to configure MEP/MIP
   entities and enable/disable OAM alarms.

5.2.  MPLS-TP PW OAM Configuration TLV

   The "OAM Configuration TLV", defined in
   [I-D.ietf-ccamp-oam-configuration-fwk], is depicted in the following
   figure.  It may be carried in the Mapping and Notification messages,



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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   just following the PW Status 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|       Type (2) (IANA)     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    OAM Type   |                Reserved                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           sub-TLVs                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5: MPLS-TP PW OAM Configuration TLV

   OAM type: indicates a new type: the MPLS-TP PW OAM Configuration TLV
   (IANA to assign).  If this type is not supported, a Label Release
   message MUST be sent.  The specific OAM functions are specified in
   the "Function Flags" sub-TLV as depicted in
   [I-D.ietf-ccamp-oam-configuration-fwk], and the additional
   corresponding sub-TLVs are defined in section 3.2 of
   [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].

   For active/active signaling, if the flags in the "MPLS-TP PW OAM
   Function Flags sub-TLV" are different in the two Mapping message, the
   two PEs nodes can compare the node IDs.  Label Withdraw message MUST
   be sent by the PE with lower ID, then it sends the Label Mapping
   message again with the same flags carried in the received Label
   Mapping message.

5.2.1.  BFD Configuration TLV

   BFD Configuration TLV follows the same TLV structure defined for
   RSVP-TE in section 3.3 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].

   For active/active signaling, if the flags of "BFD Configuration TLV"
   are different in the two Mapping message, similarly Label Withdraw
   message MUST be sent by the PE with lower ID.  Then it sends the
   Label Mapping message again with the same flags carried in the "BFD
   configuration TLV" of the received Label Mapping message.  If the
   flags of "BFD Configuration TLV" are the same, but the values of
   "Negotiation Timer parameters sub-TLV" are different, both the PE
   nodes MUST adopt the bigger interval and detection time multiplier.







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


Internet-Draft        LDP extensions for TP PW OAM          October 2010


5.2.2.  MPLS-TP PW PM Loss TLV

   MPLS-TP PW PM Loss TLV follows the same TLV structure defined for
   RSVP-TE in section 3.4 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].

   For active/active signaling, if the flags of "MPLS-TP PW OAM PM Loss
   TLV" are different in the two Mapping message, similarly Label
   Withdraw message MUST be sent by the PE with lower ID.  Then it sends
   the Label Mapping message again with the same flags carried in the
   "MPLS-TP PW OAM PM Loss TLV" of the received Label Mapping message.
   If the flags of "MPLS-TP PW OAM PM Loss TLV" are the same, but the
   Measurement Interval and Loss Threshold are different, both the PE
   nodes MUST adopt the bigger values.

5.2.3.  MPLS-TP PW PM Delay TLV

   MPLS-TP PW PM Delay TLV follows the same TLV structure defined for
   RSVP-TE in section 3.5 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].

   For active/active signaling, if the flags of "MPLS-TP PW OAM PM Delay
   TLV" are different in the two Mapping message, similarly Label
   Withdraw message MUST be sent by the PE with lower ID.  Then it sends
   the Label Mapping message again with the same flags carried in the
   "MPLS-TP PW OAM PM Delay TLV" of the received Label Mapping message.
   If the flags of "MPLS-TP PW OAM PM Delay TLV" are the same, but the
   Measurement Interval and Delay Threshold are different, both the PE
   nodes MUST adopt the bigger values.

5.2.4.  MPLS-TP PW FMS TLV

   MPLS-TP PW FMS TLV follows the same TLV structure defined for RSVP-TE
   in section 3.6 of [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext].

   For active/active signaling, if the flags of "MPLS-TP PW OAM FMS TLV"
   are different in the two Mapping message, similarly Label Withdraw
   message MUST be sent by the PE with lower ID.  Then it sends the
   Label Mapping message again with the same flags carried in the
   "MPLS-TP PW OAM FMS TLV" of the received Label Mapping message.

   Notes: CSF are overlapped with PW Status TLV, and the field of
   Refresh Timer is not needed.


6.  IANA Considerations







Zhang, et al.            Expires April 28, 2011                [Page 14]


Internet-Draft        LDP extensions for TP PW OAM          October 2010


6.1.  LDP TLV Types

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

   Sub-TLV types to be carried in the "MPLS-TP PW OAM Configuration
   TLV":
   o  MPLS-TP PW OAM Function Flags sub-TLV;
   o  BFD Configuration sub-TLV;
   o  MPLS-TP PW PM Loss sub-TLV;
   o  MPLS-TP PW PM Delay 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.

6.2.   LDP Status Code

   TBD.


7.  Security Considerations

   TBD.


8.  Acknowledgement

   The authors would like to thank Thomas Nadeau for his valuable
   comments.


9.  Normative references

   [I-D.absw-mpls-lsp-ping-mpls-tp-oam-conf]
              Bellagamba, E., Andersson, L., Skoldstrom, P., and D.
              Ward, "Configuration of pro-active MPLS-TP Operations,
              Administration, and Maintenance (OAM) Functions Using LSP
              Ping", draft-absw-mpls-lsp-ping-mpls-tp-oam-conf-00 (work
              in progress), July 2010.

   [I-D.frost-mpls-tp-loss-delay]
              Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for the MPLS Transport Profile",
              draft-frost-mpls-tp-loss-delay-02 (work in progress),
              June 2010.



Zhang, et al.            Expires April 28, 2011                [Page 15]


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   [I-D.ietf-ccamp-oam-configuration-fwk]
              Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration
              Framework and Requirements for GMPLS RSVP-TE",
              draft-ietf-ccamp-oam-configuration-fwk-03 (work in
              progress), January 2010.

   [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
              Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D.,
              and A. Takacs, "Configuration of pro-active MPLS-TP
              Operations, Administration, and Maintenance (OAM)
              Functions Using RSVP-TE",
              draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03 (work in
              progress), July 2010.

   [I-D.ietf-mpls-tp-cc-cv-rdi]
              Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan,
              S., and D. Ward, "Proactive Connectivity Verification,
              Continuity Check and Remote Defect indication for MPLS
              Transport Profile", draft-ietf-mpls-tp-cc-cv-rdi-02 (work
              in progress), October 2010.

   [I-D.ietf-mpls-tp-fault]
              Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
              Ward, D., Bryant, S., and S. Sivabalan, "MPLS Fault
              Management OAM", draft-ietf-mpls-tp-fault-02 (work in
              progress), July 2010.

   [I-D.ietf-mpls-tp-identifiers]
              Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
              draft-ietf-mpls-tp-identifiers-02 (work in progress),
              July 2010.

   [I-D.ietf-mpls-tp-lsp-ping-bfd-procedures]
              Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher,
              N., and Y. Weingarten, "LSP-Ping and BFD encapsulation
              over ACH", draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01
              (work in progress), August 2010.

   [I-D.ietf-mpls-tp-oam-analysis]
              Sprecher, N., Bellagamba, E., and Y. Weingarten, "MPLS-TP
              OAM Analysis", draft-ietf-mpls-tp-oam-analysis-02 (work in
              progress), July 2010.

   [I-D.ietf-mpls-tp-oam-framework]
              Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A.,
              Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher,
              N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R.
              Winter, "Operations, Administration and Maintenance



Zhang, et al.            Expires April 28, 2011                [Page 16]


Internet-Draft        LDP extensions for TP PW OAM          October 2010


              Framework for MPLS- based Transport Networks",
              draft-ietf-mpls-tp-oam-framework-09 (work in progress),
              October 2010.

   [I-D.ietf-mpls-tp-oam-requirements]
              Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS
              Transport Networks",
              draft-ietf-mpls-tp-oam-requirements-06 (work in progress),
              March 2010.

   [I-D.ietf-pwe3-dynamic-ms-pw]
              Martini, L., Bocci, M., Balus, F., Bitar, N., Shah, H.,
              Aissaoui, M., Rusmisel, J., Serbest, Y., Malis, A., Metz,
              C., McDysan, D., Sugimoto, J., Duckett, M., Loomis, M.,
              Doolan, P., Pan, P., Pate, P., Radoaca, V., Wada, Y., and
              Y. Seo, "Dynamic Placement of Multi Segment Pseudo Wires",
              draft-ietf-pwe3-dynamic-ms-pw-13 (work in progress),
              October 2010.

   [I-D.ietf-pwe3-redundancy]
              Muley, P., "Pseudowire (PW) Redundancy",
              draft-ietf-pwe3-redundancy-03 (work in progress),
              May 2010.

   [I-D.ietf-pwe3-segmented-pw]
              Martini, L., Nadeau, T., Metz, C., Bocci, M., Aissaoui,
              M., Balus, F., and M. Duckett, "Segmented Pseudowire",
              draft-ietf-pwe3-segmented-pw-18 (work in progress),
              September 2010.

   [I-D.ietf-pwe3-static-pw-status]
              Martini, L., Swallow, G., and M. Bocci, "Pseudowire Status
              for Static Pseudowires",
              draft-ietf-pwe3-static-pw-status-00 (work in progress),
              February 2010.

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

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

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label



Zhang, et al.            Expires April 28, 2011                [Page 17]


Internet-Draft        LDP extensions for TP PW OAM          October 2010


              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC5003]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
              "Attachment Individual Identifier (AII) Types for
              Aggregation", RFC 5003, September 2007.

   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
              Connectivity Verification (VCCV): A Control Channel for
              Pseudowires", RFC 5085, December 2007.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 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.

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

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

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.

   [RFC5885]  Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
              Detection (BFD) for the Pseudowire Virtual Circuit
              Connectivity Verification (VCCV)", RFC 5885, June 2010.


Authors' Addresses

   Fei Zhang (editor)
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86 025 52877612
   Email: zhang.fei3@zte.com.cn




Zhang, et al.            Expires April 28, 2011                [Page 18]


Internet-Draft        LDP extensions for TP PW OAM          October 2010


   Bo Wu (editor)
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86 025 52877276
   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
   4F,RD Building 2,Zijinghua Road
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86 025 52877612
   Email: dai.xuehui@zte.com.cn


   Min Xiao
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86 025 52877612
   Email: xiao.min2@zte.com.cn




Zhang, et al.            Expires April 28, 2011                [Page 19]


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