draft-ietf-ccamp-oam-configuration-fwk-03.txt   draft-ietf-ccamp-oam-configuration-fwk-04.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: August 1, 2010 Alcatel-Lucent Expires: April 28, 2011 Alcatel-Lucent
J. He J. He
Huawei Huawei
January 28, 2010 October 25, 2010
OAM Configuration Framework and Requirements for GMPLS RSVP-TE GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-03 draft-ietf-ccamp-oam-configuration-fwk-04
Abstract Abstract
OAM is an integral part of transport connections, hence it is OAM is an integral part of transport connections, hence it is
required that OAM functions are activated/deactivated in sync with required that OAM functions are activated/deactivated in sync with
connection commissioning/decommissioning; avoiding spurious alarms connection commissioning/decommissioning; avoiding spurious alarms
and ensuring consistent operation. In certain technologies OAM and ensuring consistent operation. In certain technologies OAM
entities are inherently established once the connection is set up, entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and while other technologies require extra configuration to establish and
configure OAM entities. This document specifies extensions to configure OAM entities. This document specifies extensions to
skipping to change at page 2, line 13 skipping to change at page 2, line 13
entities along with LSP signaling. entities along with LSP signaling.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in document are to be interpreted as described in
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 28, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. GMPLS based OAM Configuration . . . . . . . . . . . . . . . . 8 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 8
3.1. Establishment of OAM Entities and Functions . . . . . . . 8 3.1. Establishment of OAM Entities and Functions . . . . . . . 8
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 13
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14
4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14
4.3. Administrative Status Information . . . . . . . . . . . . 14 4.3. Administrative Status Information . . . . . . . . . . . . 15
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4.5. Considerations on Point-to-Multipoint OAM Configuration . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
Appendix A. Discussion on Alternatives . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
GMPLS is designed as an out-of-band control plane supporting dynamic GMPLS is designed as an out-of-band control plane supporting dynamic
connection provisioning for any suitable data plane technology; connection provisioning for any suitable data plane technology;
including spatial switching (e.g., incoming port or fiber to outgoing including spatial switching (e.g., incoming port or fiber to outgoing
port or fiber), wavelength-division multiplexing (e.g., DWDM), time- port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet
Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS
Transport Profile (MPLS-TP). In most of these technologies there are Transport Profile (MPLS-TP). In most of these technologies there are
skipping to change at page 6, line 29 skipping to change at page 6, line 29
o In particular some LSPs may require automated ingress-LSR to o In particular some LSPs may require automated ingress-LSR to
egress-LSR testing functionality, while others may not. egress-LSR testing functionality, while others may not.
o Mechanisms are required to coordinate network responses to o Mechanisms are required to coordinate network responses to
defects. Such mechanisms may include alarm suppression, defects. Such mechanisms may include alarm suppression,
translating defect signals at technology boundaries, and translating defect signals at technology boundaries, and
synchronizing defect detection times by setting appropriately synchronizing defect detection times by setting appropriately
bounded detection timeframes. bounded detection 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 [RFC5921]. This profile specifies the specific MPLS characteristics
characteristics and extensions required to meet transport and extensions required to meet transport requirements, including
requirements, including providing additional OAM, survivability and providing additional OAM, survivability and other maintenance
other maintenance functions not currently supported by MPLS. functions not currently supported by MPLS. Specific OAM requirements
Specific OAM requirements for MPLS-TP are specified in for MPLS-TP are specified in [RFC5654] [RFC5860]. MPLS-TP poses
[MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane requirements on the control plane to configure and control OAM
to configure and control OAM entities: entities:
o The use of OAM functions SHOULD be optional for the operator. A o OAM functions MUST operate and be configurable even in the absence
network operator SHOULD be able to choose which OAM functions to of a control plane. Conversely, it SHOULD be possible to
use and which Maintenance Entity to apply them to. configure as well as enable/disable the capability to operate OAM
functions as part of connectivity management, and it SHOULD also
be possible to configure as well as enable/disable the capability
to operate OAM functions after connectivity has been established.
o The MPLS-TP control plane MUST support the configuration and o The MPLS-TP control plane MUST support the configuration and
modification of OAM maintenance points as well as the activation/ modification of OAM maintenance points as well as the activation/
deactivation of OAM when the transport path is established or deactivation of OAM when the transport path or transport service
modified. OAM functions SHOULD be configurable as part of is established or modified.
connectivity (LSP or PW) management.
Ethernet Connectivity Fault Management (CFM) defines an adjunct
connectivity monitoring OAM flow to check the liveliness of Ethernet
networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will
support explicitly-routed Ethernet connections. CFM can be used to
track the liveliness of PBB-TE connections and detect data plane
failures. In IETF the GMPLS controlled Ethernet Label Switching
(GELS) (see [RFC5828] and [GMPLS-PBBTE]) work is extending the GMPLS
control plane to support the establishment of point-to-point PBB-TE
data plane connections. Without control plane support separate
management commands would be needed to configure and start CFM.
GMPLS based OAM configuration and control 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
solutions. There are three typical data plane technologies used for solutions. 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 [RFC5921] and
and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator
operator MUST be able to configure and control the following OAM 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 signaled LSP and provide specific information for entities for the signaled LSP and provide specific information for
the setup if this is required by the technology. the setup if this is required by the technology.
o Control of alarms is important to avoid false alarm indications o Control of alarms is important to avoid false alarm indications
and reporting to the management system. It MUST be possible to and reporting to the management system. It MUST be possible to
enable/disable alarms generated by OAM functions. In some cases enable/disable alarms generated by OAM functions. In some cases
selective alarm control may be desirable when, for instance, the selective alarm control may be desirable when, for instance, the
operator is only concerned about critical alarms thus the non- operator is only concerned about critical alarms thus the non-
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Agreements (SLAs) it may be required that measurement points agree Agreements (SLAs) it may be required that measurement points agree
on a common probing rate to avoid measurement problems. 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 based OAM Configuration 3. RSVP-TE based OAM Configuration
In general, two types of Maintenance Poits (MPs) can be In general, two types of Maintenance Points (MPs) can be
distinguished: Maintenance End Points (MEPs) and Maintenance distinguished: Maintenance End Points (MEPs) and Maintenance
Intermediate Points (MIPs). MEPs reside at the ends of an LSP and Intermediate Points (MIPs). MEPs reside at the ends of an LSP and
are capable of initiating and terminating OAM messages for Fault are capable of initiating and terminating OAM messages for Fault
Management (FM) and Performance Monitoring (PM). MIPs on the other Management (FM) and Performance Monitoring (PM). MIPs on the other
hand are located at transit nodes of an LSP and are capable of hand are located at transit nodes of an LSP and are capable of
reacting to some OAM messages but otherwise do not initiate messages. reacting to some OAM messages but otherwise do not initiate messages.
Maintenance Entity (ME) refers to an association of MEPs and MIPs Maintenance Entity (ME) refers to an association of MEPs and MIPs
that are provisioned to monitor an LSP. The ME association is that are provisioned to monitor an LSP. The ME association is
achieved by configuring MPs to belong to the same ME. achieved by configuring MPs to belong to the same ME.
skipping to change at page 9, line 28 skipping to change at page 9, line 28
When the Path message arrives at the receiver, the remote end MUST When the Path message arrives at the receiver, the remote end MUST
establish and configure OAM entities according to the OAM information establish and configure OAM entities according to the OAM information
provided in Path message. If this is not possible a PathErr SHOULD provided in Path message. If this is not possible a PathErr SHOULD
be sent and neither the OAM entities nor the LSP SHOULD be be sent and neither the OAM entities nor the LSP SHOULD be
established. If OAM entities are established successfully, the OAM established. If OAM entities are established successfully, the OAM
sink function MUST be prepared to receive OAM messages but MUST not sink function MUST be prepared to receive OAM messages but MUST not
generate any OAM alarms (e.g., due to missing or unidentified OAM generate any OAM alarms (e.g., due to missing or unidentified OAM
messages). In the case of bidirectional connections, an OAM source messages). In the case of bidirectional connections, an OAM source
function MUST be setup and, according to the requested configuration, function MUST be setup and, according to the requested configuration,
it MUST start sending OAM messages. Then a Resv message is sent the OAM source function MUST start sending OAM messages. Then a Resv
back, including the OAM Configuration TLV that corresponds to the message is sent back, including the OAM Configuration TLV that
actually established and configured OAM entities and functions. corresponds to the actually established and configured OAM entities
Depending on the OAM technology, some elements of the OAM and functions. Depending on the OAM technology, some elements of the
Configuration TLV MAY be updated/changed; i.e., if the remote end is OAM Configuration TLV MAY be updated/changed; i.e., if the remote end
not supporting a certain OAM configuration it may suggest an is not supporting a certain OAM configuration it may suggest an
alternative setting, which may or may not be accepted by the alternative setting, which may or may not be accepted by the
initiator of the Path message. If it is accepted, the initiator will initiator of the Path message. If it is accepted, the initiator will
reconfigure its OAM functions according to the information received reconfigure its OAM functions according to the information received
in the Resv message. If the alternate setting is not acceptable a in the Resv message. If the alternate setting is not acceptable a
ResvErr may be sent tearing down the LSP. Details of this operation ResvErr may be sent tearing down the LSP. Details of this operation
are technology specific and should be described in accompanying are technology specific and should be described in accompanying
technology specific documents. technology specific documents.
When the initiating side receives the Resv message it completes any When the initiating side receives the Resv message it completes any
pending OAM configuration and enables the OAM source function to send pending OAM configuration and enables the OAM source function to send
OAM messages. OAM messages.
After this round, OAM entities are established and configured for the After this round, OAM entities are established and configured for the
LSP and OAM messages MAY already be exchanged. OAM alarms can now be LSP and OAM messages are already exchanged. OAM alarms can now be
enabled. The initiator, while still keeping OAM alarms disabled enabled. The initiator, while still keeping OAM alarms disabled
sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set. sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set.
The receiving node enables the OAM alarms after processing the Path The receiving node enables the OAM alarms after processing the Path
message. The initiator enables OAM alarms after it receives the Resv message. The initiator enables OAM alarms after it receives the Resv
message. Data plane OAM is now fully functional. message. Data plane OAM is now fully functional.
3.2. Adjustment of OAM Parameters 3.2. Adjustment of OAM Parameters
There may be a need to change the parameters of an already There may be a need to change the parameters of an already
established and configured OAM function during the lifetime of the established and configured OAM function during the lifetime of the
skipping to change at page 12, line 36 skipping to change at page 12, line 36
and processed by each LSR. One TLV is defined in [RFC5420]: the and processed by each LSR. One TLV is defined in [RFC5420]: the
Attributes Flags TLV. Attributes Flags TLV.
One bit (10 IANA to assign): "OAM MEP entities desired" is allocated One bit (10 IANA to assign): "OAM MEP entities desired" is allocated
in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" in the LSP Attributes Flags TLV. If the "OAM MEP entities desired"
bit is set it is indicating that the establishment of OAM MEP bit is set it is indicating that the establishment of OAM MEP
entities are required at the endpoints of the signaled LSP. If the entities are required at the endpoints of the signaled LSP. If the
establishment of MEPs is not supported an error must be generated: establishment of MEPs is not supported an error must be generated:
"OAM Problem/MEP establishment not supported". "OAM Problem/MEP establishment not supported".
If the "OAM MEP entities desired" bit is set and additional If the "OAM MEP entities desired" bit is set but additional
parameters are needed to be configured the OAM entities an OAM parameters need also to be configured, an OAM Configuration TLV MAY
Configuration TLV may be included in the LSP_ATTRIBUTES object. be included in the LSP_ATTRIBUTES Object.
One bit (11 IANA to assign): "OAM MIP entities desired" is allocated One bit (11 IANA to assign): "OAM MIP entities desired" is allocated
in the LSP Attributes Flags TLV. This bit can only be set if the in the LSP Attributes Flags TLV. This bit can only be set if the
"OAM MEP entities desired" bit is set. If the "OAM MIP entities "OAM MEP entities desired" bit is set. If the "OAM MIP entities
desired" bit is set in the LSP_ATTRIBUTES Flags TLV, it is indicating desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the
that the establishment of OAM MIP entities is required at every LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
transit node of the signalled LSP. If the establishment of a MIP is establishment of OAM MIP entities is required at every transit node
not supported an error must be generated: "OAM Problem/MIP of the signalled LSP. If the establishment of a MIP is not supported
establishment not supported". an error must be generated: "OAM Problem/MIP establishment not
supported".
4.2. OAM Configuration TLV 4.2. OAM Configuration TLV
This TLV provides information about which OAM technology/method This TLV provides information about which OAM technology/method
should be used and carries sub-TLVs for any additional OAM should be used and carries sub-TLVs for any additional OAM
configuration information. The OAM Configuration TLV may be carried configuration information. The OAM Configuration TLV may be carried
in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
Resv messages. Resv 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 (3) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved | | OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub-TLVs ~ ~ sub-TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (2) (IANA to Type: indicates a new type: the OAM Configuration TLV (3) (IANA to
assign). assign).
OAM Type: specifies the technology specific OAM method. If the OAM Type: specifies the technology specific 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".
OAM Type Description OAM Type Description
------------ -------------------- ------------ --------------------
0-255 Reserved 0-255 Reserved
This document defines no types. IANA is requests to maintain the This document defines no types. IANA is requested to maintain the
values in a new "RSVP-TE OAM Configuration Registry". values in a new "RSVP-TE OAM Configuration Registry".
The receiving node based on the OAM Type will check if a The receiving node based on the OAM Type will check if a
corresponding technology specific OAM configuration sub-TLV is corresponding technology specific OAM configuration sub-TLV is
included. If the included technology specific OAM configuration sub- included. If the included technology specific OAM configuration sub-
TLV is different than what is specified in the OAM Type an error must TLV is different than what is specified in the OAM Type an error must
be generated: "OAM Problem/OAM Type Mismatch". be generated: "OAM Problem/OAM Type Mismatch".
Note that there is a hierarchical dependency in between the OAM Note that there is a hierarchical dependency in between the OAM
configuration elements. First, the "OAM MEP (and MIP) entities configuration elements. First, the "OAM MEP (and MIP) entities
desired" flag needs to be set. When it is set an "OAM Configuration desired" flag needs to be set. Only when that is set MAY an "OAM
TLV" may be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Configuration TLV" be included in the LSP_ATTRIBUTES or
Object. When this TLV is present, based on the "OAM Type" field, it LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on
may carry a technology specific OAM configuration sub-TLV. If this the "OAM Type" field, it MAY carry a technology specific OAM
hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP
but an OAM Configuration TLV is present) an error must be generated: entities desired" flag is not set but an OAM Configuration TLV is
"OAM Problem/Configuration Error". present) an error MUST be generated: "OAM Problem/Configuration
Error".
4.2.1. OAM Function Flags Sub-TLV 4.2.1. OAM Function Flags Sub-TLV
As the first sub-TLV one "OAM Function Flags sub-TLV" MUST be always As the first sub-TLV one "OAM Function Flags sub-TLV" MUST be always
included in the "OAM Configuration TLV". "OAM Function Flags" included in the "OAM Configuration TLV". "OAM Function Flags"
specifies which pro-active OAM functions (e.g., connectivity specifies which pro-active OAM functions (e.g., connectivity
monitoring, loss and delay measurement) and which fault management monitoring, loss and delay measurement) and which fault management
signals MUST be established and configured. If the selected OAM signals MUST be established and configured. If the selected OAM
Function(s) is(are) not supported, an error must be generated: "OAM Function(s) is(are) not supported, an error MUST be generated: "OAM
Problem/Unsupported OAM Function". Problem/Unsupported OAM Function".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) (IANA) | Length | | Type (1) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ OAM Function Flags ~ ~ OAM Function Flags ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines the following flags. OAM Function Flags is bitmap with extensible length based on the
Lenght field of the TLV. Bits are numbered from left to right as
shown in the figure. This document defines the following flags.
OAM Function Flag Description OAM Function Flag bit# Description
--------------------- --------------------------- --------------------- ---------------------------
0 Continuity Check (CC) 0 Continuity Check (CC)
1 Connectivity Verification (CV) 1 Connectivity Verification (CV)
2 Performance Monitoring/Loss (PM/Loss) 2 Performance Monitoring/Loss (PM/Loss)
3 Performance Monitoring/Delay (PM/Delay) 3 Performance Monitoring/Delay (PM/Delay)
4.2.2. Technology Specific sub-TLVs 4.2.2. Technology Specific sub-TLVs
One technology specific sub-TLV SHOULD be defined for each "OAM One technology specific sub-TLV SHOULD be defined for each "OAM
Type". This sub-TLV MUST contain any further OAM configuration Type". This sub-TLV MUST contain any further OAM configuration
information for that specific "OAM Type". The technology specific information for that specific "OAM Type". The technology specific
sub-TLV may be carried within the OAM Configuration TLV. sub-TLV, when used, MUST be carried within the OAM Configuration TLV.
4.3. Administrative Status Information 4.3. Administrative Status Information
Administrative Status Information is carried in the ADMIN_STATUS Administrative Status Information is carried in the ADMIN_STATUS
Object. The Administrative Status Information is described in Object. The Administrative Status Information is described in
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
[RFC3473]. [RFC3473].
Two bits are allocated for the administrative control of OAM Two bits are allocated for the administrative control of OAM
monitoring. In addition to the Reflect (R) bit, 7 bits are currently monitoring. In addition to the Reflect (R) bit, 7 bits are currently
skipping to change at page 16, line 5 skipping to change at page 16, line 5
than what was specified in the OAM Type an error must be generated than what was specified in the OAM Type an error must be generated
with error value: "OAM Type Mismatch" in the PathErr message. with error value: "OAM Type Mismatch" in the PathErr message.
There is a hierarchy in between the OAM configuration elements. If There is a hierarchy in between the OAM configuration elements. If
this hierarchy is broken the error value: "Configuration Error" must this hierarchy is broken the error value: "Configuration Error" must
be used in the PathErr message. be used in the PathErr message.
If a node does not support a specific OAM Function it must use the If a node does not support a specific OAM Function it must use the
error value: "Unsupported OAM Function" in the PathErr message. error value: "Unsupported OAM Function" in the PathErr message.
4.5. Considerations on Point-to-Multipoint OAM Configuration
RSVP-TE extensions for the establishment of point-to-multipoint
(P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of
multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set
up between the ingress and egress LSRs and are appropriately combined
by the branch LSRs using RSVP semantics to result in a P2MP TE LSP.
One Path message may signal one or multiple S2L sub-LSPs for a single
P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be
signaled using one Path message or split across multiple Path
messages.
P2MP OAM mechanisms are very specific to the data plane technology,
hence in this document we only highlight basic operations for P2MP
OAM configuration. We consider only the configuration of the root to
leaves OAM flows of P2MP LSPs and as such aspects of any return path
are outside the scope of our discussions. We also limit our
consideration to cases where all leaves must successfully establish
OAM entities in order a P2MP OAM is successfully established. In any
case, the discussion set forth below provides only guidelines for
P2MP OAM configuration, details SHOULD be specified in technology
specific documents.
The root node may select if it uses a single Path message or multiple
Path messages to setup the whole P2MP tree. In the case when
multiple Path messages are used the root node is responsible also to
keep the OAM Configuration information consistent in each of the sent
Path messages, i.e., the same information MUST be included in all
Path messages used to construct the multicast tree. Each branching
node will propagate the Path message downstream on each of the
branches, when constructing a Path message the OAM Configuration
information MUST be copied unchanged from the received Path message,
including the related ADMIN_STATUS bits, LSP Attribute Flags and the
OAM Configuration TLV. The latter two also imply that the
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for
the upstream Path message to the subsequent downstream Path messages.
Leaves MUST create and configure OAM sink functions according to the
parameters received in the Path message, for P2MP OAM configuration
there is no possibility for parameter negotiation on a per leaf
basis. This is due to the fact that the only OAM source function,
residing in the root of the tree, can only operate with a single
configuration which must be obeyed by all leaves. If a leaf cannot
accept the OAM parameters it MUST use the RRO Attributes sub-object
[RFC5420] to notify the root of the problem. In particular, if the
OAM configuration was successful the leaf would set the "OAM MEP
entities desired" flag in the RRO Attributes sub-object in the Resv
message, while, if due to any reason, OAM entities could not be
established the Resv message should be sent with the "OAM MEP
entities desired" bit cleared in the RRO Attributes sub-object.
Branching nodes should collect and merge the received RROs according
to the procedures described in [RFC4875]. This way, the root when
receiving the Resv message (or messages if multiple Path messages
were used to setup the tree) will have a clear information on which
of the leaves could the OAM sink functions be established. If all
leaves established OAM entities successfully, the root can enable the
OAM message flow. On the other hand, if at some leaves the
establishment was unsuccessful additional actions will be needed
before the OAM message flow can be enabled. Such action could be to
setup two independent P2MP LSPs. One with OAM Configuration
information towards leaves which successfully setup OAM. This can be
done by prunning the leaves which failed to setup OAM of the
previously signalled P2MP LSP. The other P2MP LSP could be
constructed for leaves without OAM entities. What exact procedures
are needed are technology specific and should be described in
technology specific documents.
5. IANA Considerations 5. IANA Considerations
Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs
to be allocated in the ADMIN_STATUS Object. to be allocated in the ADMIN_STATUS Object.
Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")
needs to be allocated in the LSP Attributes Flags Registry. needs to be allocated in the LSP Attributes Flags Registry.
This document specifies one new TLV to be carried in the This document specifies one new TLV to be carried in the
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv
messages: OAM Configuration TLV. messages: OAM Configuration TLV.
One new Error Code: "OAM Problem" and a set of new values: "MEP One new Error Code: "OAM Problem" and a set of new values: "MEP
establishment not supported", "MIP establishment not supported", establishment not supported", "MIP establishment not supported",
"Unsupported OAM Type", "Configuration Error" and "Unsupported OAM "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM
Function" needs to be assigned. Function" needs to be assigned.
The IANA is requested to open a new registry: "RSVP-TE OAM IANA is requested to open a new registry: "RSVP-TE OAM Configuration
Configuration Registry" that maintains the "OAM Type" code points and Registry" that maintains the "OAM Type" code points, an associated
the allocations of "OAM Function Flags" within the OAM Configuration sub-TLV space, and the allocations of "OAM Function Flags" within the
TLV. OAM Configuration TLV.
6. Security Considerations 6. Security Considerations
The signaling of OAM related parameters and the automatic The signaling of OAM related parameters and the automatic
establishment of OAM entities introduces additional security establishment of OAM entities based on RSVP-TE messages adds a new
considerations to those discussed in [RFC3473]. In particular, a aspect to the security considerations discussed in [RFC3473]. In
network element could be overloaded, if an attacker would request particular, a network element could be overloaded, if a remote
liveliness monitoring, with frequent periodic messages, for a high attacker could request liveliness monitoring, with frequent periodic
number of LSPs, targeting a single network element. messages, for a high number of LSPs, targeting a single network
element. Such an attack can efficiently be prevented when mechanisms
for message integrity and node authentication are deployed. Since
the OAM configuratiuon extensions rely on the hop-by-hop exchange of
exiting RSVP-TE messages, procedures specified for RSVP message
security in [RFC2747] can be used to mitigate possible attacks.
Security aspects will be covered in more detailed in subsequent For a more comprehensive discussion on GMPLS security please see the
versions of this document. Security Framework for MPLS and GMPLS Networks [RFC5920].
Cryptography can be used to protect against many attacks described in
[RFC5920].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel, The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments. comments.
Appendix A. Discussion on Alternatives 8. References
This appendix summarizes the discussions after IETF-71 about the way
OAM configuration information should be carried in RSVP-TE.
The first question is how the requirement for OAM establishment is
signaled and how the operation of OAM is controlled. There is a
straightforward way to achieve these using existing objects and
fields:
o Use one or more OAM flags in the LSP Attributes Flag TLV within
the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that
OAM entities for the LSP need to be established. If for any
reason this cannot be done a notification is sent or an error is
raised.
o Once the LSP with the desired OAM entities is established OAM
operation may be controlled using one or more flags in the
ADMIN_STATUS object. For instance, the generation of connectivity
monitoring messages can be disabled/enabled by setting/clearing a
flag in the ADMIN_STATUS object.
However, there are two alternatives when it comes to signaling the
actual configuration parameters of OAM entities.
o Extension of the LSP_ATTRIBUTES object with new TLVs.
o Definition of a new RSVP-TE object to carry OAM information.
In the first case, a new OAM configuration TLV is defined in the
LSP_ATTRIBUTES object. This TLV would provide the detailed
information needed for LSPs with a set OAM flag in the LSP Attributes
Flag TLV. The rationale for this approach is that in addition to
setting flags the LSP_ATTRIBUTES object may carry complementary
information for all or some of the flags set. Furthermore, as top
level RSVP-TE objects may become scarce resources, it seems to be
beneficial not to allocate new RSVP-TE objects for the purpose of
providing detailed information for new LSP Attribute Flags.
Currently there is only one TLV, the Attributes Flag TLV, defined in
the LSP_ATTRIBUTES object. Defining a new TLV associated with one of
the flags would make a precedence and possibly be a guideline for
similar future extensions.
The other alternative would be to allocate a dedicated object for OAM 8.1. Normative References
configuration information. The rationale for this is that the
complex information that may be required for OAM configuration would
unnecessarily add complexity to LSP_ATTRIBUTES/
LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms.
Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
carry configuration information of data plane entities, thus a new Signaling Functional Description", RFC 3471, January 2003.
object like an "OAM_SPEC" may be a better fit to existing protocol
elements.
The authors of this document favor the first alternative (adding new [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which Signaling Resource ReserVation Protocol-Traffic
alternative to select for standardization is up for the working group Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
to decide. In any case, the information to be carried would be the
same or very similar for both alternatives.
8. References [RFC5420] "Encoding of Attributes for Multiprotocol Label Switching
(MPLS) Label Switched Path (LSP) Establishment Using
Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 5420, February 2009.
[GELS-Framework] 8.2. Informative References
"GMPLS Ethernet Label Switching Architecture and
Framework", Internet Draft, work in progress.
[GMPLS-OAM] [GMPLS-PBBTE]
"OAM Requirements for Generalized Multi-Protocol Label "Generalized Multiprotocol Label Switching (GMPLS) control
Switching (GMPLS) Networks", Internet Draft, work in of Ethernet Provider Backbone Traffic Engineering
progress. (PBB-TE)", Internet Draft, work in progress.
[IEEE-CFM] [IEEE-CFM]
"IEEE 802.1ag, Draft Standard for Connectivity Fault "IEEE 802.1ag, Draft Standard for Connectivity Fault
Management", work in progress. Management", work in progress.
[IEEE-PBBTE] [IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone "IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress. Bridging Traffic Engineering", work in progress.
[MPLS-TP-FWK] [RFC2747] "RSVP Cryptographic Authentication", RFC 2747,
"A Framework for MPLS in Transport Networks", Internet January 2000.
Draft, work in progress.
[MPLS-TP-OAM-REQ]
"Requirements for OAM in MPLS Transport Networks",
Internet Draft, work in progress.
[RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based
Recovery", RFC 3469, February 2003. Recovery", RFC 3469, February 2003.
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4377] "Operations and Management (OAM) Requirements for Multi- [RFC4377] "Operations and Management (OAM) Requirements for Multi-
Protocol Label Switched (MPLS) Networks", RFC 4377, Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006. February 2006.
[RFC5420] "Encoding of Attributes for Multiprotocol Label Switching [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane
(MPLS) Label Switched Path (LSP) Establishment Using Failures", RFC 4379, February 2006.
Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 5420, February 2009. [RFC4875] "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5654] "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009.
[RFC5828] "GMPLS Ethernet Label Switching Architecture and
Framework", RFC 5828, March 2010.
[RFC5860] "Requirements for OAM in MPLS Transport Networks",
RFC 5860, May 2010.
[RFC5920] "Security Framework for MPLS and GMPLS Networks",
RFC 5920, July 2010.
[RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921,
July 2010.
Authors' Addresses Authors' Addresses
Attila Takacs Attila Takacs
Ericsson Ericsson
Laborc u. 1. Laborc u. 1.
Budapest, 1037 Budapest, 1037
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
 End of changes. 44 change blocks. 
165 lines changed or deleted 208 lines changed or added

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