doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc7369.txt b/doc/rfc/rfc7369.txt
new file mode 100644
index 0000000..8ad2584
--- /dev/null
+++ b/doc/rfc/rfc7369.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Takacs
+Request for Comments: 7369                                       B. Gero
+Category: Standards Track                                       Ericsson
+ISSN: 2070-1721                                                  H. Long
+                                                                  Huawei
+                                                            October 2014
+
+
+                 GMPLS RSVP-TE Extensions for Ethernet
+    Operations, Administration, and Maintenance (OAM) Configuration
+
+Abstract
+
+   The work related to GMPLS Ethernet Label Switching (GELS) extended
+   GMPLS RSVP-TE to support the establishment of Ethernet Label
+   Switching Paths (LSPs).  IEEE Ethernet Connectivity Fault Management
+   (CFM) specifies an adjunct Operations, Administration, and
+   Maintenance (OAM) flow to check connectivity in Ethernet networks.
+   CFM can also be 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 the 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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7369.
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 1]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 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  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   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  . . . . . . . . . . .   8
+       3.3.1.  MD Name Sub-TLV . . . . . . . . . . . . . . . . . . .   9
+       3.3.2.  Short MA Name Sub-TLV . . . . . . . . . . . . . . . .  10
+       3.3.3.  MEP ID Sub-TLV  . . . . . . . . . . . . . . . . . . .  11
+       3.3.4.  Continuity Check (CC) Sub-TLV . . . . . . . . . . . .  12
+     3.4.  Proactive Performance Monitoring  . . . . . . . . . . . .  12
+     3.5.  Summary of Ethernet OAM Configuration Errors  . . . . . .  13
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
+     4.1.  RSVP-TE OAM Configuration Registry  . . . . . . . . . . .  14
+     4.2.  Ethernet Sub-TLVs Sub-Registry  . . . . . . . . . . . . .  15
+     4.3.  RSVP Error Code . . . . . . . . . . . . . . . . . . . . .  15
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  17
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 2]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+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.G.8013-2013] extended CFM and specified
+   additional OAM functionality.
+
+   In the IETF, the work related to GMPLS Ethernet Label Switching
+   (GELS) 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 [RFC7260].  The purpose of this document
+   is to specify the additional technology-specific OAM entities to
+   support Ethernet connections.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Overview of Ethernet OAM Operation
+
+   For the purposes of this document, we only discuss Ethernet OAM
+   aspects that are relevant for proactive connectivity monitoring of
+   Ethernet LSPs and assume that on-demand OAM functions 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
+
+
+
+Takacs, et al.               Standards Track                    [Page 3]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+   but may have different ESP-VIDs.  The formed co-routed bidirectional
+   path is a path where the forward and backward directions follow the
+   same route (links and nodes) across the network.
+
+   Note that although it would be possible to use GMPLS to set up 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 Entity Group End Point (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]:
+
+                +---+--------------------+----------------+
+                | # | 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
+
+
+
+Takacs, et al.               Standards Track                    [Page 4]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+   If three consecutive CCMs are lost, connectivity failure is declared.
+   The MEP detecting the failure will signal the defect to the remote
+   MEP in the subsequent CCMs it emits by setting the Remote Defect
+   Indicator (RDI) bit in the CCM.  If a MEP receives a CCM with the 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 Entity Group Intermediate Points
+   (MIPs) may be established to help failure localization, e.g., using
+   link trace and loopback functions.  MIPs need to be provisioned with
+   a subset of the MEP identification parameters described above.
+
+3.  GMPLS RSVP-TE Extensions
+
+3.1.  Operation Overview
+
+   To simplify the configuration of connectivity monitoring, the
+   associated MEPs should be automatically established when an Ethernet
+   LSP is signaled.  To monitor an Ethernet LSP, a set of parameters
+   must be provided to set up a Maintenance Association and related
+   MEPs.  Optionally, MIPs may be created at the transit nodes of the
+   Ethernet LSP.  The LSP Attribute Flags "OAM MEP entities desired" and
+   "OAM MIP entities desired", as described in [RFC7260], are used to
+   signal that the respective OAM entities must be established.  An OAM
+   Configuration TLV, as described in [RFC7260], is added to the
+   LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects specifying that
+   Ethernet OAM is to be set up for the LSP.  Information specific to
+   Ethernet OAM, 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
+      CCMs, the combined length of the MD Name and Short MA Name is
+      limited to 44 bytes (see [IEEE.802.1Q-2011] for the details of the
+      message format).  How these parameters are determined is out of
+      the 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 the scope of
+      this document.
+
+
+
+Takacs, et al.               Standards Track                    [Page 5]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+   o  The Maintenance Domain Level (MD Level) allows hierarchical
+      separation of monitoring entities.  [IEEE.802.1Q-2011] allows
+      differentiation of eight levels.  How the value of the MD Level is
+      determined is out of the 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 the scope of this document.
+
+   o  The desired forwarding priority to be set by MEPs for the CCM
+      frames may be specified.  The same CCM priority must be set in
+      each of the MEPs monitoring a given Ethernet LSP.  How CCM
+      priority is determined is out of the 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 reachability parameters and those
+      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 Media Access Control (MAC) address and ESP-MAC B is
+      the same as the 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;
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 6]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+   o  MUST include the OAM Configuration TLV with OAM Type set to
+      Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
+      objects;
+
+   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,
+      which 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; and
+
+   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 has all the information needed to properly
+   configure its local MEP.
+
+3.2.  OAM Configuration TLV
+
+   This TLV is specified in [RFC7260] and is used to select which OAM
+   technology/method should be used for the LSP.  In this document, a
+   new OAM Type, Ethernet OAM, is defined.  IANA has allocated OAM Type
+   1 for Ethernet OAM in the "RSVP-TE OAM Configuration Registry".
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 7]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+     RSVP-TE OAM Configuration Registry
+
+       OAM Type           Description
+     ------------      ------------------
+         1               Ethernet OAM
+
+   When the Ethernet OAM Type is requested, the receiving node 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 configuration parameters specific to Ethernet OAM.  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.
+
+    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             |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Version |MD L.|           Reserved (set to all 0s)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                           Sub-TLVs                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type: Indicates a new type, the Ethernet OAM Configuration Sub-TLV.
+   IANA has assigned the value 32 from the "OAM Sub-TLVs" 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".
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 8]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+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)            |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Format     |  Name Length  |   Reserved (set to all 0s)    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                            MD Name                            ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type: 1, MD Name Sub-TLV.  IANA will 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
+   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 than or equal to 44 bytes.  If
+   this is violated, an error MUST be generated: "OAM Problem/Name
+   Length Problem".  Note that 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                    [Page 9]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+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)            |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Format     |  Name Length  |   Reserved (set to all 0s)    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                       Short MA Name                           ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type: 2, Short MA Name Sub-TLV.  IANA will 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
+   the Type and Length fields.
+
+   Format: According to [IEEE.802.1Q-2011].
+
+   Name Length: The length of the Short 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 than or equal to 44 bytes.  If
+   this is violated, an error MUST be generated: "OAM Problem/Name
+   Length Problem".  Note that it is allowed to have no MD Name; in this
+   case, the MA Name MUST uniquely identify a Maintenance Association.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 10]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+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)            |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Local MEP ID           |T|R|      Reserved             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Remote MEP ID          |T|R|      Reserved             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type: 3, MEP ID Sub-TLV.  IANA will 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
+   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
+   corresponding MEP MUST expect to receive OAM packets.  These flags
+   are used to configure the role of MEPs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 11]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+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)            |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Prio  | CCM I |           Reserved (set to all 0s)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type: 4, Continuity Check (CC) Sub-TLV.  IANA will 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
+   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): 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.  Proactive 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.G.8013-2013].  Only a subset of PM functions are operated in a
+   proactive fashion to monitor the performance of the connection
+   continuously.  Proactive PM supports Fault Management functions by
+   providing an indication of decreased service performance and
+   therefore may provide triggers to initiate recovery procedures.
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 12]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+   While on-demand PM functions are, for the purposes of this document,
+   always initiated by management commands, for proactive 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.G.8013-2013] defines dual-ended Loss Measurement as proactive
+   OAM for Performance Monitoring and as a PM function applicable to
+   Fault Management.  For dual-ended Loss Measurement, each MEP
+   piggybacks 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 [RFC7260] 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 the error values specified in [RFC7260], 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 than
+      or equal to 44 bytes.  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.               Standards Track                   [Page 13]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+4.  IANA Considerations
+
+4.1.  RSVP-TE OAM Configuration Registry
+
+   IANA maintains the "RSVP-TE OAM Configuration Registry".  IANA has
+   assigned an "OAM Type" from this registry as follows:
+
+   o  "Ethernet OAM" has been allocated type 1 from the "OAM Types" sub-
+      registry of the "RSVP-TE OAM Configuration Registry".
+
+   o  "Ethernet OAM Configuration Sub-TLV" has been allocated type 32
+      from the technology-specific range of the "OAM Sub-TLVs" sub-
+      registry of the "RSVP-TE OAM Configuration Registry".
+
+   RSVP-TE OAM Configuration Registry
+
+     OAM Types
+
+     OAM Type Number | Description  | Reference
+     -------------------------------------------
+           1         | Ethernet OAM | [RFC7369]
+
+
+     OAM Sub-TLVs
+
+     Sub-TLV Type |        Description               |   Ref.
+     -----------------------------------------------------------
+         32       |Ethernet OAM Configuration Sub-TLV| [RFC7369]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 14]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+4.2.  Ethernet Sub-TLVs Sub-Registry
+
+   IANA will 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.
+
+   Ethernet Sub-TLVs Sub-Registry
+
+      Range       |  Registration Procedures
+      ------------+--------------------------
+      0-65534     |  IETF Review
+       65535      |  Experimental
+
+     Sub-TLV Type |      Description               |  Ref.
+     ---------------------------------------------------------
+         0        |  Reserved                      | [RFC7369]
+         1        |  MD Name Sub-TLV               | [RFC7369]
+         2        |  Short MA Name Sub-TLV         | [RFC7369]
+         3        |  MEP ID Sub-TLV                | [RFC7369]
+         4        |  Continuity Check Sub-TLV      | [RFC7369]
+         5-65534  |  Unassigned                    | [RFC7369]
+         65535    |  Reserved for Experimental Use | [RFC7369]
+
+4.3.  RSVP Error Code
+
+   IANA maintains an 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.  [RFC7260] defines
+   a set of Error Value sub-codes for the "OAM Problem" Error Code.
+   This document defines additional Error Value sub-codes for the "OAM
+   Problem" Error Code as summarized below.
+
+          Value | Description               | Reference
+         -------+---------------------------+-----------
+             7  | Unsupported OAM Version   | [RFC7369]
+             8  | Unsupported MD Level      | [RFC7369]
+             9  | Unknown MD Name Format    | [RFC7369]
+            10  | Unknown MA Name Format    | [RFC7369]
+            11  | Name Length Problem       | [RFC7369]
+            12  | Unsupported CC Interval   | [RFC7369]
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 15]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+5.  Security Considerations
+
+   This document does not introduce any additional security issues to
+   those discussed in [RFC7260] and [RFC6060].
+
+   The signaling of OAM-related parameters and the automatic
+   establishment of OAM entities based on RSVP-TE messages add a new
+   aspect to the security considerations discussed in [RFC3473].  In
+   particular, a network element could be overloaded if a remote
+   attacker targeted that element by sending frequent periodic messages
+   requesting liveliness monitoring of a high number of LSPs.  Such an
+   attack can efficiently be prevented when mechanisms for message
+   integrity and node authentication are deployed.  Since the OAM
+   configuration extensions rely on the hop-by-hop exchange of exiting
+   RSVP-TE messages, procedures specified for RSVP message security in
+   [RFC2747] can be used to mitigate possible attacks.
+
+   For a more comprehensive discussion of GMPLS security and attack
+   mitigation techniques, please see "Security Framework for MPLS and
+   GMPLS Networks" [RFC5920].
+
+6.  References
+
+6.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.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6060]  Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
+              "Generalized Multiprotocol Label Switching (GMPLS) Control
+              of Ethernet Provider Backbone Traffic Engineering (PBB-
+              TE)", RFC 6060, March 2011,
+              <http://www.rfc-editor.org/info/rfc6060>.
+
+   [RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
+              Extensions for Operations, Administration, and Maintenance
+              (OAM) Configuration", RFC 7260, June 2014,
+              <http://www.rfc-editor.org/info/rfc7260>.
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 16]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+6.2.  Informative References
+
+   [ITU-T.G.8013-2013]
+              International Telecommunications Union, "OAM functions and
+              mechanisms for Ethernet based networks", ITU-T
+              Recommendation G.8013/Y.1731, November 2011.
+
+   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
+              Authentication", RFC 2747, January 2000,
+              <http://www.rfc-editor.org/info/rfc2747>.
+
+   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
+              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC5828]  Fedyk, D., Berger, L., and L. Andersson, "Generalized
+              Multiprotocol Label Switching (GMPLS) Ethernet Label
+              Switching Architecture and Framework", RFC 5828, March
+              2010, <http://www.rfc-editor.org/info/rfc5828>.
+
+   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, July 2010,
+              <http://www.rfc-editor.org/info/rfc5920>.
+
+Acknowledgements
+
+   The authors would like to thank Francesco Fondelli, Adrian Farrel,
+   Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful
+   comments.
+
+Contributors
+
+   Don Fedyk
+   EMail: don.fedyk@hp.com
+
+   Dinesh Mohan
+   EMail: dinmohan@hotmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 17]
+
+RFC 7369         GMPLS-Based Ethernet OAM Configuration     October 2014
+
+
+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
+   China
+
+   EMail: lonho@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et al.               Standards Track                   [Page 18]
+