Network Working Group A. Takacs
Internet-Draft Ericsson
Intended status: Standards Track D. Fedyk
Expires: December 17, 2013 Alcatel-Lucent
J. He
Huawei
June 15, 2013
GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-10
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2013.
Copyright Notice
Takacs, et al. Expires December 17, 2013 [Page 1]
Internet-Draft RSVP-TE based OAM Configuration June 2013
Copyright (c) 2013 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
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6
3.1. Establishment of OAM Entities and Functions . . . . . . . 7
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12
4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . . 13
4.3. Administrative Status Information . . . . . . . . . . . . 13
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14
4.5. Considerations on Point-to-Multipoint OAM Configuration . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Takacs, et al. Expires December 17, 2013 [Page 2]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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 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 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,
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 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 prone to misconfiguration errors. Once OAM
entities are setup and 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. In some
situations it may be possible to use the GMPLS control plane to
control on-demand OAM functions too.
This document describes requirements for OAM configuration and
control via 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.
Takacs, et al. Expires December 17, 2013 [Page 3]
Internet-Draft RSVP-TE based OAM Configuration June 2013
Extensions can be grouped into: generic elements that are applicable
to any OAM solution; and technology specific elements that provide
additional configuration parameters, which may only be needed for a
specific OAM technology. This document specifies the technology
agnostic elements 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 used to set up the LSPs that
are to be monitored using OAM.
2. Requirements
This section summarizes various technology-specific OAM requirements
which 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 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 time frames.
MPLS-TP defines a profile of MPLS targeted at transport applications
[RFC5921]. This profile specifies the specific MPLS characteristics
Takacs, et al. Expires December 17, 2013 [Page 4]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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
connectivity monitoring OAM flow 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 IETF, the GMPLS controlled 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, needs 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
used for transport applications: wavelength based such as WSON, TDM
based such as SDH/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
Takacs, et al. Expires December 17, 2013 [Page 5]
Internet-Draft RSVP-TE based OAM Configuration June 2013
operator is only concerned about critical alarms. Therefore 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. 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
continuity check messages on a per LSP basis.
o Pro-active 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 and
data plane or OAM technology specific parameters MUST be
supported.
3. RSVP-TE based OAM Configuration
In general, two types of Maintenance Points (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 to belong to the same ME.
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 MPs and MEs.
In addition to MP and ME identification parameters, pro-active OAM
functions (e.g., Continuity Check (CC) and Performance Monitoring
(PM)) may have additional parameters that require configuration as
Takacs, et al. Expires December 17, 2013 [Page 6]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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 either derived from LSP provisioning
information, or 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 setup 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., 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.
3.1. Establishment of OAM Entities and Functions
In order to avoid spurious alarms, OAM functions should be setup and
enabled in the appropriate order. When using the GMPLS control
plane, establishment and enabling of OAM functions MUST be 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 setup with OAM
entities with the first signaling of the LSP. The below procedures
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 message 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
Takacs, et al. Expires December 17, 2013 [Page 7]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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 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. Then a Resv message is sent back,
including 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 is not supporting 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 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. The initiator, during the period when OAM alarms are
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 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 identify the way OAM defects and alarms are derived and
generated. Hence, to avoid spurious alarms, it is important that
both sides, OAM sink and source, are updated in a synchronized way.
First, the alarms of the OAM sink function should be suppressed and
only then should expected OAM parameters be adjusted. Subsequently,
the parameters of the OAM source function can be updated. Finally,
the alarms of the OAM sink side can be enabled again.
In accordance with the above operation, the LSP MUST first be re-
signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared,
Takacs, et al. Expires December 17, 2013 [Page 8]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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 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 has the possibility to adjust the
requested OAM configuration parameters and reply with an 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 (e.g., lower frequency of monitoring packets) than what
has been in operation 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 alarms, first the LSP MUST be re-signaled with
"OAM Alarms Enabled" 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-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
Takacs, et al. Expires December 17, 2013 [Page 9]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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 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 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
Attributes Flags TLV.
One bit (IANA to assign): "OAM MEP entities desired" is allocated in
the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object.
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 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 (IANA to assign): "OAM MIP entities desired" is allocated in
the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUES objects. This bit MUST only be set if the
Takacs, et al. Expires December 17, 2013 [Page 10]
Internet-Draft RSVP-TE based OAM Configuration June 2013
"OAM MEP entities desired" bit is set. If the "OAM MIP entities
desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the
LSP_REQUIRED_ATTRIBUTES Object, it is indicating 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".
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. The 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 is indicating 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 (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (3) (IANA to
assign).
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], and only Label
Edge Nodes MUST generate an error if the OAM Type is not supported at
the LSP end-point.
OAM Type Description
------------ --------------------
0-255 Reserved
Takacs, et al. Expires December 17, 2013 [Page 11]
Internet-Draft RSVP-TE based OAM Configuration June 2013
This document defines no types. IANA is requested to maintain the
values in a new "RSVP-TE OAM Configuration Registry".
The receiving node, based on the OAM Type, will check 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 is requested to maintain the sub-TLV space
in the new "RSVP-TE OAM Configuration Registry".
Sub-TLV Type Description
------------ ------------------------------------
0 Reserved
1 OAM Function Flags Sub-TLV
2-31 Reserved for generic Sub-TLVs
32- Reserved for technology specific Sub-TLVs
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
As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be
included in the "OAM Configuration TLV". "OAM Function Flags"
specifies which pro-active 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(s) is(are) not supported, an error MUST be generated: "OAM
Problem/Unsupported OAM Function".
Takacs, et al. Expires December 17, 2013 [Page 12]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OAM Function Flags ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Function Flags is bitmap with extensible length based on the
Length field of the TLV. Bits are numbered from left to right. IANA
is requested to maintain 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
One technology specific sub-TLV MAY be defined for each "OAM Type".
This sub-TLV MUST contain any further OAM configuration information
for that specific "OAM Type". The technology specific sub-TLV, when
used, MUST be carried within the OAM Configuration TLV. IANA is
requested to maintain 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. The Administrative Status Information is described in
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
[RFC3473].
Two bits are allocated for the administrative control of OAM
monitoring. Two bits (IANA to assign) are allocated by this draft:
the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When
the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is
cleared, no OAM packets are emitted. When the "OAM Alarms Enabled"
Takacs, et al. Expires December 17, 2013 [Page 13]
Internet-Draft RSVP-TE based OAM Configuration June 2013
bit is set OAM triggered alarms are enabled and associated consequent
actions are executed including the notification to the management
system. When this bit is cleared, alarms are suppressed and no
action is executed and the management system is not notified.
4.4. Handling OAM 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 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
Takacs, et al. Expires December 17, 2013 [Page 14]
Internet-Draft RSVP-TE based OAM Configuration June 2013
identical configuration in order the P2MP OAM is successfully
established. In any case, the discussion set forth below provides
only guidelines for P2MP OAM configuration, details will be specified
in technology specific documents.
The root node may use a single Path message or multiple Path messages
to setup the whole P2MP tree. In the case when multiple Path
messages are used, the root node is responsible to keep 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 the OAM
Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES
and LSP_REQUIRED_ATTRIBUTES Object 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 a 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 setup two
independent P2MP LSPs. One LSP with OAM Configuration information
towards leaves which could successfully setup the OAM function. This
can be done by pruning the leaves which failed to setup OAM of the
previously signaled P2MP LSP. The other P2MP LSP could be
constructed for leaves without OAM entities. The exact procedures
will be described in technology specific documents.
Takacs, et al. Expires December 17, 2013 [Page 15]
Internet-Draft RSVP-TE based OAM Configuration June 2013
5. IANA Considerations
Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs
to be allocated in the ADMIN_STATUS Object.
Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")
needs to be allocated in the LSP Attributes Flags Registry.
This document specifies one new 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 a set of new values: "MEP
establishment not supported", "MIP establishment not supported",
"Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch"
and "Unsupported OAM Function" needs to be assigned.
IANA is requested to open a new registry: "RSVP-TE OAM Configuration
Registry" that maintains the "OAM Type" code points, an associated
sub-TLV space, and the allocations of "OAM Function Flags" within the
OAM Configuration TLV.
RSVP-TE OAM Configuration Registry
OAM Type Description
------------ ------------------
0-255 Reserved
Sub-TLV Type Description
------------ ------------------------------------
0 Reserved
1 OAM Function Flags Sub-TLV
2-31 Reserved for generic Sub-TLVs
32- Reserved for technology specific Sub-TLVs
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)
6- Reserved
Takacs, et al. Expires December 17, 2013 [Page 16]
Internet-Draft RSVP-TE based OAM Configuration June 2013
6. Security Considerations
The signaling of OAM related parameters and the automatic
establishment of OAM entities based on RSVP-TE messages adds a new
aspect to the security considerations discussed in [RFC3473]. In
particular, a network element could be overloaded, if a remote
attacker could request liveliness monitoring, with frequent periodic
messages, for a high number of LSPs, targeting a single network
element. 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 on GMPLS security, please see the
Security Framework for MPLS and GMPLS Networks [RFC5920].
Cryptography can be used to protect against many attacks described in
[RFC5920].
7. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments.
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.
[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.
Takacs, et al. Expires December 17, 2013 [Page 17]
Internet-Draft RSVP-TE based OAM Configuration June 2013
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.
[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. Expires December 17, 2013 [Page 18]
Internet-Draft RSVP-TE based OAM Configuration June 2013
Authors' Addresses
Attila Takacs
Ericsson
Konyves Kalman krt. 11.
Budapest, 1097
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
Takacs, et al. Expires December 17, 2013 [Page 19]