summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7369.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7369.txt')
-rw-r--r--doc/rfc/rfc7369.txt1011
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]
+