draft-ietf-ccamp-oam-configuration-fwk-00.txt   draft-ietf-ccamp-oam-configuration-fwk-01.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: June 26, 2009 Nortel Expires: September 10, 2009 Nortel
H. Jia J. He
Huawei Huawei
December 23, 2008 March 9, 2009
OAM Configuration Framework and Requirements for GMPLS RSVP-TE OAM Configuration Framework and Requirements for GMPLS RSVP-TE
draft-ietf-ccamp-oam-configuration-fwk-00 draft-ietf-ccamp-oam-configuration-fwk-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 26, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 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. to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
OAM functions are essential to ensure that the desired service level OAM is an integral part of transport connections, hence it is
of traffic engineered connections are met. In certain technologies required that OAM functions are activated/deactivated in sync with
OAM entities are inherently established once the connection is set connection commissioning/decommissioning; avoiding spurious alarms
up. However other technologies, especially OAM for packet switched and ensuring consistent operation. In certain technologies OAM
networks, require an extra configuration step after connection entities are inherently established once the connection is set up,
establishment to setup OAM entities. This document specifies while other technologies require extra configuration to establish
extensions to RSVP-TE to support the establishment and configuration and configure OAM entities. This document specifies extensions to
of OAM entities along with LSP signalling. RSVP-TE to support the establishment and configuration of OAM
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
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 9 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 10
3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 9 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 10
3.2. OAM entities desired -- LSP Attributes flag . . . . . . . 10 3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 11
3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12
3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 11 3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 13
3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 12 3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Discussion on alternatives . . . . . . . . . . . . . 16 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
Operations and Management (OAM) functions are essential to ensure GMPLS is designed as an out-of-band control plane supporting dynamic
that the desired service level of traffic engineered connections are connection provisioning for any suitable data plane technology;
met. OAM functions ease network operation by reducing complexity, including spatial switching (e.g., incoming port or fiber to outgoing
enhance network survivability, verify network performance, and in port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
turn reduce operational costs. division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet
Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS
In certain technologies OAM entities are inherently established once Transport Profile (MPLS-TP). In most of these technologies there are
the connection is set up. However other technologies, especially OAM Operations and Management (OAM) functions employed to monitor the
for packet switched networks, require an extra configuration step health and performance of the connections and to trigger data plane
after connection establishment to setup OAM entities. (DP) recovery mechanisms. Similarly to connections, OAM functions
follow general principles but also have some technology specific
In some situations the use of OAM functions, like those of Fault- characteristics.
(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.
The GMPLS control plane consists of a set of protocols: OSPF-TE,
RSVP-TE and LMP. which are used to reduce manual configuration and
improve management efficiency. RSVP-TE is used to setup and
configure end-to-end connections. A new useful application of
RSVP-TE is OAM configuration and control for transport networks.
When RSVP-TE is used for LSP establishment it is desirable to bind OAM is an integral part of transport connections, hence it is
OAM setup to connection establishment signalling to avoid two required that OAM functions are activated/deactivated in sync with
separate management/configuration steps (connection setup followed by connection commissioning/decommissioning; avoiding spurious alarms
OAM configuration) which increases delay, processing and more and ensuring consistent operation. In certain technologies OAM
importantly may be prune to misconfiguration errors. 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.
The mechansim described in this document provides an additional In general, it is required that the management plane and control
option for bootstrapping OAM that is not intended to replace or plane connection establishment mechanisms are synchronized with OAM
deprecate the use of other OAM bootstrapping techniques such as LSP establishment and activation. In particular, if the GMPLS control
Ping [RFC4379]. The procedures specified in this document are plane is employed it is desirable to bind OAM setup and configuration
intended only for use in environments where RSVP-TE signaling is to connection establishment signaling to avoid two separate
already in use to set up the LSPs that are to be monitored using OAM. 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 This document describes requirements on OAM configuration and control
via RSVP-TE, and specifies extensions to the RSVP-TE protocol via RSVP-TE, and specifies extensions to the RSVP-TE protocol
providing a framework to configure and control OAM entities along providing a framework to configure and control OAM entities along
with capability to carry technology specific information. Extensions with capability to carry technology specific information. Extensions
can be grouped into generic elements that are applicable to any OAM can be grouped into generic elements that are applicable to any OAM
solution and technology specific elements that provide additional solution and technology specific elements that provide additional
configuration parameters only needed for a specific OAM technology. configuration parameters only needed for a specific OAM technology.
This document specifies the technology agnostic elements that alone This document specifies the technology agnostic elements which alone
can be used to establish OAM entities in the case no technology can be used to establish and control OAM entities in the case no
specific information is needed, and specifies the way additional technology specific information is needed, and specifies the way
technology specific OAM parameters are provided. additional technology specific OAM parameters are provided.
The mechanisms described in this document provide an additional
option for bootstrapping OAM that is not intended to replace or
deprecate the use of other technology specific OAM bootstrapping
techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The
procedures specified in this document are intended only for use in
environments where RSVP-TE signaling is already in use to set up the
LSPs that are to be monitored using OAM.
2. Requirements 2. Requirements
MPLS OAM requirements are described in [RFC4377]. It provides MPLS OAM requirements are described in [RFC4377]. It provides
requirements to create consistent OAM functionality for MPLS requirements to create consistent OAM functionality for MPLS
networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The
GMPLS OAM requirements are based on the MPLS OAM requirements GMPLS OAM requirements are based on the MPLS OAM requirements
[RFC4377], in addition it also considers the existing OAM techniques [RFC4377], in addition it also considers the existing OAM techniques
in non-packet networks. in non-packet networks.
skipping to change at page 6, line 28 skipping to change at page 7, line 28
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
synchronising defect detection times by setting appropriately synchronizing defect detection times by setting appropriately
bounded detection timeframes. bounded detection timeframes.
MPLS-TP defines a profile of MPLS targeted at transport applications MPLS-TP defines a profile of MPLS targeted at transport applications
[MPLS-TP-FWK]. This profile specifies the specific MPLS [MPLS-TP-FWK]. This profile specifies the specific MPLS
characteristics and extensions required to meet transport characteristics and extensions required to meet transport
requirements, including providing additional OAM, survivability and requirements, including providing additional OAM, survivability and
other maintenance functions not currently supported by MPLS. other maintenance functions not currently supported by MPLS.
Specific OAM requirements for MPLS-TP are specified in Specific OAM requirements for MPLS-TP are specified in
[MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane
to configure and control OAM entities. to configure and control OAM entities.
skipping to change at page 7, line 22 skipping to change at page 8, line 22
GMPLS based OAM configuration and control should be general to be GMPLS based OAM configuration and control should be general to be
applicable to a wide range of data plane technologies and OAM applicable to a wide range of data plane technologies and OAM
solution. There are three typical data plane technologies used for solution. There are three typical data plane technologies used for
transport application, which are wavelength based such as WSON, TDM transport application, which are wavelength based such as WSON, TDM
based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK] 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 and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the
operator MUST be able to configure and control the following OAM operator MUST be able to configure and control the following OAM
functions. 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 signalled LSP and provide specific information entities for the signaled LSP and provide specific information for
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
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 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 allowing 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 in fast failure detection and
overhead it is beneficial to configure the frequency of continuity overhead it is beneficial to configure the frequency of continuity
check messages on a per LSP basis. check messages on a per LSP basis.
o Control of alarms is important to avoid false alarm indications o Pro-active Performance Monitoring (PM) functions are continuously
and reporting to the management system. It MUST be possible to collecting information about specific characteristics of the
enable/disable alarms generated by OAM functions. In some cases connection. For consistent measurement of Service Level
selective alarm control may be desirable when, for instance, the Agreements (SLAs) it may be required that measurement points agree
operator is only concerned about critical alarms thus the non- on a common probing rate to avoid measurement problems.
service affecting alarms should be inhibited.
o Performance Monitoring (PM) is continuously collecting information
about specific characteristics of the connection. It MUST be
possible to configure PM functions, e.g., set monitoring intervals
and thresholds for PM initiated alarms. 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 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 the data plane
technology, the OAM solution or network management policy allows. technology, the OAM solution or network management policy allows.
The extensions must be reusable as much as reasonably possible. The extensions must be reusable as much as reasonably possible.
That is generic OAM parameters and data plane or OAM technology That is generic OAM parameters and data plane or OAM technology
specific parameters must be separated. specific parameters must be separated.
3. GMPLS RSVP-TE Extensions 3. GMPLS RSVP-TE Extensions
3.1. Operation overview 3.1. Operation overview
Two types of Maintenance Poits (MPs) are distinguished: Maintenance In general, two types of Maintenance Poits (MPs) can be
End Points (MEPs) and Maintenance Intermediate Points (MIPs). MEPs distinguished: Maintenance End Points (MEPs) and Maintenance
are located at the ends of an LSP and are capable of initiating and Intermediate Points (MIPs). MEPs are located at the ends of an LSP
terminating OAM packets for Fault Management (FM) and Performance and are capable of initiating and terminating OAM messages for Fault
Monitoring (PM). MIPs on the other hand are located at transit nodes Management (FM) and Performance Monitoring (PM). MIPs on the other
of an LSP and are capable of reacting to some OAM packets but hand are located at transit nodes of an LSP and are capable of
otherwise do not initiate packets. Maintenance Entity (ME) refers to reacting to some OAM messages but otherwise do not initiate messages.
an association of MEPs and MIPs that are provisioned to monitor an Maintenance Entity (ME) refers to an association of MEPs and MIPs
LSP. The ME association is achieved by configuring MPs of an ME with that are provisioned to monitor an LSP. The ME association is
the same unique ME ID. Each MEP must have unique identification (MEP achieved by configuring MPs of an ME with the same unique ME
ID) within the ME. Assocication ID (MA ID). Each MEP must have unique identification
(MEP ID) within a Maintenance Entity.
When an LSP is signalled forwarding association is established When an LSP is signaled forwarding association is established between
between endpoints and transit nodes via label bindings. This endpoints and transit nodes via label bindings. This association
association creates a context for the OAM entities monitoring the creates a context for the OAM entities monitoring the LSP. On top of
LSP. On top of this association OAM entities may be configured with this association OAM entities may be configured with an MA ID and MEP
an ME ID and MEP IDs. The ME ID may be used to detect IDs. The MA ID may be used to detect misconfiguration errors and
misconfiguration errors and leacking OAM traffic. Within the ME the leaking OAM traffic. While the MEP ID can be used to demultiplex and
MEP ID can be used to demultiplex and identify the originating MEP of identify the originating MEP of OAM messages. Since MIPs do not
OAM packets. Since MIPs do not originate OAM packets no specific originate OAM packets, on top of the configuration of Maintenance
configuration is required for them. Entity associations, no specific configuration is required for them.
In addition to the ME and MEP identification parameters pro-active In addition to the MA and MEP identification parameters pro-active
OAM functions (e.g., Continuity Check (CC), Performance Monitoring) OAM functions (e.g., Continuity Check (CC), Performance Monitoring)
may have specific parameters requiring configuration as well. In may have specific parameters requiring configuration as well. In
particular, the frequency of periodic CC packets and the measurement particular, the frequency of periodic CC packets and the measurement
interval for loss and delay measurements may need to be configured. interval for loss and delay measurements may need to be configured.
MEP MEP
+-------------+ +-------------+
|OAM Functions| |OAM Functions|
| FM | PM | | FM | PM |
+------+------+ +------+------+
| MEP ID | | MEP ID |
+-------------+ +-------------+
| ME ID | | MA ID |
+-------------+ +-------------+
+-------------+ +-------------+
| LSP | | connection |
+-------------+ +-------------+
In some cases all the above parameters may be either derived form In some cases all the above parameters may be either derived form
some exiting information or pre-configured default values can be some exiting information or 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 needs to provide
information whether or not a ME with MPs need to be setup for the information whether or not a MA with MPs need to be setup for the
signalled LSP. If OAM entities are created signalling must provide signaled LSP. If OAM entities are created signaling must provide
means to activate/deactivate OAM message flows and associated alarms. means to activate/deactivate OAM message flows and associated alarms.
ME and MEP IDs as well as configuration of OAM functions are MA and MEP IDs as well as 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. The
OAM configuration framework allows selecting a specific OAM solution OAM configuration framework allows selecting a specific OAM solution
to be used for the signalled LSP and provides technology specific to be used for the signaled LSP and provides technology specific TLVs
TLVs to carry further detailed configuration information. to carry further detailed configuration information.
3.2. OAM entities desired -- LSP Attributes flag 3.2. 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
bits and hence is limited to differentiate only 8 options. [RFC4420] bits and hence is limited to differentiate only 8 options. [RFC4420]
defines a new object for RSVP-TE messages to allow the signalling of defines a new object for RSVP-TE messages to allow the signaling of
arbitrary attribute parameters making RSVP-TE easily extensible to arbitrary attribute parameters making RSVP-TE easily extensible to
support new applications. Furthermore, [RFC4420] allows options and support new applications. Furthermore, [RFC4420] allows options and
attributes that do not need to be acted on by all Label Switched attributes that do not need to be acted on by all Label Switched
Routers (LSRs) along the path of the LSP. In particular, these 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 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 the ingress LSR and egress LSR. Options and attributes can be
signalled transparently, and only examined at those points that need signaled transparently, and only examined at those points that need
to act on them. The LSP_ATTRIBUTES object and the to act on them. The LSP_ATTRIBUTES object and the
LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide
means to signal LSP attributes and options in the form of TLVs. means to signal LSP attributes and options in the form of TLVs.
Options and attributes signalled in the LSP_ATTRIBUTES object can be Options and attributes signaled in the LSP_ATTRIBUTES object can be
passed transparently through LSRs not supporting a particular option passed transparently through LSRs not supporting a particular option
or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES
object must be examined and processed by each LSR. One TLV is object must be examined and processed by each LSR. One TLV is
defined in [RFC4420]: the Attributes Flags TLV. defined in [RFC4420]: the Attributes Flags TLV.
A new bit (10 IANA to assign): "OAM entities desired" is allocated in One bit (10 IANA to assign): "OAM MEP entities desired" is allocated
the LSP Attributes Flags TLV. If the "OAM entities desired" bit is in the LSP Attributes Flags TLV. If the "OAM MEP entities desired"
set it is indicating that the establishment of OAM entities are bit is set it is indicating that the establishment of OAM MEP
required at the endpoints of the signalled LSP. If the establishment entities are required at the endpoints of the signaled LSP. If the
of OAM entities is not supported an error must be generated: "OAM establishment of MEPs is not supported an error must be generated:
Problem/OAM establishment not supported". "OAM Problem/MEP establishment not supported".
If the "OAM entities desired" bit is set and additional parameters If the "OAM MEP entities desired" bit is set and additional
are needed to configure the OAM entities an OAM Configuration TLV may parameters are needed to configure the OAM entities an OAM
be included in the LSP_ATTRIBUTES object. 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. If the "OAM MIP entities desired"
bit is set it is indicating that the establishment of OAM MIP
entities are required at the transit nodes of the signaled LSP. This
bit can only be set if the "OAM MEP entities desired" bit is set. If
the establishment of MIPs is not supported an error must be
generated: "OAM Problem/MIP establishment not supported".
One bit (12 IANA to assign): "Alarm indication desired" is allocated
in the LSP Attributes Flags TLV. If the "Alarm indication desired"
bit is set it is indicating that the OAM entities of the signaled LSP
should be notified of lower layer failures. In the case of
hierarchical LSPs this will create an association between the
underlying (server) LSP's OAM entities and the currently signaled
(client) LSP's OAM entities.
3.3. OAM Configuration TLV 3.3. OAM Configuration TLV
This TLV specifies which OAM technology/method should be used for the This TLV specifies which OAM technology/method should be used for the
LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES
object in Path messages. object in Path messages.
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 (2) (IANA) | Length | | Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | OAM Function | Reserved (set to all 0s) | | OAM Type | Reserved | OAM Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (2) (IANA to Type: indicates a new type: the OAM Configuration TLV (2) (IANA to
assign). assign).
OAM Type: specifies the technology specify OAM method. If the OAM Type: specifies the technology specify OAM method. If the
requested OAM method is not supported an error must be generated: requested OAM method is not supported an error must be generated:
"OAM Problem/Unsupported OAM Type". "OAM Problem/Unsupported OAM Type".
This document defines no types. The receiving node based on the OAM This document defines no types. The receiving node based on the OAM
Type will check if a corresponding technology specific OAM Type will check if a corresponding technology specific OAM
configuration TLV is included. configuration sub-TLV is included. If different technology specific
OAM configuration sub-TLV is included than what was specified in the
OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch".
OAM Function Flags: specifies proactive OAM functions (e.g., OAM Type Description
------------ --------------------
0-255 Reserved
There is a hierarchy in between the OAM configuration elements.
First, the "OAM MEP (and MIP) entities desired" flag needs to be set,
if it is set an "OAM Configuration TLV" may be included in the
LSP_ATTRIBUTES object, if this TLV is present based on the OAM Type a
technology specific OAM configuration sub-TLV may be present. 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".
OAM Function Flags: specifies pro-active OAM functions (e.g.,
connectivity monitoring, loss and delay measurement) that should be connectivity monitoring, loss and delay measurement) that should be
established and configured. If the selected OAM Function(s) is(are) established and configured. If the selected OAM Function(s) is(are)
not supported an error must be generated: "OAM Problem/Unsupported not supported an error must be generated: "OAM Problem/Unsupported
OAM Function". OAM Function".
This document defines the following flags. This document defines the following flags.
OAM Function Flag Description OAM Function Flag Description
--------------------- --------------------------- --------------------- ---------------------------
0 Connectivity Monitoring 0 Connectivity Monitoring
1-7 Reserved 1 Performance Monitoring/Loss
2 Performance Monitoring/Delay
3.4. Monitoring Disabled - Admin_Status bit 3.4. Monitoring Disabled - Admin_Status bit
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].
One bit is allocated for the administrative control of OAM One bit is allocated for the administrative control of OAM
monitoring. In addition to the Reflect (R) bit, 7 bits are currently monitoring. In addition to the Reflect (R) bit, 7 bits are currently
occupied (assigned by IANA or temporarily blocked by work in progress occupied (assigned by IANA or temporarily blocked by work in progress
Internet drafts). As the 24th bit (IANA to assign) this draft Internet drafts). As the 24th bit (IANA to assign) this draft
introduces the Monitoring Disabled (M) bit. When this bit is set the introduces the Monitoring Disabled (M) bit. When this bit is set the
monitoring and OAM triggered alarms of the LSP are disabled (e.g., no monitoring and OAM triggered alarms of the LSP are disabled (e.g., no
continuity check messages are sent). continuity check messages are sent, no AIS is generated).
3.5. OAM configuration errors 3.5. 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 is defined.
If a node does not support the establishment of OAM entities via If a node does not support the establishment of OAM MEP or MIP
RSVP-TE signalling it must use the error value (IANA to assign): "OAM entities it must use the error value (IANA to assign): "MEP
establishment not supported" in the PathErr message. 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 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 use the error value (IANA to assign): "Unsupported OAM Type" in the
PathErr message. 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 an the error value: "OAM Problem/
Configuration Error" must 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 (IANA to assign): "Unsupported OAM Function" in the error value (IANA to assign): "Unsupported OAM Function" in the
PathErr message. PathErr message.
4. IANA Considerations 4. IANA Considerations
One bit (Monitoring Disabled (M)) needs to be allocated in the One bit (Monitoring Disabled (M)) needs to be allocated in the
ADMIN_STATUS Object. ADMIN_STATUS Object.
One bit ("OAM entities desired") needs to be allocated in the LSP One bit ("OAM entities desired") needs to be allocated in the LSP
Attributes Flag Registry. Attributes Flag Registry.
This document specifies one new TLVs to be carried in the This document specifies one new TLVs to be carried in the
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages:
OAM Configuration TLV. OAM Configuration TLV.
One new Error Code: "OAM Problem" and three new values: "OAM One new Error Code: "OAM Problem" and three new values: "MEP
establishment not supported", "Unsupported OAM Type" and "Unsupported establishment not supported", "MIP establishment not supported",
OAM Function" needs to be assigned. "Unsupported OAM Type" and "Unsupported OAM Function" needs to be
assigned.
5. Security Considerations 5. Security Considerations
The signalling of OAM related parameters and the automatic The signaling of OAM related parameters and the automatic
establishment of OAM entities introduces additional security establishment of OAM entities introduces additional security
considerations to those discussed in [RFC3473]. In particular, a considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element. number of LSPs, targeting a single network element.
Security aspects will be covered in more detailed in subsequent Security aspects will be covered in more detailed in subsequent
versions of this document. versions of this document.
6. Acknowledgements 6. 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.
Appendix A. Discussion on alternatives Appendix A. Discussion on alternatives
This appendix summarises the discussions after IETF-71 about the way This appendix summarizes the discussions after IETF-71 about the way
OAM configuration information should be carried in RSVP-TE. OAM configuration information should be carried in RSVP-TE.
The first question is how the requirement for OAM establishment is The first question is how the requirement for OAM establishment is
signalled and how the operation of OAM is controlled. There is a signaled and how the operation of OAM is controlled. There is a
straightforward way to achieve these using existing objects and straightforward way to achieve these using existing objects and
fields: fields:
o Use one or more OAM flags in the LSP Attributes Flag TLV within o Use one or more OAM flags in the LSP Attributes Flag TLV within
the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that
OAM entities for the LSP need to be established. If for any 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 reason this cannot be done a notification is sent or an error is
raised. raised.
o Once the LSP with the desired OAM entities is established OAM o Once the LSP with the desired OAM entities is established OAM
operation may be controlled using one or more flags in the operation may be controlled using one or more flags in the
ADMIN_STATUS object. For instance, the generation of connectivity ADMIN_STATUS object. For instance, the generation of connectivity
monitoring messages can be disabled/enabled by setting/clearing a monitoring messages can be disabled/enabled by setting/clearing a
flag in the ADMIN_STATUS object. flag in the ADMIN_STATUS object.
However, there are two alternatives when it comes to signalling the However, there are two alternatives when it comes to signaling the
actual configuration parameters of OAM entities. actual configuration parameters of OAM entities.
o Extension of the LSP_ATTRIBUTES object with new TLVs. o Extension of the LSP_ATTRIBUTES object with new TLVs.
o Definition of a new RSVP-TE object to carry OAM information. 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 In the first case, a new OAM configuration TLV is defined in the
LSP_ATTRIBUTES object. This TLV would provide the detailed LSP_ATTRIBUTES object. This TLV would provide the detailed
information needed for LSPs with a set OAM flag in the LSP Attributes 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 Flag TLV. The rationale for this approach is that in addition to
skipping to change at page 17, line 10 skipping to change at page 19, line 10
configuration information. The rationale for this is that the configuration information. The rationale for this is that the
complex information that may be required for OAM configuration would complex information that may be required for OAM configuration would
unnecessarily add complexity to LSP_ATTRIBUTES/ unnecessarily add complexity to LSP_ATTRIBUTES/
LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms.
Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to
carry configuration information of data plane entities, thus a new carry configuration information of data plane entities, thus a new
object like an "OAM_SPEC" may be a better fit to existing protocol object like an "OAM_SPEC" may be a better fit to existing protocol
elements. elements.
The authors of this document favour the first alternative (adding new The authors of this document favor the first alternative (adding new
TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which
alternative to select for standardisation is up for the working group alternative to select for standardization is up for the working group
to decide. In any case, the information to be carried would be the to decide. In any case, the information to be carried would be the
same or very similar for both alternatives. same or very similar for both alternatives.
7. References 7. References
[GELS-Framework] [GELS-Framework]
"GMPLS Ethernet Label Switching Architecture and "GMPLS Ethernet Label Switching Architecture and
Framework", Internet Draft, work in progress. Framework", Internet Draft, work in progress.
[GMPLS-OAM] [GMPLS-OAM]
skipping to change at page 19, line 23 skipping to change at page 21, line 23
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
Don Fedyk Don Fedyk
Nortel Nortel
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
USA USA
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
He Jia Jia He
Huawei Huawei
Email: hejia@huawei.com Email: hejia@huawei.com
 End of changes. 46 change blocks. 
144 lines changed or deleted 215 lines changed or added

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