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