draft-ietf-ccamp-oam-configuration-fwk-04.txt   draft-ietf-ccamp-oam-configuration-fwk-05.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: April 28, 2011 Alcatel-Lucent Expires: September 15, 2011 Alcatel-Lucent
J. He J. He
Huawei Huawei
October 25, 2010 March 14, 2011
GMPLS RSVP-TE extensions for OAM Configuration GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-04 draft-ietf-ccamp-oam-configuration-fwk-05
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 26 skipping to change at page 2, line 26
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 April 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Simplified 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. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 8 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 9
3.1. Establishment of OAM Entities and Functions . . . . . . . 8 3.1. Establishment of OAM Entities and Functions . . . . . . . 9
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 11
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 11
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 13
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 13
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 13 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 14
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 15
4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 16
4.3. Administrative Status Information . . . . . . . . . . . . 15 4.3. Administrative Status Information . . . . . . . . . . . . 16
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 16
4.5. Considerations on Point-to-Multipoint OAM Configuration . 16 4.5. Considerations on Point-to-Multipoint OAM Configuration . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 37 skipping to change at page 6, line 37
MPLS-TP defines a profile of MPLS targeted at transport applications MPLS-TP defines a profile of MPLS targeted at transport applications
[RFC5921]. This profile specifies the specific MPLS characteristics [RFC5921]. This profile specifies the specific MPLS characteristics
and extensions required to meet transport requirements, including and extensions required to meet transport requirements, including
providing additional OAM, survivability and other maintenance providing additional OAM, survivability and other maintenance
functions not currently supported by MPLS. Specific OAM requirements functions not currently supported by MPLS. Specific OAM requirements
for MPLS-TP are specified in [RFC5654] [RFC5860]. MPLS-TP poses for MPLS-TP are specified in [RFC5654] [RFC5860]. MPLS-TP poses
requirements on the control plane to configure and control OAM requirements on the control plane to configure and control OAM
entities: entities:
o OAM functions MUST operate and be configurable even in the absence o From [RFC5860]: OAM functions MUST operate and be configurable
of a control plane. Conversely, it SHOULD be possible to even in the absence of a control plane. Conversely, it SHOULD be
configure as well as enable/disable the capability to operate OAM possible to configure as well as enable/disable the capability to
functions as part of connectivity management, and it SHOULD also operate OAM functions as part of connectivity management, and it
be possible to configure as well as enable/disable the capability SHOULD also be possible to configure as well as enable/disable the
to operate OAM functions after connectivity has been established. capability to operate OAM functions after connectivity has been
established.
o The MPLS-TP control plane MUST support the configuration and o From [RFC5654]: The MPLS-TP control plane MUST support the
modification of OAM maintenance points as well as the activation/ configuration and modification of OAM maintenance points as well
deactivation of OAM when the transport path or transport service as the activation/ deactivation of OAM when the transport path or
is established or modified. transport service is established or modified.
Ethernet Connectivity Fault Management (CFM) defines an adjunct Ethernet Connectivity Fault Management (CFM) defines an adjunct
connectivity monitoring OAM flow to check the liveliness of Ethernet connectivity monitoring OAM flow to check the liveliness of Ethernet
networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks
support explicitly-routed Ethernet connections. CFM can be used to support explicitly-routed Ethernet connections. CFM can be used to
track the liveliness of PBB-TE connections and detect data plane track the liveliness of PBB-TE connections and detect data plane
failures. In IETF the GMPLS controlled Ethernet Label Switching failures. In IETF the GMPLS controlled Ethernet Label Switching
(GELS) (see [RFC5828] and [GMPLS-PBBTE]) work is extending the GMPLS (GELS) (see [RFC5828] and [RFC6060]) work extended the GMPLS control
control plane to support the establishment of point-to-point PBB-TE plane to support the establishment of PBB-TE data plane connections.
data plane connections. Without control plane support separate Without control plane support separate management commands would be
management commands would be needed to configure and start CFM. 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 [RFC5921] and based such as SDH/SONET, packet based such as MPLS-TP [RFC5921] and
Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator
MUST be able to configure and control the following OAM functions. MUST be able to configure and control the following OAM 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
skipping to change at page 7, line 43 skipping to change at page 7, line 44
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 Pro-active Performance Monitoring (PM) functions are continuously o Pro-active Performance Monitoring (PM) functions are continuously
collecting information about specific characteristics of the collecting information about specific characteristics of the
connection. For consistent measurement of Service Level connection. For consistent measurement of Service Level
Agreements (SLAs) it may be required that measurement points agree Agreements (SLAs) measurement points must use common probing rate
on a common probing rate to avoid measurement problems. to avoid measurement errors.
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. RSVP-TE based OAM Configuration 3. RSVP-TE based OAM Configuration
skipping to change at page 9, line 21 skipping to change at page 10, line 21
corresponding OAM entities locally, however OAM source functions MUST corresponding OAM entities locally, however OAM source functions MUST
NOT start sending any OAM messages. In the case of bidirectional NOT start sending any OAM messages. In the case of bidirectional
connections, the initiator node MUST setup the OAM sink function to connections, the initiator node MUST setup the OAM sink function to
be prepared to receive OAM messages but MUST suppress any OAM alarms be prepared to receive OAM messages but MUST suppress any OAM alarms
(e.g., due to missing or unidentified OAM messages). The Path (e.g., due to missing or unidentified OAM messages). The Path
message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag
cleared, i.e, data plane OAM alarms are suppressed. cleared, i.e, data plane OAM alarms are suppressed.
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 the Path message. If this is not possible a PathErr
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, 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,
the OAM source function MUST start sending OAM messages. Then a Resv the OAM source function MUST start sending OAM messages. Then a Resv
message is sent back, including the OAM Configuration TLV that message is sent back, including the OAM Configuration TLV that
corresponds to the actually established and configured OAM entities corresponds to the actually established and configured OAM entities
and functions. Depending on the OAM technology, some elements of the and functions. Depending on the OAM technology, some elements of the
OAM Configuration TLV MAY be updated/changed; i.e., if the remote end OAM Configuration TLV MAY be updated/changed; i.e., if the remote end
skipping to change at page 11, line 4 skipping to change at page 12, line 4
settings. However OAM alarms are still disabled. A subsequent Path/ settings. However OAM alarms are still disabled. A subsequent Path/
Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set
is needed to enable OAM alarms again. is needed to enable OAM alarms again.
3.3. Deleting OAM Entities 3.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and In some cases it may be useful to remove some or all OAM entities and
functions from an LSP without actually tearing down the connection. functions from an LSP without actually tearing down the connection.
To avoid any spurious alarm, first the LSP SHOULD be re-signaled with To avoid any spurious alarm, first the LSP SHOULD be re-signaled with
"OAM Alarms" ADMIN_STATUS flag cleared but unchanged OAM "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM
configuration. Subsequently, the LSP is re-signaled with "OAM MEP configuration. Subsequently, the LSP is re-signaled with "OAM MEP
Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
cleared, and without the OAM Configuration TLV, this MUST result in cleared, and without the OAM Configuration TLV, this MUST result in
the deletion of all OAM entities associated with the LSP. All the deletion of all OAM entities associated with the LSP. All
control and data plane resources in use by the OAM entities and control and data plane resources in use by the OAM entities and
functions SHOULD be freed up. Alternatively, if only some OAM functions SHOULD be freed up. Alternatively, if only some OAM
functions need to be removed, the LSP is re-signalled with the functions need to be removed, the LSP is re-signalled with the
updated OAM Configuration TLV. Changes between the contents of the updated OAM Configuration TLV. Changes between the contents of the
previously signalled OAM Configuration TLV and the currently received previously signalled OAM Configuration TLV and the currently received
TLV represent which functions SHOULD be removed/added. TLV represent which functions SHOULD be removed/added.
skipping to change at page 12, line 29 skipping to change at page 13, line 29
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 (10 IANA to assign): "OAM MEP entities desired" is allocated One bit (IANA to assign): "OAM MEP entities desired" is allocated in
in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" the LSP Attributes Flags TLV. If the "OAM MEP entities desired" bit
bit is set it is indicating that the establishment of OAM MEP is set it is indicating that the establishment of OAM MEP entities
entities are required at the endpoints of the signaled LSP. If the 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 but additional If the "OAM MEP entities desired" bit is set but additional
parameters need also to be configured, an OAM Configuration TLV MAY parameters need also to be configured, an OAM 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 (IANA to assign): "OAM MIP entities desired" is allocated in
in the LSP Attributes Flags TLV. This bit can only be set if the the LSP Attributes Flags TLV. This bit can only be set if the "OAM
"OAM MEP entities desired" bit is set. If the "OAM MIP entities MEP entities desired" bit is set. If the "OAM MIP entities desired"
desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the 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 signalled LSP. If the establishment of a MIP is not supported of the signalled 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. 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 (3) (IANA) | Length | | Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved | | OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub-TLVs ~ ~ sub-TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (3) (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. When carried
requested OAM method is not supported an error must be generated: in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is
"OAM Problem/Unsupported OAM Type". not supported at a given node an error must be generated: "OAM
Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES
Object, intermediate nodes not supporting the OAM Type pass the
object forward unchanged as specified in [RFC5420] only Label Edge
Nodes must generate the error if the OAM Type is not supported.
OAM Type Description OAM Type Description
------------ -------------------- ------------ --------------------
0-255 Reserved 0-255 Reserved
This document defines no types. IANA is requested 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". IANA is requested to
maintain the sub-TLV space in the new "RSVP-TE OAM Configuration
Registry".
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. Only when that is set MAY an "OAM desired" flag needs to be set. Only when that 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 one "OAM Function Flags sub-TLV" MUST be always As the first sub-TLV the "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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Function Flags is bitmap with extensible length based on the OAM Function Flags is bitmap with extensible length based on the
Lenght field of the TLV. Bits are numbered from left to right as Lenght field of the TLV. Bits are numbered from left to right. IANA
shown in the figure. This document defines the following flags. is requested to maintain the OAM Function Flags in the new "RSVP-TE
OAM Configuration Registry". This document defines the following
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 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 MAY be defined for each "OAM Type".
Type". This sub-TLV MUST contain any further OAM configuration This sub-TLV MUST contain any further OAM configuration information
information for that specific "OAM Type". The technology specific for that specific "OAM Type". The technology specific sub-TLV, when
sub-TLV, when used, MUST be carried within the OAM Configuration TLV. used, MUST be carried within the OAM Configuration TLV. IANA is
requested to maintain the sub-TLV space in the new "RSVP-TE OAM
Configuration Registry".
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. Two bits (IANA to assign) are allocated by this draft:
occupied (assigned by IANA or temporarily blocked by work in progress the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When
Internet drafts). As the 24th and 25th bits (IANA to assign) this the "OAM Flows Enabled" bit is set, OAM packets are sent if it is
draft introduces the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" cleared no OAM packets are emitted. When the "OAM Alarms Enabled"
(O) bits. When the "OAM Flows Enabled" bit is set, OAM packets are bit is set OAM triggered alarms are enabled and associated consequent
sent if it is cleared no OAM packets are emitted. When the "OAM actions are executed including the notification of the management
Alarms Enabled" bit is set OAM triggered alarms are enabled and system. When this bit is cleared, alarms are suppressed and no
associated consequent actions are executed including the notification action is executed and the management system is not notified.
of the management system. When this bit is cleared, alarms are
suppressed and no action is executed and the management system is not
notified.
4.4. Handling OAM Configuration Errors 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 is defined. Error Values is defined.
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 (IANA to assign): "MEP entities it must use the error value (IANA to assign): "MEP
establishment not supported" or "MIP establishment not supported" establishment not supported" or "MIP establishment not supported"
skipping to change at page 21, line 23 skipping to change at page 22, line 23
Signaling Resource ReserVation Protocol-Traffic Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5420] "Encoding of Attributes for Multiprotocol Label Switching [RFC5420] "Encoding of Attributes for Multiprotocol Label Switching
(MPLS) Label Switched Path (LSP) Establishment Using (MPLS) Label Switched Path (LSP) Establishment Using
Resource ReserVation Protocol-Traffic Engineering Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 5420, February 2009. (RSVP-TE)", RFC 5420, February 2009.
8.2. Informative References 8.2. Informative References
[GMPLS-PBBTE]
"Generalized Multiprotocol Label Switching (GMPLS) control
of Ethernet Provider Backbone Traffic Engineering
(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.
[RFC2747] "RSVP Cryptographic Authentication", RFC 2747, [RFC2747] "RSVP Cryptographic Authentication", RFC 2747,
January 2000. January 2000.
skipping to change at page 23, line 5 skipping to change at page 23, line 14
[RFC5860] "Requirements for OAM in MPLS Transport Networks", [RFC5860] "Requirements for OAM in MPLS Transport Networks",
RFC 5860, May 2010. RFC 5860, May 2010.
[RFC5920] "Security Framework for MPLS and GMPLS Networks", [RFC5920] "Security Framework for MPLS and GMPLS Networks",
RFC 5920, July 2010. RFC 5920, July 2010.
[RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921, [RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921,
July 2010. July 2010.
[RFC6060] "Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering
(PBB-TE)", RFC 6060.
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. 24 change blocks. 
80 lines changed or deleted 87 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/