[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: September 15, 2011                           E. Bellagamba, Ed.
                                                                Ericsson
                                                          March 14, 2011


    Label Distribution Protocol Extensions for Proactive Operations,
 Administration and Maintenance Configuration of Dynamic MPLS Transport
                           Profile Pseudowire
                  draft-zhang-mpls-tp-pw-oam-config-04

Abstract

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 15, 2011.

Copyright Notice

   Copyright (c) 2011 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 September 15, 2011               [Page 1]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Analysis of Existing PW OAM Configuration  . . . . . . . . . .  4
     3.1.  MPLS PW OAM Functions  . . . . . . . . . . . . . . . . . .  4
     3.2.  Virtual Circuit Connectivity Verification  . . . . . . . .  5
     3.3.  VCCV Bidirectional Forwarding Detection  . . . . . . . . .  5
     3.4.  PW Status  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Analysis of PW OAM Configuration Extended by MPLS-TP . . . . .  6
     4.1.  Continuity Check, Connectivity Verification and Remote
           Defect Indication  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Performance Monitoring Loss/Delay  . . . . . . . . . . . .  7
     4.3.  FMS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  On-demand OAM Functions  . . . . . . . . . . . . . . . . .  8
     4.5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  MPLS-TP PW OAM Capability Advertisement  . . . . . . . . . . .  9
   6.  PW OAM Configurationd Procedures . . . . . . . . . . . . . . .  9
     6.1.  Establishment of OAM Entities and Functions  . . . . . . .  9
     6.2.  Adjustment of OAM Parameters . . . . . . . . . . . . . . . 11
     6.3.  Deleting OAM Entities  . . . . . . . . . . . . . . . . . . 12
   7.  LDP extensions . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  MPLS-TP PW OAM Capability TLV  . . . . . . . . . . . . . . 12
     7.2.  MPLS-TP PW OAM Administration TLV  . . . . . . . . . . . . 13
     7.3.  MPLS-TP PW OAM Configuration TLV . . . . . . . . . . . . . 14
       7.3.1.  BFD Configuration TLV  . . . . . . . . . . . . . . . . 15
       7.3.2.  MPLS-TP PW PM Loss TLV . . . . . . . . . . . . . . . . 15
       7.3.3.  MPLS-TP PW PM Delay TLV  . . . . . . . . . . . . . . . 15
       7.3.4.  MPLS-TP PW FMS TLV . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative references . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20








Zhang, et al.          Expires September 15, 2011               [Page 2]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


1.  Introduction

   MPLS Pseudowire (PW) is 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 Operations, Administration and Maintenance
   (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].

   The MPLS-TP OAM mechanisms that are operated to meet transport
   requirements are described in [I-D.ietf-mpls-tp-oam-framework],
   categorized into proactive and on-demand monitoring.  Proactive
   monitoring refers to OAM operations that are either configured to be
   carried out periodically and continuously or preconfigured to act on
   certain events such as alarm signals.  In 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.

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

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


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.1.  Acronyms

      AC: Attachment Circuit







Zhang, et al.          Expires September 15, 2011               [Page 3]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


      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
      ICMP: Internet Control Message Protocol
      LDI: Link Down Indication
      LDP: Label Distribution Protocol
      LKR: Lock Reporting
      LM: Loss Measurement
      LSP: Label Switched Path
      ME: Maintenance Entity
      MEG: Maintenance Entity Group
      MEP: Maintenance Entity Group End Point
      MIP: Maintenance Entity Group Intermediate Point
      MPLS-TP: MPLS Transport Profile
      MS-PW: Multi-Segment PseudoWire
      NMS: Network Management System
      OAM: Operations, Adminstration and Maintenance
      P2MP: Point to Multi-Point
      PE: Provider Edge
      PHB: Per-Hop Behavior
      PM: Performance Monitoring
      PSN: Packet Switched Network
      PW: PseudoWire
      S-PE: Switching Provider Edge
      SPME: Sub-path Maintenance Entity
      SS-PW: Single-Segment Pseudo Wire
      T-PE: Terminating Provider Edge
      TLV: Type Length Value
      VCCV: Virtual Circuit Connectivity Verification


3.  Analysis of Existing PW OAM Configuration

3.1.  MPLS PW OAM Functions

   Before MPLS-TP standards, PW OAM functions have been implemented by
   [RFC5085], [RFC5885], [RFC4447] and [I-D.ietf-pwe3-static-pw-status].
   [RFC5085] defines Connectivity Verification (CV), which belongs to
   on-demand PW monitoring.  [RFC5885] defines proactive Continuity
   Check (CC), as well as PW and Attachemnt Circuit (AC) status
   notification.  [RFC4447] and [I-D.ietf-pwe3-static-pw-status] give
   some other ways of PW/AC status notification.





Zhang, et al.          Expires September 15, 2011               [Page 4]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


3.2.  Virtual Circuit Connectivity Verification

   The goal of Virtual Circuit Connectivity Verification (VCCV) is to
   verify and further diagnose PW forwarding path, and the extensions of
   [RFC5085] to LDP are to signal VCCV capabilities to a peer Provider
   Edge (PE).

3.3.  VCCV Bidirectional Forwarding Detection

   Four CV types for Bidirectional Forwarding Detection (BFD) by
   combining two types of encapsulation with two types of functionality
   are specified in [RFC5885].  When multiple BFD CV Types are
   advertised, it also describes how to select one to use.

   The extension of [RFC5885] to LDP are 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.

3.4.  PW Status

   PW status codes provide a mechanism to signal the status of PW and AC
   failure.  When PW control plane exists, the PW Status TLV is carried
   in the initial Label Mapping message and Notification message to
   signal all PW status messages.

   The OAM related extensions of [RFC4447] to LDP are to signal PW
   Status TLV to a peer PE, and activate PW status notification function
   after PW is established.  So when an event occurs, an update PW
   status will be sent.

3.5.  Conclusion

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














Zhang, et al.          Expires September 15, 2011               [Page 5]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


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


                     Table 1: IP/MPLS PW OAM Functions


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

4.1.  Continuity Check, Connectivity Verification and Remote Defect
      Indication

   The Proactive CC, CV and Remote Defect Indication (RDI) functions of
   MPLS-TP are based on the extensions to BFD,
   see[I-D.ietf-mpls-tp-cc-cv-rdi].  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 MPLS-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, 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, Single Segment Pseudowire (SS-PW), Multi Segment Pseudowire
   (MS-PW) and Section as well as for Sub-path Maintenance Element
   (SPME), BFD might still need to use discriminator values to identify
   the connection being verified at both ends of the PW.  The
   discriminator values can be statically configured, or signaled via
   LSP Ping or LDP extensions defined in this document.

   Timer negotiation, such as Transmitter (TX)/Receiver (RX) interval is



Zhang, et al.          Expires September 15, 2011               [Page 6]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   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 Maintenance Entity Group End Point Identifier (MEP-ID)
   does not need to be carried, for they can be deduced from the
   advertised FEC (129) TLV, as described in
   [I-D.ietf-mpls-tp-identifiers].

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

   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.

4.2.  Performance Monitoring Loss/Delay

   Performance monitoring (PM) of PWs, especially for packet Loss
   Measurement (LM) and packet Delay Measurement (DM), are specified in
   [I-D.ietf-mpls-loss-delay], [I-D.ietf-mpls-tp-loss-delay-profile].

   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.

4.3.  FMS

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

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




Zhang, et al.          Expires September 15, 2011               [Page 7]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


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

4.4.  On-demand OAM Functions

   The extended on-demand OAM functions MAY need capability negotiation
   in the LDP Initialization message [RFC5561].  However, On-demand PW
   OAM functions are expected to be carried out by directly accessing
   network nodes via a management interface; hence configuration and
   control of on-demand PW OAM functions are out-of-scope for this
   document.

4.5.  Conclusion

   According to the analysis above, LDP needs to be extended 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 2 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     |



Zhang, et al.          Expires September 15, 2011               [Page 8]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   |            |               |configuration&|configuration&|configuration&|
   |            |               |Bootstrapping |Bootstrapping | Bootstrapping|
   |------------|------------------------------------------------------------|


                     Table 2: MPLS-TP PW OAM Functions


5.  MPLS-TP PW OAM Capability Advertisement

   When a PW is first set up, the PEs MUST attempt to negotiate the
   usage of OAM functions.  At the time of writing this specification,
   there are PW status negotiation and VCCV capability advertisement.
   For the proactive OAM functions as extended to support by MPLS-TP,
   such as CC-CV-RDI, PM loss/delay and FMS, the capability negotiation
   MAY be also needed, so a PE that supports the MPLS-TP PW OAM
   capability MUST include MPLS-TP PW OAM Capability TLV in the LDP
   Initialization message.  And if the peer has not advertised this
   capability, the corresponding PW OAM configuration information will
   not be sent to the peer.


6.  PW OAM Configurationd Procedures

   A PE may play an 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.

6.1.  Establishment of OAM Entities and Functions

   Assuming there is one PW that needs to be setup between T-PE1 and
   T-PE2, across S-PE1 and S-PE2.  OAM functions must be setup and



Zhang, et al.          Expires September 15, 2011               [Page 9]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   enabled in the appropriate order so that spurious alarms can be
   avoided.

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


                 Figure 1: MS-PW OAM Configuration Scheme

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

   When the Mapping message arrives at the downstream 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 Notification 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 Administration TLV.  When T-PE1 receives the Mapping message,
   it completes any pending OAM configuration and enables the OAM source
   function to send OAM messages.

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



Zhang, et al.          Expires September 15, 2011              [Page 10]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


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

6.2.  Adjustment of OAM Parameters

   There may be a need to change the parameters of an already
   established and configured OAM function during the lifetime of the
   PW.  To do so the T-PE nodes need to send a Notification message with
   the updated parameters.  OAM parameters that influence the content
   and timing of OAM messages and identify the way OAM defects and
   alarms are derived and generated.  Hence, to avoid spurious alarms,
   it is important that both sides, OAM sink and source, are updated in
   a synchronized way.  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 a
   Notification message with "OAM Alarms Enabled" cleared and including
   the updated MPLS-TP PW OAM Configuration TLV corresponding to the new
   parameter settings.  The initiator (T-PE1) MUST keep its OAM sink and
   source functions running unmodified, but it MUST suppress OAM alarms
   after the updated Notification message is sent.  The receiver (T-PE2)
   MUST 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 when it has received the Notification message from the
   peer.  After the OAM parameters are updated and OAM is running
   according the new parameter settings, OAM alarms are still disabled,
   so a subsequent Notification messages exchanges with "OAM Alarms
   Enabled" flag set are needed to enable OAM alarms again.





Zhang, et al.          Expires September 15, 2011              [Page 11]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


6.3.  Deleting OAM Entities

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

   The T-PE nodes disable OAM alarms and SHOULD send Notification
   message to each other with "OAM Alarms Enabled" cleared but unchanged
   OAM configuration and without the MPLS-TP PW OAM Configuration TLV.
   After that, T-PE1 (T-PE2) SHOULD delete OAM source functions, then
   send a Notification message with "OAM 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.


7.  LDP extensions

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

7.1.  MPLS-TP PW OAM Capability TLV

   A new Capability Parameter TLV called the MPLS-TP PW OAM Capability
   TLV is defined, and the format 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1|0|              Type (TBD)   |     Length (= 4)              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |1| Reserved    |                 Reserved                |F|D|L|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       MPLS-TP PW OAM Capability TLV

   The value of the U-bit for the MPLS-TP PW OAM Capability TLV MUST be
   set to 1 so that a receiver MUST silently ignore this TLV if unknown
   to it, and continue processing the rest of the message.  Currently



Zhang, et al.          Expires September 15, 2011              [Page 12]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   defined specific OAM Capability Flags in the "Capability Data" field
   from right to left are:


   One bit "L" (0, IANA to assign)             PM Loss supported
   One bit "D" (1, IANA to assign)             PM Delay supported
   One bit "F" (2, IANA to assign)             FMS supported


   The above bits can be set individually to indicate more than one kind
   of OAM capabilities at once, and the other reserved bits MUST be set
   to zero on transmission and MUST be ignored on receipt.

   The MPLS-TP PW OAM Capability TLV MAY be included by a PE in an
   Initialization message to signal its peer that it supports the
   MPLS-TP PW OAM Capability.  If the remote peer does not support the
   MPLS-TP PW OAM Capability TLV or the Initialization message sent by
   the remote peer does not include the MPLS-TP PW OAM Capability TLV,
   which indicates that the negotiation results do not support MPLS-TP
   PW OAM capability.  If the negotiation process results support the
   MPLS-TP PW OAM capability, then the subsequent LDP Mapping message
   will carry the information of the MPLS-TP PW OAM configuration.

7.2.  MPLS-TP PW OAM Administration TLV

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

           0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0|0|          Type (TBD)     |            Length               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |E|I|A|         Reserved                                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     MPLS-TP PW OAM Administration TLV

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



Zhang, et al.          Expires September 15, 2011              [Page 13]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   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 Notification message MUST
   be sent.

   One bit "A" (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 Notification message MUST be sent.

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

7.3.  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,
   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 (TBD)          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    OAM Type   |                Reserved                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           sub-TLVs                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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



Zhang, et al.          Expires September 15, 2011              [Page 14]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   message again with the same flags carried in the received Label
   Mapping message.

7.3.1.  BFD Configuration TLV

   BFD Configuration TLV follows the same TLV structure defined for
   Resource ReSerVation Protocol Traffic Engineering (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 identifier.  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.

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

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






Zhang, et al.          Expires September 15, 2011              [Page 15]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


7.3.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: Client Signal Fail (CSF) are overlapped with PW Status TLV,
   and the field of Refresh Timer is not needed.


8.  IANA Considerations

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

   Sub-TLV types to be carried in the "MPLS-TP PW OAM Configuration
   TLV":
   o  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.
   o  BFD Authentication sub-TLV


9.  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 September 15, 2011              [Page 16]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


10.  Acknowledgement

   The authors would like to thank Thomas Nadeau for his valuable
   comments, Eric Gray for his review of this document.


11.  References

11.1.  Normative references

   [I-D.ietf-ccamp-oam-configuration-fwk]
              Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE
              extensions for OAM Configuration",
              draft-ietf-ccamp-oam-configuration-fwk-04 (work in
              progress), October 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-05 (work in
              progress), March 2011.

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

   [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
              Framework for MPLS-based Transport Networks",
              draft-ietf-mpls-tp-oam-framework-11 (work in progress),
              February 2011.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Zhang, et al.          Expires September 15, 2011              [Page 17]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

11.2.  Informative References

   [I-D.ietf-mpls-loss-delay]
              Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks",
              draft-ietf-mpls-loss-delay-01 (work in progress),
              February 2011.

   [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-03 (work
              in progress), February 2011.

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

   [I-D.ietf-mpls-tp-identifiers]
              Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
              Identifiers", draft-ietf-mpls-tp-identifiers-04 (work in
              progress), March 2011.

   [I-D.ietf-mpls-tp-loss-delay-profile]
              Frost, D. and S. Bryant, "A Packet Loss and Delay
              Measurement Profile for MPLS-based Transport Networks",
              draft-ietf-mpls-tp-loss-delay-profile-02 (work in
              progress), February 2011.

   [I-D.ietf-mpls-tp-lsp-ping-bfd-procedures]
              Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher,



Zhang, et al.          Expires September 15, 2011              [Page 18]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


              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, "OAM
              functions in MPLS based transport network",
              draft-ietf-mpls-tp-oam-analysis-03 (work in progress),
              January 2011.

   [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., Heron, G., and M. Bocci,
              "Pseudowire Status for Static Pseudowires",
              draft-ietf-pwe3-static-pw-status-02 (work in progress),
              March 2011.

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

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

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



Zhang, et al.          Expires September 15, 2011              [Page 19]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   [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


   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




Zhang, et al.          Expires September 15, 2011              [Page 20]


Internet-Draft        LDP Extensions for TP PW OAM            March 2011


   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 September 15, 2011              [Page 21]


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