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