draft-ietf-ccamp-rsvp-te-eth-oam-ext-13.txt   rfc7369.txt 
Network Working Group A. Takacs Internet Engineering Task Force (IETF) A. Takacs
Internet-Draft B. Gero Request for Comments: 7369 B. Gero
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: January 23, 2015 H. Long ISSN: 2070-1721 H. Long
Huawei Huawei
July 22, 2014 October 2014
GMPLS RSVP-TE Extensions for Ethernet OAM Configuration GMPLS RSVP-TE Extensions for Ethernet
draft-ietf-ccamp-rsvp-te-eth-oam-ext-13 Operations, Administration, and Maintenance (OAM) Configuration
Abstract Abstract
The GMPLS controlled Ethernet Label Switching (GELS) work extended The work related to GMPLS Ethernet Label Switching (GELS) extended
GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE GMPLS RSVP-TE to support the establishment of Ethernet Label
Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management
flow to check connectivity in Ethernet networks. CFM can be also (CFM) specifies an adjunct Operations, Administration, and
used with Ethernet LSPs for fault detection and triggering recovery Maintenance (OAM) flow to check connectivity in Ethernet networks.
mechanisms. The ITU-T Y.1731 specification builds on CFM and CFM can also be used with Ethernet LSPs for fault detection and
specifies additional OAM mechanisms, including Performance triggering recovery mechanisms. The ITU-T Y.1731 specification
Monitoring, for Ethernet networks. This document specifies builds on CFM and specifies additional OAM mechanisms, including
extensions of GMPLS RSVP-TE protocol to support the setup of the Performance Monitoring, for Ethernet networks. This document
associated Ethernet OAM entities of Ethernet LSPs, and defines the specifies extensions of the GMPLS RSVP-TE protocol to support the
Ethernet technology specific TLVs based on the GMPLS OAM setup of the associated Ethernet OAM entities of Ethernet LSPs and
defines the Ethernet technology-specific TLVs based on the GMPLS OAM
Configuration Framework. This document supports, but does not Configuration Framework. This document supports, but does not
modify, the IEEE and ITU-T OAM mechanisms. modify, the IEEE and ITU-T OAM mechanisms.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7369.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Ethernet OAM operation . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of Ethernet OAM Operation . . . . . . . . . . . . . 3
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5
3.1. Operation overview . . . . . . . . . . . . . . . . . . . 5 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 5
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7 3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 8 3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 8
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 8 3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 9
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 9 3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 10
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 10 3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 11
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 11 3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12
3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 12 3.4. Proactive Performance Monitoring . . . . . . . . . . . . 12
3.5. Summary of Ethernet OAM configuration errors . . . . . . 13 3.5. Summary of Ethernet OAM Configuration Errors . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 13 4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 14
4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 14 4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 15
4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 14 4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Background 1. Background
Provider Backbone Bridging - Traffic Engineering (PBB-TE) Provider Backbone Bridging - Traffic Engineering (PBB-TE)
[IEEE.802.1Q-2011] decouples the Ethernet data and control planes, [IEEE.802.1Q-2011] decouples the Ethernet data and control planes and
and allows external control and management mechanisms to create allows external control and management mechanisms to create
explicitly routed Ethernet connections. In addition, PBB-TE defines explicitly routed Ethernet connections. In addition, PBB-TE defines
mechanisms for protection switching of bidirectional Ethernet mechanisms for protection switching of bidirectional Ethernet
connections. Ethernet Connectivity Fault Management (CFM) defines an connections. Ethernet Connectivity Fault Management (CFM) defines an
adjunct connectivity monitoring OAM flow to check the liveliness of adjunct connectivity-monitoring OAM flow to check the liveliness of
Ethernet networks [IEEE.802.1Q-2011], including the monitoring of Ethernet networks [IEEE.802.1Q-2011], including the monitoring of
specific explicitly routed Ethernet connections. The ITU-T specific explicitly routed Ethernet connections. The ITU-T
Recommendation Y.1731 [ITU-T.Y.1731-2011] extended CFM and specified Recommendation Y.1731 [ITU-T.G.8013-2013] extended CFM and specified
additional OAM functionality. additional OAM functionality.
In IETF, the GMPLS controlled Ethernet Label Switching (GELS) work In the IETF, the work related to GMPLS Ethernet Label Switching
extended the GMPLS control plane to support the establishment of (GELS) extended the GMPLS control plane to support the establishment
explicitly routed Ethernet connections [RFC5828][RFC6060]. We refer of explicitly routed Ethernet connections [RFC5828] [RFC6060]. We
to GMPLS established Ethernet connections as Ethernet LSPs. GELS refer to GMPLS-established Ethernet connections as "Ethernet LSPs".
enables the application of MPLS-TE and GMPLS provisioning and GELS 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 The use of GMPLS RSVP-TE to support the establishment and
configuration of OAM entities with LSP signaling is defined in a configuration of OAM entities with LSP signaling is defined in a
technology agnostic way in [RFC7260]. The purpose of this document technology-agnostic way in [RFC7260]. The purpose of this document
is to specify the additional technology specific OAM entities to is to specify the additional technology-specific OAM entities to
support Ethernet connections. support Ethernet connections.
2. Overview of Ethernet OAM operation 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Overview of Ethernet OAM Operation
For the purposes of this document, we only discuss Ethernet OAM For the purposes of this document, we only discuss Ethernet OAM
aspects that are relevant for proactive connectivity monitoring of aspects that are relevant for proactive connectivity monitoring of
Ethernet LSPs. On-demand OAM functions for the purposes of this Ethernet LSPs and assume that on-demand OAM functions will be
document will be supported by Management Plane operations. supported by management-plane operations.
PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as a PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) 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 bidirectional PBB-TE connection, two co-routed point-to-point ESPs
are combined. The combined ESPs must have the same ESP-MAC addresses are combined. The combined ESPs must have the same ESP-MAC addresses
but may have different ESP-VIDs. The formed co-routed bidirectional but may have different ESP-VIDs. The formed co-routed bidirectional
path is a path where the forward and backward directions follow the path is a path where the forward and backward directions follow the
same route (links and nodes) across the network. same route (links and nodes) across the network.
Note that although it would be possible to use GMPLS to setup a Note that although it would be possible to use GMPLS to set up a
single unidirectional ESP, the Ethernet OAM mechanisms are only fully 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. Therefore, 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 Entity Group End Point (MEP) is configured. The MEPs
PBB-TE connection must be configured with the same Maintenance Domain monitoring a PBB-TE connection must be configured with the same
Level (MD Level) and Maintenance Association Identifier (MAID). Each Maintenance Domain Level (MD Level) and Maintenance Association
MEP has a unique identifier, the MEP ID. Besides these identifiers, Identifier (MAID). Each MEP has a unique identifier, the MEP ID.
a MEP monitoring a PBB-TE connection must be provisioned with the Besides these identifiers, a MEP monitoring a PBB-TE connection must
3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs. be provisioned with the 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 fixed intervals. Eight distinct intervals are defined in
[IEEE.802.1Q-2011]: [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 |
| | | | | | | |
| 3 | 100 ms | 011 | | 3 | 100 ms | 011 |
| | | | | | | |
| 4 | 1 s | 100 | | 4 | 1 s | 100 |
| | | | | | | |
| 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 three consecutive CCMs are lost, connectivity failure is declared.
The MEP detecting the failure will signal the defect to the remote
If 3 consecutive CCM messages are lost; connectivity failure is MEP in the subsequent CCMs it emits by setting the Remote Defect
declared. The MEP detecting the failure will signal the defect to Indicator (RDI) bit in the CCM. If a MEP receives a CCM with the RDI
the remote MEP in the subsequent CCM messages it emits, by setting bit set, it immediately declares failure. The detection of a failure
the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP may trigger protection switching mechanisms or may be signaled to a
receives a CCM message with RDI bit set it immediately declares management system.
failure. The detection of a failure may trigger protection switching
mechanisms or may be signaled to a management system.
At each transit node, Maintenance Intermediate Points (MIPs) may be At each transit node, Maintenance Entity Group Intermediate Points
established to help failure localization, e.g., using link trace and (MIPs) may be established to help failure localization, e.g., using
loop back functions. MIPs need to be provisioned with a subset of link trace and loopback functions. MIPs need to be provisioned with
the MEP identification parameters described above. a subset of 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, the
Ethernet LSP is signaled, the associated MEPs should be automatically associated MEPs should be automatically established when an Ethernet
established. To monitor an Ethernet LSP, a set of parameters must be LSP is signaled. To monitor an Ethernet LSP, a set of parameters
provided to setup a Maintenance Association and related MEPs. must be provided to set up a Maintenance Association and related
Optionally, MIPs may be created at the transit nodes of the Ethernet MEPs. Optionally, MIPs may be created at the transit nodes of the
LSP. The LSP Attribute Flags: "OAM MEP entities desired" and "OAM Ethernet LSP. The LSP Attribute Flags "OAM MEP entities desired" and
MIP entities desired", as described in [RFC7260], are used to signal "OAM MIP entities desired", as described in [RFC7260], are used to
that the respective OAM entities must be established. An OAM signal that the respective OAM entities must be established. An OAM
Configuration TLV, as described in [RFC7260], is added to the Configuration TLV, as described in [RFC7260], is added to the
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects specifying that LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects specifying that
Ethernet OAM is to be setup for the LSP. Ethernet OAM specific Ethernet OAM is to be set up for the LSP. Information specific to
information, as described below, is carried in the new Ethernet OAM Ethernet OAM, as described below, is carried in the new Ethernet OAM
Configuration Sub-TLV (see Section 3.3) within the OAM Configuration Configuration Sub-TLV (see Section 3.3) within the OAM Configuration
TLV. 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
MEPs must be configured with the same information. The MAID both 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.802.1Q-2011]. Since this information is also carried in all [IEEE.802.1Q-2011]. Since this information is also carried in all
CCM messages, the combined length of the Names is limited to 44 CCMs, the combined length of the MD Name and Short MA Name is
bytes, see [IEEE.802.1Q-2011] for the details of the message limited to 44 bytes (see [IEEE.802.1Q-2011] for the details of the
format. How these parameters are determined is out of scope of message format). How these parameters are determined is out of
this document. the scope of 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 the scope of
document. this document.
o The Maintenance Domain Level (MD Level) allows hierarchical o The Maintenance Domain Level (MD Level) allows hierarchical
separation of monitoring entities. [IEEE.802.1Q-2011] allows separation of monitoring entities. [IEEE.802.1Q-2011] allows
differentiation of 8 levels. How the value of the MD Level is differentiation of eight levels. How the value of the MD Level is
determined is out of scope of this document. Note that probably determined is out of the scope of this document. Note that
for all Ethernet LSPs a single (default) MD Level will be used probably for all Ethernet LSPs, a single (default) MD Level will
within a network domain. be used 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 the 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 may be specified. The same CCM priority must be set in frames may 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 the scope of this document. Note
that the highest priority should be used as the default CCM that the highest priority should be used as the default CCM
priority. priority.
o MEPs must be aware of the reachability parameters of their own and o MEPs must be aware of their own reachability parameters and those
that of the remote MEP. In the case of bidirectional point-to- of the remote MEP. In the case of bidirectional point-to-point
point PBB-TE connections, this requires that the 3-tuples [ESP-MAC PBB-TE connections, this requires that the 3-tuples [ESP-MAC A,
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 Media Access Control (MAC) address and ESP-MAC B is
MAC address. The GMPLS Ethernet Label format, as defined in the same as the remote MEP's MAC address. The GMPLS Ethernet
[RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence the Label format, as defined in [RFC6060], consists of the ESP-MAC DA
necessary reachability parameters for the MEPs can be obtained and ESP-VID. Hence, the necessary reachability parameters for the
from the Ethernet Labels (i.e., carried in the downstream and MEPs can be obtained from the Ethernet Labels (i.e., carried in
upstream labels). In the case of point-to-point VLAN connections, the downstream and upstream labels). In the case of point-to-
MEPs need to be provisioned with the VLAN identifiers only, which point VLAN connections, MEPs need to be provisioned with the VLAN
can be derived similarly from the Ethernet Labels. identifiers only, which can be derived similarly from the Ethernet
Labels.
Based on the procedures described in [RFC6060] for bidirectional PBB- Based on the procedures described in [RFC6060] for bidirectional PBB-
TE Ethernet LSP establishment, the Ethernet OAM configuration TE Ethernet LSP establishment, the Ethernet OAM configuration
procedures are as follows: procedures are as follows.
When the RSVP-TE signaling is initiated for the bidirectional When the RSVP-TE signaling is initiated for the bidirectional
Ethernet LSP the local node generates a Path message and: 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 MUST include the OAM Configuration TLV with OAM Type set to o MUST include the OAM Configuration TLV with OAM Type set to
Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
Object; objects;
o MUST include the OAM Function Flags Sub-TLV in the OAM o MUST include the OAM Function Flags Sub-TLV in the OAM
Configuration TLV and set the OAM function flags as needed; Configuration TLV and set the OAM function flags as needed;
o MUST include 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 MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name
Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, that Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV,
will unambiguously identify a Maintenance Association for this which will unambiguously identify a Maintenance Association for
specific PBB-TE connection. Note that values for these parameters this specific PBB-TE connection. Note that values for these
may be derived from the GMPLS LSP identification parameters; parameters may be derived from the GMPLS LSP identification
parameters; and
o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration
Sub-TLV and select two distinct integer values to identify the Sub-TLV and select two distinct integer values to identify the
local and remote MEPs within the Maintenance Association created local and remote MEPs within the Maintenance Association created
for 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 end Once the Resv message successfully arrives to the initiator, this end
can 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 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 [RFC7260] and is used to select which OAM This TLV is specified in [RFC7260] and is used to select which OAM
technology/method should be used for the LSP. In this document, a technology/method should be used for the LSP. In this document, a
new OAM Type: Ethernet OAM is defined. IANA is requested to allocate new OAM Type, Ethernet OAM, is defined. IANA has allocated OAM Type
OAM Type 1 for Ethernet OAM in the RSVP-TE OAM Configuration 1 for Ethernet OAM in the "RSVP-TE OAM Configuration Registry".
Registry.
RSVP-TE OAM Configuration Registry RSVP-TE OAM Configuration Registry
OAM Type Description OAM Type Description
------------ ------------------ ------------ ------------------
TBA1 Ethernet OAM 1 Ethernet OAM
The receiving node, when the Ethernet OAM Type is requested, should When the Ethernet OAM Type is requested, the receiving node should
look for the corresponding technology specific Ethernet OAM look for the corresponding technology-specific Ethernet OAM
Configuration Sub-TLV. Configuration Sub-TLV.
3.3. Ethernet OAM Configuration Sub-TLV 3.3. Ethernet OAM Configuration Sub-TLV
The Ethernet OAM Configuration Sub-TLV (depicted below) is defined The Ethernet OAM Configuration Sub-TLV (depicted below) is defined
for Ethernet OAM specific configuration parameters. The Ethernet OAM for configuration parameters specific to Ethernet OAM. The Ethernet
Configuration Sub-TLV, when used, MUST be carried in the OAM OAM Configuration Sub-TLV, when used, MUST be carried in the OAM
Configuration TLV. This new sub-TLV accommodates Ethernet OAM Configuration TLV. This new sub-TLV accommodates Ethernet OAM
information and carries sub-TLVs. information and carries sub-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 (TBA2) (IANA) | Length | | Type 32 | 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 Sub-TLV. Type: Indicates a new type, the Ethernet OAM Configuration Sub-TLV.
IANA is requested to assign a value from the "Sub-TLV" space in the IANA has assigned the value 32 from the "OAM Sub-TLVs" space in the
"RSVP-TE OAM Configuration Registry". "RSVP-TE OAM Configuration Registry".
Length: indicates the total length of the TLV including padding and Length: Indicates the total length of the TLV including padding and
including the Type and Length fields. including the Type and Length fields.
Version: identifies the CFM protocol version according to Version: Identifies the CFM protocol version according to
[IEEE.802.1Q-2011]. If a node does not support a specific CFM [IEEE.802.1Q-2011]. If a node does not support a specific CFM
version an error MUST be generated: "OAM Problem/Unsupported OAM version, an error MUST be generated: "OAM Problem/Unsupported OAM
Version" Version".
MD L. (MD Level): indicates the desired MD Level. Possible values MD L. (MD Level): Indicates the desired MD Level. Possible values
are defined according to [IEEE.802.1Q-2011]. If a node does not are defined according to [IEEE.802.1Q-2011]. If a node does not
support a specific MD Level an error MUST be generated: "OAM Problem/ support a specific MD Level, an error MUST be generated: "OAM
Unsupported MD Level". Problem/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, it MAY be used for MD The optional MD Name Sub-TLV is depicted below. It MAY be used for
naming. 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) (IANA) | Length | | Type (1) | 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. IANA is requested to maintain an Ethernet Type: 1, MD Name Sub-TLV. IANA will maintain an Ethernet TLV Type
TLV Type space in the "RSVP-TE OAM Configuration Registry" for the space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV
sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. types carried in the Ethernet OAM Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding and Length: Indicates the total length of the TLV, including padding and
including the Type and Length fields. the Type and Length fields.
Format: according to [IEEE.802.1Q-2011]. 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
and Short MA Name MUST be less or equal to 44bytes, if this is Name and Short MA Name MUST be less than or equal to 44 bytes. If
violated an error MUST be generated: "OAM Problem/Name Length this is violated, an error MUST be generated: "OAM Problem/Name
Problem". Note it is allowed to have no MD Name, therefore the MD Length Problem". Note that it is allowed to have no MD Name;
Name Sub-TLV is optional. In this case the MA Name must uniquely therefore, the MD Name Sub-TLV is optional. In this case, the MA
identify a Maintenance Association. Name must uniquely 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. This sub-TLV MUST be The Short MA Name Sub-TLV is depicted below. This sub-TLV MUST be
present in the Ethernet OAM Configuration Sub-TLV. 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) (IANA) | Length | | Type (2) | 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. IANA is requested to maintain an Type: 2, Short MA Name Sub-TLV. IANA will maintain an Ethernet TLV
Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" Type space in the "RSVP-TE OAM Configuration Registry" for the sub-
for the sub-TLV types carried in the Ethernet OAM Configuration Sub- TLV types carried in the Ethernet OAM Configuration Sub-TLV.
TLV.
Length: indicates the total length of the TLV including padding and Length: Indicates the total length of the TLV, including padding and
including the Type and Length fields. the Type and Length fields.
Format: according to [IEEE.802.1Q-2011]. 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 Short 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
and Short MA Name MUST be less or equal to 44bytes, if this is Name and Short MA Name MUST be less than or equal to 44 bytes. If
violated an error MUST be generated: "OAM Problem/Name Length this is violated, an error MUST be generated: "OAM Problem/Name
Problem". Note it is allowed to have no MD Name, in this case the MA Length Problem". Note that it is allowed to have no MD Name; in this
Name MUST uniquely identify a Maintenance Association. case, the MA 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. This sub-TLV MUST be present The MEP ID Sub-TLV is depicted below. This sub-TLV MUST be present
in the Ethernet OAM Configuration Sub-TLV. 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) (IANA) | Length | | Type (3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. IANA is requested to maintain an Ethernet Type: 3, MEP ID Sub-TLV. IANA will maintain an Ethernet TLV Type
TLV Type space in the "RSVP-TE OAM Configuration Registry" for the space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV
sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. types carried in the Ethernet OAM Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding and Length: Indicates the total length of the TLV, including padding and
including the Type and Length fields. the Type and Length fields.
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. This sub-TLV The Continuity Check (CC) Sub-TLV is depicted below. This sub-TLV
MUST be present in the Ethernet OAM Configuration 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) (IANA) | Length | | Type (4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) | | Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4, Continuity Check (CC) Sub-TLV. IANA is requested to Type: 4, Continuity Check (CC) Sub-TLV. IANA will maintain an
maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry"
Registry" for the sub-TLV types carried in the Ethernet OAM for the sub-TLV types carried in the Ethernet OAM Configuration Sub-
Configuration Sub-TLV. TLV.
Length: indicates the total length of the TLV including padding and Length: Indicates the total length of the TLV, including padding and
including the Type and Length fields. the Type and Length fields.
Prio: Indicates the priority to be set for CCM frames. In Ethernet, Prio: Indicates the priority to be set for CCM frames. In Ethernet,
3 bits carried in VLAN TAGs identify priority information. Setting 3 bits carried in VLAN TAGs identify priority information. Setting
the priority is optional. If the most significant bit is set to the priority is optional. If the most significant bit is set to
zero, the subsequent 3 priority bits will be ignored, and priority zero, the subsequent 3 priority bits will be ignored, and priority
bits of the Ethernet CCM frame will be set based on default values bits of the Ethernet CCM frame will be set based on default values
specified in the Ethernet nodes. If the most significant bit is set specified in the Ethernet nodes. If the most significant bit is set
to 1, the subsequent 3 bits will be used to set the priority bits of to 1, the subsequent 3 bits will be used to set the priority bits of
the Ethernet CCM frame. the Ethernet CCM frame.
CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3 CCM I (CCM Interval): MUST be set according to the 3-bit encoding
bit encoding [IEEE.802.1Q-2011] shown in Table 1. As a consequence [IEEE.802.1Q-2011] shown in Table 1. As a consequence, the most
the most significant bit will be set to 0. Four bits are allocated significant bit will be set to 0. Four bits are allocated to support
to support the configuration of CCM intervals that may be specified the configuration of CCM Intervals that may be specified in the
in the future. If a node does not support the requested CCM Interval future. If a node does not support the requested CCM Interval, an
an error MUST be generated: "OAM Problem/Unsupported CC Interval". error MUST be generated: "OAM Problem/Unsupported CC Interval".
3.4. Pro-active Performance Monitoring 3.4. Proactive 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 Ratio, Frame Delay, and Frame Delay Variation as defined in
[ITU-T.Y.1731-2011]. Only a subset of PM functions are operated in a [ITU-T.G.8013-2013]. Only a subset of PM functions are operated in a
pro-active fashion to monitor the performance of the connection proactive fashion to monitor the performance of the connection
continuously. Pro-active PM supports Fault Management functions, by continuously. Proactive PM supports Fault Management functions by
providing an indication of decreased service performance and as such providing an indication of decreased service performance and
may provide triggers to initiate recovery procedures. therefore may provide triggers to initiate recovery procedures.
While on demand PM functions are, for the purposes of this document, While on-demand PM functions are, for the purposes of this document,
always initiated by management commands, for pro-active PM, it may be always initiated by management commands, for proactive PM, it may be
desirable to utilize the control plane for configuration and desirable to utilize the control plane for configuration and
activation together with Fault Management functions such as the activation together with Fault Management functions such as the
Continuity Check. Continuity Check.
[ITU-T.Y.1731-2011] defines dual-ended Loss Measurement as pro-active [ITU-T.G.8013-2013] defines dual-ended Loss Measurement as proactive
OAM for performance monitoring and as a PM function applicable to OAM for Performance Monitoring and as a PM function applicable to
fault management. For dual-ended Loss Measurement each MEP piggy- Fault Management. For dual-ended Loss Measurement, each MEP
backs transmitted and received frame counters on CC messages; to piggybacks transmitted and received frame counters on CC messages to
support and synchronize bidirectional Loss Measurements at the MEPs. support and synchronize bidirectional Loss Measurements at the MEPs.
Dual-ended Loss Measurement is supported by setting the Performance Dual-ended Loss Measurement is supported by setting the Performance
Monitoring/Loss OAM Function Flag and the Continuity Check Flag in Monitoring/Loss OAM Function Flag and the Continuity Check Flag in
the OAM Function Flags Sub-TLV [RFC7260], and configuring the the OAM Function Flags Sub-TLV [RFC7260] and configuring the
Continuity Check functionality by including the Ethernet OAM Continuity Check functionality by including the Ethernet OAM
Configuration Sub-TLV. No additional configuration is required for Configuration Sub-TLV. No additional configuration is required for
this type of Loss Measurement. this type of Loss Measurement.
3.5. Summary of Ethernet OAM configuration errors 3.5. Summary of Ethernet OAM Configuration Errors
In addition to error values specified in [RFC7260] this document In addition to the error values specified in [RFC7260], 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 o If a node does not support a specific CFM version, an error MUST
be 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 MD 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 The combined length of MD Name and Short MA Name must be less or o The combined length of MD Name and Short MA Name must be less than
equal to 44bytes, if this is violated an error MUST be generated: or equal to 44 bytes. If this is violated, an error MUST be
"OAM Problem/Name Length Problem". generated: "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
4.1. RSVP-TE OAM Configuration Registry 4.1. RSVP-TE OAM Configuration Registry
IANA maintains the "RSVP-TE OAM Configuration Registry". IANA is IANA maintains the "RSVP-TE OAM Configuration Registry". IANA has
requested to assign an "OAM Type" from this registry as follows. assigned an "OAM Type" from this registry as follows:
Allocate the value TBA1 for "Ethernet OAM" from the "OAM Type Sub-
Registry" of the "RSVP-TE OAM Configuration Registry". Allocate type
TBA2 for the "Ethernet OAM Configuration Sub-TLV" from the
technology-specific range of the "OAM Sub-TLVs Sub-Registry" of the
"RSVP-TE OAM Configuration Registry".
RSVP-TE OAM Configuration Registry o "Ethernet OAM" has been allocated type 1 from the "OAM Types" sub-
registry of the "RSVP-TE OAM Configuration Registry".
OAM Types Sub-Registry o "Ethernet OAM Configuration Sub-TLV" has been allocated type 32
from the technology-specific range of the "OAM Sub-TLVs" sub-
registry of the "RSVP-TE OAM Configuration Registry".
OAM Type Number | Description | Reference RSVP-TE OAM Configuration Registry
-------------------------------------------------
TBA1 | Ethernet OAM | [This.ID]
OAM Sub-TLVs Sub-Registry OAM Types
Sub-TLV Type | Description | Ref. OAM Type Number | Description | Reference
---------------------------------------------------------- -------------------------------------------
TBA2 |Ethernet OAM Configuration Sub-TLV|[This.ID] 1 | Ethernet OAM | [RFC7369]
The value of 1 is suggested for TBA1. The value of 32 is suggested OAM Sub-TLVs
for TBA2.
Sub-TLV Type | Description | Ref.
-----------------------------------------------------------
32 |Ethernet OAM Configuration Sub-TLV| [RFC7369]
4.2. Ethernet Sub-TLVs Sub-Registry 4.2. Ethernet Sub-TLVs Sub-Registry
IANA is requested to maintain an Ethernet Sub-TLVs Sub-Registry in IANA will maintain an "Ethernet Sub-TLVs Sub-Registry" in the "RSVP-
the "RSVP-TE OAM Configuration Registry" for the sub-TLV types TE OAM Configuration Registry" for the sub-TLV types carried in the
carried in the Ethernet OAM Configuration Sub-TLV. This document Ethernet OAM Configuration Sub-TLV. This document defines the
defines the following types. following types.
Ethernet Sub-TLVs Sub-Registry Ethernet Sub-TLVs Sub-Registry
Range | Registration Procedures Range | Registration Procedures
------------+---------------------------- ------------+--------------------------
0-65534 | IETF Review 0-65534 | IETF Review
65535-65536 | Experimental 65535 | Experimental
Sub-TLV Type | Description | Ref. Sub-TLV Type | Description | Ref.
--------------------------------------------------- ---------------------------------------------------------
0 | Reserved | [This.ID] 0 | Reserved | [RFC7369]
1 | MD Name Sub-TLV | [This.ID] 1 | MD Name Sub-TLV | [RFC7369]
2 | Short MA Name Sub-TLV | [This.ID] 2 | Short MA Name Sub-TLV | [RFC7369]
3 | MEP ID Sub-TLV | [This.ID] 3 | MEP ID Sub-TLV | [RFC7369]
4 | Continuity Check Sub-TLV | [This.ID] 4 | Continuity Check Sub-TLV | [RFC7369]
5-65536 | Unassigned | [This.ID] 5-65534 | Unassigned | [RFC7369]
65535 | Reserved for Experimental Use | [RFC7369]
4.3. RSVP Error Code 4.3. RSVP Error Code
IANA maintains an Error Code, "OAM Problem" in the "Error Codes and IANA maintains an Error Code, "OAM Problem", in the "Error Codes and
Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource
Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines
a set of Error Value sub-codes for the "OAM Problem" Error Code. a set of Error Value sub-codes for the "OAM Problem" Error Code.
This document defines additional Error Value sub-codes for the "OAM
This document defines additional Error Values sub-codes for the "OAM
Problem" Error Code as summarized below. Problem" Error Code as summarized below.
Value | Description | Reference Value | Description | Reference
-------+---------------------------+-------------- -------+---------------------------+-----------
TBA | Unsupported OAM Version | [This.ID] 7 | Unsupported OAM Version | [RFC7369]
TBA | Unsupported MD Level | [This.ID] 8 | Unsupported MD Level | [RFC7369]
TBA | Unknown MD Name Format | [This.ID] 9 | Unknown MD Name Format | [RFC7369]
TBA | Unknown MA Name Format | [This.ID] 10 | Unknown MA Name Format | [RFC7369]
TBA | Name Length Problem | [This.ID] 11 | Name Length Problem | [RFC7369]
TBA | Unsupported CC Interval | [This.ID] 12 | Unsupported CC Interval | [RFC7369]
5. Security Considerations 5. Security Considerations
This document does not introduce any additional security issue to This document does not introduce any additional security issues to
those discussed in [RFC7260] and [RFC6060]. those discussed in [RFC7260] and [RFC6060].
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 add a new establishment of OAM entities based on RSVP-TE messages add 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 targeted that element by sending frequent periodic messages attacker targeted that element by sending frequent periodic messages
requesting liveliness monitoring of a high number of LSPs. Such an requesting liveliness monitoring of a high number of LSPs. Such an
attack can efficiently be prevented when mechanisms for message attack can efficiently be prevented when mechanisms for message
integrity and node authentication are deployed. Since the OAM integrity and node authentication are deployed. Since the OAM
configuration extensions rely on the hop-by-hop exchange of exiting configuration extensions rely on the hop-by-hop exchange of exiting
RSVP-TE messages, procedures specified for RSVP message security in RSVP-TE messages, procedures specified for RSVP message security in
[RFC2747] can be used to mitigate possible attacks. [RFC2747] can be used to mitigate possible attacks.
For a more comprehensive discussion of GMPLS security and attack For a more comprehensive discussion of GMPLS security and attack
mitigation techniques, please see the Security Framework for MPLS and mitigation techniques, please see "Security Framework for MPLS and
GMPLS Networks [RFC5920]. GMPLS Networks" [RFC5920].
6. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments.
7. Contributors
- Don Fedyk, don.fedyk@hp.com
- Dinesh Mohan, dinmohan@hotmail.com
8. References 6. References
8.1. Normative References 6.1. Normative References
[IEEE.802.1Q-2011] [IEEE.802.1Q-2011]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual networks--Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2011. Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS) Control "Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering (PBB- of Ethernet Provider Backbone Traffic Engineering (PBB-
TE)", RFC 6060, March 2011. TE)", RFC 6060, March 2011,
<http://www.rfc-editor.org/info/rfc6060>.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, June 2014. (OAM) Configuration", RFC 7260, June 2014,
<http://www.rfc-editor.org/info/rfc7260>.
8.2. Informative References 6.2. Informative References
[ITU-T.Y.1731-2011] [ITU-T.G.8013-2013]
ITU, "ITU-T Recommendation Y.1731: OAM functions and International Telecommunications Union, "OAM functions and
mechanisms for Ethernet based networks", ITU-T mechanisms for Ethernet based networks", ITU-T
Recommendation Y.1731, 2011. Recommendation G.8013/Y.1731, November 2011.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000,
<http://www.rfc-editor.org/info/rfc2747>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized
Multiprotocol Label Switching (GMPLS) Ethernet Label Multiprotocol Label Switching (GMPLS) Ethernet Label
Switching Architecture and Framework", RFC 5828, March Switching Architecture and Framework", RFC 5828, March
2010. 2010, <http://www.rfc-editor.org/info/rfc5828>.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful
comments.
Contributors
Don Fedyk
EMail: don.fedyk@hp.com
Dinesh Mohan
EMail: dinmohan@hotmail.com
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 Peter Gero Balazs Peter Gero
Ericsson Ericsson
Konyves Kalman krt. 11. Konyves Kalman krt. 11.
Budapest 1097 Budapest 1097
Hungary Hungary
Email: balazs.peter.gero@ericsson.com EMail: balazs.peter.gero@ericsson.com
Hao Long Hao Long
Huawei Huawei
PR China China
Email: lonho@huawei.com EMail: lonho@huawei.com
 End of changes. 124 change blocks. 
311 lines changed or deleted 320 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/