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/ |