Skip to main content

GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-11

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7369.
Authors Attila Takacs , Balazs Peter Gero, Hao Long
Last updated 2014-04-15 (Latest revision 2014-03-31)
Replaces draft-takacs-ccamp-rsvp-te-eth-oam-ext
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Deborah Brungard
Shepherd write-up Show Last changed 2014-02-09
IESG IESG state Became RFC 7369 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Adrian Farrel
Send notices to ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rsvp-te-eth-oam-ext@tools.ietf.org
IANA IANA review state IANA - Not OK
draft-ietf-ccamp-rsvp-te-eth-oam-ext-11
Network Working Group                                          A. Takacs
Internet-Draft                                                   B. Gero
Intended status: Standards Track                                Ericsson
Expires: September 2, 2014                                       H. Long
                                                                  Huawei
                                                              March 2014

        GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
                draft-ietf-ccamp-rsvp-te-eth-oam-ext-11

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 the GMPLS OAM
   Configuration Framework.  This document supports, but does not
   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

   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."

Takacs, et al.          Expires September 2, 2014               [Page 1]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   This Internet-Draft will expire on September 2, 2014.

Copyright Notice

   Copyright (c) 2014 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.

Table of Contents

   1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview of Ethernet OAM operation  . . . . . . . . . . . . .   3
   3.  GMPLS RSVP-TE Extensions  . . . . . . . . . . . . . . . . . .   5
     3.1.  Operation overview  . . . . . . . . . . . . . . . . . . .   5
     3.2.  OAM Configuration TLV . . . . . . . . . . . . . . . . . .   7
     3.3.  Ethernet OAM Configuration Sub-TLV  . . . . . . . . . . .   7
       3.3.1.  MD Name Sub-TLV . . . . . . . . . . . . . . . . . . .   8
       3.3.2.  Short MA Name Sub-TLV . . . . . . . . . . . . . . . .   9
       3.3.3.  MEP ID Sub-TLV  . . . . . . . . . . . . . . . . . . .  10
       3.3.4.  Continuity Check (CC) Sub-TLV . . . . . . . . . . . .  11
     3.4.  Pro-active Performance Monitoring . . . . . . . . . . . .  11
     3.5.  Summary of Ethernet OAM configuration errors  . . . . . .  12
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     4.1.  RSVP-TE OAM Configuration Registry  . . . . . . . . . . .  13
     4.2.  Ethernet Sub-TLVs Sub-Registry  . . . . . . . . . . . . .  13
     4.3.  RSVP Error Code . . . . . . . . . . . . . . . . . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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

Takacs, et al.          Expires September 2, 2014               [Page 2]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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.

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

Takacs, et al.          Expires September 2, 2014               [Page 3]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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]:

                +---+--------------------+----------------+
                | # | 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 September 2, 2014               [Page 4]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

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 September 2, 2014               [Page 5]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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 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 September 2, 2014               [Page 6]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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
     ------------      ------------------
         TBA1            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 September 2, 2014               [Page 7]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

    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 (TBA2) (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 from the "Sub-TLV" space in the
   "RSVP-TE OAM Configuration Registry".

   Length: indicates the total length of the TLV including padding and
   including the Type and Length fields.

   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                            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Takacs, et al.          Expires September 2, 2014               [Page 8]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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 and
   including the Type and Length fields.

   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 and
   including the Type and Length fields.

Takacs, et al.          Expires September 2, 2014               [Page 9]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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
   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              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        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 and
   including the Type and Length fields.

   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

Takacs, et al.          Expires September 2, 2014              [Page 10]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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.

    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.

   Length: indicates the total length of the TLV including padding and
   including the Type and Length fields.

   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.  If the most significant bit is set to
   zero, the subsequent 3 priority bits will be ignored, and priority
   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
   to 1, the subsequent 3 bits will be used to set the priority bits of
   the Ethernet CCM frame.

   CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3
   bit encoding [IEEE.802.1Q-2011] shown in Table 1.  As a consequence
   the most significant bit will be set to 0.  Four bits are allocated
   to support the configuration of CCM intervals that may be specified
   in the future.  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

Takacs, et al.          Expires September 2, 2014              [Page 11]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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
   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 September 2, 2014              [Page 12]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

4.  IANA Considerations

4.1.  RSVP-TE OAM Configuration Registry

   [OAM-CONF-FWK] includes a request for IANA to create the "RSVP-TE OAM
   Configuration Registry".  IANA is requested to assign 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

     OAM Types Sub-Registry

       OAM Type Number | Description  | Reference
     -------------------------------------------------
             TBA1      | Ethernet OAM | [This.ID]

      OAM Sub-TLVs Sub-Registry

   Sub-TLV Type |        Description               |   Ref.
   ----------------------------------------------------------
       TBA2     |Ethernet OAM Configuration Sub-TLV|[This.ID]

   The value of 1 is suggested for TBA1.  The value of 32 is suggested
   for TBA2.

4.2.  Ethernet Sub-TLVs Sub-Registry

   IANA is requested to maintain an Ethernet Sub-TLVs Sub-Registry 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.

Takacs, et al.          Expires September 2, 2014              [Page 13]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   Ethernet Sub-TLVs Sub-Registry

      Range       |  Registration Procedures
      ------------+----------------------------
      0-65534     |  IETF Review
      65535-65536 |  Experimental

     Sub-TLV Type |      Description          |  Ref.
     ---------------------------------------------------
         0        |  Reserved                 | [This.ID]
         1        |  MD Name Sub-TLV          | [This.ID]
         2        |  Short MA Name Sub-TLV    | [This.ID]
         3        |  MEP ID Sub-TLV           | [This.ID]
         4        |  Continuity Check Sub-TLV | [This.ID]
         5-65536  |  Unassigned               | [This.ID]

4.3.  RSVP Error Code

   [OAM-CONF-FWK] includes a request for IANA to allocate a new Error
   Code, "OAM Problem" in the "Error Codes and Globally-Defined Error
   Value Sub-Codes" sub-registry of the "Resource Reservation Protocol
   (RSVP) Parameters" registry.  [OAM-CONF-FWK] defines a set of Error
   Value sub-codes for the "OAM Problem" Error Code.  This document
   defines additional Error Values sub-codes for the "OAM Problem" Error
   Code as defined below.

          Value | Description               | Reference
         -------+---------------------------+--------------
           TBA  | Unsupported OAM Version   | [This.ID]
           TBA  | Unsupported MD Level      | [This.ID]
           TBA  | Unknown MD Name Format    | [This.ID]
           TBA  | Unknown MA Name Format    | [This.ID]
           TBA  | Name Length Problem       | [This.ID]
           TBA  | Unsupported CC Interval   | [This.ID]

5.  Security Considerations

   This document does not introduce any additional security issue to
   those discussed in [OAM-CONF-FWK] and [RFC6060].

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 September 2, 2014              [Page 14]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

7.  Contributors

           - Don Fedyk
           - Dinesh Mohan

8.  References

8.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]
              Attila Takacs, Don Fedyk, and Jia He, "OAM Configuration
              Framework for GMPLS RSVP-TE", Internet Draft, work in
              progress, 2014.

   [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.

8.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.

Authors' Addresses

   Attila Takacs
   Ericsson
   Konyves Kalman krt. 11.
   Budapest  1097
   Hungary

   Email: attila.takacs@ericsson.com

Takacs, et al.          Expires September 2, 2014              [Page 15]
Internet-Draft   GMPLS based Ethernet OAM Configuration       March 2014

   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 September 2, 2014              [Page 16]