Ericsson

Konyves Kalman krt. 11. Budapest 1097 Hungary attila.takacs@ericsson.com

Ericsson

Konyves Kalman krt. 11. Budapest 1097 Hungary balazs.peter.gero@ericsson.com

Huawei

China lonho@huawei.com

Routing Area Network Working Group 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.

Provider Backbone Bridging - Traffic Engineering (PBB-TE) 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 , including the monitoring of specific explicitly routed Ethernet connections. The ITU-T Recommendation Y.1731 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 . 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 . The purpose of this document is to specify the additional technology-specific OAM entities to support Ethernet connections.

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 .

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 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 : # 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 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.

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 , are used to signal that the respective OAM entities must be established. An OAM Configuration TLV, as described in , 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 ) within the OAM Configuration TLV. 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 . 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 for the details of the message format). How these parameters are determined is out of the scope of this document. 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. The Maintenance Domain Level (MD Level) allows hierarchical separation of monitoring entities. 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. 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. 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. 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 , 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 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: 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; MUST include the OAM Configuration TLV with OAM Type set to Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects; MUST include the OAM Function Flags Sub-TLV in the OAM Configuration TLV and set the OAM function flags as needed; MUST include an Ethernet OAM Configuration Sub-TLV in the OAM Configuration TLV that specifies the CCM Interval and MD Level; 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 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.

This TLV is specified in 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".

When the Ethernet OAM Type is requested, the receiving node should look for the corresponding technology-specific 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.

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 . 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 . If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level".

The optional MD Name Sub-TLV is depicted below. It MAY be used for MD naming.

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

The Short MA Name Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.

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

The MEP ID Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.

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.

The Continuity Check (CC) Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.

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

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

In addition to the error values specified in , this document defines the following values for the "OAM Problem" Error Code. If a node does not support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version". If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level". If an undefined MD name format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format". If an undefined MA name format is specified, an error MUST be generated: "OAM Problem/Unknown MA Name Format". 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". If a node does not support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval".

IANA maintains the "RSVP-TE OAM Configuration Registry". IANA has assigned an "OAM Type" from this registry as follows: "Ethernet OAM" has been allocated type 1 from the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry". "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".

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.

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

This document does not introduce any additional security issues to those discussed in and . 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 . 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 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" .

Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling. This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK] Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. IEEE There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. This document is not an Internet Standards Track specification; it is published for informational purposes. Cisco Systems

519 Lado Drive Santa Barbara CA 93111 US +1 408 526 4257 fred@cisco.com

USC Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292 US +1 310 822 1511 lindell@ISI.EDU

Microsoft Corporation

One Microsoft Way Redmond WA 98052 US +1 425 705 3131 mohitt@microsoft.com

This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK] This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes. International Telecommunications Union

The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful comments.

Don FedykEMail: don.fedyk@hp.com Dinesh MohanEMail: dinmohan@hotmail.com