GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7369

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7369.txt · Last modified: 2014/10/17 00:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki