draft-ietf-ccamp-rsvp-te-eth-oam-ext-09.txt   draft-ietf-ccamp-rsvp-te-eth-oam-ext-10.txt 
Network Working Group A. Takacs Network Working Group A. Takacs
Internet-Draft B. Gero Internet-Draft B. Gero
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 29, 2013 H. Long Expires: December 17, 2013 H. Long
Huawei Huawei
February 25, 2013 June 15, 2013
GMPLS RSVP-TE Extensions for Ethernet OAM Configuration GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-09 draft-ietf-ccamp-rsvp-te-eth-oam-ext-10
Abstract Abstract
The GMPLS controlled Ethernet Label Switching (GELS) work extended The GMPLS controlled Ethernet Label Switching (GELS) work extended
GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE
Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM
flow to check connectivity in Ethernet networks. CFM can be also flow to check connectivity in Ethernet networks. CFM can be also
used with Ethernet LSPs for fault detection and triggering recovery used with Ethernet LSPs for fault detection and triggering recovery
mechanisms. The ITU-T Y.1731 specification builds on CFM and mechanisms. The ITU-T Y.1731 specification builds on CFM and
specifies additional OAM mechanisms, including Performance specifies additional OAM mechanisms, including Performance
Monitoring, for Ethernet networks. This document specifies Monitoring, for Ethernet networks. This document specifies
extensions of GMPLS RSVP-TE to support the setup of the associated extensions of GMPLS RSVP-TE protocol to support the setup of the
Ethernet OAM entities of Ethernet LSPs, and defines the Ethernet associated Ethernet OAM entities of Ethernet LSPs, and defines the
technology specific TLV based on [OAM-CONF-FWK]. Ethernet technology specific TLVs based on [OAM-CONF-FWK]. This
document supports, but does not modify, the IEEE and ITU-T OAM
mechanisms.
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 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). 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 August 29, 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Ethernet OAM operation . . . . . . . . . . . . . . 5 2. Overview of Ethernet OAM operation . . . . . . . . . . . . . . 5
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 7 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 7
3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 7 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 7
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 9 3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 9
3.3. Ethernet OAM Configuration TLV . . . . . . . . . . . . . . 9 3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . . 9
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 10 3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 10
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 11 3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 11
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12 3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12
3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 13 3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 13
3.5. Ethernet OAM configuration errors . . . . . . . . . . . . 13 3.5. Summary of Ethernet OAM configuration errors . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Background 1. Background
Provider Backbone Bridging - Traffic Engineering (PBB-TE) [IEEE] Provider Backbone Bridging - Traffic Engineering (PBB-TE)
decouples the Ethernet data and control planes, and allows external [IEEE.802.1Q-2011] decouples the Ethernet data and control planes,
control and management mechanisms to create explicitly routed and allows external control and management mechanisms to create
Ethernet connections. In addition, PBB-TE defines mechanisms for explicitly routed Ethernet connections. In addition, PBB-TE defines
protection switching of bidirectional Ethernet connections. Ethernet mechanisms for protection switching of bidirectional Ethernet
Connectivity Fault Management (CFM) defines an adjunct connectivity connections. Ethernet Connectivity Fault Management (CFM) defines an
monitoring OAM flow to check the liveliness of Ethernet networks adjunct connectivity monitoring OAM flow to check the liveliness of
[IEEE], including the monitoring of specific explicitly routed Ethernet networks [IEEE.802.1Q-2011], including the monitoring of
Ethernet connections. specific explicitly routed Ethernet connections. The ITU-T
Recommendation Y.1731 [ITU-T.Y.1731-2011] extended CFM and specified
additional OAM functionality.
In IETF the GMPLS controlled Ethernet Label Switching (GELS) work In IETF, the GMPLS controlled Ethernet Label Switching (GELS) work
extended the GMPLS control plane to support the establishment of extended the GMPLS control plane to support the establishment of
explicitly routed Ethernet connections [RFC5828][RFC6060]. We refer explicitly routed Ethernet connections [RFC5828][RFC6060]. We refer
to GMPLS established Ethernet connections as Ethernet LSPs. GELS to GMPLS established Ethernet connections as Ethernet LSPs. GELS
enables the application of MPLS-TE and GMPLS provisioning and enables the application of MPLS-TE and GMPLS provisioning and
recovery features in Ethernet networks. recovery features in Ethernet networks.
The use of GMPLS RSVP-TE to support the establishment and
configuration of OAM entities with LSP signaling is defined in a
technology agnostic way in [OAM-CONF-FWK]. The purpose of this
document is to specify the additional technology specific OAM
entities to support Ethernet connections.
2. Overview of Ethernet OAM operation 2. Overview of Ethernet OAM operation
For the purposes of this document, we only discuss those Ethernet OAM For the purposes of this document, we only discuss Ethernet OAM
[IEEE] aspects that are relevant for the connectivity monitoring of aspects that are relevant for proactive connectivity monitoring of
Ethernet LSPs. Ethernet LSPs. On-demand OAM functions for the purposes of this
document will be supported by Management Plane operations.
PBB-TE [IEEE] defines point-to-point Ethernet Switched Paths (ESPs) PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as a
as a provisioned traffic engineered unidirectional connectivity, provisioned traffic engineered unidirectional connectivity,
identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where
the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA
is the source address of the ESP, and the ESP-VID is a VLAN is the source address of the ESP, and the ESP-VID is a VLAN
identifier allocated for explicitly routed connections. To form a identifier allocated for explicitly routed connections. To form a
bidirectional PBB-TE connection two co-routed point-to-point ESPs are bidirectional PBB-TE connection, two co-routed point-to-point ESPs
combined. The combined ESPs must have the same ESP-MAC addresses but are combined. The combined ESPs must have the same ESP-MAC addresses
may have different ESP-VIDs. but may have different ESP-VIDs.
Note that although it would be possible to use GMPLS to setup a Note that although it would be possible to use GMPLS to setup a
single unidirectional ESP, the Ethernet OAM mechanisms are only full single unidirectional ESP, the Ethernet OAM mechanisms are only fully
functional when bidirectional connections are established with co- functional when bidirectional connections are established with co-
routed ESPs. Therfore, the scope of this document only covers routed ESPs. Therefore, the scope of this document only covers
bidirectional point-to-point PBB-TE connections. bidirectional point-to-point PBB-TE connections.
At both ends of the bidirectional point-to-point PBB-TE connection At both ends of the bidirectional point-to-point PBB-TE connection,
one Maintenance Endpoint (MEP) is configured. The MEPs monitoring a one Maintenance Endpoint (MEP) is configured. The MEPs monitoring a
PBB-TE connection must be configured with the same Maintenance Domain PBB-TE connection must be configured with the same Maintenance Domain
Level (MD Level) and Maintenance Association Identifier (MAID). Each Level (MD Level) and Maintenance Association Identifier (MAID). Each
MEP has a unique identifier, the MEP ID. Besides these identifiers a MEP has a unique identifier, the MEP ID. Besides these identifiers,
MEP monitoring a PBB-TE connection must be provisioned with the a MEP monitoring a PBB-TE connection must be provisioned with the
3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs. 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs.
In the case of point-to-point VLAN connections, the connection may be In the case of point-to-point VLAN connections, the connection may be
identified with a single VLAN, or with two VLANs one for each identified with a single VLAN, or with two VLANs, one for each
direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs,
MEPs must be provisioned with the proper VLAN identifiers. MEPs must be provisioned with the proper VLAN identifiers.
MEPs exchange Connectivity Check Messages (CCMs) periodically with MEPs exchange Connectivity Check Messages (CCMs) periodically with
fixed intervals. Eight distinct intervals are defined in [IEEE]: fixed intervals. Eight distinct intervals are defined in
[IEEE.802.1Q-2011]:
+---+--------------------+----------------+ +---+--------------------+----------------+
| # | CCM Interval (CCI) | 3 bit encoding | | # | CCM Interval (CCI) | 3 bit encoding |
+---+--------------------+----------------+ +---+--------------------+----------------+
| 0 | Reserved | 000 | | 0 | Reserved | 000 |
| | | | | | | |
| 1 | 3 1/3 ms | 001 | | 1 | 3 1/3 ms | 001 |
| | | | | | | |
| 2 | 10 ms | 010 | | 2 | 10 ms | 010 |
| | | | | | | |
skipping to change at page 6, line 28 skipping to change at page 6, line 28
| 5 | 10 s | 101 | | 5 | 10 s | 101 |
| | | | | | | |
| 6 | 1 min | 110 | | 6 | 1 min | 110 |
| | | | | | | |
| 7 | 10 min | 111 | | 7 | 10 min | 111 |
+---+--------------------+----------------+ +---+--------------------+----------------+
Table 1: CCM Interval encoding Table 1: CCM Interval encoding
If 3 consecutive CCM messages are lost; connectivity failure is If 3 consecutive CCM messages are lost; connectivity failure is
declared. The MEP detecting the failiure will signal the defect to declared. The MEP detecting the failure will signal the defect to
the remote MEP in the subsequent CCM messages it emmits, by setting the remote MEP in the subsequent CCM messages it emits, by setting
the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP
receives a CCM message with RDI bit set it immediately declares receives a CCM message with RDI bit set it immediately declares
failure. The detection of a failure may trigger protection switching failure. The detection of a failure may trigger protection switching
mechanisms or may be signaled to a management system. mechanisms or may be signaled to a management system.
At each transit node Maintenance Intermediate Points (MIPs) may be At each transit node, Maintenance Intermediate Points (MIPs) may be
established to help failure localization, e.g., using link trace and established to help failure localization, e.g., using link trace and
loop back functions. MIPs need to be provisioned with a subset of loop back functions. MIPs need to be provisioned with a subset of
the MEP identification parameters described above. the MEP identification parameters described above.
3. GMPLS RSVP-TE Extensions 3. GMPLS RSVP-TE Extensions
3.1. Operation overview 3.1. Operation overview
To simplify the configuration of connectivity monitoring, when an To simplify the configuration of connectivity monitoring, when an
Ethernet LSP is signaled the associated MEPs should be automatically Ethernet LSP is signaled, the associated MEPs should be automatically
established. To monitor an Ethernet LSP a set of parameters must be established. To monitor an Ethernet LSP, a set of parameters must be
provided to setup a Maintenance Association and related MEPs. provided to setup a Maintenance Association and related MEPs.
Optionally, MIPs may be created at the transit nodes of the Ethernet Optionally, MIPs may be created at the transit nodes of the Ethernet
LSP. The LSP Attributes Flags: "OAM MEP entities desired" and "OAM LSP. The LSP Attributes Flags: "OAM MEP entities desired" and "OAM
MIP entities desired", described in [OAM-CONF-FWK] are used to signal MIP entities desired", as described in [OAM-CONF-FWK], are used to
that the respective OAM entities must be established. Subsequently, signal that the respective OAM entities must be established. An OAM
an OAM Configuration TLV is added to the LSP_ATTRIBUTES Object Configuration TLV, as described in [OAM-CONF-FWK], is added to the
specifying that Ethernet OAM is to be setup for the LSP. Ethernet LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects specifying that
OAM specific information, as described below, is carried in the new Ethernet OAM is to be setup for the LSP. Ethernet OAM specific
Ethernet OAM Configuration sub-TLV. information, as described below, is carried in the new Ethernet OAM
Configuration Sub-TLV (see Section 3.3) within the OAM Configuration
TLV.
o A unique MAID must be allocated for the PBB-TE connection and both o A unique MAID must be allocated for the PBB-TE connection and both
MEPs must be configured with the same information. The MAID MEPs must be configured with the same information. The MAID
consists of an optional Maintenance Domain Name (MD Name) and a consists of an optional Maintenance Domain Name (MD Name) and a
mandatory Short Maintenance Association Name (Short MA Name). mandatory Short Maintenance Association Name (Short MA Name).
Various formatting rules for these names have been defined in Various formatting rules for these names have been defined in
[IEEE]. Since this information is also carried in all CCM [IEEE.802.1Q-2011]. Since this information is also carried in all
messages, the combined length of the Names is limited to 44 bytes. CCM messages, the combined length of the Names is limited to 44
How these parameters are determined is out of scope of this bytes. How these parameters are determined is out of scope of
document. this document.
o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely
identifies a given MEP within a Maintenance Association. That is, identifies a given MEP within a Maintenance Association. That is,
the combination of MAID and MEP ID must uniquely identify a MEP. the combination of MAID and MEP ID must uniquely identify a MEP.
How the value of the MEP ID is determined is out of scope of this How the value of the MEP ID is determined is out of scope of this
document. document.
o The Maintenance Domain Level (MD Level) allows hierarchical o The Maintenance Domain Level (MD Level) allows hierarchical
separation of monitoring entities. [IEEE] allows differentiation separation of monitoring entities. [IEEE.802.1Q-2011] allows
of 8 levels. How the value of the MD Level is determined is out differentiation of 8 levels. How the value of the MD Level is
of scope of this document. Note that most probably for all determined is out of scope of this document. Note that probably
Ethernet LSPs a single (default) MD Level will be used within a for all Ethernet LSPs a single (default) MD Level will be used
network domain. within a network domain.
o The desired CCM Interval must be specified by the management o The desired CCM Interval must be specified by the management
system based on service requirements or operator policy. The same system based on service requirements or operator policy. The same
CCM Interval must be set in each of the MEPs monitoring a given CCM Interval must be set in each of the MEPs monitoring a given
Ethernet LSP. How the value of the CCM Interval is determined is Ethernet LSP. How the value of the CCM Interval is determined is
out of scope of this document. out of scope of this document.
o The desired forwarding priority to be set by MEPs for the CCM o The desired forwarding priority to be set by MEPs for the CCM
frames can be specified. The same CCM priority must be set in frames can be specified. The same CCM priority must be set in
each of the MEPs monitoring a given Ethernet LSP. How CCM each of the MEPs monitoring a given Ethernet LSP. How CCM
priority is determined is out of scope of this document. Note priority is determined is out of scope of this document. Note
that the highest priority is used as the default CCM priority. that the highest priority should be used as the default CCM
priority.
o MEPs must be aware of their own and the reachability parameters of o MEPs must be aware of their own and the reachability parameters of
the remote MEP. In the case of bidirectional point-to-point the remote MEP. In the case of bidirectional point-to-point
PBB-TE connections this requires that the 3-tuples [ESP-MAC A, PBB-TE connections, this requires that the 3-tuples [ESP-MAC A,
ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are
configured in each MEP, where the ESP-MAC A is the same as the configured in each MEP, where the ESP-MAC A is the same as the
local MEP's MAC address and ESP-MAC B is the same as remote MEP's local MEP's MAC address and ESP-MAC B is the same as remote MEP's
MAC address. The GMPLS Ethernet Label format, as defined in MAC address. The GMPLS Ethernet Label format, as defined in
[RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence the [RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence the
necessary reachability parameters for the MEPs can be obtained necessary reachability parameters for the MEPs can be obtained
from Ethernet Labels (i.e., carried in the "downstream" and from the Ethernet Labels (i.e., carried in the downstream and
upstream labels). In the case of point-to-point VLAN connections, upstream labels). In the case of point-to-point VLAN connections,
MEPs need to be provisioned with the VLAN identifiers only, which MEPs need to be provisioned with the VLAN identifiers only, which
can be derived similarly from the Ethernet Label. can be derived similarly from the Ethernet Labels.
Assuming the procedures described in [RFC6060] for bidirectional Based on the procedures described in [RFC6060] for bidirectional
PBB-TE Ethernet LSP establishment the MEP configuration should be as PBB-TE Ethernet LSP establishment, the Ethernet OAM configuration
follows. When the RSVP-TE signaling is initiated for the procedures are recommended as follows:
bidirectional Ethernet LSP the local node generates a Path message
and: When the RSVP-TE signaling is initiated for the bidirectional
Ethernet LSP the local node generates a Path message and:
o Allocates an Upstream Label formed by combining its MAC address o Allocates an Upstream Label formed by combining its MAC address
(ESP-MAC A) and locally selected VID (ESP-VID1), which will be (ESP-MAC A) and locally selected VID (ESP-VID1), which will be
used to receive traffic; used to receive traffic;
o Inserts the OAM Configuration TLV with OAM Type set to Ethernet o MUST include the OAM Configuration TLV with OAM Type set to
OAM in the LSP_ATTRIBUTES object; Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
Object;
o Adds the OAM Function Flags sub-TLV in the OAM Configuration TLV o MUST include the OAM Function Flags Sub-TLV in the OAM
and sets the OAM function flags as needed; Configuration TLV and set the OAM function flags as needed;
o Adds an Ethernet OAM Configuration sub-TLV in the OAM o MUST include an Ethernet OAM Configuration Sub-TLV in the OAM
Configuration TLV that specifies the CCM Interval and MD Level; Configuration TLV that specifies the CCM Interval and MD Level;
o Adds an MD Name Sub-TLV (optional) and a Short MA Name Sub-TLV to o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name
the Ethernet OAM Configuration TLV, that will unambiguously Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, that
identify a Maintenance Association for this specific PBB-TE will unambiguously identify a Maintenance Association for this
connection. Note that values for these parameters may be derived specific PBB-TE connection. Note that values for these parameters
from the GMPLS LSP identification parameters; may be derived from the GMPLS LSP identification parameters;
o Adds a MEP ID Sub-TLV to the Ethernet OAM Configuration TLV. It o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration
selects two distinct integer values to identify the local and Sub-TLV and select two distinct integer values to identify the
remote MEPs within the Maintenance Association created for local and remote MEPs within the Maintenance Association created
monitoring of the point-to-point PBB-TE connection. for monitoring of the point-to-point PBB-TE connection.
Once the remote node receives the Path message it can use the Once the remote node receives the Path message, it can use the
UPSTREAM_LABEL to extract the reachability information of the UPSTREAM_LABEL to extract the reachability information of the
initiator. Then it allocates a Label by selecting a local MAC initiator. Then it allocates a Label by selecting a local MAC
address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive
traffic. These parameters determine the reachability information of traffic. These parameters determine the reachability information of
the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP- the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-
VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the
Ethernet Labels. In addition the information received in the Ethernet Labels. In addition, the information received in the
Ethernet OAM Configuration TLV is used to configure the local MEP. Ethernet OAM Configuration TLV is used to configure the local MEP.
Once the Resv message successfully arrives to the initiator, this can Once the Resv message successfully arrives to the initiator, this end
extract the remote side's reachability information from the Label can extract the remote side's reachability information from the Label
Object and therefore it has all the information needed to properly Object and therefore it has all the information needed to properly
configure its local MEP. configure its local MEP.
3.2. OAM Configuration TLV 3.2. OAM Configuration TLV
This TLV is specified in [OAM-CONF-FWK] and is used to select which This TLV is specified in [OAM-CONF-FWK] and is used to select which
OAM technology/method should be used for the LSP. In this document a OAM technology/method should be used for the LSP. In this document,
new OAM Type: Ethernet OAM is defined. a new OAM Type: Ethernet OAM is defined. IANA is requested to
allocate OAM Type 1 for Ethernet OAM in the RSVP-TE OAM Configuration
Registry.
RSVP-TE OAM Configuration Registry
OAM Type Description OAM Type Description
------------ ------------------ ------------ ------------------
0 Reserved
1 Ethernet OAM 1 Ethernet OAM
2-256 Reserved
The receiving node when the Ethernet OAM Type is requested should The receiving node, when the Ethernet OAM Type is requested, should
look for the corresponding technology specific Ethernet OAM look for the corresponding technology specific Ethernet OAM
Configuration TLV. Configuration Sub-TLV.
3.3. Ethernet OAM Configuration TLV 3.3. Ethernet OAM Configuration Sub-TLV
The Ethernet OAM Configuration TLV (depicted below) is defined for The Ethernet OAM Configuration Sub-TLV (depicted below) is defined
Ethernet OAM specific configuration parameters. The Ethernet OAM for Ethernet OAM specific configuration parameters. The Ethernet OAM
Configuration TLV is carried within the OAM Configuration TLV in the Configuration Sub-TLV, when used, MUST be carried in the OAM
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRUIBUTES object in Path messages. Configuration TLV. This new sub-TLV accommodates Ethernet OAM
This new TLV accommodates Ethernet OAM information and carries sub- information and carries sub-TLVs.
TLVs.
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 (32) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.| Reserved (set to all 0s) | | Version |MD L.| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub TLVs ~ ~ sub TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the Ethernet OAM Configuration TLV. IANA Type: indicates a new type: the Ethernet OAM Configuration Sub-TLV.
is requested to assigne a value from the "OAM Type sub-TLV" space in IANA is requested to assign a value (32) from the "Sub-TLV" space in
the "RSVP-TE OAM Configuration Registry". the "RSVP-TE OAM Configuration Registry".
Length: indicates the total length including sub-TLVs. Length: indicates the total length including sub-TLVs.
Version: identifies the CFM protocol version according to [IEEE]. If Version: identifies the CFM protocol version according to
a node does not support a specific CFM version an error must be [IEEE.802.1Q-2011]. If a node does not support a specific CFM
generated: "OAM Problem/Unsupported OAM Version" version an error MUST be generated: "OAM Problem/Unsupported OAM
Version"
MD L. (MD Level): indicates the desired MD Level. Posible values are MD L. (MD Level): indicates the desired MD Level. Possible values
defined according to [IEEE]. If a node does not support a specific are defined according to [IEEE.802.1Q-2011]. If a node does not
MD Level an error must be generated: "OAM Problem/Unsupported OAM support a specific MD Level an error MUST be generated: "OAM Problem/
Level". Unsupported MD Level".
3.3.1. MD Name Sub-TLV 3.3.1. MD Name Sub-TLV
The optional MD Name sub-TLV is depicted below. The optional MD Name Sub-TLV is depicted below, it MAY be used for MD
naming.
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) | Length | | Type (1) (IANA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) | | Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MD Name ~ ~ MD Name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1, MD Name Sub-TLV. Type: 1, MD Name Sub-TLV. IANA is requested to maintain an Ethernet
TLV Type space in the "RSVP-TE OAM Configuration Registry" for the
sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding.
Format: according to [IEEE]. Format: according to [IEEE.802.1Q-2011].
Name Length: the length of the MD Name field in bytes. This is Name Length: the length of the MD Name field in bytes. This is
necessary to allow non 4 byte padded MD Name lengths. necessary to allow non 4 byte padded MD Name lengths.
MD Name: variable length field, formatted according to the format MD Name: variable length field, formatted according to the format
specified in the Format field. specified in the Format field.
If an undefined Format is specified an error must be generated: "OAM If an undefined Format is specified an error MUST be generated: "OAM
Problem/Unknown MD Name Format". Also the combined length of MD Name Problem/Unknown MD Name Format". Also the combined length of MD Name
and Short MA Name must be less or equal to 44bytes, if this is and Short MA Name MUST be less or equal to 44bytes, if this is
violated an error must be generated: "OAM Problem/Name Length violated an error MUST be generated: "OAM Problem/Name Length
Problem". Note it is allowed to have no MD Name, therefore the MD Problem". Note it is allowed to have no MD Name, therefore the MD
Name sub-TLV is optional. In this case the MA Name must uniquely Name Sub-TLV is optional. In this case the MA Name must uniquely
identify a Maintenance Association. identify a Maintenance Association.
3.3.2. Short MA Name Sub-TLV 3.3.2. Short MA Name Sub-TLV
The Short MA Name sub-TLV is depicted below. The Short MA Name Sub-TLV is depicted below, this sub-TLV MUST be
present in the Ethernet OAM Configuration Sub-TLV.
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) | Length | | Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) | | Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Short MA Name ~ ~ Short MA Name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2, Short MA Name Sub-TLV. Type: 2, Short MA Name Sub-TLV. IANA is requested to maintain an
Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry"
for the sub-TLV types carried in the Ethernet OAM Configuration Sub-
TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding.
Format: according to [IEEE]. Format: according to [IEEE.802.1Q-2011].
Name Length: the length of the MA Name field in bytes. This is Name Length: the length of the MA Name field in bytes. This is
necessary to allow non 4 byte padded MA Name lengths. necessary to allow non 4 byte padded MA Name lengths.
Short MA Name: variable length field formatted according to the Short MA Name: variable length field formatted according to the
format specified in the Format field. format specified in the Format field.
If an undefined Format is specified an error must be generated: "OAM If an undefined Format is specified an error MUST be generated: "OAM
Problem/Unknown MA Name Format". Also the combined length of MD Name Problem/Unknown MA Name Format". Also the combined length of MD Name
and Short MA Name must be less or equal to 44bytes, if this is and Short MA Name MUST be less or equal to 44bytes, if this is
violated an error must be generated: "OAM Problem/Name Length violated an error MUST be generated: "OAM Problem/Name Length
Problem". Note it is allowed to have no MD Name, in this case the MA Problem". Note it is allowed to have no MD Name, in this case the MA
Name must uniquely identify a Maintenance Association. Name MUST uniquely identify a Maintenance Association.
3.3.3. MEP ID Sub-TLV 3.3.3. MEP ID Sub-TLV
The MEP ID Sub-TLV is depicted below. The MEP ID Sub-TLV is depicted below, this sub-TLV MUST be present in
the Ethernet OAM Configuration Sub-TLV.
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) | Length (4) | | Type (3) (IANA) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local MEP ID |T|R| Reserved | | Local MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MEP ID |T|R| Reserved | | Remote MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3, MEP ID Sub-TLV. Type: 3, MEP ID Sub-TLV. IANA is requested to maintain an Ethernet
TLV Type space in the "RSVP-TE OAM Configuration Registry" for the
sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding.
Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP
ID on the initiator side. ID on the initiator side.
Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP
ID to be set for the MEP established at the receiving side. This ID to be set for the MEP established at the receiving side. This
value is determined by the initiator node. This is possible, since a value is determined by the initiator node. This is possible, since a
new MAID is assigned to each PBB-TE connection, and MEP IDs must be new MAID is assigned to each PBB-TE connection, and MEP IDs must be
only unique within the scope of the MAID. only unique within the scope of the MAID.
Two flags are defined Transmit (T) and Receive (R). When T is set Two flags are defined Transmit (T) and Receive (R). When T is set
the corresponding MEP must send OAM packets. When R is set the the corresponding MEP MUST send OAM packets. When R is set the
corresponding MEP must expect to receive OAM packets. These flags corresponding MEP MUST expect to receive OAM packets. These flags
are used to configure the role of MEPs. are used to configure the role of MEPs.
3.3.4. Continuity Check (CC) Sub-TLV 3.3.4. Continuity Check (CC) Sub-TLV
The Continuity Check (CC) sub-TLV is depicted below. The Continuity Check (CC) Sub-TLV is depicted below, this sub-TLV
MUST be present in the Ethernet OAM Configuration Sub-TLV.
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 (4) | Length | | Type (4) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) | | Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4, Continuity Check (CC) sub-TLV. Type: 4, Continuity Check (CC) Sub-TLV. IANA is requested to
maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration
Registry" for the sub-TLV types carried in the Ethernet OAM
Configuration Sub-TLV.
Prio: Indicates the priority to be set for CCM frames. In Ethernet 3 Prio: Indicates the priority to be set for CCM frames. In Ethernet,
bits carried in VLAN TAGs identify priority information. 3 bits carried in VLAN TAGs identify priority information. Setting
the priority is optional, all zeros will result in the use of default
values as defind in the network nodes.
CCM I (CCM Interval): CCM Interval, according to the 3 bit encoding CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3
[IEEE] shown in Table 1. If a node does not support the requested bit encoding [IEEE.802.1Q-2011] shown in Table 1. If a node does not
CCM Interval an error must be generated: "OAM Problem/Unsupported CC support the requested CCM Interval an error MUST be generated: "OAM
Interval". Problem/Unsupported CC Interval".
3.4. Pro-active Performance Monitoring 3.4. Pro-active Performance Monitoring
Ethernet OAM functions for Performance Monitoring (PM) allow Ethernet OAM functions for Performance Monitoring (PM) allow
measurements of different performance parameters including Frame Loss measurements of different performance parameters including Frame Loss
Ratio, Frame Delay and Frame Delay variation as defined in the ITU-T Ratio, Frame Delay and Frame Delay variation as defined in
Y.1731 recommendation. Only a subset of PM functions are operated in [ITU-T.Y.1731-2011]. Only a subset of PM functions are operated in a
a pro-active fashion to monitor the performance of the connection pro-active fashion to monitor the performance of the connection
continuously. Pro-active PM supports Fault Management functions, by continuously. Pro-active PM supports Fault Management functions, by
providing an indication of decreased service performance and as such providing an indication of decreased service performance and as such
may provide triggers to initiate recovery procedures. may provide triggers to initiate recovery procedures.
While on demand PM functions are always initiated by management While on demand PM functions are, for the purposes of this document,
commands, for pro-active PM it may be desirable to utilize the always initiated by management commands, for pro-active PM, it may be
control plane for configuration and activation together with Fault desirable to utilize the control plane for configuration and
Management functions such as Continuity Check. activation together with Fault Management functions such as the
Continuity Check.
ITU-T Y.1731 defines dual-ended Loss Measurement as pro-active OAM [ITU-T.Y.1731-2011] defines dual-ended Loss Measurement as pro-active
for performance monitoring and as a PM function applicable to fault OAM for performance monitoring and as a PM function applicable to
management. For dual-ended Loss Measurement each MEP piggy-backs fault management. For dual-ended Loss Measurement each MEP piggy-
transmitted and received frame counters on CC messages; to support backs transmitted and received frame counters on CC messages; to
and synchronize bidirectional Loss Measurements at the MEPs. Dual- support and synchronize bidirectional Loss Measurements at the MEPs.
ended Loss Measurement is invoked by setting the Performance Dual-ended Loss Measurement is supported by setting the Performance
Monitoring/Loss OAM Function Flag in the OAM Function Flags Sub-TLV Monitoring/Loss OAM Function Flag and the Continuity Check Flag in
[OAM-CONF-FWK]. Besides configuring the Continuity Check the OAM Function Flags Sub-TLV [OAM-CONF-FWK], and configuring the
functionality, no additional configuration is required for this type Continuity Check functionality by including the Ethernet OAM
of Loss Measurement. Configuration Sub-TLV. No additional configuration is required for
this type of Loss Measurement.
3.5. Ethernet OAM configuration errors 3.5. Summary of Ethernet OAM configuration errors
In addition to error values specified in [OAM-CONF-FWK] this document In addition to error values specified in [OAM-CONF-FWK] this document
defines the following values for the "OAM Problem" Error Code. defines the following values for the "OAM Problem" Error Code.
o If a node does not support a specific CFM version an error must be o If a node does not support a specific CFM version, an error MUST
generated: "OAM Problem/Unsupported OAM Version". be generated: "OAM Problem/Unsupported OAM Version".
o If a node does not support a specific MD Level an error must be o If a node does not support a specific MD Level, an error MUST be
generated: "OAM Problem/Unsupported OAM Level". generated: "OAM Problem/Unsupported MD Level".
o If an undefined MD name format is specified an error must be o If an undefined MD name format is specified, an error MUST be
generated: "OAM Problem/Unknown MD Name Format". generated: "OAM Problem/Unknown MD Name Format".
o If an undefined MA name format is specified an error must be o If an undefined MA name format is specified, an error MUST be
generated: "OAM Problem/Unknown MA Name Format". generated: "OAM Problem/Unknown MA Name Format".
o If the combined length of MD Name and Short MA Name must be less o The combined length of MD Name and Short MA Name must be less or
or equal to 44bytes, if this is violated an error must be equal to 44bytes, if this is violated an error MUST be generated:
generated: "OAM Problem/Name Length Problem". "OAM Problem/Name Length Problem".
o If a node does not support the requested CCM Interval an error o If a node does not support the requested CCM Interval, an error
must be generated: "OAM Problem/Unsupported CC Interval". MUST be generated: "OAM Problem/Unsupported CC Interval".
4. IANA Considerations 4. IANA Considerations
This document specifies the Ethernet OAM Configuration sub-TLV to be This document specifies the Ethernet OAM Configuration Sub-TLV to be
carried in the OAM Configuration TLV in LSP_ATTRIBUTES and carried in the OAM Configuration TLV in LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES objects in Path messages. LSP_REQUIRED_ATTRIBUTES objects in Path and Resv messages.
IANA is requested to allocate the value 1 for Ethernet OAM from the IANA is requested to allocate the value 1 for Ethernet OAM from the
OAM Type space in the "RSVP-TE OAM Configuration Registry" and OAM Type space in the "RSVP-TE OAM Configuration Registry" and
allocate type 1 for the Ethernet OAM Configuration sub-TLV from the allocate type 32 for the Ethernet OAM Configuration Sub-TLV from the
OAM Type sub-TLV space in the "RSVP-TE OAM Configuration Registry". Sub-TLV space in the "RSVP-TE OAM Configuration Registry".
The following values need to be assigned under the Error Code: "OAM RSVP-TE OAM Configuration Registry
Problem": "Unsupported OAM Version", "Unsupported OAM Level",
OAM Type Description
------------ ------------------
1 Ethernet OAM
Sub-TLV Type Description
------------ ------------------------------------
32 Ethernet OAM Configuration Sub-TLV
IANA is requested to maintain an Ethernet TLV Type space in the
"RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in
the Ethernet OAM Configuration Sub-TLV. This document defines the
following types.
Ethernet TLV Type Description
----------------- ------------------------------------
0 Reserved
1 MD Name Sub-TLV
2 Short MA Name Sub-TLV
3 MEP ID Sub-TLV
4 Continutiy Check Sub-TLV
5- Reserved
The following values need to be assigned under the "OAM Problem"
Error Code: "Unsupported OAM Version", "Unsupported MD Level",
"Unknown MD Name Format", "Unknown MA Name Format", "Name Length "Unknown MD Name Format", "Unknown MA Name Format", "Name Length
Problem", "Unsupported CC Interval". Problem", "Unsupported CC Interval".
5. Security Considerations 5. Security Considerations
This document does not introduce any additional security issuse to This document does not introduce any additional security issue to
those discussed in [OAM-CONF-FWK]. those discussed in [OAM-CONF-FWK] and [RFC6060].
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel, The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments. comments.
Contributors Contributors
Don Fedyk - Don Fedyk
Alcatel-Lucent - Dinesh Mohan
Groton, MA 01450
USA
Email: donald.fedyk@alcatel-lucent.com
Dinesh Mohan
7. References 7. References
7.1. Normative References 7.1. Normative References
[IEEE.802.1Q-2011]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[OAM-CONF-FWK] [OAM-CONF-FWK]
"OAM Configuration Framework for GMPLS RSVP-TE", Internet "OAM Configuration Framework for GMPLS RSVP-TE", Internet
Draft, work in progress. Draft, work in progress.
[RFC5828] "GMPLS Ethernet Label Switching Architecture and [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Framework", RFC 5828, March 2010. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6060] "Generalized Multiprotocol Label Switching (GMPLS) Control [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering of Ethernet Provider Backbone Traffic Engineering
(PBB-TE)", RFC 6060. (PBB-TE)", RFC 6060, March 2011.
7.2. Informative References 7.2. Informative References
[IEEE] "IEEE, "IEEE Standard for Local and metropolitan area [ITU-T.Y.1731-2011]
networks -- Media Access Control (MAC) Bridges and Virtual ITU, "ITU-T Recommendation Y.1731: OAM functions and
Bridged Local Area Networks", IEEE Std 802.1Q, 2011.". mechanisms for Ethernet based networks", ITU-T
Recommendation Y.1731, 2011.
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized
Multiprotocol Label Switching (GMPLS) Ethernet Label
Switching Architecture and Framework", RFC 5828,
March 2010.
Authors' Addresses Authors' Addresses
Attila Takacs Attila Takacs
Ericsson Ericsson
Konyves Kalman krt. 11. Konyves Kalman krt. 11.
Budapest, 1097 Budapest, 1097
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
Balazs Gero Balazs Peter Gero
Ericsson Ericsson
Laborc u. 1. Konyves Kalman krt. 11.
Budapest, 1037 Budapest, 1097
Hungary Hungary
Email: balazs.gero@ericsson.com Email: balazs.peter.gero@ericsson.com
Hao Long Hao Long
Huawei Huawei
Email: lonho@huawei.com Email: lonho@huawei.com
 End of changes. 97 change blocks. 
190 lines changed or deleted 258 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/