doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc7260.txt b/doc/rfc/rfc7260.txt
new file mode 100644
index 0000000..c095f19
--- /dev/null
+++ b/doc/rfc/rfc7260.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Takacs
+Request for Comments: 7260                                      Ericsson
+Category: Standards Track                                       D. Fedyk
+ISSN: 2070-1721                                  Hewlett-Packard Company
+                                                                   J. He
+                                                                  Huawei
+                                                               June 2014
+
+
+                      GMPLS RSVP-TE Extensions for
+    Operations, Administration, and Maintenance (OAM) Configuration
+
+Abstract
+
+   Operations, Administration, and Maintenance (OAM) is an integral part
+   of transport connections; hence, it is required that OAM functions be
+   activated/deactivated in sync with connection commissioning/
+   decommissioning, in order to avoid spurious alarms and ensure
+   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 Resource
+   Reservation Protocol - Traffic Engineering (RSVP-TE) to support the
+   establishment and configuration of OAM entities along with Label
+   Switched Path signaling.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7260.
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 1]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Language ......................................4
+   2. Technology-Specific OAM Requirements ............................4
+   3. RSVP-TE-Based OAM Configuration .................................6
+      3.1. Establishment of OAM Entities and Functions ................8
+      3.2. Adjustment of OAM Parameters ..............................10
+      3.3. Deleting OAM Entities .....................................11
+   4. RSVP-TE Extensions .............................................11
+      4.1. LSP Attribute Flags .......................................11
+      4.2. OAM Configuration TLV .....................................13
+           4.2.1. OAM Function Flags Sub-TLV .........................14
+           4.2.2. Technology-Specific Sub-TLVs .......................15
+      4.3. Administrative Status Information .........................15
+      4.4. Handling OAM Configuration Errors .........................16
+      4.5. Considerations on Point-to-Multipoint OAM Configuration ...16
+   5. IANA Considerations ............................................18
+      5.1. Admin_Status Object Bit Flags .............................18
+      5.2. LSP Attribute Flags .......................................18
+      5.3. New LSP Attributes ........................................19
+      5.4. RSVP Error Code ...........................................19
+      5.5. RSVP-TE OAM Configuration Registry ........................20
+           5.5.1. OAM Types Sub-Registry .............................20
+           5.5.2. OAM Sub-TLVs Sub-Registry ..........................20
+           5.5.3. OAM Function Flags Sub-Registry ....................21
+   6. Security Considerations ........................................21
+   7. Acknowledgements ...............................................21
+   8. References .....................................................22
+      8.1. Normative References ......................................22
+      8.2. Informative References ....................................22
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 2]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+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., Dense
+   Wavelength Division Multiplexing (DWDM)); time-division multiplexing
+   (e.g., Synchronous Optical Networking and Synchronous Digital
+   Hierarchy (SONET/SDH), G.709); and Ethernet Provider Backbone
+   Bridging - Traffic Engineering (PBB-TE) and MPLS.  In most of these
+   technologies, there are Operations, Administration, and Maintenance
+   (OAM) functions employed to monitor the health and performance of the
+   connections and to trigger data plane (DP) recovery mechanisms.
+   Similar to connection provisioning, OAM functions follow general
+   principles but also have some technology-specific characteristics.
+
+   OAM is an integral part of transport connections.  Therefore, it is
+   required that OAM functions be activated/deactivated in sync with
+   connection commissioning/decommissioning, in order to avoid spurious
+   alarms and ensure 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, such as Fault Management (FM) and Performance Management
+   (PM), may be optional (based on network management policies).  Hence,
+   the network operator must be able to choose which set of OAM
+   functions to apply to specific connections and which parameters
+   should be configured and activated.  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 be 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), as these separate steps increase delay and
+   processing time; more importantly, they may be prone to
+   misconfiguration errors.  Once OAM entities are set up and
+   configured, proactive 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 proactive OAM functions via the GMPLS
+   control plane as well.  In some situations, it may be possible to use
+   the GMPLS control plane to control on-demand OAM functions too.
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 3]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   This document describes requirements for OAM configuration and
+   control via Resource Reservation Protocol - Traffic Engineering
+   (RSVP-TE).  Extensions to the RSVP-TE protocol are specified,
+   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 that may only be needed for
+   a specific OAM technology.  This document specifies the technology-
+   agnostic elements and specifies the way that 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 Label Switched Path (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 is outside 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 used to set up the LSPs that
+   are to be monitored using OAM.
+
+1.1.  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 [RFC2119].
+
+2.  Technology-Specific OAM Requirements
+
+   This section summarizes various technology-specific OAM requirements
+   that can be used as a basis for an OAM configuration framework.
+
+   MPLS OAM requirements are described in [RFC4377], which provides
+   requirements to create consistent OAM functionality for MPLS
+   networks.  The following list is an excerpt of MPLS OAM requirements
+   documented in [RFC4377] that bear direct relevance to the discussion
+   set forth in this document:
+
+   o  It is desired that the automation of LSP defect detection be
+      supported.  It is especially important in cases where large
+      numbers of LSPs might be tested.
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 4]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   o  In particular, some LSPs may require automated testing
+      functionality from the ingress LSR (Label Switching Router) to the
+      egress LSR, 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 time frames.
+
+   The MPLS Transport Profile (MPLS-TP) defines a profile of MPLS
+   targeted at transport applications [RFC5921].  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 [RFC5654] and [RFC5860].  MPLS-TP poses the following
+   requirements on the control plane to configure and control OAM
+   entities:
+
+   o  From [RFC5860]: OAM functions MUST operate and be configurable
+      even in the absence of a control plane.  Conversely, it SHOULD be
+      possible to configure as well as enable/disable the capability to
+      operate OAM functions as part of connectivity management, and it
+      SHOULD also be possible to configure as well as enable/disable the
+      capability to operate OAM functions after connectivity has been
+      established.
+
+   o  From [RFC5654]: 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 or
+      transport service is established or modified.
+
+   Ethernet Connectivity Fault Management (CFM) defines an adjunct OAM
+   flow that monitors connectivity in order to check the liveliness of
+   Ethernet networks [IEEE.802.1Q-2011].  With PBB-TE
+   [IEEE.802.1Q-2011], Ethernet networks support explicitly routed
+   Ethernet connections.  CFM can be used to track the liveliness of
+   PBB-TE connections and detect data-plane failures.  In the IETF, the
+   GMPLS Ethernet Label Switching (GELS) (see [RFC5828] and [RFC6060])
+   work extended the GMPLS control plane to support the establishment of
+   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 need to provide a general
+   framework to be applicable to a wide range of data-plane technologies
+   and OAM solutions.  There are three typical data-plane technologies
+
+
+
+Takacs, et al.               Standards Track                    [Page 5]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   used for transport applications: wavelength based, such as Wavelength
+   Switched Optical Networks (WSON); Time-Division Multiplexing (TDM)
+   based, such as Synchronous Digital Hierarchy (SDH) and Synchronous
+   Optical Networking (SONET); and packet based, such as MPLS-TP
+   [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011].  For 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.  Therefore,
+      alarms that do not affect service should be inhibited.
+
+   o  When periodic messages are used for liveliness checks (Continuity
+      Checks (CCs)) of LSPs, it MUST be possible to set the frequency of
+      messages.  This allows 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 between fast failure detection
+      and data overhead, it is beneficial to configure the frequency of
+      CC messages on a per-LSP basis.
+
+   o  Proactive Performance Monitoring (PM) functions are used to
+      continuously collect information about specific characteristics of
+      the connection.  For consistent measurement of Service Level
+      Agreements (SLAs), it MUST be possible to set common configuration
+      parameters for the LSP.
+
+   o  The extensions MUST allow the operator to use only a minimal set
+      of OAM configuration and control features if supported by the OAM
+      solution or network management policy.  Generic OAM parameters, as
+      well as parameters specific to data-plane technology or OAM
+      technology, MUST be supported.
+
+3.  RSVP-TE-Based OAM Configuration
+
+   In general, two types of maintenance points can be distinguished:
+   Maintenance Entity Group End Points (MEPs) and Maintenance Entity
+   Group 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
+
+
+
+Takacs, et al.               Standards Track                    [Page 6]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   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.
+
+   When an LSP is signaled, a 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 to
+   unambiguously identify MEs.
+
+   In addition to ME identification parameters, proactive OAM functions
+   (e.g., CC and PM) may have additional parameters that require
+   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.
+
+   The above parameters may be derived from information related to LSP
+   provisioning; alternatively, pre-configured default values can be
+   used.  In the simplest case, the control plane MAY provide
+   information on whether or not OAM entities need to be set up for the
+   signaled LSP.  If OAM entities are created, control-plane signaling
+   MUST also provide a means to activate/deactivate OAM message flows
+   and associated alarms.
+
+   OAM identifiers, as well as the configuration of OAM functions, are
+   technology specific (i.e., they 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.
+   Therefore, the OAM configuration framework allows selecting a
+   specific OAM solution to be used for the signaled LSP and provides
+   means to carry detailed OAM configuration information in technology-
+   specific TLVs.
+
+   Administrative Status Information is carried in the Admin_Status
+   object.  Administrative Status Information is described in [RFC3471],
+   and the Admin_Status object is specified for RSVP-TE in [RFC3473].
+   Two bits are allocated for the administrative control of OAM
+   monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O)
+   bits.  When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST
+   be enabled; if it is cleared, OAM mechanisms MUST be disabled.  When
+   the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled
+   and associated consequent actions MUST be executed, including the
+   notification to the management system.  When this bit is cleared,
+   alarms are suppressed and no action SHOULD be executed, and the
+   management system SHOULD NOT be notified.
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 7]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects are defined in
+   [RFC5420] to provide means to signal LSP attributes and options in
+   the form of TLVs.  Options and attributes signaled in the
+   LSP_ATTRIBUTES object can be passed transparently through LSRs not
+   supporting a particular option or attribute, while the contents of
+   the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by
+   each LSR.  The "OAM MEP entities desired" bit is allocated in the
+   Attribute Flags TLV [RFC5420] to be used in the LSP_ATTRIBUTES
+   object.  If the "OAM MEP entities desired" bit is set, it indicates
+   that the establishment of OAM MEP entities is required at the
+   endpoints of the signaled LSP.  The "OAM MIP entities desired" bit is
+   allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES
+   or LSP_REQUIRED_ATTRIBUTES objects.  If the "OAM MIP entities
+   desired" bit is set in the Attribute Flags TLV in the
+   LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment
+   of OAM MIP entities is required at every transit node of the
+   signaled LSP.
+
+3.1.  Establishment of OAM Entities and Functions
+
+   In order to avoid spurious alarms, OAM functions should be set up and
+   enabled in the appropriate order.  When using the GMPLS control plane
+   for both LSP establishment and enabling OAM functions on the LSPs,
+   the control of both processes is bound to RSVP-TE message exchanges.
+
+   An LSP may be signaled and established without OAM configuration
+   first, and OAM entities may be added later with a subsequent
+   re-signaling of the LSP.  Alternatively, the LSP may be set up with
+   OAM entities with the first signaling of the LSP.  The procedures
+   below apply to both cases.
+
+   Before initiating a Path message with OAM configuration information,
+   an initiating node MUST establish and configure the corresponding OAM
+   entities locally.  But until the LSP is established, OAM source
+   functions MUST NOT start sending any OAM messages.  In the case of
+   bidirectional connections, in addition to the OAM source function,
+   the initiator node MUST set up the OAM sink function and prepare it
+   to receive OAM messages.  During this time the OAM alarms MUST be
+   suppressed (e.g., due to missing or unidentified OAM messages).  To
+   achieve OAM alarm suppression, Path messages MUST be sent with the
+   "OAM Alarms Enabled" Admin_Status flag cleared.
+
+   When the Path message arrives at the receiver, the remote end MUST
+   establish and configure OAM entities according to the OAM information
+   provided in the Path message.  If this is not possible, a PathErr
+   message SHOULD be sent, and neither the OAM entities nor the LSP
+   SHOULD be established.  If OAM entities are established successfully,
+   the OAM sink function MUST be prepared to receive OAM messages but
+
+
+
+Takacs, et al.               Standards Track                    [Page 8]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   MUST NOT generate any OAM alarms (e.g., due to missing or
+   unidentified OAM messages).  In the case of bidirectional
+   connections, in addition to the OAM sink function, an OAM source
+   function MUST be set up and, according to the requested
+   configuration, the OAM source function MUST start sending OAM
+   messages.  A Resv message MUST then be sent back, including the
+   Attribute Flags TLV, with the appropriate setting of the "OAM MEP
+   entities desired" and "OAM MIP entities desired" flags, and the OAM
+   Configuration TLV that corresponds to the established and configured
+   OAM entities and functions.  Depending on the OAM technology, some
+   elements of the OAM Configuration TLV MAY be updated/changed, i.e.,
+   if the remote end does not support a certain OAM configuration it may
+   suggest an alternative setting, which may or may not be accepted by
+   the initiator of the Path message.  If it is accepted, the initiator
+   will reconfigure its OAM functions according to the information
+   received in the Resv message.  If the alternate setting is not
+   acceptable, a ResvErr message MAY be sent, tearing down the LSP.
+   Details of this operation are technology specific and should be
+   described in accompanying technology-specific documents.
+
+   When the initiating side receives the Resv message, it completes any
+   pending OAM configuration and enables the OAM source function to send
+   OAM messages.
+
+   After this exchange, OAM entities are established and configured for
+   the LSP, and OAM messages are exchanged.  OAM alarms can now be
+   enabled.  During the period when OAM alarms are disabled, the
+   initiator sends a Path message with the "OAM Alarms Enabled"
+   Admin_Status flag set.  The receiving node enables 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.
+
+   If an egress LSR does not support the extensions defined in this
+   document, according to [RFC5420], it will silently ignore the new LSP
+   attribute flags as well as the TLVs carrying additional OAM
+   configuration information, and therefore no error will be raised that
+   would notify the ingress LSR about the missing OAM configuration
+   actions on the egress side.  However, as described above, an egress
+   LSR conformant to the specification of this document will set the LSP
+   attribute flags and include the OAM Configuration TLV in the Resv
+   message indicating the configuration of the OAM mechanisms;
+   therefore, by detecting the missing information in the Resv message,
+   an ingress LSR will be able to recognize that the remote end does not
+   support the OAM configuration functionality, and therefore it SHOULD
+   tear down the LSP and, if appropriate, signal the LSP without any OAM
+   configuration information.
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 9]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+3.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
+   LSP.  To do so, the LSP needs to be re-signaled with the updated
+   parameters.  OAM parameters influence the content and timing of OAM
+   messages and also identify the way that 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, the LSP MUST first be
+   re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared,
+   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 and then update the OAM parameters 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 can adjust the requested OAM
+   configuration parameters and reply with an updated OAM Configuration
+   TLV in the Resv message, reflecting the values that are actually
+   configured.  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 (e.g.,
+   lower frequency of monitoring packets) than what had previously been
+   in place.
+
+   The initiator MUST only update its OAM sink and source functions
+   after it receives 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 to the new
+   parameter settings.  However, OAM alarms are still disabled.  A
+   subsequent Path/Resv message exchange with the "OAM Alarms Enabled"
+   Admin_Status flag set is needed to enable OAM alarms again.
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 10]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+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 alarms, first the LSP MUST be re-signaled with
+   the "OAM Alarms Enabled" Admin_Status flag cleared but with OAM
+   configuration unchanged.  Subsequently, the LSP is re-signaled with
+   "OAM MEP entities desired" and "OAM MIP entities desired" LSP
+   attribute flags cleared, and without the OAM Configuration TLV, this
+   MUST result in the deletion of all OAM entities associated with the
+   LSP.  All control-plane 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-signaled 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 MUST be removed/added.
+
+   OAM source functions MUST be deleted first, and only after the "OAM
+   Alarms Disabled" can 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, MUST remove
+   the OAM source, hence terminating the OAM message flow associated to
+   the downstream direction.  In the case of a bidirectional connection,
+   it MUST leave in place the OAM sink functions associated to the
+   upstream direction.  The remote end, after receiving the Path
+   message, MUST 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 arrives.
+
+4.  RSVP-TE Extensions
+
+4.1.  LSP Attribute 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 Switching 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
+
+
+
+Takacs, et al.               Standards Track                   [Page 11]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide
+   means to signal LSP attributes and options in the form of TLVs.
+   Options and attributes signaled in the LSP_ATTRIBUTES object can be
+   passed transparently through LSRs not supporting a particular option
+   or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES
+   object MUST be examined and processed by each LSR.  One TLV is
+   defined in [RFC5420]: the Attribute Flags TLV.
+
+   One bit (bit number 10): "OAM MEP entities desired" is allocated in
+   the Attribute Flags TLV to be used in the LSP_ATTRIBUTES object.  If
+   the "OAM MEP entities desired" bit is set, it indicates that the
+   establishment of OAM MEP entities is required at the endpoints of the
+   signaled LSP.  If the establishment of MEPs is not supported, an
+   error MUST be generated: "OAM Problem/MEP establishment not
+   supported".
+
+   If the "OAM MEP entities desired" bit is set and additional
+   parameters need to be configured, an OAM Configuration TLV MAY be
+   included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
+
+   One bit (bit number 11): "OAM MIP entities desired" is allocated in
+   the Attribute Flags TLV to be used in the LSP_ATTRIBUTES or
+   LSP_REQUIRED_ATTRIBUTES objects.  If the "OAM MEP entities desired"
+   bit is not set, then this bit MUST NOT be set.  If the "OAM MIP
+   entities desired" bit is set in the Attribute Flags TLV in the
+   LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment
+   of OAM MIP entities is required at every transit node of the signaled
+   LSP.  If the establishment of a MIP is not supported, an error MUST
+   be generated: "OAM Problem/MIP establishment not supported".  If an
+   intermediate LSR does not support the extensions defined in this
+   document, it will not recognize the "OAM MIP entities desired" flag
+   and, although the LSP_REQUIRED_ATTRIBUTES object was used, it will
+   not configure MIP entities and will not raise any errors.  If LSRs
+   that do not support the extensions defined in this document are to be
+   assumed as present in the network, the ingress LSR SHOULD collect
+   per-hop information about the LSP attributes utilizing the LSP
+   Attributes sub-object of the Record Route object (RRO) as defined in
+   [RFC5420].  When the Record Route object is received, the ingress
+   SHOULD check whether all intermediate LSRs set the "OAM MIP entities
+   desired" flag indicating support of the function; if not, depending
+   on operator policy, the LSP MAY need to be torn down.
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 12]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+4.2.  OAM Configuration TLV
+
+   This TLV provides information about which OAM technology/method
+   should be used and carries sub-TLVs for any additional OAM
+   configuration information.  One OAM Configuration TLV MAY be carried
+   in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
+   Resv messages.  When carried in the LSP_REQUIRED_ATTRIBUTES object,
+   it indicates that intermediate nodes MUST recognize and react on the
+   OAM configuration information.
+
+    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)            |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    OAM Type   |                 Reserved                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           sub-TLVs                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type: indicates a new type: the OAM Configuration TLV (3).
+
+   OAM Type: specifies the technology-specific OAM method.  When carried
+   in the LSP_REQUIRED_ATTRIBUTES object, if the requested OAM method is
+   not supported at any given node an error MUST be generated: "OAM
+   Problem/Unsupported OAM Type".  When carried in the LSP_ATTRIBUTES
+   object, intermediate nodes not supporting the OAM Type pass the
+   object forward unchanged as specified in [RFC5420].  Ingress and
+   egress nodes that support the OAM Configuration TLV but that do not
+   support a specific OAM Type MUST respond with an error indicating
+   "OAM Problem/Unsupported OAM Type".
+
+       OAM Type             Description
+     ------------      --------------------
+        0-255               Reserved
+
+   This document defines no types.  IANA maintains the values in a new
+   "RSVP-TE OAM Configuration Registry".
+
+   Length: indicates the total length of the TLV in octets.  The TLV
+   MUST be zero-padded so that the TLV is 4-octet aligned.
+
+   Two groups of TLVs are defined: generic sub-TLVs and technology-
+   specific sub-TLVs.  Generic sub-TLVs carry information that is
+   applicable independent of the actual OAM technology, while
+   technology-specific sub-TLVs are providing configuration parameters
+
+
+
+Takacs, et al.               Standards Track                   [Page 13]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   for specific OAM technologies.  This document defines one generic
+   sub-TLV (see Section 4.2.1), while it is foreseen that technology-
+   specific sub-TLVs will be defined by separate documents.
+
+   The receiving node, based on the OAM Type, will check to see if a
+   corresponding technology-specific OAM configuration sub-TLV is
+   included in the OAM Configuration TLV.  If the included technology-
+   specific OAM configuration sub-TLV is different from what is
+   specified in the OAM Type, an error MUST be generated: "OAM Problem/
+   OAM Type Mismatch".  IANA maintains the sub-TLV space in the new
+   "RSVP-TE OAM Configuration Registry".
+
+   Note that there is a hierarchical dependency between the OAM
+   configuration elements.  First, the "OAM MEP entities desired" flag
+   needs to be set.  Only when that flag is set MAY an OAM Configuration
+   TLV be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
+   object.  When this TLV is present, based on the "OAM Type" field, it
+   MAY carry a technology-specific OAM configuration sub-TLV.  If this
+   hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set
+   but an OAM Configuration TLV is present), an error MUST be generated:
+   "OAM Problem/Configuration Error".
+
+4.2.1.  OAM Function Flags Sub-TLV
+
+   The OAM Configuration TLV MUST always include a single instance of
+   the OAM Function Flags Sub-TLV, and it MUST always be the first
+   sub-TLV.  "OAM Function Flags" specifies which proactive OAM
+   functions (e.g., connectivity monitoring, loss and delay measurement)
+   and which fault management signals MUST be established and
+   configured.  If the selected OAM Function or Functions are not
+   supported, an error MUST be generated: "OAM Problem/Unsupported OAM
+   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 (1)            |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                      OAM Function Flags                       ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 14]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   OAM Function Flags is a bitmap with extensible length based on the
+   Length field of the TLV.  Bits are numbered from left to right.  The
+   TLV is padded to 4-octet alignment.  The Length field indicates the
+   size of the padded TLV in octets.  IANA maintains the OAM Function
+   Flags in the new "RSVP-TE OAM Configuration Registry".  This document
+   defines the following flags:
+
+   OAM Function Flag bit #      Description
+   ----------------------- ---------------------------------------------
+    0                      Continuity Check (CC)
+    1                      Connectivity Verification (CV)
+    2                      Fault Management Signal (FMS)
+    3                      Performance Monitoring/Loss (PM/Loss)
+    4                      Performance Monitoring/Delay (PM/Delay)
+    5                      Performance Monitoring/Throughput Measurement
+                           (PM/Throughput)
+
+4.2.2.  Technology-Specific Sub-TLVs
+
+   If technology-specific configuration information is needed for a
+   specific "OAM Type", then this information is carried in a
+   technology-specific sub-TLV.  Such sub-TLVs are OPTIONAL, and an OAM
+   Configuration TLV MUST NOT contain more than one technology-specific
+   sub-TLV.  IANA maintains the OAM technology-specific sub-TLV space in
+   the new "RSVP-TE OAM Configuration Registry".
+
+4.3.  Administrative Status Information
+
+   Administrative Status Information is carried in the Admin_Status
+   object, which is specified for RSVP-TE in [RFC3473].  Administrative
+   Status Information is described in [RFC3471].
+
+   Two bits (bit numbers 23 and 24) are allocated by this document for
+   the administrative control of OAM monitoring: the "OAM Flows Enabled"
+   (M) and "OAM Alarms Enabled" (O) bits.  When the "OAM Flows Enabled"
+   bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM
+   mechanisms MUST be disabled.  When the "OAM Alarms Enabled" bit is
+   set, OAM-triggered alarms are enabled and associated consequent
+   actions MUST be executed, including the notification to the
+   management system.  When this bit is cleared, alarms are suppressed,
+   and no action SHOULD be executed; additionally, the management system
+   SHOULD NOT be notified.  For a detailed description of the use of
+   these flags, see Section 3.
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 15]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+4.4.  Handling OAM Configuration Errors
+
+   To handle OAM configuration errors, a new Error Code "OAM Problem"
+   (40) is introduced.  To refer to specific problems, a set of Error
+   Values are defined under the "OAM Problem" error code.
+
+   If a node does not support the establishment of OAM MEP or MIP
+   entities it MUST use the error value "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 "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 Type Mismatch" in the PathErr message.
+
+   There is a hierarchy between the OAM configuration elements.  If this
+   hierarchy is broken, the error value "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 "Unsupported OAM Function" in the PathErr message.
+
+4.5.  Considerations on Point-to-Multipoint OAM Configuration
+
+   RSVP-TE extensions for the establishment of point-to-multipoint
+   (P2MP) LSPs are specified in [RFC4875].  A P2MP LSP is comprised of
+   multiple source-to-leaf (S2L) sub-LSPs.  These S2L sub-LSPs are set
+   up between the ingress and egress LSRs and are appropriately combined
+   by the branch LSRs using RSVP semantics to result in a P2MP TE LSP.
+   One Path message may signal one or multiple S2L sub-LSPs for a single
+   P2MP LSP.  Hence, the S2L sub-LSPs belonging to a P2MP LSP can be
+   signaled using one Path message or split across multiple Path
+   messages.
+
+   P2MP OAM mechanisms are very specific to the data-plane technology;
+   therefore, in this document we only highlight the basic principles of
+   P2MP OAM configuration.  We consider only the root-to-leaf OAM flows,
+   and as such, aspects of the configuration of return paths are outside
+   the scope of our discussions.  We also limit our consideration to the
+   case where all leaves must successfully establish OAM entities with
+   identical configuration in order for the P2MP OAM to be successfully
+   established.  In any case, the discussion set forth below provides
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 16]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   only guidelines for P2MP OAM configuration.  However, at a minimum,
+   the procedures below SHOULD be specified for P2MP OAM configuration
+   in a technology-specific document.
+
+   The root node may use a single Path message or multiple Path messages
+   to set up the whole P2MP tree.  In the case when multiple Path
+   messages are used, the root node is responsible for keeping the OAM
+   configuration information consistent in each of the sent Path
+   messages, i.e., the same information MUST be included in all Path
+   messages used to construct the multicast tree.  Each branching node
+   will propagate the Path message downstream on each of the branches;
+   when constructing a Path message, the OAM configuration information
+   MUST be copied unchanged from the received Path message, including
+   the related Admin_Status bits, LSP attribute flags, and OAM
+   Configuration TLV.  The latter two also imply that the LSP_ATTRIBUTES
+   and LSP_REQUIRED_ATTRIBUTES objects MUST be copied for the upstream
+   Path message to the subsequent downstream Path messages.
+
+   Leaves MUST create and configure OAM sink functions according to the
+   parameters received in the Path message; for P2MP OAM configuration,
+   there is no possibility for parameter negotiation on a per-leaf
+   basis.  This is due to the fact that the OAM source function,
+   residing in the root of the tree, will operate with a single
+   configuration, which then must be obeyed by all leaves.  If a leaf
+   cannot accept the OAM parameters, it MUST use the RRO Attributes
+   sub-object [RFC5420] to notify the root about the problem.  In
+   particular, if the OAM configuration was successful, the leaf would
+   set the "OAM MEP entities desired" flag in the RRO Attributes
+   sub-object in the Resv message.  On the other hand, if OAM entities
+   could not be established, the Resv message should be sent with the
+   "OAM MEP entities desired" bit cleared in the RRO Attributes
+   sub-object.  Branching nodes should collect and merge the received
+   RROs according to the procedures described in [RFC4875].  This way,
+   the root, when receiving the Resv message (or messages if multiple
+   Path messages were used to set up the tree), will have clear
+   information about which of the leaves could establish the OAM
+   functions.  If all leaves established OAM entities successfully, the
+   root can enable the OAM message flow.  On the other hand, if at some
+   leaves the establishment was unsuccessful, additional actions will be
+   needed before the OAM message flow can be enabled.  Such action could
+   be to set up two independent P2MP LSPs:
+
+   o  One LSP with OAM configuration information towards leaves that can
+      support the OAM function.  This can be done by pruning from the
+      previously signaled P2MP LSP the leaves that failed to set up OAM.
+
+   o  The other P2MP LSP could be constructed for leaves without OAM
+      entities.
+
+
+
+Takacs, et al.               Standards Track                   [Page 17]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   The exact procedures will be described in technology-specific
+   documents.
+
+5.  IANA Considerations
+
+5.1.  Admin_Status Object Bit Flags
+
+   IANA maintains a registry called "Generalized Multi-Protocol Label
+   Switching (GMPLS) Signaling Parameters" with a sub-registry called
+   "Administrative Status Information Flags".
+
+   IANA has allocated two new flags as follows:
+
+      Bit Number |  Hex Value | Name                     | Reference
+      -----------+------------+--------------------------+-----------
+         23      | 0x00000100 | OAM Flows Enabled (M)    | [RFC7260]
+         24      | 0x00000080 | OAM Alarms Enabled (O)   | [RFC7260]
+
+5.2.  LSP Attribute Flags
+
+   IANA maintains a registry called "Resource Reservation Protocol-
+   Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
+   "Attribute Flags".
+
+   IANA has allocated two new flags as follows:
+
+   Bit |                  | Attribute  | Attribute  |     |
+   No. | Name             | Flags Path | Flags Resv | RRO | Reference
+   ----+------------------+------------+------------+-----+----------
+    10 | OAM MEP          |            |            |     |
+       | entities desired |   Yes      |    Yes     | Yes | [RFC7260]
+       |                  |            |            |     |
+    11 | OAM MIP          |            |            |     |
+       | entities desired |   Yes      |    Yes     | Yes | [RFC7260]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 18]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+5.3.  New LSP Attributes
+
+   IANA maintains a registry called "Resource Reservation Protocol-
+   Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
+   "Attributes TLV Space".
+
+   IANA has allocated one new TLV type as follows:
+
+       |                      |              |Allowed on   |
+       |                      |Allowed on    |LSP_REQUIRED_|
+   Type| Name                 |LSP_ATTRIBUTES|ATTRIBUTES   |Reference
+   ----+----------------------+--------------+-------------+---------
+    3  | OAM Configuration TLV|    Yes       |    Yes      |[RFC7260]
+
+5.4.  RSVP Error Code
+
+   IANA maintains a registry called "Resource Reservation Protocol
+   (RSVP) Parameters" with a sub-registry called "Error Codes and
+   Globally-Defined Error Value Sub-Codes".
+
+   IANA has allocated one new Error Code as follows:
+
+      Error Code | Meaning     | Reference
+      -----------+-------------+-------------
+          40     | OAM Problem | [RFC7260]
+
+   The following Error Value sub-codes are defined for this new Error
+   Code:
+
+      Value   | Description                     | Reference
+   -----------+---------------------------------+--------------
+        0     | Reserved                        | [RFC7260]
+        1     | MEP establishment not supported | [RFC7260]
+        2     | MIP establishment not supported | [RFC7260]
+        3     | Unsupported OAM Type            | [RFC7260]
+        4     | Configuration Error             | [RFC7260]
+        5     | OAM Type Mismatch               | [RFC7260]
+        6     | Unsupported OAM Function        | [RFC7260]
+     7-32767  | Unassigned                      |
+   32768-65535| Reserved for Private Use        | [RFC7260]
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 19]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+5.5.  RSVP-TE OAM Configuration Registry
+
+   IANA has created a new registry called "RSVP-TE OAM Configuration
+   Registry".
+
+   IANA has created sub-registries as defined in the following
+   subsections.  The registration procedures specified are as defined in
+   [RFC5226].
+
+5.5.1.  OAM Types Sub-Registry
+
+   IANA has created the "OAM Types" sub-registry of the "RSVP-TE OAM
+   Configuration Registry" as follows:
+
+       Range | Registration Procedures
+      -------+-------------------------
+       0-255 | IETF Review
+
+   There are no initial values in this registry.  IANA shows the
+   registry as follows:
+
+       OAM Type Number | OAM Type Description | Reference
+       ----------------+----------------------+--------------
+        0-255          | Unassigned           |
+
+5.5.2.  OAM Sub-TLVs Sub-Registry
+
+   IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM
+   Configuration Registry" as follows:
+
+   Range       | Note                         | Registration Procedures
+   ------------+------------------------------|------------------------
+   0-31        | Generic Sub-TLVs             | IETF Review
+   32-65534    | Technology-specific Sub-TLVs | IETF Review
+   65535-65536 | Experimental Sub-TLVs        | Reserved for
+                                              |   Experimental Use
+
+   IANA has populated the registry as follows:
+
+      Sub-TLV Type | Description                   | Reference
+      -------------+-------------------------------+----------
+          0        | Reserved                      | [RFC7260]
+          1        | OAM Function Flags Sub-TLV    | [RFC7260]
+          2-65534  | Unassigned                    |
+      65535-65536  | Reserved for Experimental Use | [RFC7260]
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 20]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+5.5.3.  OAM Function Flags Sub-Registry
+
+   IANA has created the "OAM Function Flags Sub-Registry" sub-registry
+   of the "RSVP-TE OAM Configuration Registry".
+
+   New values in the registry are allocated by IETF Review [RFC5226].
+   There is no top value to the range.  Bits are counted from bit 0 as
+   the first bit transmitted.
+
+   IANA has populated the registry as follows:
+
+      OAM Function Flag | Description
+      Bit Number        |
+      ------------------+----------------------------------------------
+        0               | Continuity Check (CC)
+        1               | Connectivity Verification (CV)
+        2               | Fault Management Signal (FMS)
+        3               | Performance Monitoring/Loss (PM/Loss)
+        4               | Performance Monitoring/Delay (PM/Delay)
+        5               | Performance Monitoring/Throughput Measurement
+                        |    (PM/Throughput)
+        >=6             | Unassigned
+
+6.  Security Considerations
+
+   The signaling of OAM-related parameters and the automatic
+   establishment of OAM entities based on RSVP-TE messages add a new
+   aspect to the security considerations discussed in [RFC3473].  In
+   particular, a network element could be overloaded if a remote
+   attacker targeted that element by sending frequent periodic messages
+   requesting liveliness monitoring of a high number of LSPs.  Such an
+   attack can efficiently be prevented when mechanisms for message
+   integrity and node authentication are deployed.  Since the OAM
+   configuration extensions rely on the hop-by-hop exchange of exiting
+   RSVP-TE messages, procedures specified for RSVP message security in
+   [RFC2747] can be used to mitigate possible attacks.
+
+   For a more comprehensive discussion of GMPLS security and attack
+   mitigation techniques, please see the Security Framework for MPLS and
+   GMPLS Networks [RFC5920].
+
+7.  Acknowledgements
+
+   The authors would like to thank Francesco Fondelli, Adrian Farrel,
+   Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful
+   comments.
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 21]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
+              (GMPLS) Signaling Functional Description", RFC 3471,
+              January 2003.
+
+   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
+              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
+              Ayyangarps, "Encoding of Attributes for MPLS LSP
+              Establishment Using Resource Reservation Protocol Traffic
+              Engineering (RSVP-TE)", RFC 5420, February 2009.
+
+8.2.  Informative References
+
+   [IEEE.802.1Q-2011]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks -- Media Access Control (MAC) Bridges and Virtual
+              Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
+
+   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
+              Authentication", RFC 2747, January 2000.
+
+   [RFC4377]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
+              Matsushima, "Operations and Management (OAM) Requirements
+              for Multi-Protocol Label Switched (MPLS) Networks",
+              RFC 4377, February 2006.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              February 2006.
+
+   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
+              "Extensions to Resource Reservation Protocol - Traffic
+              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
+              Switched Paths (LSPs)", RFC 4875, May 2007.
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 22]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
+              and S. Ueno, "Requirements of an MPLS Transport Profile",
+              RFC 5654, September 2009.
+
+   [RFC5828]  Fedyk, D., Berger, L., and L. Andersson, "Generalized
+              Multiprotocol Label Switching (GMPLS) Ethernet Label
+              Switching Architecture and Framework", RFC 5828,
+              March 2010.
+
+   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
+              Operations, Administration, and Maintenance (OAM) in MPLS
+              Transport Networks", RFC 5860, May 2010.
+
+   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, July 2010.
+
+   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
+              Berger, "A Framework for MPLS in Transport Networks",
+              RFC 5921, July 2010.
+
+   [RFC6060]  Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
+              "Generalized Multiprotocol Label Switching (GMPLS) Control
+              of Ethernet Provider Backbone Traffic Engineering
+              (PBB-TE)", RFC 6060, March 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 23]
+
+RFC 7260             RSVP-TE-Based OAM Configuration           June 2014
+
+
+Authors' Addresses
+
+   Attila Takacs
+   Ericsson
+   Konyves Kalman krt. 11.
+   Budapest  1097
+   Hungary
+
+   EMail: attila.takacs@ericsson.com
+
+
+   Don Fedyk
+   Hewlett-Packard Company
+   153 Taylor Street
+   Littleton, MA  01460
+   USA
+
+   EMail: don.fedyk@hp.com
+
+
+   Jia He
+   Huawei
+   PR China
+
+   EMail: hejia@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 24]
+