draft-ietf-ccamp-oam-configuration-fwk-09.txt   draft-ietf-ccamp-oam-configuration-fwk-10.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: July 26, 2013 Alcatel-Lucent Expires: December 17, 2013 Alcatel-Lucent
J. He J. He
Huawei Huawei
January 22, 2013 June 15, 2013
GMPLS RSVP-TE extensions for OAM Configuration GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-09 draft-ietf-ccamp-oam-configuration-fwk-10
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 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2013. This Internet-Draft will expire on December 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6
3.1. Establishment of OAM Entities and Functions . . . . . . . 7 3.1. Establishment of OAM Entities and Functions . . . . . . . 7
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12
4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 13 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . . 13
4.3. Administrative Status Information . . . . . . . . . . . . 13 4.3. Administrative Status Information . . . . . . . . . . . . 13
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 13 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14
4.5. Considerations on Point-to-Multipoint OAM Configuration . 14 4.5. Considerations on Point-to-Multipoint OAM Configuration . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
GMPLS is designed as an out-of-band control plane supporting dynamic GMPLS is designed as an out-of-band control plane supporting dynamic
connection provisioning for any suitable data plane technology; connection provisioning for any suitable data plane technology;
including spatial switching (e.g., incoming port or fiber to outgoing including spatial switching (e.g., incoming port or fiber to outgoing
port or fiber), wavelength-division multiplexing (e.g., DWDM), time- port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider
Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most
of these technologies, there are Operations, Administration and of these technologies, there are Operations, Administration and
skipping to change at page 3, line 45 skipping to change at page 3, line 45
plane connection establishment mechanisms are synchronized with OAM plane connection establishment mechanisms are synchronized with OAM
establishment and activation. In particular, if the GMPLS control establishment and activation. In particular, if the GMPLS control
plane is employed, it is desirable to bind OAM setup and plane is employed, it is desirable to bind OAM setup and
configuration to connection establishment signaling to avoid two configuration to connection establishment signaling to avoid two
separate management/configuration steps (connection setup followed by separate management/configuration steps (connection setup followed by
OAM configuration) which increases delay, processing, and more OAM configuration) which increases delay, processing, and more
importantly may be prone to misconfiguration errors. Once OAM importantly may be prone to misconfiguration errors. Once OAM
entities are setup and configured, pro-active as well as on-demand entities are setup and configured, pro-active as well as on-demand
OAM functions can be activated via the management plane. On the OAM functions can be activated via the management plane. On the
other hand, it should be possible to activate/deactivate pro-active other hand, it should be possible to activate/deactivate pro-active
OAM functions via the GMPLS control plane as well. OAM functions via the GMPLS control plane as well. In some
situations it may be possible to use the GMPLS control plane to
control on-demand OAM functions too.
This document describes requirements for OAM configuration and This document describes requirements for OAM configuration and
control via RSVP-TE. Extensions to the RSVP-TE protocol are control via RSVP-TE. Extensions to the RSVP-TE protocol are
specified providing a framework to configure and control OAM entities specified providing a framework to configure and control OAM entities
along with the capability to carry technology specific information. along with the capability to carry technology specific information.
Extensions can be grouped into: generic elements that are applicable Extensions can be grouped into: generic elements that are applicable
to any OAM solution; and technology specific elements that provide to any OAM solution; and technology specific elements that provide
additional configuration parameters, which may only be needed for a additional configuration parameters, which may only be needed for a
specific OAM technology. This document specifies the technology specific OAM technology. This document specifies the technology
agnostic elements and specifies the way additional technology agnostic elements and specifies the way additional technology
specific OAM parameters are provided. specific OAM parameters are provided.
This document addresses end-to-end OAM configuration, that is, the This document addresses end-to-end OAM configuration, that is, the
setup of OAM entities bound to an end-to-end LSP, and configuration setup of OAM entities bound to an end-to-end LSP, and configuration
and control of OAM functions running end-to-end in the LSP. and control of OAM functions running end-to-end in the LSP.
skipping to change at page 7, line 7 skipping to change at page 7, line 10
In addition to MP and ME identification parameters, pro-active OAM In addition to MP and ME identification parameters, pro-active OAM
functions (e.g., Continuity Check (CC) and Performance Monitoring functions (e.g., Continuity Check (CC) and Performance Monitoring
(PM)) may have additional parameters that require configuration as (PM)) may have additional parameters that require configuration as
well. In particular, the frequency of periodic CC packets and the well. In particular, the frequency of periodic CC packets and the
measurement interval for loss and delay measurements may need to be measurement interval for loss and delay measurements may need to be
configured. configured.
The above parameters may be either derived from LSP provisioning The above parameters may be either derived from LSP provisioning
information, or alternatively, pre-configured default values can be information, or alternatively, pre-configured default values can be
used. In the simplest case, the control plane provides information used. In the simplest case, the control plane MAY provide
on whether or not OAM entities need to be setup for the signaled LSP. information on whether or not OAM entities need to be setup for the
If OAM entities are created, control plane signaling must also signaled LSP. If OAM entities are created, control plane signaling
provide a means to activate/deactivate OAM message flows and MUST also provide a means to activate/deactivate OAM message flows
associated alarms. and associated alarms.
OAM identifiers, as well as the configuration of OAM functions, are OAM identifiers, as well as the configuration of OAM functions, are
technology specific (i.e., vary depending on the data plane technology specific (i.e., vary depending on the data plane
technology and the chosen OAM solution). In addition, for any given technology and the chosen OAM solution). In addition, for any given
data plane technology, a set of OAM solutions may be applicable. data plane technology, a set of OAM solutions may be applicable.
Therefore, the OAM configuration framework allows selecting a Therefore, the OAM configuration framework allows selecting a
specific OAM solution to be used for the signaled LSP and provides specific OAM solution to be used for the signaled LSP and provides
means to carry detailed OAM configuration information in technology means to carry detailed OAM configuration information in technology
specific TLVs. specific TLVs.
skipping to change at page 7, line 35 skipping to change at page 7, line 38
enabled in the appropriate order. When using the GMPLS control enabled in the appropriate order. When using the GMPLS control
plane, establishment and enabling of OAM functions MUST be bound to plane, establishment and enabling of OAM functions MUST be bound to
RSVP-TE message exchanges. RSVP-TE message exchanges.
An LSP may be signaled and established without OAM configuration An LSP may be signaled and established without OAM configuration
first, and OAM entities may be added later with a subsequent re- first, and OAM entities may be added later with a subsequent re-
signaling of the LSP. Alternatively, the LSP may be setup with OAM signaling of the LSP. Alternatively, the LSP may be setup with OAM
entities with the first signaling of the LSP. The below procedures entities with the first signaling of the LSP. The below procedures
apply to both cases. apply to both cases.
Before the initiating a Path message with OAM Configuration Before initiating a Path message with OAM Configuration information,
information, an initiating node MUST establish and configure the an initiating node MUST establish and configure the corresponding OAM
corresponding OAM entities locally. But until the LSP is entities locally. But until the LSP is established, OAM source
established, OAM source functions MUST NOT start sending any OAM functions MUST NOT start sending any OAM messages. In the case of
messages. In the case of bidirectional connections, in addition to bidirectional connections, in addition to the OAM source function,
the OAM source function, the initiator node MUST set up the OAM sink the initiator node MUST set up the OAM sink function and prepare it
function and prepare it to receive OAM messages. During this time to receive OAM messages. During this time the OAM alarms MUST be
the OAM alarms MUST be suppressed (e.g., due to missing or suppressed (e.g., due to missing or unidentified OAM messages). To
unidentified OAM messages). To achieve OAM alarm suppression, Path achieve OAM alarm suppression, Path message MUST be sent with the
message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag "OAM Alarms Enabled" ADMIN_STATUS flag cleared.
cleared.
When the Path message arrives at the receiver, the remote end MUST When the Path message arrives at the receiver, the remote end MUST
establish and configure OAM entities according to the OAM information establish and configure OAM entities according to the OAM information
provided in the Path message. If this is not possible, a PathErr provided in the Path message. If this is not possible, a PathErr
SHOULD be sent and neither the OAM entities nor the LSP SHOULD be SHOULD be sent and neither the OAM entities nor the LSP SHOULD be
established. If OAM entities are established successfully, the OAM established. If OAM entities are established successfully, the OAM
sink function MUST be prepared to receive OAM messages, but MUST NOT sink function MUST be prepared to receive OAM messages, but MUST NOT
generate any OAM alarms (e.g., due to missing or unidentified OAM generate any OAM alarms (e.g., due to missing or unidentified OAM
messages). In the case of bidirectional connections, in addition to messages). In the case of bidirectional connections, in addition to
the OAM sink function, an OAM source function MUST be set up and, the OAM sink function, an OAM source function MUST be set up and,
according to the requested configuration, the OAM source function according to the requested configuration, the OAM source function
MUST start sending OAM messages. Then a Resv message is sent back, MUST start sending OAM messages. Then a Resv message is sent back,
including the OAM Configuration TLV that corresponds to the actually including the OAM Configuration TLV that corresponds to the
established and configured OAM entities and functions. Depending on established and configured OAM entities and functions. Depending on
the OAM technology, some elements of the OAM Configuration TLV MAY be the OAM technology, some elements of the OAM Configuration TLV MAY be
updated/changed; i.e., if the remote end is not supporting a certain updated/changed; i.e., if the remote end is not supporting a certain
OAM configuration it may suggest an alternative setting, which may or OAM configuration it may suggest an alternative setting, which may or
may not be accepted by the initiator of the Path message. If it is may not be accepted by the initiator of the Path message. If it is
accepted, the initiator will reconfigure its OAM functions according accepted, the initiator will reconfigure its OAM functions according
to the information received in the Resv message. If the alternate to the information received in the Resv message. If the alternate
setting is not acceptable a ResvErr may be sent tearing down the LSP. setting is not acceptable a ResvErr may be sent tearing down the LSP.
Details of this operation are technology specific and should be Details of this operation are technology specific and should be
described in accompanying technology specific documents. described in accompanying technology specific documents.
skipping to change at page 10, line 29 skipping to change at page 10, line 32
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
signaled 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 and the LSP_REQUIRED_ATTRIBUTES to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES
objects are defined in [RFC5420] to provide means to signal LSP objects are defined in [RFC5420] to provide means to signal LSP
attributes and options in the form of TLVs. Options and attributes attributes and options in the form of TLVs. Options and attributes
signaled in the LSP_ATTRIBUTES object can be passed transparently signaled in the LSP_ATTRIBUTES object can be passed transparently
through LSRs not supporting a particular option or attribute, while through LSRs not supporting a particular option or attribute, while
the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined
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 (IANA to assign): "OAM MEP entities desired" is allocated in One bit (IANA to assign): "OAM MEP entities desired" is allocated in
the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object.
If the "OAM MEP entities desired" bit is set it is indicating that If the "OAM MEP entities desired" bit is set it is indicating that
the establishment of OAM MEP entities are required at the endpoints the establishment of OAM MEP entities are required at the endpoints
of the signaled LSP. If the establishment of MEPs is not supported of the signaled LSP. If the establishment of MEPs is not supported
an error must be generated: "OAM Problem/MEP establishment not an error MUST be generated: "OAM Problem/MEP establishment not
supported". supported".
If the "OAM MEP entities desired" bit is set and additional If the "OAM MEP entities desired" bit is set and additional
parameters need to be configured, an OAM Configuration TLV MAY be parameters need to be configured, an OAM Configuration TLV MAY be
included in the LSP_ATTRIBUTES Object. included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
One bit (IANA to assign): "OAM MIP entities desired" is allocated in One bit (IANA to assign): "OAM MIP entities desired" is allocated in
the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUES objects. This bit can only be set if the "OAM LSP_REQUIRED_ATTRIBUES objects. This bit MUST only be set if the
MEP entities desired" bit is set. If the "OAM MIP entities desired" "OAM MEP entities desired" bit is set. If the "OAM MIP entities
bit is set in the LSP_ATTRIBUTES Flags TLV in the desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the
LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
establishment of OAM MIP entities is required at every transit node establishment of OAM MIP entities is required at every transit node
of the signaled LSP. If the establishment of a MIP is not supported of the signaled LSP. If the establishment of a MIP is not supported
an error MUST be generated: "OAM Problem/MIP establishment not an error MUST be generated: "OAM Problem/MIP establishment not
supported". supported".
4.2. OAM Configuration TLV 4.2. OAM Configuration TLV
This TLV provides information about which OAM technology/method This TLV provides information about which OAM technology/method
should be used and carries sub-TLVs for any additional OAM should be used and carries sub-TLVs for any additional OAM
configuration information. The OAM Configuration TLV MAY be carried configuration information. The OAM Configuration TLV MAY be carried
in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object,
it is indicating that intermediate nodes MUST recognize and it is indicating that intermediate nodes MUST recognize and react on
eventually react on the OAM configuration information. the OAM configuration information.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (IANA) | Length | | Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved | | OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub-TLVs ~ ~ sub-TLVs ~
skipping to change at page 12, line 13 skipping to change at page 12, line 16
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 in the OAM Configuration TLV. If the included technology included in the OAM Configuration TLV. If the included technology
specific OAM configuration sub-TLV is different from what is specific OAM configuration sub-TLV is different from what is
specified in the OAM Type an error MUST be generated: "OAM Problem/ specified in the OAM Type an error MUST be generated: "OAM Problem/
OAM Type Mismatch". IANA is requested to maintain the sub-TLV space OAM Type Mismatch". IANA is requested to maintain the sub-TLV space
in the new "RSVP-TE OAM Configuration Registry". in the new "RSVP-TE OAM Configuration Registry".
Note that there is a hierarchical dependency in between the OAM Sub-TLV Type Description
------------ ------------------------------------
0 Reserved
1 OAM Function Flags Sub-TLV
2-31 Reserved for generic Sub-TLVs
32- Reserved for technology specific Sub-TLVs
Note that there is a hierarchical dependency between the OAM
configuration elements. First, the "OAM MEP entities desired" flag configuration elements. First, the "OAM MEP entities desired" flag
needs to be set. Only when that flag is set MAY an "OAM needs to be set. Only when that flag is set MAY an "OAM
Configuration TLV" be included in the LSP_ATTRIBUTES or Configuration TLV" be included in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on
the "OAM Type" field, it MAY carry a technology specific OAM the "OAM Type" field, it MAY carry a technology specific OAM
configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP
entities desired" flag is not set but an OAM Configuration TLV is entities desired" flag is not set but an OAM Configuration TLV is
present) an error MUST be generated: "OAM Problem/Configuration present) an error MUST be generated: "OAM Problem/Configuration
Error". Error".
4.2.1. OAM Function Flags Sub-TLV 4.2.1. OAM Function Flags Sub-TLV
As the first sub-TLV the "OAM Function Flags sub-TLV" MUST always be As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be
included in the "OAM Configuration TLV". "OAM Function Flags" included in the "OAM Configuration TLV". "OAM Function Flags"
specifies which pro-active OAM functions (e.g., connectivity specifies which pro-active OAM functions (e.g., connectivity
monitoring, loss and delay measurement) and which fault management monitoring, loss and delay measurement) and which fault management
signals MUST be established and configured. If the selected OAM signals MUST be established and configured. If the selected OAM
Function(s) is(are) not supported, an error MUST be generated: "OAM Function(s) is(are) not supported, an error MUST be generated: "OAM
Problem/Unsupported OAM Function". Problem/Unsupported OAM Function".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 9 skipping to change at page 13, line 25
OAM Function Flags is bitmap with extensible length based on the OAM Function Flags is bitmap with extensible length based on the
Length field of the TLV. Bits are numbered from left to right. IANA Length field of the TLV. Bits are numbered from left to right. IANA
is requested to maintain the OAM Function Flags in the new "RSVP-TE is requested to maintain the OAM Function Flags in the new "RSVP-TE
OAM Configuration Registry". This document defines the following OAM Configuration Registry". This document defines the following
flags. flags.
OAM Function Flag bit# Description OAM Function Flag bit# Description
--------------------- --------------------------- --------------------- ---------------------------
0 Continuity Check (CC) 0 Continuity Check (CC)
1 Connectivity Verification (CV) 1 Connectivity Verification (CV)
2 Fault Monitoring Signal (FMS) 2 Fault Management Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss) 3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay) 4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement 5 Performance Monitoring/Throughput Measurement
(PM/Throughput) (PM/Throughput)
4.2.2. Technology Specific sub-TLVs 4.2.2. Technology Specific Sub-TLVs
One technology specific sub-TLV MAY be defined for each "OAM Type". One technology specific sub-TLV MAY be defined for each "OAM Type".
This sub-TLV MUST contain any further OAM configuration information This sub-TLV MUST contain any further OAM configuration information
for that specific "OAM Type". The technology specific sub-TLV, when for that specific "OAM Type". The technology specific sub-TLV, when
used, MUST be carried within the OAM Configuration TLV. IANA is used, MUST be carried within the OAM Configuration TLV. IANA is
requested to maintain the OAM technology specific sub-TLV space in requested to maintain the OAM technology specific sub-TLV space in
the new "RSVP-TE OAM Configuration Registry". the new "RSVP-TE OAM Configuration Registry".
4.3. Administrative Status Information 4.3. Administrative Status Information
skipping to change at page 13, line 37 skipping to change at page 14, line 5
Object. The Administrative Status Information is described in Object. The Administrative Status Information is described in
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
[RFC3473]. [RFC3473].
Two bits are allocated for the administrative control of OAM Two bits are allocated for the administrative control of OAM
monitoring. Two bits (IANA to assign) are allocated by this draft: monitoring. Two bits (IANA to assign) are allocated by this draft:
the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When
the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is
cleared, no OAM packets are emitted. When the "OAM Alarms Enabled" cleared, no OAM packets are emitted. When the "OAM Alarms Enabled"
bit is set OAM triggered alarms are enabled and associated consequent bit is set OAM triggered alarms are enabled and associated consequent
actions are executed including the notification of the management actions are executed including the notification to the management
system. When this bit is cleared, alarms are suppressed and no system. When this bit is cleared, alarms are suppressed and no
action is executed and the management system is not notified. action is executed and the management system is not notified.
4.4. Handling OAM Configuration Errors 4.4. Handling OAM Configuration Errors
To handle OAM configuration errors a new Error Code (IANA to assign) To handle OAM configuration errors, a new Error Code (IANA to assign)
"OAM Problem" is introduced. To refer to specific problems, a set of "OAM Problem" is introduced. To refer to specific problems, a set of
Error Values are defined under the "OAM Problem" error code. Error Values are defined under the "OAM Problem" error code.
If a node does not support the establishment of OAM MEP or MIP If a node does not support the establishment of OAM MEP or MIP
entities it MUST use the error value: "MEP establishment not entities it MUST use the error value: "MEP establishment not
supported" or "MIP establishment not supported" respectively in the supported" or "MIP establishment not supported" respectively in the
PathErr message. 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: "Unsupported OAM Type" in the PathErr message. use the error value: "Unsupported OAM Type" in the PathErr message.
If a different technology specific OAM configuration TLV is included If a different technology specific OAM configuration TLV is included
than what was specified in the OAM Type an error MUST be generated than what was specified in the OAM Type an error MUST be generated
with error value: "OAM Type Mismatch" in the PathErr message. with error value: "OAM Type Mismatch" in the PathErr message.
There is a hierarchy in between the OAM configuration elements. If There is a hierarchy between the OAM configuration elements. If this
this hierarchy is broken the error value: "Configuration Error" MUST hierarchy is broken, the error value: "Configuration Error" MUST be
be used in the PathErr message. used in the PathErr message.
If a node does not support a specific OAM Function it MUST use the If a node does not support a specific OAM Function, it MUST use the
error value: "Unsupported OAM Function" in the PathErr message. error value: "Unsupported OAM Function" in the PathErr message.
4.5. Considerations on Point-to-Multipoint OAM Configuration 4.5. Considerations on Point-to-Multipoint OAM Configuration
RSVP-TE extensions for the establishment of point-to-multipoint RSVP-TE extensions for the establishment of point-to-multipoint
(P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of
multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set
up between the ingress and egress LSRs, and are appropriately up between the ingress and egress LSRs, and are appropriately
combined by the branch LSRs using RSVP semantics to result in a P2MP 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 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 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 can be signaled using one Path message or split across multiple Path
messages. messages.
P2MP OAM mechanisms are very specific to the data plane technology, P2MP OAM mechanisms are very specific to the data plane technology,
therefore in this document we only highlight the basic principles of therefore in this document, we only highlight the basic principles of
P2MP OAM configuration. We consider only the root to leaf OAM flows, P2MP OAM configuration. We consider only the root to leaf OAM flows,
and as such aspects of the configuration of return paths are outside and as such, aspects of the configuration of return paths are outside
the scope of our discussions. We also limit our consideration to the the scope of our discussions. We also limit our consideration to the
case where all leaves must successfully establish OAM entities with case where all leaves must successfully establish OAM entities with
identical configuration in order the P2MP OAM is successfully identical configuration in order the P2MP OAM is successfully
established. In any case, the discussion set forth below provides established. In any case, the discussion set forth below provides
only guidelines for P2MP OAM configuration, details should be only guidelines for P2MP OAM configuration, details will be specified
specified in technology specific documents. in technology specific documents.
The root node may use a single Path message or multiple Path messages The root node may use a single Path message or multiple Path messages
to setup the whole P2MP tree. In the case when multiple Path to setup the whole P2MP tree. In the case when multiple Path
messages are used, the root node is responsible to keep the OAM messages are used, the root node is responsible to keep the OAM
Configuration information consistent in each of the sent Path Configuration information consistent in each of the sent Path
messages, i.e., the same information MUST be included in all Path messages, i.e., the same information MUST be included in all Path
messages used to construct the multicast tree. Each branching node messages used to construct the multicast tree. Each branching node
will propagate the Path message downstream on each of the branches, will propagate the Path message downstream on each of the branches,
when constructing a Path message the OAM Configuration information when constructing a Path message the OAM Configuration information
MUST be copied unchanged from the received Path message, including MUST be copied unchanged from the received Path message, including
skipping to change at page 15, line 28 skipping to change at page 15, line 45
entities desired" bit cleared in the RRO Attributes sub-object. entities desired" bit cleared in the RRO Attributes sub-object.
Branching nodes should collect and merge the received RROs according Branching nodes should collect and merge the received RROs according
to the procedures described in [RFC4875]. This way, the root when to the procedures described in [RFC4875]. This way, the root when
receiving the Resv message (or messages if multiple Path messages receiving the Resv message (or messages if multiple Path messages
were used to set up the tree) will have a clear information about were used to set up the tree) will have a clear information about
which of the leaves could establish the OAM functions. If all leaves which of the leaves could establish the OAM functions. If all leaves
established OAM entities successfully, the root can enable the OAM established OAM entities successfully, the root can enable the OAM
message flow. On the other hand, if at some leaves the establishment message flow. On the other hand, if at some leaves the establishment
was unsuccessful additional actions will be needed before the OAM was unsuccessful additional actions will be needed before the OAM
message flow can be enabled. Such action could be to setup two message flow can be enabled. Such action could be to setup two
independent P2MP LSPs. One with OAM Configuration information independent P2MP LSPs. One LSP with OAM Configuration information
towards leaves which could successfully setup the OAM function. This towards leaves which could successfully setup the OAM function. This
can be done by pruning the leaves which failed to setup OAM of the can be done by pruning the leaves which failed to setup OAM of the
previously signaled P2MP LSP. The other P2MP LSP could be previously signaled P2MP LSP. The other P2MP LSP could be
constructed for leaves without OAM entities. The exact procedures constructed for leaves without OAM entities. The exact procedures
SHOULD be described in technology specific documents. will 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", "OAM Type Mismatch"
Function" needs to be assigned. and "Unsupported OAM Function" needs to be assigned.
IANA is requested to open a new registry: "RSVP-TE OAM Configuration IANA is requested to open a new registry: "RSVP-TE OAM Configuration
Registry" that maintains the "OAM Type" code points, an associated Registry" that maintains the "OAM Type" code points, an associated
sub-TLV space, and the allocations of "OAM Function Flags" within the sub-TLV space, and the allocations of "OAM Function Flags" within the
OAM Configuration TLV. OAM Configuration TLV.
RSVP-TE OAM Configuration Registry
OAM Type Description
------------ ------------------
0-255 Reserved
Sub-TLV Type Description
------------ ------------------------------------
0 Reserved
1 OAM Function Flags Sub-TLV
2-31 Reserved for generic Sub-TLVs
32- Reserved for technology specific Sub-TLVs
OAM Function Flag bit# Description
---------------------- -------------------------------
0 Continuity Check (CC)
1 Connectivity Verification (CV)
2 Fault Management Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement
(PM/Throughput)
6- Reserved
6. Security Considerations 6. Security Considerations
The signaling of OAM related parameters and the automatic The signaling of OAM related parameters and the automatic
establishment of OAM entities based on RSVP-TE messages adds a new establishment of OAM entities based on RSVP-TE messages adds a new
aspect to the security considerations discussed in [RFC3473]. In aspect to the security considerations discussed in [RFC3473]. In
particular, a network element could be overloaded, if a remote particular, a network element could be overloaded, if a remote
attacker could request liveliness monitoring, with frequent periodic attacker could request liveliness monitoring, with frequent periodic
messages, for a high number of LSPs, targeting a single network messages, for a high number of LSPs, targeting a single network
element. Such an attack can efficiently be prevented when mechanisms element. Such an attack can efficiently be prevented when mechanisms
for message integrity and node authentication are deployed. Since for message integrity and node authentication are deployed. Since
the OAM configuration extensions rely on the hop-by-hop exchange of the OAM configuration extensions rely on the hop-by-hop exchange of
exiting RSVP-TE messages, procedures specified for RSVP message exiting RSVP-TE messages, procedures specified for RSVP message
security in [RFC2747] can be used to mitigate possible attacks. security in [RFC2747] can be used to mitigate possible attacks.
For a more comprehensive discussion on GMPLS security please see the For a more comprehensive discussion on GMPLS security, please see the
Security Framework for MPLS and GMPLS Networks [RFC5920]. Security Framework for MPLS and GMPLS Networks [RFC5920].
Cryptography can be used to protect against many attacks described in Cryptography can be used to protect against many attacks described in
[RFC5920]. [RFC5920].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel, The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments. comments.
 End of changes. 33 change blocks. 
58 lines changed or deleted 91 lines changed or added

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