Network Working Group                                          A. Takacs
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                D. Fedyk
Expires: April 29, August 1, 2010                                   Alcatel-Lucent
                                                                   J. He
                                                                  Huawei
                                                        October 26, 2009
                                                        January 28, 2010

     OAM Configuration Framework and Requirements for GMPLS RSVP-TE
               draft-ietf-ccamp-oam-configuration-fwk-02
               draft-ietf-ccamp-oam-configuration-fwk-03

Abstract

   OAM is an integral part of transport connections, hence it is
   required that OAM functions are activated/deactivated in sync with
   connection commissioning/decommissioning; avoiding spurious alarms
   and ensuring consistent operation.  In certain technologies OAM
   entities are inherently established once the connection is set up,
   while other technologies require extra configuration to establish and
   configure OAM entities.  This document specifies extensions to
   RSVP-TE to support the establishment and configuration of OAM
   entities along with LSP signaling.

Requirements Language

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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, August 1, 2010.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   OAM is an integral part of transport connections, hence it is
   required that OAM functions are activated/deactivated in sync with
   connection commissioning/decommissioning; avoiding spurious alarms
   and ensuring consistent operation.  In certain technologies OAM
   entities are inherently established once the connection is set up,
   while other technologies require extra configuration to establish and
   configure OAM entities.  This  Code Components extracted from this document specifies extensions to
   RSVP-TE to support the establishment and configuration must
   include Simplified BSD License text as described in Section 4.e of OAM
   entities along with LSP signaling.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   the Trust Legal Provisions and "OPTIONAL" in this
   document are to be interpreted provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  GMPLS RSVP-TE Extensions based OAM Configuration  . . . . . . . . . . . . . . . .  8
     3.1.  Establishment of OAM Entities and Functions  . . .  9
     3.1.  Operation overview . . . .  8
     3.2.  Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10
     3.3.  Deleting OAM Entities  .  9
     3.2.  LSP Attributes flags . . . . . . . . . . . . . . . . . 10
   4.  RSVP-TE Extensions . . 10
     3.3.  OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
     3.4.  TCME Configuration TLV . . 12
     4.1.  LSP Attributes Flags . . . . . . . . . . . . . . . . . . 13
     3.5.  NIME . 12
     4.2.  OAM Configuration TLV  . . . . . . . . . . . . . . . . . . 12
       4.2.1.  OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14
     3.6.  Monitoring Disabled - Admin_Status bit
       4.2.2.  Technology Specific sub-TLVs . . . . . . . . . . 15
     3.7.  OAM configuration errors . . . 14
     4.3.  Administrative Status Information  . . . . . . . . . . . . 14
     4.4.  Handling OAM Configuration Errors  . . . . . . . . . . . . 15
   4.
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   5. 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   6. 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 18
   Appendix A.  Discussion on alternatives Alternatives  . . . . . . . . . . . . . 20
   7. 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 22

1.  Introduction

   GMPLS is designed as an out-of-band control plane supporting dynamic
   connection provisioning for any suitable data plane technology;
   including spatial switching (e.g., incoming port or fiber to outgoing
   port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
   division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet
   Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS
   Transport Profile (MPLS-TP).  In most of these technologies there are
   Operations and Management (OAM) functions employed to monitor the
   health and performance of the connections and to trigger data plane
   (DP) recovery mechanisms.  Similarly to connections, OAM functions
   follow general principles but also have some technology specific
   characteristics.

   OAM is an integral part of transport connections, hence it is
   required that OAM functions are activated/deactivated in sync with
   connection commissioning/decommissioning; avoiding spurious alarms
   and ensuring consistent operation.  In certain technologies OAM
   entities are inherently established once the connection is set up,
   while other technologies require extra configuration to establish and
   configure OAM entities.  In some situations the use of OAM functions,
   like those of Fault- (FM) and Performance Management (PM), may be
   optional confirming to actual network management policies.  Hence the
   network operator must be able to choose which kind of OAM functions
   to apply to specific connections and with what parameters the
   selected OAM functions should be configured and operated.  To achieve
   this objective OAM entities and specific functions must be
   selectively configurable.

   In general, it is required that the management plane and control
   plane connection establishment mechanisms are synchronized with OAM
   establishment and activation.  In particular, if the GMPLS control
   plane is employed it is desirable to bind OAM setup and configuration
   to connection establishment signaling to avoid two separate
   management/configuration steps (connection setup followed by OAM
   configuration) which increases delay, processing and more importantly
   may be prune to misconfiguration errors.  Once OAM entities are setup
   and configured configured, pro-active as well as on-demand OAM functions can be
   activated via the management plane.  On the other hand, it should be
   possible to activate/deactivate pro-active OAM functions via the
   GMPLS control plane as well.

   This document describes requirements on OAM configuration and control
   via RSVP-TE, and specifies extensions to the RSVP-TE protocol
   providing a framework to configure and control OAM entities along
   with the capability to carry technology specific information.
   Extensions can be grouped into generic elements that are applicable
   to any OAM solution and technology specific elements that provide
   additional configuration parameters parameters, only needed for a specific OAM
   technology.  This document specifies the technology agnostic elements
   elements, which alone can be used to establish and control OAM
   entities in the case no technology specific information is needed,
   and specifies the way additional technology specific OAM parameters
   are provided.

   This document addresses end-to-end OAM configuration, that is, the
   setup of OAM entities bound to an end-to-end LSP, and configuration
   and control of OAM functions running end-to-end in the LSP.
   Configuration of OAM entities for LSP segments and tandem connections
   are out of the scope of this document.

   The mechanisms described in this document provide an additional
   option for bootstrapping OAM that is not intended to replace or
   deprecate the use of other technology specific OAM bootstrapping
   techniques; e.g., LSP Ping [RFC4379] for MPLS networks.  The
   procedures specified in this document are intended only for use in
   environments where RSVP-TE signaling is already in use to set up the
   LSPs that are to be monitored using OAM.

2.  Requirements

   MPLS OAM requirements are described in [RFC4377].  It [RFC4377], which provides
   requirements to create consistent OAM functionality for MPLS
   networks.  GMPLS OAM requirements are described in [GMPLS-OAM].  The
   GMPLS OAM requirements are based on the MPLS OAM requirements
   [RFC4377], in addition it also considers the existing OAM techniques
   in non-packet networks.

   The following list is an excerpt of MPLS OAM requirements documented
   in [RFC4377].  Only a few requirements are discussed that bear a
   direct relevance to the discussion set forth in this document.

   o  It is desired to support the automation of LSP defect detection.
      It is especially important in cases where large numbers of LSPs
      might be tested.

   o  In particular some LSPs may require automated ingress-LSR to
      egress-LSR testing functionality, while others may not.

   o  Mechanisms are required to coordinate network responses to
      defects.  Such mechanisms may include alarm suppression,
      translating defect signals at technology boundaries, and
      synchronizing defect detection times by setting appropriately
      bounded detection timeframes.

   MPLS-TP defines a profile of MPLS targeted at transport applications
   [MPLS-TP-FWK].  This profile specifies the specific MPLS
   characteristics and extensions required to meet transport
   requirements, including providing additional OAM, survivability and
   other maintenance functions not currently supported by MPLS.
   Specific OAM requirements for MPLS-TP are specified in
   [MPLS-TP-OAM-REQ].  MPLS-TP poses requirements on the control plane
   to configure and control OAM entities. entities:

   o  The use of OAM functions SHOULD be optional for the operator.  A
      network operator SHOULD be able to choose which OAM functions to
      use and which Maintenance Entity to apply them to.

   o  The MPLS-TP control plane MUST support the configuration and
      modification of OAM maintenance points as well as the activation/
      deactivation of OAM when the transport path is established or
      modified.  OAM functions SHOULD be configurable as part of
      connectivity (LSP or PW) management.

   Ethernet Connectivity Fault Management (CFM) defines an adjunct
   connectivity monitoring OAM flow to check the liveliness of Ethernet
   networks [IEEE-CFM].  With PBB-TE [IEEE-PBBTE] Ethernet networks will
   support explicitly-routed Ethernet connections.  CFM can be used to
   track the liveliness of PBB-TE connections and detect data plane
   failures.  In IETF the GMPLS controlled Ethernet Label Switching
   (GELS) [GELS-Framework] work is extending the GMPLS control plane to
   support the establishment of point-to-point PBB-TE data plane
   connections.  Without control plane support separate management
   commands would be needed to configure and start CFM.

   GMPLS based OAM configuration and control should be general to be
   applicable to a wide range of data plane technologies and OAM
   solution.
   solutions.  There are three typical data plane technologies used for
   transport application, which are wavelength based such as WSON, TDM
   based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK]
   and Ethernet PBB-TE [IEEE-PBBTE].  In all these data planes, the
   operator MUST be able to configure and control the following OAM
   functions.

   o  It MUST be possible to explicitly request the setup of OAM
      entities for the signaled LSP and provide specific information for
      the setup if this is required by the technology.

   o  Control of alarms is important to avoid false alarm indications
      and reporting to the management system.  It MUST be possible to
      enable/disable alarms generated by OAM functions.  In some cases
      selective alarm control may be desirable when, for instance, the
      operator is only concerned about critical alarms thus the non-
      service affecting alarms should be inhibited.

   o  When periodic messages are used for liveliness check (continuity
      check) of LSPs it MUST be possible to set the frequency of
      messages allowing proper configuration for fulfilling the
      requirements of the service and/or meeting the detection time
      boundaries posed by possible congruent connectivity check
      operations of higher layer applications.  For a network operator
      to be able to balance the trade-off in fast failure detection and
      overhead it is beneficial to configure the frequency of continuity
      check messages on a per LSP basis.

   o  Pro-active Performance Monitoring (PM) functions are continuously
      collecting information about specific characteristics of the
      connection.  For consistent measurement of Service Level
      Agreements (SLAs) it may be required that measurement points agree
      on a common probing rate to avoid measurement problems.

   o  The extensions must MUST allow the operator to use only a minimal set
      of OAM configuration and control features if the data plane
      technology, the OAM solution or network management policy allows.
      The extensions must be reusable as much as reasonably possible.
      That is generic OAM parameters and data plane or OAM technology
      specific parameters must be separated.

3.  GMPLS RSVP-TE Extensions

3.1.  Operation overview based OAM Configuration

   In general, two types of Maintenance Poits (MPs) can be
   distinguished: Maintenance End Points (MEPs) and Maintenance
   Intermediate Points (MIPs).  MEPs reside at the ends of an LSP and
   are capable of initiating and terminating OAM messages for Fault
   Management (FM) and Performance Monitoring (PM).  MIPs on the other
   hand are located at transit nodes of an LSP and are capable of
   reacting to some OAM messages but otherwise do not initiate messages.
   Maintenance Entity (ME) refers to an association of MEPs and MIPs
   that are provisioned to monitor an LSP.  The ME association is
   achieved by configuring MPs of an ME with to belong to the same unique ME Assocication ID (MA ID).  Each MEP must have
   unique identification (MEP ID) within a Maintenance Entity. ME.

   When an LSP is signaled signaled, forwarding association is established
   between endpoints and transit nodes via label bindings.  This
   association creates a context for the OAM entities monitoring the
   LSP.  On top of this association OAM entities may be configured with an MA ID and MEP
   IDs.  The MA ID may be used to detect misconfiguration errors and
   leaking OAM traffic.  While the MEP ID can be used to demultiplex and
   unambigously identify the originating MEP of OAM messages.  Since MIPs do not
   originate OAM packets, on top of the configuration of Maintenance
   Entity associations, no specific configuration is required for them.

   Along the LSP several Tandem Connections may be provisioned and
   associated to the end-to-end connection.  These Tandem Connections
   may implement their own OAM monitoring entities.  The Tandem
   Connection Maintenance Entities (TCMEs) provide the same monitoring
   capabilities for a segment of a connection as what is possible on an
   end-to-end basis.  As the endpoints of a TCME may be (and usually
   are) intermediate nodes of an end-to-end LSP, the placement of TCME
   ingress and egress endpoints must be explicitly identified.

   Altough provisioned together with the end-to-end connection, each
   TCME defines a new context for the OAM entities, which is independent
   from the end-to-end connection.  The MA ID MPs and MEP IDs for a TCME are
   within this new context.

   When an LSP is signaled Non-Intrusive Maintenance Elements (NIME) may
   be deployed along the path.  These elements differ from the MIPs as
   they implemetn egress MEP functions: they not only process OAM
   messages but they can also trigger consequent actions, for instance,
   initiate segment protection switching.  The NIMEs belong to the OAM
   entity context of the end-to-end LSP and, thus, the same MA ID is
   applied.  As the NIMEs are placed at intermediate nodes, their
   placement must be explicitly indicated. MEs.

   In addition to the MA MP and MEP ME identification parameters pro-active OAM
   functions (e.g., Continuity Check (CC), Performance Monitoring) may
   have specific parameters requiring configuration as well.  In
   particular, the frequency of periodic CC packets and the measurement
   interval for loss and delay measurements may need to be configured.

                                 MEP
                           +-------------+
                           |OAM Functions|
                           | FM   |   PM |
                           +------+------+
                           |    MEP ID   |
                           +-------------+
                           |    MA ID    |
                           +-------------+
                           +-------------+
                           | connection  |
                           +-------------+

   In some cases all the above parameters may be either derived form
   some exiting information or pre-configured default values can be
   used.  In the simplest case the control plane needs to provide
   information whether or not a MA with MPs OAM entities need to be setup for the
   signaled LSP.  If OAM entities are created signaling must provide
   means to activate/deactivate OAM message flows and associated alarms.

   MA and MEP IDs

   OAM identifiers as well as the configuration of OAM functions are
   technology specific, i.e., vary depending on the data plane
   technology and the chosen OAM solution.  In addition, for any given
   data plane technology a set of OAM solutions may be applicable.  The
   OAM configuration framework allows selecting a specific OAM solution
   to be used for the signaled LSP and provides technology specific TLVs
   to carry further detailed configuration information.

3.2.  LSP Attributes flags

   In RSVP-TE the Flags field

3.1.  Establishment of the SESSION_ATTRIBUTE object is used OAM Entities and Functions

   In order to
   indicate options avoid spurious alarms OAM functions must be setup and attributes of
   enabled in the LSP.  The Flags field has 8
   bits appropriate order.  When using the GMPLS control
   plane, establishment and hence is limited to differentiate only 8 options.  [RFC4420]
   defines new objects for RSVP-TE messages to allow the signaling enabling of
   arbitrary attribute parameters making RSVP-TE easily extensible OAM functions must be bound to
   support new applications.  Furthermore, [RFC4420] allows options
   RSVP-TE message exchanges.

   An LSP may be signaled and
   attributes that do not need to established without OAM configuration
   first, and OAM entities may be acted on by all Label Switched
   Routers (LSRs) along the path added later with a subsequent re-
   signaling of the LSP.  In particular, these
   options and attributes  Alternatively, the LSP may be setup with OAM
   entities right with the first signaling of the LSP.  The below
   procedures apply only to key LSRs on the path such as both cases.

   Before the ingress LSR and egress LSR.  Options initiator first sends a Path messages with OAM
   Configuration information, it MUST establish and attributes can configure the
   corresponding OAM entities locally, however OAM source functions MUST
   NOT start sending any OAM messages.  In the case of bidirectional
   connections, the initiator node MUST setup the OAM sink function to
   be
   signaled transparently, and only examined at those points that need prepared to act on them. receive OAM messages but MUST suppress any OAM alarms
   (e.g., due to missing or unidentified OAM messages).  The LSP_ATTRIBUTES and Path
   message MUST be sent with the LSP_REQUIRED_ATTRIBUTES
   objects "OAM Alarms Enabled" ADMIN_STATUS flag
   cleared, i.e, data plane OAM alarms are defined in [RFC4420] to provide means to signal LSP
   attributes and options in suppressed.

   When the form of TLVs.  Options Path message arrives at the receiver, the remote end MUST
   establish and attributes
   signaled in configure OAM entities according to the LSP_ATTRIBUTES object can be passed transparently
   through LSRs OAM information
   provided in Path message.  If this is not supporting possible a particular option or attribute, while
   the contents of the LSP_REQUIRED_ATTRIBUTES object must PathErr SHOULD
   be examined sent and processed by each LSR.  One TLV is defined in [RFC4420]: neither the
   Attributes Flags TLV.

   One bit (10 IANA to assign): "OAM MEP OAM entities desired" is allocated
   in nor the LSP Attributes Flags TLV. SHOULD be
   established.  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 LSP.  If established successfully, the
   establishment of MEPs is not supported an error must OAM
   sink function MUST be generated:
   "OAM Problem/MEP establishment prepared to receive OAM messages but MUST not supported".

   If the "OAM MEP entities desired" bit is set and additional
   parameters are needed
   generate any OAM alarms (e.g., due to configure the missing or unidentified OAM entities
   messages).  In the case of bidirectional connections, an OAM
   Configuration TLV may source
   function MUST be included in the LSP_ATTRIBUTES object.

   One bit (11 IANA setup and, according to assign): "OAM MIP entities desired" is allocated
   in the LSP Attributes Flags TLV.  If the "OAM MIP entities desired"
   bit is set requested configuration,
   it MUST start sending OAM messages.  Then a Resv message is indicating sent
   back, including the OAM Configuration TLV that corresponds to the establishment of
   actually established and configured OAM MIP entities are required at and functions.
   Depending on the transit nodes OAM technology, some elements of the signaled LSP.  This
   bit can only OAM
   Configuration TLV MAY be set updated/changed; i.e., if the "OAM MEP entities desired" bit is set.  If
   the establishment of MIPs remote end is
   not supported supporting a certain OAM configuration it may suggest an error must be
   generated: "OAM Problem/MIP establishment
   alternative setting, which may or may not supported".

   One bit (12 IANA to assign): "Alarm indication desired" is allocated
   in be accepted by the LSP Attributes Flags TLV.  If
   initiator of the "Alarm indication desired"
   bit is set Path message.  If it is indicating that accepted, the initiator will
   reconfigure its OAM entities of functions according to the signaled LSP
   should be notified of lower layer failures.  In information received
   in the case Resv message.  If the alternate setting is not acceptable a
   ResvErr may be sent tearing down the LSP.  Details of
   hierarchical LSPs this will create an association between operation
   are technology specific and should be described in accompanying
   technology specific documents.

   When the
   underlying (server) LSP's initiating side receives the Resv 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 currently signaled
   (client) LSP's
   LSP and OAM entities.

3.3. messages MAY already be exchanged.  OAM Configuration TLV

   This TLV specifies which alarms can now be
   enabled.  The initiator, while still keeping OAM technology/method should alarms disabled
   sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set.
   The receiving node enables the OAM alarms after processing the Path
   message.  The initiator enables OAM alarms after it receives the Resv
   message.  Data plane OAM is now fully functional.

3.2.  Adjustment of OAM Parameters

   There may be used for a need to change the parameters of an already
   established and configured OAM function during the lifetime of the
   LSP.  The  To do so the LSP needs to be re-signaled with the updated
   parameters.  OAM Configuration TLV parameters 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 carried important that
   both sides, OAM sink and source, are updated in a synchronized way.
   First, the alarms of the LSP_ATTRIBUTES
   object in Path messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (2) (IANA)     |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OAM Type   |   Reserved    | sink function should be suppressed and
   only then should expected OAM Function          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: indicates a new type: parameters be adjusted.  Subsequently,
   the parameters of the OAM Configuration TLV (2) (IANA source function can be updated.  Finally,
   the alarms of the OAM sink side can be enabled again.

   In accordance with the above operation, the LSP MUST first be re-
   signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared and
   including the updated OAM Configuration TLV corresponding to the new
   parameter settings.  The initiator MUST keep its OAM sink and source
   functions running unmodified, but it MUST suppress OAM alarms after
   the updated Path message is sent.  The receiver MUST first disable
   all OAM alarms, then update the OAM paramaters according to the
   information in the Path message and reply with a Resv message
   acknowledging the changes by including the OAM Configuration TLV.
   Note that the receiving side has the possibility to adjust the
   requested OAM configuration parameters and reply with and updated OAM
   Configuration TLV in the Resv 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 Path message to an extent that would provide lower
   performance than what has been configured previously.

   The initiator MUST only update its OAM sink and source functions
   after it received the Resv message.  After this Path/Resv message
   exchange (in both unidirectional and bidirectional LSP cases) the OAM
   parameters are updated and OAM is running according the new parameter
   settings.  However OAM alarms are still disabled.  A subsequent Path/
   Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set
   is needed to enable OAM alarms again.

3.3.  Deleting OAM Entities

   In some cases it may be useful to remove some or all OAM entities and
   functions from an LSP without actually tearing down the connection.

   To avoid any spurious alarm, first the LSP SHOULD be re-signaled with
   "OAM Alarms" ADMIN_STATUS flag cleared but unchanged OAM
   configuration.  Subsequently, the LSP is re-signaled with "OAM MEP
   Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
   cleared, and without the OAM Configuration TLV, this MUST result in
   the deletion of all OAM entities associated with the LSP.  All
   control and data plane resources in use by the OAM entities and
   functions SHOULD be freed up.  Alternatively, if only some OAM
   functions need to be removed, the LSP is re-signalled with the
   updated OAM Configuration TLV.  Changes between the contents of the
   previously signalled OAM Configuration TLV and the currently received
   TLV represent which functions SHOULD be removed/added.

   First, OAM source functions SHOULD be deleted and only after that
   SHOULD the associated OAM sink functions be removed, this will ensure
   that OAM messages do not leak outside the LSP.  To this end the
   initiator, before sending the Path message, SHOULD remove the OAM
   source, hence terminating the OAM message flow associated to the
   downstream direction.  In the case of a bidirectional connection, it
   SHOULD leave in place the OAM sink functions associated to the
   upstream direction.  The remote end, after receiving the Path
   message, SHOULD remove all associated OAM entities and functions and
   reply with a Resv message without an OAM Configuration TLV.  The
   initiator completely removes OAM entities and functions after the
   Resv message arrived.

4.  RSVP-TE Extensions

4.1.  LSP Attributes Flags

   In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to
   indicate options and attributes of the LSP.  The Flags field has 8
   bits and hence is limited to differentiate only 8 options.  [RFC5420]
   defines new objects for RSVP-TE messages to allow the signaling of
   arbitrary attribute parameters making RSVP-TE easily extensible to
   support new applications.  Furthermore, [RFC5420] allows options and
   attributes that do not need to be acted on by all Label Switched
   Routers (LSRs) along the path of the LSP.  In particular, these
   options and attributes may apply only to key LSRs on the path such as
   the ingress LSR and egress LSR.  Options and attributes can be
   signaled transparently, and only examined at those points that need
   to act on them.  The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES
   objects are defined in [RFC5420] to provide means to
   assign).

   OAM Type: specifies signal LSP
   attributes and options in the technology specific OAM method.  If form of TLVs.  Options and attributes
   signaled in the
   requested OAM method is LSP_ATTRIBUTES object can be passed transparently
   through LSRs not supported an error supporting a particular option or attribute, while
   the contents of the LSP_REQUIRED_ATTRIBUTES object must be generated:
   "OAM Problem/Unsupported OAM Type".

   This document defines no types.  The receiving node based on examined
   and processed by each LSR.  One TLV is defined in [RFC5420]: the OAM
   Type will check if a corresponding technology specific OAM
   configuration sub-TLV
   Attributes Flags TLV.

   One bit (10 IANA to assign): "OAM MEP entities desired" is included. allocated
   in the LSP Attributes Flags TLV.  If different technology specific
   OAM configuration sub-TLV the "OAM MEP entities desired"
   bit is included than what was specified in set it is indicating that the establishment of OAM Type MEP
   entities are required at the endpoints of the signaled LSP.  If the
   establishment of MEPs is not supported an error must be generated:
   "OAM Problem/OAM Type Mismatch".

       OAM Type             Description
     ------------      --------------------
        0-255                Reserved

   There is a hierarchy in between the OAM configuration elements.
   First, Problem/MEP establishment not supported".

   If the "OAM MEP (and MIP) entities desired" flag needs to be set,
   if it bit is set and additional
   parameters are needed to be configured the OAM entities an "OAM OAM
   Configuration TLV" TLV may be included in the LSP_ATTRIBUTES object, if this TLV object.

   One bit (11 IANA to assign): "OAM MIP entities desired" is present based on allocated
   in the OAM Type a
   technology specific OAM configuration sub-TLV may LSP Attributes Flags TLV.  This bit can only be present.  If
   this hierarchy set if the
   "OAM MEP entities desired" bit is broken (e.g., set.  If the "OAM MEP MIP entities
   desired" flag bit is
   not set but an OAM Configuration TLV in the LSP_ATTRIBUTES Flags TLV, it is present an error must be
   generated: "OAM Problem/Configuration Error".

   OAM Function Flags: specifies pro-active OAM functions (e.g.,
   connectivity monitoring, loss and delay measurement) indicating
   that should be
   established and configured.  If the selected establishment of OAM Function(s) is(are) MIP entities is required at every
   transit node of the signalled LSP.  If the establishment of a MIP is
   not supported an error must be generated: "OAM Problem/Unsupported
   OAM Function".

   This document defines the following flags. Problem/MIP
   establishment not supported".

4.2.  OAM Function Flag                Description
     ---------------------      ---------------------------
             0                   Connectivity Monitoring
             1                   Performance Monitoring/Loss
             2                   Performance Monitoring/Delay

3.4.  TCME Configuration TLV

   Two TCME Configuration TLVs together specify a Tandem Connection
   Monitoring entity: they designate the TCM ingress

   This TLV provides information about which OAM technology/method
   should be used and TCM egress
   MEPs, respectively.  TCME carries sub-TLVs for any additional OAM
   configuration information.  The OAM Configuration TLVs are TLV may be carried
   in
   HOP_ATTRIBUTES subobjects [HOP_ATTR] in the ERO, the corresponding
   node LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in the ERO identifies where TCME MEP is placed.  Both TCME
   Configuration TLVs of the same TCME must specify the same OAM
   technology Path and method.
   Resv messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (2) (IANA)     |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    OAM Type    |H|M|  Level   |        OAM Functions                 Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SUB TLVs                                                               |
   ~                           sub-TLVs                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: indicates a new type: the TCME OAM Configuration TLV (2) (IANA to
   assign).

   OAM Type: specifies the technology specific OAM method.  The OAM Type
   values defined for OAM Configuration TLV are applied here.  If the
   requested OAM method is not supported an error must be generated:
   "OAM Problem/Unsupported OAM Type".

   One bit (Flag H)

       OAM Type             Description
     ------------      --------------------
        0-255                Reserved

   This document defines no types.  IANA is allocated requests to indicate which endpoint of a TCME is
   encoded by maintain the TCME
   values in a new "RSVP-TE OAM Configuration TLV.  Setting this flag indicates
   the ingress endpoints while clearing it indicates Registry".

   The receiving node based on the egress one.

   One bit (Flag M) "TCME MIP entities desired" is allocated.  This flag
   indicates OAM Type will check if a
   corresponding technology specific OAM MIP entities monitoring the TCME are required. configuration sub-TLV is
   included.  If
   this function the included technology specific OAM configuration sub-
   TLV is not supported different than what is specified in the OAM Type an error must
   be generated: "OAM
   Problem/TCME MIP establishment not supported".

   Level provides Problem/OAM Type Mismatch".

   Note that there is a key for the ingress node to determine the egress of hierarchical dependency in between the same TCME.  Therefore, OAM
   configuration elements.  First, the same Level values must "OAM MEP (and MIP) entities
   desired" flag needs to be set.  When it is set to an "OAM Configuration
   TLV" may be included in the
   ingress and egress endpoints of LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
   Object.  When this TLV is present, based on the same TCME.  Overlapping
   (including nesting) TCM "OAM Type" field, it
   may carry a technology specific OAM configuration sub-TLV.  If this
   hierarchy is broken (e.g., "OAM MEP entities must use different Level values, but
   two entries desired" flag is not having common segments may use the same Level value.
   Value 0 set
   but an OAM Configuration TLV is reserved and present) an error must not be used to identify a TCM entity.
   Futher technology specific constraints of generated:
   "OAM Problem/Configuration Error".

4.2.1.  OAM Function Flags Sub-TLV

   As the Level value may first sub-TLV one "OAM Function Flags sub-TLV" MUST be
   defined by accompying documents.

   OAM always
   included in the "OAM Configuration TLV".  "OAM Function Flags: Flags"
   specifies which pro-active OAM functions (e.g., connectivity
   monitoring, loss and delay measurement) that should be
   established and configured.  Same flags are applied as for OAM
   Configuration TLV.

   Both TLVs may contain technology sub-TLVs and the encoded sub-TLVs
   are relevant to the referred monitoring endpoint.  The TCM ingress
   may update the OAM configuration of the egress point by changing
   already defined sub-TLVs or by adding new sub-TLVs.

   If the node, where TCME endpoint is to which fault management
   signals MUST be configured, does not
   support that feature, must generate an error: "OAM Problem/TCM not
   supported".

   Since a TCME Configuration TLV pair encodes a TCME, the ingress node
   must check if a proper TCME Configuration TLV encoding the egress MEP
   is included in the ERO.  If no such TLV (i.e., the same Level value
   is set and flag H is cleared) is found established and configured.  If the selected OAM
   Function(s) is(are) not supported, an error must be generated: "OAM Problem/TCM Egress is not properly configured".

   The above check ensures that a TCM egress will not be configured
   without peering TCM ingress.  Therefore, there is no need TCME
   ingress checking procedure at the TCME egress.

3.5.  NIME Configuration TLV

   Inserting a NIME Configuration TLV into a HOP_ATTRIBUTES object
   [HOP_ATTR] indicates that a non-intrusive monitoring element is to be
   configured.  Futhermore, it encodes what
   Problem/Unsupported OAM technology and method
   should be used at that entity. Function".

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (3) (1) (IANA)     |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OAM Type    |D|U|  Level                                                               |
   ~                      OAM Functions          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Function Flags                       ~
   |                          SUB TLVs                                                               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type: indicates a new type:

   This document defines the NIM OAM Configuration TLV (3) (IANA
   to assign). following flags.

       OAM Type: specifies the Function Flag                Description
     ---------------------      ---------------------------
             0                   Continuity Check (CC)
             1                   Connectivity Verification (CV)
             2                   Performance Monitoring/Loss (PM/Loss)
             3                   Performance Monitoring/Delay (PM/Delay)

4.2.2.  Technology Specific sub-TLVs

   One technology specify OAM method.  If the
   requested OAM method is not supported an error must specific sub-TLV SHOULD be generated: defined for each "OAM Problem/Unsupported OAM
   Type".  The same  This sub-TLV MUST contain any further OAM type values to be
   used as configuration
   information for OAM Configuration TLV.

   Level value indicates which OAM flow of the connection is monitored:
   the end-to-end OAM flow (Level = 0) or TCM entity associated to the
   connection (Level > 0).

   Two bits (Flags D,U) indicates the direction of the monitored entity.
   The downstream traffic is monitored if flag D is set, while setting
   flag U means monitoring the upstream direction.  Both directions are
   monitored if both flags are set.  When both flags are cleared or the
   flag U is set but the LSP is not bidirectional an error must be
   generated: "OAM Problem/Invalid NIM direction defined".

   OAM Function Flags: specifies pro-active OAM functions (e.g.,
   connectivity monitoring, loss and delay measurement) that should specific "OAM Type".  The technology specific
   sub-TLV may be
   established and configured.  Same procedures and flags applied as for carried within the OAM Configuration TLV.

3.6.  Monitoring Disabled - Admin_Status bit

4.3.  Administrative Status Information

   Administrative Status Information is carried in the ADMIN_STATUS
   Object.  The Administrative Status Information is described in
   [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
   [RFC3473].

   One bit is

   Two bits are allocated for the administrative control of OAM
   monitoring.  In addition to the Reflect (R) bit, 7 bits are currently
   occupied (assigned by IANA or temporarily blocked by work in progress
   Internet drafts).  As the 24th bit and 25th bits (IANA to assign) this
   draft introduces the Monitoring Disabled "OAM Flows Enabled" (M) bit. and "OAM Alarms Enabled"
   (O) bits.  When this the "OAM Flows Enabled" bit is set set, OAM packets are
   sent if it is cleared no OAM packets are emitted.  When the
   monitoring and "OAM
   Alarms Enabled" bit is set OAM triggered alarms are enabled and
   associated consequent actions are executed including the notification
   of the LSP are disabled (e.g., no
   continuity check messages management system.  When this bit is cleared, alarms are sent,
   suppressed and no AIS action is executed and the management system is generated).

3.7. not
   notified.

4.4.  Handling OAM configuration errors Configuration Errors

   To handle OAM configuration errors a new Error Code (IANA to assign)
   "OAM Problem" is introduced.  To refer to specific problems a set of
   Error Values is defined.

   If a node does not support the establishment of OAM MEP or MIP
   entities it must use the error value (IANA to assign): "MEP
   establishment not supported" or "MIP establishment not supported"
   respectively in the PathErr message.

   If a node does not support a specific OAM technology/solution it must
   use the error value (IANA to assign): "Unsupported OAM Type" in the
   PathErr message.

   If a different technology specific OAM configuration TLV is included
   than what was specified in the OAM Type an error must be generated
   with error value:"OAM value: "OAM Type Mismatch" in the PathErr message.

   There is a hierarchy in between the OAM configuration elements.  If
   this hierarchy is broken an the error value: "OAM Problem/
   Configuration "Configuration Error" must
   be used in the PathErr message.

   If a node does not support a specific OAM Function it must use the
   error value (IANA to assign): value: "Unsupported OAM Function" in the PathErr message.

   If an intermediate node is configured as a TCM ingress node, but no
   egress node for the same TCM entity is encoded in the ERO it must use
   "OAM Problem/TCM Egress is not properly configured" error value in
   the PathErr message

   If the node, where TCME endpoint is to be configured, does not
   support that feature, must generate an error: "OAM Problem/TCM not
   supported".

   If the technology does not support deploying MIPs monitoring a TCME
   an error must be generated by the TCME ingress: "OAM Problem/TCME MIP
   establishment not supported".

   If an intermediate node is configured as a non-intrusive monitoring
   node, but direction flags encode an invalid direction (both flags are
   set to 0 or flag "U" is set in the case of an unidirectional LSP) the
   node must issue a PathErr message with "OAM Problem/invalid NIM
   direction defined".

4.

5.  IANA Considerations

   One bit (Monitoring Disabled

   Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs
   to be allocated in the ADMIN_STATUS Object.

   One bit

   Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")
   needs to be allocated in the LSP Attributes Flag Flags Registry.

   This document specifies one new TLVs TLV to be carried in the
   LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv
   messages: OAM Configuration TLV.

   One new Error Code: "OAM Problem" and three a set of new values: "MEP
   establishment not supported", "MIP establishment not supported",
   "Unsupported OAM Type" Type", "Configuration Error" and "Unsupported OAM
   Function" needs to be assigned.

5.

   The IANA is requested to open a new registry: "RSVP-TE OAM
   Configuration Registry" that maintains the "OAM Type" code points and
   the allocations of "OAM Function Flags" within the OAM Configuration
   TLV.

6.  Security Considerations

   The signaling of OAM related parameters and the automatic
   establishment of OAM entities introduces additional security
   considerations to those discussed in [RFC3473].  In particular, a
   network element could be overloaded, if an attacker would request
   liveliness monitoring, with frequent periodic messages, for a high
   number of LSPs, targeting a single network element.

   Security aspects will be covered in more detailed in subsequent
   versions of this document.

6.

7.  Acknowledgements

   The authors would like to thank Francesco Fondelli, Adrian Farrel,
   Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
   comments.

Appendix A.  Discussion on alternatives Alternatives

   This appendix summarizes the discussions after IETF-71 about the way
   OAM configuration information should be carried in RSVP-TE.

   The first question is how the requirement for OAM establishment is
   signaled and how the operation of OAM is controlled.  There is a
   straightforward way to achieve these using existing objects and
   fields:

   o  Use one or more OAM flags in the LSP Attributes Flag TLV within
      the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that
      OAM entities for the LSP need to be established.  If for any
      reason this cannot be done a notification is sent or an error is
      raised.

   o  Once the LSP with the desired OAM entities is established OAM
      operation may be controlled using one or more flags in the
      ADMIN_STATUS object.  For instance, the generation of connectivity
      monitoring messages can be disabled/enabled by setting/clearing a
      flag in the ADMIN_STATUS object.

   However, there are two alternatives when it comes to signaling the
   actual configuration parameters of OAM entities.

   o  Extension of the LSP_ATTRIBUTES object with new TLVs.

   o  Definition of a new RSVP-TE object to carry OAM information.

   In the first case, a new OAM configuration TLV is defined in the
   LSP_ATTRIBUTES object.  This TLV would provide the detailed
   information needed for LSPs with a set OAM flag in the LSP Attributes
   Flag TLV.  The rationale for this approach is that in addition to
   setting flags the LSP_ATTRIBUTES object may carry complementary
   information for all or some of the flags set.  Furthermore, as top
   level RSVP-TE objects may become scarce resources, it seems to be
   beneficial not to allocate new RSVP-TE objects for the purpose of
   providing detailed information for new LSP Attribute Flags.
   Currently there is only one TLV, the Attributes Flag TLV, defined in
   the LSP_ATTRIBUTES object.  Defining a new TLV associated with one of
   the flags would make a precedence and possibly be a guideline for
   similar future extensions.

   The other alternative would be to allocate a dedicated object for OAM
   configuration information.  The rationale for this is that the
   complex information that may be required for OAM configuration would
   unnecessarily add complexity to LSP_ATTRIBUTES/
   LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms.

   Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to
   carry configuration information of data plane entities, thus a new
   object like an "OAM_SPEC" may be a better fit to existing protocol
   elements.

   The authors of this document favor the first alternative (adding new
   TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES.  However, which
   alternative to select for standardization is up for the working group
   to decide.  In any case, the information to be carried would be the
   same or very similar for both alternatives.

7.

8.  References

   [GELS-Framework]
              "GMPLS Ethernet Label Switching Architecture and
              Framework", Internet Draft, work in progress.

   [GMPLS-OAM]
              "OAM Requirements for Generalized Multi-Protocol Label
              Switching (GMPLS) Networks", Internet Draft, work in
              progress.

   [HOP_ATTR]
              Kern, A. and A. Takacs, "Encoding of Attributes of LSP
              hops using RSVP-TE", Internet-draft Work in progress,
              October 2009.

   [IEEE-CFM]
              "IEEE 802.1ag, Draft Standard for Connectivity Fault
              Management",  work in progress.

   [IEEE-PBBTE]
              "IEEE 802.1Qay Draft Standard for Provider Backbone
              Bridging Traffic Engineering",  work in progress.

   [MPLS-TP-FWK]
              "A Framework for MPLS in Transport Networks", Internet
              Draft, work in progress.

   [MPLS-TP-OAM-REQ]
              "Requirements for OAM in MPLS Transport Networks",
              Internet Draft, work in progress.

   [RFC3469]  "Framework for Multi-Protocol Label Switching (MPLS)-based
              Recovery", RFC 3469, February 2003.

   [RFC3471]  "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Functional Description", RFC 3471, January 2003.

   [RFC3473]  "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4377]  "Operations and Management (OAM) Requirements for Multi-
              Protocol Label Switched (MPLS) Networks", RFC 4377,
              February 2006.

   [RFC4420]

   [RFC5420]  "Encoding of Attributes for Multiprotocol Label Switching
              (MPLS) Label Switched Path (LSP) Establishment Using
              Resource ReserVation Protocol-Traffic Engineering
              (RSVP-TE)", RFC 4420, 5420, February 2006. 2009.

Authors' Addresses

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

   Email: attila.takacs@ericsson.com

   Don Fedyk
   Alcatel-Lucent
   Groton, MA  01450
   USA

   Email: donald.fedyk@alcatel-lucent.com

   Jia He
   Huawei

   Email: hejia@huawei.com