draft-ietf-ccamp-oam-configuration-fwk-08.txt   draft-ietf-ccamp-oam-configuration-fwk-09.txt 
Network Working Group A. Takacs Network Working Group A. Takacs
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track D. Fedyk Intended status: Standards Track D. Fedyk
Expires: January 14, 2013 Alcatel-Lucent Expires: July 26, 2013 Alcatel-Lucent
J. He J. He
Huawei Huawei
July 13, 2012 January 22, 2013
GMPLS RSVP-TE extensions for OAM Configuration GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-08 draft-ietf-ccamp-oam-configuration-fwk-09
Abstract Abstract
OAM is an integral part of transport connections, hence it is OAM is an integral part of transport connections, hence it is
required that OAM functions are activated/deactivated in sync with required that OAM functions are activated/deactivated in sync with
connection commissioning/decommissioning; avoiding spurious alarms connection commissioning/decommissioning; avoiding spurious alarms
and ensuring consistent operation. In certain technologies OAM and ensuring consistent operation. In certain technologies, OAM
entities are inherently established once the connection is set up, entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and while other technologies require extra configuration to establish and
configure OAM entities. This document specifies extensions to configure OAM entities. This document specifies extensions to
RSVP-TE to support the establishment and configuration of OAM RSVP-TE to support the establishment and configuration of OAM
entities along with LSP signaling. entities along with LSP signaling.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2013. This Internet-Draft will expire on July 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 9 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6
3.1. Establishment of OAM Entities and Functions . . . . . . . 9 3.1. Establishment of OAM Entities and Functions . . . . . . . 7
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 11 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 11 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 13 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 13 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 14 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 15 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12
4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 16 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 13
4.3. Administrative Status Information . . . . . . . . . . . . 16 4.3. Administrative Status Information . . . . . . . . . . . . 13
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 16 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 13
4.5. Considerations on Point-to-Multipoint OAM Configuration . 17 4.5. Considerations on Point-to-Multipoint OAM Configuration . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
GMPLS is designed as an out-of-band control plane supporting dynamic GMPLS is designed as an out-of-band control plane supporting dynamic
connection provisioning for any suitable data plane technology; connection provisioning for any suitable data plane technology;
including spatial switching (e.g., incoming port or fiber to outgoing including spatial switching (e.g., incoming port or fiber to outgoing
port or fiber), wavelength-division multiplexing (e.g., DWDM), time- port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider
Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS. In most Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most
of these technologies there are Operations, Administration and of these technologies, there are Operations, Administration and
Maintenance (OAM) functions employed to monitor the health and Maintenance (OAM) functions employed to monitor the health and
performance of the connections and to trigger data plane (DP) performance of the connections and to trigger data plane (DP)
recovery mechanisms. Similarly to connections, OAM functions follow recovery mechanisms. Similar to connection provisioning, OAM
general principles but also have some technology specific functions follow general principles, but also have some technology
characteristics. specific characteristics.
OAM is an integral part of transport connections, hence it is OAM is an integral part of transport connections. Therefore it is
required that OAM functions are activated/deactivated in sync with required that OAM functions are activated/deactivated in sync with
connection commissioning/decommissioning; avoiding spurious alarms connection commissioning/decommissioning; avoiding spurious alarms
and ensuring consistent operation. In certain technologies OAM and ensuring consistent operation. In certain technologies, OAM
entities are inherently established once the connection is set up, entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and while other technologies require extra configuration to establish and
configure OAM entities. In some situations the use of OAM functions, configure OAM entities. In some situations the use of OAM functions,
like those of Fault- (FM) and Performance Management (PM), may be such as Fault Management (FM) and Performance Management (PM), may be
optional confirming to actual network management policies. Hence the optional (based on network management policies). Hence, the network
network operator must be able to choose which kind of OAM functions operator must be able to choose which set of OAM functions to apply
to apply to specific connections and with what parameters the to specific connections and which parameters should be configured and
selected OAM functions should be configured and operated. To achieve activated. To achieve this objective, OAM entities and specific
this objective OAM entities and specific functions must be functions must be selectively configurable.
selectively configurable.
In general, it is required that the management plane and control In general, it is required that the management plane and control
plane connection establishment mechanisms are synchronized with OAM plane connection establishment mechanisms are synchronized with OAM
establishment and activation. In particular, if the GMPLS control establishment and activation. In particular, if the GMPLS control
plane is employed it is desirable to bind OAM setup and configuration plane is employed, it is desirable to bind OAM setup and
to connection establishment signaling to avoid two separate configuration to connection establishment signaling to avoid two
management/configuration steps (connection setup followed by OAM separate management/configuration steps (connection setup followed by
configuration) which increases delay, processing and more importantly OAM configuration) which increases delay, processing, and more
may be prune to misconfiguration errors. Once OAM entities are setup importantly may be prone to misconfiguration errors. Once OAM
and configured, pro-active as well as on-demand OAM functions can be entities are setup and configured, pro-active as well as on-demand
activated via the management plane. On the other hand, it should be OAM functions can be activated via the management plane. On the
possible to activate/deactivate pro-active OAM functions via the other hand, it should be possible to activate/deactivate pro-active
GMPLS control plane as well. OAM functions via the GMPLS control plane as well.
This document describes requirements on OAM configuration and control This document describes requirements for OAM configuration and
via RSVP-TE, and specifies extensions to the RSVP-TE protocol control via RSVP-TE. Extensions to the RSVP-TE protocol are
providing a framework to configure and control OAM entities along specified providing a framework to configure and control OAM entities
with the capability to carry technology specific information. along with the capability to carry technology specific information.
Extensions can be grouped into generic elements that are applicable Extensions can be grouped into: generic elements that are applicable
to any OAM solution and technology specific elements that provide to any OAM solution; and technology specific elements that provide
additional configuration parameters, which are only needed for a additional configuration parameters, which may only be needed for a
specific OAM technology. This document specifies the technology specific OAM technology. This document specifies the technology
agnostic elements, which alone can be used to establish and control agnostic elements and specifies the way additional technology
OAM entities in the case no technology specific information is specific OAM parameters are provided.
needed, and specifies the way additional technology specific OAM
parameters are provided.
This document addresses end-to-end OAM configuration, that is, the This document addresses end-to-end OAM configuration, that is, the
setup of OAM entities bound to an end-to-end LSP, and configuration 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. and control of OAM functions running end-to-end in the LSP.
Configuration of OAM entities for LSP segments and tandem connections Configuration of OAM entities for LSP segments and tandem connections
are out of the scope of this document. are out of the scope of this document.
The mechanisms described in this document provide an additional The mechanisms described in this document provide an additional
option for bootstrapping OAM that is not intended to replace or option for bootstrapping OAM that is not intended to replace or
deprecate the use of other technology specific OAM bootstrapping deprecate the use of other technology specific OAM bootstrapping
techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The
procedures specified in this document are intended only for use in procedures specified in this document are intended only for use in
environments where RSVP-TE signaling is already in use to set up the environments where RSVP-TE signaling is used to set up the LSPs that
LSPs that are to be monitored using OAM. are to be monitored using OAM.
2. Requirements 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 MPLS OAM requirements are described in [RFC4377], which provides
requirements to create consistent OAM functionality for MPLS requirements to create consistent OAM functionality for MPLS
networks. networks. The following list is an excerpt of MPLS OAM requirements
documented in [RFC4377] that bear a direct relevance to the
The following list is an excerpt of MPLS OAM requirements documented discussion set forth in this document.
in [RFC4377]. Only a few requirements are discussed that bear a
direct relevance to the discussion set forth in this document.
o It is desired to support the automation of LSP defect detection. o It is desired to support the automation of LSP defect detection.
It is especially important in cases where large numbers of LSPs It is especially important in cases where large numbers of LSPs
might be tested. might be tested.
o In particular some LSPs may require automated ingress-LSR to o In particular some LSPs may require automated ingress-LSR to
egress-LSR testing functionality, while others may not. egress-LSR testing functionality, while others may not.
o Mechanisms are required to coordinate network responses to o Mechanisms are required to coordinate network responses to
defects. Such mechanisms may include alarm suppression, defects. Such mechanisms may include alarm suppression,
translating defect signals at technology boundaries, and translating defect signals at technology boundaries, and
synchronizing defect detection times by setting appropriately synchronizing defect detection times by setting appropriately
bounded detection timeframes. bounded detection time frames.
MPLS-TP defines a profile of MPLS targeted at transport applications MPLS-TP defines a profile of MPLS targeted at transport applications
[RFC5921]. This profile specifies the specific MPLS characteristics [RFC5921]. This profile specifies the specific MPLS characteristics
and extensions required to meet transport requirements, including and extensions required to meet transport requirements, including
providing additional OAM, survivability and other maintenance providing additional OAM, survivability, and other maintenance
functions not currently supported by MPLS. Specific OAM requirements functions not currently supported by MPLS. Specific OAM requirements
for MPLS-TP are specified in [RFC5654] [RFC5860]. MPLS-TP poses for MPLS-TP are specified in [RFC5654] and [RFC5860]. MPLS-TP poses
requirements on the control plane to configure and control OAM the following requirements on the control plane to configure and
entities: control OAM entities:
o From [RFC5860]: OAM functions MUST operate and be configurable o From [RFC5860]: OAM functions MUST operate and be configurable
even in the absence of a control plane. Conversely, it SHOULD be even in the absence of a control plane. Conversely, it SHOULD be
possible to configure as well as enable/disable the capability to possible to configure as well as enable/disable the capability to
operate OAM functions as part of connectivity management, and it operate OAM functions as part of connectivity management, and it
SHOULD also be possible to configure as well as enable/disable the SHOULD also be possible to configure as well as enable/disable the
capability to operate OAM functions after connectivity has been capability to operate OAM functions after connectivity has been
established. established.
o From [RFC5654]: The MPLS-TP control plane MUST support the o From [RFC5654]: The MPLS-TP control plane MUST support the
configuration and modification of OAM maintenance points as well configuration and modification of OAM maintenance points as well
as the activation/ deactivation of OAM when the transport path or as the activation/ deactivation of OAM when the transport path or
transport service is established or modified. transport service is established or modified.
Ethernet Connectivity Fault Management (CFM) defines an adjunct Ethernet Connectivity Fault Management (CFM) defines an adjunct
connectivity monitoring OAM flow to check the liveliness of Ethernet connectivity monitoring OAM flow to check the liveliness of Ethernet
networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet
support explicitly-routed Ethernet connections. CFM can be used to networks support explicitly-routed Ethernet connections. CFM can be
track the liveliness of PBB-TE connections and detect data plane used to track the liveliness of PBB-TE connections and detect data
failures. In IETF the GMPLS controlled Ethernet Label Switching plane failures. In IETF, the GMPLS controlled Ethernet Label
(GELS) (see [RFC5828] and [RFC6060]) work extended the GMPLS control Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the
plane to support the establishment of PBB-TE data plane connections. GMPLS control plane to support the establishment of PBB-TE data plane
Without control plane support separate management commands would be connections. Without control plane support, separate management
needed to configure and start CFM. commands would be needed to configure and start CFM.
GMPLS based OAM configuration and control should be general to be GMPLS based OAM configuration and control, needs to provide a general
applicable to a wide range of data plane technologies and OAM framework to be applicable to a wide range of data plane technologies
solutions. There are three typical data plane technologies used for and OAM solutions. There are three typical data plane technologies
transport application, which are wavelength based such as WSON, TDM used for transport applications: wavelength based such as WSON, TDM
based such as SDH/SONET, packet based such as MPLS-TP [RFC5921] and based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921]
Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes,
MUST be able to configure and control the following OAM functions. 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 o It MUST be possible to explicitly request the setup of OAM
entities for the signaled LSP and provide specific information for entities for the signaled LSP and provide specific information for
the setup if this is required by the technology. the setup if this is required by the technology.
o Control of alarms is important to avoid false alarm indications o Control of alarms is important to avoid false alarm indications
and reporting to the management system. It MUST be possible to and reporting to the management system. It MUST be possible to
enable/disable alarms generated by OAM functions. In some cases enable/disable alarms generated by OAM functions. In some cases,
selective alarm control may be desirable when, for instance, the selective alarm control may be desirable when, for instance, the
operator is only concerned about critical alarms thus the non- operator is only concerned about critical alarms. Therefore the
service affecting alarms should be inhibited. non-service affecting alarms should be inhibited.
o When periodic messages are used for liveliness check (continuity o When periodic messages are used for liveliness check (continuity
check) of LSPs it MUST be possible to set the frequency of check) of LSPs, it MUST be possible to set the frequency of
messages allowing proper configuration for fulfilling the messages. This allows proper configuration for fulfilling the
requirements of the service and/or meeting the detection time requirements of the service and/or meeting the detection time
boundaries posed by possible congruent connectivity check boundaries posed by possible congruent connectivity check
operations of higher layer applications. For a network operator operations of higher layer applications. For a network operator
to be able to balance the trade-off in fast failure detection and to be able to balance the trade-off between fast failure detection
overhead it is beneficial to configure the frequency of continuity and data overhead, it is beneficial to configure the frequency of
check messages on a per LSP basis. continuity check messages on a per LSP basis.
o Pro-active Performance Monitoring (PM) functions are continuously o Pro-active Performance Monitoring (PM) functions are used to
collecting information about specific characteristics of the continuously collect information about specific characteristics of
connection. For consistent measurement of Service Level the connection. For consistent measurement of Service Level
Agreements (SLAs) measurement points must use common probing rate Agreements (SLAs), it MUST be possible to set common configuration
to avoid measurement errors. parameters for the LSP.
o The extensions MUST allow the operator to use only a minimal set o The extensions MUST allow the operator to use only a minimal set
of OAM configuration and control features if the data plane of OAM configuration and control features if supported by the OAM
technology, the OAM solution or network management policy allows. solution or network management policy. Generic OAM parameters and
The extensions must be reusable as much as reasonably possible. data plane or OAM technology specific parameters MUST be
That is generic OAM parameters and data plane or OAM technology supported.
specific parameters must be separated.
3. RSVP-TE based OAM Configuration 3. RSVP-TE based OAM Configuration
In general, two types of Maintenance Points (MPs) can be In general, two types of Maintenance Points (MPs) can be
distinguished: Maintenance End Points (MEPs) and Maintenance distinguished: Maintenance End Points (MEPs) and Maintenance
Intermediate Points (MIPs). MEPs reside at the ends of an LSP and Intermediate Points (MIPs). MEPs reside at the ends of an LSP and
are capable of initiating and terminating OAM messages for Fault are capable of initiating and terminating OAM messages for Fault
Management (FM) and Performance Monitoring (PM). MIPs on the other Management (FM) and Performance Monitoring (PM). MIPs on the other
hand are located at transit nodes of an LSP and are capable of hand, are located at transit nodes of an LSP and are capable of
reacting to some OAM messages but otherwise do not initiate messages. reacting to some OAM messages but otherwise do not initiate messages.
Maintenance Entity (ME) refers to an association of MEPs and MIPs Maintenance Entity (ME) refers to an association of MEPs and MIPs
that are provisioned to monitor an LSP. The ME association is that are provisioned to monitor an LSP. The ME association is
achieved by configuring MPs to belong to the same ME. achieved by configuring MPs to belong to the same ME.
When an LSP is signaled, forwarding association is established When an LSP is signaled, a forwarding association is established
between endpoints and transit nodes via label bindings. This between endpoints and transit nodes via label bindings. This
association creates a context for the OAM entities monitoring the association creates a context for the OAM entities monitoring the
LSP. On top of this association OAM entities may be configured to LSP. On top of this association, OAM entities may be configured to
unambigously identify MPs and MEs. unambiguously identify MPs and MEs.
In addition to MP and ME identification parameters pro-active OAM In addition to MP and ME identification parameters, pro-active OAM
functions (e.g., Continuity Check (CC), Performance Monitoring) may functions (e.g., Continuity Check (CC) and Performance Monitoring
have specific parameters requiring configuration as well. In (PM)) may have additional parameters that require configuration as
particular, the frequency of periodic CC packets and the measurement well. In particular, the frequency of periodic CC packets and the
interval for loss and delay measurements may need to be configured. measurement interval for loss and delay measurements may need to be
configured.
In some cases all the above parameters may be either derived from The above parameters may be either derived from LSP provisioning
some exiting information or pre-configured default values can be information, or alternatively, pre-configured default values can be
used. In the simplest case the control plane needs to provide used. In the simplest case, the control plane provides information
information whether or not OAM entities need to be setup for the on whether or not OAM entities need to be setup for the signaled LSP.
signaled LSP. If OAM entities are created signaling must provide If OAM entities are created, control plane signaling must also
means to activate/deactivate OAM message flows and associated alarms. provide a means to activate/deactivate OAM message flows and
associated alarms.
OAM identifiers as well as the configuration of OAM functions are OAM identifiers, as well as the configuration of OAM functions, are
technology specific, i.e., vary depending on the data plane technology specific (i.e., vary depending on the data plane
technology and the chosen OAM solution. In addition, for any given technology and the chosen OAM solution). In addition, for any given
data plane technology a set of OAM solutions may be applicable. The data plane technology, a set of OAM solutions may be applicable.
OAM configuration framework allows selecting a specific OAM solution Therefore, the OAM configuration framework allows selecting a
to be used for the signaled LSP and provides technology specific TLVs specific OAM solution to be used for the signaled LSP and provides
to carry further detailed configuration information. means to carry detailed OAM configuration information in technology
specific TLVs.
3.1. Establishment of OAM Entities and Functions 3.1. Establishment of OAM Entities and Functions
In order to avoid spurious alarms OAM functions should be setup and In order to avoid spurious alarms, OAM functions should be setup and
enabled in the appropriate order. When using the GMPLS control enabled in the appropriate order. When using the GMPLS control
plane, establishment and enabling of OAM functions MUST be bound to plane, establishment and enabling of OAM functions MUST be bound to
RSVP-TE message exchanges. RSVP-TE message exchanges.
An LSP can be signaled and established without OAM configuration An LSP may be signaled and established without OAM configuration
first, and OAM entities can be added later with a subsequent re- first, and OAM entities may be added later with a subsequent re-
signaling of the LSP. Alternatively, the LSP can be setup with OAM signaling of the LSP. Alternatively, the LSP may be setup with OAM
entities right with the first signaling of the LSP. The below entities with the first signaling of the LSP. The below procedures
procedures apply to both cases. apply to both cases.
Before the initiator first sends a Path messages with OAM Before the initiating a Path message with OAM Configuration
Configuration information, it MUST establish and configure the information, an initiating node MUST establish and configure the
corresponding OAM entities locally, however OAM source functions MUST corresponding OAM entities locally. But until the LSP is
NOT start sending any OAM messages. In the case of bidirectional established, OAM source functions MUST NOT start sending any OAM
connections, the initiator node MUST setup the OAM sink function to messages. In the case of bidirectional connections, in addition to
be prepared to receive OAM messages but MUST suppress any OAM alarms the OAM source function, the initiator node MUST set up the OAM sink
(e.g., due to missing or unidentified OAM messages). The Path 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 message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag
cleared, i.e, data plane OAM alarms are suppressed. cleared.
When the Path message arrives at the receiver, the remote end MUST When the Path message arrives at the receiver, the remote end MUST
establish and configure OAM entities according to the OAM information establish and configure OAM entities according to the OAM information
provided in the Path message. If this is not possible a PathErr provided in the Path message. If this is not possible, a PathErr
SHOULD be sent and neither the OAM entities nor the LSP SHOULD be SHOULD be sent and neither the OAM entities nor the LSP SHOULD be
established. If OAM entities are established successfully, the OAM established. If OAM entities are established successfully, the OAM
sink function MUST be prepared to receive OAM messages but MUST not sink function MUST be prepared to receive OAM messages, but MUST NOT
generate any OAM alarms (e.g., due to missing or unidentified OAM generate any OAM alarms (e.g., due to missing or unidentified OAM
messages). In the case of bidirectional connections, an OAM source messages). In the case of bidirectional connections, in addition to
function MUST be setup and, according to the requested configuration, the OAM sink function, an OAM source function MUST be set up and,
the OAM source function MUST start sending OAM messages. Then a Resv according to the requested configuration, the OAM source function
message is sent back, including the OAM Configuration TLV that MUST start sending OAM messages. Then a Resv message is sent back,
corresponds to the actually established and configured OAM entities including the OAM Configuration TLV that corresponds to the actually
and functions. Depending on the OAM technology, some elements of the established and configured OAM entities and functions. Depending on
OAM Configuration TLV MAY be updated/changed; i.e., if the remote end the OAM technology, some elements of the OAM Configuration TLV MAY be
is not supporting a certain OAM configuration it may suggest an updated/changed; i.e., if the remote end is not supporting a certain
alternative setting, which may or may not be accepted by the OAM configuration it may suggest an alternative setting, which may or
initiator of the Path message. If it is accepted, the initiator will may not be accepted by the initiator of the Path message. If it is
reconfigure its OAM functions according to the information received accepted, the initiator will reconfigure its OAM functions according
in the Resv message. If the alternate setting is not acceptable a to the information received in the Resv message. If the alternate
ResvErr may be sent tearing down the LSP. Details of this operation setting is not acceptable a ResvErr may be sent tearing down the LSP.
are technology specific and should be described in accompanying Details of this operation are technology specific and should be
technology specific documents. described in accompanying technology specific documents.
When the initiating side receives the Resv message it completes any When the initiating side receives the Resv message, it completes any
pending OAM configuration and enables the OAM source function to send pending OAM configuration and enables the OAM source function to send
OAM messages. OAM messages.
After this round, OAM entities are established and configured for the After this exchange, OAM entities are established and configured for
LSP and OAM messages are already exchanged. OAM alarms can now be the LSP and OAM messages are exchanged. OAM alarms can now be
enabled. The initiator, while still keeping OAM alarms disabled enabled. The initiator, during the period when OAM alarms are
sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set. disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS
The receiving node enables the OAM alarms after processing the Path flag set. The receiving node enables the OAM alarms after processing
message. The initiator enables OAM alarms after it receives the Resv the Path message. The initiator enables OAM alarms after it receives
message. Data plane OAM is now fully functional. the Resv message. Data plane OAM is now fully functional.
3.2. Adjustment of OAM Parameters 3.2. Adjustment of OAM Parameters
There may be a need to change the parameters of an already There may be a need to change the parameters of an already
established and configured OAM function during the lifetime of the established and configured OAM function during the lifetime of the
LSP. To do so the LSP needs to be re-signaled with the updated LSP. To do so the LSP needs to be re-signaled with the updated
parameters. OAM parameters influence the content and timing of OAM parameters. OAM parameters influence the content and timing of OAM
messages and identify the way OAM defects and alarms are derived and messages and identify the way OAM defects and alarms are derived and
generated. Hence, to avoid spurious alarms, it is important that generated. Hence, to avoid spurious alarms, it is important that
both sides, OAM sink and source, are updated in a synchronized way. both sides, OAM sink and source, are updated in a synchronized way.
First, the alarms of the OAM sink function should be suppressed and First, the alarms of the OAM sink function should be suppressed and
only then should expected OAM parameters be adjusted. Subsequently, only then should expected OAM parameters be adjusted. Subsequently,
the parameters of the OAM source function can be updated. Finally, the parameters of the OAM source function can be updated. Finally,
the alarms of the OAM sink side can be enabled again. the alarms of the OAM sink side can be enabled again.
In accordance with the above operation, the LSP MUST first be re- In accordance with the above operation, the LSP MUST first be re-
signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared and signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared,
including the updated OAM Configuration TLV corresponding to the new including the updated OAM Configuration TLV corresponding to the new
parameter settings. The initiator MUST keep its OAM sink and source parameter settings. The initiator MUST keep its OAM sink and source
functions running unmodified, but it MUST suppress OAM alarms after functions running unmodified, but it MUST suppress OAM alarms after
the updated Path message is sent. The receiver MUST first disable the updated Path message is sent. The receiver MUST first disable
all OAM alarms, then update the OAM paramaters according to the all OAM alarms, then update the OAM parameters according to the
information in the Path message and reply with a Resv message information in the Path message and reply with a Resv message
acknowledging the changes by including the OAM Configuration TLV. acknowledging the changes by including the OAM Configuration TLV.
Note that the receiving side has the possibility to adjust the Note that the receiving side has the possibility to adjust the
requested OAM configuration parameters and reply with and updated OAM requested OAM configuration parameters and reply with an updated OAM
Configuration TLV in the Resv message, reflecting the actually Configuration TLV in the Resv message, reflecting the actually
configured values. However, in order to avoid an extensive configured values. However, in order to avoid an extensive
negotiation phase, in the case of adjusting already configured OAM negotiation phase, in the case of adjusting already configured OAM
functions, the receiving side SHOULD NOT update the parameters functions, the receiving side SHOULD NOT update the parameters
requested in the Path message to an extent that would provide lower requested in the Path message to an extent that would provide lower
performance than what has been configured previously. 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 The initiator MUST only update its OAM sink and source functions
after it received the Resv message. After this Path/Resv message after it received the Resv message. After this Path/Resv message
exchange (in both unidirectional and bidirectional LSP cases) the OAM exchange (in both unidirectional and bidirectional LSP cases) the OAM
parameters are updated and OAM is running according the new parameter parameters are updated and OAM is running according the new parameter
settings. However OAM alarms are still disabled. A subsequent Path/ settings. However, OAM alarms are still disabled. A subsequent
Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set Path/Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS
is needed to enable OAM alarms again. flag set is needed to enable OAM alarms again.
3.3. Deleting OAM Entities 3.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and 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. functions from an LSP without actually tearing down the connection.
To avoid any spurious alarm, first the LSP SHOULD be re-signaled with To avoid any spurious alarms, first the LSP MUST be re-signaled with
"OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM
configuration. Subsequently, the LSP is re-signaled with "OAM MEP configuration. Subsequently, the LSP is re-signaled with "OAM MEP
Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
cleared, and without the OAM Configuration TLV, this MUST result in cleared, and without the OAM Configuration TLV, this MUST result in
the deletion of all OAM entities associated with the LSP. All the deletion of all OAM entities associated with the LSP. All
control and data plane resources in use by the OAM entities and control and data plane resources in use by the OAM entities and
functions SHOULD be freed up. Alternatively, if only some OAM functions SHOULD be freed up. Alternatively, if only some OAM
functions need to be removed, the LSP is re-signalled with the functions need to be removed, the LSP is re-signaled with the updated
updated OAM Configuration TLV. Changes between the contents of the OAM Configuration TLV. Changes between the contents of the
previously signalled OAM Configuration TLV and the currently received previously signaled OAM Configuration TLV and the currently received
TLV represent which functions SHOULD be removed/added. TLV represent which functions MUST be removed/added.
First, OAM source functions SHOULD be deleted and only after that OAM source functions MUST be deleted first and only after the "OAM
SHOULD the associated OAM sink functions be removed, this will ensure Alarms Disabled" can the associated OAM sink functions be removed,
that OAM messages do not leak outside the LSP. To this end the this will ensure that OAM messages do not leak outside the LSP. To
initiator, before sending the Path message, SHOULD remove the OAM this end the initiator, before sending the Path message, MUST remove
source, hence terminating the OAM message flow associated to the the OAM source, hence terminating the OAM message flow associated to
downstream direction. In the case of a bidirectional connection, it the downstream direction. In the case of a bidirectional connection,
SHOULD leave in place the OAM sink functions associated to the it MUST leave in place the OAM sink functions associated to the
upstream direction. The remote end, after receiving the Path upstream direction. The remote end, after receiving the Path
message, SHOULD remove all associated OAM entities and functions and message, MUST remove all associated OAM entities and functions and
reply with a Resv message without an OAM Configuration TLV. The reply with a Resv message without an OAM Configuration TLV. The
initiator completely removes OAM entities and functions after the initiator completely removes OAM entities and functions after the
Resv message arrived. Resv message arrived.
4. RSVP-TE Extensions 4. RSVP-TE Extensions
4.1. LSP Attributes Flags 4.1. LSP Attributes Flags
In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 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 indicate options and attributes of the LSP. The Flags field has 8
skipping to change at page 13, line 44 skipping to change at page 10, line 48
an error must be generated: "OAM Problem/MEP establishment not an error must be generated: "OAM Problem/MEP establishment not
supported". supported".
If the "OAM MEP entities desired" bit is set and additional If the "OAM MEP entities desired" bit is set and additional
parameters need to be configured, an OAM Configuration TLV MAY be parameters need to be configured, an OAM Configuration TLV MAY be
included in the LSP_ATTRIBUTES Object. included in the LSP_ATTRIBUTES Object.
One bit (IANA to assign): "OAM MIP entities desired" is allocated in 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 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUES objects. This bit can only be set if the "OAM LSP_REQUIRED_ATTRIBUES objects. This bit can only be set if the "OAM
MEP entities desired" bit is set in. If the "OAM MIP entities MEP entities desired" bit is set. If the "OAM MIP entities desired"
desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the bit is set in the LSP_ATTRIBUTES Flags TLV in the
LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
establishment of OAM MIP entities is required at every transit node establishment of OAM MIP entities is required at every transit node
of the signalled LSP. If the establishment of a MIP is not supported of the signaled LSP. If the establishment of a MIP is not supported
an error MUST be generated: "OAM Problem/MIP establishment not an error MUST be generated: "OAM Problem/MIP establishment not
supported". supported".
4.2. OAM Configuration TLV 4.2. OAM Configuration TLV
This TLV provides information about which OAM technology/method This TLV provides information about which OAM technology/method
should be used and carries sub-TLVs for any additional OAM should be used and carries sub-TLVs for any additional OAM
configuration information. The OAM Configuration TLV MAY be carried configuration information. The OAM Configuration TLV MAY be carried
in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object it Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object,
is indicating that intermediate nodes MUST recognize and eventually it is indicating that intermediate nodes MUST recognize and
react on the OAM configuration onformation. eventually react on the OAM configuration information.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved | | OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub-TLVs ~ ~ sub-TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (3) (IANA to Type: indicates a new type: the OAM Configuration TLV (3) (IANA to
assign). assign).
OAM Type: specifies the technology specific OAM method. When carried OAM Type: specifies the technology specific OAM method. When carried
in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is
not supported at a given node an error MUST be generated: "OAM not supported at any given node an error MUST be generated: "OAM
Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES
Object, intermediate nodes not supporting the OAM Type pass the Object, intermediate nodes not supporting the OAM Type pass the
object forward unchanged as specified in [RFC5420] only Label Edge object forward unchanged as specified in [RFC5420], and only Label
Nodes MUST generate the error if the OAM Type is not supported. Edge Nodes MUST generate an error if the OAM Type is not supported at
the LSP end-point.
OAM Type Description OAM Type Description
------------ -------------------- ------------ --------------------
0-255 Reserved 0-255 Reserved
This document defines no types. IANA is requested to maintain the This document defines no types. IANA is requested to maintain the
values in a new "RSVP-TE OAM Configuration Registry". values in a new "RSVP-TE OAM Configuration Registry".
The receiving node based on the OAM Type will check if a The receiving node, based on the OAM Type, will check if a
corresponding technology specific OAM configuration sub-TLV is corresponding technology specific OAM configuration sub-TLV is
included. If the included technology specific OAM configuration sub- included in the OAM Configuration TLV. If the included technology
TLV is different than what is specified in the OAM Type an error MUST specific OAM configuration sub-TLV is different from what is
be generated: "OAM Problem/OAM Type Mismatch". IANA is requested to specified in the OAM Type an error MUST be generated: "OAM Problem/
maintain the sub-TLV space in the new "RSVP-TE OAM Configuration OAM Type Mismatch". IANA is requested to maintain the sub-TLV space
Registry". in the new "RSVP-TE OAM Configuration Registry".
Note that there is a hierarchical dependency in between the OAM Note that there is a hierarchical dependency in between the OAM
configuration elements. First, the "OAM MEP (and MIP) entities configuration elements. First, the "OAM MEP entities desired" flag
desired" flag needs to be set. Only when that is set MAY an "OAM needs to be set. Only when that flag is set MAY an "OAM
Configuration TLV" be included in the LSP_ATTRIBUTES or Configuration TLV" be included in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on
the "OAM Type" field, it MAY carry a technology specific OAM the "OAM Type" field, it MAY carry a technology specific OAM
configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP
entities desired" flag is not set but an OAM Configuration TLV is entities desired" flag is not set but an OAM Configuration TLV is
present) an error MUST be generated: "OAM Problem/Configuration present) an error MUST be generated: "OAM Problem/Configuration
Error". Error".
4.2.1. OAM Function Flags Sub-TLV 4.2.1. OAM Function Flags Sub-TLV
As the first sub-TLV the "OAM Function Flags sub-TLV" MUST be always As the first sub-TLV the "OAM Function Flags sub-TLV" MUST always be
included in the "OAM Configuration TLV". "OAM Function Flags" included in the "OAM Configuration TLV". "OAM Function Flags"
specifies which pro-active OAM functions (e.g., connectivity specifies which pro-active OAM functions (e.g., connectivity
monitoring, loss and delay measurement) and which fault management monitoring, loss and delay measurement) and which fault management
signals MUST be established and configured. If the selected OAM signals MUST be established and configured. If the selected OAM
Function(s) is(are) not supported, an error MUST be generated: "OAM Function(s) is(are) not supported, an error MUST be generated: "OAM
Problem/Unsupported OAM Function". Problem/Unsupported OAM Function".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Type (1) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ OAM Function Flags ~ ~ OAM Function Flags ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Function Flags is bitmap with extensible length based on the OAM Function Flags is bitmap with extensible length based on the
Lenght field of the TLV. Bits are numbered from left to right. IANA 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 is requested to maintain the OAM Function Flags in the new "RSVP-TE
OAM Configuration Registry". This document defines the following OAM Configuration Registry". This document defines the following
flags. flags.
OAM Function Flag bit# Description OAM Function Flag bit# Description
--------------------- --------------------------- --------------------- ---------------------------
0 Continuity Check (CC) 0 Continuity Check (CC)
1 Connectivity Verification (CV) 1 Connectivity Verification (CV)
2 Fault Monitoring Signal (FMS) 2 Fault Monitoring Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss) 3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay) 4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement 5 Performance Monitoring/Throughput Measurement
(PM/Throughput) (PM/Throughput)
4.2.2. Technology Specific sub-TLVs 4.2.2. Technology Specific sub-TLVs
One technology specific sub-TLV MAY be defined for each "OAM Type". One technology specific sub-TLV MAY be defined for each "OAM Type".
This sub-TLV MUST contain any further OAM configuration information This sub-TLV MUST contain any further OAM configuration information
for that specific "OAM Type". The technology specific sub-TLV, when for that specific "OAM Type". The technology specific sub-TLV, when
used, MUST be carried within the OAM Configuration TLV. IANA is used, MUST be carried within the OAM Configuration TLV. IANA is
requested to maintain the sub-TLV space in the new "RSVP-TE OAM requested to maintain the OAM technology specific sub-TLV space in
Configuration Registry". the new "RSVP-TE OAM Configuration Registry".
4.3. Administrative Status Information 4.3. Administrative Status Information
Administrative Status Information is carried in the ADMIN_STATUS Administrative Status Information is carried in the ADMIN_STATUS
Object. The Administrative Status Information is described in Object. The Administrative Status Information is described in
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
[RFC3473]. [RFC3473].
Two bits are allocated for the administrative control of OAM Two bits are allocated for the administrative control of OAM
monitoring. Two bits (IANA to assign) are allocated by this draft: 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" (M) and "OAM Alarms Enabled" (O) bits. When
the "OAM Flows Enabled" bit is set, OAM packets are sent if it is 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" cleared, no OAM packets are emitted. When the "OAM Alarms Enabled"
bit is set OAM triggered alarms are enabled and associated consequent bit is set OAM triggered alarms are enabled and associated consequent
actions are executed including the notification of the management actions are executed including the notification of the management
system. When this bit is cleared, alarms are suppressed and no system. When this bit is cleared, alarms are suppressed and no
action is executed and the management system is not notified. action is executed and the management system is not notified.
4.4. Handling OAM Configuration Errors 4.4. Handling OAM Configuration Errors
To handle OAM configuration errors a new Error Code (IANA to assign) To handle OAM configuration errors a new Error Code (IANA to assign)
"OAM Problem" is introduced. To refer to specific problems a set of "OAM Problem" is introduced. To refer to specific problems, a set of
Error Values is defined. Error Values are defined under the "OAM Problem" error code.
If a node does not support the establishment of OAM MEP or MIP If a node does not support the establishment of OAM MEP or MIP
entities it must use the error value (IANA to assign): "MEP entities it MUST use the error value: "MEP establishment not
establishment not supported" or "MIP establishment not supported" supported" or "MIP establishment not supported" respectively in the
respectively in the PathErr message.
If a node does not support a specific OAM technology/solution it must
use the error value (IANA to assign): "Unsupported OAM Type" in the
PathErr message. 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 If a different technology specific OAM configuration TLV is included
than what was specified in the OAM Type an error must be generated than what was specified in the OAM Type an error MUST be generated
with error value: "OAM Type Mismatch" in the PathErr message. with error value: "OAM Type Mismatch" in the PathErr message.
There is a hierarchy in between the OAM configuration elements. If There is a hierarchy in between the OAM configuration elements. If
this hierarchy is broken the error value: "Configuration Error" must this hierarchy is broken the error value: "Configuration Error" MUST
be used in the PathErr message. be used in the PathErr message.
If a node does not support a specific OAM Function it must use the If a node does not support a specific OAM Function it MUST use the
error value: "Unsupported OAM Function" in the PathErr message. error value: "Unsupported OAM Function" in the PathErr message.
4.5. Considerations on Point-to-Multipoint OAM Configuration 4.5. Considerations on Point-to-Multipoint OAM Configuration
RSVP-TE extensions for the establishment of point-to-multipoint RSVP-TE extensions for the establishment of point-to-multipoint
(P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of (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 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set
up between the ingress and egress LSRs and are appropriately combined up between the ingress and egress LSRs, and are appropriately
by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. combined by the branch LSRs using RSVP semantics to result in a P2MP
One Path message may signal one or multiple S2L sub-LSPs for a single TE LSP. One Path message may signal one or multiple S2L sub-LSPs for
P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP
signaled using one Path message or split across multiple Path can be signaled using one Path message or split across multiple Path
messages. messages.
P2MP OAM mechanisms are very specific to the data plane technology, P2MP OAM mechanisms are very specific to the data plane technology,
hence in this document we only highlight basic operations for P2MP therefore in this document we only highlight the basic principles of
OAM configuration. We consider only the configuration of the root to P2MP OAM configuration. We consider only the root to leaf OAM flows,
leaves OAM flows of P2MP LSPs and as such aspects of any return path and as such aspects of the configuration of return paths are outside
are outside the scope of our discussions. We also limit our the scope of our discussions. We also limit our consideration to the
consideration to cases where all leaves must successfully establish case where all leaves must successfully establish OAM entities with
OAM entities in order a P2MP OAM is successfully established. In any identical configuration in order the P2MP OAM is successfully
case, the discussion set forth below provides only guidelines for established. In any case, the discussion set forth below provides
P2MP OAM configuration, details SHOULD be specified in technology only guidelines for P2MP OAM configuration, details should be
specific documents. specified in technology specific documents.
The root node may select if it uses a single Path message or multiple The root node may use a single Path message or multiple Path messages
Path messages to setup the whole P2MP tree. In the case when to setup the whole P2MP tree. In the case when multiple Path
multiple Path messages are used the root node is responsible also to messages are used, the root node is responsible to keep the OAM
keep the OAM Configuration information consistent in each of the sent Configuration information consistent in each of the sent Path
Path messages, i.e., the same information MUST be included in all messages, i.e., the same information MUST be included in all Path
Path messages used to construct the multicast tree. Each branching messages used to construct the multicast tree. Each branching node
node will propagate the Path message downstream on each of the will propagate the Path message downstream on each of the branches,
branches, when constructing a Path message the OAM Configuration when constructing a Path message the OAM Configuration information
information MUST be copied unchanged from the received Path message, MUST be copied unchanged from the received Path message, including
including the related ADMIN_STATUS bits, LSP Attribute Flags and the the related ADMIN_STATUS bits, LSP Attribute Flags and the OAM
OAM Configuration TLV. The latter two also imply that the Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for the upstream
the upstream Path message to the subsequent downstream Path messages. Path message to the subsequent downstream Path messages.
Leaves MUST create and configure OAM sink functions according to the Leaves MUST create and configure OAM sink functions according to the
parameters received in the Path message, for P2MP OAM configuration parameters received in the Path message, for P2MP OAM configuration
there is no possibility for parameter negotiation on a per leaf there is no possibility for parameter negotiation on a per leaf
basis. This is due to the fact that the only OAM source function, basis. This is due to the fact that the OAM source function,
residing in the root of the tree, can only operate with a single residing in the root of the tree, will operate with a single
configuration which must be obeyed by all leaves. If a leaf cannot configuration, which then must be obeyed by all leaves. If a leaf
accept the OAM parameters it MUST use the RRO Attributes sub-object cannot accept the OAM parameters it MUST use the RRO Attributes sub-
[RFC5420] to notify the root of the problem. In particular, if the object [RFC5420] to notify the root about the problem. In
OAM configuration was successful the leaf would set the "OAM MEP particular, if the OAM configuration was successful, the leaf would
entities desired" flag in the RRO Attributes sub-object in the Resv set the "OAM MEP entities desired" flag in the RRO Attributes sub-
message, while, if due to any reason, OAM entities could not be object in the Resv message. On the other hand, if OAM entities could
established the Resv message should be sent with the "OAM MEP not be established the Resv message should be sent with the "OAM MEP
entities desired" bit cleared in the RRO Attributes sub-object. entities desired" bit cleared in the RRO Attributes sub-object.
Branching nodes should collect and merge the received RROs according Branching nodes should collect and merge the received RROs according
to the procedures described in [RFC4875]. This way, the root when to the procedures described in [RFC4875]. This way, the root when
receiving the Resv message (or messages if multiple Path messages receiving the Resv message (or messages if multiple Path messages
were used to setup the tree) will have a clear information on which were used to set up the tree) will have a clear information about
of the leaves could the OAM sink functions be established. If all which of the leaves could establish the OAM functions. If all leaves
leaves established OAM entities successfully, the root can enable the established OAM entities successfully, the root can enable the OAM
OAM message flow. On the other hand, if at some leaves the message flow. On the other hand, if at some leaves the establishment
establishment was unsuccessful additional actions will be needed was unsuccessful additional actions will be needed before the OAM
before the OAM message flow can be enabled. Such action could be to message flow can be enabled. Such action could be to setup two
setup two independent P2MP LSPs. One with OAM Configuration independent P2MP LSPs. One with OAM Configuration information
information towards leaves which successfully setup OAM. This can be towards leaves which could successfully setup the OAM function. This
done by prunning the leaves which failed to setup OAM of the can be done by pruning the leaves which failed to setup OAM of the
previously signalled P2MP LSP. The other P2MP LSP could be previously signaled P2MP LSP. The other P2MP LSP could be
constructed for leaves without OAM entities. What exact procedures constructed for leaves without OAM entities. The exact procedures
are needed are technology specific and SHOULD be described in SHOULD be described in technology specific documents.
technology specific documents.
5. IANA Considerations 5. IANA Considerations
Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs
to be allocated in the ADMIN_STATUS Object. to be allocated in the ADMIN_STATUS Object.
Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")
needs to be allocated in the LSP Attributes Flags Registry. needs to be allocated in the LSP Attributes Flags Registry.
This document specifies one new TLV to be carried in the This document specifies one new TLV to be carried in the
skipping to change at page 20, line 15 skipping to change at page 16, line 20
6. Security Considerations 6. Security Considerations
The signaling of OAM related parameters and the automatic The signaling of OAM related parameters and the automatic
establishment of OAM entities based on RSVP-TE messages adds a new establishment of OAM entities based on RSVP-TE messages adds a new
aspect to the security considerations discussed in [RFC3473]. In aspect to the security considerations discussed in [RFC3473]. In
particular, a network element could be overloaded, if a remote particular, a network element could be overloaded, if a remote
attacker could request liveliness monitoring, with frequent periodic attacker could request liveliness monitoring, with frequent periodic
messages, for a high number of LSPs, targeting a single network messages, for a high number of LSPs, targeting a single network
element. Such an attack can efficiently be prevented when mechanisms element. Such an attack can efficiently be prevented when mechanisms
for message integrity and node authentication are deployed. Since for message integrity and node authentication are deployed. Since
the OAM configuratiuon extensions rely on the hop-by-hop exchange of the OAM configuration extensions rely on the hop-by-hop exchange of
exiting RSVP-TE messages, procedures specified for RSVP message exiting RSVP-TE messages, procedures specified for RSVP message
security in [RFC2747] can be used to mitigate possible attacks. security in [RFC2747] can be used to mitigate possible attacks.
For a more comprehensive discussion on GMPLS security please see the For a more comprehensive discussion on GMPLS security please see the
Security Framework for MPLS and GMPLS Networks [RFC5920]. Security Framework for MPLS and GMPLS Networks [RFC5920].
Cryptography can be used to protect against many attacks described in Cryptography can be used to protect against many attacks described in
[RFC5920]. [RFC5920].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel, The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments. comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Signaling Functional Description", RFC 3471, January 2003. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
Signaling Resource ReserVation Protocol-Traffic (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. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5420] "Encoding of Attributes for Multiprotocol Label Switching [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
(MPLS) Label Switched Path (LSP) Establishment Using Ayyangarps, "Encoding of Attributes for MPLS LSP
Resource ReserVation Protocol-Traffic Engineering Establishment Using Resource Reservation Protocol Traffic
(RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
8.2. Informative References 8.2. Informative References
[IEEE-CFM] [IEEE.802.1Q-2011]
"IEEE 802.1ag, Draft Standard for Connectivity Fault IEEE, "IEEE Standard for Local and metropolitan area
Management", work in progress. networks -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress.
[RFC2747] "RSVP Cryptographic Authentication", RFC 2747, [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
January 2000. Authentication", RFC 2747, January 2000.
[RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Recovery", RFC 3469, February 2003. Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks",
RFC 4377, February 2006.
[RFC4377] "Operations and Management (OAM) Requirements for Multi- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Protocol Label Switched (MPLS) Networks", RFC 4377, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
Failures", RFC 4379, February 2006. "Extensions to Resource Reservation Protocol - Traffic
[RFC4875] "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5654] "Requirements of an MPLS Transport Profile", RFC 5654, [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
September 2009. and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5828] "GMPLS Ethernet Label Switching Architecture and [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized
Framework", RFC 5828, March 2010. Multiprotocol Label Switching (GMPLS) Ethernet Label
Switching Architecture and Framework", RFC 5828,
March 2010.
[RFC5860] "Requirements for OAM in MPLS Transport Networks", [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
RFC 5860, May 2010. Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC5920] "Security Framework for MPLS and GMPLS Networks", [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921, [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
July 2010. Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC6060] "Generalized Multiprotocol Label Switching (GMPLS) Control [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering of Ethernet Provider Backbone Traffic Engineering
(PBB-TE)", RFC 6060. (PBB-TE)", RFC 6060, March 2011.
Authors' Addresses Authors' Addresses
Attila Takacs Attila Takacs
Ericsson Ericsson
Konyves Kalman krt. 11. Konyves Kalman krt. 11.
Budapest, 1097 Budapest, 1097
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
 End of changes. 95 change blocks. 
320 lines changed or deleted 329 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/