Network Working Group A. Takacs
Internet-Draft Ericsson
Intended status: Standards Track D. Fedyk
Expires: August 1, 2010 Alcatel-Lucent
J. He
Huawei
January 28, 2010
OAM Configuration Framework and Requirements for GMPLS RSVP-TE
draft-ietf-ccamp-oam-configuration-fwk-03
Abstract
OAM is an integral part of transport connections, hence it is
required that OAM functions are activated/deactivated in sync with
connection commissioning/decommissioning; avoiding spurious alarms
and ensuring consistent operation. In certain technologies OAM
entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and
configure OAM entities. This document specifies extensions to
RSVP-TE to support the establishment and configuration of OAM
entities along with LSP signaling.
Takacs, et al. Expires August 1, 2010 [Page 1]
Internet-Draft GMPLS OAM Configuration Framework January 2010
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. 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 BSD License.
Takacs, et al. Expires August 1, 2010 [Page 2]
Internet-Draft GMPLS OAM Configuration Framework January 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. GMPLS based OAM Configuration . . . . . . . . . . . . . . . . 8
3.1. Establishment of OAM Entities and Functions . . . . . . . 8
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14
4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14
4.3. Administrative Status Information . . . . . . . . . . . . 14
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Discussion on Alternatives . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Takacs, et al. Expires August 1, 2010 [Page 3]
Internet-Draft GMPLS OAM Configuration Framework January 2010
1. Introduction
GMPLS is designed as an out-of-band control plane supporting dynamic
connection provisioning for any suitable data plane technology;
including spatial switching (e.g., incoming port or fiber to outgoing
port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet
Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS
Transport Profile (MPLS-TP). In most of these technologies there are
Operations and Management (OAM) functions employed to monitor the
health and performance of the connections and to trigger data plane
(DP) recovery mechanisms. Similarly to connections, OAM functions
follow general principles but also have some technology specific
characteristics.
OAM is an integral part of transport connections, hence it is
required that OAM functions are activated/deactivated in sync with
connection commissioning/decommissioning; avoiding spurious alarms
and ensuring consistent operation. In certain technologies OAM
entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and
configure OAM entities. In some situations the use of OAM functions,
like those of Fault- (FM) and Performance Management (PM), may be
optional confirming to actual network management policies. Hence the
network operator must be able to choose which kind of OAM functions
to apply to specific connections and with what parameters the
selected OAM functions should be configured and operated. To achieve
this objective OAM entities and specific functions must be
selectively configurable.
In general, it is required that the management plane and control
plane connection establishment mechanisms are synchronized with OAM
establishment and activation. In particular, if the GMPLS control
plane is employed it is desirable to bind OAM setup and configuration
to connection establishment signaling to avoid two separate
management/configuration steps (connection setup followed by OAM
configuration) which increases delay, processing and more importantly
may be prune to misconfiguration errors. Once OAM entities are setup
and configured, pro-active as well as on-demand OAM functions can be
activated via the management plane. On the other hand, it should be
possible to activate/deactivate pro-active OAM functions via the
GMPLS control plane as well.
This document describes requirements on OAM configuration and control
via RSVP-TE, and specifies extensions to the RSVP-TE protocol
providing a framework to configure and control OAM entities along
with the capability to carry technology specific information.
Extensions can be grouped into generic elements that are applicable
Takacs, et al. Expires August 1, 2010 [Page 4]
Internet-Draft GMPLS OAM Configuration Framework January 2010
to any OAM solution and technology specific elements that provide
additional configuration parameters, only needed for a specific OAM
technology. This document specifies the technology agnostic
elements, which alone can be used to establish and control OAM
entities in the case no technology specific information is needed,
and specifies the way additional technology specific OAM parameters
are provided.
This document addresses end-to-end OAM configuration, that is, the
setup of OAM entities bound to an end-to-end LSP, and configuration
and control of OAM functions running end-to-end in the LSP.
Configuration of OAM entities for LSP segments and tandem connections
are out of the scope of this document.
The mechanisms described in this document provide an additional
option for bootstrapping OAM that is not intended to replace or
deprecate the use of other technology specific OAM bootstrapping
techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The
procedures specified in this document are intended only for use in
environments where RSVP-TE signaling is already in use to set up the
LSPs that are to be monitored using OAM.
Takacs, et al. Expires August 1, 2010 [Page 5]
Internet-Draft GMPLS OAM Configuration Framework January 2010
2. Requirements
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]. Only a few requirements are discussed that bear a
direct relevance to the discussion set forth in this document.
o It is desired to support the automation of LSP defect detection.
It is especially important in cases where large numbers of LSPs
might be tested.
o In particular some LSPs may require automated ingress-LSR to
egress-LSR testing functionality, while others may not.
o Mechanisms are required to coordinate network responses to
defects. Such mechanisms may include alarm suppression,
translating defect signals at technology boundaries, and
synchronizing defect detection times by setting appropriately
bounded detection timeframes.
MPLS-TP defines a profile of MPLS targeted at transport applications
[MPLS-TP-FWK]. This profile specifies the specific MPLS
characteristics and extensions required to meet transport
requirements, including providing additional OAM, survivability and
other maintenance functions not currently supported by MPLS.
Specific OAM requirements for MPLS-TP are specified in
[MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane
to configure and control OAM entities:
o The use of OAM functions SHOULD be optional for the operator. A
network operator SHOULD be able to choose which OAM functions to
use and which Maintenance Entity to apply them to.
o The MPLS-TP control plane MUST support the configuration and
modification of OAM maintenance points as well as the activation/
deactivation of OAM when the transport path is established or
modified. OAM functions SHOULD be configurable as part of
connectivity (LSP or PW) management.
GMPLS based OAM configuration and control should be general to be
applicable to a wide range of data plane technologies and OAM
solutions. There are three typical data plane technologies used for
transport application, which are wavelength based such as WSON, TDM
based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK]
and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the
Takacs, et al. Expires August 1, 2010 [Page 6]
Internet-Draft GMPLS OAM Configuration Framework January 2010
operator MUST be able to configure and control the following OAM
functions.
o It MUST be possible to explicitly request the setup of OAM
entities for the signaled LSP and provide specific information for
the setup if this is required by the technology.
o Control of alarms is important to avoid false alarm indications
and reporting to the management system. It MUST be possible to
enable/disable alarms generated by OAM functions. In some cases
selective alarm control may be desirable when, for instance, the
operator is only concerned about critical alarms thus the non-
service affecting alarms should be inhibited.
o When periodic messages are used for liveliness check (continuity
check) of LSPs it MUST be possible to set the frequency of
messages allowing proper configuration for fulfilling the
requirements of the service and/or meeting the detection time
boundaries posed by possible congruent connectivity check
operations of higher layer applications. For a network operator
to be able to balance the trade-off in fast failure detection and
overhead it is beneficial to configure the frequency of continuity
check messages on a per LSP basis.
o Pro-active Performance Monitoring (PM) functions are continuously
collecting information about specific characteristics of the
connection. For consistent measurement of Service Level
Agreements (SLAs) it may be required that measurement points agree
on a common probing rate to avoid measurement problems.
o The extensions MUST allow the operator to use only a minimal set
of OAM configuration and control features if the data plane
technology, the OAM solution or network management policy allows.
The extensions must be reusable as much as reasonably possible.
That is generic OAM parameters and data plane or OAM technology
specific parameters must be separated.
Takacs, et al. Expires August 1, 2010 [Page 7]
Internet-Draft GMPLS OAM Configuration Framework January 2010
3. GMPLS based OAM Configuration
In general, two types of Maintenance Poits (MPs) can be
distinguished: Maintenance End Points (MEPs) and Maintenance
Intermediate Points (MIPs). MEPs reside at the ends of an LSP and
are capable of initiating and terminating OAM messages for Fault
Management (FM) and Performance Monitoring (PM). MIPs on the other
hand are located at transit nodes of an LSP and are capable of
reacting to some OAM messages but otherwise do not initiate messages.
Maintenance Entity (ME) refers to an association of MEPs and MIPs
that are provisioned to monitor an LSP. The ME association is
achieved by configuring MPs to belong to the same ME.
When an LSP is signaled, forwarding association is established
between endpoints and transit nodes via label bindings. This
association creates a context for the OAM entities monitoring the
LSP. On top of this association OAM entities may be configured to
unambigously identify MPs and MEs.
In addition to MP and ME identification parameters pro-active OAM
functions (e.g., Continuity Check (CC), Performance Monitoring) may
have specific parameters requiring configuration as well. In
particular, the frequency of periodic CC packets and the measurement
interval for loss and delay measurements may need to be configured.
In some cases all the above parameters may be either derived form
some exiting information or pre-configured default values can be
used. In the simplest case the control plane needs to provide
information whether or not OAM entities need to be setup for the
signaled LSP. If OAM entities are created signaling must provide
means to activate/deactivate OAM message flows and associated alarms.
OAM identifiers as well as the configuration of OAM functions are
technology specific, i.e., vary depending on the data plane
technology and the chosen OAM solution. In addition, for any given
data plane technology a set of OAM solutions may be applicable. The
OAM configuration framework allows selecting a specific OAM solution
to be used for the signaled LSP and provides technology specific TLVs
to carry further detailed configuration information.
3.1. Establishment of OAM Entities and Functions
In order to avoid spurious alarms OAM functions must 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
Takacs, et al. Expires August 1, 2010 [Page 8]
Internet-Draft GMPLS OAM Configuration Framework January 2010
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 right with the first signaling of the LSP. The below
procedures apply to both cases.
Before the initiator first sends a Path messages with OAM
Configuration information, it MUST establish and configure the
corresponding OAM entities locally, however OAM source functions MUST
NOT start sending any OAM messages. In the case of bidirectional
connections, the initiator node MUST setup the OAM sink function to
be prepared to receive OAM messages but MUST suppress any OAM alarms
(e.g., due to missing or unidentified OAM messages). The Path
message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag
cleared, i.e, data plane OAM alarms are suppressed.
When the Path message arrives at the receiver, the remote end MUST
establish and configure OAM entities according to the OAM information
provided in Path message. If this is not possible a PathErr 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, an OAM source
function MUST be setup and, according to the requested configuration,
it MUST start sending OAM messages. Then a Resv message is sent
back, including the OAM Configuration TLV that corresponds to the
actually 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 round, OAM entities are established and configured for the
LSP and OAM messages MAY already be exchanged. OAM alarms can now be
enabled. The initiator, while still keeping OAM alarms disabled
sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set.
The receiving node enables the OAM alarms after processing the Path
message. The initiator enables OAM alarms after it receives the Resv
Takacs, et al. Expires August 1, 2010 [Page 9]
Internet-Draft GMPLS OAM Configuration Framework January 2010
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 and
including the updated OAM Configuration TLV corresponding to the new
parameter settings. The initiator MUST keep its OAM sink and source
functions running unmodified, but it MUST suppress OAM alarms after
the updated Path message is sent. The receiver MUST first disable
all OAM alarms, then update the OAM paramaters according to the
information in the Path message and reply with a Resv message
acknowledging the changes by including the OAM Configuration TLV.
Note that the receiving side has the possibility to adjust the
requested OAM configuration parameters and reply with and updated OAM
Configuration TLV in the Resv message, reflecting the actually
configured values. However, in order to avoid an extensive
negotiation phase, in the case of adjusting already configured OAM
functions, the receiving side SHOULD NOT update the parameters
requested in the Path message to an extent that would provide lower
performance than what has been configured previously.
The initiator MUST only update its OAM sink and source functions
after it received the Resv message. After this Path/Resv message
exchange (in both unidirectional and bidirectional LSP cases) the OAM
parameters are updated and OAM is running according the new parameter
settings. However OAM alarms are still disabled. A subsequent Path/
Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set
is needed to enable OAM alarms again.
3.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and
functions from an LSP without actually tearing down the connection.
To avoid any spurious alarm, first the LSP SHOULD be re-signaled with
Takacs, et al. Expires August 1, 2010 [Page 10]
Internet-Draft GMPLS OAM Configuration Framework January 2010
"OAM Alarms" ADMIN_STATUS flag cleared but unchanged OAM
configuration. Subsequently, the LSP is re-signaled with "OAM MEP
Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
cleared, and without the OAM Configuration TLV, this MUST result in
the deletion of all OAM entities associated with the LSP. All
control and data plane resources in use by the OAM entities and
functions SHOULD be freed up. Alternatively, if only some OAM
functions need to be removed, the LSP is re-signalled with the
updated OAM Configuration TLV. Changes between the contents of the
previously signalled OAM Configuration TLV and the currently received
TLV represent which functions SHOULD be removed/added.
First, OAM source functions SHOULD be deleted and only after that
SHOULD the associated OAM sink functions be removed, this will ensure
that OAM messages do not leak outside the LSP. To this end the
initiator, before sending the Path message, SHOULD remove the OAM
source, hence terminating the OAM message flow associated to the
downstream direction. In the case of a bidirectional connection, it
SHOULD leave in place the OAM sink functions associated to the
upstream direction. The remote end, after receiving the Path
message, SHOULD remove all associated OAM entities and functions and
reply with a Resv message without an OAM Configuration TLV. The
initiator completely removes OAM entities and functions after the
Resv message arrived.
Takacs, et al. Expires August 1, 2010 [Page 11]
Internet-Draft GMPLS OAM Configuration Framework January 2010
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 (10 IANA to assign): "OAM MEP entities desired" is allocated
in the LSP Attributes Flags TLV. 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 are needed to be configured the OAM entities an OAM
Configuration TLV may be included in the LSP_ATTRIBUTES object.
One bit (11 IANA to assign): "OAM MIP entities desired" is allocated
in the LSP Attributes Flags TLV. This bit can only be set if the
"OAM MEP entities desired" bit is set. If the "OAM MIP entities
desired" bit is set in the LSP_ATTRIBUTES Flags TLV, it is indicating
that the establishment of OAM MIP entities is required at every
transit node of the signalled LSP. If the establishment of a MIP is
not supported an error must be generated: "OAM Problem/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
Takacs, et al. Expires August 1, 2010 [Page 12]
Internet-Draft GMPLS OAM Configuration Framework January 2010
configuration information. The OAM Configuration TLV may be carried
in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
Resv messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (2) (IANA to
assign).
OAM Type: specifies the technology specific OAM method. If the
requested OAM method is not supported an error must be generated:
"OAM Problem/Unsupported OAM Type".
OAM Type Description
------------ --------------------
0-255 Reserved
This document defines no types. IANA is requests 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. If the included technology specific OAM configuration sub-
TLV is different than what is specified in the OAM Type an error must
be generated: "OAM Problem/OAM Type Mismatch".
Note that there is a hierarchical dependency in between the OAM
configuration elements. First, the "OAM MEP (and MIP) entities
desired" flag needs to be set. When it is set an "OAM Configuration
TLV" may 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".
Takacs, et al. Expires August 1, 2010 [Page 13]
Internet-Draft GMPLS OAM Configuration Framework January 2010
4.2.1. OAM Function Flags Sub-TLV
As the first sub-TLV one "OAM Function Flags sub-TLV" MUST be always
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".
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines the following flags.
OAM Function Flag Description
--------------------- ---------------------------
0 Continuity Check (CC)
1 Connectivity Verification (CV)
2 Performance Monitoring/Loss (PM/Loss)
3 Performance Monitoring/Delay (PM/Delay)
4.2.2. Technology Specific sub-TLVs
One technology specific sub-TLV SHOULD 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 may be carried within the OAM Configuration TLV.
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. In addition to the Reflect (R) bit, 7 bits are currently
occupied (assigned by IANA or temporarily blocked by work in progress
Takacs, et al. Expires August 1, 2010 [Page 14]
Internet-Draft GMPLS OAM Configuration Framework January 2010
Internet drafts). As the 24th and 25th bits (IANA to assign) this
draft introduces 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" bit is set OAM triggered alarms are enabled and
associated consequent actions are executed including the notification
of 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 is defined.
If a node does not support the establishment of OAM MEP or MIP
entities it must use the error value (IANA to assign): "MEP
establishment not supported" or "MIP establishment not supported"
respectively in the PathErr message.
If a node does not support a specific OAM technology/solution it must
use the error value (IANA to assign): "Unsupported OAM Type" in the
PathErr message.
If a different technology specific OAM configuration TLV is included
than what was specified in the OAM Type an error must be generated
with error value: "OAM Type Mismatch" in the PathErr message.
There is a hierarchy in 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.
Takacs, et al. Expires August 1, 2010 [Page 15]
Internet-Draft GMPLS OAM Configuration Framework January 2010
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" and "Unsupported OAM
Function" needs to be assigned.
The IANA is requested to open a new registry: "RSVP-TE OAM
Configuration Registry" that maintains the "OAM Type" code points and
the allocations of "OAM Function Flags" within the OAM Configuration
TLV.
Takacs, et al. Expires August 1, 2010 [Page 16]
Internet-Draft GMPLS OAM Configuration Framework January 2010
6. Security Considerations
The signaling of OAM related parameters and the automatic
establishment of OAM entities introduces additional security
considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element.
Security aspects will be covered in more detailed in subsequent
versions of this document.
Takacs, et al. Expires August 1, 2010 [Page 17]
Internet-Draft GMPLS OAM Configuration Framework January 2010
7. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments.
Takacs, et al. Expires August 1, 2010 [Page 18]
Internet-Draft GMPLS OAM Configuration Framework January 2010
Appendix A. Discussion on Alternatives
This appendix summarizes the discussions after IETF-71 about the way
OAM configuration information should be carried in RSVP-TE.
The first question is how the requirement for OAM establishment is
signaled and how the operation of OAM is controlled. There is a
straightforward way to achieve these using existing objects and
fields:
o Use one or more OAM flags in the LSP Attributes Flag TLV within
the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that
OAM entities for the LSP need to be established. If for any
reason this cannot be done a notification is sent or an error is
raised.
o Once the LSP with the desired OAM entities is established OAM
operation may be controlled using one or more flags in the
ADMIN_STATUS object. For instance, the generation of connectivity
monitoring messages can be disabled/enabled by setting/clearing a
flag in the ADMIN_STATUS object.
However, there are two alternatives when it comes to signaling the
actual configuration parameters of OAM entities.
o Extension of the LSP_ATTRIBUTES object with new TLVs.
o Definition of a new RSVP-TE object to carry OAM information.
In the first case, a new OAM configuration TLV is defined in the
LSP_ATTRIBUTES object. This TLV would provide the detailed
information needed for LSPs with a set OAM flag in the LSP Attributes
Flag TLV. The rationale for this approach is that in addition to
setting flags the LSP_ATTRIBUTES object may carry complementary
information for all or some of the flags set. Furthermore, as top
level RSVP-TE objects may become scarce resources, it seems to be
beneficial not to allocate new RSVP-TE objects for the purpose of
providing detailed information for new LSP Attribute Flags.
Currently there is only one TLV, the Attributes Flag TLV, defined in
the LSP_ATTRIBUTES object. Defining a new TLV associated with one of
the flags would make a precedence and possibly be a guideline for
similar future extensions.
The other alternative would be to allocate a dedicated object for OAM
configuration information. The rationale for this is that the
complex information that may be required for OAM configuration would
unnecessarily add complexity to LSP_ATTRIBUTES/
LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms.
Takacs, et al. Expires August 1, 2010 [Page 19]
Internet-Draft GMPLS OAM Configuration Framework January 2010
Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to
carry configuration information of data plane entities, thus a new
object like an "OAM_SPEC" may be a better fit to existing protocol
elements.
The authors of this document favor the first alternative (adding new
TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which
alternative to select for standardization is up for the working group
to decide. In any case, the information to be carried would be the
same or very similar for both alternatives.
Takacs, et al. Expires August 1, 2010 [Page 20]
Internet-Draft GMPLS OAM Configuration Framework January 2010
8. References
[GELS-Framework]
"GMPLS Ethernet Label Switching Architecture and
Framework", Internet Draft, work in progress.
[GMPLS-OAM]
"OAM Requirements for Generalized Multi-Protocol Label
Switching (GMPLS) Networks", Internet Draft, work in
progress.
[IEEE-CFM]
"IEEE 802.1ag, Draft Standard for Connectivity Fault
Management", work in progress.
[IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress.
[MPLS-TP-FWK]
"A Framework for MPLS in Transport Networks", Internet
Draft, work in progress.
[MPLS-TP-OAM-REQ]
"Requirements for OAM in MPLS Transport Networks",
Internet Draft, work in progress.
[RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based
Recovery", RFC 3469, February 2003.
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4377] "Operations and Management (OAM) Requirements for Multi-
Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006.
[RFC5420] "Encoding of Attributes for Multiprotocol Label Switching
(MPLS) Label Switched Path (LSP) Establishment Using
Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 5420, February 2009.
Takacs, et al. Expires August 1, 2010 [Page 21]
Internet-Draft GMPLS OAM Configuration Framework January 2010
Authors' Addresses
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Don Fedyk
Alcatel-Lucent
Groton, MA 01450
USA
Email: donald.fedyk@alcatel-lucent.com
Jia He
Huawei
Email: hejia@huawei.com
Takacs, et al. Expires August 1, 2010 [Page 22]
