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/ |